Brandon Black [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-05 🗒️ Summary of this message: The proposal ...

📅 Original date posted:2023-08-05
🗒️ Summary of this message: The proposal suggests using different byte lengths to encode expiration times in Bitcoin addresses, with varying granularities. The author argues against a fixed granularity and explains the potential degradation over time.
📝 Original message:
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