bitjson / bch-zce

Instant, incentive-secure payments on Bitcoin Cash. Note: spec not yet updated to treeless construction:
https://bitcoincashresearch.org/t/chip-2021-08-zces-zero-confirmation-escrows/537/94#treeless-zce-1
10 stars 4 forks source link

Privacy: managing unused same-address UTXOs (until PMv3) #10

Open bitjson opened 3 years ago

bitjson commented 3 years ago

Recommendation identified by Jonas on BCR:

Currently many wallets do spend all UTXOs from the same address due to (valid) privacy reasons and given the number of services that sends all coins to one address (for instance tipping services, read.cash and peoples indifference to setup new withdrawal addresses on exchanges) it might be an UX issue to not be able to combine those outputs in one payment. And given that the inputs are required to have at least one confirmation the wallet can not combine those inputs to a new address and use that for the payment…

And the plan to address:

Without PMv3 I’m afraid we can’t fix the UX part, but privacy-wise, wallets should probably add all UTXOs for used addresses to the second reclaim transaction. It’s always broadcasted at the same time, and merging those inputs immediately doesn’t lose any further privacy. (If the wallet waits around to use them later, future transactions can be easily connected.)

bitjson commented 3 years ago

Eh... I clearly didn't think about this long enough, if you just add the unused UTXOs as inputs to the reclaim transaction, that defeats the purpose of not adding them to the first transaction. 😆

So if we're starting with a wallet with N same-address UTXOs, the best we can do is spend one in the ZCE, then merge the other UTXOs with the output of the ZCE reclaim transaction after 11 blocks have passed (ideally using CashFusion). And even that is messy, since the ZCE reclaim transaction outputs could otherwise be re-used in a further ZCE transaction after just 1 block (and they can even be passed through CashFusion within that block).

Another (possibly better) strategy would be for wallets to merge same-address UTXOs in advance (using CashFusion), and spending only to specially-derived "ZCE-ready" outputs which the wallet can be sure will not be re-used by other wallet clients sharing the same imported HD key. (Or at least the other wallet clients can be expected to take the same ZCE precautions.)

The downside of that approach is that must happen at some specific time before the ZCE transaction (if the user even opens the wallet), and it's also hard for wallets to anticipate when the last payment to an address might be received (to reduce the number of merges needed, which leak access-timing information for the owner).

Anyways, I'm not sure if we can really make a general recommendation for all wallets on this issue. The issue is fully solved by PMv3 though, so it's also probably not worth wallets expending a lot of development resources on temporary patches.