bolt04: Variable `hop_payload` for the sphinx onion #619

cdecker · 2019-06-06T19:37:13Z

This is the variable payload length variant of #593. It removes the concept of fixed-length frames, in favor of just prefixing the payload with its varint-encoded length, followed by the HMAC.

The varint is limited to 1 and 3 byte encodings, since the maximum length of the payload is 1300 - 32 - 3 bytes, and the 5 and 9 byte varints are not useful. The HMAC is not part of the payload since it allows us to fit more of the shorter lengths in the single byte varint.

I didn't update the example code yet, since the Go version was not migrated yet, but it should not be too much work to update that later.

t-bast

Good stuff, only nit comments from me.

Maybe the only thing that we could discuss is the option of including the HMAC inside the hop_payload to be able to remove it entirely from the last hop and save 32 bytes (because the fact that a hop is the last hop can be encoded more efficiently than with 32 0x00 bytes)?

EDIT: in fact it probably isn't a good idea to put the HMAC inside the hop_payload, because it would cost 2 additional bytes per hop (the type and length, and potentially might require 3 bytes instead of 1 for the hop_payload length) so it ends up costing more than 32 0x00 bytes in the last hop for long routes. You can ignore that comment.

04-onion-routing.md

bolt04/onion-test-multi-frame.json

t-bast · 2019-06-11T09:25:33Z

@cdecker I think the feature flag that was included in #593 didn't make it to this PR, could you re-add it?

t-bast · 2019-06-14T10:03:31Z

@Roasbeef would you have time to review this PR to unblock merging it?

Roasbeef

In addition to lack of the specification for the varint, I think this PR is also missing:

the new feature bit selection
an updated section on the new feature generation

I also think that we should keep the existing realm field in place. Otherwise, we're more or less locked into this new format for the current onion version, and it also makes code that handles the current and legacy format more complex.

One other thing that stands out is that since the encoded integers for the hop payload are variably sized, there isn't a clear "max route length" any longer. Instead, it's now dependent on the encoded size of each of these fields which makes things a bit harder to analyze.

04-onion-routing.md

Roasbeef · 2019-06-18T02:02:37Z

04-onion-routing.md

+
+The `length` field determines both the length and the format of the `hop_payload` field; the following formats are defined:
+
+ - Legacy `hop_data` format, identified by a `0x00` length.


by a single byte 0x00 length?

Otherwise will 0x00 and 0x00 0x00 0x00 both mean to parse the legacy format?

Yes, a single byte 0x00 is more precise. The second option would be invalid for minimal encoding anyway :-)

Roasbeef · 2019-06-18T02:34:39Z

04-onion-routing.md


 For each hop in the route, in reverse order, the sender applies the
 following operations:

 - The _rho_-key and _mu_-key are generated using the hop's shared secret.
- - The `hops_data` field is right-shifted by 65 bytes, discarding the last 65
+ - `shift_size` is defined as the length of the `hop_payload` plus the varint encoding of the length and the length of that HMAC. Thus if the payload is `l` then the `shift_size` is `1 + l + 32` for `l < 253`, otherwise `3 + l + 32` due to the varint encoding of `l`.


This varint encoding isn't defined anywhere in this PR.

The Go code below also needs to be updated as it still references constants which are fixed values rather than variable due to the new payload format.

Yeah, I didn't implement the Go version, so I can replace the code with the C version only.

Gotcha, after I update can slot it in.

Roasbeef · 2019-06-18T02:38:27Z

04-onion-routing.md


 For each hop in the route, in reverse order, the sender applies the
 following operations:

 - The _rho_-key and _mu_-key are generated using the hop's shared secret.
- - The `hops_data` field is right-shifted by 65 bytes, discarding the last 65
+ - `shift_size` is defined as the length of the `hop_payload` plus the varint encoding of the length and the length of that HMAC. Thus if the payload is `l` then the `shift_size` is `1 + l + 32` for `l < 253`, otherwise `3 + l + 32` due to the varint encoding of `l`.


I think it should be:

if the length of the payload is l

Roasbeef · 2019-06-18T03:17:19Z

Hey @t-bast, I don't think I'm blocking anything here. This PR as is is underspecified, and there're comments that are a week or two old which are currently unaddressed.

