path: root/cc/85419beb8e364b8acb0d2faa9dd6e114db4e8a

Return-Path: <pete@petertodd.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 9D205C0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 20:58:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 3DFA34052B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 20:58:08 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3DFA34052B
Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key,
 unprotected) header.d=messagingengine.com header.i=@messagingengine.com
 header.a=rsa-sha256 header.s=fm3 header.b=O7gLtkFs
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001,
 RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 6FTDCWtnz2V5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 20:58:06 +0000 (UTC)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 9F533400DC
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 10 Aug 2023 20:58:06 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9F533400DC
Received: from compute6.internal (compute6.nyi.internal [10.202.2.47])
 by mailout.nyi.internal (Postfix) with ESMTP id E4C165C0145;
 Thu, 10 Aug 2023 16:58:03 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163])
 by compute6.internal (MEProxy); Thu, 10 Aug 2023 16:58:03 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:cc:content-type:content-type:date:date
 :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to
 :message-id:mime-version:references:reply-to:sender:subject
 :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm3; t=1691701083; x=1691787483; bh=PUe2r+mGP/s/r
 lqvGF4sk7oawMzdxSzHXG33S0Uh5k0=; b=O7gLtkFsvKuMo80F2MvtbR0o3bzmp
 BZzbdARVX3pMmOeyRgAvoK/4oBDbe5Z7YTp2+52Coo+lbUw0RAtETL+wg7rM5Lz2
 pQ7Tt+PWt16T10UN44dZYxHlsD5ha+BzupkXH94N6+atIqPrtM2e/EhwJ/sfhZLK
 D5eJop6E/weYuvXLNJLV/P3zGKBhtj2dBaW8s706HJiUJscRcHg76BOCcLckmS/E
 ppHfaPA9xvfhmbwU+TVJaAY4jiHJ70PQpT/AKLOMeu6G021S2kTobTZD6CHg8z2+
 /QCq8jLkB0dtvdempDnoVZsc3cyVP0HAys3aMZBzvOJUp9ATVaoZbQDTw==
X-ME-Sender: <xms:W0_VZHKfOH4Lt9wEEt3cHzf9vtvJ4N_mrLiQh2A-LF6gHUEXPSVimw>
 <xme:W0_VZLJrar6Jnd6YCKdc0ApBnmWIqHh4EjiPfh1ky61CRkPVbeTvO8m6ieRHMduxB
 nc65v2UXW14bgAZr8M>
X-ME-Received: <xmr:W0_VZPseikvYKCkmDaYjkYd-ZIm30uT2fDpTAKUHjCBrKz__tTUOsYbAlrQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeigdduheegucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
 uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehgtd
 erredttddvnecuhfhrohhmpefrvghtvghrucfvohguugcuoehpvghtvgesphgvthgvrhht
 ohguugdrohhrgheqnecuggftrfgrthhtvghrnhepledvleelffdtudekudffjefgfeejue
 ehieelfedtgfetudetgeegveeutefhjedtnecuffhomhgrihhnpehpvghtvghrthhouggu
 rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh
 epphgvthgvsehpvghtvghrthhouggurdhorhhg
X-ME-Proxy: <xmx:W0_VZAYf7L9JOArAWYOkYTzysCexsKw7fM03C0wsma3h2HKPe_kIkQ>
 <xmx:W0_VZOZdNOX5-nnHPZJnpVO5HSHAEk1mnckxNaqoTyPCSK8By2uOaw>
 <xmx:W0_VZEA7lyjI0pesK3xqmaFcfXelvz8qncKDMctWRGXRXO7U4KhBHw>
 <xmx:W0_VZOHIM18himMQUhNhMJRXl4IixMWnbWDk-QuunSR7lLd8taUjlg>
Feedback-ID: i525146e8:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 10 Aug 2023 16:58:03 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id CA5B05F97F; Thu, 10 Aug 2023 20:58:00 +0000 (UTC)
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Aug 2023 20:58:08 -0000


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