I recently setup a new node and attempted to send payments to invoices from another node I am operating to see the results of the tx's.....this is what I am getting from listsendpays as opposed to the normal response:
pocket-server@pocketserver-DEFAULT-STRING:~$ lightning-cli listsendpays
{
"payments": [
{
"id": 1,
"payment_hash": "bd99a2d61b46740423bdb7ead0a1b5f567511d9356db0d763bc6fcafff25ddc0",
"amount_msat": null,
"msatoshi_sent": 10000,
"amount_sent_msat": "10000msat",
"created_at": 1595912475,
"status": "complete",
"payment_preimage": "2e1cb0794afef78c0874df4f70ee3fa3475d0ad9ae8faadb5fd462ece6503838"
},
{
"id": 2,
"payment_hash": "cd16b3a6f6a8d19facaae09d53ff9b7ad630cbe9ab9b5b813b13bead1ec9667e",
"amount_msat": null,
"msatoshi_sent": 40000,
"amount_sent_msat": "40000msat",
"created_at": 1595912626,
"status": "complete",
"payment_preimage": "75d3dcc66987ea7e7e320729051f8edb1de359fa4d94cd9fc1b2679779a3eebf"
},
{
"id": 3,
"payment_hash": "a3b68806e9cf67b3c3fddb1b25e823ab2420601afb4e5dbd6dc176f12c3d0590",
"partid": 5,
"amount_msat": null,
"msatoshi_sent": 10568329,
"amount_sent_msat": "10568329msat",
"created_at": 1595970869,
"status": "failed"
},
{
"id": 4,
"payment_hash": "a3b68806e9cf67b3c3fddb1b25e823ab2420601afb4e5dbd6dc176f12c3d0590",
"partid": 6,
"amount_msat": null,
"msatoshi_sent": 10209608,
"amount_sent_msat": "10209608msat",
"created_at": 1595970869,
"status": "failed"
},
Why is there null and there are 7 fields for POST response instead of 11..what could be causing this? I assumed it was an improperly setup channel so I closed the offending channel (which had the wrong IP in the conf file when the channel was created...I think) When I noticed that the ip for the node was incorrect in the conf, I corrected the conf after the fact. Upon restart of the LN node, the ip was showing as corrected (in that previously open channel, but now closed one ) but the port was some random port and not my designated port..Could this have been it.....Ideas?
Also.....
Is there anyway to remove these erroneous listsendpay id's, since they will cause problems with front end development?
Hi @d4amenace,
The team are working around the clock to build the rc4, this problem was fixed inside this PR. I hope this answer help you.
So now, there is no pay cmd.....I will tell my devs.....is it to be replaced by sendpay now? or just temporarily?
There is still supposed to be a pay command. Most likely the plugin providing it crashed. Can you check logs for plugin-pay and see what happened?
There is still supposed to be a
paycommand. Most likely the plugin providing it crashed. Can you check logs forplugin-payand see what happened?
pocket-server@pocketserver-DEFAULT-STRING:~$ lightning-cli pay lnbc50u1p0jpt2ydq0d4skkefqwfhk7mgcqzgapp5d34sp8qc65fhevw0pncydhcc5lp0m63qtjrkv08f88xpuvll2glqxqyz5vprzjqv2ylnrne6jp5qpt9pjlnqvs4wgwfl6c5t8zf5u8pag8jzq7g2fz6ppdl09azf7hyuqqqqlgqqqqqeqqjqcq58nrg0hwnsxdmvhx5nah3kuz3wxur96vxc8uxn33ujmzqnm7yq8tqcxhnt7yzguvcg7spw7c63deewju9hyy400yc85gdru6xwy5gpzaw8c4 5000000 outgoing1
{
"code": -32601,
"message": "Unknown command 'pay'"
}
Where would I find the lightning log?
Ok, pay is working...it is just listsendpays on this LN node for some reason (have tested on one of my other nodes)...like you said probably installed incorrectly. To be sure I would like to uninstall the node and reinstall to clear out any errors before reposting her. How would I completely uninstall a node?
How would I completely uninstall a node?
Close all channels with unilateraltimeout=5. Shut down lightningd (lightningd-cli stop) and add offline to your conf file (or --offline to your lightningd command line, whatever you are using), then start lightningd again. If somebody made a channel to you between the time you closed everything down and you could shut down lightningd, remove the offline and restart lightningd and close the new channel, then shut down lightningd, re-add the offline, and start again. Wait out until all the channels complete their closure (unilateral closes can take days or weeks), then move the now-onchain funds elsewhere.
Then uninstall by going to your source distribution and doing make uninstall.
Where would I find the lightning log?
lightningd typically prints to stdout. Unless you specify a --log-file option, in which case you should know where the log file is. If you did not, you have to know how you started up lightningd and where it directs stdout to. If it is a systemd service for example then journalctl -u <lightningd service> should show you. Depends; how do you manage the lightningd process?
Ok, pay is working...it is just listsendpays on this LN node for some reason
If you are using pay, you should use listpays, not listsendpays. With MPP and automatic payment retrying, listsendpays does not provide accurate information about the status of pay commands, and you should use listpays instead.
Ok, pay is working...it is just listsendpays on this LN node for some reason
If you are using
pay, you should uselistpays, notlistsendpays. With MPP and automatic payment retrying,listsendpaysdoes not provide accurate information about the status ofpaycommands, and you should uselistpaysinstead.
Ok, so new node. Neither listsendpays nor listpays give complete payment info...now missing bolt11 invoice on listpays....and on listsendpays also no bolt 11 invoice??
minipc@minipc-desktop:~$ lightning-cli listsendpays
{
"payments": [
{
"id": 1,
"payment_hash": "3c43486e64284cd5d17e8a38bee76b42310bf195adf93d56cf88658929516a0e",
"amount_msat": null,
"msatoshi_sent": 10000000,
"amount_sent_msat": "10000000msat",
"created_at": 1596002463,
"status": "complete",
"payment_preimage": "7fe29f11eff1960ddfcc58268ad5dc6dedc057d909796f875563c1e6cc3619a1"
}
]
}
minipc@minipc-desktop:~$ lightning-cli listpays
{
"pays": [
{
"bolt11": "(null)",
"status": "complete",
"preimage": "7fe29f11eff1960ddfcc58268ad5dc6dedc057d909796f875563c1e6cc3619a1",
"amount_sent_msat": "10000000msat"
}
]
}
Older node gives full information under listsendpays:
{
"id": 8,
"payment_hash": "0bf817e93e8dfe0fe24593c85e2c14923f6c14747679ff5dd8cb6628793a2c80",
"destination": "02dd238ecc1d1c1798025a78caac1e20c5945e97836bdf01b25449d0fef776f456",
"msatoshi": 5001050,
"amount_msat": "5001050msat",
"msatoshi_sent": 5001050,
"amount_sent_msat": "5001050msat",
"created_at": 1596002609,
"status": "complete",
"payment_preimage": "eb0a83d46aea5acd872e154115c112345f4393f4e7b0afca885aedf1d3379afb",
"bolt11": "lnbc50u1p0jzyg6pp5p0up06f73hlqlcj9j0y9utq5jglkc9r5weul7hwcednzs7f69jqqdqcve5hyum5d9hxvun0d45x7mt9xqyjw5qcqp2sp5skxag5u3v54d6j3px6clldpyzpeyntsh69fhf6xa548mlljx6mpsrzjqtwgtyxavad4h7yud00eamkhvu5sk0tq2er9ukcpxat0v4sk60fhyzwfqvqqxlcqqyqqqqlgqqqqqzsqpc9qy9qsqevvddx89zceda2nf3qecxuvzeljy8a937v5n4gs8fu9h908c5uq53l4czysqcq7yzy306x5epgkn6568axxzzd29hdw83nvsshud6lgpfxdalp"
}
]
}
Either listsendpays or listpays MUST include bolt11,destination and payment hash. App is using listsendpays to list all payments sent...cannot identify without any identifiers.
Need to call listsendpays or listpays with bolt 11 parameter....neither tracks so how can lookup particular invoice? (used by app to confirm payments after executing pay call)
Either listsendpays or listpays MUST include bolt11
Not necessarily, if you use the command keysend you haven't a bolt11, you can find more information about the bolt11 null described inside this issue. However, if the bolt is null, you shouldn't node see the null value but the payment_hash (this feature is coming).
You have run the version rc3 and make some payment? maybe if you are seeing the bolt11 null and you didn't use the command keysend, you are reproducing the bug fixed inside this PR
Either listsendpays or listpays MUST include bolt11
Not necessarily, if you use the command
keysendyou haven't abolt11, you can find more information about thebolt11null described inside this issue. However, if the bolt is null, you shouldn't node see the null value but thepayment_hash(this feature is coming).You have run the version rc3 and make some payment? maybe if you are seeing the
bolt11null and you didn't use the commandkeysend, you are reproducing the bug fixed inside this PR
ok, so keysend is an option except in a retail situation.....example, using pay customer creates an invoice and shows qr (containing bolt11) so merchant can pay bolt11......If I were to use keysend, the node receiving the funds would need to display their node ID in QR form for scanning, which most mobiles apps do not do (particularly eclair mobile) automatically for speed of payment. Does not fix retail use case...also has the problem of possibly sending multiple payments continuously (which is a vulnerability of this approach).
ok, so keysend is an option except in a retail situation.....example, using pay customer creates an invoice and shows qr (containing bolt11) so merchant can pay bolt11......If I were to use keysend, the node receiving the funds would need to display their node ID in QR form for scanning, which most mobiles apps do not do (particularly eclair mobile) automatically for speed of payment. Does not fix retail use case...also has the problem of possibly sending multiple payments continuously (which is a vulnerability of this approach).
All good points, but I can not answer at these points, maybe some of the protocol developers can answer this and make an explanation.
If I were to use keysend, the node receiving the funds would need to display their node ID in QR form for scanning
Yep.
which most mobiles apps do not do (particularly eclair mobile) automatically for speed of payment.
I don't know eclair mobile, but I think that the ID Qr is already popular because you should be know the URL of the node to open a channel. However, in this cases you have the following pattern, NODE_ID@IP:PORT but you can make a simple parsing from URL to extract the ID
The (null) bolt11 field should have been fixed by #3878. What version are you using? Please note that 0.9.0 rc3 is only a release candidate and is known to be buggy, we will release an rc4 "soon". Ish.
I don't know eclair mobile, but I think that the ID Qr is already popular because you should be know the URL of the node to open a channel. However, in this cases you have the following pattern,
NODE_ID@IP:PORTbut you can make a simple parsing from URL to extract the ID
I have been using Eclair, BLW, and Lightning from lightning labs...none of which display ID QR easily. Only blw can do it but it must share to another app.
The
(null)bolt11field should have been fixed by #3878. What version are you using? Please note that 0.9.0 rc3 is only a release candidate and is known to be buggy, we will release an rc4 "soon". Ish.
0.9.0rc3
Yes, it is a known bug in rc3 and is fixed on master.
Yes, it is a known bug in rc3 and is fixed on master.
Is v0.9.0rc3-10-g14d08b7 current master?
Is v0.9.0rc3-10-g14d08b7 current master?
If you are cloning the master now, yes, it is. In addition, with the last version, you will not resolve the problem of the bolt11 made with version rc3 because the value is null also inside the database. I'm working to create the PR that check if the value is null and return the payment_hash but with the actual version, you may have the bolt11 null also with the last version of master.
The fix, proposed inside this PR fixes the problem to stop create bolt11 null, but don't fix the problem to display the bolt11 null (if exist). For this reason, you will see the bolt11 not null for all payment made with the version > rc3, but you still see the bolt11 null for all payment made with the rc3. The team are working to resolve also this problem
Is v0.9.0rc3-10-g14d08b7 current master?
If you are cloning the master now, yes, it is. In addition, with the last version, you will not resolve the problem of the bolt11 made with version rc3 because the value is null also inside the database. I'm working to create the PR that check if the value is null and return the payment_hash but with the actual version, you may have the bolt11 null also with the last version of master.
The fix, proposed inside this PR fixes the problem to stop create bolt11 null, but don't fix the problem to display the bolt11 null (if exist). For this reason, you will see the bolt11 not null for all payment made with the
version > rc3, but you still see the bolt11 null for all payment made with the rc3. The team are working to resolve also this problem
Thanks for clarifying that. It took me a while to get up to speed....Do you know if devs plan to include destination ?
Thanks for clarifying that. It took me a while to get up to speed....Do you know if devs plan to include destination ?
destination is embedded in bolt11 and the bolt11 will be saved if you never ran the 0.9.0 rc1 to rc3 and use pay only. The intent is that you parse this bolt11 yourself, and never run 0.9.0 rc1 to rc3, or use anything other than pay..
The issue is the sendonion command, which gives an opaque onion to lightningd, thus we cannot know details like destination or amount at destination. Do you need destination from listsendpays to work with sendonion too? keysend uses sendonion and does not provide a bolt11 (it cannot). Maybe we need to add a destination param to sendonion as well, which keysend command uses. Hmm.
Thanks for clarifying that. It took me a while to get up to speed....Do you know if devs plan to include destination ?
destinationis embedded inbolt11and thebolt11will be saved if you never ran the 0.9.0 rc1 to rc3 and usepayonly. The intent is that you parse thisbolt11yourself, and never run 0.9.0 rc1 to rc3, or use anything other thanpay..The issue is the
sendonioncommand, which gives an opaque onion tolightningd, thus we cannot know details likedestinationor amount at destination. Do you needdestinationfromlistsendpaysto work withsendoniontoo?keysendusessendonionand does not provide abolt11(it cannot). Maybe we need to add adestinationparam tosendonionas well, whichkeysendcommand uses. Hmm.
What changes should I see to listpays in rc4? bolt issue resolved? payment hash?
What changes should I see to listpays in rc4? bolt issue resolved? payment hash?
The only change that you will see is the bolt11 and not null for the new payment with invoice
I can confirm that the issue with listsendpays and listpays has been fixed in 0.9.0 rc4.
I can confirm that the issue with listsendpays and listpays has been fixed in 0.9.0 rc4.
Cool :)
Most helpful comment
Yes, it is a known bug in rc3 and is fixed on master.