summaryrefslogtreecommitdiff
path: root/28/7cfd8efec43ceb397f5f4dbcf17260cfac921b
blob: fa492579648d7518b35271cc7b804aec8b74442e (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
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
Return-Path: <d@ngould.dev>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 54709C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Aug 2023 21:06:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 25F4640900
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Aug 2023 21:06:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 25F4640900
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev
 header.a=rsa-sha256 header.s=protonmail header.b=nJB+6jMl
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id n5Tc3LzYROFz
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Aug 2023 21:06:05 +0000 (UTC)
Received: from mail-41103.protonmail.ch (mail-41103.protonmail.ch
 [185.70.41.103])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 59E394093C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  8 Aug 2023 21:06:05 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 59E394093C
Date: Tue, 08 Aug 2023 21:05:43 +0000
Authentication-Results: mail-41103.protonmail.ch;
 dkim=pass (1024-bit key) header.d=ngould.dev header.i=@ngould.dev
 header.b="nJB+6jMl"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ngould.dev;
 s=protonmail; t=1691528752; x=1691787952;
 bh=WXza1rPEBUReN+HWw3pe0cmnM8Pk7J21iHXCwj+5vR8=;
 h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=nJB+6jMl1pDMOTirC/ywk3xLj3ILv6LuI7BPk9zX1d5Gw3g3wP048Nmhts5CO+P8E
 pfWpwE860tdBmZqkO5HHxzXT/YvHSxF34x9fXo7fF2tlrP8z0eNCFUMXcmj+KBgmWV
 xVNBzd6HdAEW9xvnqxAMg2pEKVqo2n5UgsyMwvpM=
To: bitcoin-dev@lists.linuxfoundation.org
From: Dan Gould <d@ngould.dev>
Message-ID: <D9DABB64-2277-43B2-8C37-CBFFF674C8A5@ngould.dev>
In-Reply-To: <mailman.128723.1691332123.956.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.128723.1691332123.956.bitcoin-dev@lists.linuxfoundation.org>
Feedback-ID: 13175031:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 09 Aug 2023 03:37:25 +0000
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an
	expiration time
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: Tue, 08 Aug 2023 21:06:09 -0000

Address expiration does seem to be a generic problem, but Silent Payments c=
ould play a role in solving the problem once and for all. Payment requests =
often have expiration in practice because of moving exchange rates but no w=
ay to communicate that to sending software. BTCPay checkout page includes a=
 15 minute countdown by default. Payments made to a checkout after the expi=
ration are saved in an error state for the BTCPay operator and customer to =
triage.

Since enforcing expiration by consensus sounds unpopular, one generic way t=
o enforce it at the application layer would be to use a new BIP 21 URI para=
meter `req-exp=3D`.

BIP 21 specifies that parameters starting `req-` are considered required. U=
RIs containing unknown `req-` parameters are considered invalid and the par=
ameter can still be shown in UI. Support for `req-exp=3D` could thus be imp=
lemented in BIP 21 libraries rather than for each address type, and without=
 necessarily supporting Silent Payments.

New address specifications like Silent Payments could recommend wallets req=
uest payments using BIP 21 URI and `req-exp=3D` to begin to solve this prob=
lem in general. Wallets supporting Silent Payments & `req-exp=3D` could the=
n apply expiration to older address types too.

Dan

> On Aug 6, 2023, at 10:28 AM, bitcoin-dev-request@lists.linuxfoundation.or=
g wrote:
>=20
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>=20
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>=20
>=20
> Today's Topics:
>=20
>   1. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (Samson Mow)
>   2. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (Brandon Black)
>   3. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (josibake)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Fri, 4 Aug 2023 11:41:39 -0700
> From: Samson Mow <samson.mow@gmail.com>
> To: Peter Todd <pete@petertodd.org>,  Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <CAAWeQ5fRi3AiZpSm4riyrNyCRphi5dSE6tFpkaGeQCY3x4keng@mail.gmail.com>
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> Why the 180 year limit? imho should plan for longer.
>=20
> On Fri, Aug 4, 2023 at 10:41?AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>> tl;dr: Wallets don't last forever. They are often compromised or lost. W=
hen
>> this happens, the addresses generated from those wallets become a form o=
f
>> toxic
>> data: funds sent to those addresses can be easily lost forever.
>>=20
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole
>> point is
>> to have a single address that you can safely pay to multiple times, with=
out
>> privacy concerns. Failing to make Silent Payment addresses eventually
>> expire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>>=20
>> Fixing this is easy: add a 3 byte field to silent payments addresses,
>> encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,0=
00
>> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days
>> is 180
>> years. We'll be lucky if Bitcoin still exists in 180 years.
>>=20
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a
>> simple
>> "address expired". Lightning invoices are a good example here: while
>> invoices
>> does not require expiration from a technical point of view, they do expi=
re
>> for
>> similar UX reasons as applies to silent payments.
>>=20
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20230804/fc013648/attachment.html>
>=20
> ------------------------------
>=20
> Message: 2
> Date: Sat, 5 Aug 2023 07:46:52 -0700
> From: Brandon Black <freedom@reardencode.com>
> To: Peter Todd <pete@petertodd.org>, Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID: <ZM5g3Fi_vErCeEx0@console>
> Content-Type: text/plain; charset=3Dus-ascii
>=20
> On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:
>>> bytes | prefix     | usable bits | granularity | max expiration
>>> ------|------------|-------------|-------------|---------------
>>> 1     | 0b0        |   7         | year        | 128 years
>>> 2     | 0b10       |  14         | week        | 315 years
>>> 3     | 0b110      |  21         | day         | 5700 years
>>> 4     | 0b1110     |  28         | block       | 5100 years
>>> 5     | 0b11110    |  35         | ???         | ???
>>> 6     | 0b111110   |  42         | ???         | ???
>>> 7     | 0b1111110  |  49         | ???         | ???
>>> 8     | 0b11111110 |  56         | ???         | ???
>>=20
>> 1) Having the granularity of the limit depend on *when* the limit is to =
be
>> applied in a UX nightmare. It is far simpler to just pick a useful granu=
larity,
>> and include enough bytes of integer to work until well into the future. =
3
>> bytes, 24-bits, of days is 45,000 years. That's plenty.
>=20
> I must not have explained my proposal clearly. The granularity depends
> not on when it is applied, but on the encoding. For example, the bits
> 0b00000001 encode an expiration 1-year from the epoch of the system. The
> bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.
>=20
> When decoding, the position of the highest `0` bit in the expiration
> indicates the byte-length, and the granularity. If the expiration's
> highest bit is `0`, it is 1-byte long, and the bits following the
> highest `0` encode a number of years. If the first `0` bit is in the
> second highest position, then it is 2-bytes long and the bits following
> the highest 0 encode a number of weeks. &c.
>=20
>> 2) Your suggestion would result in a protocol that degrades over time, a=
s the
>> granularity of *newly* created addresses goes up. This isn't like CTV/CL=
TV,
>> where we're creating something now with a limit in the future. 100 years=
 from
