From efe9d2d151b80b1992f0ed65fead2b36d2908721 Mon Sep 17 00:00:00 2001 From: Michael Schmoock Date: Mon, 27 Sep 2021 13:59:10 +0200 Subject: [PATCH 1/4] BOLT 1: adds remote address to optional init_tlvs This adds the option to report an remote IP address back to a connecting peer using the `init` message. A node can decide to use that information to discover a potential update to its public IPv4 address (NAT) and use that for a `node_announcement` update message containing the new address. The proposal includes reporting the IPv4 and IPv6 address, however in IPv6 there are likely no NAT issues. TOR is skipped for obvious reasons. Certain approaches to check and use this information are thinkable: - Wait for multiple peers or a certain fraction to report the same new address. - Check some random node known via gossip to also report the new address. - Verify this information by making a test connection to itself. --- 01-messaging.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/01-messaging.md b/01-messaging.md index 84e402d70..935083b04 100644 --- a/01-messaging.md +++ b/01-messaging.md @@ -265,8 +265,12 @@ The `features` field MUST be padded to bytes with 0s. 2. data: * [`...*chain_hash`:`chains`] + 1. type: 3 (`remote_addr`) + 2. data: + * `address descriptor` (1 byte type and data, see BOLT 7) The optional `networks` indicates the chains the node is interested in. +The optional `remote_addr` can be used to circumvent NAT issues. #### Requirements @@ -277,6 +281,10 @@ The sending node: - SHOULD NOT set features greater than 13 in `globalfeatures`. - SHOULD use the minimum length required to represent the `features` field. - SHOULD set `networks` to all chains it will gossip or open channels for. + - SHOULD set `remote_addr` to reflect the remote IP address (and port) of an + incoming connection, if the node is the receiver and the connection was done + via IP. + - SHOULD NOT set private addresses as `remote_addr`. The receiving node: - MUST wait to receive `init` before sending any other messages. @@ -290,6 +298,7 @@ The receiving node: - MAY close the connection. - if the feature vector does not set all known, transitive dependencies: - MUST close the connection. + - MAY use the `remote_addr` to update its `node_annoucement` #### Rationale From c878cd8e1dae32df781c9e31bcd09f813aa64716 Mon Sep 17 00:00:00 2001 From: Matt Corallo <649246+TheBlueMatt@users.noreply.github.com> Date: Mon, 17 Jan 2022 18:40:47 +0000 Subject: [PATCH 2/4] s/send a warning/warn the user/ in BOLT 5 to avoid confusion (#951) Prior to the addition of `warning` messages, BOLT 5 specified a few cases where users should be warned that funds may have been lost. However, it used the phrasing "send a warning" which can now be confused with `warning` messages. Nodes should not generally inform their counterparty that they have been robbed. --- 05-onchain.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/05-onchain.md b/05-onchain.md index 08cd27efa..c324b1776 100644 --- a/05-onchain.md +++ b/05-onchain.md @@ -361,7 +361,7 @@ A local node: - MUST handle HTLCs offered by the remote node as specified in [HTLC Output Handling: Remote Commitment, Remote Offers](#htlc-output-handling-remote-commitment-remote-offers) - otherwise (it is NOT able to handle the broadcast for some reason): - - MUST send a warning regarding lost funds. + - MUST inform the user of potentially lost funds. ## Rationale @@ -625,7 +625,7 @@ A node: - upon discovering a transaction that spends a funding transaction output which does not fall into one of the above categories (mutual close, unilateral close, or revoked transaction close): - - MUST send a warning regarding lost funds. + - MUST warn the user of potentially lost funds. - Note: the existence of such a rogue transaction implies that its private key has leaked and that its funds may be lost as a result. - MAY simply monitor the contents of the most-work chain for transactions. From 29db92f334327b2854f4a3e5cd2ac1fb6f87bf93 Mon Sep 17 00:00:00 2001 From: lightning-developer <95319454+lightning-developer@users.noreply.github.com> Date: Mon, 17 Jan 2022 20:09:28 +0100 Subject: [PATCH 3/4] Removed requirement to broadcast an outdated commitment transaction (#942) If a node has to fail a channel but knows that its latest commitment transaction is outdated it should not be required to send it but rather wait for the peer to unilaterally close the channel. The proposed solution is not so clean because it might produce a deadlock in which two peers assume they have outdated state and send `error` back and forth without actually force closing. Maybe in such a scenario we could create a protocol that mutually closes with split balance? Also replaced the word use with broadcast as it seems more accurate. Co-authored-by: t-bast --- 02-peer-protocol.md | 29 +++++++++++++++-------------- 05-onchain.md | 15 +++++++++------ 2 files changed, 24 insertions(+), 20 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index afc2919c4..445b1f54b 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -1405,7 +1405,7 @@ A node: `your_last_per_commitment_secret` is correct for that `next_revocation_number` minus 1: - MUST NOT broadcast its commitment transaction. - - SHOULD fail the channel. + - SHOULD send an `error` to request the peer to fail the channel. - otherwise: - if `your_last_per_commitment_secret` does not match the expected values: - SHOULD send an `error` and fail the channel. @@ -1414,7 +1414,7 @@ A node: `your_last_per_commitment_secret` is correct for that `next_revocation_number` minus 1: - MUST NOT broadcast its commitment transaction. - - SHOULD fail the channel. + - SHOULD send an `error` to request the peer to fail the channel. - SHOULD store `my_current_per_commitment_point` to retrieve funds should the sending node broadcast its commitment transaction on-chain. - otherwise (`your_last_per_commitment_secret` or `my_current_per_commitment_point` @@ -1490,18 +1490,19 @@ Similarly, for the fundee's `funding_signed` message: it's better to remember a channel that never opens (and times out) than to let the funder open it while the fundee has forgotten it. -`option_data_loss_protect` was added to allow a node, which has somehow fallen behind -(e.g. has been restored from old backup), to detect that it's fallen-behind. A fallen-behind -node must know it cannot broadcast its current commitment transaction — which would lead to -total loss of funds — as the remote node can prove it knows the -revocation preimage. The error returned by the fallen-behind node -(or simply the invalid numbers in the `channel_reestablish` it has -sent) should make the other node drop its current commitment -transaction to the chain. This will, at least, allow the fallen-behind node to recover -non-HTLC funds, if the `my_current_per_commitment_point` -is valid. However, this also means the fallen-behind node has revealed this -fact (though not provably: it could be lying), and the other node could use this to -broadcast a previous state. +`option_data_loss_protect` was added to allow a node, which has somehow fallen +behind (e.g. has been restored from old backup), to detect that it has fallen +behind. A fallen-behind node must know it cannot broadcast its current +commitment transaction — which would lead to total loss of funds — as the +remote node can prove it knows the revocation preimage. The `error` returned by +the fallen-behind node should make the other node drop its current commitment +transaction to the chain. The other node should wait for that `error` to give +the fallen-behind node an opportunity to fix its state first (e.g by restarting +with a different backup). If the fallen-behind node doesn't have the latest +backup, this will, at least, allow it to recover non-HTLC funds, if the +`my_current_per_commitment_point` is valid. However, this also means the +fallen-behind node has revealed this fact (though not provably: it could be lying), +and the other node could use this to broadcast a previous state. `option_static_remotekey` removes the changing `to_remote` key, so the `my_current_per_commitment_point` is unnecessary and thus diff --git a/05-onchain.md b/05-onchain.md index c324b1776..2cf87d6b8 100644 --- a/05-onchain.md +++ b/05-onchain.md @@ -143,12 +143,15 @@ A node: sufficient fee: - SHOULD use this fee to perform a *mutual close*. - otherwise: - - MUST use the *last commitment transaction*, for which it has a - signature, to perform a *unilateral close*. - - MUST spend any `to_local_anchor` output, providing sufficient fees as incentive to include the commitment transaction in a block - Special care must be taken when spending to a third-party, because this re-introduces the vulnerability that was - addressed by adding the CSV delay to the non-anchor outputs. - - SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) or other mechanism on the spending transaction if it proves insufficient for timely inclusion in a block. + - if the node knows or assumes its channel state is outdated: + - MUST NOT broadcast its *last commitment transaction*. + - otherwise: + - MUST broadcast the *last commitment transaction*, for which it has a + signature, to perform a *unilateral close*. + - MUST spend any `to_local_anchor` output, providing sufficient fees as incentive to include the commitment transaction in a block. + Special care must be taken when spending to a third-party, because this re-introduces the vulnerability that was + addressed by adding the CSV delay to the non-anchor outputs. + - SHOULD use [replace-by-fee](https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki) or other mechanism on the spending transaction if it proves insufficient for timely inclusion in a block. ## Rationale From 655915c2520cb7f572edfd3f38ba349369a150be Mon Sep 17 00:00:00 2001 From: Ken Sedgwick Date: Fri, 14 Jan 2022 16:28:43 -0800 Subject: [PATCH 4/4] Clarify the sighash types for HTLC Success and Timeout transactions --- 03-transactions.md | 2 +- 05-onchain.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/03-transactions.md b/03-transactions.md index 282533236..0ad86e211 100644 --- a/03-transactions.md +++ b/03-transactions.md @@ -328,7 +328,7 @@ These HTLC transactions are almost identical, except the HTLC-timeout transactio * txout count: 1 * `txout[0]` amount: the HTLC amount minus fees (see [Fee Calculation](#fee-calculation)) * `txout[0]` script: version-0 P2WSH with witness script as shown below -* if `option_anchors` applies to this commitment transaction, `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used. +* if `option_anchors` applies to this commitment transaction, `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` is used as described in [BOLT #5](05-onchain.md#generation-of-htlc-transactions). The witness script for the output is: diff --git a/05-onchain.md b/05-onchain.md index 2cf87d6b8..934ab4f62 100644 --- a/05-onchain.md +++ b/05-onchain.md @@ -594,8 +594,8 @@ If `option_anchors` does not apply to the commitment transaction, then HTLC-timeout and HTLC-success transactions are complete transactions with (hopefully!) reasonable fees and must be used directly. -Otherwise, the use of `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` on the HTLC -signatures received from the peer allows HTLC transactions to be combined with +Otherwise, `SIGHASH_SINGLE|SIGHASH_ANYONECANPAY` MUST be used on the +HTLC signatures received from the peer, as this allows HTLC transactions to be combined with other transactions. The local signature MUST use `SIGHASH_ALL`, otherwise anyone can attach additional inputs and outputs to the tx.