Are fidelity bonds unattainable for plebs? Is the offer book large enough?

[m0wer]

Currently there are around 2,000 offers on the order book. At first this sounds good, but if we only consider offers with a fidelity bond, the number drops to less than 100. But from those hundred, the top 6 have 90% of the total weight in terms of bond value.

This is crazy, these must be involved in almost all coinjoins!

I've discovered this while investigating what would make a good bond value, with the intention of becoming a maker and at least getting some coinjoins for free. I've developed a tool to calculate the chances of being chosen depending on the bond size and time. And I've discovered that even with 10M sats locked up for a year, the probability of being chosen as one of the 7 makers with a bond is 0.0006%, even lower than the probability of being the "bondless" peer of ~1/2000 (0.0138%).

This basically happens because the top offer has the mouthwatering amount of 141 ₿ locked for more than a year. And it really disincentivizes plebs from submitting fidelity bonds. Why would someone lock 10M sats when the chances of being picked would be higher with those 10M sats just sitting in a secondary instance looking to be picked as the "bondless" peer?

Additionally, it's concerning that for a 10M sats coinjoin there are only ~40 makers with bonds. That does not feel like a large enough "anonymity pool."

Feel free to correct me and to play with my instance of the orderbook and the simulator that I've created for this research.

Happy coinjoining!

Edit: strike-through old simulator URL -> new simulator

[PulpCattel]

Thanks for working on this. Have you seen https://github.com/PulpCattel/jm-scripts#jmsim? I would recommend open sourcing the code for your tool if you haven't already, otherwise it's hard to recommend and use it.

From just a quick look I'm curious about a few things.

• How did you calculate the bond value? Why sats²?
• In How Selection Works you say Random Selection: One maker is randomly chosen among all makers (1/n chance, where n is the number of makers), and The remaining makers (n-1) are chosen proportionally to their fidelity bond values. Why is that? n is not the number of makers. By default, we have bondless_makers_allowance=0.125, which means 1 in every 8 makers on average will be bondless, independently of how many makers you select in your conjoin.
• The probabilities drop the more participants you select, but it should be opposite. More makers means you have more chance to be one of them.

[m0wer]

Super cool script... Wish I found it earlier. I can rewrite the tool based on it, but I want to keep it web based and only client side for ease of use and privacy.

See view-source:https://joinmarket.sgn.space/simulator.html L328 for the details on the formula used. Basically the one from joinmarket client with the exponent 1.3 and interest rate 1.5%.

Sats² is not really correct, should be sats^1.3. Maybe we can just call it sats or remove the unit.

For the random selection I've used the approximation of a fixed bondless maker, this can be improved as well.

For the probabilities, I think I'm missing multiplying the probability of being chosen by bond times the number of participants. So currently it's probably one order of magnitude lower than it should and decreases with the number.

I will improve the code based on your script for better accuracy and ping here. But for the time being, I think the point of fidelity bonds being unattainable by plebs still holds true. And also the concern about a few large players getting all offers.

What do you think about that? Those conclusions with more accurate numbers could be drawn from your script already.

Thanks for your reply!

[m0wer]

These are the results from your script:

$ python jmsim.py orderbook.json -n 10 -t 100 -s 1000 -b 0.125 -a 1000000 -f 3000,0.2 -j 16 -v
04/01/2025 10:18:02 INFO: Filtering by CoinJoin amount
04/01/2025 10:18:02 INFO: Filtered 48 offers
04/01/2025 10:18:02 INFO: Filtering by max fee
04/01/2025 10:18:02 INFO: Filtered 1442 offers
04/01/2025 10:18:02 INFO: Removing duplicates
04/01/2025 10:18:02 INFO: Removed 0 offers
04/01/2025 10:18:02 INFO: Running simulation for 100 trials (1000 CoinJoin each)...
04/01/2025 10:18:05 INFO: Simulation completed in 2.67s
04/01/2025 10:18:05 INFO: Estimated picking chances (95% confidence):
NICK (BOND VALUE)