>> now - if silent payments still exists - people will still want to create=
 silent
>> payment addresses that expire, say, 30 days in the future. Your suggesti=
on does
>> not allow that.
>=20
> My suggestion does degrade over time in one sense: if it is still in use
> 128 years in the future, users are required to start using at least 2
> bytes to encode their expiration instead of 1, even if they only need
> year granularity. After 315 years they have to start using at least 3
> bytes even if they only need week granularity.
>=20
> I'd rather enable users to encode their expirations in 1 or 2 bytes
> today and degrade by requiring more bytes than require 3 bytes now.
>=20
> Best,
>=20
> --Brandon
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Sun, 06 Aug 2023 14:20:06 +0000
> From: josibake <josibake@protonmail.com>
> To: Peter Todd <pete@petertodd.org>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MN=
SpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=3D@protonmail.com>
>=20
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> Hi Peter,
>=20
> Thanks for the feedback! As you mentioned, this is a more general problem=
 in Bitcoin and not specific to BIP352. Therefore, if expiration dates are =
indeed something we want, they should be proposed and discussed as their ow=
n BIP and be a standard that can work for xpubs, static payment codes, as w=
ell as existing and future address formats. If that were to happen, it woul=
d be easy enough to add this expiration standard to silent payments as a ne=
w silent payments address version.
>=20
> That being said, I'm a bit skeptical in general of expiration dates and t=
hink that they weaken the value proposition of silent payments while not ac=
tually solving the problems you described. Consider the following scenarios=
:
>=20
> 1. Bob's wallet is compromised with a one-year expiry and for the next ye=
ar, funds are sent to the attacker. The attacker may have the ability to up=
date the expiration, and thus be able to keep receiving funds as Bob.
> 2. Bob loses his keys with a one-year expiry but finds them again 3 years=
 later. The expiration causes Bob to miss out on 2 years worth of potential=
 payments.
