Remove the incentive for 7000 bondless bots, among only 40 bonded makers
I'd like to start/restart the discussion on fully disincentivizing bondless bots.
We have about 40 honest bonded makers in the orderbook. Everything else (7 thousand bots) is either spying, trying to game the selection algorithm or DOSing, effectively Sybil attacking JM, bringing it to a halt.
I believe these thousands of bots had caused our good will with IRC Operators to run out; and we got kicked off all three IRC servers, sadly suffering further centralization. Directory Nodes are needlessly being stressed too, and they are not forever. JM seems to be at a breaking point -- I have not seen successful coinjoins in a while.
Fidelity Bonds are 6 years old. In the initial introduction stage, when they were first created; it made sense to allow some non-bonded makers to be selected by default. Fidelity Bonds were new, untested, scary (potential loss of coin for makers). It made sense for some makers to continue running without Fidelity Bonds for a while.
Now, six years later, bond creation is easy, safe & secure and every honest maker does it.
I would like to suggest to drop the default to 0% in all taker clients.
If an entity wants to be a maker temporarily (the reason for the initial 12.5% default) -- it is quite easy & safe to set up a short duration bond, of a month or two.
Going to 0% bondless default will stop the endless flood of bots, ease up Directory Nodes operations, and allow JM to be fully functional once again.
the corresponding pull request: https://github.com/JoinMarket-Org/joinmarket-clientserver/pull/1792
Going to 0% bondless default will stop the endless flood of bots, ease up Directory Nodes operations, and allow JM to be fully functional once again.
I'm just a user, but I see this is as necessary change and will only benefit every honest participant. Keeping it as, with 1000s of bondless makers, will only get worse i fear.
Agreed, I had posted as well earlier on this issue and it looks like it has only gotten worse. When I was looking at the orderbook a few months back it was something like 2-3000 makers, which was already bad. This is just unworkable now and I agree we should go to fully bonded makers to block out what is clearly (to me) a coordinated attempt to break JM.
The impact to IRC is important as well. We don't want to be perceived as spam.
In the meantime, as a taker, find this line in your joinmarket.cfg line and set it to 0
bondless_makers_allowance = 0
cACK
So, now it doesn't matter how often you change your Tor identity and JM nick. You're easily traceable because your fidelity bond is one and the same and is easily traceable!
I'd like to start/restart the discussion on fully disincentivizing bondless bots. We have about 40 honest bonded makers in the orderbook. Everything else (7 thousand bots) is either spying, trying to game the selection algorithm or DOSing, effectively Sybil attacking JM, bringing it to a halt.
I believe these thousands of bots had caused our good will with IRC Operators to run out; and we got kicked off all three IRC servers, sadly suffering further centralization. Directory Nodes are needlessly being stressed too, and they are not forever. JM seems to be at a breaking point -- I have not seen successful coinjoins in a while. Fidelity Bonds are 6 years old. In the initial introduction stage, when they were first created; it made sense to allow some non-bonded makers to be selected by default. Fidelity Bonds were new, untested, scary (potential loss of coin for makers). It made sense for some makers to continue running without Fidelity Bonds for a while. Now, six years later, bond creation is easy, safe & secure and every honest maker does it. I would like to suggest to drop the default to 0% in all taker clients. If an entity wants to be a maker temporarily (the reason for the initial 12.5% default) -- it is quite easy & safe to set up a short duration bond, of a month or two. Going to 0% bondless default will stop the endless flood of bots, ease up Directory Nodes operations, and allow JM to be fully functional once again.
You forgot one category : Many honest bonded makers that can't get his bonds taken into account due to whatever bug in the software... I have a tried with multiple offers, made 2 bonds and my bond value in the offer sticks to 0!
I'd like to start/restart the discussion on fully disincentivizing bondless bots. We have about 40 honest bonded makers in the orderbook. Everything else (7 thousand bots) is either spying, trying to game the selection algorithm or DOSing, effectively Sybil attacking JM, bringing it to a halt.
I believe these thousands of bots had caused our good will with IRC Operators to run out; and we got kicked off all three IRC servers, sadly suffering further centralization. Directory Nodes are needlessly being stressed too, and they are not forever. JM seems to be at a breaking point -- I have not seen successful coinjoins in a while. Fidelity Bonds are 6 years old. In the initial introduction stage, when they were first created; it made sense to allow some non-bonded makers to be selected by default. Fidelity Bonds were new, untested, scary (potential loss of coin for makers). It made sense for some makers to continue running without Fidelity Bonds for a while. Now, six years later, bond creation is easy, safe & secure and every honest maker does it. I would like to suggest to drop the default to 0% in all taker clients. If an entity wants to be a maker temporarily (the reason for the initial 12.5% default) -- it is quite easy & safe to set up a short duration bond, of a month or two. Going to 0% bondless default will stop the endless flood of bots, ease up Directory Nodes operations, and allow JM to be fully functional once again.
You forgot the honest bonded makers that can't get their bonds taken into account due to whatever bug in the software... I have a tried with multiple offers, made 2 bonds and my bond value in the offer sticks to 0!
You forgot one category : Many honest bonded makers that can't get his bonds taken into account due to whatever bug in the software... I have a tried with multiple offers, made 2 bonds and my bond value in the offer sticks to 0!
Sounds the website orderbook issue and/or obwatcher.py
The maker-to-taker P2P interface always presents the bond. No problem there.
Unfortunately, fidelity bonds don't stop people from running multiple bots either. These are clearly multiple bonds ran by a single entity. They didn't even try to hide it...
Here's multiple offers utilizing a single bond.
Unfortunately, fidelity bonds don't stop people from running multiple bots either.
The original exponent in the bond value formula would have been a more effective disincentive against running multiple bots with multiple bonds, but it was watered down at some point. If I didn't know better, I might suspect a conspiracy to cripple the whole fidelity bond concept from its infancy.
Added some further context here
https://github.com/JoinMarket-Org/joinmarket-clientserver/discussions/1773#discussioncomment-14387559
Unfortunately, fidelity bonds don't stop people from running multiple bots either.
The original exponent in the bond value formula would have been a more effective disincentive against running multiple bots with multiple bonds, but it was watered down at some point.
What was it before?
Possible to change it back to the original one?
(Incentives matter)
Unfortunately, fidelity bonds don't stop people from running multiple bots either.
The original exponent in the bond value formula would have been a more effective disincentive against running multiple bots with multiple bonds, but it was watered down at some point.
What was it before? Possible to change it back to the original one? (Incentives matter)
I believe it was the square (exponent=2) if I'm reading the original paper correctly.
Unfortunately, fidelity bonds don't stop people from running multiple bots either. These are clearly multiple bonds ran by a single entity.
That may be -- the issue of how to incentivize makers to use 1 large bond instead of several small ones is better saved for another topic (has something to do with the bond formula calculation per @whitslack).
Here I claim the majority (7000) bondless offers are all fake, spy attempts, DOS attempts, directory nodes attacks, pollution, etc. -- and should be dropped. That includes the guy with the same bond for 10 different offers.
That includes the guy with the same bond for 10 different offers.
That's not necessarily disingenuous if the offers are disjoint (e.g., different fee rates for different amount ranges). Anyway, the taker code should be smart enough to select only one maker per distinct fidelity bond. (I don't know whether it is, though.)
You're absolutely right about the bondless makers, though. I would set the bondless allowance default to 0% if it were up to me. There is no excuse for not being bonded.
There is no excuse for not being bonded.
There are plenty, unfortunately. I'm not using bondless taker now. And this is not because I've no bitcoins to pledge in a fbond.
Fidelity bonds as a concept used in joinmarket is nonsense. It greatly increases the possibility of de-anonymizing takers while contributing very little to demonstrate dedication. There will be bots with or without announced fbonds trying to identify you as a person or entity. I'm not ready to propose solution but I'm quite confident that setting the bondless allowance default to 0% is not the right way forward.
There is no excuse for not being bonded.
There are plenty, unfortunately. I'm not using bondless taker now. And this is not because I've no bitcoins to pledge in a fbond.
There is no requirement for a taker to have a bond. Maker's require a bond to improve their chances to be selected by the taker.
Fidelity bonds as a concept used in joinmarket is nonsense.
If fidelity bonds were not a thing in JoinMarket, then it is cheap and easy for anyone to run multiple maker bots to improve their chances for selection by the taker. This is occurring now, has always occurred since the beginning of JoinMarket. It increases the odds of a maker's bot to be selected and is harmful to the privacy that the taker is paying for.
It greatly increases the possibility of de-anonymizing takers while contributing very little to demonstrate dedication. There will be bots with or without announced fbonds trying to identify you as a person or entity. I'm not ready to propose solution but I'm quite confident that setting the bondless allowance default to 0% is not the right way forward.
How does requiring Fidelity Bonds increase the possibility of de-anonymizing the taker? Defaulting the bondless allowance to 0% at least imposes a cost on dishonest makers who chose to run multiple bots. Those who are knowledgeable enough to understand what this setting does can easily modify it to whatever they wish if they want bondless maker's in their transaction.
How does requiring Fidelity Bonds increase the possibility of de-anonymizing the taker?
What I mean is maker, of course, not taker. Sorry for misleading you.
How does requiring Fidelity Bonds increase the possibility of de-anonymizing the taker?
What I mean is maker, of course, not taker. Sorry for misleading you.
No worries. Any UTXO that's used for a bond should be one that is already sufficiently anonymous. Otherwise, you're correct that it is very bad for maker privacy. An output that has gone through many rounds of CJ, an output from a lightning to on chain swap, or even a combination of the two would be a good solution.
Same goes for when the bond expires and is eventually spent. Actions need to be taken to ensure maker privacy is preserved. Ultimately, Bitcoin privacy is not cheap or easy to obtain. Every move must consider repercussions to privacy in advance.
That includes the guy with the same bond for 10 different offers.
That's not necessarily disingenuous if the offers are disjoint (e.g., different fee rates for different amount ranges). Anyway, the taker code should be smart enough to select only one maker per distinct fidelity bond. (I don't know whether it is, though.)
You're absolutely right about the bondless makers, though. I would set the bondless allowance default to 0% if it were up to me. There is no excuse for not being bonded.
This person is doing it for no other reason than thinking they are gaming the system. In reality, it bloats the orderbook. The code isn't designed to support multiple offers for different amount ranges using the same wallet. Doing so for this purpose leads to address reuse.
Unfortunately, fidelity bonds don't stop people from running multiple bots either.
The original exponent in the bond value formula would have been a more effective disincentive against running multiple bots with multiple bonds, but it was watered down at some point.
What was it before? Possible to change it back to the original one? (Incentives matter)
I believe it was the square (exponent=2) if I'm reading the original paper correctly.
Good idea. I have created a new pull request #1798 to restore the default setting to Chris Belcher's original bond value exponent of 2.
See #1247. It's kinda a lot but it would probably help to read that whole thread. I'm a bit surprised that this thread doesn't reference that (including Chris Belcher and others agreeing with it!) nor the PR #1253 (although I can see there were other, later threads on this, but those two were the actual change).
There was a perception, in that thread, of it being a temporary change, which is clearly relevant to the proposal here (i.e. it supports it). There was also a discussion of the "rug pull" problem - the difficulty we face in changing (although let's not forget only default) settings in the config file because it can affect the economic calculus on bonds that people already committed money to. Well, blah, blah, all the various points were already discussed there, in the open, and not in a "conspiracy" (sigh).
For myself I don't have a strong opinion about exponents (above 1.0 ofc) being 1.3 or 2.0 etc, except to say: (and repeating from the earlier thread), 2.0 meaning a 10 btc has 100x more chance than a 1 btc, combined with a natural Pareto-ish wealth distribution, seems rather extreme.
Here's a scenario which I think illustrates it well:
Imagine there are 4 makers with 10btc, old bonds and 40 makers with 1 btc, not so old bonds. If you start doing 20 coinjoins with 6 participants (e.g.) you'll probably find that every join uses those 4 makers, which at least should be a cause of concern.
This effect is of course in tension with the other extreme: a 1.01 or 1.0 multiple means the 4 10btc guys can split themselves into 10x 1.0 btc guys, but then with 40 others (let's say they're all similar age FBs), they will still be "over represented" in a series of 20 6 party coinjoins, but not as much; they're now 50%, on average (40/80), of all the coinjoins, not 50-70% ish.
The TLDR, at least the way I saw it, is exponent compounds with a natural wealth distribution, so what seems like a "normal" high exponent can lead to an extreme concentration in maker selection.
Isn't the right way to analyze this to ask ourselves: can a maker with 10 BTC earn more in CoinJoin commissions with a single 10-BTC bond or with ten 1-BTC bonds? The exponent should be set to the break-even point.
Isn't the right way to analyze this to ask ourselves: can a maker with 10 BTC earn more in CoinJoin commissions with a single 10-BTC bond or with ten 1-BTC bonds? The exponent should be set to the break-even point.
I would think we want to discourage the ten separate maker scenario so a healthy incentive should be provided towards having a single maker and single bond.
The TLDR, at least the way I saw it, is exponent compounds with a natural wealth distribution, so what seems like a "normal" high exponent can lead to an extreme concentration in maker selection.
Right, but there are still multiple makers controlled by different folks with the normal 2.0 exponent, with the potential for more equitable scenarios moving forward. Right now what we're seeing is extreme and arguably worse, which is looking like one party with the knowledge and sophistication to create and control hundreds of makers. This is an unfair advantage, and isn't something that regular users know how to do.
With reverting back to the original exponent, we disincentivize this scenario, and there are no artificial barriers for new unique users to spin up makers and be part of the maker pool, diluting any advantage other makers have. Right now to offset the advantage of this party creating hundreds of makers, others maker would need to do the same thing, which is requiring special knowledge, and worse, creating spam.
Isn't the right way to analyze this to ask ourselves: can a maker with 10 BTC earn more in CoinJoin commissions with a single 10-BTC bond or with ten 1-BTC bonds? The exponent should be set to the break-even point.
I would think we want to discourage the ten separate maker scenario so a healthy incentive should be provided towards having a single maker and single bond.
At break-even, it is true that there would be no monetary disincentive against running multiple bots, but there would be an operational disincentive. I would think it's pain in the ass to manage multiple maker bots, only worth doing if it yields an economic advantage. If someone can make the same rate of return with a single bot as they can with two (or twenty or two hundred), then they're just going to run the single bot.
Then again, there's an entirely orthogonal analysis concerning makers whose motive isn't to generate yield but rather to disrupt the effectiveness of JoinMarket and to deänonymize its participants. At break-even, they can be effective with a horde of maker bots, but with high exponents it's more likely that they won't be selected at all, as pointed out by @AdamISZ:
Imagine there are 4 makers with 10btc, old bonds and 40 makers with 1 btc, not so old bonds. If you start doing 20 coinjoins with 6 participants (e.g.) you'll probably find that every join uses those 4 makers, which at least should be a cause of concern.
If the 4 makers are real and the 40 makers are an actor intent on deänonymizing JoinMarket, then I have zero concerns about using the 4 makers in every join and utterly ignoring the 40 Sybils.
I'm not sure how effective changing the exponent value would even be. The average JoinMarket maker with say, a few thousand dollars worth of BTC to commit to a bond should already have enough incentive to create one big bond rather than many small ones if they want to maximize how often they are picked.
The average user isn't the issue. It's the massive imbalance of whales vs the average user. If a whale has enough BTC to easily create the top 5-10 bonds, they are going to have much better profit potential by doing that vs creating a single, super large bond. With a single bond, they can fill at most 1 slot in the taker's coin join. Ideally that's how it should be. However, with multiple large bonds they can fill multiple slots, maximizing profit potential.
From the looks of the orders and fees, it appears that profit is what they are after vs attempting to sybil. Sybil is just the unfortunate side effect. They are very expensive with their fee settings, the opposite of what I would think an attempt to sybil would do.
I don't see a reliable way to fix the incentive in a way that preserves maker privacy. It's up to the taker to really analyze the orders and make a educated selection of who they decide to mix with.
From the looks of the orders and fees, it appears that profit is what they are after vs attempting to sybil. Sybil is just the unfortunate side effect. They are very expensive with their fee settings, the opposite of what I would think an attempt to sybil would do.
Taking the exponent back to 2.0 would give makers (those with a single large bond) higher weight/probability in the selection algorithm.
Since whales are after profit, the opposite of Sybil attacks -- that's exactly the behavior I'd want to incentivize!
Isn't the right way to analyze this to ask ourselves: can a maker with 10 BTC earn more in CoinJoin commissions with a single 10-BTC bond or with ten 1-BTC bonds? The exponent should be set to the break-even point.
I half agree and half disagree. The agree part is: yes, after writing that post I had the same feeling: there should be a mathematical formula that finds some kind of optimum. The disagree is about thinking of it from the point of view of earnings incentive; I think you should start from "what does the customer want?" which here is to prevent a successful Sybil attack, and then other stuff should be secondary/in support of that goal. But, that "disagreement" has a finesse as per the following:
So I spent some time today trying to formulate what we actually want and came up with a surprising result. Frame it as:
Posit an attacker with C coins whose goal is to be chosen N times, where (reasonably) we assume he knows the value of N that is needed to fully Sybil one coinjoin. Suppose for simplicity the rest of the order book has C coins also, consisting of C honest makers with 1 coin each (we can generalize later). Ignore coin age for now; we assume the taker has a (coin amount)^x choosing function. The attacker we assume is free to split his C coins into arbitrary sizes, ignoring any practical limits. The question becomes: what value of x (the exponent) minimizes the maximum probability P_success that the attacker can obtain?
I believe the answer is actually x=1, surprisingly.
Go back to Chris Belcher's original gist on the topic, specifically the section "Cost of Sybil attacks" which has a concrete, though very simple example: 2 honest makers and 2 attacker bots. He calculates a 76% chance of success with x=2, for those numbers, which I agree with. But with x=1 and the same coins (20 attacker coins and 6.4 honest maker coins) you cannot do better than a 57% attack success probability, no matter how you split up the coins (into 1 offer, 10 offers or 100 offers). Split into 4 chunks, you should get 53%. For 12 chunks, you should get 56%. I checked most of this with a calculator :)
If I'm right about that, it comes back to the "finesse" point I mentioned above: as per Chris' gist, the motivation here is that the exponents > 1 create the concentrating incentive; Chris's point in that section was that the Sybiller had to sacrifice a huge amount of value to get a success prob. still significantly less than 100% [1]. But that doc (and all the subsequent discussion that I recall) doesn't identify the very important point that high exponents do not actually help prevent Sybil attacks directly, in fact they are quite suboptimal for that, since ceteris paribus they increase, rather than reduce, the probability of Sybil attack success with the same coin resources.[2] But on the other hand indirectly they make such attacks less likely because they are more costly in terms of lost income.
You can quite reasonably argue that some of my simplifying assumptions affect this overall result, but I'm not at all sure that's true. Most importantly, I assumed that all the honest makers were at coin value = 1, and allowed the attacker to be arbitrarily large. Perhaps there is a more general model that could be written down easily. But I tend to think, from what I've seen, than "an x > 1 makes Sybil attack success probability more likely" is a good general heuristic; concentration effect allows bumping Sybil success probability, generally. (btw x < 1 is also bad, because it allows success by arbitrarily small splitting, but ... no one would propose that!).
I realize that a lot of people's gut-check will be that this is wrong, but bear in mind: when you see 50 Sybils swamping an orderbook, say: we're not discussing here network-level DOS, nor DOS of makers by random fake offers, we're discussing specifically what is seen algorithmically by a taker wanting to choose N distinct parties, using an FB-based choice algorithm. The Sybiller wants to be specifically those N.
[1] Let me unpack that as a side note, to avoid getting too lost: the incentive to concentrate to get more income is stronger with higher exponents, because (a+b)^x > a^x + b^x, basically. If you had 20 coins you'd get 400 FB value vs 100+100 FB value with a split into (10,10), which in the long term should give double the income. If the exponent x were 4 instead of 2, that'd be 160K vs 10K+10K, so 8 times the income. etc. But let's not forget that when we speak of "sacrificed value" here it's quite abstract: it's assuming the economic value implied by an FB calculation only used in joinmarket, which is not the same thing as "time value of money lockup" in the CLTV utxo; I've explicitly excluded that here, and that is of course not affected by exponent, it's affected by actual coin value, and time.
[2] To be clear, according to my framing of a "Sybil attack sucess", it is not even possible unless you split into at least N chunks, but I don't think that affects the conclusion.
Taking the exponent back to 2.0 would give makers (those with a single large bond) higher weight/probability in the selection algorithm. Since whales are after profit, the opposite of Sybil attacks -- that's exactly the behavior I'd want to incentivize!
The exponent does play a big factor for the average pleb and incentivizes them to have a single, large bond. That much is good. But it doesn't change the incentive for a profit motivated whale to create multiple of the largest bonds in the book.
A maker who controls the top 3 largest bonds will participate in more joins than a maker who controls the single largest bond. I don't see how increasing the exponent changes that.
I believe these thousands of bots had caused our good will with IRC Operators to run out; and we got kicked off all three IRC servers, sadly suffering further centralization. Directory Nodes are needlessly being stressed too, and they are not forever. JM seems to be at a breaking point -- I have not seen successful coinjoins in a while. Fidelity Bonds are 6 years old. In the initial introduction stage, when they were first created; it made sense to allow some non-bonded makers to be selected by default. Fidelity Bonds were new, untested, scary (potential loss of coin for makers). It made sense for some makers to continue running without Fidelity Bonds for a while. Now, six years later, bond creation is easy, safe & secure and every honest maker does it. I would like to suggest to drop the default to 0% in all taker clients. If an entity wants to be a maker temporarily (the reason for the initial 12.5% default) -- it is quite easy & safe to set up a short duration bond, of a month or two. Going to 0% bondless default will stop the endless flood of bots, ease up Directory Nodes operations, and allow JM to be fully functional once again.