1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Return-Path: <somber.night@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6507240B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 00:29:36 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0ABD5F8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 20 Oct 2019 00:29:34 +0000 (UTC)
Date: Sun, 20 Oct 2019 00:29:25 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1571531372;
bh=CrWp2hBaALQIYMt6JrK16kqm0k57zMwsKsiPBLXwYwA=;
h=Date:To:From:Cc:Reply-To:Subject:Feedback-ID:From;
b=cITqzvem174VKxC0qmlSEir9B4Q70FRcz7iHnzYtJEG1QSqxoN4OaCkJo6Kj0IRqY
+RhaHTL17GKmvn0fEE0oh4HJxteU79EeEv6DdNTGLYBMgocFtz6j/syfO36HE6l9mu
16jzfD+BPJQoojUsv02hNMVGB502cARYybuC/6a0=
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 20 Oct 2019 04:30:58 +0000
Subject: Re: [bitcoin-dev] Draft BIP for SNICKER
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Oct 2019 00:29:36 -0000
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
|