J52dcjVKrxUxBEDE (0.0000234706061844): 99.412% +/- 0.506%
J59e9MCV3WjFZpe7 (0.0000153961079604): 98.198% +/- 0.873%
J5CbnAvtQzbUmB1Z (0.0000124092526076): 97.036% +/- 1.077%
J5Aujw3ShREYiiou (0.0000097986384414): 95.192% +/- 1.178%
J59ZQ7MgvTrkoGJs (0.0000096895168245): 94.918% +/- 1.328%
J55R2dpkeKJMwghg (0.0000092604461962): 94.594% +/- 1.436%
J52YVTFHUG31v4DR (0.0000052877962973): 86.123% +/- 1.997%
J597C6TEGuu8wGVL (0.0000034399835598): 75.793% +/- 2.848%
J56dMBm8AjyMkD4D (0.0000010033367684): 36.575% +/- 3.207%
J5MoppMr7D3uUhSO (0.0000009820312020): 35.728% +/- 3.111%
J57FCFtTVuqAqCjJ (0.0000007261045256): 27.595% +/- 2.740%
J5CQncefAPQkKXAT (0.0000006274673341): 24.403% +/- 2.641%
J5FEzRbMKJ4uW22Q (0.0000000899494950): 4.035% +/- 1.233%
J54wg3mHjwUFRZ3b (0.0000000622062538): 2.820% +/- 0.965%
J5ArCycf716X5mRj (0.0000000515322088): 2.324% +/- 0.852%
J5EAtmdadVVzhRxx (0.0000000231912852): 1.221% +/- 0.681%
J5BHio7mArfKdfx1 (0.0000000154799523): 0.872% +/- 0.524%
J59RD4wFN7zUhZTf (0.0000000059543365): 0.464% +/- 0.442%
J52pd74yR1siiHzo (0.0000000042810234): 0.439% +/- 0.416%
J579iroY5hjuNgg3 (0.0000000022459819): 0.344% +/- 0.368%
J5B48SSMgagaD28k (0.0000000016861493): 0.279% +/- 0.306%
J5EzQUAuHMLwYiJD (0.0000000015461648): 0.266% +/- 0.330%
J5DKR7bZo3Zthsrj (0.0000000014225219): 0.275% +/- 0.332%
J5LHfXavbZa3voEO (0.0000000012242268): 0.308% +/- 0.344%
J5JwPKFaJjiCq8qO (0.0000000005849829): 0.291% +/- 0.330%
J52kvJAYSkXYizBn (0.0000000005792260): 0.251% +/- 0.278%
J5CKcvw1CvkyUC75 (0.0000000005190521): 0.269% +/- 0.320%
J53tJLJziEsiRLVu (0.0000000004873876): 0.260% +/- 0.332%
J5EKxA3NFMfZfjHu (0.0000000004680034): 0.247% +/- 0.295%
J5EGXczUbqbddXa8 (0.0000000004452353): 0.246% +/- 0.304%
J52QaWZNX8nZmSdb (0.0000000003397379): 0.253% +/- 0.335%
J5ASkXm2A6tDwPNo (0.0000000001822102): 0.241% +/- 0.251%
J58QG1bjsymnGf1X (0.0000000001809965): 0.220% +/- 0.311%
J5A1qo66N1JAntdf (0.0000000001140397): 0.248% +/- 0.285%
J56qKvkhB4BrCnHY (0.0000000000717578): 0.238% +/- 0.293%
J5F47ivr4ZMukhrY (0.0000000000465290): 0.205% +/- 0.295%
J5EyQRvPcVdT8R9i (0.0000000000423639): 0.215% +/- 0.306%
J544xnPJCnKn4jwb (0.0000000000070092): 0.234% +/- 0.270%
J5DbXdviQsNhKAAZ (0.0000000000061220): 0.236% +/- 0.301%
J59JwF4Z6AuS6WYh (0.0000000000045768): 0.237% +/- 0.265%
J52x9gcHEwgqvnQw (0.0000000000007710): 0.203% +/- 0.259%
J53VYitzj11hpCRk (0.0000000000001486): 0.246% +/- 0.334%
J538TLC4o5ZnG82z (0.0000000000001132): 0.220% +/- 0.306%
J59s16YRwUv9SMBM (0.0000000000000000): 0.237% +/- 0.302%
J57NXwXxA3ZP5Etu (0.0000000000000000): 0.225% +/- 0.303%
J5BJm2qKs2SeMh2N (0.0000000000000000): 0.227% +/- 0.287%
J53x6se93aoiehxe (0.0000000000000000): 0.214% +/- 0.287%
J55Xxkjet2oFLjCu (0.0000000000000000): 0.225% +/- 0.262%
J5A3VMBFaK2QRCdx (0.0000000000000000): 0.209% +/- 0.291%

As an example here, the first offer with a bond that has significant more chances to be chosen is J579iroY5hjuNgg3 who locked up 25M sats for 14 months. But only to get ~0.3% chance of being chosen instead of the “baseline” ~0.22%. Woulnd't that guy have been better off by putting those 25M into another instance? (0.22%+0.22%>0.3%)

Is this desirable?

[PulpCattel]

See view-source:https://joinmarket.sgn.space/simulator.html L328 for the details on the formula used.

I was thinking of a github repo or something like that. If it's a standalone HTML file (but I see that it needs to download the orderbook.json file from your server), maybe it could work well with github pages?

For the probabilities, I think I'm missing multiplying the probability of being chosen by bond times the number of participants.

