path: root/38/7b42d2d13446c7ac640f643bb428911a890a42

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 <bitcoindev+bncBCU2P6FJ3EBBBS575XBAMGQEDZKTAMI@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <bitcoindev@googlegroups.com>
        (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 <bitcoindev@googlegroups.com>; 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> <a34c4b4a-b8af-44d3-9b8f-ec525438cc92n@googlegroups.com>
In-Reply-To: <a34c4b4a-b8af-44d3-9b8f-ec525438cc92n@googlegroups.com>
From: "/dev /fd0" <alicexbtong@gmail.com>
Date: Wed, 25 Jun 2025 07:25:47 +0530
X-Gm-Features: AX0GCFs0htx1woMYWLLNNbKJdTwKXFGbZx4ABbobpqSZ61VsaGJy_4WzTVQbEKk
Message-ID: <CALiT-ZqKQutZSFjzKwU=RRphCbArazJqfOzgF3oMAVuc_YhGew@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Sybil resistance in different coinjoin implementations
To: "waxwing/ AdamISZ" <ekaggata@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
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: <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 (/)

--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 <ekaggata@gmail.com=
> 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 <https://github.com/AdamISZ/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
> <https://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec5=
25438cc92n%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/=
CALiT-ZqKQutZSFjzKwU%3DRRphCbArazJqfOzgF3oMAVuc_YhGew%40mail.gmail.com.

--0000000000001378cd06385bbf93
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi waxwing,<div><br></div><div>A formula to calculate the =
UTXO value which could used to measure the cost of owning a UTXO:=C2=A0<a h=
ref=3D"https://gitlab.com/-/snippets/4866444">https://gitlab.com/-/snippets=
/4866444</a><br><br>It is simple and uses basic properties of a UTXO howeve=
r it can be improved further. <i>Nothingmuch </i>has suggested a few improv=
ements in a private discussion.<br><br>&gt;=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&#39;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. </div><div><br></div><div>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.<br><br>A few other problems associated=
 with fidelity bonds are shared in this issue:=C2=A0<a href=3D"https://gith=
ub.com/JoinMarket-Org/joinmarket-clientserver/discussions/1773">https://git=
hub.com/JoinMarket-Org/joinmarket-clientserver/discussions/1773</a><br><br>=
&gt;=C2=A0How much does that really cost? It&#39;s reasonable to answer &qu=
ot;almost absolutely nothing&quot;, since you don&#39;t spend those coins, =
and while in a vague, abstract 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>I don&#39;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.</div><div><br></=
div><div>/de/fd0</div><div>floppy disk guy</div></div><br><div class=3D"gma=
il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Sa=
t, Jun 7, 2025 at 8:32=E2=80=AFPM waxwing/ AdamISZ &lt;<a href=3D"mailto:ek=
aggata@gmail.com">ekaggata@gmail.com</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid=
 rgb(204,204,204);padding-left:1ex"><div>Hi fd0,</div><div><br></div><div>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):</div><div><br></div=
><div>I want to expand on something I said when we were discussing this on =
delving [1]:</div><div><br></div><div>There&#39;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.</div><div><br></div><div>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.)</div><di=
v><br></div><div>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&#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, b=
y default, than one would hope.</div><div><br></div><div>Just a pure &quot;=
I own a utxo&quot; imposes 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 suspec=
t it&#39;s troublesome, and, it tends to fall into the &quot;anything&#39;s=
 better than nothing&quot; category. While a fidelity bond with a public ti=
meout is more convenient specifically because you don&#39;t need to have &q=
uot;prepared&quot; it 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 (t=
he expense part is unintuitive, but, if a value lock is to impose cost that=
 *specifically prevents Sybils*, it&#39;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&#39;s a whole can of worms, though).</div><div><br></div><div>So g=
iven that, it&#39;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:</div><div><br></div><div>&gt; 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.</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">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">https://delvingbitcoin.org/t/anonymous-usage-to=
kens-from-curve-trees-or-autct/862/3</a></div><div>[2] <a href=3D"https://g=
ist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b" target=3D"_b=
lank">https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25=
b</a></div><div><br></div><div class=3D"gmail_quote"><div dir=3D"auto" clas=
s=3D"gmail_attr">On Tuesday, May 27, 2025 at 10:21:42=E2=80=AFPM UTC-3 /dev=
 /fd0 wrote:<br></div><blockquote 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 whi=
rlpool in this post because its not used anymore. Although it won&#39;t be =
any different from wabisabi.</div><div><br></div><div>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=
.</div><div><br></div><div>Feel free to share your feedback.</div><div><br>=
</div><div>Link:=C2=A0<a href=3D"https://uncensoredtech.substack.com/p/sybi=
l-resistance-in-coinjoin-implementations" rel=3D"nofollow" target=3D"_blank=
">https://uncensoredtech.substack.com/p/sybil-resistance-in-coinjoin-implem=
entations</a><br><br>/dev/fd0<br>floppy disk guy</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" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.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">https://groups.googl=
e.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%40googlegrou=
ps.com</a>.<br>
</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/CALiT-ZqKQutZSFjzKwU%3DRRphCbArazJqfOzgF3oMAVuc_YhGew%40mail.gma=
il.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/=
msgid/bitcoindev/CALiT-ZqKQutZSFjzKwU%3DRRphCbArazJqfOzgF3oMAVuc_YhGew%40ma=
il.gmail.com</a>.<br />

--0000000000001378cd06385bbf93--