Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time

[Dan Gould <d@ngould.dev>]

Address expiration does seem to be a generic problem, but Silent Payments could 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 way to communicate that to sending software. BTCPay checkout page includes a 15 minute countdown by default. Payments made to a checkout after the expiration are saved in an error state for the BTCPay operator and customer to triage.

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

BIP 21 specifies that parameters starting `req-` are considered required. URIs containing unknown `req-` parameters are considered invalid and the parameter can still be shown in UI. Support for `req-exp=` could thus be implemented 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 request payments using BIP 21 URI and `req-exp=` to begin to solve this problem in general. Wallets supporting Silent Payments & `req-exp=` could then apply expiration to older address types too.

Dan

> On Aug 6, 2023, at 10:28 AM, bitcoin-dev-request@lists.linuxfoundation.org wrote:
> 
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
> 
> 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
> 
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
> 
> 
> Today's Topics:
> 
>   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)
> 
> 
> ----------------------------------------------------------------------
> 
> 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="utf-8"
> 
> Why the 180 year limit? imho should plan for longer.
> 
> On Fri, Aug 4, 2023 at 10:41?AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> tl;dr: Wallets don't last forever. They are often compromised or lost. When
>> this happens, the addresses generated from those wallets become a form of
>> 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
>> point is
>> to have a single address that you can safely pay to multiple times, without
>> privacy concerns. Failing to make Silent Payment addresses eventually
>> expire 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,
>> encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,000
>> 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
>> simple
>> "address expired". Lightning invoices are a good example here: while
>> invoices
>> does not require expiration from a technical point of view, they do expire
>> 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
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/fc013648/attachment.html>
> 
> ------------------------------
> 
> 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=us-ascii
> 
> 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         | ???         | ???
>> 
>> 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 granularity,
>> 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.
> 
> 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.
> 
> 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.
> 
>> 2) Your suggestion would result in a protocol that degrades over time, as the
>> granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
>> 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 suggestion does
>> not allow that.
> 
> 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.
> 
> 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.
> 
> Best,
> 
> --Brandon
> 
> 
> ------------------------------
> 
> 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:
> <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
> 
> 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 own 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 would 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 think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
> 
> 1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update 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 several 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 retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.
> 5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.
> 6. By updating his address, Bob is leaking metadata about himself, potentially 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 solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside 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 address expiration date.
> 
> Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send 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).
> 
> 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 solution, 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 <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
>> tl;dr: Wallets don't last forever. They are often compromised or lost. When
>> this happens, the addresses generated from those wallets become a form of 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 point is
>> to have a single address that you can safely pay to multiple times, without
>> privacy concerns. Failing to make Silent Payment addresses eventually expire 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, encoding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,000
>> 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 simple
>> "address expired". Lightning invoices are a good example here: while invoices
>> does not require expiration from a technical point of view, they do expire 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
> -------------- 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>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> 
> ------------------------------
> 
> End of bitcoin-dev Digest, Vol 99, Issue 15
> *******************************************