From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 54709C0032 for ; 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 ; 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 ; 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 ; 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 Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > To: Peter Todd , Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should > have an expiration time > Message-ID: > > 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: >=20 > ------------------------------ >=20 > Message: 2 > Date: Sat, 5 Aug 2023 07:46:52 -0700 > From: Brandon Black > To: Peter Todd , Bitcoin Protocol Discussion > > Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should > have an expiration time > Message-ID: > 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 > To: Peter Todd > Cc: bitcoin-dev@lists.linuxfoundation.org > Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should > have an expiration time > Message-ID: > >=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 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: > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 855 bytes > Desc: OpenPGP digital signature > URL: >=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 > *******************************************