From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Tue, 24 Jun 2025 19:32:53 -0700 Received: from mail-ot1-f55.google.com ([209.85.210.55]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uUFwS-0004Xm-Fi for bitcoindev@gnusha.org; Tue, 24 Jun 2025 19:32:53 -0700 Received: by mail-ot1-f55.google.com with SMTP id 46e09a7af769-73866ade2e1sf1834979a34.0 for ; Tue, 24 Jun 2025 19:32:52 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1750818766; cv=pass; d=google.com; s=arc-20240605; b=Q1pjzWRJp8h6fdaJvNRi/SrR26oWnSNbP4yIMNUiDPYoUpEiahPvVhf0MoVF8Gqfkq YOfSejmnX2tOiZq5hWDKwa2dW6qGE4qI7JY6TNUuTEK6rXOsmOoem4xV03/xNBtaPdf9 w9HJDwQWAdDbdyEuXMvxZ3Y+s/X3vys0lBKb/rqmrNCoryzWj20gvVL/BEqQ8eSsFQrd K5qDDANxNAMLoC3Ej3uwjtLzI0Jueq/EOXEXCf6PgJbOUAyNEf/iyqKxLUB7ei/c5bR1 2eRVOO6/A1ogkZawX3mtaKQ62b27N3sjYDKryMMiNMHYykwe+WTP4KP8zB1FwfE7hENg HZiA== 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 :dkim-signature; bh=/AR7yWgCBYERtCvleQ9F1gbtiW36iWuRdzw+hvJ9QUE=; fh=WlWROQ7HfeKjcASGLxgA/hjWVaqqAsqeye5w+7e2r88=; b=gkHIC0guCDGo60wbTNfAw4yhZNWMn5sAJoP9Iy/q9ZEtiRmQKUy4l+elynQMb2h01B CdKAlFabQ/qP+ZFhpa3hMr2OKwcNJncBzw4RmcLqAbGIejt2VpURZAkhkYEy9nubDyEG JSWJaf4sLs5SSXsAA9fs/Sq8no8xD8on0VB3g+HtkUsBdSeieb63AAMrva5TIc9ceVdS yWaG/i7/yjjm+GmSY8meqH8SlpiUmKQF0zL/75Y41Sp97kCu98plwzU0FA0n5+eLPxl6 S9mCdp4XtIREEV9JERP0k5kaTIFrGocHuzoVINO8YN8w7JF3YkP2hJP96vQ6gBi7G0op gbKg==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=LfDmG8UR; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750818766; x=1751423566; 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=/AR7yWgCBYERtCvleQ9F1gbtiW36iWuRdzw+hvJ9QUE=; b=S0fm7xfKsEbUbkWvVmtu9Vix3vlSl+7O2da4AaegjWJGk4EffkjbOQcxE08HWvS68h QZhv0olprCwRlqVFPPEDgyyK9LQpkmp00zVRQ6SrCLhWXRN2cbe738FxJR4E090wBX0b v6ZO/xcSC63CG6O0ofDT0+Puqs2AYtg4qfsZdlrqTzRBwk+NTUWIoiygYPIj5V/R3SpI ms3svEC9xeH2f6daEAAwf4bGXoLsYcPFiv3kgQfmsErRNAez8B/PYgqFA/1tYT4nMhx3 7Fqy36DDYjH0BeoUtFUA1zjtPq1nFVHR4Q8R3xsAzrqhVLsNhdslvhF3EY/DIEJg7+dG yhpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750818766; x=1751423566; 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:from:to:cc:subject:date:message-id:reply-to; bh=/AR7yWgCBYERtCvleQ9F1gbtiW36iWuRdzw+hvJ9QUE=; b=mDO2SC+JIOnDiHSSveGm+yRBO44fRvDKNk4SvUG7htRSocZcF41aJS/Z+l3zMp0QpW 7ftLMhF8YZBYXotBuGvMXFB5L85F6xLg6nOySdkq15jjblaSYoPIK92BpgG1U9b+imn+ WU3XbaYVaGRm6lzFprllEY5y3kXM0UY8aBhCx8wSFEkhm7AMNNOymngNNdoTF2RW6s9a /GKvt4M+HrRHzgfRlgGuXASuBV6UTa57w4rIkc7th3VJvDF/SOTu8ni3QtH+UK0sW1dS obPUNPPCIUCnXM6d7PpjIkMkvt5WCyPyIVJAgRbneEw+JFQp0YDqEUj6wSmMmW8tdNO8 FJJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750818766; x=1751423566; 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=/AR7yWgCBYERtCvleQ9F1gbtiW36iWuRdzw+hvJ9QUE=; b=lE4F7Xa8jGH8dpG3FbJr2BnYjnJxcZHJUgmRNHPXRyZuCr2XvA9vtaBdlUqYltc3JR XikUMLtzXtLftBJUaMiP6H2zj60wFiokncECGSQquKYHE6xcKDZlLwgZiMUpTCGbXOPk KjpECGet22acL6BrRp6jLC2MC639wrLu8tBXR97H/yPBmwToi3dpHYHfreSPyaKoVxzC iWJNbl1NsuMhUq5mu3h91l4eK87ROAuYD9JeujWtzpSpmDH3DqlKGcPL27o1mCbprHms yZIpID6E+6KXCq4t+syUyecLV68p8htpMePDyEQXc+OJlyr+WZVNaxiizwXmUEkhfl3H cwyg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUXXtXiltbm4vZ7gLQuNAfbsL0odh+/O3WFyoJXn4AXiDfkWZ3Xzlzz1ppBYEVSdUVXYXc2Fdo+Sx4k@gnusha.org X-Gm-Message-State: AOJu0YwPf8PPrZ8i0fXvYOtXKHp6nRv1uU35R2Ad6+fzCteL6HRGqo7z G432pIJDFMXg7RwgMhMU/5pkjqIYuPB3lFCoE8WaAmlNXSUUQVe/87Vz X-Google-Smtp-Source: AGHT+IHAV1NOnQcSV+H3bwO3ug6msMv+xkZ9oc92Rctio/ypjl7e/kaDe3ySuUOSt+alOP2cD7eiCg== X-Received: by 2002:a05:6820:328c:b0:60b:6a75:210d with SMTP id 006d021491bc7-6119d763ec3mr198515eaf.1.1750818766047; Tue, 24 Jun 2025 19:32:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZf1+IdjsfmavNN7KkooBaRumAGjQ0xR1gYCIurY7gAsCg== Received: by 2002:a05:6820:2e42:b0:611:91cb:cc5d with SMTP id 006d021491bc7-61191cbd55als237099eaf.2.-pod-prod-02-us; Tue, 24 Jun 2025 19:32:42 -0700 (PDT) X-Received: by 2002:a05:6808:2001:b0:408:e68d:975a with SMTP id 5614622812f47-40b05a11227mr1244764b6e.39.1750818762556; Tue, 24 Jun 2025 19:32:42 -0700 (PDT) Received: by 2002:a05:6808:bcf:b0:3fa:da36:efcd with SMTP id 5614622812f47-40b06236e1emsb6e; Tue, 24 Jun 2025 18:56:00 -0700 (PDT) X-Received: by 2002:a05:6e02:18ce:b0:3d8:2085:a188 with SMTP id e9e14a558f8ab-3df327f3d75mr16723525ab.1.1750816559877; Tue, 24 Jun 2025 18:55:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1750816559; cv=none; d=google.com; s=arc-20240605; b=FdEm1tf08yfADIkj99vVk6Avey3uOdO+ouq8zjjSg/V++h+mOLilLKy8CzFdHHjhS5 JUVI8AlP1B3zbNGq3S1HUMGiiCyzErxUZQiT7zwi6JW1jPAdFDCZS3bR/7S5X0RZ77ES fmw6E3AVBIPAR12918piSYjOW/rPI+6sz/fuXlx8U6Jp4N+OXOXa3pTMTilkTQ9KwGZs jbobIYUMwoJ0tkwRtWAoUzSOdeF4jb7iLf/vee/6qbeAml8pmG6yAIOtfEGw5nKGCO57 pNE9J8mAHuiwhqILQpDWjK3CWzdjrr/XwD1c1sznHf3J2OzepVWg3QcJxtzlHBt51XZp kCDg== 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=4bpt26FJ2HWhIWxaSpUoCwgUZyqeeM/9o1xnBN02fHI=; fh=zfrgopOiIZUyW/QOQMW3tlf+B0T0p2fpIoXRbxgb3Y8=; b=BsxXOyZwjcjfdwzC5W8Y+MCi22zu/QPNSDwuEjH9xE4OUYvBvODmtXRZuv3phm94wD mmpFxSX3CvZj42TPNKVOoKCDstmm4akmXv9v0zcf6UG51+Wxeb9uDqk0w8jka83DfW/y Id7LSu2pepy8OBk7lk4t1ziYhe6vkSSyhcxiqk87x8u36/LG/LTPEfQ41Z8yN/y4b9sh t+kEW/lNq8MOxltJDDNKAR1dncy2yuOzv0msiFbFD2GRVAWzsJPKxZ6ZTI1UrxKndFd9 0NH2uPzjBp4qN0sRWx71DkGPfYr5crGy7fG1C516t51ZM0mweywLwxNIPeF8ar+Z1J5B qplQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=LfDmG8UR; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com. [2607:f8b0:4864:20::336]) by gmr-mx.google.com with ESMTPS id e9e14a558f8ab-3de3762b2e6si5278095ab.1.2025.06.24.18.55.59 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Jun 2025 18:55:59 -0700 (PDT) Received-SPF: pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) client-ip=2607:f8b0:4864:20::336; Received: by mail-ot1-x336.google.com with SMTP id 46e09a7af769-72c09f8369cso357713a34.3 for ; Tue, 24 Jun 2025 18:55:59 -0700 (PDT) X-Gm-Gg: ASbGncsFISusuIAD9FdQ6gl2lxYIGSaGvY7cqTNYHnHxhBMbWd5lVbemUTFTN22uwuA 5MM6pa9MSVpVR1yremfmH+c+qSahONEPvPyGcGpr86aWuvHp6pYexEKEBPKzsStGVtlzR597WHc JGQm9bCn73FItRBbE/pSp75SvQSdoNT+hNGT1nURgClXXcOIz3YUH0evw0xkid X-Received: by 2002:a05:6870:5251:b0:2ea:73bc:1304 with SMTP id 586e51a60fabf-2efb23f3c4dmr1007077fac.30.1750816559166; Tue, 24 Jun 2025 18:55:59 -0700 (PDT) MIME-Version: 1.0 References: <8fb3deaf-417c-4ec9-9d23-424c4926905an@googlegroups.com> In-Reply-To: From: "/dev /fd0" Date: Wed, 25 Jun 2025 07:25:47 +0530 X-Gm-Features: AX0GCFs0htx1woMYWLLNNbKJdTwKXFGbZx4ABbobpqSZ61VsaGJy_4WzTVQbEKk Message-ID: Subject: Re: [bitcoindev] Re: Sybil resistance in different coinjoin implementations To: "waxwing/ AdamISZ" Cc: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000001378cd06385bbf93" X-Original-Sender: alicexbtong@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=LfDmG8UR; spf=pass (google.com: domain of alicexbtong@gmail.com designates 2607:f8b0:4864:20::336 as permitted sender) smtp.mailfrom=alicexbtong@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; 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.5 (/) --0000000000001378cd06385bbf93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi waxwing, A formula to calculate the UTXO value which could used to measure the cost of owning a UTXO: https://gitlab.com/-/snippets/4866444 It is simple and uses basic properties of a UTXO however it can be improved further. *Nothingmuch *has suggested a few improvements in a private discussion. > The actual problems with fidelity bonds are twofold: privacy headache from public utxo announcement, and expense (the expense part is unintuitive, but, if a value lock is to impose cost that *specifically prevents Sybils*, it's very valuable that it be counted super-linearly in the size of the utxo; otherwise, a high-net-worth Sybiler can split his amount into 100 pieces e.g. to get 100 valid entry tokens. While doing some research I realized that an attacker can lock 1 BTC for 3 months and open a short position in quarterly futures with minimum leverage to hedge locked bitcoin. In this case the only thing an attacker needs is to acquire 2 BTC. They would also earn fees from coinjoin being a maker. A few other problems associated with fidelity bonds are shared in this issue: https://github.com/JoinMarket-Org/joinmarket-clientserver/discussions/1773 > How much does that really cost? It's reasonable to answer "almost absolutely nothing", since you don't spend those coins, and while in a vague, abstract sense they are "locked" (you need some that lasted that long), a well funded attacker could always have that amount x10 or x100 sitting *somewhere*. I don't agree that it costs nothing to own a UTXO with x amount, y age and z type. A well funded attacker will need to own a lot of UTXOs to attack all the pools created in joinstr by different users. This introduces a cost for the attack. I think it works best when used in combination with fidelity bonds. /de/fd0 floppy disk guy On Sat, Jun 7, 2025 at 8:32=E2=80=AFPM waxwing/ AdamISZ wrote: > Hi fd0, > > You make some interesting points in these comparisons. I will address a > few things you say in the article at the end, here, but first I want to > discuss some background related to aut-ct (and yes this is mostly already > implicit in your article but for other readers, the following): > > I want to expand on something I said when we were discussing this on > delving [1]: > > There's always in my mind two very distinct threats from Sybilling. The > first is that your protocol might subtly (or grossly) depend on > non-collusion of participants. For that you want one kind of Sybil > resistance. > > The second is the problem of free-entry, which can occur even if > non-collusion is not a requirement. If anyone can join a protocol without > real limits, then the resource usage implied when the number of protocol > users increases by 1000x can screw up resource utilization. (Bitcoin itse= lf > deals with this beautifully through implicit PoW dependence of messages t= o > be considered valid.) > > My feeling when working on the idea of RIDDLE and then later aut-ct was > that I was only really addressing or thinking about the 2nd of those two > cases. It's not impossible to use a utxo ownership proof to address the 1= st > of the two above, but it's clearly much less strong, by default, than one > would hope. > > Just a pure "I own a utxo" imposes no, or negligible cost. As per the > delving post, and in a few other places, I've noted you can impose an age > and value restriction to bump up the cost. So it's not inconceivable but = I > suspect it's troublesome, and, it tends to fall into the "anything's bett= er > than nothing" category. While a fidelity bond with a public timeout is mo= re > convenient specifically because you don't need to have "prepared" it in > advance, a long time (so same lockup cost, but in advance). > > The actual problems with fidelity bonds are twofold: privacy headache fro= m > public utxo announcement, and expense (the expense part is unintuitive, > but, if a value lock is to impose cost that *specifically prevents Sybils= *, > it's very valuable that it be counted super-linearly in the size of the > utxo; otherwise, a high-net-worth Sybiler can split his amount into 100 > pieces e.g. to get 100 valid entry tokens. Chris Belcher originally > proposed and implemented a quadratic scaling [2], but we reduced that > default exponent and made it configurable, precisely because the HNW > Sybiler (or honest participant) can nearly guarantee participation. It's = a > whole can of worms, though). > > So given that, it's very natural to look for alternatives to, or finesses > on, fidelity bond ideas. Which you do, here, so, coming to some parts of > your article: > > > Since WabiSabi is a coinjoin implementation based on centralized > coordinator, a user must also trust the coordinator not to link inputs an= d > outputs. > > I can see that being true only in one specific sense: that Wa(bi)Sabi > coordinators can Sybil and thus link. Obviously in the default honest mod= e > of operation of coordinator this is not true of such systems. > > > Joinstr uses aut-ct as the primary > mechanism for sybil resistance, however fidelity bonds can also be used > with aut-ct. There is an initiator who creates the pool and adds sybil > requirements to join the pool. Everyone (maker and takers) needs to provi= de > the proof for a successful coinjoin. > > Interesting idea to blend, but I am left considering an ambiguity: > > When you say "fidelity bonds can be used with aut-ct" I *thought* you > meant that: the anon set can be the anon-set of all timelocked UTXOs (th= at > may or may not be fidelity bond type), but if you do that then of course > you need to form the anon set based on some time-range, I guess? The > problem I always had with this was how do we coordinate anything like thi= s > for the anon set to be big enough. Like, if you did it with aut-ct it wou= ld > either have to be taproot or users publishing (where?) the pubkeys in ord= er > to make the tree. People need to actually create these timelocked utxos, = so > they need somehow to be told well in advance what the realistic parameter= s > are for it. It seems very difficult practically to coordinate and then to > get to decent privacy, also (in case you commit a big chunk of funds and > then only 5 other people do it .. you were hoping 5000, now you have litt= le > or no privacy from a big cost. Just an example) > > But reading further I see you were looking at it the other way; literally > two separate things, both fidelity bonds, and aut-ct tokens. > > > Everyone shares aut-ct proof that proves they own a P2TR UTXO worth > 0.1-0.2 BTC that is unspent until last block and aged more than 2016 bloc= ks > > For me this example illustrates why Sybil-threat type 1 is not well > defended by this kind of system. How much does that really cost? It's > reasonable to answer "almost absolutely nothing", since you don't spend > those coins, and while in a vague, abstract sense they are "locked" (you > need some that lasted that long), a well funded attacker could always hav= e > that amount x10 or x100 sitting *somewhere*. Handwavy, but imo it's only = if > we want to prevent 1000 of those at once that it starts to be in some sen= se > "costly". But a Sybil attack on a coinjoin does not need more than N-1 > participants to Sybil an N-party join, so 1000 is way over the line. > > Cheers, > AdamISZ/waxwing > > [1] > https://delvingbitcoin.org/t/anonymous-usage-tokens-from-curve-trees-or-a= utct/862/3 > [2] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25= b > > On Tuesday, May 27, 2025 at 10:21:42=E2=80=AFPM UTC-3 /dev /fd0 wrote: > >> Hi Bitcoin Developers, >> >> I have written a post comparing the sybil resistance of joinmarket, >> joinstr and wabisabi. I did not include whirlpool in this post because i= ts >> not used anymore. Although it won't be any different from wabisabi. >> >> Its not a long post but written after doing a lot of research. The >> results show that joinmarket has good enough sybil resistance. However, >> joinstr provides better solution. >> >> Feel free to share your feedback. >> >> Link: >> https://uncensoredtech.substack.com/p/sybil-resistance-in-coinjoin-imple= mentations >> >> /dev/fd0 >> floppy disk guy >> > -- > 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/a34c4b4a-b8af-44d3-9b8f-ec52= 5438cc92n%40googlegroups.com > > . > --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= CALiT-ZqKQutZSFjzKwU%3DRRphCbArazJqfOzgF3oMAVuc_YhGew%40mail.gmail.com. --0000000000001378cd06385bbf93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi waxwing,

