public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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


  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 [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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