Skip to content
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

Unexpected and unexplainable error #84

Closed
ghost opened this issue Jan 14, 2020 · 8 comments
Closed

Unexpected and unexplainable error #84

ghost opened this issue Jan 14, 2020 · 8 comments

Comments

@ghost
Copy link

ghost commented Jan 14, 2020

First of all: sendinvoiceless is a really cool and useful feature that I've implemented in my lightning game

I run 2 nodes like this: myshtery <-> Bitkoins.nl <-> 7 other channels

Myshtery is only connect to Bitkoins.nl. I have paid "Ship of Theseus" via Bitkoins.nl a few day ago 1000 satoshi with sendinvioiceless and it went ok over 4 hops and a small fee.

I had to pay "Ship of Theseus" again today but it didn't work while it's a very well connected node and it worked before. Error message:

error: {'message': 'Sending failed'}\",)"

I tried increasing the fee but nothing worked. I tested paying another node ID with Bitkoins.nl and that went fine.

I then decided to try to pay with myshtery but since myshtery is only connected to Bitkoins.nl it should have made it harder not easier to pay. However, the payment went smooth (via Bitkoins.nl obviously) over 6 hops and a small fee. After that I tried to pay again via Bitkoins.nl but it didn't work. Restarted Bitkoins.nl but that also didn't help.

What on Earth could cause this situation?

c-lightning: "v0.8.0-1-gb14b2b0"

@jarret
Copy link
Contributor

jarret commented Jan 14, 2020

I was having problems similar to what was described using circular payments borrowing logic from sendinvoiceless.py on a different project that traced back to an issue with the cltv-final setting.

By default, C-Lightning will only accept 10 blocks as the final hop cltv for the route back to oneself. sendinvoiceless.py checks that boot arg and uses that as the final routing hop cltv. However, if a block arrives during the operation (which can span a couple seconds to execute, depending), the final hop on the circular route back to itself will get rejected and the payment will fail.

After padding that cltv-final value on the route construction (the equivalent of setup_routing_fees() in sendinvoiceless.py) by 3 blocks, I no longer had the same intermittent failures. It looks like the script has an option to set that value for sendinvoiceless.py which can be greater than the default cltv-final boot arg.

@ghost
Copy link
Author

ghost commented Jan 14, 2020

@jarret thanks I will look into it later because I have not time now but at first sight it doesn't seem to make a difference.

@ghost
Copy link
Author

ghost commented Jan 14, 2020

@jarret Should I put (for example) cltv-final=20 in config in .lightning?

@jarret
Copy link
Contributor

jarret commented Jan 14, 2020

hmm, both the lightningd boot arg option and the plugin option are both called cltv-final, so I am not sure which one will be adjusted as a result (and that namespace collision is probably a problem that should be fixed).

Maybe edit the script to pad on a higher value to use for setup_routing_fees() for now?

@ghost
Copy link
Author

ghost commented Jan 14, 2020

I changed:

plugin.add_option('cltv-final', 10, 'Number of blocks for final CheckLockTimeVerify expiry')

into

plugin.add_option('cltv-final', 20, 'Number of blocks for final CheckLockTimeVerify expiry')

in sendinvoiceless.py but that didn't change anything after restarting c-lightning. Remember it worked before and I don't think for the routes anything has changed because myshtery needed 6 hops instead of 4 hops which seems to indicate the same route was used as before when Bitkoins.nl still worked the first time I paid.

@darosior
Copy link
Member

darosior commented Jan 14, 2020

hmm, both the lightningd boot arg option and the plugin option are both called cltv-final, so I am not sure which one will be adjusted as a result (and that namespace collision is probably a problem that should be fixed).

It is indeed. It results from the plugin option to not be set, you can inspect it with listconfigs.

Regarding the issue it seems related to ElementsProject/lightning#3376.
EDIT: @sumBTC I think increasing your cltv-final in your config would solve that. You were setting it in the plugin, which had the effect of not having any effect.

@jarret
Copy link
Contributor

jarret commented Jan 14, 2020

I changed:

plugin.add_option('cltv-final', 10, 'Number of blocks for final CheckLockTimeVerify expiry')

into

plugin.add_option('cltv-final', 20, 'Number of blocks for final CheckLockTimeVerify expiry')

Looks like in the init function, it overwrites that value with whatever is obtained from the listconfigs rpc call, so this change isn't doing anything.

@ghost
Copy link
Author

ghost commented Jan 14, 2020

@darosior I've set cltv-final to 20 in .lightning/config and I also see that value with lightning-cli listconfigs and it worked! I got:

"1000000 msat delivered with 1010 msat fee over 7 hops"

Thanks both of you for all the help!

Closing this issue.

@ghost ghost closed this as completed Jan 14, 2020
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants