"If you use XMR, then there isn't much anyone can do (or to help you with), as far as I know. Bitcoin can be traced, but not frozen, until you send it to a CEX."

"The key point is, you have the choice."

• Twitter

@cz_binance said it before and he will say it again:

Bitcoin is traceable. https://monero.town/post/461435

"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 at GitHub

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).

• fluffypony at Github

cross-posted from: https://monero.town/post/934733

SimpleX Chat

Private and Secure messaging platform without user IDs

Will this new messenger replace Signal?

Watch on Youtube

by Evgeny Poberezkin

SimpleX Chat

Private and Secure messaging platform without user IDs

Will this new messenger replace Signal?

Watch on Youtube

by Evgeny Poberezkin

Seraphis wallet development, 1 year report

TL;DR: A group of Monero devs is busy implementing "next generation" technologies for Monero called Seraphis and Jamtis that will bring solid improvements. After about 1 year passed since project start they did not yet get very far unfortunately but do have some interesting results to show, and speed will likely pick up considerably soon. Still, the corresponding hardfork is years out, and the design of those technologies is not yet fully settled nor fully reviewed for security.

Next month it will be 1 year that a number of Monero devs formed something like a workgroup with the goal to develop a wallet for the upcoming Seraphis and Jamtis based Monero and I took on the job to care about the project management side. It's therefore a good time for a report about what happened so far.

You find general info about Seraphis, Jamtis and the workgroup here on our wiki. The Seraphis and Jamtis FAQ linked there may be especially useful.

A word of caution here: Regardless of any implementation work, Seraphis and Jamtis as cryptographic designs still need a review by at least 1 competent independent third party, and so-called security proofs developed for them wherever possible. Efforts to find such a party are under way.

The Seraphis wallet workgroup does not build a new wallet app, like Cake Wallet or Monerujo are wallet apps. We build a new component within the Monero core code that most of those apps will rely on internally once reworked for Seraphis. For lack of a good and unambiguous term we also call that component wallet.

I admit right away that we don't yet have many hard results to show, i.e. very little actual reviewed code that has a chance to become part of the final Monero software, and no prototype of any sort yet, despite the almost full year that passed.

Personally, I have mixed feelings about that but wouldn't call it an outright failure. I see several factors that resulted in this still modest result.

When UkoeHB, the designer / inventor of Seraphis, set out about 2 years ago to implement Seraphis and Jamtis as designed by Tevador, the idea was that he would crown his dev work with a prototype of a wallet that we other devs would then flesh out and improve until it reached production quality and finally became ready for a hardfork.

Unfortunately building a wallet prototype turned out to be out of reach within his work. What he finally built was "only" a general-purpose Seraphis and Jamtis library that could be used to implement, among other things, a wallet. The good news however: That library turned out to be a marvel of solid software engineering and a very good base for our work.

In the first weeks we had so many devs showing interest in contributing work that I started to worry about coordination and finding enough reasonably independent parts of the wallet to work on concurrently. Alas, this never developed into a real problem: For the people without knowledge yet about the Monero codebase the challenge mostly proved to be too daunting, and the people with such knowledge had many additional Monero things on their hands at the same time and couldn't concentrate on the wallet alone.

Still, I can report some pretty good results:

u/j-berman wrote a scanner, a piece of software that reads through the blockchain starting at a specified height and finds all enotes / outputs that belong to a given Monero address - a core part of every wallet. He was using the Seraphis library to do so because that has full "read support" for pre-Seraphis transactions. The encouraging result: The scanner, although still at an early "version 1" so to say, is already faster than the true-and-tried scanner inside the current component called wallet2, up to a surprising 40% when using a remote node.

u/dangerousfreedom1984 originally set out to write something like a frame for a wallet prototype. The bad news: That is still work in heavy progress. The good news: He wrote some nice so-called proofs on the way. For example, the basic code that allows to construct a proof that it was your wallet and not any other that made a particular Seraphis transaction exists already.

