Profile: 59909c5a...
📅 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>
📅 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
or
<2 years> OP_CLTV
Best,
--Brandon