Here there's a simple visualization of the selection process: https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybil-attacks I think an important part is that for each CoinJoin as makers are selected they are removed from the next "draw". So the probability of being chosen changes at each selection "round".

I think the point of fidelity bonds being unattainable by plebs still holds true. And also the concern about a few large players getting all offers.

This topic comes around often. See for example: #1247, but you can find many others (often feedbacks on this are contradicting, some people would prefer even stronger defaults, say exponent 2 instead of 1.3 for example.) I think almost everyone agrees fidelity bonds are a suboptimal mitigation but better than nothing (as you can see, most of the 2k offers without bond are probably malicious in some way. If the top dogs in the orderbook want to spy, at least we know for sure they have to lock hundreds of btc to do so).

Woulnd't that guy have been better off by putting those 25M into another instance? (0.22%+0.22%>0.3%)

Possibly, but there are a lot of things to consider. Some that come to my mind:

• The technical complexity of running a second instance, and it gets worse and worse if you want a third, a forth, etc.
• The dynamic nature of the orderbook. E.g., The big bonds might disappear tomorrow, and now your bond might be worth a lot more.
• A single simulation represents a single scenario, while the whole picture is made of multiple different amounts, number of participants, fees, taker settings, etc. So, even if the makers remain the same, we have to take all the different scenarios into account.

[m0wer]

Is there any better option to Fidelity bonds?

[m0wer]

I've improved a lot the web app basing it on your script. It's now available under GitHub pages built from the verifiable code repo! Thanks a lot for your suggestions.

It's available at https://m0wer.github.io/joinmarket-fidelity-bond-simulator/ and this is the repo: https://github.com/m0wer/joinmarket-fidelity-bond-simulator

[PulpCattel]

Nice! I'll try to have a deeper look.

BTW, if you or others want to work on this, I'd be in favor of adding this kind of functionality to JM itself (maybe in the ob-watche.py script). Of course, that's a lot more work.

[m0wer]

Do you think it's worth it? I'm pretty new to the order book but it feels like it's pretty stable. Meaning that in general makers only need to make the decision once about the fidelity bond and fees and forget about it.

I'm also curious on the rationale behind the chosen fee amounts and fee types (absolute or relative). From my point of view I don't care about the amount, just want enough sats to consolidate after if needed (so an absolute fee). But I guess this is another subject and there's something I must be missing since most offers have relative fees.

Looks like the fee selection might be more relevant and dynamic than the fidelity bond itself.

What do you think?

[PulpCattel]

Do you think it's worth it?

IMHO is definitely worth it. Fidelity bonds are probably the single most important decision a maker has to take. Fidelity bonds are also the main defense against sybil attack, so takers would certainly benefit from knowing who they are picking based on their settings. The code for this is unlikely to change, so I'd expect almost no maintenance burden (it can also reuse code from the bond-calculator.py script). Fidelity bonds are also pretty much a JM-only thing, so I think it makes sense to have related tooling in this repo.

I'm pretty new to the order book but it feels like it's pretty stable. Meaning that in general makers only need to make the decision once about the fidelity bond and fees and forget about it.

No, I'd say it's not really stable at all, and it would be even less stable with more users. I also don't think it's true that makers have to make this decision once. This is a market and if they want to be competitive they should keep an eye on what's happening. Fees can be changed with a simple restart, so they are less of a problem, but a bond is committing and I'd personally prefer to know exactly what I'm getting in return for locking my sats.

I'm also curious on the rationale behind the chosen fee amounts and fee types (absolute or relative). From my point of view I don't care about the amount, just want enough sats to consolidate after if needed (so an absolute fee). But I guess this is another subject and there's something I must be missing since most offers have relative fees.

Well, some people run JM to make money, that's the whole premise of the system. If you are locking 100btc in a bond I don't think you'd mind to get something in return other than privacy. Relative fees work very well with big CJ amount.
Other people just want privacy and are okay with free CJs instead of direct profit.

Looks like the fee selection might be more relevant and dynamic than the fidelity bond itself.

It's certainly more dynamic, since you can simply change your fees and restart. The impact they have is for sure smaller than your fidelity bond. You can set your fees to 0 and you would get nothing like a decent bond would give you.

[cookcut]

Lets talk about the hundreds of spam offers with no fidelity bonds. They look like they're engineered by the same team or person to collude in as many coinjoins as possible and sniff out information. We should reduce this attack by requiring more makers with fidelity bonds. The default should probably be changed to 5% from 12.5% currently.

This should also encourages legit makers to add fidelity bonds. The next likely step for the attacker is to tack on customary fidelity bonds onto their hundreds of makers so that they can be part of the coinjoins again. We'll need to have a way to make this futile.