Feedback-ID: i525146e8:Fastmail
Date: Sat, 5 Aug 2023 14:06:10 +0000
From: Peter Todd <pete@petertodd.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZM5XUlqymce3xsFy@petertodd.org>
References: <ZM03twumu88V2NFH@petertodd.org>
 <ZM17RTXV7M5tVt6N@console>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="OCNLvmm47FThI7YQ"
Content-Disposition: inline
In-Reply-To: <ZM17RTXV7M5tVt6N@console>
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an
 expiration time
Precedence: list


--OCNLvmm47FThI7YQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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, e=
ncoding
> > 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 day=
s is 180
> > years. We'll be lucky if Bitcoin still exists in 180 years.
>=20
> 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.
>=20
> 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         | ???         | ???
>=20
> 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 granular=
ity,
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 t=
he
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 fr=
om
now - if silent payments still exists - people will still want to create si=
lent
payment addresses that expire, say, 30 days in the future. Your suggestion =
does
not allow that.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--OCNLvmm47FThI7YQ
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmTOV04ACgkQLly11TVR
LzdGgBAAtYLexccxchGn+m9IFUzgwEuzqE3z2PKKDfctvrFxv14FCjMCj3Lyp79Q
eh6KxGZsiYteBw+U+9MYMBeemaep8vZtULBw665URcBsALeu87uroPmOmE3fEvXk
8PcyxEgZ8SYxivx63QS4zbXbqGBZe8eqBQzE3SFB+Y7nzWVIvBH/yO9JKjxrzQZo
4AYL/QGyCL0E+paD+dCr5aEVJJjR5kDAygCZLwNeTCzABomh4GRSHLqgaTTbjmUc
VPLeu196aps6tDvTtYcL7ylSBs1SQJfEWvrD/oXibupWHKF7+GXtTrRYq6xRx2Xb
5+IqG1ZCc2ArS88kOa7lUrNZQLeiAPDQSjht0mm5hgUCGBcrd6UE/oOr0FAzuvbJ
F2FQ2bQvs644EQ2OwZlmCPbgq9XFpX5Ewr3IBnlQoUFnAWQKFwJh8EaL6OoQySaC
abDG0MHT21FZbHqnuThT5aGnzfFtjGD2PPU9s2o2OIY7tALRS3XX3vXi+wZOqe0z
ViMnm5cJS6e4udtrqwfxrH7ouBirWIM1fIEZiLoyTGbSSWY17WAvMRCcm4Dmaf7B
8DHQ4uAzyl0q5jeIWi1OfCBJ+rCWqvHoDNE/LFvBt92LXqqgISvrsZGHMUfmcph7
5a4h9XvR9OBWq+uaNrjtil0fS1V6DYcjFLICwu2i1IAnZ3YDoVI=
=KkVP
-----END PGP SIGNATURE-----

--OCNLvmm47FThI7YQ--