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

[Peter Todd <pete@petertodd.org>]

[-- Attachment #1: Type: text/plain, Size: 2383 bytes --]

On Fri, Aug 04, 2023 at 03:27:17PM -0700, Brandon Black wrote:
> I agree. Non-expiring addresses are a significant risk to bitcoin users.
> 
> On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:
> > 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.
> 
> Instead of a fixed width nDays, consider a custom compact encoding with
> the position of the first 0-bit indicating the number of extension bytes
> and the encoded granularity.
> 
> 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         | ???         | ???
> 
> For address expiration, year or week expiration will typically be
> sufficiently granular, but for rare occasions more granularity can be
> encoded with longer addresses. This method also degrades cleanly even if
> the same address format is still in use in 100 or 300 years.

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.

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]