Hello list,
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 
that helpful.

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

Reply via email to