On Tue, 4 Feb 2025 at 23:22, Peter Todd <[email protected]> wrote: > The supermajority of the people posting on this mailing list are being > paid for their work. It would be silly to pre-face every single email > with "sponsored by Foo"; what you are replying to is just an email, not > my actual review publication, which I have not completed yet.
What I said was: >> paid for by an interested party as a direct response to accusations I have >> made The conflict isn't that you are being paid, but that you're uncritically repeating unsubstantiated, and even refuted assertions made by your sponsor, who hired you as a direct response to me correcting him on those assertions which misrepresent how his service and the software used to access it both work. You were also cc'd on the moderated version of the email that you're replying to which spelled this out in detail, with supporting evidence. https://gist.github.com/nothingmuch/dcc7c38ab4a689bfc5c13dcb474d134f/revisions > The amounts involved are tiny, always less than the > transaction fee, as you can easily see on https://liquisabi.com/ There's a difference between presumed and informed consent, between presumed consent due to genuine misunderstandings, lies by omission, and deliberate & persistent misrepresentation of verifiable facts, that mislead users about what they think they are consenting to. If the service is really free as users are being told that it is, how does it generate ~0.2 btc in revenues a month? There's nothing wrong with earning an income for providing a useful service. What makes it wrong is that it's misrepresented as being free and trustless. Whether or not you personally think the amounts are negligible is completely beside the point, that's for users to decide, which they can't if they are being misinformed. > Due to how Wasabi coinjoins work, coinjoins will almost always have some > small amount of sats left over that didn't decompose into standard > denominations after the transaction fee is paid. No, that's not "how Wasabi coinjoins work". This is *entirely* client side policy. The fact that the policy is so lenient is an implementation bug (again, a claim I made years ago which was never argued against) that has no technical justification, and no economic justification when fees are low. Claiming the excess mining fees for the coordinator is exploiting this bug. > Those sats go to the coordinator. During most of the zksnack's coordinator run, that surplus went towards *mining* fees, and was widely understood to do so. This part is entirely server side policy, and possible due to gaps in the protocol and the client implementation. The coordinator software was modified to claim those excess mining fees with no justification of overruling cNACK that had led to it being not merged 6 months prior https://github.com/WalletWasabi/WalletWasabi/pull/10884#pullrequestreview-1485776991 and that was only publicly documented around 7 months later, after the zksnacks coordinator shutdown and the removal of explicit coordinator fees https://github.com/WalletWasabi/WasabiDoc/pull/1841/files and only fully clarified a month after that https://github.com/WalletWasabi/WasabiDoc/pull/1859 Again I suggest you read the wabisabi paper, section 7.2.2, because the you are conflating two kinds of cost that are explicitly discussed in that section: > In particular, remember that that fees are part of the coinjoin security > model: we *need* transactions to be costly enough to prevent sybil > attacks. Contributing this excess towards *mining* fees is a meaningful deterrence against sybil attacks. This is precisely the original justification I gave for the set of standard denominations I proposed, where the excess was supposed to be randomized and around fee-rate dependent overhead of creating ~1-3 TxOuts (and not just <1, which is what a pure mining fee minimization strategy would dictate, due to privacy concerns discussed in the previous email relating to the generalization sub-transaction model that accounts for fees). Coordinator revenues, unlike mining fees, *reduce* the cost of sybil attacks if the coordinator is colluding with the sybil attacker. Since there is no *requirement* to pay an excess, even in the setting where the coordinator and the sybil attacker are assumed not to be colluding, where this could theoretically be a deterrent, a sybil attacker can economize so this only harms users with unmodified clients. Claims about the protocol or its implementation work should be supported by evidence. Opinions on how it's supposed to work should be supported by a rationale. Of course, this should also have applied to the discussion of #10884. > I'll let others decide whether or not you're being dishonest by not > mentioning the tiny amounts involved, while simultanously claiming I'm > being dishonest by not mentioning in my email that (as usual) I'm > getting paid to work on this stuff. For the sybil deterrence reasons, in particular with regards to the concern about targeted attacks, and because of the lack of informed consent, ~0.2 bitcoin of revenue per month can't be dismissed as "tiny amounts", especially when the service is described as being "free" specifically order to avoid regulatory overreach (see twitter spaces link in moderated email) in response to the Samourai trial. My claim is that you are minimizing these concerns with no justification, consistent with the minimization your sponsor is doing, who stands to gain financially. > Wasabi set the coordinator fee limit to 0% by default in the Jun 2024 > release: This was done in response to malicious coordinators that tricked the client into just giving them money, with no value provided and no other participants, i.e. another client bug. The origin of this flaw is that verifiably fair computation of coordinator fees by all parties to the coinjoin was never implemented, see also https://github.com/WalletWasabi/WalletWasabi/issues/8814#issuecomment-1199635171 It does not follow from the removal of explicit coordinator fees that the following holds: > Kruw's coordinator does not charge a coordinator fee. The fact that one mechanism for extracting revenue from clients was called coordinator fees and another, underhanded one is not, is arguing semantics. What actually matters for analyzing sybil concerns and for users' consent is where the money goes. What exactly is the problem with clearly informing users about where the excess actually ends up, and that the protocol requires some trust in the coordinator's honesty, so that their consent is informed? If doing so harms revenues, the implication is that consent was obtained deceptively prior to disclosure. -- 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/CAAQdECDH20thrpNJ%2BBv43DqmJfxyTRJ4BgoVjUU8Vz8i4%2BZEGA%40mail.gmail.com.
