From: Peter Todd <pete@petertodd•org>
To: josibake <josibake@protonmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP-352 Silent Payments addresses should have an expiration time
Date: Thu, 10 Aug 2023 20:58:00 +0000 [thread overview]
Message-ID: <ZNVPWBd3+06Su01h@petertodd.org> (raw)
In-Reply-To: <Xypmhu6s58gWgRNoFzBDhbtvcEt8DomdJcLe1RIbesEKOx1MO5TBHTLDENqedTbN9DPZT5MNSpA-xMiiSDDb-hVnx-YgIAqCtrGHoCrqxsE=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 5309 bytes --]
On Sun, Aug 06, 2023 at 02:20:06PM +0000, josibake wrote:
> Hi Peter,
>
> 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 own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.
>
> That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
>
> 1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update 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 find
the keys, and multiple years worth of funds are wasted.
> 3. Bob dies with a one-year expiry but an heir inherits his backups several 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 retains access to his keys/backups. The expiration date causes Bob to miss out on 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 likely
to prevent a loss of funds due to theft or fraud.
> 5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential 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 this
address, and yet, can't update it. Social media, webpages, github repos, etc.
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, potentially 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 reasons
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 solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater 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 concerns with the user needing to regularly update their silent payment address expiration date.
Outside observers can already do this kind of analysis with or without
expiration, as users regularly expire addresses in other ways (eg by updating 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 solution is not enforceable: any wallet can just ignore the extra bytes and send 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.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-08-10 20:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-04 17:39 Peter Todd
2023-08-04 18:41 ` Samson Mow
2023-08-05 14:15 ` Peter Todd
2023-08-04 22:27 ` Brandon Black
2023-08-05 14:06 ` Peter Todd
2023-08-05 14:46 ` Brandon Black
2023-08-06 14:20 ` josibake
2023-08-10 20:58 ` Peter Todd [this message]
[not found] <mailman.128723.1691332123.956.bitcoin-dev@lists.linuxfoundation.org>
2023-08-08 21:05 ` Dan Gould
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZNVPWBd3+06Su01h@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=josibake@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox