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

BOLT 2: advise ping-before-commitment_signed on quiescent connections. #508

Merged
merged 3 commits into from Nov 29, 2018

Conversation

Projects
None yet
6 participants
@rustyrussell
Collaborator

rustyrussell commented Nov 14, 2018

This seems to be a cause of stuck HTLCs on the network: c-lightning has
done this for a while now (since 0.6.1).

Decided-at: Adelaide Summit 2018

BOLT 2: advise ping-before-commitment_signed on quiescent connections.
This seems to be a cause of stuck HTLCs on the network: c-lightning has
done this for a while now (since 0.6.1).

Decided-at: Adelaide Summit 2018
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

@rustyrussell rustyrussell added this to the v1.1 milestone Nov 14, 2018

@TheBlueMatt

No brainer. ACK.

that networks are unreliable: nodes might not realize their peers are
offline until after sending `commitment_signed`. Once
`commitment_signed` is sent, the sender considers itself bound to
those HTLCs, and cannot close incoming HTLCs.

This comment has been minimized.

@pm47

pm47 Nov 14, 2018

Collaborator
Suggested change Beta
those HTLCs, and cannot close incoming HTLCs.
those HTLCs, and cannot fast-fail related incoming HTLCs anymore.

This comment has been minimized.

@rustyrussell

rustyrussell Nov 19, 2018

Collaborator

How about 'cannot fail incoming the related incoming HTLCs until the output HTLC is fully resolved'?

This comment has been minimized.

@ZmnSCPxj

ZmnSCPxj Nov 23, 2018

Collaborator

Agree with @pm47, "close" for HTLC seems wrong/too undetailed here. Both @pm47 and @rustyrussell rewordings seem fine.

@@ -936,6 +936,8 @@ change the commitment transaction aside from the new revocation hash
fee changes).
- MUST include one `htlc_signature` for every HTLC transaction corresponding
to BIP69 lexicographic ordering of the commitment transaction.
- if it has not recently received a message from the remote node:
- SHOULD use `ping` and await the reply `pong` before sending `commitment_signed`.

This comment has been minimized.

@pm47

pm47 Nov 14, 2018

Collaborator

Can we also say alternatively that a node should regularly ping its peers? That's easier to implement and achieves almost the same goal.

We don't need to as Matt pointed out

@TheBlueMatt

This comment has been minimized.

Contributor

TheBlueMatt commented Nov 15, 2018

@renepickhardt

This comment has been minimized.

renepickhardt commented Nov 16, 2018

just to make sure I get this correctly. this does not mean we ping every node in the route that we are creating in the onion but just our direct channel partner.
Since we assume every node on the route does so they will send an error message if they can't forward the HTLC since the pong did not arrive in time.

What are the disadvantages with my suggestion that the payee pings all hopes on the path of the designated onion package? If any node does not pong in time we can reduce the traffic on all other nodes on the path up to that node.

@rustyrussell

This comment has been minimized.

Collaborator

rustyrussell commented Nov 19, 2018

just to make sure I get this correctly. this does not mean we ping every node in the route that we are creating in the onion but just our direct channel partner.

This applies to any node about to send an HTLC, not just the originator of a payment.

Since we assume every node on the route does so they will send an error message if they can't forward the HTLC since the pong did not arrive in time.

What are the disadvantages with my suggestion that the payee pings all hopes on the path of the designated onion package? If any node does not pong in time we can reduce the traffic on all other nodes on the path up to that node.

You could do that, but it's orthogonal; each node wants to know if the HTLC will get stuck, so each node should do a liveness check before committing to HTLCs.

that networks are unreliable: nodes might not realize their peers are
offline until after sending `commitment_signed`. Once
`commitment_signed` is sent, the sender considers itself bound to
those HTLCs, and cannot fail incoming the related incoming HTLCs until the

This comment has been minimized.

@ZmnSCPxj

ZmnSCPxj Nov 26, 2018

Collaborator

Wording problem? "fail incoming the related incoming"...?

@rustyrussell

This comment has been minimized.

Collaborator

rustyrussell commented Nov 26, 2018

Will fix double-wording by removing incoming

@Roasbeef

LGTM 🏎

@rustyrussell rustyrussell merged commit 20524d4 into lightningnetwork:master Nov 29, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment