{"type":"rich","version":"1.0","title":"Peter Todd [ARCHIVE] wrote","author_name":"Peter Todd [ARCHIVE] (npub1m2…a2np2)","author_url":"https://yabu.me/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2023-08-05\n🗒️ Summary of this message: Adding a field to silent payment addresses to encode expiration dates is suggested, with different byte lengths for different granularities.\n📝 Original message:\nOn Fri, Aug 04, 2023 at 03:27:17PM -0700, Brandon Black wrote:\n\u003e I agree. Non-expiring addresses are a significant risk to bitcoin users.\n\u003e \n\u003e On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:\n\u003e \u003e Fixing this is easy: add a 3 byte field to silent payments addresses, encoding\n\u003e \u003e the expiration date in terms of days after some epoch. 2^24 days is 45,000\n\u003e \u003e years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180\n\u003e \u003e years. We'll be lucky if Bitcoin still exists in 180 years.\n\u003e \n\u003e Instead of a fixed width nDays, consider a custom compact encoding with\n\u003e the position of the first 0-bit indicating the number of extension bytes\n\u003e and the encoded granularity.\n\u003e \n\u003e bytes | prefix     | usable bits | granularity | max expiration\n\u003e ------|------------|-------------|-------------|---------------\n\u003e 1     | 0b0        |   7         | year        | 128 years\n\u003e 2     | 0b10       |  14         | week        | 315 years\n\u003e 3     | 0b110      |  21         | day         | 5700 years\n\u003e 4     | 0b1110     |  28         | block       | 5100 years\n\u003e 5     | 0b11110    |  35         | ???         | ???\n\u003e 6     | 0b111110   |  42         | ???         | ???\n\u003e 7     | 0b1111110  |  49         | ???         | ???\n\u003e 8     | 0b11111110 |  56         | ???         | ???\n\u003e \n\u003e For address expiration, year or week expiration will typically be\n\u003e sufficiently granular, but for rare occasions more granularity can be\n\u003e encoded with longer addresses. This method also degrades cleanly even if\n\u003e the same address format is still in use in 100 or 300 years.\n\n1) Having the granularity of the limit depend on *when* the limit is to be\napplied in a UX nightmare. It is far simpler to just pick a useful granularity,\nand include enough bytes of integer to work until well into the future. 3\nbytes, 24-bits, of days is 45,000 years. That's plenty.\n\n2) Your suggestion would result in a protocol that degrades over time, as the\ngranularity of *newly* created addresses goes up. This isn't like CTV/CLTV,\nwhere we're creating something now with a limit in the future. 100 years from\nnow - if silent payments still exists - people will still want to create silent\npayment addresses that expire, say, 30 days in the future. Your suggestion does\nnot allow that.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230805/82374bb3/attachment.sig\u003e"}