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