Hi all,
waxwing, ThomasV, and I recently had a discussion about implementing SNICKER in
Electrum; specifically the "Receiver" role. To me, SNICKER is an interesting
proposal, due to the non-interactivity and because it seems it would be easy to
implement the "Receiver" role in a light wallet. If enough users are using
wallets that implement the "Receiver" role, even if full nodes and specialised
scripts are needed to run SNICKER as a "Proposer", then coinjoins via SNICKER
could become fairly frequent on-chain, benefitting the whole ecosystem
indirectly by breaking common chain-analysis assumptions even further.
The BIP (draft) describes how the Receiver can deterministically find all his
outputs and reconstruct all corresponding private keys, just from the seed
words and the blockchain.
However what is not explicitly pointed out, and what I would like to point out
in this mail, is that SNICKER breaks watch-only functionality.
See "Receiver actions" > "Storage of Keys" section ("Re-derive from blockchain
history"). [0]
Specifically, the output address in the SNICKER transaction that pays to the
"Receiver", is constructed from the pubkey `P_A + cG`, where `P_A` is a pubkey
of "Receiver" (typically a leaf pubkey along some BIP32 path), and `c` is a
tweak. This tweak was constructed such that `c = ECDH(Q, P_A)`, where `Q` is a
pubkey of the "Proposer" that appears in the witness of the SNICKER tx.
As the referenced section [0] explains, the "Receiver" can restore from seed,
and assuming he knows he needs to do extra scanning steps (e.g. via a seed
version that signals SNICKER support), he can find and regain access to his
SNICKER outputs. However, to calculate `c` he needs access to his private keys,
as it is the ECDH of one of the Receiver's pubkeys and one of the Proposer's
pubkeys.
This means the proposed scheme is fundamentally incompatible with watch-only
wallets.
Nowadays many users expect being able to watch their addresses from an unsecure
machine, or to be able to offline sign transactions. In the case of Electrum
specifically, Electrum Personal Server (EPS) is also using xpubs to function.
We've been exposing users to xpubs since the initial BIP32 implementation (and
even predating BIP32, in the legacy Electrum HD scheme, there were already
"master public keys").
It would seem that if we implemented SNICKER, users would have to make a
choice, most likely during wallet creation time, whether they want to be able
to use xpubs or to potentially participate in SNICKER coinjoins as a "Receiver"
(and then encode the choice in the seed version). This choice seems rather
difficult to communicate to users. Further, if SNICKER is not supported by the
default choice then it is less likely to take off and hence less useful for the
user; OTOH if xpubs are not supported by the default choice then existing user
expectations are broken.
(Note that I am using a loosened definition of xpub here. The pubkeys in
SNICKER tx output scripts are not along any BIP32 derivation. The point here is
whether they could somehow be identified deterministically without access to
secret material.)
Unfortunately it is not clear how the SNICKER scheme could be adjusted to "fix"
this. Note that `c` needs to be known exactly by the two coinjoin-participants
and no-one else; otherwise the anonymity set (of 2) is broken as:
- which SNICKER output corresponds to the tweaked public key and hence to the
Receiver, can then be identified (as soon as the output is spent and the pubkey
appears on-chain), and
- using subset-sum analysis the inputs and the outputs can be linked
SNICKER assumes almost no communication between the two parties, so it seems
difficult to find a sufficient construction for `c` such that it can be
recreated by the Receiver if he only has an xpub (and access to the blockchain)
as all pubkeys from the xpub that the Proposer would have access to are already
public information visible on-chain.
ghost43
[0]
https://gist.github.com/AdamISZ/2c13fb5819bd469ca318156e2cf25d79#Storage_of_Keys
> 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
>
> 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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
