Increase the default makercount to more than 8~10 #1047
Comments
Samourai coinjoin implementation has 5 equal outputs.
I'm not sure this is true, in the sense that remixing is simply the only way to have strong privacy guarantees with CoinJoin, even Wasabi that has an average # of participants around 60-70 heavily uses and encourage remixes. I.e, the tumbler will be needed regardless, especially by average users that most likely cannot outperform it.
The main reason is IRC servers limitation.
If he wants strong privacy, he'll have to wait, and it can take days, not just hours. The same happens in any other CoinJoin implementation. This is, I think, important to note, because it's important not to be misleading in what is being proposed to users.
As said above, I don't think there's a reason to remove the tumbler, nor I think remixing with it become unneeded just because we have a lot of counterparties. I'd love to see big CoinJoin becoming viable, hopefully by moving away from IRC, but I'm not sure we can make such the default. It may be better keeping the default at e.g., 10-12 and having the possibilities for whoever wants to to make much bigger CoinJoin. |
|
As @PulpCattel said, we are limited by IRC servers limitations, how much data we can send beween peers in limited amount of time. See also - #415. |
|
I also agree with the general flow of @PulpCattel 's response. If we get something following from #415 then we can discuss how/to what extent to move to larger single tx anon sets; as it is even 10-15 is pretty hard. I hope this motivates people to either help out with #1000 or make serious efforts towards another alternative :) |
|
Got it, thank you all so much for your inputs, I did not aware that IRC server limitation was the root cause.
So each input would increase the transaction size by 67 vBytes, and each output would increase the transaction size by 31 vBytes. If adding one maker would introduce 2 inputs and 2 outputs on average, we're talking about 67*2 + 31 * 2 = 196 bytes. When the mempool is empty and that 1sat/vB can be mined, having 20~30 makers instead of 10 would increase the fee by 2000 ~ 4000 sats, still acceptable. If the mempool is full, when you need to pay 5 ~ 8 sat/vB, the additional fee cost would increase to 10k sats ~ 32k sats. It would be too high to coinjoin 100k sats with such a high fee. But if I'm trying to mix 100M sats, I wouldn't mind paying 10k~30k sats more to double / triple the anonymity set. We can also prioritize the tx_fee_contribution and the cj_fee over fidelity bond when the amount to be mixed is small, but less focus on the fee but mostly on the fidelity bond value when the amount to be mixed is large, as usually the more coin you're trying to mix, the more protection you'd want. |
|
On that aspect, the idea that we could end with too large a fee burden on takers, a couple of points to note:
All this just brings up the fact that our fundamentally 1-to-many asymmetric design makes very large anon sets be quite different from other cj protocols. Edit: but otoh I do totally agree that for large-ish coinjoin amounts, even with a completely unchanged model, anon sets much larger than 10 are perfectly viable. In particular, note that a tumbler of 10 txs is just like having say 80-100 size single join, more or less, from the cost point of view. What's much more open to discussion is whether it's better. Consider amount correlation for example. |
Could you elaborate a bit more on this point, why this is the case? Say I'm trying to pay Jack 100k sats, I CoinJoin 100k sats and let one of the output arrive in his wallet directly in that CoinJoin tx, what would be the problem here? Personally, when I CoinJoin as a taker myself, 8~10 counter parties doesn't make me feel safe enough, and that's the main reason I use Tumbler to CoinJoin multiple times. I would feel much safer if the anonymity set is much larger. I'm not saying that we should get rid of the Tumbler, but I'd prefer to reserve the Tumbler mechanism as a more advanced mechanism that maybe hidden in some advanced settings and only present that to users who knows a lot more about JoinMarket. When I first opened up JoinMarket, the whole thing about Tumbler feels very daunting as I had no idea what that is and why I would need it. |
Yes! That's what I was trying to say. And especially with the introduction of Fidelity Bond, there is a higher chance that the taker would re-mix with the same makers multiple times in the following CoinJoin transactions, that might not necessarily be better than having one CoinJoin tx with like 50 other counter parties. |
|
Note that with just a single coinjoin it can be pretty easy to unmix a join based on what the coinjoin outputs later do. The maker's coinjoin outputs will almost certainly be spent as inputs into other coinjoins, but the taker's output will be spent in some other non-coinjoin way (perhaps consolidated and then batched if it was sent to a merchant, or remain unspent for years if sent to cold storage). Repeated coinjoins are also very important to break this effect. |
5-8 sat/vB is an empty mempool :), in your calc I'd substitute 5-8 sat/vb as the empty case and 50-80 sat/vb as the full case (not that 80 is a ceiling at all, we have seen much more than that ofc).
I'm curious, why do you consider 5-8 sat/vb "such an high fee"? If Bitcoin and its incentive structure work, we should assume much higher fee rate going forward.
The Edward Snowden of the situation may not have a lot of money to hide, but he may still want as good of a privacy/security as he can get. The more coin, the more possibilities, that's for sure, but not necessarily wanting more privacy.
@AdamISZ Yeah, that's the crux, I'm on the camp of 10 txs with 10 people each over time, we can see it as a kinda defense in depth concept, where we want no single point of failures and multiple layers of defense.
There have been a lot of previous discussion on this topic, the more recent are in e.g., #864, #948
That's what the documentation is for, but also, can't we fix that with a better and cleaner UI? I mean, do you think it's inherent to the tumbler being too complex? |
I guess my other question is, when a user is doing a Tumbler schedule, should we consider avoiding taking the offer from the same maker in the subsequent CoinJoin mixes?
Yes, that's true. But for smaller amount of Bitcoin, I think it makes much more sense to use Lightning to protect your privacy. And when you have a large enough amount, that you want to save it to your cold storage; or when you want to pay a big amount to someone else, where the amount is too large to use your Lightning wallet, that's when CoinJoin shines. If we want everybody to CoinJoin to improve their privacy, there is no way for everybody to CoinJoin their every small transaction on-chain due to limited block space. The way I see it, is that everybody has to batch their transactions via lightning (or Liquid, or whatever), and occasionally do a large on-chain transaction with CoinJoin to protect their on-chain privacy. When the transaction amount is large enough, the on-chain fee would be much smaller percentage-wise and can easily be justified.
If the fee is 50 ~ 80 sats/vB, even if you only CoinJoin with 8 other makers, the total transaction would be 196vb / maker * 8 maker * 80sats / vB = 125440 sats. You still wouldn't be able to CoinJoin 100k sats, and that'll be 12% of a 1M sats coinjoin. And if the fee is 5~8 sats / vB, the difference between 8 other makers and 24 other makers, is 196 vb / maker * (24 - 8)makers * 8 sats / vB = 25088 sats, which is only 2.5% of a 1M sats coinjoin. My point is, when the on-chain fee is very high, lowering the number of counter parties would still incur a very high on-chain fee and may only worth doing it when you CoinJoin a large amount anyway. But when the on-chain fee is low, increasing the number of counter parties doesn't increase the on-chain fee that much comparing to the benefit of doubling / tripling / quadrupling the anonymity set.
Yes, regarding that, I think a more fine approach here is to take into the account of both the amount of BTC being CoinJoined, as well as the on-chain fee you're paying as a taker. I think having a default cap fee of say 0.5% ~ 1% could be considered to protect the user from shooting himself in the foot. For example, if the default settings of target makers is 25, and the default cap fee is 0.5%, and I'm trying to CoinJoin 10M sats (which is very common on JoinMarket), if the fee is lower than 50k, it'll be acceptable. Otherwise, we give the user a warning and asking the user double check and confirm if they wants to proceed forward, and also provide the option of lowering the counterparties as a way to lower the fee. Or, if we find that by having 25 makers, the fee would be over 0.5%, we could lower the default value of counter parties to maybe 8 ~ 10 as it is today? Nevertheless, if the CoinJoin amount is too small, and the on-chain fee is very high, like 50 ~ 80 sats / vB as you mentioned above, even with 8 ~ 10 makers the fee would still be too high to justify CoinJoin 100k or sometimes even 1M sats.
Yes. That's my point. It's already not so easy to understand the concept of CoinJoin, adding Tumbler on top of that makes the whole thing much more difficult to understand. For sure, Tumbler would increase your privacy, and may be more effective than simply increasing the counter parties count. But if the user is only doing one CoinJoin, either due to not having the time to wait, or due to not understanding the concept of Tumbling, having more counter parties is still a net positive from the privacy's perspective. |
|
I guess we could summarize as: the default cost of JoinMarket can already be high, especially if someone is not a bit careful, and there are indeed warnings across the relevant doc files about miner fee and tumbler costs, so I think increasing it 3-4-5-etc times more, when not strictly needed, is not necessarily a win and quite a danger for user.
Interesting, it doesn't have to be a complex concept, no? Once one grasps what a CoinJoin is, the idea of chaining multiple ones in a row should be reasonable to follow.
Yeah, the idea here would be that the user could choose a higher number of counter parties when desired, and by doing so we can assume it is a more conscious decision. |
Fidelity bonds should make those go right back up, at least in theory.
Paying 0.002% of the CoinJoin amount per maker is definitely affordable/worth it, it's in fact ~ free. Bitcoin block space is not as generous as JM makers though, and, as said above, maybe we can't count on charitable makers either going forward. |
|
Just idea - how about some kind of dynamic default maker count choosing, depending on cj amount and current fee environment? This is actually something I have done manually when sending small amount as a taker, I often reduce maker count on command line manually, so that transaction (using coinjoin) makes sense economically to me. |
I still think default maker fee is currently unfairly cheap, IMHO should be increased to 0.003%, which is Wasabi default per anonymity set. |
That sounds cool, a few questions that come to mind related to implementation complexity:
|
|
About unfairly cheap: 0.00002 x 10 counterparties x 10 transactions in a tumble is still only 0.2% so I think i agree. Only for very large coin amounts does that not get overwhelmed by network fees. However I am not a fan of fussing over these defaults too much; the market will figure it out. |
We add a new label next to the text field, provide a "suggested maker count", base on "the cj amount and current fee environment". Also a button next to that label, which is "use suggested maker count", if the user click that button, the text field will be replaced by the "suggested maker count". This way, we dynamically update that "suggested maker count" without replacing what the user has already entered in the text field.
What do you think about this "suggested value" idea? That way we don't mess around with the default value, but also provide a better suggestion base on the cj amount and the fee environment. For the cli interface, we can also provide a suggested value, but we may not continously update that value dynamically as we can do with the QT interface. |
and others
The current default maker count is a random number between 8~10, this doesn't provide very good privacy protection as the anonymity set is very small, especially when we comparing this number to what other CoinJoin wallet does: Samurai, Wasabi, etc., they all have a much higher CoinJoin counter party count.
To mitigate this problem, JoinMarket had introduced the Tumbler mechanism, which is confusing to the new comers and makes it much harder for them to understand how to effectively make use of JoinMarket.
IIRC, the reason we had only 8~10 as the default number of coinjoin at JoinMarket, was because that there wasn't enough makers to provide the liquidity. But from what I can see, the situation is very different today.
At this moment, I can see 437 orders provided by 305 counterparties on the JoinMarket Orderbook, and there are 53 fidelity bonds found with 415.62868225 BTC total locked up. And the majority of these orders are only asking for 0.001% ~ 0.003% of maker fee for CoinJoin.
Base on these stats, I think it makes sense to increase the default maker count:
The ideal situation IMHO would be that we increase it to a number that is high enough where the Tumbler mechanism is no longer needed, like 50~100. But that number may still be too high to be used right now as there are only 53 fidelity bonds locked up.
My suggestion is that we can increase the default maker count to something like a random number between 20~30. In this case, even if a user only did a single CoinJoin when they need to spent their Bitcoin sooner, they would still get a pretty decent anonymity set to protect their privacy.
Any thoughts please?
Thanks!
The text was updated successfully, but these errors were encountered: