From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 11 Feb 2025 16:04:36 -0800 Received: from mail-qt1-f191.google.com ([209.85.160.191]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1ti0F1-0002x6-3e for bitcoindev@gnusha.org; Tue, 11 Feb 2025 16:04:36 -0800 Received: by mail-qt1-f191.google.com with SMTP id d75a77b69052e-47180af961bsf164150571cf.0 for ; Tue, 11 Feb 2025 16:04:35 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1739318669; cv=pass; d=google.com; s=arc-20240605; b=EPbPL+mijE849KP3bSAHerj4G9bumRioB/sqnJm/Y27te+EWXmZs54UZ90Lc6YasrP 4WUUKJvsEhU8QE4qpFVhly6DQ5zH2sq64Kd2it38SQvp1xiH3YaHpStvXscWbHPSahYW 4nDAwJC/BQmPLq3jNb5WzABrQ4UlWu3ofZkDWlKwk0BKUo4XHtzeAf2KAuUmYWO1KDQX FEOkufTPAHP8wTGGc5/UXxrBnI/J4GbMxlx5DYzPfpCD3iyj9ZaS1rG/+o367MBoJQc+ 1uP3utO1UjcxYm0i8Gbj5CJoK5lP6hsjEakljE6Zj1OAvBHm6ZwLXuiN5IyxtJXziwcH HC/A== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature; bh=WCiMB+9yOgdYozb1xFhdvxo9096m6DnJV4cbzarh2bg=; fh=iMQzebucNsf+yiwOgHHMfB036B5JXxpIcvR0lTInX5M=; b=Uk2/4HQByPDDnVkxSXhqP8PA2M6IS/+SQgJRdfd5xEUACwHGKfaxVimAo5NG593kAk wnN0Ty1M+lZiTY0gqLxIfZtrlBzH0fVuvK/F92iQV6hyQCyZNGw5Y5eTC609RwKK06j5 BQKVYQ1vmyN4rPPMEEIlDYgGmjYqOGpGsrPinr/gQWQvWZUiXT6QAWyQOIY1AVTwidfF WsCXVH6VV4FDcWN4jyn1wNKGIhL0DJlrqaytdcw/GXLqlv3KD7UfOelctwoLXfN8T4DJ Kh9fGjx1TijNUr3Fcj8fPzJxVIT29nsVY7WHhelHy2YeXJ4FlIXmi1KIEeaX9k8jmCSC WQzA==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@woobling.org header.s=google header.b=BacKA6fV; spf=none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) smtp.mailfrom=nothingmuch@woobling.org; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1739318669; x=1739923469; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=WCiMB+9yOgdYozb1xFhdvxo9096m6DnJV4cbzarh2bg=; b=CILRD8dQNEO0WLbOJDZ4FToUbQFjh1PD43g3DsgVqPnIOI3C3F6VLnH6Hdup8KUNsm 1EF4PAsCqSIh9u2CwKzgn5AZhdC9ph8azTtvmt4HPaEczSxkoTn6JZTpnq6kp2gyQm3y Ry7Sbz0w4FAoZFdbw3fQQgjq4CchoeuoSa+yB1mwhYi/oV/A2zoErwf4ZdpcZ6L4I9bb eXwwKA4ZkDpaG/+ujTQAqu90es/+PYDpufe+SnB9h7RDsl7K9gOwfWU288VgKRQ5zIUL eA3apU1b9BIPOqe/ybqMY7d16rHi76KvtKASzsSBUpSKK8KvQbxyq5oNZ/Y9qssH6NiG +12Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739318669; x=1739923469; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=WCiMB+9yOgdYozb1xFhdvxo9096m6DnJV4cbzarh2bg=; b=lJMxEqvlmenKzU6GD9VYyCwPEwYrSkT3aOSC9dIaygU3XcOl47PfjcfIDirX60/3uO YUXWF+F+paMDuZISs3XWwQDZpwfe9i/m+8A7/w7jIwg6KsjOLZJPFI6L6Awazn4Eb+6a VLUs/B9k28BjRAHrMXrJOQ6nker81fn3LaDWqr6B3W3j9keaVNPiHjHI2P+pZF5WiOt0 JvWz0ZmEKIYfTZSLcrIo3/4CFtsR26ruUg2MbGkutt1+6ebO9q+gc2DzP7cr8igX102a PmYPYo2Q2EBlOT7KCmrgMoJudd5c1bsMUZgxskPGAq65DavC77yiXXWRKgR7MQnHQzZM kkEw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCVNoDyT0b6o+fBRJIRw8omrmKC1FoShAK/2EaOirTedULGRRgUiSioQ6ni1nueU/eOLE3tIhFySTB4L@gnusha.org X-Gm-Message-State: AOJu0YzRsPXIW434QbyQmb0EztiZaC2aAA/TkGVQSI5Z3Aygf6Kfz7qI y5PyrxSu5/9cDTL/RHmheFfIzwzaStd5tFBiaGZvD2V5aDGlezeM X-Google-Smtp-Source: AGHT+IF47WvcrROlvnZqpu/oQCAUhPZu6AmLk9+rQ8YOZgGHvk7r+/7V2pajscL3KkWGSSwX9yQpEA== X-Received: by 2002:ac8:5a48:0:b0:471:8183:a66a with SMTP id d75a77b69052e-471aff26c49mr15977701cf.47.1739318669086; Tue, 11 Feb 2025 16:04:29 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:ac8:5e4c:0:b0:46b:2e03:7b85 with SMTP id d75a77b69052e-471a0cabefdls25244551cf.2.-pod-prod-04-us; Tue, 11 Feb 2025 16:04:25 -0800 (PST) X-Received: by 2002:a05:620a:440f:b0:7b6:d079:748f with SMTP id af79cd13be357-7c06fcd53c0mr299104085a.54.1739318665379; Tue, 11 Feb 2025 16:04:25 -0800 (PST) Received: by 2002:ae9:e110:0:b0:7b6:67a8:4fcd with SMTP id af79cd13be357-7c04784d284ms85a; Fri, 7 Feb 2025 12:07:25 -0800 (PST) X-Received: by 2002:a05:600c:3ba9:b0:434:a91e:c709 with SMTP id 5b1f17b1804b1-439249c05e8mr35632425e9.28.1738958843487; Fri, 07 Feb 2025 12:07:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1738958843; cv=none; d=google.com; s=arc-20240605; b=DjrnH7ivcqYizqWOfTnbiQFoFyuNGu+ajRfZCKbxCP5kGO8P6YnzsyzFg8ar6K8Qrp CiqmnKJKZLH4HwIbRBwwruj1RKtLFjGqxODjBB6FXY8TIrWrS1373aGzVQa53+A1z+10 FkTZLvwHu7BxJ0yI0XRbO8pO7bn9iRusETCponGq87jd3Ud1jYQ87L6Fq1M+3MVT5JF7 DIqJG18J0agrveSrBvOH9Ac6zfQE/1n+XXZlUrwF9IhAneZWiOeOiDNPFOq64AY4r5YL EkvufANO99aAEB/XVVwL3hOT7T2M6H6Nxf0a2gbWycB5EkqjheNqn/Xncw9niKH8Hm2k OceQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=x4hfN551gVa78u8+4tNs4pJK3sPbE8/E8z3e8vHgjcU=; fh=yPd8HNyAt94w6+9mawPnFhKq8crEnOt8R5D/kg3m3ro=; b=UsBduelbHveJGIwJ9T4etd+3vYCl2V5iYFyLg0maTvRejHufLJynZcStiuDHDLlSK+ lcSz4rRLS+ZRHasqAadO1J73F/t2+CsuQtYr1TIBLT+Z/T9M7uvth1rQ01MJEcoCOP8A XAuBYeWNDa2dTJ5w11JoSAylg8IG6MBqYsJFIZUOnTvCjTFY/YOtxgTymIgLgs8a4VXu GgjIoSrthMQTc6bUiatPBZCf5mMwNMSNYuV07YDNleBmxYFEh0NW7/2EFnxJaz9LGUCG ZVi7hxB+T7CH2C0MHCiV1IW3opbMT2pZvJx9WlriEgx7w4Za6/Ohq5T3mjNJ0ybSUl5e +RHA==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@woobling.org header.s=google header.b=BacKA6fV; spf=none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) smtp.mailfrom=nothingmuch@woobling.org; dara=pass header.i=@googlegroups.com Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com. [2a00:1450:4864:20::136]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-43907f18ffcsi3784215e9.1.2025.02.07.12.07.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 07 Feb 2025 12:07:21 -0800 (PST) Received-SPF: none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) client-ip=2a00:1450:4864:20::136; Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-5439e331cceso2872410e87.1 for ; Fri, 07 Feb 2025 12:07:21 -0800 (PST) X-Gm-Gg: ASbGncvayQOM3pYiAse/mZO1FIMhfJGU2fbg5isbZmzOxlSIJXITZHIDbMqDKsmaZWA oSMNOqIRYMy8btZn00UA46CunjSLYBybLG7Qa6XrQwfkd1YxrKS7gT6JbKxPh/J57LbQ4U96S X-Received: by 2002:a05:6512:2824:b0:53e:3a79:1ad2 with SMTP id 2adb3069b0e04-54414ae0e10mr1226623e87.40.1738958840132; Fri, 07 Feb 2025 12:07:20 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Yuval Kogman Date: Fri, 7 Feb 2025 21:07:08 +0100 X-Gm-Features: AWEUYZm6NyLUotdn1mJdPqjSEmSEpnzDGbJepB47SEV_sGKUJpPCNUnJSWwIH7g Message-ID: Subject: Re: [bitcoindev] Reiterating centralized coinjoin (Wasabi & Samourai) deanonymization attacks To: Peter Todd Cc: Bitcoin Development Mailing List Content-Type: text/plain; charset="UTF-8" X-Original-Sender: nothingmuch@woobling.org X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@woobling.org header.s=google header.b=BacKA6fV; spf=none (google.com: nothingmuch@woobling.org does not designate permitted sender hosts) smtp.mailfrom=nothingmuch@woobling.org; dara=pass header.i=@googlegroups.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) On Tue, 4 Feb 2025 at 23:22, Peter Todd 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 bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAAQdECDH20thrpNJ%2BBv43DqmJfxyTRJ4BgoVjUU8Vz8i4%2BZEGA%40mail.gmail.com.