t-bast · 2019-06-18T07:55:16Z

@Roasbeef there probably was some miscommunication here, but we had an action item in the IRC meeting to get your feedback on this PR (because the rest of us were ok with the proposal), which is why I think @cdecker was waiting for your comments before fixing the others (which were mainly nits).

cdecker · 2019-06-18T14:03:48Z

@Roasbeef there probably was some miscommunication here, but we had an action item in the IRC meeting to get your feedback on this PR (because the rest of us were ok with the proposal), which is why I think @cdecker was waiting for your comments before fixing the others (which were mainly nits).

No, I'm just working on other stuff in the meantime, since we won't merge this before monday anyway, I thought I'd better work on more pressing issues first. @Roasbeef wasn't really blocking anything here :-)

t-bast · 2019-06-18T14:13:53Z

since we won't merge this before monday anyway

Damn, I had misunderstood the last meeting's outcome, I got my hopes up for nothing then 😬

I'd love to help move this forward though as TLV + variable-length onion are the two features that unblock many other cool things (with non-negligible user impact).

Is there something I can help with or are you good? I can for example pick up the update of the Go implementation if no-one has time to work on it.

cdecker · 2019-06-18T20:12:16Z

Added a bunch of fixups mostly addressing @t-bast's feedback. Will see if it makes sense to keep the old payload section in place, or whether it just reads better by restructuring.

I'm not planning on implementing the Go version, so if @t-bast wants to do it, that'd work for me 😁

Sorry for the mixup, I was under the impression we wanted to discuss one last time on Monday.

cdecker · 2019-06-18T20:19:57Z

In addition to lack of the specification for the varint, I think this PR is also missing:

the new feature bit selection

I cherry-picked the commits defining the feature bit from #593 now.

an updated section on the new feature generation

I'm not sure I understand what you mean by this.

I also think that we should keep the existing realm field in place. Otherwise, we're more or less locked into this new format for the current onion version, and it also makes code that handles the current and legacy format more complex.

I can restore that section if it makes sense in the text. As for lockin, that's pretty much guaranteed at this point, sadly. That was one of the advantages of the multi-frame proposal, namely that we'd be left with some bits to define future, non-TLV, payload types.

One other thing that stands out is that since the encoded integers for the hop payload are variably sized, there isn't a clear "max route length" any longer. Instead, it's now dependent on the encoded size of each of these fields which makes things a bit harder to analyze.

Indeed, I have now removed any reference to 20 being the maximum route length, since that's no longer true. This was incidentally also the main reason I was holding on to the 65 frame size, it made sure that 20 would really be the maximum length. Not sure if this is a feature or a bug with the variable length payload tbh 😉

cfromknecht

@cdecker a couple things from me, see inline comments

@t-bast i don't think we are blocked on the implementation when we're still hammering out the details of the proposal

cfromknecht · 2019-06-18T21:27:12Z

04-onion-routing.md


-1. type: `per_hop` (for `realm` 0)
+ - Legacy `hop_data` format, identified by a `0x00` length.
+ - `tlv_payload` format, identified by any other length.


imo it'd be preferable to keep the realm byte/version in-tact, and just call this the version 1 hop_data format. i'm hesitant to nerf future versioning of the inner payload format, given that the upgrade path of the outer version is unclear at this point.

we could even move to signal the final hop by setting the high order realm bit instead of using an empty hmac, saving 32-num_hops bytes

04-onion-routing.md

t-bast · 2019-06-19T07:40:25Z

04-onion-routing.md

+    - The legacy `hop_data` is identified by a single `0x00`-byte prefix
+	- The variable length `hop_payload` is prefixed with a `varint` encoding
+      the length in bytes, excluding the prefix and the trailing HMAC.
+ - This specification makes us of available length encoded integer format,


Suggested change

- This specification makes us of available length encoded integer format,

- This specification makes use of available length encoded integer format,

04-onion-routing.md

t-bast · 2019-06-19T07:50:08Z

04-onion-routing.md

+## Legacy `hop_data` payload format
+
+The `hop_data` format is identified by a single `0x00`-byte length, for backward compatibility.
+It's payload is defined as:


Suggested change

