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.
While dual funding only needs unsigned funding amounts, other protocols
that leverage interactive-tx may use signed funding amounts, for example
to take funds out of an existing channel (splice-out).
It is thus more future-proof to use signed amounts in `tx_init_rbf` and
`tx_ack_rbf`.
This commit adds the interactive transaction construction protcol, as
well as the first practical example of using it, v2 of channel
establishment.
Note that for v2 we also update the channel_id, which now uses the hash
of the revocation_basepoints. We move away from using the funding
transaction id, as the introduction of RBF* makes it such that a single
channel may have many funding transaction id's over the course of
its lifetime.
*Later, also splicing
Prior wording of the description of this parameter left room for
ambiguity around whether it capped the total value offered by both
channel peers combined or if it was solely capping the total value
of HTLCs offered by the remote.
1. Put it in the PR title so everyone can see.
2. Deploy with +100 while it's still unratified, in case it changes.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
i.e. it was present in the init feature bits. We use this in several places, but assume everyone knows what it means.
It's particularly fraught with required features: it's explicitly legitimate to assume these are accepted if
the node keeps talking to you after init!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Since "reject" isn't defined anywhere in the spec and "fail" does
have a definition laid out in BOLT1 that includes special
provisions for channels that have not yet been established, BOLT2
is amended to clarify the requirements for the receiver of
`accept_channel`
While reviewing a patch on lnprototest, I encountered a scenario
where the BOLT 9 specification needed to provide clear guidance.
As a result, this commit adds specific requirements to
determine the appropriate behaviour when a node specifies
both optional and required features.
Additionally, if this situation appears to be an
implementation bug, it will be taken care of accordingly.
Reported-by: lnprototest
Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
