Subnostr

nostr:nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0aumg5q can you elaborate on this flaw in JM?

waxwing 5mo ago

It depends how you look at it, but an external actor can often (not always) trace through a sequence of a few taker side joins *assuming the taker is the same actor across them*; that assumption is true more often than not. I did some quantitative analysis of this myself on real transactions and it's like 40-60% of individual joins that have the necessary property of identifying the input set of the taker, though success strongly depends on assumptions made about coinjoin fees.

So there are a number of factors, but generally the anonymizing effect is much weaker than one would believe if you go for "a few coinjoins with "anon set of 9-10". All depends on your usage pattern. A long running mixture of taker and maker behaviour is best, but there are never any guarantees, just long term amelioration.

That's how i always saw coinjoin generally, but most people don't, I guess. They want guarantees.

Reply to this note

Please Login to reply.

Discussion

Peter Todd 5mo ago

...at which point you really gotta ask why don't you just use Wasabi, which can get a better and more reliable k-anonymity set per transaction?

JoinMarket should fix this issue too, maybe with some kind of out-of-band payment scheme. But even if it doesn't seems thwt Wasabi's huge transaction model is more efficient.

waxwing 5mo ago

I'll always be skeptical about any centralized coordination because of the weakness to internal and external attacks on the coordinator. So that's the main "why not?" answer. Albeit I do think Wabisabi's design is very powerful.

Re: out of band payments, totally agree, I had two separate but related ideas about that over the years, but they never seemed very easy to implement. One was "Coinjoin unlimited", basically coordinating transaction graphs instead of single transactions (for a steganographic effect), with a lightning channel opening embedded to move the payment element offchain. The other was more a pure "make the payment on L2 with a swap and a HODL invoice", but I'm not at all sure you could make such an idea work in practice. That general meta-concept of "L2 has privacy properties, leverage them into your onchain (much larger) transfers that are much more secure but have much worse privacy properties" feels right, but not very easy.

waxwing 5mo ago

Oh, one other thing I wanted to comment on: you mention that it's more realistic to have makers pay than takers. I think it's hard to know, because both sides have advantages, but ideally, you just let the market figure it out. The problem I always had was, while a negative fee (i.e. makers pay to take part) is clearly possible in software with trivial changes, it's a scary concept to have makers passively ready to do unlimited transactions where they lose money. I guess you could attack it from a number of angles, such as just rate-limiting. Hmm on reflection not sure why this wasn't pursued more. But anyway the off band payments would indeed be the "royal road". I know indeed that several people, including Peter, have suggested that a system like this could work way better with no inter-participant payment at all. I wasn't convinced that a zero-fee version would work, but, for sure, there's an argument for implementing that, too. Best would be a complete free market if that were practically possible.

Cody 5mo ago

Thanks for bringing this to people's attention. Prior to this thread I believed (ignorance on my part) that JM had better privacy assurances than it seems to.

I love the JM and JAM projects and hope they can continue to improve