From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 25 Jun 2025 06:05:43 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uUPor-0004fP-Di for bitcoindev@gnusha.org; Wed, 25 Jun 2025 06:05:43 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e812e064de6sf7008134276.3 for ; Wed, 25 Jun 2025 06:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1750856735; x=1751461535; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=uZCPfGNWHNXlOCsqFfVHL5LYzDO814HdaCi4UPS85LU=; b=E5kAHHyaWBkwpqs2Pe7Gz6kjCiSPkjVS+d2vqYpRtyE1ZHRu07GBPETeDTT5OGd9Bx knF2SZiz+aFSO46dfnLX8/+fbW+J9g3/zkoLKn4sPSo0Ci1VOhNQf6ivQ7gbCVUDiSTa bO1dcLiky7uYuTnmyVMqZvmou2Sig7vxmzUmjZJ9kgmKotcF1a8MVtQ9GX1MWDLJyKqO gRXMPLdL5lteuqtPdL30AWgCPMxWCvM5Bm5bdDICcSTSXtcrusoOBxaq4Bu/Gz5fZGoh B0t+IgntSw6zH2qE6J0q1OJSPRoYkEeh7OWOL6yljLYANGO0uhWD2QpRQWoulaeuNVy9 70nQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750856735; x=1751461535; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=uZCPfGNWHNXlOCsqFfVHL5LYzDO814HdaCi4UPS85LU=; b=NCh/jsGDhK5+uxvwyCMxIE+7i2ZvbX1ArflK+AWAcvht1xYI69WN0B7L5JV/DiBegR sn+u1YEDqVmKjz5uYqPVKYONvOU5fUX+CjuYk34H4rPV7yiCxpCnqromo8CCewlIrCU3 Ro4Whdk4QAuuuCwzt4x0nZsWNvlaiosJEn6t8LCeunwC3SwQtFJ9AKLsy6EIu/dSeM/R 8khX6BRE/St/DlAPwD4SSIJIBdjRC2fzE85xoCEF8GWeaw6L0WrYN/aj0cI+Hkzyo+c9 FmCOd9L6AYTNaTtHW9sf8msJntTA8rQ4oqP8jiSJ8QXTCPWP6ngO4rrC19IAx2lpeYMI xICw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750856735; x=1751461535; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=uZCPfGNWHNXlOCsqFfVHL5LYzDO814HdaCi4UPS85LU=; b=H9R5ix4squVnm6iu7+6ymvHC6F62FcBjB2I18K/k3TZiArntKlwgTQY4mbh4O2FlCq C6/He013Ysu+AIGHbVBpKQZOAX+mHns9wsJO4spMCpkNFJvedH1/ONwKnb1n9FipxAZX eWdNgi2TFQ44i7BZOmuup13z9PM/nImhYlKqBVUqp9KeR0Rzs7pfSAc/oaEjeF6mfg/S AMI7uI7D2M4Xmo4Mqva4FmCcqZKAMI09TCYQ9O8Rdt9M2BHbUdf1DIqtQlZY3QoZvbaf 7V5GyORzWM8X4S4dwOJqtWcu26D9lAq/Ah5SJwOL3lZPad7RXhQWfIako5oDs5y53qF1 qioQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWndSm2yxqVHP8HNl/pBHa3tyeOdo/sk+XUSv5PAcTpzmvMjgp1Z+BC4to04ZzpojukmANJ7I3IG5hn@gnusha.org X-Gm-Message-State: AOJu0YwZeJmmcgEWInFupF9d6bQJfSb3+bOZC6wlGSUQK31vFjxpt7g2 xydbGCMzOz/r3CW83qVU9PzaiQKOjkjdtJVYvZsEA5z/G8SCOAkGTtgr X-Google-Smtp-Source: AGHT+IEqRr3OlWM5Ff1+0XK/NS3ibvanMJ8OO2GVIz99TT9zvkHdblgC5mJKdt4+gyKP6iidoNRMQg== X-Received: by 2002:a05:6902:200a:b0:e82:1a2d:fac8 with SMTP id 3f1490d57ef6-e860192636dmr2996430276.30.1750856734304; Wed, 25 Jun 2025 06:05:34 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZeF6dWEStrtUL+4oFJkn8GtFj6GJYiLUZgJEY0NIeapsg== Received: by 2002:a25:5144:0:b0:e82:21c7:6973 with SMTP id 3f1490d57ef6-e841d28946els5350061276.0.-pod-prod-04-us; Wed, 25 Jun 2025 06:05:30 -0700 (PDT) X-Received: by 2002:a05:690c:4a0f:b0:714:3e9:dd3 with SMTP id 00721157ae682-71406c8a47emr42176137b3.6.1750856729983; Wed, 25 Jun 2025 06:05:29 -0700 (PDT) Received: by 2002:a05:690c:f0f:b0:711:63b1:720 with SMTP id 00721157ae682-7140610f4a0ms7b3; Wed, 25 Jun 2025 05:53:15 -0700 (PDT) X-Received: by 2002:a05:690c:4b12:b0:712:d54e:2209 with SMTP id 00721157ae682-71406cb5cf9mr41652647b3.14.1750855993701; Wed, 25 Jun 2025 05:53:13 -0700 (PDT) Date: Wed, 25 Jun 2025 05:53:13 -0700 (PDT) From: waxwing/ AdamISZ To: Bitcoin Development Mailing List Message-Id: <81017721-9194-46b7-8a1d-a1ee9cd7a362n@googlegroups.com> In-Reply-To: References: <8fb3deaf-417c-4ec9-9d23-424c4926905an@googlegroups.com> Subject: Re: [bitcoindev] Re: Sybil resistance in different coinjoin implementations MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_83964_1879953836.1750855993125" X-Original-Sender: ekaggata@gmail.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 (/) ------=_Part_83964_1879953836.1750855993125 Content-Type: multipart/alternative; boundary="----=_Part_83965_993567890.1750855993125" ------=_Part_83965_993567890.1750855993125 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > While doing some research I realized that an attacker can lock 1 BTC for= =20 3 months and open a short position in quarterly futures with minimum=20 leverage to hedge locked bitcoin. In this case the only thing an attacker= =20 needs is to acquire 2 BTC. They would also earn fees from coinjoin being a= =20 maker. Indeed hedging is something to consider when analyzing cost of timelocking= =20 coins. It's not obvious what its effect is, but it certainly doesn't remove= =20 the "opportunity cost"/"sacrifice" (i.e. the cost derived from the time=20 value of money), and thus doesn't invalidate the idea of using a timelock= =20 to create a nontrivial cost to attack the system. What it does it remove=20 one aspect of cost, which comes from the volatility in the "true value"=20 (however you want to measure that, e.g. purchasing power) of the asset=20 (here, 1 BTC), but with the additional cost of locking more capital (and=20 transaction costs, and ..). But with or without hedging, the *main* aspect= =20 of cost remains: you forego the opportunity to use those funds otherwise,= =20 during the locked period; the monetary value of that opportunity cost is a= =20 lot less than the 1 BTC, of course, for only 3 months, but it is a lot=20 greater than zero. On to calculating costs: In this other part of my reply, I wrote: > Just a pure "I own a utxo" imposes no, or negligible cost. As per the=20 delving post, and in a few other places, I've noted you can impose an age= =20 and value restriction to bump up the cost. So your idea of calculating that is certainly something I considered,=20 though, how exactly one constructs the right kind of formula isn't that=20 obvious. I had something like age^a * value ^ b whereas you are looking at= =20 straight multiplication in your linked gitlab note (so I guess a=3D1, b=3D= 1)=20 (also you weight by utxo type, but I guess that's a very small delta). I=20 have no real clue for now what the correct formula is; but in any case, we= =20 agree there. > I don't agree that it costs nothing to own a UTXO with x amount, y age=20 and z type.=20 On the phrase that I used, "almost absolutely nothing" - you'll notice that= =20 the two qualifiers are .. umm .. almost absolutely contradictory. But=20 literally, they are not contradictory. My point here is that the "base=20 case" of cost for an aut-ct style token is *very* close to zero *for a user= =20 who actually holds utxos from other activities* (some mild "user" of=20 bitcoin, including "holders"). While there is a cost, it's abstract and=20 near irrelevant if you only need 1 such token every long while (or in the= =20 extreme, if you only ever needed 1 token in your life). The cost *does=20 exist* though, if the requirement for them is more like a continuous flow= =20 over time, and what matters more I think is that the cost is, in the limit,= =20 spectacularly non-linear: if I want to "attack" a system with really=20 low-level Sybilling (1 "access" to the system every 10 minutes e.g.) it=20 might be very cheap. But If I want 10k "accesses" in the next minute (which= =20 might be Sybil-to-DOS an online resource maybe) it could be very expensive= =20 or even impossible, depending on how you make the condition on utxo age and= =20 amount. I saw this as an attempt to find what I consider a kind of "holy grail" in= =20 anti-DOS measures that actually retain privacy: you want super=20 non-linearity in cost to use the system, because this gets you the property= =20 than an ordinary user's costs are not even noticeable whereas an attacker's= =20 costs are prohibitive. We saw this concept already in hashcash=20 *specifically for email spamming*. That's the thing, whether the idea is=20 helpful depends on whether attacking the system requires huge numbers of=20 usage tokens. If attacking the system only requires 10 or even 100,=20 especially for a *targeted* attack, over a period of a day or something=20 like that, then I think you have to look at things differently. Cheers, AdamISZ/waxwing On Tuesday, June 24, 2025 at 11:32:46=E2=80=AFPM UTC-3 /dev /fd0 wrote: > Hi waxwing, > > A formula to calculate the UTXO value which could used to measure the cos= t=20 > of owning a UTXO: https://gitlab.com/-/snippets/4866444 > > It is simple and uses basic properties of a UTXO however it can be=20 > improved further. *Nothingmuch *has suggested a few improvements in a=20 > private discussion. > > > > The actual problems with fidelity bonds are twofold: privacy headache= =20 > from public utxo announcement, and expense (the expense part is=20 > unintuitive, but, if a value lock is to impose cost that *specifically=20 > prevents Sybils*, it's very valuable that it be counted super-linearly in= =20 > the size of the utxo; otherwise, a high-net-worth Sybiler can split his= =20 > amount into 100 pieces e.g. to get 100 valid entry tokens.=20 > > While doing some research I realized that an attacker can lock 1 BTC for = 3=20 > months and open a short position in quarterly futures with minimum levera= ge=20 > to hedge locked bitcoin. In this case the only thing an attacker needs is= =20 > 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=20 > issue:=20 > https://github.com/JoinMarket-Org/joinmarket-clientserver/discussions/177= 3 > > > > How much does that really cost? It's reasonable to answer "almost=20 > absolutely nothing", since you don't spend those coins, and while in a=20 > vague, abstract sense they are "locked" (you need some that lasted that= =20 > long), a well funded attacker could always have that amount x10 or x100= =20 > sitting *somewhere*. > > I don't agree that it costs nothing to own a UTXO with x amount, y age an= d=20 > z type. A well funded attacker will need to own a lot of UTXOs to attack= =20 > all the pools created in joinstr by different users. This introduces a co= st=20 > for the attack. I think it works best when used in combination with=20 > 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= =20 >> few things you say in the article at the end, here, but first I want to= =20 >> discuss some background related to aut-ct (and yes this is mostly alread= y=20 >> implicit in your article but for other readers, the following): >> >> I want to expand on something I said when we were discussing this on=20 >> delving [1]: >> >> There's always in my mind two very distinct threats from Sybilling. The= =20 >> first is that your protocol might subtly (or grossly) depend on=20 >> non-collusion of participants. For that you want one kind of Sybil=20 >> resistance. >> >> The second is the problem of free-entry, which can occur even if=20 >> non-collusion is not a requirement. If anyone can join a protocol withou= t=20 >> real limits, then the resource usage implied when the number of protocol= =20 >> users increases by 1000x can screw up resource utilization. (Bitcoin its= elf=20 >> deals with this beautifully through implicit PoW dependence of messages = to=20 >> be considered valid.) >> >> My feeling when working on the idea of RIDDLE and then later aut-ct was= =20 >> that I was only really addressing or thinking about the 2nd of those two= =20 >> cases. It's not impossible to use a utxo ownership proof to address the = 1st=20 >> of the two above, but it's clearly much less strong, by default, than on= e=20 >> would hope. >> >> Just a pure "I own a utxo" imposes no, or negligible cost. As per the=20 >> delving post, and in a few other places, I've noted you can impose an ag= e=20 >> and value restriction to bump up the cost. So it's not inconceivable but= I=20 >> suspect it's troublesome, and, it tends to fall into the "anything's bet= ter=20 >> than nothing" category. While a fidelity bond with a public timeout is m= ore=20 >> convenient specifically because you don't need to have "prepared" it in= =20 >> advance, a long time (so same lockup cost, but in advance). >> >> The actual problems with fidelity bonds are twofold: privacy headache=20 >> from public utxo announcement, and expense (the expense part is=20 >> unintuitive, but, if a value lock is to impose cost that *specifically= =20 >> prevents Sybils*, it's very valuable that it be counted super-linearly i= n=20 >> the size of the utxo; otherwise, a high-net-worth Sybiler can split his= =20 >> amount into 100 pieces e.g. to get 100 valid entry tokens. Chris Belcher= =20 >> originally proposed and implemented a quadratic scaling [2], but we redu= ced=20 >> that default exponent and made it configurable, precisely because the HN= W=20 >> Sybiler (or honest participant) can nearly guarantee participation. It's= a=20 >> whole can of worms, though). >> >> So given that, it's very natural to look for alternatives to, or finesse= s=20 >> on, fidelity bond ideas. Which you do, here, so, coming to some parts of= =20 >> your article: >> >> > Since WabiSabi is a coinjoin implementation based on centralized=20 >> coordinator, a user must also trust the coordinator not to link inputs a= nd=20 >> outputs. >> >> I can see that being true only in one specific sense: that Wa(bi)Sabi=20 >> coordinators can Sybil and thus link. Obviously in the default honest mo= de=20 >> of operation of coordinator this is not true of such systems. >> >> > Joinstr uses aut-ct as the primary= =20 >> mechanism for sybil resistance, however fidelity bonds can also be used= =20 >> with aut-ct. There is an initiator who creates the pool and adds sybil= =20 >> requirements to join the pool. Everyone (maker and takers) needs to prov= ide=20 >> 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=20 >> meant that: the anon set can be the anon-set of all timelocked UTXOs (t= hat=20 >> may or may not be fidelity bond type), but if you do that then of course= =20 >> you need to form the anon set based on some time-range, I guess? The=20 >> problem I always had with this was how do we coordinate anything like th= is=20 >> for the anon set to be big enough. Like, if you did it with aut-ct it wo= uld=20 >> either have to be taproot or users publishing (where?) the pubkeys in or= der=20 >> to make the tree. People need to actually create these timelocked utxos,= so=20 >> they need somehow to be told well in advance what the realistic paramete= rs=20 >> are for it. It seems very difficult practically to coordinate and then t= o=20 >> get to decent privacy, also (in case you commit a big chunk of funds and= =20 >> then only 5 other people do it .. you were hoping 5000, now you have lit= tle=20 >> or no privacy from a big cost. Just an example) >> >> But reading further I see you were looking at it the other way; literall= y=20 >> two separate things, both fidelity bonds, and aut-ct tokens. >> >> > Everyone shares aut-ct proof that proves they own a P2TR UTXO worth=20 >> 0.1-0.2 BTC that is unspent until last block and aged more than 2016 blo= cks >> >> For me this example illustrates why Sybil-threat type 1 is not well=20 >> defended by this kind of system. How much does that really cost? It's=20 >> reasonable to answer "almost absolutely nothing", since you don't spend= =20 >> those coins, and while in a vague, abstract sense they are "locked" (you= =20 >> need some that lasted that long), a well funded attacker could always ha= ve=20 >> that amount x10 or x100 sitting *somewhere*. Handwavy, but imo it's only= if=20 >> we want to prevent 1000 of those at once that it starts to be in some se= nse=20 >> "costly". But a Sybil attack on a coinjoin does not need more than N-1= =20 >> participants to Sybil an N-party join, so 1000 is way over the line. >> >> Cheers, >> AdamISZ/waxwing >> >> [1]=20 >> https://delvingbitcoin.org/t/anonymous-usage-tokens-from-curve-trees-or-= autct/862/3 >> [2]=20 >> https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b >> >> 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,=20 >>> joinstr and wabisabi. I did not include whirlpool in this post because = its=20 >>> 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=20 >>> results show that joinmarket has good enough sybil resistance. However,= =20 >>> joinstr provides better solution. >>> >>> Feel free to share your feedback. >>> >>> Link:=20 >>> https://uncensoredtech.substack.com/p/sybil-resistance-in-coinjoin-impl= ementations >>> >>> /dev/fd0 >>> floppy disk guy >>> >> --=20 >> You received this message because you are subscribed to the Google Group= s=20 >> "Bitcoin Development Mailing List" group. >> To unsubscribe from this group and stop receiving emails from it, send a= n=20 >> email to bitcoindev+...@googlegroups.com. >> To view this discussion visit=20 >> https://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec5= 25438cc92n%40googlegroups.com=20 >> >> . >> > --=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/= 81017721-9194-46b7-8a1d-a1ee9cd7a362n%40googlegroups.com. ------=_Part_83965_993567890.1750855993125 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> 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=20 leverage to hedge locked bitcoin. In this case the only thing an=20 attacker needs is to acquire 2 BTC. They would also earn fees from=20 coinjoin being a maker.

