-
Notifications
You must be signed in to change notification settings - Fork 54
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[feat] Coin Control #689
Comments
Related - JoinMarket-Org/joinmarket-clientserver#1112 (there is dispute between using UTXOs vs addresses). |
Ping @editwentyone |
To me, when going to the send screen, you would just be presented with the option of collaborative or not. After this selection, you can then decide which UTXOs you'd like to use, with a tick-box for "consume" (to use the entire UTXO without change). |
Interesting, although I would still think UTXO control is the more important option as they are the atomic unit in this context, and address re-use maybe ought to be shunned in general, especially when considering privacy. I think my above desired UI/UX could accommodate both, but I would favor UTXOs only, for simplicity. |
In UI like Jam this could be actually achieved purely in frontend side - when address reuse has happened, if user selects one of UTXOs sent to that address, just automatically select others related to that address too. And user can override by deselecting them. |
|
[feat] Coin Control #689
Bonus:
|
Describe the solution you'd like
During a non-collaborative send, it would be nice to be able to select a UTXO (and consume it) to spend.
*Note
There is currently a workaround to this where you can freeze all UTXOs except the one you'd like to spend.
The text was updated successfully, but these errors were encountered: