Nostr Web Client

🔖 Title: BIP-352 Silent Payments addresses should have an expiration time

🏷️ Categories: bitcoin-dev

nostr:naddr1qqjxxdf4xuunsden94nrvvph956xzvfn943rjvtp94jrxcmpx5erwce3vyensqg5waehxw309aex2mrp0yhxgctdw4eju6t0qy2hwumn8ghj7etyv4hzumn0wd68ytnvv9hxgqguwaehxw309ahx7um5wghx6at5d9h8jampd3kx2apwvdhk6q3q2llycjh8gg2lhy4aph9c5au8ch5s0km5axrlxrc6e24dnsaqyu0sxpqqqp65wvn4pzs

⚠️ Heads up! We've now started linking to replaceable long-form events (NIP-23), which allow for dynamic display of thread details like summaries, authors, and more. If you're unable to see this, your client may not support this feature yet.

Reply to this note

Please Login to reply.

Discussion

daa2fc67... 2y ago

📅 Original date posted:2023-08-04

🗒️ Summary of this message: Silent Payment addresses, which allow for multiple payments without privacy concerns, should have an expiration date to prevent funds from being lost forever. Adding a 3-byte field to encode the expiration date is a simple solution. Wallets should have a default expiration date and attempts to pay an expired address should fail.

📝 Original message:

tl;dr: Wallets don't last forever. They are often compromised or lost. When

this happens, the addresses generated from those wallets become a form of toxic

data: funds sent to those addresses can be easily lost forever.

All Bitcoin addresses have this problem. But at least existing Bitcoin

addresses aren't supposed to be reused. Silent Payments are: the whole point is

to have a single address that you can safely pay to multiple times, without

privacy concerns. Failing to make Silent Payment addresses eventually expire in

a reasonable amount of time is thus a particularly harmful mistake.

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.

Wallets should pick a reasonable default, eg 1 year, for newly created

addresses. Attempts to pay an expired address should just fail with a simple

"address expired". Lightning invoices are a good example here: while invoices

does not require expiration from a technical point of view, they do expire for

similar UX reasons as applies to silent payments.

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/20230804/70c37a09/attachment.sig>

59909c5a... 2y ago

📅 Original date posted:2023-08-04

🗒️ Summary of this message: Adding a field to silent payment addresses to encode expiration dates in terms of days after an epoch can fix the risk of non-expiring addresses in Bitcoin. Custom compact encoding can be used for different levels of granularity.

📝 Original message:

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 OP_VAULT_RECOVER

<2 years> OP_CLTV OP_CHECKSIG

Best,

--Brandon

daa2fc67... 2y ago

📅 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>

daa2fc67... 2y ago

📅 Original date posted:2023-08-05

🗒️ Summary of this message: Samson Mow questions the 180-year limit for planning, suggesting a longer timeframe, and provides examples of historical inventions.

📝 Original message:

On Fri, Aug 04, 2023 at 11:41:39AM -0700, Samson Mow wrote:

> Why the 180 year limit? imho should plan for longer.

You know, it was only 137 years ago that the first practical electric motor was

invented; 143 years ago that the first practical light bulb was invented.

180 years is a long time.

But if that seems too short, as I said, 3 bytes is sufficient for 45,934 years.

The invention of agriculture is only 12,000 years old. Although I guess as a

toxic bitcoin carnivore you care more about the invention of the bow and arrow,

70,000 years ago.

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/e99335b2/attachment.sig>