It's payload is defined as:

Its payload is defined as:

04-onion-routing.md

t-bast · 2019-06-19T08:01:14Z

04-onion-routing.md

 bytes that exceed its 1300-byte size.
- - The `version`, `short_channel_id`, `amt_to_forward`, `outgoing_cltv_value`,
-   `padding`, and `HMAC` are copied into the following 65 bytes.
+ - The varint-serialized length, serialized `hop_payload` and `HMAC` are copied into the following `shift_size` bytes.
 - The _rho_-key is used to generate 1300 bytes of pseudo-random byte stream
 which is then applied, with `XOR`, to the `hops_data` field.


Suggested change

which is then applied, with `XOR`, to the `hops_data` field.

which is then applied, with `XOR`, to the `hop_payloads` field.

t-bast · 2019-06-19T08:12:25Z

@t-bast i don't think we are blocked on the implementation when we're still hammering out the details of the proposal

I think that most of the proposal makes sense to implement now to be able to provide spec feedback. For example there's a mention that dropping the realm byte makes it hard in the code to handle legacy and new format. That wasn't really an issue for my implementation and I don't see how re-adding the realm byte would make the implementation simpler (it does provide a way out of TLV though, that argument remains valid).

But if you feel this is not necessary right now, I won't do anything on the go implementation, let me know if you need a hand at some point.

04-onion-routing.md

cfromknecht · 2019-06-20T09:15:34Z

04-onion-routing.md

+
+The reader:
+  - MUST return an error if `amt_to_forward` or `outgoing_cltv_value` are not present.
+  - MUST return an error if it is not the final node and `short_channel_id` is not present.


Given that the proposal currently uses the HMAC to signal the exit hop, enforcing these requires a lookahead since the HMAC follows the TLV payload or remembering which types the TLV payload contained when checking the HMAC :( Ideally the final hop would be signaled before parsing the TLV payload, making it possible to enforce these requirements while parsing the packet linearly.

Perhaps this is another argument for signaling the final hop in the realm byte and dropping the final HMAC?

I think we should add a signal in the TLV (making it a low type such that it gets processed first)?

That means that the onion processing layer needs to parse and interpret the TLV stream to look for a particular TLV type though, isn't this a layering violation? Whereas signaling via the realm byte might be a bit cleaner, don't you think?

Roasbeef · 2019-06-24T19:45:20Z

an updated section on the new feature generation

Oops, meant filler generation.

As for lockin, that's pretty much guaranteed at this point, sadly.

I don't think we're locked in if we leave the existing realm in place. I think all the prior iterations we went through have allowed us to explore the level of extensibility the current "realm" field as to offer. Would be shame if we closed off all future paths prematurely. I think we can get the best of both worlds by keeping the realm in place, and just using 2 fixed bytes for a length. 65KB is far larger than the max payload size in the onion, it simplifies parsing, and also allows us to avoid unnecessarily adding a var int into the protocol.

t-bast · 2019-06-25T08:39:48Z

I think all design comments (realm vs no realm, termination signaling via TLV) have been addressed during yesterday's meeting right?

There are still a few typos/nits and a clarification on the TLVs' integer notation, but apart from that are we missing something? What are the next steps before merging this?

@Roasbeef @cfromknecht are you happy with the current state of the proposal? :)

04-onion-routing.md

cdecker · 2019-06-29T03:11:39Z

I think we can get the best of both worlds by keeping the realm in place, and just using 2 fixed bytes for a length. 65KB is far larger than the max payload size in the onion, it simplifies parsing, and also allows us to avoid unnecessarily adding a var int into the protocol.

While I think we can discuss about leaving the realm byte intact, I'd definitely want to use the varint in there, it's a tiny change and it saves us up to 20 bytes in total. I'd actually argue that for a vast majority of cases we'll have payload lengths < 253 which results so we'd rarely ever use the 2 byte length prefix at all.

cdecker · 2019-06-29T03:18:33Z

an updated section on the new feature generation

Oops, meant filler generation.

The filler generation literally doesn't change, we just generate a bit more since we might be shifting a bit more.

t-bast · 2019-07-02T11:50:21Z

09-features.md

+|------|-------------------|-------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
+| Bits | Name              | Description                                                 | Link                                                                                                             |
+|------|-------------------|-------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
+| 0/1  | `var_onion_optin` | This node requires/supports variable payload routing onions | [routing onion specification](https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md) |


If we want to be able to combine those with the local features (such as in #571) it would be better to use bits that aren't currently assigned (instead of 0/1).
I'll let you sync with @rustyrussell to see what bit values would make sense: many are tentatively assigned in #605 but I think var_onion_optin should replace one of those (since it's coming first). We probably need to update the list in #605.

Roasbeef · 2019-07-03T01:29:38Z

04-onion-routing.md

+
+1. tlv: `tlv_payload`
+2. types:
+    1. type: 0 (`destination_signal`)


So we have both a signal here and also a final set of zero bytes in the HMAC? I'm not sure we need another signal on this level, given that in the underlying Sphinx format, the zero'd HMAC is used as a tag for the final destination. This would also create two ways that packet processors are required to know of in order to determine if this is the final hop or not. This framing layer sits above the current onion layer IMO, meaning we're crossing layers here in order to detect a terminal point in the route.

Or will the HMAC be left in place, and this is just for the higher level TLV parser?

I currently kept both conditions in my implementation. If either the next packet's hmac is 0x00 or if the first byte of the TLV stream is 0x00 it means we are the last hop.
Instead of using TLV code inside the onion processor, I translated this condition as the first byte after the varint length of the payload is 0x00 (since TLV streams are ordered by TLV type values and this one as type 0x00).
I don't have a strong opinion on what we should do here because it's not necessarily the onion processor layer that need to figure out that we are the destination, it might make more sense that it's the layer that interprets the payload that should figure out that we are the destination.

If we leave the HMAC, we should continue to use it to signal termination.

Half-parsing the TLV this way is just nasty, as is the alternative of using type 0xFFFFFFFFFFFFFFFF to signal the HMAC (which, of course would always put it at the end), which loses more bytes across any normal route than skipping the terminal HMAC would!

Roasbeef · 2019-07-03T01:32:34Z

04-onion-routing.md

+	    * Empty
+    1. type: 2 (`amt_to_forward`)
+    2. data:
+        * [`integer`:`amt_to_forward`]


Still not clear what integer is from strictly reading this document. I think using varint here makes it more clear when combined with #622.

Should be tu64, agreed.

The clarifications were tacked on after the fact, but they should really be part of the conventions. I also updated the links to use the reference style, which results in better text flow and makes it easier to read the source. Signed-off-by: Christian Decker <decker.christian@gmail.com>

Signed-off-by: Christian Decker <decker.christian@gmail.com>

This actually introduces the variable size shift and filler generation. Signed-off-by: Christian Decker <decker.christian@gmail.com>

Signed-off-by: Christian Decker <decker.christian@gmail.com>

As discussed during the spec meeting this allows us not to use the 32 byte HMAC to identify the last hop, and use a 2-byte signal instead. Signed-off-by: Christian Decker <decker.christian@gmail.com>

@ysangkok

The tables were a bit unreadable in the source view, and the globalfeatures table was not rendering correctly. This is just a minor cleanup pass. Signed-off-by: Christian Decker <decker.christian@gmail.com> Suggested-by: Janus Troelsen <@ysangkok>

As discussed during the IRC meeting on 2019-07-22 this would have been a duplication of signals. It was decided to use one for now, with the option of coming back should we ever need the last 32 bytes of the onion.

cdecker · 2019-07-25T11:07:44Z

Rebased ^^

Here's the range-diff, to make it easier to look for changes during the rebase:

$ git range-diff $(git merge-base master origin/variable-onion)..origin/variable-onion master..variable-onion
 1:  4f4c3c3 =  1:  a93cc7f bolt04: Formatting cleanup and fold clarifications into conventions
 2:  dc7c2fc !  2:  29e7be9 bolt04: Describe the variable size `hop_payload`
    @@ -117,6 +117,6 @@
      When building the route, the origin node MUST use a payload for
      the final node with the following values:
     +
    - * `outgoing_cltv_value`: set to the final expiry specified by the recipient
    - * `amt_to_forward`: set to the final amount specified by the recipient
    - 
    + * `outgoing_cltv_value`: set to the final expiry specified by the recipient (e.g.
    +   `min_final_cltv_expiry` from a [BOLT #11](11-payment-encoding.md) payment invoice)
    + * `amt_to_forward`: set to the final amount specified by the recipient (e.g. `amount`
 3:  62d8d7b =  3:  2bff8e5 bolt04: Amend the filler generation and onion decoding to varpayload
 4:  cf0527b =  4:  3be749c bolt04: Remove in-spec test vector in favor of JSON test vector
 5:  be5add0 =  5:  74093fa bolt04: Add the TLV types for the new payload format
 6:  d0862a5 !  6:  6b2144c bolt04: Shut the spellchecker up
    @@ -14,12 +14,11 @@
      verifier
      verifiers
     @@
    - structs
    - CompactSize
    - encodings
    + BigSize
    + namespaces
    + tlvs
     +fips
     +rfc
     +varint
     +CompactSize
     +tlvs
    - \ No newline at end of file
 7:  b70ae1f =  7:  d3bb7f2 bolt07: Add feature bits for multi-frame support
 8:  82a73d2 =  8:  88e476f bolt04: Introduce the destination_signal to the tlv_payload
 9:  157a708 =  9:  35edd4e bolt09: Cleanup the feature bits tables and extract URLs into footer
10:  b06386f = 10:  437d79b bolt04: Remove TLV based termination signal

t-bast

ACK 437d79b

rustyrussell · 2019-07-26T00:33:37Z

Ack 437d79b

@cdecker please apply. I'd do it, but you deserve the honor :)

cdecker · 2019-07-26T09:39:21Z

Congrats everyone, this has been a long time in the making, but it got substantially better through the extensive feedback 👍 🎆

See lightning/bolts#619 and lightning/bolts#619 for discussion. Signed-off-by: Christian Decker <decker.christian@gmail.com>

04-onion-routing.md

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).

cdecker force-pushed the variable-onion branch from 5dad251 to 54f03d5 Compare June 6, 2019 19:41

t-bast reviewed Jun 7, 2019

View reviewed changes

cdecker mentioned this pull request Jun 10, 2019

Onion format variation a-la @roasbeef (vs #593) #604

Closed

t-bast mentioned this pull request Jun 11, 2019

Variable-length onion payloads ACINQ/eclair#976

Merged

Roasbeef requested changes Jun 18, 2019

View reviewed changes

cfromknecht reviewed Jun 19, 2019

View reviewed changes

t-bast reviewed Jun 19, 2019

View reviewed changes

cfromknecht reviewed Jun 19, 2019

View reviewed changes

04-onion-routing.md Outdated Show resolved Hide resolved

t-bast added the Meeting Discussion Raise at next meeting label Jun 19, 2019

cfromknecht reviewed Jun 20, 2019

View reviewed changes

cdecker force-pushed the variable-onion branch from 13033b7 to e6dbdba Compare June 24, 2019 18:17

joostjager reviewed Jun 27, 2019

View reviewed changes

04-onion-routing.md Outdated Show resolved Hide resolved

t-bast reviewed Jul 2, 2019

View reviewed changes

Roasbeef mentioned this pull request Jul 3, 2019

BOLT4: Correct hop count clarification #617

Closed

Roasbeef requested changes Jul 3, 2019

View reviewed changes

cdecker added 10 commits July 25, 2019 13:03

bolt04: Describe the variable size hop_payload

29e7be9

Signed-off-by: Christian Decker <decker.christian@gmail.com>

bolt04: Amend the filler generation and onion decoding to varpayload

2bff8e5

This actually introduces the variable size shift and filler generation. Signed-off-by: Christian Decker <decker.christian@gmail.com>

bolt04: Remove in-spec test vector in favor of JSON test vector

3be749c

Signed-off-by: Christian Decker <decker.christian@gmail.com>

bolt04: Add the TLV types for the new payload format

74093fa

Signed-off-by: Christian Decker <decker.christian@gmail.com>

bolt04: Shut the spellchecker up

6b2144c

bolt07: Add feature bits for multi-frame support

d3bb7f2

bolt04: Introduce the destination_signal to the tlv_payload

88e476f

As discussed during the spec meeting this allows us not to use the 32 byte HMAC to identify the last hop, and use a 2-byte signal instead. Signed-off-by: Christian Decker <decker.christian@gmail.com>

bolt04: Remove TLV based termination signal

437d79b

As discussed during the IRC meeting on 2019-07-22 this would have been a duplication of signals. It was decided to use one for now, with the option of coming back should we ever need the last 32 bytes of the onion.

cdecker force-pushed the variable-onion branch from b06386f to 437d79b Compare July 25, 2019 11:06

t-bast approved these changes Jul 25, 2019

View reviewed changes

cdecker merged commit d23f4b0 into master Jul 26, 2019

cdecker added a commit to cdecker/lightning that referenced this pull request Jul 26, 2019

sphinx: Switch to big-endian number encoding

ede7f88

See lightning/bolts#619 and lightning/bolts#619 for discussion. Signed-off-by: Christian Decker <decker.christian@gmail.com>

cdecker added a commit to cdecker/lightning that referenced this pull request Jul 26, 2019

sphinx: Switch to big-endian number encoding

eed19e6

See lightning/bolts#619 and lightning/bolts#619 for discussion. Signed-off-by: Christian Decker <decker.christian@gmail.com>

rustyrussell pushed a commit to ElementsProject/lightning that referenced this pull request Jul 30, 2019

sphinx: Switch to big-endian number encoding

78c7edb

See lightning/bolts#619 and lightning/bolts#619 for discussion. Signed-off-by: Christian Decker <decker.christian@gmail.com>

cfromknecht mentioned this pull request Aug 16, 2019

BOLT04: Atomic Multi-path Payments [feature 30/31] #658

Open

cfromknecht reviewed Aug 29, 2019

View reviewed changes

04-onion-routing.md Show resolved Hide resolved

cfromknecht mentioned this pull request Aug 30, 2019

BOLT04: use truncated u64 encoding for next_hop_id #663

Closed

t-bast mentioned this pull request Sep 19, 2019

04-onion-routing.md: Prepare for extra onion blob encoding. #507

Closed

joostjager mentioned this pull request Nov 3, 2019

Allow custom data fields in the htlc payload lightningnetwork/lnd#3670

Closed

joostjager mentioned this pull request Nov 14, 2019

Take into account max onion blob size when pathfinding lightningnetwork/lnd#3725

Closed

t-bast deleted the variable-onion branch September 22, 2021 06:52

t-bast mentioned this pull request Feb 25, 2022

Remove support for legacy Sphinx payloads ACINQ/eclair#2190

Merged


		The `length` field determines both the length and the format of the `hop_payload` field; the following formats are defined:

		- Legacy `hop_data` format, identified by a `0x00` length.

	- This specification makes us of available length encoded integer format,
	- This specification makes use of available length encoded integer format,

	which is then applied, with `XOR`, to the `hops_data` field.
	which is then applied, with `XOR`, to the `hop_payloads` field.

bolt04: Variable hop_payload for the sphinx onion #619

bolt04: Variable hop_payload for the sphinx onion #619

Conversation

cdecker commented Jun 6, 2019

t-bast left a comment • edited Loading

Choose a reason for hiding this comment

t-bast commented Jun 11, 2019

t-bast commented Jun 14, 2019

Roasbeef left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef commented Jun 18, 2019 • edited Loading

t-bast commented Jun 18, 2019

cdecker commented Jun 18, 2019

t-bast commented Jun 18, 2019

cdecker commented Jun 18, 2019

cdecker commented Jun 18, 2019

cfromknecht left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

t-bast commented Jun 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef commented Jun 24, 2019

t-bast commented Jun 25, 2019

cdecker commented Jun 29, 2019

cdecker commented Jun 29, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdecker commented Jul 25, 2019

t-bast left a comment

Choose a reason for hiding this comment

rustyrussell commented Jul 26, 2019

cdecker commented Jul 26, 2019

bolt04: Variable `hop_payload` for the sphinx onion #619

bolt04: Variable `hop_payload` for the sphinx onion #619

t-bast left a comment •

edited

Loading

Roasbeef commented Jun 18, 2019 •

edited

Loading