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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
