-
Notifications
You must be signed in to change notification settings - Fork 492
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
Clarify onions part 2: a bit deeper rework #1182
Clarify onions part 2: a bit deeper rework #1182
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.
Thanks, this is now much better! The individual commits are easy to follow and all make sense, and the end result looks good to me!
…` type there. It's currently buried in the onion message section, but it applies to payments too. We now have a separate sub-section for the encrypted_data_tlv definition. Signed-off-by: Rusty Russell <[email protected]>
…nstructing. This spec was initially written before the `blinded_path` type existed. Be precise (and we no longer need to say "MUST communicate"!). Signed-off-by: Rusty Russell <[email protected]>
Writer parts: 1. Be explicit that the writer creates a route. 2. Make it clear we create shared secrets, then derive blinded points. 3. Refer explicitly to all `blinded_path` fields. Split reader into the *two* readers: 1. The reader of the blinded path, who uses it to make an onion (which wasn't described at all!) 2. The reader of the encrypted_recipient_data, who decrypts it. In the latter case, we don't have to discuss unblinding the onion since that's now covered in the "Onion Decryption" section. Signed-off-by: Rusty Russell <[email protected]>
It's a bit complex, but try to convey the idea of an introduction point, blinded node ids and encrypted blobs. Since the requirements detail the two ways to reach the introduction node, I handwaved on that a bit. Signed-off-by: Rusty Russell <[email protected]>
It was mentioned in the rationale only. Signed-off-by: Rusty Russell <[email protected]>
It's used for blinded payment paths, too, not just onion messages. Suggested-by: @t-bast Signed-off-by: Rusty Russell <[email protected]>
OK:
|
fbb914a
to
6654c57
Compare
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.
Thanks, this looks good! Can you also update route-blinding-test.json
? It contains fields called ephemeral_pubkey
and ephemeral_privkey
, which is confusing and should be replaced by path_key
and path_privkey
.
1. Always use the term `encrypted_recipient_data` for the encrypted field: it's confusing enough without multiple names! 2. Don't give an option for joining blinded payments, since everyone will use an unblinded payment to the introduction node (at least, for now). 3. Avoid the term "payer" and at least note that encrypted_recipient_data can be made by the sender themselves, pointing out that the forwarding node cannot tell. Thanks t-bast and gijswijs for this feedback! Signed-off-by: Rusty Russell <[email protected]>
Bastien points out we didn't update this when we changed terms. Signed-off-by: Rusty Russell <[email protected]>
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 0aae209
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.
Reads a lot more clearly to me! The new section on path concatenation clarifies a lot. A good amount of the additions to BOLT 4 seem a bit redundant to what's in proposals/route_blinding.me
but that seems ok.
@Roasbeef can you take a quick look at this PR? As discussed during yesterday's spec meeting, we should merge this once we have your ACK :) |
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 🎫
|
||
The writer of a `blinded_path`: | ||
|
||
- MUST create a viable path to itself ($`N_r`$) i.e. $`N_0 \rightarrow N_1 \rightarrow ... \rightarrow N_r`$. |
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.
😎
This is based on #1181 (first four commits), and replaces #1179 based on feedback there.
You're going to want to review one commit at a time: I rewrote it to be managable to review.
blinded_path
elementsBasically, nothing changes, but hopefully it will be more digestable in future!