Open darosior opened 4 years ago
Concept ack on #22 to implement a bitcoin validation uri/address from scratch (continue the discussion on the MR about improvements and requirements).
Other approach:
lightning-txprepare
to make a fake transaction testing the addressHi @lvaccaro,
Thanks to give me the lock on this feature.
use lightning-txprepare to make a fake transaction testing the address
Concept ack, I agree with this, we can use the node lightning to make a check on this, I can try to implement another draft with this solution.
extend esplora plugin with a validation address command, but this should call bitcoin-cli to work in bitcoin peer node mode.
This is very cool to have, but now I'm asking a question about the electrum server, there is the possibility to validate the address with the server? such as use bitcoin-cli. If yes, we can try to wrapping this idea inside a real solution.
Maybe @darosior could give us a bit of wisdom about lightning-txprepare
and if he think is a good approach.
On the other hand, Esplora has the https://github.com/Blockstream/esplora/blob/master/API.md#get-addressaddress api but you have to send the address to the explorer for validation that it takes time and maybe it is not always the best case. So I don't like so much.
Maybe @darosior could give us a bit of wisdom about lightning-txprepare and if he think is a good approach.
Under the hood txprepare
and withdraw
use almost the same codepath. In addition, withdraw
will check the address (in the same way txprepare
would btw):
struct command_result *param_bitcoin_address(struct command *cmd,
const char *name,
const char *buffer,
const jsmntok_t *tok,
const u8 **scriptpubkey)
{
/* Parse address. */
switch (json_to_address_scriptpubkey(cmd,
chainparams,
buffer, tok,
scriptpubkey)) {
case ADDRESS_PARSE_UNRECOGNIZED:
return command_fail(cmd, LIGHTNINGD,
"Could not parse destination address, "
"%s should be a valid address",
name ? name : "address field");
case ADDRESS_PARSE_WRONG_NETWORK:
return command_fail(cmd, LIGHTNINGD,
"Destination address is not on network %s",
chainparams->network_name);
case ADDRESS_PARSE_SUCCESS:
return NULL;
}
abort();
}
Hence I see no additional benefits to use txprepare
and I think using withdraw
directly is OK.
On the other hand, Esplora has the https://github.com/Blockstream/esplora/blob/master/API.md#get-addressaddress api but you have to send the address to the explorer for validation that it takes time and maybe it is not always the best case. So I don't like so much.
Strongly agree with this, lightningd
is already capable to check an address (and the network btw) let's not encumber ourself with YA roundtrip.
Reading withdraw
from https://lightning.readthedocs.io/lightning-withdraw.7.html?highlight=withdraw, it looks the tx is built and broadcasted, if valid.
In QR code scanning, I think we only need to parse the address without broadcast tx, in order to postpone amount selection and user confirmation, or maybe I am missing something.
I assumed you'd call withdraw
after gathering all these informations, either by uri or user input.
-------- Original Message --------
On Jul 14, 2020, 06:40, luca vaccaro wrote:
Reading withdraw from https://lightning.readthedocs.io/lightning-withdraw.7.html?highlight=withdraw, it looks the tx is built and broadcasted, if valid. In QR code scanning, I think we only need to parse the address without broadcast tx, in order to postpone amount selection and user confirmation, or maybe I am missing something.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.
I'd like to switch to Lamp as my main wallet but too many people are still using onchain payments.
Hint: you can use the
withdraw
RPC command under the hood to spend fromlightningd
's onchain wallet.