summaryrefslogtreecommitdiff
path: root/81/7e4157954b0af5b2505adae76032949cd2c14c
blob: 7da9a3b7909d5f03ccad2fc1ab91e5c0c54ffd75 (plain)
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
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
Return-Path: <rsomsen@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 26D4DC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Oct 2022 23:41:24 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id EEF444013B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Oct 2022 23:41:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EEF444013B
Authentication-Results: smtp2.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=d3aK9hpl
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001, TRACKER_ID=0.1] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id npF1jOh8H8oo
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Oct 2022 23:41:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org D8B10400C8
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com
 [IPv6:2001:4860:4864:20::2e])
 by smtp2.osuosl.org (Postfix) with ESMTPS id D8B10400C8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  3 Oct 2022 23:41:21 +0000 (UTC)
Received: by mail-oa1-x2e.google.com with SMTP id
 586e51a60fabf-1322fa1cf6fso7492594fac.6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 03 Oct 2022 16:41:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date;
 bh=cSnD9loJfSpmX5MWFcvxaVjJyQzM3EELzZ1Ic/K00mM=;
 b=d3aK9hplahAX04jRCSZ4JM5GySBibhV1Elg/N/L7CQtQf2tO2yYuI/ZnkNZDmO7Hwl
 +rkLTIvjJUz7i1YgLRDUoIFP9Zk3JiM1SRfvQCI5SWAJB8maglxKgE/VwlZdfeStewwV
 bVKzD51qZ9kRo6hU497KP+JJnOuwbQKBF87No9720+LUozIFDMS5RDh+xJ3uqh5IcK8o
 mns4lrPL3BxdyeH+iEq8OEDO8D4Svz6O2/bANCrSNhylg1HSQktS6gMB9gF4YkKwS6NL
 xwrRQ+ozj+EwnpgvV5mVFa4IsI0113B6/qYcRmGrldcnaBz/3KIwKEFzvO9hLv6l92yU
 1npw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date;
 bh=cSnD9loJfSpmX5MWFcvxaVjJyQzM3EELzZ1Ic/K00mM=;
 b=4of4EeDWPJKRCuXYgUXEuEoJnML4Cw4vcK+QBd7MARPiUw53EveIHL3Jy6uE5npSov
 9jC8JHmUvx+c7wJwCTJNndhYckV0eFRoRiuquZQ6rKZtjEpMR9c5Mb4fXCOqYdAuSoJX
 DASngQUJiQyuDS0JhkScyr5+5EWq2GeyyiNPp7xwNxakky8g+Ks5qBh+EUs8nR8AKgvn
 LDPWs92enJr+1QHTT1/RJ0xyVmGZYGFnUeEFA0wIE63ejLLj/GWeTKMXOt5nKrARUZcY
 hzm34TPPTfuMzQ3FnSpkfOP2k287951csIAeI7CrLBv5VaXAYVJ05s4bhlnxNyjrTCst
 6czg==
X-Gm-Message-State: ACrzQf2FSopUcRCQUADD+BUJvnF2+j+RAY+kuoykooew5BeFEaV3bZ7D
 nZWR8Zw9UENM/KX7wGH+/1IpgGACiZ+PCIilOu59mly8BNI=
X-Google-Smtp-Source: AMsMyM7YtO8kWlDEqXFqR1e7wzvUxmULPzO6vn7R0Hua9j6iV73v7/lfbYeT1oSZ+RqW6+sWfP00kfrtQHBHp8TOfZI=
X-Received: by 2002:a05:6870:c0c9:b0:127:c4df:5b50 with SMTP id
 e9-20020a056870c0c900b00127c4df5b50mr6561870oad.126.1664840480726; Mon, 03
 Oct 2022 16:41:20 -0700 (PDT)
MIME-Version: 1.0
References: <BkzIoBmDaBRo-URg9JqL1fZOyN-iu32rvsv7VNfEKsnX3HuBjXEPcREYIUftcQ6TvOHY1pcjKGd8ekUYfEObGqdDNGuJYhxOqYb9_s_c80w=@protonmail.com>
 <CAPv7TjZOJSFeRjpJjY5Lkjpr4LRexsCuhi8t_1nkL9ys+qoYhA@mail.gmail.com>