A formula to calculate the = UTXO value which could used to measure the cost of owning a UTXO:=C2=A0https://gitlab.com/-/snippets= /4866444

It is simple and uses basic properties of a UTXO howeve= r it can be improved further. Nothingmuch has suggested a few improv= ements in a private discussion.

>=C2=A0The actual problems with f= idelity bonds are twofold: privacy headache from public utxo announcement, = and expense (the expense part is unintuitive, but, if a value lock is to im= pose cost that *specifically prevents Sybils*, it's very valuable that = it be counted super-linearly in the size of the utxo; otherwise, a high-net= -worth Sybiler can split his amount into 100 pieces e.g. to get 100 valid e= ntry tokens.

While doing some research I realized= that an attacker can lock 1 BTC for 3 months and open a short position in = quarterly futures with minimum leverage to hedge locked bitcoin. In this ca= se the only thing an attacker needs is to acquire 2 BTC. They would also ea= rn fees from coinjoin being a maker.

A few other problems associated= with fidelity bonds are shared in this issue:=C2=A0https://git= hub.com/JoinMarket-Org/joinmarket-clientserver/discussions/1773

= >=C2=A0How much does that really cost? It's reasonable to answer &qu= ot;almost absolutely nothing", since you don't spend those coins, = and while in a vague, abstract sense they are "locked" (you need = some that lasted that long), a well funded attacker could always have that = amount x10 or x100 sitting *somewhere*.

I don't agree that it co= sts nothing to own a UTXO with x amount, y age and z type. A well funded at= tacker will need to own a lot of UTXOs to attack all the pools created in j= oinstr by different users. This introduces a cost for the attack. I think i= t works best when used in combination with fidelity bonds.

/de/fd0
floppy disk guy

On Sa= t, Jun 7, 2025 at 8:32=E2=80=AFPM waxwing/ AdamISZ <ekaggata@gmail.com> wrote:
Hi fd0,

Y= ou make some interesting points in these comparisons. I will address a few = things you say in the article at the end, here, but first I want to discuss= some background related to aut-ct (and yes this is mostly already implicit= in your article but for other readers, the following):

I want to expand on something I said when we were discussing this on = delving [1]:

There's always in my mind two ver= y distinct threats from Sybilling. The first is that your protocol might su= btly (or grossly) depend on non-collusion of participants. For that you wan= t one kind of Sybil resistance.

The second is the = problem of free-entry, which can occur even if non-collusion is not a requi= rement. If anyone can join a protocol without real limits, then the resourc= e usage implied when the number of protocol users increases by 1000x can sc= rew up resource utilization. (Bitcoin itself deals with this beautifully th= rough implicit PoW dependence of messages to be considered valid.)

My feeling when working on the idea of RIDDLE and then lat= er aut-ct was that I was only really addressing or thinking about the 2nd o= f those two cases. It's not impossible to use a utxo ownership proof to= address the 1st of the two above, but it's clearly much less strong, b= y default, than one would hope.

Just a pure "= I own a utxo" imposes no, or negligible cost. As per the delving post,= and in a few other places, I've noted you can impose an age and value = restriction to bump up the cost. So it's not inconceivable but I suspec= t it's troublesome, and, it tends to fall into the "anything's= better than nothing" category. While a fidelity bond with a public ti= meout is more convenient specifically because you don't need to have &q= uot;prepared" it in advance, a long time (so same lockup cost, but in = advance).

The actual problems with fidelity bonds = are twofold: privacy headache from public utxo announcement, and expense (t= he expense part is unintuitive, but, if a value lock is to impose cost that= *specifically prevents Sybils*, it's very valuable that it be counted = super-linearly in the size of the utxo; otherwise, a high-net-worth Sybiler= can split his amount into 100 pieces e.g. to get 100 valid entry tokens. C= hris Belcher originally proposed and implemented a quadratic scaling [2], b= ut we reduced that default exponent and made it configurable, precisely bec= ause the HNW Sybiler (or honest participant) can nearly guarantee participa= tion. It's a whole can of worms, though).

So g= iven that, it's very natural to look for alternatives to, or finesses o= n, fidelity bond ideas. Which you do, here, so, coming to some parts of you= r article:

> Since WabiSabi is a coinjoin imple= mentation based on centralized=20 coordinator, a user must also trust the coordinator not to link inputs=20 and outputs.

I can see that being true only in one= specific sense: that Wa(bi)Sabi coordinators can Sybil and thus link. Obvi= ously in the default honest mode of operation of coordinator this is not tr= ue of such systems.

> Joinstr uses aut-ct as the primary mechanism for sybil resistance, however fidelity bonds=20 can also be used with aut-ct. There is an initiator who creates the pool and adds sybil requirements to join the pool. Everyone (maker and=20 takers) needs to provide the proof for a successful coinjoin.
=

Interesting idea to blend, but I am = left considering an ambiguity:

When you say "fidelity bonds can be used with aut-ct" I *t= hought* you meant=C2=A0 that: the anon set can be the anon-set of all timel= ocked UTXOs (that may or may not be fidelity bond type), but if you do that= then of course you need to form the anon set based on some time-range, I g= uess? The problem I always had with this was how do we coordinate anything = like this for the anon set to be big enough. Like, if you did it with aut-c= t it would either have to be taproot or users publishing (where?) the pubke= ys in order to make the tree. People need to actually create these timelock= ed utxos, so they need somehow to be told well in advance what the realisti= c parameters are for it. It seems very difficult practically to coordinate = and then to get to decent privacy, also (in case you commit a big chunk of = funds and then only 5 other people do it .. you were hoping 5000, now you h= ave little or no privacy from a big cost. Just an example)

But reading further I see you were looki= ng at it the other way; literally two separate things, both fidelity bonds,= and aut-ct tokens.

>= Everyone shares aut-ct proof that proves they own a P2TR UTX= O=20 worth 0.1-0.2 BTC that is unspent until last block and aged more than=20 2016 blocks

For me this = example illustrates why Sybil-threat type 1 is not well defended by this ki= nd of system. How much does that really cost? It's reasonable to answer= "almost absolutely nothing", since you don't spend those coi= ns, and while in a vague, abstract sense they are "locked" (you n= eed some that lasted that long), a well funded attacker could always have t= hat amount x10 or x100 sitting *somewhere*. Handwavy, but imo it's only= if we want to prevent 1000 of those at once that it starts to be in some s= ense "costly". But a Sybil attack on a coinjoin does not need mor= e than N-1 participants to Sybil an N-party join, so 1000 is way over the l= ine.

Cheers,
AdamISZ/waxwing


On Tuesday, May 27, 2025 at 10:21:42=E2=80=AFPM UTC-3 /dev= /fd0 wrote:
Hi = Bitcoin Developers,

I have written a post comparing the = sybil resistance of joinmarket, joinstr and wabisabi. I did not include whi= rlpool in this post because its not used anymore. Although it won't be = any different from wabisabi.

Its not a long post b= ut written after doing a lot of research. The results show that joinmarket = has good enough sybil resistance. However, joinstr provides better solution= .

Feel free to share your feedback.

=

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.googl= e.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%40googlegrou= ps.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/= msgid/bitcoindev/CALiT-ZqKQutZSFjzKwU%3DRRphCbArazJqfOzgF3oMAVuc_YhGew%40ma= il.gmail.com.
--0000000000001378cd06385bbf93--