-
Notifications
You must be signed in to change notification settings - Fork 179
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
Add the command line option of "input-addrs" #1112
base: master
Are you sure you want to change the base?
Add the command line option of "input-addrs" #1112
Conversation
Apologies for the long delay in starting to review this. It's become impossible for me to keep up with all the things I want to on the project. So first points on first code read-through: There is an issue with the requiring of an auth-suitable address, that is seen in (I'll also want to double check the formatting of putting the input address list at the end of the schedule, and double check there is no snafu based on "what's at the end of the schedule item list" logic.) The general idea makes sense, but I'm wondering where it's coming from, like: if I decide to use exact coin control, why wouldn't I select by utxo, not by address? Obviously we want it to be the case that there's a 1-1 match, but in cases where there isn't, isn't it even better to make sure you're doing a utxo based check, not an address based check? |
Could you elaborate on the issue? I'm not really understand what the problem is here. Thanks!
|
Edit: ignore this first point, it's wrong, see here
I meant this:
Re: your points as to why address-based may be better, I can see your point, but if anything I would tend to lean the other way, still. Users working at this level (full coin control) should be encouraged to precisely choose the coin they want to spend; doing it by address is an imprecision which could catch them with an unpleasant surprise. So I'm more anti- than for- doing it by address, though your arguments are perfectly reasonable. |
I would argue for using addresses, as, from privacy perspective, if you have multiple UTXOs sent to the same address in your wallet, you migh want to always spend them all. But some warning should be printed in case some of them are frozen, some not. |
Coming back to this again, I can see that this comment I made, is just wrong:
Sorry! No wonder you were confused :) This is wrong because the So that's one thing cleared up :) On the second point that was discussed: There's an old phrase in Bitcoin going back to the early days "there is no such thing as a from address". This is technically true, which is the best kind of true :)
I don't think the counterargument that addresses are easier UX wise, is significant (both are horrible UX wise, in plain text form). |
To be clear, does it mean that the problem doesn't really exist and this PR should be working fine?
I agree. And my plan is to add this feature to the QT gui once this PR is merged. The idea is that, you can simply right click an address in the "JM Wallet" main tab, and select a new context menu option, "Spend from this address". And in the "Coinjoins" tab, there will be an optional field, "spend from addresses". If you did that "Spend from this address" thing, you'll be redirected to the "Coinjoins" tab, with the "spend from addresses" field prefilled for you. |
Hello, could you make this feature use UTXOs instead of addresses? It would be much easier just to select from a list of UTXOs, the ones we want to include in a direct-send or a coinjoin. |
exactly! |
It looks this got stuck in discussion of using addresses vs UTXOs. I have my arguments for using addresses, but going UTXO way is also ok with me, better to have something, one way or another, than nothing. @BitcoinWukong Could you rebase? |
With this new command line option, user can spend from specified addresses via the following command:
This is the first step of implementing #1010
cc @openoms FYI