In-Reply-To: <CAPv7TjZOJSFeRjpJjY5Lkjpr4LRexsCuhi8t_1nkL9ys+qoYhA@mail.gmail.com>
From: Ruben Somsen <rsomsen@gmail.com>
Date: Tue, 4 Oct 2022 01:41:10 +0200
Message-ID: <CAPv7TjZwxuUxUXSuxKbvQqUfO=c3-rx0tx+ajbLm3hzV4WptvA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000076231f05ea29e1af"
X-Mailman-Approved-At: Mon, 03 Oct 2022 23:42:13 +0000
Subject: Re: [bitcoin-dev] Third version of Silent Payment implementation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Mon, 03 Oct 2022 23:41:24 -0000

--00000000000076231f05ea29e1af
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Apologies, the link I sent in my previous post was incorrect and should
have been:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1218641521

Let me also use this opportunity to share another clarifying comment:

"There seems to be some confusion about the function of the identifier. Its
function is not to create more than one identity, but to be able to
distinguish why someone paid you. For example, when the same entity is
raising money on behalf of two different charities and wants to know for
which of the two charities the sender intended their donation.

To be absolutely clear, the payments that appear on-chain are still
absolutely unlinkable by a third party observer, nor are they able to tell
which identifier was used.

In cases where you don't want people to know that you're the same entity,
the identifier is insufficient =E2=80=93 you'll need a completely separate =
Silent
Payment address which (roughly) doubles your scanning efforts, so it's much
more costly in terms of performance."

This comment can be found here:
https://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1266193417

Cheers,
Ruben

On Fri, Sep 30, 2022 at 1:03 AM Ruben Somsen <rsomsen@gmail.com> wrote:

