Feature request: detect onchain QR codes, and allow to spend from the onchain wallet instead

[darosior]

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 from lightningd's onchain wallet.

[lvaccaro]

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:

• use lightning-txprepare to make a fake transaction testing the address
• extend esplora plugin with a validation address command, but this should call bitcoin-cli to work in bitcoin peer node mode.

[vincenzopalazzo]

Hi @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.

[lvaccaro]

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.

[darosior]

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.

[lvaccaro]

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.

[darosior]

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.