AdamISZ [ARCHIVE] on Nostr: š Original date posted:2019-09-01 š Original message:Hello list, Here is a link ...
š
Original date posted:2019-09-01
š Original message: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.
https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190901/de941638/attachment.html>;
š Original message: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.
https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190901/de941638/attachment.html>;