Please tell me you actually walked around town with that 😄

I don't think pixel is available where I am. Is it the only option?

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.

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.

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.

Yeah i figured you meant that. I just have that kneejerk "not proper cryptography" reaction. The reaction is definitely out of place here 😁

Interesting thought. But I'd say they are more an efficient *encoding*, not encryption.

Thanks for all your coverage of this, no matter how awful it is.

He has a huge anon set.

Writing P =xG instead of P = g^x is using additive notation. In something like bulletproofs that matters a lot. Yeah, conventions for inner products and vectors are very helpful, though one has to be careful with them. I think the bulletproofs paper itself from 2017 was quite influential in that regard.

It's not particularly surprising but I agree it's unfortunate.

I remember coming back to London in 2018 after a very long time away and seeing this exact ad (i think? If not, very similar). It was surreal but I can't say I liked it.

"Team additive notation" as we call it 😁