Indeed hedging is someth= ing to consider when analyzing cost of timelocking coins. It's not obvious = what its effect is, but it certainly doesn't remove the "opportunity cost"/= "sacrifice" (i.e. the cost derived from the time value of money), and thus = doesn't invalidate the idea of using a timelock to create a nontrivial cost= to attack the system. What it does it remove one aspect of cost, which com= es from the volatility in the "true value" (however you want to measure tha= t, e.g. purchasing power) of the asset (here, 1 BTC), but with the addition= al cost of locking more capital (and transaction costs, and ..). But with o= r without hedging, the *main* aspect of cost remains: you forego the opport= unity to use those funds otherwise, during the locked period; the monetary = value of that opportunity cost is a lot less than the 1 BTC, of course, for= only 3 months, but it is a lot greater than zero.

On to calculating costs:

In this other part o= f my reply, I wrote:

> Just a pure "I own a u= txo" imposes no, or negligible cost. As per the=20 delving post, and in a few other places, I've noted you can impose an=20 age and value restriction to bump up the cost.

S= o your idea of calculating that is certainly something I considered, though= , how exactly one constructs the right kind of formula isn't that obvious. = I had something like age^a * value ^ b whereas you are looking at straight = multiplication in your linked gitlab note=C2=A0 (so I guess a=3D1, b=3D1) (= also you weight by utxo type, but I guess that's a very small delta). I hav= e no real clue for now what the correct formula is; but in any case, we agr= ee there.

