path: root/e4/ad3f90ef63f750f3eaf61d3ade6f85852d4c8f

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 <bitcoindev+bncBDI23FE35EIBBGXI57BAMGQEXI5K7VQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <ekaggata@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <81017721-9194-46b7-8a1d-a1ee9cd7a362n@googlegroups.com>
In-Reply-To: <CALiT-ZqKQutZSFjzKwU=RRphCbArazJqfOzgF3oMAVuc_YhGew@mail.gmail.com>
References: <8fb3deaf-417c-4ec9-9d23-424c4926905an@googlegroups.com>
 <a34c4b4a-b8af-44d3-9b8f-ec525438cc92n@googlegroups.com>
 <CALiT-ZqKQutZSFjzKwU=RRphCbArazJqfOzgF3oMAVuc_YhGew@mail.gmail.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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <ekag...@gmail.co=
m> 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 <https://github.com/AdamISZ/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
>> <https://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec=
525438cc92n%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
>> .
>>
>

--=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

<div>&gt; 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.</div><div><br /></div><div>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.</div><div><br /></div><d=
iv>On to calculating costs:</div><div><br /></div><div>In this other part o=
f my reply, I wrote:</div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>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.</div><div><br /></div><div>&gt; I don't agree that it costs nothi=
ng to own a UTXO with x amount, y age and z type. <br /></div><div><br /></=
div><div>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.</div>=
<div><br /></div><div>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.</div><div><br /></div><di=
v>Cheers,</div><div>AdamISZ/waxwing</div><div><br /></div><div><br /></div>=
<br /><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On =
Tuesday, June 24, 2025 at 11:32:46=E2=80=AFPM UTC-3 /dev /fd0 wrote:<br/></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-=
left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir=3D"ltr">Hi=
 waxwing,<div><br></div><div>A formula to calculate the UTXO value which co=
uld used to measure the cost of owning a UTXO:=C2=A0<a href=3D"https://gitl=
ab.com/-/snippets/4866444" target=3D"_blank" rel=3D"nofollow" data-saferedi=
recturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gitlab.com/-/=
snippets/4866444&amp;source=3Dgmail&amp;ust=3D1750941012069000&amp;usg=3DAO=
vVaw32YgfhjCkSPkzgdAy55hkb">https://gitlab.com/-/snippets/4866444</a><br><b=
r>It is simple and uses basic properties of a UTXO however it can be improv=
ed further. <i>Nothingmuch </i>has suggested a few improvements in a privat=
e discussion.</div></div><div dir=3D"ltr"><div><br><br>&gt;=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&#39;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. </div></div><div dir=3D"ltr"><div></div><div><=
br></div><div>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.<br><br>A few other problems associated with fidelity bonds are =
shared in this issue:=C2=A0<a href=3D"https://github.com/JoinMarket-Org/joi=
nmarket-clientserver/discussions/1773" target=3D"_blank" rel=3D"nofollow" d=
ata-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://g=
ithub.com/JoinMarket-Org/joinmarket-clientserver/discussions/1773&amp;sourc=
e=3Dgmail&amp;ust=3D1750941012069000&amp;usg=3DAOvVaw1WkslxJzTazebmP1XVeWgT=
">https://github.com/JoinMarket-Org/joinmarket-clientserver/discussions/177=
3</a></div></div><div dir=3D"ltr"><div><br><br>&gt;=C2=A0How much does that=
 really cost? It&#39;s reasonable to answer &quot;almost absolutely nothing=
&quot;, since you don&#39;t spend those coins, and while in a vague, abstra=
ct sense they are &quot;locked&quot; (you need some that lasted that long),=
 a well funded attacker could always have that amount x10 or x100 sitting *=
somewhere*.<br><br></div></div><div dir=3D"ltr"><div>I don&#39;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.</div><div>=
<br></div><div>/de/fd0</div><div>floppy disk guy</div></div><br><div class=
=3D"gmail_quote"></div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">On Sat, Jun 7, 2025 at 8:32=E2=80=AFPM waxwing/ AdamISZ &lt;<a=
 href data-email-masked rel=3D"nofollow">ekag...@gmail.com</a>&gt; wrote:<b=
