Potential update to fidelity bond settings #1247
Comments
Sorry please ignore my earlier (deleted) comment, I misread this sentence. Yes, that's true. We also need people to upgrade their config for new onion channels, so it will be put in big bold letters for this release :) |
Strongly agree with this, was thinking about proposing this myself. If we look at the current orderbook, most of the makers don't have fidelity bonds currently, so too small value can actually decrease privacy, as total anonset of counterparties one is mixing with is with high probability actually reduced. |
|
I agree with the sentiment, and personally I have no problem with the changes. I think though that the main focus should be helping fidelity bond adoption, rather than making non-FB offers more attractive/picked (in this case is dramatically asymmetric, this change is not even one full line of code, helping FB adoption is hard and slow). Fidelity bonds are quite a significant burden for users (duh!), and there are already a few things in the making / foreseeable that should help with that:
The main downsides I can see of lowering
|
Well there is one line of code that has to change - the squaring as per above. But technically the others are also lines of code, as they are default config vals :) Your two bullet points are valid, especially the second one, but: I see our task as principally to try to ensure takers get some version of the service they're paying for, it's not about conceding something to makers, and I think the status quo is not good for takers who get too much repetition (in particular because of the high exponent .. at least it seems that way).
I think that's a very good point too, but that could reasonably take a very long time to get agreement and adoption, so if that's a reason makers are not going ahead, all the more reason to make this temporary change, for now. Also one last thing on:
Agree but I think precisely the fact that the squaring, given wealth distribution, results in such a huge disparity between small and large bonds, is putting off adoption. |
|
Fairly new to JM. Normie user. Not technical. Recently created my first FB not long ago. Think we could get more FB if there was more of a push to use JM. Maybe some dumb down explanations on how they work and why you would want to use them. I hope the web gui gets more users on board. Most people I try to on-board are used to SW/whirlpool. Scared to try CLI of JM. |
Ahah you are right ofc, I was thinking that if we put the changes in line, they do not even reach 80 characters :) Edited. Agreed with the rest, they all seem valid arguments. |
|
I do agree with @AdamISZ proposition . As long as the number of FB has not been very large, it concentrates too much coinjoins among those makers. If that concentration is too big, I was wondering if it makes even easier for bad actors to deanonymize CJ. Ideally if user base of JM was higher, FB would not even be necessary and I do think that the idea of implementing FB was a brilliant way to try to mitigate Sybil attacks but at the end, solutions like joininbox, joinmakert-web-ui it is what will help to increase user base. So for now this solution seems a good compromise, it gives an advantage for users with FB but not as big as it was. |
While it's true that a bigger maker user base increases the cost of a sybil attack (it's also mentioned in the fidelity bond design), I don't think FBs (or equivalent mitigation to the sybil problem) ever stop to be necessary to some degree. There is also to consider that we cannot know if a "higher user base" is actually a higher user base, it might be sybils all along. We see this with, e.g., the Tor network (which has a few thousand relays, far more than the makers JM has ever had in the orderbook), that spinning up tons of relays to make up for a significant chunk of the network is not at all hard (relatively speaking). The two projects are of course quite different, but the point is that the raw number of participants is not necessarily a sufficient defense, even more that with JM the sybil attacker gets paid to sybil and can reuse the same bitcoin in virtually infinite offers. A sybil attack is hard to pull off and mantain; multiple sybils harm each other, there is a lot of room for noise by even a few honest participants, it still does not remove the privacy benefit against everybody else, etc. so it's not as bad as it sounds, but I don't think we should ever reduce the defense against it, nor stop adding new one, based on number of makers. |
|
For now DEFAULT_BONDLESS_MAKERS_ALLOWANCE: 0.125 gives a lot of chances and "push" you to use FB, however get a high FB value which "guarantees" many CJ isn't that easy, so makers with low-medium value bonds won't get many CJ but it will always be better than not having FB because of the actual allowance. Would it make sense to just make FB mandatory? Like if you want to be a maker you must have a FB and a prefixed locktime or various possibilities, like for example 3 or 6 months and a fixed/predifined amount (like 0.2BTC, just said it as example). That would make all makers have the same bond value. It could increase the amount of bad actors to run multiple makers (it would still give some protection since their funds would be lock for a period of time) but it would also make the possibility to have more honest participants, reducing the concentration of joins amongst a small group (which I think is the main problem), and as @PulpCattel pointed out, there is a lot of room for noise by even few honest participants |
No. That's a very important point which we should perhaps communicate more clearly. The algorithm does this: joinmarket-clientserver/jmclient/jmclient/support.py Lines 223 to 231 in 199b571 Notice:
|
|
Choosing the values to determine the probability of choosing a maker according to its fidelity bond is a difficult problem because we are faced with a contradiction: to maximise the anonymity set, a maker must be chosen without favouring one more than others, but those with a large fidelity bond must still be favoured in order to ensure that a maker is not a sybil, at least in proportion to the amount locked, in order to guarantee that a fidelity bond reduces the sybils. Fidelity bonds are therefore a kind of "proof of stake" but with even more centralisation because we also want to favour makers who pool their funds in a single account. It seems to me very appropriate to replace the square by a power of 1.3, but there will always be a problem of natural concentration of funds, which will result in an effective reduction in the anonymity set because the makers chosen will always be the same with high probabilities. This is also why I find it appropriate to choose more makers regardless of the fidelity bond, but then the interest of the fidelity bond is reduced. I have been thinking about how to solve this problem. Unfortunately I don't think the long term solution is to change the value of the scoring parameters. In the short term, I would consider changing the value of the interest rate given to locked-in funds. I would increase it so that those who can't make fidelity bonds with lots of BTC can compensate by locking up their funds a little longer, the problem then being that those with lots of BTC to lock up can also lock up funds longer in response to keep monopolising coinjoins. At the moment, the median value of a FB is 1 BTC and the max around 100. So the one who has blocked all 100 BTC has 100*100=10,000 times more chance of being chosen each time compared to the median maker (for a blocking duration of 1 year), passing the square to 1.3 makes it 400 times. In my opinion the problem of reducing the anonymity set will therefore persist even if we change this parameter to 1.3, there is no good solution anyway: at best we set it very close to 1 and the biggest fidelity bond always has 100 times more chance of being chosen, which is still enormous compared to the number of orders in the orderbook (450, almost 400 of them without FB). The median maker with 1 BTC to lock in has to do it 666 years longer than the one with 100 BTC to have a fidelity bond that allows him to be selected about as many times as the biggest one with an interest rate of 0.15% (in the approximation where r is the inverse of the number of year until the fidelity bond is equal the burn value). So I would increase this value but I am not sure how much without breaking something.... The solution for the long term is in my opinion not to choose independently and identically the makers at each coinjoin. I think for example that the taker can choose to select only makers who have locked up enough BTCs (we can use the square function to encourage makers to gather funds in a single account, so for a coinjoin of 2 BTC you should have a fidelity bond of sqrt(2) to be selected or something like this), this avoids the taker ending up with makers who only handle small amounts who would be tempted to consolidate their UTXO and reduce anonymity. I also think that the taker should remember which maker he chose before and decrease the probability of reselecting him later. The chances of a maker being reselected would then increase over time at a rate related to the time he locked up his funds in the fidelity bond (faster if funds are locked longer). This is obviously not for the next release because it is a totally differen way of choosing maker, but at least it doesn't change anything about the funds already locked, it is just about how a taker selects a maker given the same information. TLDR: This is really complicated.... but maybe we should change the interest rate too ? |
I don't see a contradiction, just a tension of two things in opposite direction. The first half of what you say there isn't true, it's fine to favour some makers over others based on any number of criteria. It's just not fine to 'turn the dial up to 100' on that.
So on interest rate, which is one of your main points here: first, to be clear it's a user-configurable parameter today, as is bondless maker allowance, and unlike the latter, it's a familiar concept. It's already the case that my suggestion of 'change the exponent' is at least somewhat unfair to people who locked up long term funds. I hope that it discourages exactly that behaviour. The reason we see people making very long term commitments, I think, is because they've recognized it's a way to overcome the hurdle of quadraticity of amount valuation. But, apart from my long rant above about why that's "bad", there is also the obvious point, which you make yourself, that this can be done by large holders just as easily as small holders. To whatever extent there is a problem with bond valuation, changing the default interest rate doesn't help. And as much as we would like to de-emphasize amount with algos like 'any amount above X is OK' it breaks the anti-sybil property, if the valuation of the bond with BTC amount is not super-linear (i.e. the exponent y in bond value = (btc amount)^y is not greater than 1).
This is possible, and an interesting thought: keep track of fidelity bonds used and de-weight them for let's say the next 1 or 2 coinjoins, or variations on the idea. It's complicated. Also there is a force pushing in the other direction: we already slightly tend to be more in favour of re-use of makers who prove reliable (ones that don't send signatures get added to
A minor one so I left it to the end, but this example is IMO not that useful, as 100x is already completely overwhelming, even if the exponent were 1. Compare 1BTC to 0.1 BTC (i.e. 10x) I think is better; a change from 100x likelihood, with exponent 2, to 20x, with exponent 1.3 |
Closes #1247. This consists of a change to the default value of bondless_makers_allowance, an inclusion of the bond value exponent into the config that the user can alter, and a change to the default of that value from 2 (implicit by quadratic) to 1.3. Also updates the fidelity bond documentation to account for those changes.
|
#1253 gives a concrete proposal. Feel free to keep the discussion here if it's easier, either there or here is fine with me. |
I think this is a completely wrong line of thinking. Money being locked up for a long time isn't a consequence of our software, but of human nature. In all other areas of finance we see people locking up capital for years or decades. People who invest in real estate usually intend to hold their property for years. People who invest in the stock market usually intend to hold their assets for years. Same with gold, bitcoins, education, etc etc anything else you can invest in. It's just human nature and market forces. We shouldn't go against it just because it makes our lives as programmers easier. And anyway, long-term lockups increase the sybil resistance of the system. The longer people lock up their coins, the harder it is to sybil attack joinmarket. These long-term lockups should be celebrated IMO. Yes nobody knows the future of joinmarket or bitcoin, but that's okay. Fidelity bond owners know this and have chosen of their own free will to take the risk anyway. In return for that risk they get a reward of more coinjoin fees, and a side effect of that is we all enjoy much greater sybil protection than before. |
This is bad logic. A big reason is because of tyranny-of-the-default. The vast majority of users won't go changing default parameters, especially of a parameter that's pretty complicated and abstract in its effects. For better or worse, we programmers have a huge amount of control over these parameters.
This is not right, at all. One person participating in a coinjoin doesn't have enough knowledge to unmix the coinjoin. The only way to unmix a coinjoin is to be all the makers in that coinjoin, not just one. |
|
I think a change something like this is a good idea. The main reason is that I think the current power of 2 causes a lot of centralization, we're probably in a situation where about 30 makers have enough information between them to unmix most coinjoins. Yes we're very very sure that those 30 makers are genuinely 30 different people, but it would be much more comfortable if that number was 100 or 200 instead. Occasionally I've seen people on the telegram group say things like "I don't like fidelity bonds because my maker doesn't get many coinjoins anymore, and I liked earning money". This is a bad reason to change the parameters IMO. The point of joinmarket is to improve privacy, not to provide an easy income stream. Nobody in this thread actually said anything like, but I just wanted to pre-empt it. The only justification for changing the parameters is to improve privacy, and my above point about decentralization does this. Someone in this thread said something like "well we have 400 makers overall, isn't that enough", but we must remember that without fidelity bonds we have no evidence that those 400 are actually different people. They could easily all be chainalysis running those bots, it wouldn't be much of a cost to them at all. Right now all the displays in the software use BTC² as a unit, we should move to something like FBU (short for Fidelity Bond Unit) instead, then we define Changing parameters like this is a rug-pull on people who've already created fidelity bonds. I think we should introduce this change as a flag day set in the future, something like I've got some python scripts which calculate how the sybil resistance of the system changes with different powers. (Sorry I haven't been able to finish them and publish them yet due to personal issues). I tried with parameters where the power is 2, 1.7, 1.5 and 1.2, and all of them seemed to offer still pretty good sybil protection (like, it still costs hundreds of thousands of bitcoins locked up for months, and if the top fidelity bonds were actually the same person they would still be foregoing tens or hundreds of BTC in value). So any of those values are fine, I'd go with 1.2 or 1.3 personally to try to get as much decentralization as possible. I'm against changing |
Yes, it's human nature and market forces, but it's market forces in the context of what we have as our hardcoded bond value scaling (and the other parameters, default vs hardcoded to one side for a moment). It's not about making our lives easier, it's about what commitments we should and should not make to users, because they are or aren't easy to live up to.
I can see that this has always been a disagreement between us, and for sure it's subjective, but I am focused on the issue of inertia, in case something unpredictable happens: if the software were perfectly secure and correct, and we were only thinking about future updates that were augmentation, then I think it'd be more sensible to say 'ok, lock up for any amount of time that seems reasonable', but I think it's more sensible to suggest to people not to lean on the time aspect here, since if a large majority did, we could be severely hampered from making needed upgrades (honestly I'd count it as slightly unlikely that such a change might be needed, but it scares me to think that it might happen). This of course also ties in to the rug pull element. That's a clearly valid criticism of this proposal, specifically on the exponent (since it was hardcoded). @PulpCattel also agrees as per here.
I can see this argument (re: maker count). My problem with it is, why ever have this value above 0, if it's considered equivalent to maker count? (you could still code it to fall back if we ever didn't have enough FBs for the join, but 0 could be the choice when there are). Speaking as a user, when I did coinjoins recently, I found myself not very happy with using the current parameters, because I don't actually want to coinjoin over and over again with the same counterparties (to be fair, there are positives to this, but the negatives outweigh it), and I have a little anecdotal evidence here and there that others feel the same. That non-FB makers may be likely Sybils is understood, but so is the argument that we always made back in the day 'one set of spies might be sybilling but so might another', which is of course a weak but not actually false argument. Personally I would definitely be fine with 0.125 if I saw 100+ FB in the market, with a decent chance of a lot of them being chosen. With 30, and with maybe 8 having a dominant probability of being chosen on the FB-weighted choice, I am much less comfortable with it. (Update: checking the OB today I see it's more reasonable to talk about 50FBs with maybe 10-15 having a decent chance. Much better but still not great). The probability weighting and the small pool together make it, to me, not yet actually functioning as intended. Sybil protection is really slippery as a concept.
I'm really a bit torn here, because I also agree that changing the former has a lot more compelling case than changing the latter, but I also agree that the 'rug pull' critique is very valid for the former (because it was hardcoded) but not as much for the latter (configurable).
To be clear, this Issue opening and PR is not coming from the comments of people being upset that their small amount of committed funds cannot get an income stream easily. It's looking at how the market functions from the orderbook that concerns me (although as per update above, it seems to be getting better maybe?). I know you've been thinking about it too, partly why I opened this :) |
|
So finally, on the concrete issue of rug pull vs exponent update:
I remain torn about it. I would like to see the system be more healthy, and a very long delay like that doesn't feel right to me. A change from 2 to 1.3 still keeps the fact that bigger has more value, it just reduces it and spreads it out. I'd argue that in fact, a larger maker might see more volume after this change, because the system as a whole is more healthy and attractive, that may counteract the fact that they get a reduced (from overwhelming!) probability of choice. People (like me) may also be happier to stick with 0.125 bondless allowance or even 0, after this change. So in short I think we have to tear off the bandage or whatever the saying is, either do this immediately or after a short delay. But to be fair, this decision very closely ties in with the disagreement above: I still think people using long lock times is a very bad thing. This is one reason. |
How long do you think or recommend a FB should be set?
The point of joinmarket is to improve privacy of course, however, when people complaining you will find mainly two kinds:
So overall I do approve the changes since more chances for the rest of makers will reduce the actual concentration but it could also make sense to just make mandatory FB with a fixed value (locking a fixed amount & time) since it would give the same chances of getting CJ to all makers. Other competitor services people they just pay get privacy, earnings should not be the main reason (and makers can still set their desired fee) |
I think you're saying that people only lock up coins for a long time because of the superlinear scaling? If so I don't think that's right. There would be long lockups even if the exponent was one. We see long term investments happening in other areas of life even though the return is linear (as a concrete example, 10 people each putting $100 into a fiat bank savings account will get exactly the same total return as one person putting $1000 into the same fiat bank savings account, yet some people still put cash into savings account locked up for years). Regarding having to make changes regarding fidelity bonds, I'd say that is just part of the risk fidelity bond owners have to take. And the risk isn't that big I think: It's very likely that fidelity bond owners will always be able to get their coins back, because the timelock wallet part isn't too complicated and issue #993 should help eventually. I expect people locking are coins are long term hodlers, so its most likely their coins would've been sitting around in cold storage not doing anything anyway, so if they end up not making much money from their timelocked coins then that isn't too different to having bitcoins in cold storage.
My initial line of reasoning is written here: https://gist.github.com/chris-belcher/18ea0e6acdb885a2bfbdee43dcd6b5af#taker-algorithm-for-choosing-makers
FWIW in teleport/coinswap I intend to not have a bondless maker allowance, every maker must have a fidelity bond, because its required to avoid a certain DOS attack. In coinswap it's possible for a taker user to waste their time and miner fees, and the coinswap can still fail, and a fidelity bond helps disincentivize this. I agree with everything else you said. It's concerning that even today you as a taker don't like the default parameters, that probably means we shouldn't use a flag day then, but fix the problem and increase decentralization straight away. |
|
Maybe it's a stretch, but based on the conversation so far, let's say there's consensus on changing the exponent to 1.3. What about the 0.125 v 0.375 (which again, was only a guesstimate from me, nothing concrete)? Anyone else has opinions on that? I'm definitely not dogmatic about it. I just think it should be higher for now, with a bigger/deeper pool of FB liquidity naturally leading to less and less need for large values here. Remember for that one ( |
|
I'd like to suggest a deadline of 1 week from today for making a decision on this. It could be just #1253 or an adjustment of it or something else, but we, imo, should be building a release shortly and this change should be included (along with the onion messaging which now seems to be stabilized). |
|
An exponent of 1.3 is good with me. I support FWIW, speaking historically the reason I chose an exponent of 2 was because I forgot the possibility of fractional exponents. So in my head the choice was only 1 or 2 (or natural numbers higher than two which are even worse). It sounds stupid now but that's how it went. Two is also the exponent in Metcalfe's law which I was thinking about a lot at the time. |
|
See #1253 (comment) ; I think this is a fair assessment of all the discussions we've had and is conservative, so without further objections that's what will go forward (only exponent to 1.3). |
Closes JoinMarket-Org#1247. This consists of an inclusion of the bond value exponent into the config that the user can alter, and a change of that from 2 to default 1.3. Also updates the fidelity bond documentation to account for those changes, including the units used in ob-watcher, but not the calculation of fidelity bond attack resistance (which remains a TODO).
|
A recent check of this with ob-watcher shows 82 offers with fidelity bonds and 85 offers without - almost a 50/50 split. When this was proposed, the number of fidelity bonds in the market was not very large and most of the makers didn't have fidelity bonds. Now that we will soon have more offers with bonds than without, should we consider switching back to an exponent of 2 to reduce the likelihood of Sybil counterparties? |
and others
With a mind to a new release being fairly imminent now, let's canvas opinions on fidelity bond settings.
This has been discussed a little bit, informally, in a few places, but it needs some kind of public discussion, I guess.
First, the two user chosen settings in the
joinmarket.cfg:joinmarket-clientserver/jmclient/jmclient/configure.py
Lines 95 to 97 in 0d20aa9
_DEFAULT_BONDLESS_MAKERS_ALLOWANCEfrom 0.125 to 0.375.Reason: in the long term we would much prefer this to be small, maybe even smaller than the current 1/8 (0.125). But the number of fidelity bonds in the market thus far has not been very large. Combined with the below (the exponent) this has meant too much concentration of joins amongst a small group. Setting this higher is in some sense going in the wrong direction, but it's an attempt to say "let's take this slowly until the system is actually working as intended". To be clear, I chose 3/8 just intuitively, I have no quantitative analysis to justify any particular number, here.
The third important item is the exponent; this is not currently user configured, but hardcoded, here (the value 2 mentioned below is implicit, i.e. squaring the returned value):
joinmarket-clientserver/jmclient/jmclient/wallet.py
Line 2560 in 0d20aa9
See here for @chris-belcher 's original detailed analysis - quadratic is exponent 2.
Reason: This would have the effect of much less heavily weighting size. As long as the value is larger than 1, it still economically incentivizes not splitting the time-value you sacrifice in fidelity bonds, into multiple amounts. But with an exponent as high as 2, a 10 times larger bond has 100 times more chance of being chosen ... given the already Pareto-distributed wealth (let's say), this has a really very strong concentration effect which is deleterious. We somehow have to counterbalance 2 requirements: users want varied counterparties, but don't want Sybil counterparties. Erring on the lower side is in my opinion the correct decision here, at least for now. (We could also make the exponent user configurable.)
This direction will of course reduce the quantitatively assessed 'defence against Sybiling' for now. Based on a lot of conversation and looking at the market, I think that it makes sense.
The text was updated successfully, but these errors were encountered: