1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (6) ·
Yes, we need to switch to a p2p tx model and allow recipient to specify many addresses, or sender to specify many addresses (using DH). This allows us to use merge avoidance and send many txs. BIP 270 extension.
1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (6) ·
The other thing we can do it let the user manage their UTXOs as different "wallets" within the same wallet. Then you have different wallets for different purposes. Though I'm pretty sure merge avoidance gets us 99% of the gains.
1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (9181) ·
Is there a reference for merge avoidance? -- rt12
1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (6) ·
https://medium.com/@octskyward/merge-avoidance-7f95a386692f
1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (9181) ·
If everyone is doing merge avoidance, including Alice's employer, and no-one is reusing addresses, then the privacy problem (as well as denomination/split maintenance) is perhaps solved. Perhaps worth featuring it in BIP270/SPV spec for that reason.-- rt12
1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (9181) ·
I'd like to say that accounts should only touch their own coins, but I am not so sure. It seems too convenient to allow an account to break change, maybe it's left down to a user option for ElectrumSV. -- rt12
1AKHViYgBGbmxi8qiJkNvoHNeDu9m3MfPE (9181) ·
Thanks Ryan, this actually ties in nicely with the coin management we were planning and reduces overhead for the wallet as well as the need for the wallet to request coin access for denomination/splitting management. -- rt12