Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Onion format variation a-la @roasbeef (vs #593) #604
I based it on #593 so the differences are clear. It leaves realm 0 alone (naming it legacy), just defines realms 1-15.
These are TLVs, which in is a win for the final node since
(See #603 which explicitly describes that encoding smaller numbers with fewer than 8 bytes in a TLV is allowed).
referenced this pull request
May 6, 2019
I'm fine with this small tweak. If I'm not missing anything it achieves the same tradeoffs as @cdecker's proposal, in fact the only change is that the least significant bits of the
We have room for new messages in two different places:
I think that this is clearly enough for the foreseeable future (and it achieves both backwards-compatibility and simplicity, which is very important to get it deployed smoothly).
In the longer term, we know we want to change a few things in a version 1 of the onion message (per-hop versioning for example). Version 1 can be an opportunity to provide even more room for new messages if developers can't achieve what they want with version 0.
All those reasons make this a good pragmatic proposal which could unblock trampoline/rendezvous routing and I think we should move forward. If we all agree with that, we only need test vectors for the new realm values and the feature bit and we should be good to go.
Roasbeef left a comment
This addresses my objection to bit-packing the packet type + number of frames into the realm byte, but it doesn't (to my current reading) address the small number of possible types for TLV in the onion.
I think a much smaller modification to the prior proposal is possible compared to the iteration in this PR. As is, it completely re-defines the current hop data payloads which results in additional code impact for all nodes involved in a route. I think completely re-defining the hop payload is an interesting idea that demonstrates the flexibility of TLV in the onion packets in general, but one that seems tangential to allowing nodes to add structure to the currently unused extra blob data.
Thinking about this more, I really like the signaling unification and also clean slate for the payload for each hop. In comparison, the other proposal made the payloads into a hybrid of the old and new, while with this, payloads are just opaque blobs to be passed up (which lets us do things like shave the short id for the final hop) . Also to my reading, the prior proposal left the current 13 padding bytes unutilized, while with this there's no longer any distinction.…
On Sun, May 5, 2019, 11:34 PM Rusty Russell ***@***.***> wrote: This splits the difference between #593 <#593> from @cdecker <https://github.com/cdecker> and comments from @Roasbeef <https://github.com/Roasbeef> I based it on #593 <#593> so the differences are clear. It leaves realm 0 alone (naming it legacy), just defines realms 1-15. These are TLVs, which in is a win for the final node since short_channel_id is unnecessary there. (See #603 <#603> which explicitly describes that encoding smaller numbers with fewer than 8 bytes in a TLV is allowed). ------------------------------ You can view, comment on, or merge this pull request online at: #604 Commit Summary - bolt04: Formatting cleanup and fold clarifications into conventions - bolt04: Introduce the notion of frames and make payloads variable - bolt04: Update the technical description of the multi-frame proposal - bolt04: Move the test vectors into JSON documents - bolt04: Update spell check dictionary - BOLT 4: leave legacy realm byte alone, use values 1-15 for multi-frame / TLV. File Changes - *M* .aspell.en.pws <https://github.com/lightningnetwork/lightning-rfc/pull/604/files#diff-0> (17) - *M* 04-onion-routing.md <https://github.com/lightningnetwork/lightning-rfc/pull/604/files#diff-1> (547) - *A* bolt04/onion-error-test.json <https://github.com/lightningnetwork/lightning-rfc/pull/604/files#diff-2> (43) - *A* bolt04/onion-test-v0.json <https://github.com/lightningnetwork/lightning-rfc/pull/604/files#diff-3> (62) Patch Links: - https://github.com/lightningnetwork/lightning-rfc/pull/604.patch - https://github.com/lightningnetwork/lightning-rfc/pull/604.diff — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#604>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHTWLVMIEVKX7ICP6JEWLLPT7GQ5ANCNFSM4HK5OYQQ> .