From 84c31eceb209bc71a5d2efdc0d5c40f9cf2c5a26 Mon Sep 17 00:00:00 2001 From: t-bast Date: Wed, 17 Feb 2021 10:57:09 +0100 Subject: [PATCH] Add 2016 blocks channel funding timeout Routing nodes have an incentive to use low fees when opening channels to ensure their activity is economically viable. However, when a funding transaction takes too long to confirm, the fundee may have forgotten the channel. In that case the funder is forced to broadcast the first commit tx to get his funds back and then open a new channel, which is costly. We can avoid this issue by simply knowing how long the fundee will wait, and ensuring the funding tx confirms before that period ends. We set this timeout to 2016 blocks (2 weeks). --- 02-peer-protocol.md | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 842274074..be600ed6e 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -351,6 +351,7 @@ The sender MUST set: The sender: - when creating the funding transaction: - SHOULD use only BIP141 (Segregated Witness) inputs. + - SHOULD ensure the funding transaction confirms in the next 2016 blocks. The recipient: - if `signature` is incorrect OR non-compliant with LOW-S-standard rule[LOWS](https://github.com/bitcoin/bitcoin/pull/6769): @@ -362,6 +363,9 @@ The `funding_output_index` can only be 2 bytes, since that's how it's packed int A transaction with all Segregated Witness inputs is not malleable, hence the funding transaction recommendation. +The funder may use CPFP on a change output to ensure that the funding transaction confirms before 2016 blocks, +otherwise the fundee may forget that channel. + ### The `funding_signed` Message This message gives the funder the signature it needs for the first @@ -415,16 +419,15 @@ This message indicates that the funding transaction has reached the `minimum_dep The sender MUST: - NOT send `funding_locked` unless outpoint of given by `funding_txid` and `funding_output_index` in the `funding_created` message pays exactly `funding_satoshis` to the scriptpubkey specified in [BOLT #3](03-transactions.md#funding-transaction-output). - - wait until the funding transaction has reached -`minimum_depth` before sending this message. - - set `next_per_commitment_point` to the -per-commitment point to be used for the following commitment -transaction, derived as specified in -[BOLT #3](03-transactions.md#per-commitment-secret-requirements). + - wait until the funding transaction has reached `minimum_depth` before + sending this message. + - set `next_per_commitment_point` to the per-commitment point to be used + for the following commitment transaction, derived as specified in + [BOLT #3](03-transactions.md#per-commitment-secret-requirements). A non-funding node (fundee): - - SHOULD forget the channel if it does not see the correct -funding transaction after a reasonable timeout. + - SHOULD forget the channel if it does not see the correct funding + transaction after a timeout of 2016 blocks. From the point of waiting for `funding_locked` onward, either node MAY fail the channel if it does not receive a required response from the @@ -437,6 +440,11 @@ funds are at risk. If the fundee were to remember the channel forever, this would create a Denial of Service risk; therefore, forgetting it is recommended (even if the promise of `push_msat` is significant). +If the fundee forgets the channel before it was confirmed, the funder will need +to broadcast the commitment transaction to get his funds back and open a new +channel. To avoid this, the funder should ensure the funding transaction +confirms in the next 2016 blocks. + ## Channel Close Nodes can negotiate a mutual close of the connection, which unlike a