Date: Sun, 06 Aug 2023 14:20:06 +0000
To: Peter Todd <pete@petertodd.org>
From: josibake <josibake@protonmail.com>
Message-ID: <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
In-Reply-To: <ZM03twumu88V2NFH@petertodd.org>
References: <ZM03twumu88V2NFH@petertodd.org>
Feedback-ID: 27113594:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha256;
 boundary="------cc64988d2142f40237946b9dfec55efdeabea69e8ba9947802a35caa13c5c0fd";
 charset=utf-8
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an
	expiration time
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------cc64988d2142f40237946b9dfec55efdeabea69e8ba9947802a35caa13c5c0fd
Content-Type: multipart/mixed;boundary=---------------------2828a6b2e8619b8377a3ce545edd6e91

-----------------------2828a6b2e8619b8377a3ce545edd6e91
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hi Peter,

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 o=
wn BIP and be a standard that can work for xpubs, static payment codes, as=
 well as existing and future address formats. If that were to happen, it w=
ould be easy enough to add this expiration standard to silent payments as =
a new silent payments address version.

That being said, I'm a bit skeptical in general of expiration dates and th=
ink that they weaken the value proposition of silent payments while not ac=
tually solving the problems you described. Consider the following scenario=
s:

1. Bob's wallet is compromised with a one-year expiry and for the next yea=
r, 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 severa=
l 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 retain=
s 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 sender=
s 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, potenti=
ally compromising his safety.

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 r=
evoke his silent payment address. For this, I think building a wallet prot=
ocol on top of silent payments is a better path to explore. Additionally, =
expiration dates as proposed degrade the privacy of silent payments: any o=
utside observer can conclude that all transactions mined at block height N=
 or greater 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=
 concerns with the user needing to regularly update their silent payment a=
ddress expiration date.

Lastly, on the subject of expiration dates in general, your proposed solut=
ion 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 t=
o be useful, I'd argue they need to be enforced by consensus (which I am n=
ot convinced is a good idea).

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 =
payments version, but even then, I'm still not convinced expiration dates =
for static payment codes is a good idea, for the reasons I mentioned above=
.

Cheers,
Josie


Sent with Proton Mail secure email.

------- Original Message -------
On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org> wrote:


> 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.
> =


> 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.
> =


> 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.
> =


> 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.
> =


> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-----------------------2828a6b2e8619b8377a3ce545edd6e91
Content-Type: application/pgp-keys; filename="publickey - josibake@protonmail.com - 0x616516B8.asc"; name="publickey - josibake@protonmail.com - 0x616516B8.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - josibake@protonmail.com - 0x616516B8.asc"; name="publickey - josibake@protonmail.com - 0x616516B8.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4c0ZOQkdETWFRSUJFQURhRjhO
dUdMdG5NSDF5WUNUUnlXa0tscWFnczlqUGcyV3R4Q3BmUVBjRlNvMXUKczh0ZmN3SjdRL2xtZ2Ev
MEg4WnJNQVNwNEY4VkJ6d0lLY2Y4RTBTdTBxSEQwVHRDVHdReGlZM1hvM1paCmkvcU05TGZxQ3ZK
SHdtamdWc2JIOHJwRmVwSndYeFY2cG5vZ1hFUkRwOHVCSG5NNUlON0VhUG9rQXF6cApXcER1d2F4
VE9MVWNwYTd3aDg0em1xdEFpV0tMczhmYkE4TnM2WlJXRjYxVlZMbm9FU0VFSGtOYjVucDkKWW42
RnRxUXVGcUR1Wi9DeUwyMG4rc0VpaHRzYmlCYkxsS00zRHBIRzIxbWNXenRreXh3VVJzV1RvdGpo
CjhjUm82eU1nVTAwYnpXQlNCek01bWlqaGxWdXhvbjhVdzRuZWs3eHZBWmFvU3duVmJIYkV5eHhU
TWdMbwpadW1OV2pERkc0RGZiRHBuemtrVzY3a1A5bWxCcEpTWHJZRUFJRnFCQW9ZZlNRV21KWEN4
OW1DNy96cEwKeG9pU3dHR2NvT0FDTVV3dDlIOEVFRmtFOE5tUDVKUkRHcjUxYjNoZDhQTWhlK1Z6
OXJpTys3SDd0elRnCkwzcjlvSDZGNXRzNGhVdm5wdFY4cFFkR2J3OUx3aUhOd1BlWDN4SUNhR2h0
Y1FKNGJlSGNSWnZYL1QxRwoyN1p1NjBKZnhmNE5sczBybTNXK1o0S1ZxamxBWHVNc2pCZzhXeS9O
U0Z4QmMzZDhYdmljWm1WTXFRYWoKL1dhQUNRVnllbjdTU0NNeHZ4cmdNc2RYTnBOV1BackJhRVN3
RVBSczVLeGMzVVdzMXFVL0dDbHA3YndOCjNScmVYalJDLzYybmRuQUVUNmRicFVlNGdvSVoxMVh0
TnhrQjNRQVJBUUFCelRGcWIzTnBZbUZyWlVCdwpjbTkwYjI1dFlXbHNMbU52YlNBOGFtOXphV0po
YTJWQWNISnZkRzl1YldGcGJDNWpiMjArd3NHTkJCQUIKQ0FBZ0JRSmd6SmlaQmdzSkJ3Z0RBZ1FW
Q0FvQ0JCWUNBUUFDR1FFQ0d3TUNIZ0VBSVFrUWl0eTFXTVR6ClBXVVdJUVJoWlJhNDYyN1FLSUw4
U25xSzNMVll4UE05WlZjd0QvOTlJQitsL29FUHA0ZkcwcWRURERPTQovaUhuZENmSXFmOXVaZ3pT
NnQyTGMzUWY3Qlk2ZDlrTytJbzhoQzI5dGpGZFd4TFlrWVdHWkZMSUVRcWoKQndCSjZ4Umtmclpu
YjJROFpRdk11Nk9sV1RtYTBoSnB5OXVaV1BMeXczTTZVMnRpdjRPMFlvM3U2RVVLCnJOQjJpclpq
eHc5MlVHbW5JSHlXOFhkT1c2cjdXSFZpUXUyVGU4VWJYZUZzMWphMGJIZVJNbjlhNStMaQpoZ1Zt
NXAvdVpSMW5abG51cWkwcVlySGhmUEZoUE9UQWdMZUNrdHRBS0NyRFpNYWw5WU5heHBkTzFRZG0K
Uk02UGYwclRBcW1QTkEzZG9iSDZiZ0M2WXgwZjhtRnpOR2pvaTByZ3FNbEJ3UDNqR0gxOVVZNExu
amV1Cjdtakllb1dDSVh2c3RQSkVnWlZxall6QjBJdWhZUFU4RHZZaVNwejdrWWFVMlphL0ZIUlRt
MlB5NUhiYQo2NlFGMTZpR1FQaXNXT2JtcHpQK0pLWnFqd0k4VXRCeVU4S09Lb21NZllFZVVNUDdl
MHJQNUJSWEo1N0UKZm5NUlBkNUR2dFRWdzQrQUt1TzdjbEc0bHRubVl4dHVQTUkwWWRIYm12UWFz
Nmthc2pxTG15ZUZNa1NtCjdEMHhwS0R5SytjYWJPaFNSczlmcUpvUFV6NENHeU9XeXZrYVhiRkpl
eExyOVpiU1Q5VGdjN0xEN00xRApia0VrSy9SNzlZVk9uamVaT29zOE5YRDNrRjZ5c1gvUzkzKzlu
VnFLclFROUt2UDkrNGIrdlFsRXZTNnIKY29ldElLZEY2bmxRU25iVHFvSG5Ed0xTdUhsSGZWZjND
T1N2NHRXN0JBd28yNk5lU1JmeUZEQm5RUzVpCkpNN0JUUVJnekdrQ0FSQUE2Z0FZQ21lWjFuVktX
OUgvVDBDMkhNWGMwRE1zbTNacUN6MVF2dDRXV0NYVApJNitXbzRvUlZLUXRwdDR3aU91Z25TT0U4
cTMzSzRTS3Y5QW5JWjJaenJVT3p2RGU5Yk1mcDhZVnYvUGUKbkFXbS9acHNJaysyV3dZc1FsdzNC
aE9CV0NYMXlhUko2bVlWZHNJS3dDMW5xS1laT1AxcW0rSGRUWUFJCk1LdkE2WjcxR3N6elI3akNh
Z05ObGdlU3N2cFpYUzcrSUROWlNGUXJyNHYrR1M3d0Vqd1A1REVUaHB0UQp1djA2TzBNNVMxT3ZH
OStBQjhITHhZVkFBb3FFS25VNjZZZmtJaWhzT1hpWHJScXJSUm8ydFg5MDVPNksKc0E1N0hUT3JN
NlgvQVVLWmhZNDVuVjVWcGQxc3BXOHFyS3NRQnM0NXYyREZuQmkvSmsrWm1Yak1FZENlCkN3MDlz
WUlJM1JISnh1V25paW9tbFArU3F1dHVCbWNCdXY3ZW9ONVU3T0Y0S2lPcGJHMlk2ZS9zczV5TApk
SzJPcnVHeFdUZWNVUDRPL1ZaL09lNUFWR0xTZ1JSTFcrb0lTSUhySE0xcWZFN0RrMWpUTWJoQUdh
VlkKUmM2azV3YmxvcXIzQlgzQ0hUUkl0dTlJZUVHUTVGTng5NVNmL3REUUVOSGhPK0wyZkkxdC9L
TlJsSUUxCjZEcHdEeTV3MCtJWmptbWEvOHI2cHBPaUJiSVNrbW1FTFRxQURSTzBhR0t3b21BTXRv
Nk5WdCtZVTNZZwpWU09DTUcvRExhMzBORU5lQ1luUllQcmNCUnNxcUF3Q0ZWR2pBcUcrQUplTDRJ
OUNkZUh3U1RaVnpFOWUKN2Z5U3U0YXR4NDVaQ1I4MWFsUCtIWVh3eXhkckdkakZJZVZNRk1NQUVR
RUFBY0xCZGdRWUFRZ0FDUVVDCllNeVltUUliREFBaENSQ0szTFZZeFBNOVpSWWhCR0ZsRnJqcmJ0
QW9ndnhLZW9yY3RWakU4ejFsUkxNUAovUmJtOHUrTWhoZHRTQ21DMUppdWgzOTk3VnIrN1N1ck1v
OXQ4TlVpQVdobitoejlPVGgzdFdHbzc3N1EKSVBGc21GcnNWa0pjVnhHdjZvS01NVFZpR05tOUsw
NGVORmRLa3NDUUluNFJMTzl1WHAyS21VUkt6cFNyCklJVUFOVExXZ1ZZa3VjMVB1d1VaMW4yTjl3
UzQ5WHRtRXNIMWpjR0FpZTVXM2FvSGR0dWZMOWJ1cDYxVgo1UHRFUlVMZldYT3g1UXRiRTNidTdx
S1VMa0wrTXYwQ1dsazgrR05rVGNWSGVkUU1JQ3ZyNlhBU0lYUTcKZTFINTdUNk1IanozTjQ2bFNs
ZnNTS0RraGUrYkNkQmxaeEdBN3FSS3A0T3VsYWp5SzJSTW93WnRobnpiCk9RZXptdkE1bkVrRjB3
blZBMld5VWVJamhua2c5TmtkWllTcFpTMmtib3RNbjJhYUFOSWEzaVV1ZU1WWApYbmNacStEWkgr
bzlLRVRJaTg2eHRBZzFmKzNMb2k5WDFNazRqeXd3QXRSSkg5amZ5c0p0bEJsaXU1MGgKZ1Rkbnpa
QlpodGdKaE8xYVVoZlVGL2V3elpWc0cxZ2Zsb0lRTVVHT0dBNWV0QkxuTnZMbzNVRXNnaWQyCk5P
Z2dVeEl1T2RrV0ZET1FncHNsVE9BNkxjdE1LWGtoMFYrZ3YvQlh5MmEreTlzL1VhRzBUcEJUVzdq
QQpwZy9YYmF3cUpNQUZ5VTY5WVZvYXJiejFMMmdIUWVxeEhwZVdZb0FGWWkrZW93L2lzbjRlMy9Q
cnlVekkKQTd5dHFvcnk1a0YzZnBwZXZtZHZ3czlhTnZaRThuMVJIWFFUdG9Ta2F5Tk15bXIzUy9t
UkFDeHVxK1YzCjkwczFVYjlvQ1dSYnB0ZEFwRlRlajVISQo9SFFlaAotLS0tLUVORCBQR1AgUFVC
TElDIEtFWSBCTE9DSy0tLS0tCg==
-----------------------2828a6b2e8619b8377a3ce545edd6e91--