> 3. Bob dies with a one-year expiry but an heir inherits his backups sever=
al years down the road. The expiration date causes the heir to miss out on =
several years worth of potential payments.
> 4. Bob is prevented from updating his address for several years but retai=
ns access to his keys/backups. The expiration date causes Bob to miss out o=
n several years worth of potential payments.
> 5. Bob regularly updates his address with a new expiry, but not all sende=
rs are able to find the new, updated address causing Bob to miss out on pot=
ential payments.
> 6. By updating his address, Bob is leaking metadata about himself, potent=
ially compromising his safety.
>=20
> You could argue that none of the scenarios above would be an issue if Bob=
 just sets a very long expiry, but then the expiry doesn't really help in s=
olving the issues you mentioned. What we really want is a way for Bob to re=
voke his silent payment address. For this, I think building a wallet protoc=
ol on top of silent payments is a better path to explore. Additionally, exp=
iration dates as proposed degrade the privacy of silent payments: any outsi=
de observer can conclude that all transactions mined at block height N or g=
reater were not payments to any silent payment address with an expiry less =
than N. As I mentioned already, there may also be privacy and safety concer=
ns with the user needing to regularly update their silent payment address e=
xpiration date.
>=20
> Lastly, on the subject of expiration dates in general, your proposed solu=
tion is not enforceable: any wallet can just ignore the extra bytes and sen=
d to the address/xpub/static payment code, anyways. For expiration dates to=
 be useful, I'd argue they need to be enforced by consensus (which I am not=
 convinced is a good idea).
>=20
> In summary, expiration dates are a separate problem, outside the scope of=
 what BIP352 is trying to address. If we can work toward a more general sol=
ution, there is nothing preventing us from adding this to a future silent p=
ayments version, but even then, I'm still not convinced expiration dates fo=
r static payment codes is a good idea, for the reasons I mentioned above.
>=20
> Cheers,
> Josie
>=20
>=20
> Sent with Proton Mail secure email.
>=20
> ------- Original Message -------
> On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:
>=20
>=20
>> tl;dr: Wallets don't last forever. They are often compromised or lost. W=
hen
>> this happens, the addresses generated from those wallets become a form o=
f toxic
>> data: funds sent to those addresses can be easily lost forever.
>>=20
>=20
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole p=
oint is
>> to have a single address that you can safely pay to multiple times, with=
out
>> privacy concerns. Failing to make Silent Payment addresses eventually ex=
pire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>>=20
>=20
>> Fixing this is easy: add a 3 byte field to silent payments addresses, en=
coding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,0=
00
>> years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days=
 is 180
>> years. We'll be lucky if Bitcoin still exists in 180 years.
>>=20
>=20
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a si=
mple
>> "address expired". Lightning invoices are a good example here: while inv=
oices
>> does not require expiration from a technical point of view, they do expi=
re for
>> similar UX reasons as applies to silent payments.
>>=20
>=20
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: publickey - josibake@protonmail.com - 0x616516B8.asc
> Type: application/pgp-keys
> Size: 3154 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20230806/edd207c8/attachment.bin>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 855 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20230806/edd207c8/attachment.sig>
>=20
> ------------------------------
>=20
> Subject: Digest Footer
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> ------------------------------
>=20
> End of bitcoin-dev Digest, Vol 99, Issue 15
> *******************************************