From: Brandon Black <freedom@reardencode•com>
To: Peter Todd <pete@petertodd•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time
Date: Fri, 4 Aug 2023 15:27:17 -0700 [thread overview]
Message-ID: <ZM17RTXV7M5tVt6N@console> (raw)
In-Reply-To: <ZM03twumu88V2NFH@petertodd.org>
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
next prev parent reply other threads:[~2023-08-04 22:33 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 17:39 Peter Todd
2023-08-04 18:41 ` Samson Mow
2023-08-05 14:15 ` Peter Todd
2023-08-04 22:27 ` Brandon Black [this message]
2023-08-05 14:06 ` Peter Todd
2023-08-05 14:46 ` Brandon Black
2023-08-06 14:20 ` josibake
2023-08-10 20:58 ` Peter Todd
[not found] <mailman.128723.1691332123.956.bitcoin-dev@lists.linuxfoundation.org>
2023-08-08 21:05 ` Dan Gould
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZM17RTXV7M5tVt6N@console \
--to=freedom@reardencode$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox