Date: Sun, 20 Oct 2019 00:29:25 +0000
To: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
From: SomberNight <somber.night@protonmail.com>
Reply-To: SomberNight <somber.night@protonmail.com>
Message-ID: <YwZ3vq20LFvpx-nKn1RJjcRHwYTAVCC0v0EyD0y6zVMlQtKXUFNAaEk_QE2dzYDU6z2eK0S0TDXRPfl1_y93RgDjdCGboOgjcERBTLUPHao=@protonmail.com>
Feedback-ID: daQbrs0DpmRrllQYkksiX-ZnvUtz6D5CoTQt69spWvfuKGSaRC1oU4kOBEGTrhNvt_RBDz2CWSzCwYz6Ytdxzw==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Draft BIP for SNICKER
Precedence: list

Hi all,

waxwing, ThomasV, and I recently had a discussion about implementing SNICKE=
R in Electrum; specifically the "Receiver" role. To me, SNICKER is an inter=
esting 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 user=
s are using wallets that implement the "Receiver" role, even if full nodes =
and specialised scripts are needed to run SNICKER as a "Proposer", then coi=
njoins via SNICKER could become fairly frequent on-chain, benefitting the w=
hole ecosystem indirectly by breaking common chain-analysis assumptions eve=
n further.

The BIP (draft) describes how the Receiver can deterministically find all h=
is outputs and reconstruct all corresponding private keys, just from the se=
ed 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 blockch=
ain history"). [0]

Specifically, the output address in the SNICKER transaction that pays to th=
e "Receiver", is constructed from the pubkey `P_A + cG`, where `P_A` is a p=
ubkey of "Receiver" (typically a leaf pubkey along some BIP32 path), and `c=
` is a tweak. This tweak was constructed such that `c =3D ECDH(Q, P_A)`, wh=
ere `Q` is a pubkey of the "Proposer" that appears in the witness of the SN=
ICKER tx.

As the referenced section [0] explains, the "Receiver" can restore from see=
d, and assuming he knows he needs to do extra scanning steps (e.g. via a se=
ed version that signals SNICKER support), he can find and regain access to =
his SNICKER outputs. However, to calculate `c` he needs access to his priva=
te 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-onl=
y wallets.
Nowadays many users expect being able to watch their addresses from an unse=
cure machine, or to be able to offline sign transactions. In the case of El=
ectrum specifically, Electrum Personal Server (EPS) is also using xpubs to =
function. We've been exposing users to xpubs since the initial BIP32 implem=
entation (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 ch=
oice, most likely during wallet creation time, whether they want to be able=
 to use xpubs or to potentially participate in SNICKER coinjoins as a "Rece=
iver" (and then encode the choice in the seed version). This choice seems r=
ather difficult to communicate to users. Further, if SNICKER is not support=
ed 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 SN=
ICKER tx output scripts are not along any BIP32 derivation. The point here =
is whether they could somehow be identified deterministically without acces=
s 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-part=
icipants 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 t=
he 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 seem=
s difficult to find a sufficient construction for `c` such that it can be r=
ecreated by the Receiver if he only has an xpub (and access to the blockcha=
in) 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#Storag=
e_of_Keys


> Hello list,
> Here is a link for a draft of a BIP for a different type of CoinJoin I've=
 named 'SNICKER' =3D Simple Non-Interactive Coinjoin with Keys for Encrypti=
on 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 s=
hould 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 th=
is is that it isn't a hugely difficult task for a wallet developer to imple=
ment (especially: Receiver side), and it would only really have value if wa=
llet developers did indeed implement it. To be specific, it requires ECDH (=
which is already available in libsecp256k1 anyway) and ECIES which is prett=
y easy to do (just ecdh and hmac, kinda).
>
> Plenty of uncertainty on the specs, in particular the specification for t=
ransactions, 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