r></div></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div>Hi fd0,</div><div><br></div><div>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):</div><div><br></div><div>I want to expa=
nd on something I said when we were discussing this on delving [1]:</div><d=
iv><br></div><div>There&#39;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.</div><div><br></div><div>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.)</div><div><br></div><div>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&#39;s not impossible to use a utxo ownership proof to address the 1st of =
the two above, but it&#39;s clearly much less strong, by default, than one =
would hope.</div><div><br></div><div>Just a pure &quot;I own a utxo&quot; i=
mposes no, or negligible cost. As per the delving post, and in a few other =
places, I&#39;ve noted you can impose an age and value restriction to bump =
up the cost. So it&#39;s not inconceivable but I suspect it&#39;s troubleso=
me, and, it tends to fall into the &quot;anything&#39;s better than nothing=
&quot; category. While a fidelity bond with a public timeout is more conven=
ient specifically because you don&#39;t need to have &quot;prepared&quot; i=
t in advance, a long time (so same lockup cost, but in advance).</div><div>=
<br></div><div>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&#39;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&#39;s a who=
le can of worms, though).</div><div><br></div><div>So given that, it&#39;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:</div><div=
><br></div><div>&gt; 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.</div><div><br></div><div>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.</div><div><br></div><div>&gt; <span>Joinstr uses </span=
><a href=3D"https://github.com/AdamISZ/aut-ct" rel=3D"nofollow ugc noopener=
" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Den&amp;q=3Dhttps://github.com/AdamISZ/aut-ct&amp;source=3Dgmail&amp;ust=
=3D1750941012069000&amp;usg=3DAOvVaw09Amj9GRHF8W1oU5Y9WHP4">aut-ct</a><span=
>
 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.</span></div>=
<div><span><br></span></div><div><span>Interesting idea to blend, but I am =
left considering an ambiguity:</span></div><div><span><br></span></div><div=
><span>When you say &quot;fidelity bonds can be used with aut-ct&quot; 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)</span></div><div=
><span><br></span></div><div><span>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.</span></div><div><span><br></span></div><div><span>&gt;=
 </span><span> 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</span></div><div><span><br></span></div><div><span>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&#39;s reasonable to answer=
 &quot;almost absolutely nothing&quot;, since you don&#39;t spend those coi=
ns, and while in a vague, abstract sense they are &quot;locked&quot; (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&#39;s only=
 if we want to prevent 1000 of those at once that it starts to be in some s=
ense &quot;costly&quot;. 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.</span></div><div><span><br></span></div><div><span>Cheers,</span></div=
><div><span>AdamISZ/waxwing</span></div><div><br></div><div>[1] <a href=3D"=
https://delvingbitcoin.org/t/anonymous-usage-tokens-from-curve-trees-or-aut=
ct/862/3" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https:=
//www.google.com/url?hl=3Den&amp;q=3Dhttps://delvingbitcoin.org/t/anonymous=
-usage-tokens-from-curve-trees-or-autct/862/3&amp;source=3Dgmail&amp;ust=3D=
1750941012070000&amp;usg=3DAOvVaw1jR4JfjaFAsbUynzfYHwXT">https://delvingbit=
coin.org/t/anonymous-usage-tokens-from-curve-trees-or-autct/862/3</a></div>=
<div>[2] <a href=3D"https://gist.github.com/chris-belcher/87ebbcbb639686057=
a389acb9ab3e25b" target=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gist.github.com/chris-b=
elcher/87ebbcbb639686057a389acb9ab3e25b&amp;source=3Dgmail&amp;ust=3D175094=
1012070000&amp;usg=3DAOvVaw3V9TGOCrD9saKVjB9g11aL">https://gist.github.com/=
chris-belcher/87ebbcbb639686057a389acb9ab3e25b</a></div><div><br></div><div=
 class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Tuesday, M=
ay 27, 2025 at 10:21:42=E2=80=AFPM UTC-3 /dev /fd0 wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Hi Bitcoin Developers,<div><br></=
div><div>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&#39;t be any different from wabisabi.</=
div><div><br></div><div>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.</div><div><br></div><div>Fee=
l free to share your feedback.</div><div><br></div><div>Link:=C2=A0<a href=
=3D"https://uncensoredtech.substack.com/p/sybil-resistance-in-coinjoin-impl=
ementations" rel=3D"nofollow" target=3D"_blank" data-saferedirecturl=3D"htt=
ps://www.google.com/url?hl=3Den&amp;q=3Dhttps://uncensoredtech.substack.com=
/p/sybil-resistance-in-coinjoin-implementations&amp;source=3Dgmail&amp;ust=
=3D1750941012070000&amp;usg=3DAOvVaw0JZ-NTDRXllGAIDjM689Vd">https://uncenso=
redtech.substack.com/p/sybil-resistance-in-coinjoin-implementations</a><br>=
<br>/dev/fd0<br>floppy disk guy</div></blockquote></div>

<p></p></blockquote></div><div class=3D"gmail_quote"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex">

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href data-email-masked rel=3D"nofollow">bitcoindev+...@googlegro=
ups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" rel=3D"nofollow" dat=
a-saferedirecturl=3D"https://www.google.com/url?hl=3Den&amp;q=3Dhttps://gro=
ups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%254=
0googlegroups.com?utm_medium%3Demail%26utm_source%3Dfooter&amp;source=3Dgma=
il&amp;ust=3D1750941012070000&amp;usg=3DAOvVaw1RGLj0Iewg5wJ37CFTbQoY">https=
://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc9=
2n%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/81017721-9194-46b7-8a1d-a1ee9cd7a362n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/81017721-9194-46b7-8a1d-a1ee9cd7a362n%40googlegroups.com</a>.<br />

------=_Part_83965_993567890.1750855993125--

------=_Part_83964_1879953836.1750855993125--