From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9D205C0032 for ; 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 ; 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 ; 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 ; 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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrleeigdduheegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehgtd erredttddvnecuhfhrohhmpefrvghtvghrucfvohguugcuoehpvghtvgesphgvthgvrhht ohguugdrohhrgheqnecuggftrfgrthhtvghrnhepledvleelffdtudekudffjefgfeejue ehieelfedtgfetudetgeegveeutefhjedtnecuffhomhgrihhnpehpvghtvghrthhouggu rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epphgvthgvsehpvghtvghrthhouggurdhorhhg X-ME-Proxy: 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 To: josibake Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="b3O4wZ5c1Wg635nI" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--