From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0F61FC0032 for ; Sun, 6 Aug 2023 14:27:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id D62E2408CA for ; Sun, 6 Aug 2023 14:27:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org D62E2408CA Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=Kb0g47y9 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 f3lzYRRprhhc for ; Sun, 6 Aug 2023 14:27:54 +0000 (UTC) X-Greylist: delayed 448 seconds by postgrey-1.37 at util1.osuosl.org; Sun, 06 Aug 2023 14:27:54 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 4BAA3409A5 Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by smtp4.osuosl.org (Postfix) with ESMTPS id 4BAA3409A5 for ; Sun, 6 Aug 2023 14:27:54 +0000 (UTC) Date: Sun, 06 Aug 2023 14:20:06 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.b="Kb0g47y9" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1691331624; x=1691590824; bh=KkOcn6RnMxHnKWmiyeLjGqJiySsmq/Q3249fjeQ5CMI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Kb0g47y9A1UYn0IiHtrxsyWT60EELSoSBl3Oh6kZKKsuv7ti2gOHyBPcEGtNrw2r7 mENP4KcOdo/lYifLIU8ZBHFjJDsvaarcZr4KIKKPgzE5mWpWOr5MtkdyWtX7Hu6HSR noEPN3wt5GpkAH98gGMsxxQ/dYdSa75aMO7hzy2ybgeGXUpWoYaiS1OeBgmqtfpk47 bteZwik4U7qD79DjdPsqwUZfWRiehNEl71Glm7ITQkWuRMetBxCbbkH7miqoYKg8OQ f+6S1XzJUOFOs/+fq0tXGVeKY8I0D6oZHDkEmigUmNHVDdmr9wV0B2znNGX08t8Dm1 me5PCiK2A8UBQ== To: Peter Todd From: josibake Message-ID: In-Reply-To: References: 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 X-Mailman-Approved-At: Sun, 06 Aug 2023 14:28:42 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2023 14:27:56 -0000 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 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--