Skip to content

Add funding expiry to channel open #839

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.

Sign up for GitHub

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

Merged
t-bast merged 1 commit into from
Mar 2, 2021
Merged

Add funding expiry to channel open #839

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 16 additions & 8 deletions 02-peer-protocol.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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<sup>[LOWS](https://github.com/bitcoin/bitcoin/pull/6769)</sup>:
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down