Open bitjson opened 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.
Recommendation identified by Jonas on BCR:
And the plan to address: