Here is a link for a draft of a BIP for a different type of CoinJoin I've named
'SNICKER' = Simple Non-Interactive Coinjoin with Keys for Encryption Reused.
Summary in document abstract and motivation, but also there is a more
discursive blog post I wrote a while back, linked in the abstract, if you find
Purpose of writing this as a BIP:
There was some discussion on the Wasabi repo about this recently
(https://github.com/zkSNACKs/Meta/issues/67) and it prompted me to do something
I should have done way back when I came up with the idea in late '17: write a
technical specification, because one of the main attractive points about this
is that it isn't a hugely difficult task for a wallet developer to implement
(especially: Receiver side), and it would only really have value if wallet
developers did indeed implement it. To be specific, it requires ECDH (which is
already available in libsecp256k1 anyway) and ECIES which is pretty easy to do
(just ecdh and hmac, kinda).
Plenty of uncertainty on the specs, in particular the specification for
transactions, e.g. see 'Partially signed transactions' subsection, point 3).
Also perhaps the encryption specs. I went with the exact algo already used by
Electrum here, but it could be considered dubious (CBC).
Thanks for any feedback.
Adam Gibson / waxwing
Sent with [ProtonMail](https://protonmail.com) Secure Email.
bitcoin-dev mailing list