-
Notifications
You must be signed in to change notification settings - Fork 491
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 4: Remove legacy format, make var_onion_optin compulsory. #962
BOLT 4: Remove legacy format, make var_onion_optin compulsory. #962
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a typo to fix and should be ready to go.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACK 7a6291d, I'll prepare a branch to remove the legacy code in eclair as well.
Actually while updating eclair, I realized that we should also update the test vectors:
That does mean a bit more work to do (sorry!). |
We previously supported a 65-bytes fixed-size sphinx payload, which has been deprecated in favor of variable length payloads containing a tlv stream (see lightning/bolts#619). It looks like the whole network now supports the variable-length format, so we can stop accepting the old one. It is also being removed from the spec (see lightning/bolts#962).
Hmm, I'm out of time to update the multiframe test, though you're right :( |
Ping @cdecker ? |
As per proposal in lightning/bolts#962 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Removed: protocol: support for legacy onion format removed, since everyone supports the new one.
Concept ACK, we'll likely start with just making our existing feature bit required, as we have some existing tests that still assume this is relevant. |
As per proposal in lightning/bolts#962 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Removed: protocol: support for legacy onion format removed, since everyone supports the new one.
As per proposal in lightning/bolts#962 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Removed: protocol: support for legacy onion format removed, since everyone supports the new one.
As per proposal in lightning/bolts#962 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Removed: protocol: support for legacy onion format removed, since everyone supports the new one.
As per proposal in lightning/bolts#962 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Removed: protocol: support for legacy onion format removed, since everyone supports the new one.
In this commit, we start to advertise the required feature bit for the new modern TLV onion format. In a future change, we'll remove the logic for being able to encode+encode the payload. For now, we still have tests that exercise being able to use the new and old formats (as well as both of them in a single route), so we'll continue to retain that behavior for now. Implements lightning/bolts#962.
As per proposal in lightning/bolts#962 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> Changelog-Removed: protocol: support for legacy onion format removed, since everyone supports the new one.
I'm looking at our node's statistics, and a non-negligible portion (~30%) of the payments we relay are still using the legacy format. |
|
In that case that's probably not the culprit since more than 99% of nodes (including ours) advertise |
on c-lightning IRC we have a crash report due to the old onion format too!
|
I find c-lightning should definitely not be crashing, even with the legacy encoding disabled it should simply fail the adds with a |
Some ppl on Twitter hypothesized that maybe a lot of the traffic is actually probing. I know in the past, some systems/applications would use an API for lnd that accept a raw routes for probing. I dug into things on our end, and realized that unless a user is setting some custom TLV record in the route (also not using mpp/amp), we'll default to using the legacy payload (there's a bool that defaults to false). So this might be contributing to that 30% number mentioned above... We have a new major release coming up, so this could be an opportunity to change our API to default to the modern payload (can't thing of any downside really). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ❄️
Confirmed: my node has seen no legacy since 17 June (over 12000 htlcs fwd since then), and the one before that was 2 July. He's dead, Jim! |
7a6291d
to
63b8b25
Compare
Squashed into a single commit, and included the test vector fixups. Will test them today... |
Ack test vectors! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of nits, otherwise LGTM, let's kill this thing!
bolt04/onion-test.json
Outdated
@@ -0,0 +1,37 @@ | |||
{ | |||
"comment": "A testcase for a variable length hop_payload. The third payload is 256 bytes long.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like I forgot to update this comment, the third payload isn't 256 bytes long!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, fixed to "275 bytes long".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies for leaving this comment only after the PR has been merged, but I believe the "comment" is still incorrect as it's the fifth payload that is 275 bytes long, no?
There's also the second payload that's 83 bytes long, so there's now two payloads that have a different size than the rest of the payloads, so perhaps it'd be worth mentioning both if we want to explicitly mention the payloads that have a different size. If you'd like me to, I can of course open a PR editing the "comment" :).
My measurements a few weeks ago reveal that only 5 nodes do not advertize this feature, of over 17000. I have a patch to remove support from c-lightning, too. [ 6 months later: t-bast notes that they only see 0.2% of htlcs using legacy, and my node hasn't seen one for 2 months w/ 12000 htlcs --RR ] Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
To only use valid tlv payloads instead of fixed-size legacy ones and invalid tlv streams. [ Minor typo change: third payload is 275 not 256 bytes long --RR ]
63b8b25
to
e5cfdf2
Compare
This has been removed from the spec recently, see: lightning/bolts#962
This has been removed from the spec recently, see: lightning/bolts#962
This has been removed from the spec recently, see: lightning/bolts#962
This has been removed from the spec recently, see: lightning/bolts#962
* Add support for arbitrary length onion errors The specification recommends using a length of 256 for onion errors, but it doesn't say that we should reject errors that use a different length. We may want to start creating errors with a bigger length than 256 if we need to transmit more data to the sender. In order to prepare for this, we keep creating 256-bytes onion errors, but allow receiving errors of arbitrary length. * Remove support for legacy fixed-size onion payload This has been removed from the spec recently, see: lightning/bolts#962
In this commit, we start to ignore the option to allow the caller to use the legacy onion payload. The new payload is much more flexible and efficient, so there's really no reason to still use it, other than for backwards compatibility tests. Our existing tests that exercise the legacy feature uses a build tag, which forces nodes to not advertise the new payload format, which then forces path finding to include the legacy payload, so we can be confident that route is still being tested. The existence of this option (which actually makes the TLV payload opt-in for `SendToRoute` users) makes it harder to remove it from the protocol all together. With this PR, we take a step forward to allowing such a change which is being tracked on the spec level at: lightning/bolts#962. In a future release, we'll move to remove the field all together. Ignoring the field today doesn't seem to have any clear downsides, as most payments always include the MPP payload (due to payment secrets), so this shouldn't impact users in a significant way.
In this commit, we start to ignore the option to allow the caller to use the legacy onion payload. The new payload is much more flexible and efficient, so there's really no reason to still use it, other than for backwards compatibility tests. Our existing tests that exercise the legacy feature uses a build tag, which forces nodes to not advertise the new payload format, which then forces path finding to include the legacy payload, so we can be confident that route is still being tested. The existence of this option (which actually makes the TLV payload opt-in for `SendToRoute` users) makes it harder to remove it from the protocol all together. With this PR, we take a step forward to allowing such a change which is being tracked on the spec level at: lightning/bolts#962. In a future release, we'll move to remove the field all together. Ignoring the field today doesn't seem to have any clear downsides, as most payments always include the MPP payload (due to payment secrets), so this shouldn't impact users in a significant way.
My measurements a few weeks ago reveal that only 5 nodes do not advertize this feature, of over 17000. I have a patch to remove support from c-lightning, too.