jeffro256 joined the workgroup a few months ago. He wrote a new component to read today's wallet files that is fully independent from code that will be retired after getting superseded by the Seraphis library and the Seraphis wallet, which will be essential for a seamless migration. It's nice to have that settled already, but on the other hand this did not further the wallet proper yet.

So, how will things probably continue? I see again a mix of good news and bad news.

All 3 devs mentioned above know their way around the Seraphis library now and are able to productively write code that will be relevant for the switch to Seraphis and Jamtis. I think right now we have more dev capacity working on Seraphis related stuff than other, more general Monero stuff.

On the other hand there are surprising developments on the design front over the last few months. For quite some time it looked as if the designs of Seraphis and Jamtis were complete and set, and we "only" had to implement them.

That has changed on two fronts at once.

jeffro256 started an initiative to fix a weakness of Jamtis that plays a role in connection with possible future third-party blockchain scanning services, somewhat similar to what MyMonero servers are doing today, but much more privacy-friendly. The already long and quite technical discussion starts here. Personally, I would love to see that weakness gone, but it's also a bit disturbing that quite deep changes are on the table for something that looked rock-solid already, and if this gets accepted it means more delays of course.

u/kayabanerve started an even bigger "attack" on the current design of Seraphis: He set out to once and for all get rid of the weakest of Monero's privacy technologies, the rings, by using so called full chain membership proofs. Info about this story can be found here.

On the one hand it would be fantastic to see it implemented, or at least prepared to avoid the potential logistical nightmare of people having to change all their Monero addresses twice. On the other hand this alone may push the hardfork to Seraphis and Jamtis a full year further out, and as a more immediate consequence it will absorb a big chunk of u/j-berman 's capacity while he connects kayabanerve's code with the Seraphis library to test the feasibility of the technology.

Do we have to worry that Seraphis and Jamtis are still years away? If you ask me, Monero as of today stands pretty solid. For all we know, currently we don't have exploits, we don't have spam attacks, and the privacy holds up quite well. This does not look like an emergency of any kind to me.

Still, of course we will try to move much faster in our second year than we did in our first. The signs that we will be able to look good.

If you are a dev and could imagine to become part of this adventure, read our "job offering" page here.

- Reddit -

Sophon SG2042R SOC Risc-V 64cores (2ghz), 64mb-cash, 8gb DDR4 3200

0% fee mining SWITCH NOW

It is the officially recommended way to mine Monero! Here are seven easy steps:

• 1) Download the bundled version of Gupax examples:

windows file: gupax-v1.3.1-windows-x64-bundle.zip

macOs file: gupax-v1.3.1-macos-x64-bundle.tar.gz

• 2) Extract
• 3) Launch Gupax
• 4) Input your Monero address in the P2Pool tab (or create a new one for mining)
• 5) Select a Remote Monero Node (or run your own local Monero Node)
• 6) Start P2Pool
• 7) Start XMRig

Motivation: The hashrate of centralized pools increases; so: miners update the mining software and/or start new workers, but do not change their used pool to p2pool. p2pool should be used in general because it is the best technology and:

• 0% fee
• 0 XMR payout fee
• ~0.00027 XMR minimal payout

Maybe an monero.town OP can pin this. It's important.

Coming "This Fall"

How will it hash RandomX?

Ampere ARM - Hetzner Matrix

https://www.hetzner.com/dedicated-rootserver/matrix-rx

80 cores, 128/256 GB DDR4 does XMrig scale?

P2Pool v3.6.1 was released.

Changes:

• Fixed Windows 7 compatibility
• Fixed a crash when running as a systemd service

Github - SChernykh p2pool

P2Pool v3.6 was released.

Changes:

• Avoid unnecessary block broadcasts and block requests to save traffic (works best when connected to v3.6+ nodes)
• 2 times faster initial sync when connected to v3.6+ nodes
• Release binaries for Windows are now built with clang compiler (7-8% faster block verification)
• Tweaked how release binaries for other OS are built, binary sizes are reduced significantly
• Fixed a rare data race bug that could happen during block verification
• Added a full source code archive with all dependencies

Github - SChernykh p2pool