-
Notifications
You must be signed in to change notification settings - Fork 895
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
lnd c-lightning incompatibility #3920
Comments
I assume this is after the c-lightning node was restarted, i.e., it loaded the pending HTLCs from the database. Could it be that you are using the postgresql backend? If that's the case it could be that a simple For context: |
This was on a Debian box and the dependencies were installed by following the installation docs. So I installed libsqlite3-dev. I don't believe postgres was used since I didn't install it. |
Interesting, if you didn't specify a postgres wallet, then you'll have used the default
To me it seems like the latter at this point. Do you have logs for the c-lightning side, and specifically do you have logs regarding the HTLC in question? |
I have complete logs for this, where would you like them? |
Hmm, please try: That will tell us what htlcs it's trying to send, to be sure. |
We had one report of this, and then Eugene and Roasbeef of Lightning Labs confirmed it; they saw misordered HTLCs on reconnection too. Since we didn't enforce this when we receive HTLCs, we never noticed :( Fixes: ElementsProject#3920 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had one report of this, and then Eugene and Roasbeef of Lightning Labs confirmed it; they saw misordered HTLCs on reconnection too. Since we didn't enforce this when we receive HTLCs, we never noticed :( Fixes: ElementsProject#3920 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: Protocol: fixed retransmission order of multiple new HTLCs (causing channel close with LND)
We had one report of this, and then Eugene and Roasbeef of Lightning Labs confirmed it; they saw misordered HTLCs on reconnection too. Since we didn't enforce this when we receive HTLCs, we never noticed :( Fixes: ElementsProject#3920 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: Protocol: fixed retransmission order of multiple new HTLCs (causing channel close with LND)
We had one report of this, and then Eugene and Roasbeef of Lightning Labs confirmed it; they saw misordered HTLCs on reconnection too. Since we didn't enforce this when we receive HTLCs, we never noticed :( Fixes: ElementsProject#3920 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: Protocol: fixed retransmission order of multiple new HTLCs (causing channel close with LND)
We had one report of this, and then Eugene and Roasbeef of Lightning Labs confirmed it; they saw misordered HTLCs on reconnection too. Since we didn't enforce this when we receive HTLCs, we never noticed :( Fixes: ElementsProject#3920 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: Protocol: fixed retransmission order of multiple new HTLCs (causing channel close with LND)
We had one report of this, and then Eugene and Roasbeef of Lightning Labs confirmed it; they saw misordered HTLCs on reconnection too. Since we didn't enforce this when we receive HTLCs, we never noticed :( Fixes: ElementsProject#3920 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Fixed: Protocol: fixed retransmission order of multiple new HTLCs (causing channel close with LND)
When restoring HTLC's, c-lightning will send the HTLC's out of order (i.e. not monotonically increasing) which lnd doesn't expect. Example log output from lnd:
If c-lightning logs are needed, I can send those over. Thanks.
The text was updated successfully, but these errors were encountered: