š
Original date posted:2023-08-05
šļø Summary of this message: Adding a field to silent payment addresses to encode expiration dates is suggested, with different byte lengths for different granularities.
š Original message:
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230805/82374bb3/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-08-05 21:58:15
in reply to nevent1qā¦0a8w
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-08-05 21:58:15Event JSON
{
"id": "12389a5eab1966beb360d9c90e5d03d253d73c75e6bb03f9332154ada22ce1b8",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1691272695,
"kind": 1,
"tags": [
[
"e",
"c08d8bfe5e8ab2894e9fbdb020ab2bbb281ca98857e700a8e90822dc365f2c84",
"",
"root"
],
[
"e",
"bc85afc91e19be7059df00180a6e16d32080bf6975ef33b7e3b79e202c0688de",
"",
"reply"
],
[
"p",
"59909c5ada0189425f58f43a87eeb09131d41d33298de94a994852fa43c25afd"
]
],
"content": "š
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",
"sig": "b167bad4755a475245e4eb8c6fc6695501be76fb52a6a1e8800993263fe4334da82fe02538252b2714b0501e9a4e84e6d691f4e36f55b579d40e79b687a886aa"
}