> Hi woltx,
>
> Excellent work.
>
> >Implements the new scheme suggested by Ruben Somsen that allows multiple
> silent addresses per wallet with minimal overhead
>
> To expand on this, the scheme basically allows the resulting address to b=
e
> recognizably marked (only recognizable by the recipient of course), which
> enables you to distinguish between different payment purposes (e.g. some
> people donate to you for purpose A, others for purpose B). Here's my
> original comment describing it:
>
> "Naively, the issue is that two keys means twice the scanning, but an
> interesting alternative would be to simply use the same key (assuming
> you're OK with using the same identity) but add a public identifier f to =
it
> when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X + f*=
G
> . This means every additional "address" only costs one additional ECC
> addition when scanning (relatively cheap compared to doing ECC
> multiplications).
>
> The main downside with this is that f becomes crucial for recovering from
> backup. If we set f as an index (0, 1, 2, 3...) then you'd only have to
> remember how many "addresses" you issued (and perhaps overshoot when
> unsure) to ensure recovery of funds, though of course you'd rather also
> remember which index is associated with what payment reason.
>
> Absolute worst case scenario you could even do something similar to the
> gap limit where you scan the full history (not just the UTXO set so you
> don't miss spent outputs) with a default max index of e.g. 100, and then =
if
> you find out most of them are in use, you scan the next 100, etc. Costly,
> but thorough, and only needed as a last resort."
>
> Original comment here:
>
> https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub=
-sharing
>
> Also good to note that f needs to be communicated to the sender somehow,
> perhaps as part of the address format.
>
> Cheers,
> Ruben
>
> On Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>> This new version addresses most (or all) requests made in PR:
>>
>> . Implements the new scheme suggested by Ruben Somsen that allows
>> multiple silent addresses per wallet with minimal overhead.
>> . Implements a new RPC to retrieve silent addresses, which allows users
>> to assign different labels to different addresses. That way, the user kn=
ows
>> which silent address the UTXO came from.
>>
>> Example:
>>
>> ./src/bitcoin-cli -signet -rpcwallet=3D"receiver" getspaddress
>> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>>
>> # This will return the same address as above (both have no label)
>> ./src/bitcoin-cli -signet -rpcwallet=3D"receiver" getspaddress
>> tsp001pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq
>>
>> # New label, new address
>> ./src/bitcoin-cli -signet -rpcwallet=3D"receiver" getspaddress 'donation=
'
>> tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kq80t7lt
>>
>> In this new scheme, the address has a new field called identifier, which
>> tells the receiver and sender how to set the address correctly.
>>
>> If the receiver, for whatever reason, doesn't know which identifiers hav=
e
>> been used, there is no problem. The wallet can scan all identifiers from=
 0
>> to 99. Currently, only 100 different identifiers per wallet are allowed.
>> This limit, however, can be increased at any time in the future.
>>
>> Unlike address formats so far, sp addresses are not script-related and
>> may eventually include any additional information needed, such as an
>> expiration timestamp (or block height). That way, users don't have to tr=
ack
>> the address indefinitely.
>>
>> As usual I wrote a step by step tutorial:
>> https://gist.github.com/w0xlt/c81277ae8677b6c0d3dd073893210875
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>

--00000000000076231f05ea29e1af
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi,<br><div><br></div><div>Apologies, the link I sent in m=
y previous post was incorrect and should have been:</div><div><a href=3D"ht=
tps://github.com/bitcoin/bitcoin/pull/24897#issuecomment-1218641521">https:=
//github.com/bitcoin/bitcoin/pull/24897#issuecomment-1218641521</a><br></di=
v><div><br></div><div>Let me also use this opportunity to share another cla=
rifying comment:</div><div><br></div><div>&quot;There seems to be some conf=
usion about the function of the identifier. Its function is not to create m=
ore than one identity, but to be able to distinguish why someone paid you. =
For example, when the same entity is raising money on behalf of two differe=
nt charities and wants to know for which of the two charities the sender in=
tended their donation.</div><br>To be absolutely clear, the payments that a=
ppear on-chain are still absolutely unlinkable by a third party observer, n=
or are they able to tell which identifier was used.<br><br>In cases where y=
ou don&#39;t want people to know that you&#39;re the same entity, the ident=
ifier is insufficient =E2=80=93 you&#39;ll need a completely separate Silen=
t Payment address which (roughly) doubles your scanning efforts, so it&#39;=
s much more costly in terms of performance.&quot;<div><br></div><div>This c=
omment can be found here:</div><div><a href=3D"https://github.com/bitcoin/b=
itcoin/pull/24897#issuecomment-1266193417">https://github.com/bitcoin/bitco=
in/pull/24897#issuecomment-1266193417</a><br></div><div><br></div><div>Chee=
rs,</div><div>Ruben</div></div><br><div class=3D"gmail_quote"><div dir=3D"l=
tr" class=3D"gmail_attr">On Fri, Sep 30, 2022 at 1:03 AM Ruben Somsen &lt;<=
a href=3D"mailto:rsomsen@gmail.com">rsomsen@gmail.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>=
Hi=C2=A0woltx,</div><div><br></div><div>Excellent work.</div><div><br></div=
><div>&gt;<span style=3D"font-family:Arial;font-size:14px">Implements the n=
ew scheme suggested by Ruben Somsen that allows multiple silent addresses p=
er wallet with minimal overhead</span><br></div><div><span style=3D"font-fa=
mily:Arial;font-size:14px"><br></span></div><div><font face=3D"Arial"><span=
 style=3D"font-size:14px">To expand on this, the scheme basically allows th=
e resulting address to be recognizably marked (only recognizable by the rec=
ipient of course), which enables you to distinguish between different payme=
nt purposes (e.g. some people donate to you for purpose=C2=A0A, others for =
purpose B). Here&#39;s my original comment describing=C2=A0</span></font>it=
:<font face=3D"Arial"><span style=3D"font-size:14px"><br></span></font></di=
v><br>&quot;Naively, the issue is that two keys means twice the scanning, b=
ut an interesting alternative would be to simply use the same key (assuming=
 you&#39;re OK with using the same identity) but add a public identifier f =
to it when tweaking. So instead of hash(i*X)*G + X you get hash(i*X)*G + X =
+ f*G . This means every additional &quot;address&quot; only costs one addi=
tional ECC addition when scanning (relatively cheap compared to doing ECC m=
ultiplications).<br><br>The main downside with this is that f becomes cruci=
al for recovering from backup. If we set f as an index (0, 1, 2, 3...) then=
 you&#39;d only have to remember how many &quot;addresses&quot; you issued =
(and perhaps overshoot when unsure) to ensure recovery of funds, though of =
course you&#39;d rather also remember which index is associated with what p=
ayment reason.<br><br>Absolute worst case scenario you could even do someth=
ing similar to the gap limit where you scan the full history (not just the =
UTXO set so you don&#39;t miss spent outputs) with a default max index of e=
.g. 100, and then if you find out most of them are in use, you scan the nex=
t 100, etc. Costly, but thorough, and only needed as a last resort.&quot;<b=
r><br>Original comment here:<br><a href=3D"https://gist.github.com/RubenSom=
sen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing" target=3D"_blank">https:=
//gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing=
</a><br><br>Also good to note that f needs to be communicated to the sender=
 somehow, perhaps as part of the address format.<br><br>Cheers,<br>Ruben</d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Fri, Sep 30, 2022 at 12:35 AM woltx via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div style=3D"font-family:Arial;font-size:14px"><br></div=
><div style=3D"font-family:Arial;font-size:14px"><span>This new version add=
resses most (or all) requests made in PR:</span><div><br></div><div><span>.=
 Implements the new scheme suggested by Ruben Somsen that allows multiple s=
ilent addresses per wallet with minimal overhead.</span></div><div><span>. =
Implements a new RPC to retrieve silent addresses, which allows users to as=
sign different labels to different addresses. That way, the user knows whic=
h silent address the UTXO came from.</span></div><div><br></div><div><span>=
Example:</span></div><div><br></div><div><span>./src/bitcoin-cli -signet -r=
pcwallet=3D&quot;receiver&quot; getspaddress</span></div><div><span>tsp001p=
jgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq</span></div><div=
><br></div><div><span># This will return the same address as above (both ha=
ve no label)</span></div><div><span>./src/bitcoin-cli -signet -rpcwallet=3D=
&quot;receiver&quot; getspaddress</span></div><div><span>tsp001pjgcwd9p6f2r=
cgf35dlgvj77h2afylg6lp5cdn0cztrk4k54w99kqxn48tq</span></div><div><br></div>=
<div><span># New label, new address</span></div><div><span>./src/bitcoin-cl=
i -signet -rpcwallet=3D&quot;receiver&quot; getspaddress &#39;donation&#39;=
</span></div><div><span>tsp011pjgcwd9p6f2rcgf35dlgvj77h2afylg6lp5cdn0cztrk4=
k54w99kq80t7lt </span></div><div><br></div><div><span>In this new scheme, t=
he address has a new field called identifier, which tells the receiver and =
sender how to set the address correctly.</span></div><div><br></div><div><s=
pan>If the receiver, for whatever reason, doesn&#39;t know which identifier=
s have been used, there is no problem. The wallet can scan all identifiers =
from 0 to 99. Currently, only 100 different identifiers per wallet are allo=
wed. This limit, however, can be increased at any time in the future.</span=
></div><div><br></div><div><span>Unlike address formats so far, sp addresse=
s are not script-related and may eventually include any additional informat=
ion needed, such as an expiration timestamp (or block height). That way, us=
ers don&#39;t have to track the address indefinitely.</span></div><div><br>=
</div><div><span>As usual I wrote a step by step tutorial:</span></div><div=
><span><a rel=3D"noreferrer nofollow noopener" href=3D"https://gist.github.=
com/w0xlt/c81277ae8677b6c0d3dd073893210875" target=3D"_blank">https://gist.=
github.com/w0xlt/c81277ae8677b6c0d3dd073893210875</a></span></div><span></s=
pan><br></div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--00000000000076231f05ea29e1af--