joinmarket-clientserver
joinmarket-clientserver copied to clipboard
Add the command line option of "input-addrs"
With this new command line option, user can spend from specified addresses via the following command:
python sendpayment.py wallet.jmdat amount target_address -i spend_from_address_1 -i spend_from_address_2 -i spend_from_address_3 -m mix_depth_of_from_address
This is the first step of implementing #1010
cc @openoms FYI
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 select_utxos
, that would have to be fixed up
(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?
There is an issue with the requiring of an auth-suitable address, that is seen in select_utxos, that would have to be fixed up
Could you elaborate on the issue? I'm not really understand what the problem is here. Thanks!
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
- It's easier for the user to use address instead of UTXO, as addresses are much shorter than the UTXO, and users interact with addresses much more frequently than with UTXOs directly.
- I would like to support selecting by UTXOs as well, in addition to selecting by address. That could be implemented in a future PR.
Edit: ignore this first point, it's wrong, see here
Could you elaborate on the issue? I'm not really understand what the problem is here. Thanks!
I meant this: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/b95cb36bc1bb09f0458749b8837f920d7138c2dd/jmclient/jmclient/wallet.py#L751 is required for the taker usage (not for the direct send usage of course).
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:
I meant this:
https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/b95cb36bc1bb09f0458749b8837f920d7138c2dd/jmclient/jmclient/wallet.py#L751 is required for the taker usage (not for the direct send usage of course).
Sorry! No wonder you were confused :) This is wrong because the auth_address
, which is used to authenticate the counterparty (to prevent a MitM), is only provided by the maker, in the !ioauth
message, not by the taker. So this kind of restriction does not exist on taker utxos.
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 have two reasons I don't want to use addresses but prefer utxos:
- This gives users full control of the history of the inputs of a transaction; yes, it's true that coins at the same address are intrinsically connected, but that's still not quite the same, if we use addresses then users cannot choose to spend a single utxo, as they might, for reasons we don't know
- It also keeps the correct mental model for users of coins/utxos not accounts
I don't think the counterargument that addresses are easier UX wise, is significant (both are horrible UX wise, in plain text form).
This is wrong because the auth_address, which is used to authenticate the counterparty (to prevent a MitM), is only provided by the maker, in the !ioauth message, not by the taker. So this kind of restriction does not exist on taker utxos.
To be clear, does it mean that the problem doesn't really exist and this PR should be working fine?
I don't think the counterargument that addresses are easier UX wise, is significant (both are horrible UX wise, in plain text form).
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.
This is wrong because the auth_address, which is used to authenticate the counterparty (to prevent a MitM), is only provided by the maker, in the !ioauth message, not by the taker. So this kind of restriction does not exist on taker utxos.
To be clear, does it mean that the problem doesn't really exist and this PR should be working fine?
I don't think the counterargument that addresses are easier UX wise, is significant (both are horrible UX wise, in plain text form).
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? UTXOs have much more meaning (actually, they have a direct meaning on the Bitcoin protocol), addresses are not as a granular selection, and some addresses are just the result of a tx change, which might be confusing for the user.
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.
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.
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?