From: waxwing/ AdamISZ <ekaggata@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: Sybil resistance in different coinjoin implementations
Date: Sat, 7 Jun 2025 07:39:21 -0700 (PDT) [thread overview]
Message-ID: <a34c4b4a-b8af-44d3-9b8f-ec525438cc92n@googlegroups.com> (raw)
In-Reply-To: <8fb3deaf-417c-4ec9-9d23-424c4926905an@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 6682 bytes --]
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 itself
deals with this beautifully through implicit PoW dependence 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. It's not impossible to use a utxo ownership proof to address the 1st
of the two above, but it's clearly much less strong, 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 better
than nothing" category. While a fidelity bond with a public timeout is more
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 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. 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 and
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 mode
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 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 *thought* you
meant that: the anon set can be the anon-set of all timelocked 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 guess? 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-ct it would
either have to be taproot or users publishing (where?) the pubkeys in order
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 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 have little
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 blocks
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 have
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 sense
"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-autct/862/3
[2] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b
On Tuesday, May 27, 2025 at 10:21:42 PM 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 its
> 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-implementations
>
> /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-ec525438cc92n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 8179 bytes --]
prev parent reply other threads:[~2025-06-07 15:02 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 14:29 [bitcoindev] " /dev /fd0
2025-06-07 14:39 ` waxwing/ AdamISZ [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a34c4b4a-b8af-44d3-9b8f-ec525438cc92n@googlegroups.com \
--to=ekaggata@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox