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](https://github.com/lvaccaro/lamp/issues/20#issuecomment-657999812), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AFLK3F6CX7VA3ZQRLDN764DR3P4WRANCNFSM4OXNTLDA).