On Mon, 7 Apr 2025 at 12:35, Javier Mateos <[email protected]> wrote: > If the coordinator had malicious intentions in the beginning, these have been > observed and brought to the table by a community that is always active and > vigilant about these crucial issues. I believe this is already part of the > healthy culture surrounding Bitcoin.
I don't see a reason to believe the privacy weaknesses I have described have been exploited, due to the complexity of the attack. If they are/were exploited as discussed with Sjors above in the thread, users should be able to find evidence of that in their debug logs in the case of wasabi. In regards to samourai, as far as I know no coordinator is operating, and whirlpool functionality has been removed from the fork that is still maintained. That said, there also hasn't been much demand to actually fix these issues. They've been publicly documented for years. > -Overall Transparency: We need clear answers to questions such as: How are > the residual funds calculated and allocated? Which wallet(s) are used? > Ultimately, this information should be publicly verifiable on the blockchain. As far as I know there are currently two compatible client implementations, wasabi wallet and the btcpay coinjoin plugin. The trezor feature was removed following the shutdown of the zksnacks coordinator, as per https://blog.trezor.io/important-update-transitioning-from-coinjoin-in-trezor-suite-9dfc63d2662f It's not verifiable on the blockchain. To the extent that on chain data can be inferred, liquisabi.com provides estimate, but it's just a likely interpretation (in that it's consistent with well known behavior of the client and backend implementations), not proof, although there's no reason to doubt this information (see earlier in the thread re acknowledgement of the figures' accuracy). The source code for these clients is readily available, and has been throughout. Backend code is also available, but it is not possible to verify what software coordinator operators are running. In Samourai's case, there are different archives of the source code, since their self hosted gitlab instance was taken down, so I can't make strong claims about its authenticity but regardless the service is no longer in operation that doesn't matter as much. > -Audit and Review of the Revenue Model: Is the current mechanism (which > retains residual funds) the best option? Could the excess be redistributed > among users? Should it be handed over to a group of independent auditors, or > what alternative is best? These are questions aimed at finding more > transparent options, especially if disclosed properly. They could even be > addressed through a bounty, for example. If there is demand for more transparent coordinators, no significant barriers exist. Anyone switch to the ones that have posted disclosures instead of misrepresenting the facts, or start their own, and lead by example by clearly communicating the trust assumptions, e.g. the coinjoin.nl coordinator does that, but gets very little volume. if people want to operate for profit coordinators, or one that maybe donate all the revenue to some specific cause (perhaps sponsoring contributrions to fix these issues?), that's their business, though ideally they wouldn't wouldn't advertise their service misleadingly. Also note that the fee siphoning policy is trivial to revert, which would mean that a 0 fee coordinator would really have revenue, with any residues counting towards mining fees (decomposition can also be improved to reduce these residues, as per #6580). > -Audit and Review of the Protocol Architecture: The measures above would help > and could pave the way for the adoption of technical mitigations. In regards to wabisabi's architecture, that has already been done with respect to what's in the paper. What matters more is the implementation itself, not sure if that's what you meant by architecture. Over several years I've made many critiques both before I left (i.e. the aforementioned github links) as well as starting after the mainnet release (mainly on twitter), but not a single one of the concern I've raised has been addressed or refuted. My suggestion would be that people qualified to audit or review should probably start by verifying or refuting the claims I have already made. One of the mitigations I described in this thread (using multiple tor circuits to obtain the round information and introduce consistency checks between these) was supposedly planned to be implemented, or so I was told in private, but unfortunately I see no evidence of progress on that in the github repository. If new contributors are interested in implementing that, any of the other fixes described here or elsewhere, I am happy to provide them with more details, but bear in mind that some of the people still maintaining it dispute the existence of these issues (the only rationale i've seen is "it's a lightweigt client", which is irrelevant). -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECB2%3DFPiTkJ5HT813tcK1522j-J1%2B2%3DS%3Dnir6kb33KoQjw%40mail.gmail.com.