> I don't agree that it costs nothi= ng to own a UTXO with x amount, y age and z type.

On the phrase that I used, "almost absolutely nothing" - you'll no= tice that the two qualifiers are .. umm .. almost absolutely contradictory.= But literally, they are not contradictory. My point here is that the "base= case" of cost for an aut-ct style token is *very* close to zero *for a use= r who actually holds utxos from other activities* (some mild "user" of bitc= oin, including "holders"). While there is a cost, it's abstract and near ir= relevant if=C2=A0 you only need 1 such token every long while (or in the ex= treme, if you only ever needed 1 token in your life). The cost *does exist*= though, if the requirement for them is more like a continuous flow over ti= me, and what matters more I think is that the cost is, in the limit, specta= cularly non-linear: if I want to "attack" a system with really low-level Sy= billing (1 "access" to the system every 10 minutes e.g.) it might be very c= heap. But If I want 10k "accesses" in the next minute (which might be Sybil= -to-DOS an online resource maybe) it could be very expensive or even imposs= ible, depending on how you make the condition on utxo age and amount.
=

I saw this as an attempt to find what I consider a ki= nd of "holy grail" in anti-DOS measures that actually retain privacy: you w= ant super non-linearity in cost to use the system, because this gets you th= e property than an ordinary user's costs are not even noticeable whereas an= attacker's costs are prohibitive. We saw this concept already in hashcash = *specifically for email spamming*. That's the thing, whether the idea is he= lpful depends on whether attacking the system requires huge numbers of usag= e tokens. If attacking the system only requires 10 or even 100, especially = for a *targeted* attack, over a period of a day or something like that, the= n I think you have to look at things differently.

