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
signature.asc
Description: PGP signature
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
