-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: detect onchain QR codes, and allow to spend from the onchain wallet instead #20
Comments
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:
|
Hi @lvaccaro, Thanks to give me the lock on this feature.
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.
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 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. |
Under the hood 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
Strongly agree with this, |
Reading |
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).
|
This is a draft solution to discuss with developer is the Validator solution is a good solution or I'm losing somethings important. If the solution, like at developer I will require the lock on the issue. Commit built by @vincenzopalazzo [email protected]
This is a draft solution to discuss with developer is the Validator solution is a good solution or I'm losing somethings important. If the solution, like at developer I will require the lock on the issue. Commit built by @vincenzopalazzo [email protected]
This is a draft solution to discuss with developer is the Validator solution is a good solution or I'm losing somethings important. If the solution, like at developer I will require the lock on the issue. Commit built by @vincenzopalazzo [email protected]
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.The text was updated successfully, but these errors were encountered: