multi: implement latest multi-frame EOB proposal #36
Closed
Roasbeef wants to merge 10 commits intolightningnetwork:masterfrom
Closed
multi: implement latest multi-frame EOB proposal #36Roasbeef wants to merge 10 commits intolightningnetwork:masterfrom
Roasbeef wants to merge 10 commits intolightningnetwork:masterfrom
Conversation
We'll be encoding to and decoding from a variable length byte-slice once we complete the multi-hop proposal. Signed-off-by: Christian Decker <decker.christian@gmail.com>
This was referenced May 14, 2019
Closed
…frames Since we want to use multiple former per-hop-payloads as a single payload, we want to differentiate the notion of a frame from a payload, since the latter can be now be made up of multiple frames. Signed-off-by: Christian Decker <@cdecker>
HopPayload represents the raw, unparsed payload, from which the HopData can be parsed. The sphinx code internally only handles HopPayload, and the `HopData()` method can be used to parse and return the HopData. This completes the transition to HopPayload. Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is the central commit in this whole series, it modifies the right- and left- shifts to account for multi-frame payloads and it modifies the filler generation code to generate multi-frame fillers if the payload requires it. Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is a simple test that create a 5 hop onion, and the third hop gets a payload that spans 2 frames. Signed-off-by: Christian Decker <decker.christian@gmail.com>
This should make testing a lot easier, since we can just have a bunch of these sitting in the repo and test them. Signed-off-by: Christian Decker <decker.christian@gmail.com>
In this commit, we move the HopData struct back into path.go. Along the way, we remove its old HMAC field (since it's now in the hop payload), and also restore its Decode method for later use.
In this commit, we add a new constructor to abstract away the details of the hop payload framing from the caller. This new function accepts the hop data, as well as optional EOB bytes. We'll then map these two pieces of data into a single hop payload by appending the EOB bytes to the serialized hop data.
Rather than mutate the underlying realm byte, we'll now expose two methods to the caller: one for the "external" realm, and one of the realm that we'll encode in the payload.
In this commit, we remove the HopData field from the OnionHop struct as it's no longer needed since we can obtain the HopData via the HopData() method of the HopPayload struct. Additinoally, we also now return the set of unused payload bytes after the HopData encoding, we call these the EOB or extra onion blobs. With this distinction we now provide the caller of ProcessOnionPacket with the forwarding instructions, then the left over EOB bytes. These EOB bytes will then be interpreted using a TLV format or any other arbitrary framing system.
ysangkok
reviewed
May 14, 2019
| HopDataSize = (RealmByteSize + AddressSize + AmtForwardSize + | ||
| OutgoingCLTVSize + NumPaddingBytes + HMACSize) | ||
|
|
||
| // FramSize is the size of a frame in the packet. A frame is a region |
ysangkok
reviewed
May 14, 2019
| privkey, _ := btcec.PrivKeyFromBytes(btcec.S256(), binKey) | ||
| s := sphinx.NewRouter(privkey, &chaincfg.TestNet3Params, | ||
| sphinx.NewMemoryReplayLog()) | ||
| replay_log := sphinx.NewMemoryReplayLog() |
Member
Author
|
Superseded by #38. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This takes off where #31 and #33 left off. It implements the latest version of lightning/bolts#593 (4 bits right now, but I think that's heading to 3 bits for the packet type). At the same time with the way the code is implemented right now, it's a short distance away from lightning/bolts#604 if we end up going in that direction (only thing that would change in that case is the new
HopDatamethod and thepackRealmmethod).This PR takes the commits from #33, implements a few bug fixes along the way, and the unifies the external caller API with that of #31. It passes all the tests from #31 as is, but I also plan to port over relevant tests from #33 as they exercise additional end-to-end behavior.