Cheers,
AdamISZ/waxwing


=
On = Tuesday, June 24, 2025 at 11:32:46=E2=80=AFPM UTC-3 /dev /fd0 wrote:
Hi= waxwing,

A formula to calculate the UTXO value which co= uld 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 however it can be improv= ed further. Nothingmuch has suggested a few improvements in a privat= e discussion.


>=C2=A0The actual= problems with fidelity bonds are twofold: privacy headache from public utx= o announcement, and expense (the expense part is unintuitive, but, if a val= ue lock is to impose cost that *specifically prevents Sybils*, it's ver= y valuable that it be counted super-linearly in the size of the utxo; other= wise, a high-net-worth Sybiler can split his amount into 100 pieces e.g. to= get 100 valid entry tokens.
<= br>
While doing some research I realized that an attacker can loc= k 1 BTC for 3 months and open a short position in quarterly futures with mi= nimum leverage to hedge locked bitcoin. In this case the only thing an atta= cker needs is to acquire 2 BTC. They would also earn fees from coinjoin bei= ng a maker.

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


>=C2=A0How 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, abstra= ct 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 fun= ded attacker will need to own a lot of UTXOs to attack all the pools create= d in joinstr by different users. This introduces a cost for the attack. I t= hink 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 <ekag...@gmail.com> wrote:
Hi fd0,

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

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

There's always in my mind two very distinct threats f= rom Sybilling. The first is that your protocol might subtly (or grossly) de= pend on non-collusion of participants. For that you want one kind of Sybil = resistance.

The second is the problem of free-entr= y, which can occur even if non-collusion is not a requirement. If anyone ca= n join a protocol without real limits, then the resource usage implied when= the number of protocol users increases by 1000x can screw up resource util= ization. (Bitcoin itself deals with this beautifully through implicit PoW d= ependence of messages to 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. I= t's not impossible to use a utxo ownership proof to address the 1st of = the two above, but it's clearly much less strong, by default, than one = would hope.

Just a pure "I own a utxo" i= mposes 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 troubleso= me, and, it tends to fall into the "anything's better than nothing= " category. While a fidelity bond with a public timeout is more conven= ient specifically because you don't need to have "prepared" i= t 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 (the expense part is u= nintuitive, but, if a value lock is to impose cost that *specifically preve= nts Sybils*, it's very valuable that it be counted super-linearly in th= e size of the utxo; otherwise, a high-net-worth Sybiler can split his amoun= t into 100 pieces e.g. to get 100 valid entry tokens. Chris Belcher origina= lly proposed and implemented a quadratic scaling [2], but we reduced that d= efault exponent and made it configurable, precisely because the HNW Sybiler= (or honest participant) can nearly guarantee participation. It's a who= le can of worms, though).

So given that, it's = very natural to look for alternatives to, or finesses on, fidelity bond ide= as. Which you do, here, so, coming to some parts of your article:

> Since WabiSabi is a coinjoin implementation based on c= entralized=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, M= ay 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 it= s not used anymore. Although it won't be any different from wabisabi.

Its not a long post but written after doing a lot o= f research. The results show that joinmarket has good enough sybil resistan= ce. However, joinstr provides better solution.

Fee= l 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+...@googlegro= ups.com.
To view this discussion visit https= ://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc9= 2n%40googlegroups.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/bitcoind= ev/81017721-9194-46b7-8a1d-a1ee9cd7a362n%40googlegroups.com.
------=_Part_83965_993567890.1750855993125-- ------=_Part_83964_1879953836.1750855993125--