If Bitcoin changed anything, it would have been banned a long time ago. Coluche
Si Bitcoin changeaid quelque chose, il y'a longtemps que ça serait interdit. Coluche
Sounds like you don't know Silk. Private stablecoin with peg to various currencies, gold and BTC.
Price speculation and analysis has always been of little interest or even frowned upon in this community. Monero is a tool that works. If you need it then get it, or borrow it and then use it. It is not meant to be looked at, displayed in a showcase.
Edward Snowden,
I've been warning Bitcoin developers for ten years that privacy needs to be provided for at the protocol level. This is the final warning. The clock is ticking.
When they ask me why I withdraw money, I always answer: 'To buy Monero'. Even if I'm actually withdrawing it for something else.
Yet another bunch of people converting their coins into XMR.
On Monero-birthday, tell someone with an overjoyed look on your face that it is Monero-birthday. 100 extra points are awarded if you make a video of it, e.g. on Instagram, TikTok or Youtube.
Top-Tec! decentralized and doesn’t depend on any unique identifiers
From the Video "State of the Onion 2023"
"For the sake of clarity, I am stepping down as a member of the Monero Core Team effective immediately. I have not really had any active role in the Core Team in many years, and this is in line with my stated goals since 2018.
As part of this, any remaining privileges or access I have will be handed over or revoked. It is my hope that it can be handed over to new workgroups in the coming weeks / months, instead of the Core Team continuing in a highly centralised model."
fluffypony (Riccardo Spagni) Proposal: Disband Core
Currently the Monero Core Team is responsible for a number of things that are critical to Monero, and as a result there is a great level of trust implicit in them. For instance, a malicious Monero Core Team member could hijack the domain, and serve up malicious Monero downloads right after a new release. No matter how quickly this is detected, there will be many affected downloads, and could cause massive financial and privacy-related network damage. The recent CSS wallet incident is also an example of risks that the Core Team presents.
Additionally, this has been a thankless job that the Core Team has taken on (for no compensation), although even if there were compensation and constant praise it would still be a centralising force that we should try and eviscerate.
My suggestion, and I encourage us to use this thread to iterate on it in public, is to break the Core Team up into 6 self-assembling workgroups. This is not a complicated exercise, apart from the community coming to consensus as to who should form part of the workgroups. I would suggest we aim for a January 1st, 2025, cutover date for this.
Existing Core Team members can, naturally, choose to join a particular workgroup (or workgroups), if the community agrees they should. I, personally, will not be participating in any of these proposed working groups, and will use this as an opportunity to step back from any last vestiges of administrative involvement or perceived leadership in Monero.
Open questions that we should use this thread to answer is: (1) what should we use to quickly spin up some sort of loose consensus mechanism for the workgroups (eg. Strawpoll)? (2) how many members should be part of each workgroup?
Some basics that I think should be set in stone are: given the sensitivity of these workgroups, community members that do not have a long multi-year history should simply not be considered. Community members should also be familiar with secure communications platforms, GPG, and similar. Their GPG keys should preferably be a matter of public record already, or inserted into source tree as soon as possible. Many of the roles and responsibilities aren't just technical, but require building a deep relationship with service providers who are familiar with the sensitive nature of Monero's software and support the project's mission, so it would generally require individuals in those particular roles to not be abrasive, and to be warm and understanding and friendly with the individuals they deal with at those service providers. Finally, some of these workgroups simply CANNOT have any form of multisig / ACL / group access, and by definition each individual on the workgroup can exercise complete control and abuse their position (or be wrench-attacked, or be compromised). I've tried to note that below.
General Donation Fund Workgroup This workgroup can use multisig to share control.
Responsible for determining what General Donation Funds should be spent on, and dispensing them. The download server and CDN are the primary recurring costs, and we have a whole structure setup that pays those monthly via card / wire transfer and is reimbursed by the GF. They can choose to continue to use that, or they can do their own thing.
CCS Workgroup This workgroup can use multisig on the wallet, but some other aspects might inherently be more centralised.
Responsible for managing the CCS, approving proposals, managing milestones, etc. This obviously includes dispensing funds.
IP and DNS Workgroup This workgroup can democratise some aspects of it, but ultimately there will need to have a super-administrator for both domains and DNS (this can be a shared account).
Responsible for IP (as in intellectual property) which includes domains, trademarks, copyrights, service marks, anything along those lines. They're mostly going to be responsible for renewing the domains on an annual basis, ensuring the domains aren't stolen / socially engineered (I built an extremely deep relationship with our registrar, Gandi, over the last decade to prevent these attacks which occur very frequently). For multiple reasons we use Cloudflare to handle the DNS (including their embracing and facilitating Tor routing and access from Tor exit nodes, and their exceptional DDoS prevention). Of course, this workgroup is welcome to transfer the domains somewhere else, as well as move the DNS elsewhere.
Servers and CDN Workgroup This workgroup might be able to democratise some access, but as with the previous one there is a need for some super-administrator access (this can be a shared account).
Responsible for the CDN and server infrastructure. Currently there is a single, very beefy server on a 10gbps unmetered, well-peered uplink, that serves the Monero website and the downloads. We have a well architected, hardened configuration that was designed by Gus, formerly of Tari Labs, and Dan (pigeons), from Cypherstack. The CDN is one that we specifically chose because it has a network of endpoints in China, and thus bypasses the Chinese GFW to serve the Monero website and downloads. Of course, this workgroup is absolutely entitled to move the infrastructure elsewhere, switch off the CDN, etc.
Git Workgroup This workgroup likely can't democratise much at a high level (some nuance below), and will also require a super-administrator account (this can be a shared account).
Responsible for the monero-project GitHub organisation, managing GitHub issues and pull requests, managing maintainers, and managing releases. There is some democratisation in the form of individual repo access. In other words, an individual who isn't even part of the workgroup can be given write access (ie. maintainer role) on an individual repo. They are welcome to re-run the experiment we ran with self-hosted GitLab a few years ago, but I think we've demonstrated that GitHub is fine as a platform for collaboration, knowing that we will detect any malicious activity on GitHub's part really quickly as git acts almost as a blockchain, distributing the code (and its branches and history of changes) on the computers of thousands of Monero contributors and users.
Community Channels Workgroup This workgroup can democratise some individual channels, but it will require a require a super-administrator account (this can be a shared account).
Responsible for managing the various community channels, like the Telegram groups, the subreddit, the IRC channels, etc. Obviously these channels already exist, and this workgroup might choose to fold the existing moderators of the subreddit (for instance) into the workgroup. They could also exist as a distinct workgroup, working with those moderators and letting them handle changes to their moderation team. They would generally be expected to maintain some of the guidelines and standards we have for community channels (eg. no price talk in most channels / forums, there are specific places for that) and ensure that these guidelines are largely accepted and enforced where relevant. They would also be responsible for some more sensitive things like controlling the Monero namespace on Libera (the IRC server we use), which is an elevated level of access that allows the workgroup to take over any channel that starts with "monero" (useful for channels that are trying to scam or impersonate).
cross-posted from: https://monero.town/post/934733
SimpleX Chat
Private and Secure messaging platform without user IDs
Will this new messenger replace Signal?
by Evgeny Poberezkin
SimpleX Chat
Private and Secure messaging platform without user IDs
Will this new messenger replace Signal?
by Evgeny Poberezkin
cross-posted from: https://monero.town/post/444500
Your data is YOUR data!
An iPhone or an Android smartphone collects several megabytes of your personal data every day to Google Servers, even when it is inactive.
Murena smartphones have been designed to offer a different approach to users who care about privacy and data-hungry handsets.
Those smartphones are running the open-source “/e/OS” operating system, which is fully “deGoogled”: by default it doesn’t send any data to Google and it’s been designed to offer a great and natural user experience.
/e/OS is paired with carefully selected applications. They form a privacy-enabled internal system for your Murena smartphone. And it’s not just claims: open-source means auditable privacy.
P2Pool will hardfork to new consensus rules on October 12th, 2024 at 20:00 UTC (note that only P2Pool will hardfork, Monero blockchain will not hardfork on October 12th). Merge mining will be enabled at that time. You must update to P2Pool v4.0 or newer before this date. Changes in v4.0
New features:
Bugfixes:
Before you start mining, create a new wallet and don't use it for anything else but mining for privacy reasons - all wallet addresses are public on P2Pool! Only primary wallet address is supported - no subaddresses or integrated addresses.
It is strongly recommended to synchronize your system clock before you start mining!
Recommended monerod command line parameters:
./monerod --zmq-pub tcp://127.0.0.1:18083 --out-peers 32 --in-peers 64 --add-priority-node=p2pmd.xmrvsbeast.com:18080 --add-priority-node=nodes.hashvault.pro:18080 --disable-dns-checkpoints --enable-dns-blocklist--out-peers 32 --in-peers 64 is needed to (1) have many connections to other nodes and (2) limit incoming connection count because it can grow uncontrollably and cause problems when it goes above 1000 (open files limit in Linux). If your network connection's upload bandwidth is less than 10 Mbit, use --out-peers 8 --in-peers 16 instead.
--add-priority-node=p2pmd.xmrvsbeast.com:18080 --add-priority-node=nodes.hashvault.pro:18080 is needed to have guaranteed good working nodes in your connected peers.
--disable-dns-checkpoints is needed to avoid periodical lags when DNS is updated (it's not needed when mining) --enable-dns-blocklist is needed to ban known bad nodes
Usage:
Run Monero daemon v0.18.3.3 or newer: ./monerod --zmq-pub tcp://127.0.0.1:18083 --out-peers 32 --in-peers 64 --add-priority-node=p2pmd.xmrvsbeast.com:18080 --add-priority-node=nodes.hashvault.pro:18080 --disable-dns-checkpoints --enable-dns-blocklist Run p2pool: ./p2pool --host 127.0.0.1 --wallet YOUR_WALLET_ADDRESS Start mining to port 3333 on your machine: ./xmrig -o 127.0.0.1:3333 You can set custom difficulty for your miner to get more accurate stats on P2Pool side: ./xmrig -o 127.0.0.1:3333 -u x+50000 (it doesn't affect mining rewards in any way) To connect another mining rig to your P2Pool node, run ./xmrig -o YOUR_P2POOL_NODE_IP:3333 on that mining rig
Antivirus
Some antiviruses and firewalls may flag any Monero-related executables and archives, including P2Pool, as malware. This is because it contains RandomX mining code and therefore is considered as "mining software". To be sure that you downloaded the original binaries, always check SHA256 sums of what you downloaded - a GPG signed list of SHA256 sums is in sha256sums.txt.asc. You can read the instructions on how to do it here: https://www.getmonero.org/resources/user-guides/verification-windows-beginner.html - but to check P2Pool binaries, replace binaryFate's key with the GPG key provided here:
GPG key to verify SHA256 sums can be downloaded from github or p2pool.io