--------cc64988d2142f40237946b9dfec55efdeabea69e8ba9947802a35caa13c5c0fd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsFzBAEBCAAnBYJkz6wFCZCK3LVYxPM9ZRYhBGFlFrjrbtAogvxKeorctVjE
8z1lAABVIg/+OtUi0+651O8K1APtsVTO0aJjOSauFN2k5bDlVKteb4onQkVS
bvK0wRk75lhQj4uWzRfAIYHUd9VQNhfiaS4FJpVzyJe89CrXgmdi+c5/1OCv
z+CTYQgoLTdAcdXCHGAyN4H0VOd37tbZRlBrAOQ7gpnxF8qqmUEU6D2hH+UK
FPZxDE6Ot5On0qeoTTCrkCQyaNiQacWHNC0EgoSWSKO5ebmaR10qz/W8fyvv
DNG4wvtJLA2Q9ytmAKgQnvsupDLtCj7sVyeL/FMoD1k4seOMxfaLMOlv539M
MJdWhUFeP+4ZsAiDv5ui5WBdpOsAa5H23jQhcqEAUEVtCBKLuBaeWnQ2d1/G
S3nWnagvrmfTx2Pl3IiYKZoQg1rrerZY9p+mvynMR4tqSDMkIilCAkMztsj/
CIUJv7n+tUMyZAFV55bY/+viRGwxu0rpa0/V+Fo6sMepRZnloLPsehs/JPLU
VVnA4eVBISj31kEj036JvTcPnHC+dg2+kN8LuSPui9kaTHp+V9FN1iouR8Cs
5LPzCz1awDAQsYRxSM7OoZ1LIAF5bcmRPA0vY0w7SOW74W8NvsnUKgM+t9d6
4xaFheSsv3CF8iO+QaYnY7UhjNyEmkaeFi2/hACtPddv0SamimAtVM8F7RTY
evzEjwyigYEKfV7/hiTkDMHE51ym29s9mDo=
=vT2Z
-----END PGP SIGNATURE-----


--------cc64988d2142f40237946b9dfec55efdeabea69e8ba9947802a35caa13c5c0fd--