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

[Brandon Black <freedom@reardencode.com>]

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