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. I included block-based expiration to enable SP users to match CLTVs embedded in their scripts, e.g. <2 years> OP_CLTV <recovery_path> OP_VAULT_RECOVER or <2 years> OP_CLTV <backup_key> OP_CHECKSIG Best, --Brandon _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
