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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
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 <rusty@rustcorp.com.au>
This commit doesn't change the logic at all, it simply:
- removes `realm` from onion test vector
- cleans-up markdown formatting and indents
- fixes typos and missing parenthesis
- consistently uses `_` instead of `-` for field names
- fixes math formatting (including changes from #1169 and #1158)
Sure, it's used to derive a secret for blinding, but it's also used to derive the key
for encrypted_recipient_data. It's not used as a blinding factor *directly*.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This ties it together, saying what to use as associated data, blinding, and what to do on failure.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
There's currently a *description* of how to decrypt an onion, and some requirements
in forwarding. But it also applies to onion messages, so:
1. Turn the description into actual enumerated requirements.
2. Ensure the description covers both payload and messaging onions.
3. Include both methods to apply the blinding tweak.
4. Leave the actual handling of the extracted payload (payment vs messaging onion) to those specific sections (e.g. reporting failure)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* BOLT4: include `min_final_cltv_expiry_delta` in `max_cltv_expiry` calc
Include `min_final_cltv_expiry_delta` in the `max_cltv_expiry`
calculation. Also add a note that indicates that this field may be set
for the final node too. This is useful for the final node as then it
does not need to persist the path expiry separately and can rely on just
checking the `payment_relay` field when the payment arrives.
* BOLT4: include calculation for `total_cltv_delta` of a blinded path
Include an explicit formula to use for determining the total CLTV delta
of a blinded path so that it is clear that it should include the
recipient's `min_final_cltv_expiry_delta`.
* proposals: fix `max_cltv_expiry` value for final hop in example
More info
[here](https://github.com/lightning/bolts/issues/1174#issue-2371364610)
outlining why the example needed to be updated.
As noted previously, `channel_update`s in the onion failure packets
are massive gaping fingerprintign vulnerabilities - if a node
applies them in a publicly-visible way the err'ing node can easily
identify the sender of an HTLC.
While the updates are still arguably marginally useful for nodes to
use in their pathfinding local to retires of the same payment, this
too will eventually become an issue with PTLCs. Further, we
shouldn't be letting nodes get away with delaying payments by
failing to announce the latest channel parameters or enforcing new
parameters too soon, so treating the node as having indicated
insufficient liquidity (or other general failure) is appropriate
in the general case.
Thus, here, we begin phasing out the `channel_update` field,
requiring nodes ignore it outside of the current payment and making
it formally optional (though nodes have been doing this for some
time due to various bugs).
Because some nodes may want to use update data on mobile when they
have stale gossip data, it is left optional.
To avoid timing analysis when decrypting failed payments the sender
should act as if the failure in the route came for the 27th hop.
Also changed the maximum number of hops in the route from 20 (legacy)
to 27 (tlv onion).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'bolt_2__set_an_initiator_in_quiescence.patch':
BOLT #2: Set an initiator in quiescence.
This is especially useful for protocols such as splicing; for
simplified commitment transactions, there is already an implied
initiator at each point, so having the negotiation at splicing
time would be redundant.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Header from folded patch 'option_quiesce__feature_to_support_stfu_method.patch':
option_quiesce: feature to support stfu method.
In practice, sftu is useless unless you have something (e.g. channel_upgrade)
which uses it, but adding a feature is best practice IMHO.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This is a follow-up to https://github.com/lightning/bolts/pull/1092
that fixes the following issues:
- fix a few typos
- remove non-zero-fee anchors test cases
- remove `remote_pubkey` rotation
Supported by all but 11 nodes*.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[* there are 449 three-year old LND nodes which advertize `2200` as their features, which have already been trimmed from most gossip for not having htlc_maximum_msat in their channel_updates]
Advertized as supported by all but 6 nodes (and those can no longer
route payments since people only send the modern onion these days)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These still have names and numbers, since they appear in `channel_type`. They are somewhat tangled with each other, so let's tie them together as assumed.
option_data_loss_protect is advertized by all by 11 nodes(*), and option_static_remotekey all but 16 nodes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
[* there are 449 three-year old LND nodes which advertize `2200` as their features, which have already been trimmed from most gossip for not having htlc_maximum_msat in their channel_updates]
In this commit, we propose a purely syntactical change to the current
blinded paths specification. Rather than denote the public key of the i-th
node as `E(i)`, we propose that instead it's denoted as: `E_i`. This results
in less overall characters, and is more similar to notation customarily
used in LaTeX.
My personal preference is that the proposed notation is easier to scan at a
glance, and also less ambiguous (doesn't look like a function call).
This commit updates bolt04 to more strictly enforce that encrypted_data
that is part of a blinded payment only has short_channel_id set. On
the reader side, we disallow setting of both short_channel_id and
next_node_id (which is intended for use in the context of onion
messages), and on the writer side we specify that next_node_id should
not be included by recipients.
I always get this wrong too, so CLN actually has a source check for this, and it triggered when importing the latest spec!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Moved up some rationale from the Rationale section and added a
bit of clarification to when you'd want to close/cancel an open.
Reported-By: @morehouse
`tx_abort`'s structure comes from the `warning`/`error` messages,
but we failed to port over the rationale/rules for the `data` field.
Suggested-By: @morehouse
If we only store state when sending `tx_signatures`, there are cases where
we cannot reconcile states if a disconnection occurs during the signing
steps: one side will have sent `tx_signatures` and thus must wait for the
transaction to be spent or double-spent, while the other side has already
forgotten that channel because they haven't sent `tx_signatures`.
This is fixed by storing state when sending `commitment_signed`, and
adding a `next_funding_txid` field to `channel_reestablish` to ask our
peer to retransmit signatures that we haven't received.
This issue is non-trivial and worth mentioning, otherwise implementations
may forget to handle this which would result in an easy way of attacking
node's on-chain liquidity, creating a large opportunity cost.
Prior versions of the v2 dual-funding protocol assumed a 'minimum fee'
payment for any witness stack of any input, as a way to simplify fee
checks.
The suggested min feerate didn't make sense for taproot spend paths etc;
instead we remove this check entirely.
