sendpay from plugin crashes lightningd (FATAL SIGNAL 6) #3431
Comments
s-tikhomirov
changed the title
|
try to replace this line: with works for me then |
|
@renepickhardt this helped! So if I use |
|
You seem to assume that the The reason it is crashing is, I think, is because the amount recorded ( Regardless, this should lead to an RPC error, not a crash of the |
|
@ZmnSCPxj I changed the amounts to millisatoshis and now observe two different outcomes. If I use exactly the same amounts in I thought that the problem may have been in fees (the real payment demands a higher fee than
Log attached as file: crash.log.20200123114958.txt. |
|
You could put the text in an ordinary text file and drag it into the UI of GitHub (assuming you are using the web GitHub interface), the bit which says "Attach files by dragging & dropping", which would also be easier on us so as not to scroll so much in the GitHub issue and to read the logs in our preferred editor / text slice-and-dice tool (the one and only VIM). |
|
The culprit is this Lines 97 to 98 in 6489e63 It seems you are mixing two different concepts here: by specifying a The crash is undesirable and can be fixed by just checking that having a value for either |
We were implicitly assuming a multi-part payment if the `msatoshi` argument was specified, but then didn't check that we have all the pieces in place for mpp. This adds a couple of additional checks to the arguments and makes it more explicit what it means to do an mpp. Fixes ElementsProject#3431 Reported-by: Sergei Tikhomirov <@s-tikhomirov>
|
@cdecker So am I correct to assume that the following use case is discouraged / not possible?
|
It is possible, however the route needs adjustments for different values, since each element in the route array contains the absolute value the processing node should forward. So you can't. In addition if you want to split a payment, each split needs a unique For an example on how to manually drive a multi-part payment please see the following tests: Line 2572 in 6489e63 Line 2654 in 6489e63 Line 2673 in 6489e63 Line 2701 in 6489e63 |
cdecker
added
the
state::fixed
We were implicitly assuming a multi-part payment if the `msatoshi` argument was specified, but then didn't check that we have all the pieces in place for mpp. This adds a couple of additional checks to the arguments and makes it more explicit what it means to do an mpp. Fixes ElementsProject#3431 Reported-by: Sergei Tikhomirov <@s-tikhomirov>
Assuming surveillors only run a single node on the network. If a surveillor runs multiple nodes (likely, since that is more likely to catch more payments for them to monitor) then the extra routes make it easier to triangulate the destination. Fortunately Payment Decorrelation Fixes This (TM). When Schnorrrrrrr? |
Issue and Steps to Reproduce
I'm experimenting with
sendpayon regtest. Calling a plugin which usessendpayconsistently crashes the node.The following is the minimal example. I'm sending a payment of 1000 sats from node
0306to node03da. There is a channel between them with enough capacity, as indicated bylightning-cli listchannelsoutput (the relevant part):The plugin code:
Calling the plugin and the crash:
The log file:
One could conclude from the logs that the receiver (
03da..bcc4@localhost:9735) is offline. However, it shows up with"connected": true,inlightning-cli listpeers, and re-connecting manually doesn't resolve the issue.getinfooutputThe text was updated successfully, but these errors were encountered: