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: Sat, 5 Aug 2023 07:46:52 -0700 [thread overview]
Message-ID: <ZM5g3Fi_vErCeEx0@console> (raw)
In-Reply-To: <ZM5XUlqymce3xsFy@petertodd.org>
On 2023-08-05 (Sat) at 14:06:10 +0000, Peter Todd via bitcoin-dev wrote:
> > 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 | ??? | ???
>
> 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.
I must not have explained my proposal clearly. The granularity depends
not on when it is applied, but on the encoding. For example, the bits
0b00000001 encode an expiration 1-year from the epoch of the system. The
bits 0b10000000 10000000 encode an expiration 128 weeks from the epoch.
When decoding, the position of the highest `0` bit in the expiration
indicates the byte-length, and the granularity. If the expiration's
highest bit is `0`, it is 1-byte long, and the bits following the
highest `0` encode a number of years. If the first `0` bit is in the
second highest position, then it is 2-bytes long and the bits following
the highest 0 encode a number of weeks. &c.
> 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.
My suggestion does degrade over time in one sense: if it is still in use
128 years in the future, users are required to start using at least 2
bytes to encode their expiration instead of 1, even if they only need
year granularity. After 315 years they have to start using at least 3
bytes even if they only need week granularity.
I'd rather enable users to encode their expirations in 1 or 2 bytes
today and degrade by requiring more bytes than require 3 bytes now.
Best,
--Brandon
next prev parent reply other threads:[~2023-08-05 14:47 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
2023-08-05 14:06 ` Peter Todd
2023-08-05 14:46 ` Brandon Black [this message]
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=ZM5g3Fi_vErCeEx0@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