Feedback-ID: i525146e8:Fastmail
Date: Thu, 10 Aug 2023 20:58:00 +0000
From: Peter Todd <pete@petertodd.org>
To: josibake <josibake@protonmail.com>
Message-ID: <ZNVPWBd3+06Su01h@petertodd.org>
References: <ZM03twumu88V2NFH@petertodd.org>
 <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="b3O4wZ5c1Wg635nI"
Content-Disposition: inline
In-Reply-To: <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an
 expiration time
Precedence: list


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

On Sun, Aug 06, 2023 at 02:20:06PM +0000, josibake wrote:
> 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.

The ability to "update the expiration" is the ability to trick someone into
thinking a new address came from Bob, eg by modifying a donation address in=
 a
social media profile. This attack works whether or not expiration exists.

> 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.

If Bob has lost his keys, the safe thing to do is for people sending funds =
to
Bob to ask Bob for a new address. It is much more likely that Bob doesn't f=
ind
the keys, and multiple years worth of funds are wasted.

> 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.

If Bob is dead, why are people sending Bob money? In this example expiration
prevented an unintentional fraud.

> 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.

Same category as #2 and #3. The main cause of this example is going to jail,
which would usually be a circumstance where both key loss is likely, *and*
people may want to reconsider sending Bob money. Expiration is much more li=
kely
to prevent a loss of funds due to theft or fraud.

> 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.

If the senders can't find Bob's up-to-date address, how much due dilligence=
 are
they possibly doing on where they're sending funds?

You need to provide a clear example of how you think Bob is distributing th=
is
address, and yet, can't update it. Social media, webpages, github repos, et=
c.
are all easily updatable.  How, concretely, is Bob going to be in a position
where updating an address is hard?

> 6. By updating his address, Bob is leaking metadata about himself, potent=
ially compromising his safety.

This is an extremely marginal concern. Any silent payment address associated
with, eg, a social media profile is revealing far more metadata from other
actions of the user.

People pay other people for reasons, eg a developer writing code. Those rea=
sons
translate into far more metadata than updating a donation address once every
year or two.

> 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.

Outside observers can already do this kind of analysis with or without
expiration, as users regularly expire addresses in other ways (eg by updati=
ng a
social media profile).

I also find this attack extremely marginal due to how little information the
attacker gets: the k-anonymity set of silent payments is already very large.

> 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).

Checksums are similar to expiration in this fashion: neither are enforced by
the consensus layer, and they don't need to be. For them to work in almost =
all
cases it is more than sufficient to just standardize them and enforce them =
in
the client. 99.999% of clients will respect expiration, solving the problem
nearly 100% of the time.

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

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

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

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmTVT1UACgkQLly11TVR
LzcUSBAAiiLONVv2yqDXLUn+fE1HxdS4rROrcGDfaKLkOWOxTvdAv+0H24djApog
FuLoQZK/yn2UuIkFEHrjCVJfxifzexHgN6y0DJi98ik2XzRP59dNeELP4Q0MvXNu
6Id+HDFmMAdGFEeKe0VvoUzp7ODkd1LpVDUeRL8VFyybMHe9wqgy/S0Xv4Bq7sXc
ORGm48StjlWFLUux63mSqezn6VwE6n6xDyfb6e6Wh6ItuKGdCfGdfmzgVFlEHZy6
P4os8wxaxRv2fvlG9IlwVIG99W65YFf73+YZT8HcFUQ+1k+bs8Q3z269uwuSLdda
57JP3BYHui5NA/b3O+B1+YRLVJ8KjyVV5TqCymwPY01crazOhOt659g8kwnuzQaG
JHYCvC8afMZDurNvCI5qtFTCMTrnfnjuR5/Alka4zHk0MkgyrfPI31Nn5r35yYxs
8vJmr5iZt0sdWKyO4XaiguXQReh+jTcq+j7kWapSYNj0VWfMm6yPZujTSUmPLICe
qamvqPp7U6mlpZOpIueIwKvu3Y40aWNH80U4zGn/zziu/VpT+aE7uh7YT33beEHE
L7y+CR8fRLBGwm8JvsWKLbgx2lHeTDQXmISPXkAlahQrZP8SIVfxEh2yi5wOk8/+
omE4EYoFetowUukaB3T2Pq0TRwu5nlnhlX/V82z0fvpuaLaJONs=
=2pjy
-----END PGP SIGNATURE-----

--b3O4wZ5c1Wg635nI--