lianad: warn createrecovery to an address of the same wallet. - #2226
Conversation
| coins_outpoints: &[bitcoin::OutPoint], | ||
| feerate_vb: u64, | ||
| timelock: Option<u16>, | ||
| allow_own_address: Option<bool>, |
There was a problem hiding this comment.
I can overlook something, but I dont think this flag is really useful, it seems to me we can just return warnings
There was a problem hiding this comment.
I will get my annotations made before "that" and lyn :)
There was a problem hiding this comment.
I think i got your idea and make sense. LMK if it' correct: no need to allow_own_address option so the directed warnings value could go directly to GUI when doing it, and no need to call twice (one for "doing, deny and warning plus one for doing and warning" vs "one for doing and warning" ? My UI/UX thinking was to deny first, so the user could have full knowledge about will happen and need to be sure about before do. Your perspective is that the user already know the risks?
There was a problem hiding this comment.
My perspective is we just want to warn the user, not prevent doing this, and making 2 call is overkill/overcpmplex imo
This commit adds a new error (code 1001, just after the existing 1000) bound to `createrecovery` -- as an error/warning response -- when a user wants to re-lock funds from/to addresses derived from the wallet descriptor. As stated by jp1ac4 the starting point is to check this on the backend since the backend has easier access to known wallet addresses (needs a check on how to deal with derivation indices beyond what the DB knows). The proposed flow is first return an error from `createrecovery`, controlled by a new `Option<bool>` parameter `allow_own_address` (defaults to `false`). With this, a user can try again with `allow_own_address=true` (see `tests/test_rpc.py`). In that case, a new `warnings` field is added to the response alongside the `psbt` one, so the user can double-check the entire procedure. refs wizardsardine#1654.
73ee1df to
dde5488
Compare
2 participants
This commit adds a new error (code 1001, just after the existing 1000) bound to
createrecovery-- as an error/warning response -- when a user wants to re-lock funds from/to addresses derived from the wallet descriptor.As stated by jp1ac4 the starting point is to check this on the backend since the backend has easier access to known wallet addresses (needs a check on how to deal with derivation indices beyond what the DB knows).
The proposed flow is first return an error from
createrecovery, controlled by a newOption<bool>parameterallow_own_address(defaults tofalse). With this, a user can try again withallow_own_address=true(seetests/test_rpc.py).In that case, a new
warningsfield is added to the response alongside thepsbtone, so the user can double-check the entire procedure.refs #1654.
Details
A follow-up commit (the GUI confirmation flow) is being drafted while discussing.