Date: Tue, 08 Aug 2023 21:05:43 +0000
To: bitcoin-dev@lists.linuxfoundation.org
From: Dan Gould <d@ngould.dev>
Message-ID: <D9DABB64-2277-43B2-8C37-CBFFF674C8A5@ngould.dev>
In-Reply-To: <mailman.128723.1691332123.956.bitcoin-dev@lists.linuxfoundation.org>
References: <mailman.128723.1691332123.956.bitcoin-dev@lists.linuxfoundation.org>
Feedback-ID: 13175031:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an
	expiration time
Precedence: list

Address expiration does seem to be a generic problem, but Silent Payments c=
ould play a role in solving the problem once and for all. Payment requests =
often have expiration in practice because of moving exchange rates but no w=
ay to communicate that to sending software. BTCPay checkout page includes a=
 15 minute countdown by default. Payments made to a checkout after the expi=
ration are saved in an error state for the BTCPay operator and customer to =
triage.

Since enforcing expiration by consensus sounds unpopular, one generic way t=
o enforce it at the application layer would be to use a new BIP 21 URI para=
meter `req-exp=3D`.

BIP 21 specifies that parameters starting `req-` are considered required. U=
RIs containing unknown `req-` parameters are considered invalid and the par=
ameter can still be shown in UI. Support for `req-exp=3D` could thus be imp=
lemented in BIP 21 libraries rather than for each address type, and without=
 necessarily supporting Silent Payments.

New address specifications like Silent Payments could recommend wallets req=
uest payments using BIP 21 URI and `req-exp=3D` to begin to solve this prob=
lem in general. Wallets supporting Silent Payments & `req-exp=3D` could the=
n apply expiration to older address types too.

Dan

> On Aug 6, 2023, at 10:28 AM, bitcoin-dev-request@lists.linuxfoundation.or=
g wrote:
>=20
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>=20
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>=20
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>=20
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>=20
>=20
> Today's Topics:
>=20
>   1. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (Samson Mow)
>   2. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (Brandon Black)
>   3. Re: BIP-352 Silent Payments addresses should have an
>      expiration time (josibake)
>=20
>=20
> ----------------------------------------------------------------------
>=20
> Message: 1
> Date: Fri, 4 Aug 2023 11:41:39 -0700
> From: Samson Mow <samson.mow@gmail.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
> Message-ID:
> <CAAWeQ5fRi3AiZpSm4riyrNyCRphi5dSE6tFpkaGeQCY3x4keng@mail.gmail.com>
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> Why the 180 year limit? imho should plan for longer.
>=20
> On Fri, Aug 4, 2023 at 10:41?AM Peter Todd via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
>> tl;dr: Wallets don't last forever. They are often compromised or lost. W=
hen
>> this happens, the addresses generated from those wallets become a form o=
f
>> toxic
>> data: funds sent to those addresses can be easily lost forever.
>>=20
>> 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, with=
out
>> privacy concerns. Failing to make Silent Payment addresses eventually
>> expire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>>=20
>> 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,0=
00
>> 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.
>>=20
>> 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 expi=
re
>> for
>> similar UX reasons as applies to silent payments.
>>=20
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>=20
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20230804/fc013648/attachment.html>
>=20
> ------------------------------
>=20
> Message: 2
> Date: Sat, 5 Aug 2023 07:46:52 -0700
> 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
> Message-ID: <ZM5g3Fi_vErCeEx0@console>
> Content-Type: text/plain; charset=3Dus-ascii
>=20
> 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         | ???         | ???
>>=20
>> 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 granu=
larity,
>> 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.
>=20
> 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.
>=20
> 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.
>=20
>> 2) Your suggestion would result in a protocol that degrades over time, a=
s the
>> granularity of *newly* created addresses goes up. This isn't like CTV/CL=
TV,
>> 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 suggesti=
on does
>> not allow that.
>=20
> 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.
>=20
> 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.
>=20
> Best,
>=20
> --Brandon
>=20
>=20
> ------------------------------
>=20
> Message: 3
> Date: Sun, 06 Aug 2023 14:20:06 +0000
> From: josibake <josibake@protonmail.com>
> To: Peter Todd <pete@petertodd.org>
> Cc: bitcoin-dev@lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should
> have an expiration time
> Message-ID:
> <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MN=
SpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=3D@protonmail.com>
>=20
> Content-Type: text/plain; charset=3D"utf-8"
>=20
> Hi Peter,
>=20
> Thanks for the feedback! As you mentioned, this is a more general problem=
 in Bitcoin and not specific to BIP352. Therefore, if expiration dates are =
indeed something we want, they should be proposed and discussed as their ow=
n BIP and be a standard that can work for xpubs, static payment codes, as w=
ell as existing and future address formats. If that were to happen, it woul=
d be easy enough to add this expiration standard to silent payments as a ne=
w silent payments address version.
>=20
> That being said, I'm a bit skeptical in general of expiration dates and t=
hink that they weaken the value proposition of silent payments while not ac=
tually solving the problems you described. Consider the following scenarios=
:
>=20
> 1. Bob's wallet is compromised with a one-year expiry and for the next ye=
ar, funds are sent to the attacker. The attacker may have the ability to up=
date the expiration, and thus be able to keep receiving funds as Bob.
> 2. Bob loses his keys with a one-year expiry but finds them again 3 years=
 later. The expiration causes Bob to miss out on 2 years worth of potential=
 payments.
> 3. Bob dies with a one-year expiry but an heir inherits his backups sever=
al years down the road. The expiration date causes the heir to miss out on =
several years worth of potential payments.
> 4. Bob is prevented from updating his address for several years but retai=
ns access to his keys/backups. The expiration date causes Bob to miss out o=
n several years worth of potential payments.
> 5. Bob regularly updates his address with a new expiry, but not all sende=
rs are able to find the new, updated address causing Bob to miss out on pot=
ential payments.
> 6. By updating his address, Bob is leaking metadata about himself, potent=
ially compromising his safety.
>=20
> You could argue that none of the scenarios above would be an issue if Bob=
 just sets a very long expiry, but then the expiry doesn't really help in s=
olving the issues you mentioned. What we really want is a way for Bob to re=
voke his silent payment address. For this, I think building a wallet protoc=
ol on top of silent payments is a better path to explore. Additionally, exp=
iration dates as proposed degrade the privacy of silent payments: any outsi=
de observer can conclude that all transactions mined at block height N or g=
reater were not payments to any silent payment address with an expiry less =
than N. As I mentioned already, there may also be privacy and safety concer=
ns with the user needing to regularly update their silent payment address e=
xpiration date.
>=20
> Lastly, on the subject of expiration dates in general, your proposed solu=
tion is not enforceable: any wallet can just ignore the extra bytes and sen=
d to the address/xpub/static payment code, anyways. For expiration dates to=
 be useful, I'd argue they need to be enforced by consensus (which I am not=
 convinced is a good idea).
>=20
> In summary, expiration dates are a separate problem, outside the scope of=
 what BIP352 is trying to address. If we can work toward a more general sol=
ution, there is nothing preventing us from adding this to a future silent p=
ayments version, but even then, I'm still not convinced expiration dates fo=
r static payment codes is a good idea, for the reasons I mentioned above.
>=20
> Cheers,
> Josie
>=20
>=20
> Sent with Proton Mail secure email.
>=20
> ------- Original Message -------
> On Friday, August 4th, 2023 at 7:39 PM, Peter Todd via bitcoin-dev <bitco=
in-dev@lists.linuxfoundation.org> wrote:
>=20
>=20
>> tl;dr: Wallets don't last forever. They are often compromised or lost. W=
hen
>> this happens, the addresses generated from those wallets become a form o=
f toxic
>> data: funds sent to those addresses can be easily lost forever.
>>=20
>=20
>> All Bitcoin addresses have this problem. But at least existing Bitcoin
>> addresses aren't supposed to be reused. Silent Payments are: the whole p=
oint is
>> to have a single address that you can safely pay to multiple times, with=
out
>> privacy concerns. Failing to make Silent Payment addresses eventually ex=
pire in
>> a reasonable amount of time is thus a particularly harmful mistake.
>>=20
>=20
>> Fixing this is easy: add a 3 byte field to silent payments addresses, en=
coding
>> the expiration date in terms of days after some epoch. 2^24 days is 45,0=
00
>> 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.
>>=20
>=20
>> Wallets should pick a reasonable default, eg 1 year, for newly created
>> addresses. Attempts to pay an expired address should just fail with a si=
mple
>> "address expired". Lightning invoices are a good example here: while inv=
oices
>> does not require expiration from a technical point of view, they do expi=
re for
>> similar UX reasons as applies to silent payments.
>>=20
>=20
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: publickey - josibake@protonmail.com - 0x616516B8.asc
> Type: application/pgp-keys
> Size: 3154 bytes
> Desc: not available
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20230806/edd207c8/attachment.bin>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 855 bytes
> Desc: OpenPGP digital signature
> URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/=
20230806/edd207c8/attachment.sig>
>=20
> ------------------------------
>=20
> Subject: Digest Footer
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
>=20
> ------------------------------
>=20
> End of bitcoin-dev Digest, Vol 99, Issue 15
> *******************************************