public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoindev] Sybil resistance in different coinjoin implementations
@ 2025-05-27 14:29 /dev /fd0
  2025-06-07 14:39 ` [bitcoindev] " waxwing/ AdamISZ
  0 siblings, 1 reply; 4+ messages in thread
From: /dev /fd0 @ 2025-05-27 14:29 UTC (permalink / raw)
  To: Bitcoin Development Mailing List


[-- Attachment #1.1: Type: text/plain, Size: 943 bytes --]

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/8fb3deaf-417c-4ec9-9d23-424c4926905an%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 1418 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

• * [bitcoindev] Re: Sybil resistance in different coinjoin implementations
    2025-05-27 14:29 [bitcoindev] Sybil resistance in different coinjoin implementations /dev /fd0
  @ 2025-06-07 14:39 ` waxwing/ AdamISZ
    2025-06-25  1:55   ` /dev /fd0
    0 siblings, 1 reply; 4+ messages in thread
  From: waxwing/ AdamISZ @ 2025-06-07 14:39 UTC (permalink / raw)
    To: Bitcoin Development Mailing List
  
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 4+ messages in thread

• • * Re: [bitcoindev] Re: Sybil resistance in different coinjoin implementations
      2025-06-07 14:39 ` [bitcoindev] " waxwing/ AdamISZ
    @ 2025-06-25  1:55   ` /dev /fd0
      2025-06-25 12:53     ` waxwing/ AdamISZ
      0 siblings, 1 reply; 4+ messages in thread
    From: /dev /fd0 @ 2025-06-25  1:55 UTC (permalink / raw)
      To: waxwing/ AdamISZ; +Cc: Bitcoin Development Mailing List
    
    [-- Attachment #1: Type: text/plain, Size: 9312 bytes --]
    
    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 PM 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 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
    > <https://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%40googlegroups.com?utm_medium=email&utm_source=footer>
    > .
    >
    
    -- 
    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/CALiT-ZqKQutZSFjzKwU%3DRRphCbArazJqfOzgF3oMAVuc_YhGew%40mail.gmail.com.
    
    [-- Attachment #2: Type: text/html, Size: 11459 bytes --]
    
    ^ permalink raw reply	[flat|nested] 4+ messages in thread

  • • * Re: [bitcoindev] Re: Sybil resistance in different coinjoin implementations
        2025-06-25  1:55   ` /dev /fd0
      @ 2025-06-25 12:53     ` waxwing/ AdamISZ
        0 siblings, 0 replies; 4+ messages in thread
      From: waxwing/ AdamISZ @ 2025-06-25 12:53 UTC (permalink / raw)
        To: Bitcoin Development Mailing List
      
      
      [-- Attachment #1.1: Type: text/plain, Size: 13635 bytes --]
      
      > 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.
      
      Indeed hedging is something 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 comes from the volatility in the "true value" 
      (however you want to measure that, e.g. purchasing power) of the asset 
      (here, 1 BTC), but with the additional cost of locking more capital (and 
      transaction costs, and ..). But with or without hedging, the *main* aspect 
      of cost remains: you forego the opportunity 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 of my reply, I wrote:
      
      > 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 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  (so I guess a=1, b=1) 
      (also you weight by utxo type, but I guess that's a very small delta). I 
      have no real clue for now what the correct formula is; but in any case, we 
      agree there.
      
      > I don't agree that it costs nothing to own a UTXO with x amount, y age 
      and z type. 
      
      On the phrase that I used, "almost absolutely nothing" - you'll notice 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 user 
      who actually holds utxos from other activities* (some mild "user" of 
      bitcoin, including "holders"). While there is a cost, it's abstract and 
      near irrelevant if  you only need 1 such token every long while (or in the 
      extreme, 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 time, and what matters more I think is that the cost is, in the limit, 
      spectacularly non-linear: if I want to "attack" a system with really 
      low-level Sybilling (1 "access" to the system every 10 minutes e.g.) it 
      might be very cheap. 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 impossible, depending on how you make the condition on utxo age and 
      amount.
      
      I saw this as an attempt to find what I consider a kind of "holy grail" in 
      anti-DOS measures that actually retain privacy: you want super 
      non-linearity in cost to use the system, because this gets you the 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 
      helpful depends on whether attacking the system requires huge numbers of 
      usage 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, then I think you have to look at things differently.
      
      Cheers,
      AdamISZ/waxwing
      
      
      
      On Tuesday, June 24, 2025 at 11:32:46 PM UTC-3 /dev /fd0 wrote:
      
      > 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 PM waxwing/ AdamISZ <ekag...@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 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+...@googlegroups•com.
      >> To view this discussion visit 
      >> https://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%40googlegroups.com 
      >> <https://groups.google.com/d/msgid/bitcoindev/a34c4b4a-b8af-44d3-9b8f-ec525438cc92n%40googlegroups.com?utm_medium=email&utm_source=footer>
      >> .
      >>
      >
      
      -- 
      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/81017721-9194-46b7-8a1d-a1ee9cd7a362n%40googlegroups.com.
      
      [-- Attachment #1.2: Type: text/html, Size: 17790 bytes --]
      
      ^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2025-06-25 13:05 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-05-27 14:29 [bitcoindev] Sybil resistance in different coinjoin implementations /dev /fd0
2025-06-07 14:39 ` [bitcoindev] " waxwing/ AdamISZ
2025-06-25  1:55   ` /dev /fd0
2025-06-25 12:53     ` waxwing/ AdamISZ

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox