mirror of
https://github.com/lightning/bolts.git
synced 2024-11-19 01:50:03 +01:00
BOLT #2: Fix indent levels
(Rebased by Rusty Russell <rusty@rustcorp.com.au>)
This commit is contained in:
Pierre-Marie Padiou
Rusty Russell
parent
17060cbf9d
commit
18824a803a
@ -46,7 +46,7 @@ offered by the other node are not suitable, the channel establishment
|
||||
fails.
|
||||
|
||||
|
||||
## The `open_channel` message
|
||||
### The `open_channel` message
|
||||
|
||||
|
||||
This message contains information about a node, and indicates its
|
||||
@ -85,7 +85,7 @@ The `funding-pubkey` is the public key in the 2-of-2 multisig script of the fund
|
||||
FIXME: Describe Dangerous feature bit for larger channel amounts.
|
||||
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
|
||||
A sending node MUST set the most significant bit in
|
||||
@ -128,7 +128,7 @@ are not be valid DER-encoded compressed secp256k1 pubkeys.
|
||||
The receiver MUST NOT consider funds received using `push-msat` to be received until the funding transaction has reached sufficient depth.
|
||||
|
||||
|
||||
### Rationale
|
||||
#### Rationale
|
||||
|
||||
|
||||
The *channel reserve* is specified by the peer's `channel-reserve-satoshis`; 1% of the channel total is suggested. Each side of a channel maintains this reserve so it always has something to lose if it were to try to broadcast an old, revoked commitment transaction. Initially this reserve may not be met, as only one side has funds, but the protocol ensures that progress is always toward it being met, and once met it is maintained.
|
||||
@ -137,7 +137,7 @@ The *channel reserve* is specified by the peer's `channel-reserve-satoshis`; 1%
|
||||
The sender can unconditionally give initial funds to the receiver using a non-zero `push-msat`, and this is one case where the normal reserve mechanism doesn't apply. However, like any other on-chain transaction, this payment is not certain until the funding transaction has been confirmed sufficiently (may be double-spent) and may require a separate method to prove payment via on-chain confirmation.
|
||||
|
||||
|
||||
### Future
|
||||
#### Future
|
||||
|
||||
|
||||
It would be easy to have a local feature bit which indicated that a
|
||||
@ -145,7 +145,7 @@ receiving was prepared to fund a channel, which would reverse this
|
||||
protocol.
|
||||
|
||||
|
||||
## The `accept_channel` message
|
||||
### The `accept_channel` message
|
||||
|
||||
|
||||
This message contains information about a node, and indicates its
|
||||
@ -168,7 +168,7 @@ acceptance of the new channel.
|
||||
* [33:Refund base point]
|
||||
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
|
||||
The `temporary-channel-id` MUST be the same as the `temporary-channel-id` in the `open_channel` message. The sender SHOULD set `minimum-depth` to a number of blocks it considers reasonable to avoid double-spending of the funding transaction.
|
||||
@ -177,7 +177,7 @@ The receiver MAY reject the `minimum-depth` if it considers it unreasonably larg
|
||||
Other fields have the same requirements as their counterparts in `open_channel`.
|
||||
|
||||
|
||||
## The `funding_created` message
|
||||
### The `funding_created` message
|
||||
|
||||
This message describes the outpoint which the funder has created for
|
||||
the initial commitment transactions. After receiving the peer's
|
||||
@ -192,11 +192,11 @@ signature, it will broadcast the funding transaction.
|
||||
|
||||
FIXME: describe
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
The recipient MUST fail the channel if the signature is invalid.
|
||||
|
||||
## The `funding_signed` message
|
||||
### The `funding_signed` message
|
||||
|
||||
This message gives the funder the signature they need for the first
|
||||
commitment transaction, so they can broadcast it knowing they can
|
||||
@ -207,11 +207,11 @@ redeem their funds if they need to.
|
||||
* [8:temporary-channel-id]
|
||||
* [64:signature]
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
FIXME: Describe
|
||||
|
||||
## The `funding_locked` message
|
||||
### The `funding_locked` message
|
||||
|
||||
This message indicates that the funding transaction has reached the `minimum-depth` asked for in `accept_channel`. Once both nodes have sent this, the channel enters normal operating mode.
|
||||
|
||||
@ -231,16 +231,16 @@ index which pays to the channel.
|
||||
This `channel-id` is used in all messages referring to the channel
|
||||
from this point onwards.
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
FIXME: Describe
|
||||
|
||||
### Future
|
||||
#### Future
|
||||
|
||||
We could add an SPV proof, and route block hashes in separate
|
||||
messages.
|
||||
|
||||
## Updating Fees: `update_fee`
|
||||
### Updating Fees: `update_fee`
|
||||
|
||||
An `update_fee` message is sent by the node which is paying the
|
||||
bitcoin fee. Like any update, it is first committed to the receiver's
|
||||
@ -263,7 +263,7 @@ given in [BOLT #3].
|
||||
* [8:channel-id]
|
||||
* [4:fee-per-kilobyte]
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
The node which is responsible for paying the bitcoin fee SHOULD send
|
||||
`update_fee` when to ensure the current fee rate is sufficient for
|
||||
@ -284,7 +284,7 @@ the new fee rate on the receiving node's current commitment
|
||||
transaction, but it MAY delay this check until the `update_fee` is
|
||||
committed.
|
||||
|
||||
### Rationale
|
||||
#### Rationale
|
||||
|
||||
Bitcoin fees are required for unilateral closes to be effective,
|
||||
particularly since there is no general method for the node which
|
||||
@ -326,7 +326,7 @@ negotiation begins.
|
||||
+-------+ +-------+
|
||||
|
||||
|
||||
## Closing initiation: `shutdown`
|
||||
### Closing initiation: `shutdown`
|
||||
|
||||
Either node (or both) can send a `shutdown` message to initiate closing,
|
||||
and indicating the scriptpubkey it wants to be paid to.
|
||||
@ -338,7 +338,7 @@ and indicating the scriptpubkey it wants to be paid to.
|
||||
* [4:len]
|
||||
* [len:scriptpubkey]
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
A node MUST NOT send a `shutdown` if there are updates pending
|
||||
on the receiving node's commitment transaction which are not yet added to the sender’s commitment.
|
||||
@ -360,7 +360,7 @@ of those forms.
|
||||
|
||||
A receiving node MUST reply to a `shutdown` message with a `shutdown` once there are no outstanding updates on the peer, unless it has already sent a `shutdown`.
|
||||
|
||||
### Rationale
|
||||
#### Rationale
|
||||
|
||||
If channel state is always "clean" (no pending changes) when a
|
||||
shutdown starts, we avoid the question of how to behave if it wasn't;
|
||||
@ -375,7 +375,7 @@ propagate to miners.
|
||||
|
||||
The `shutdown` response requirement implies that the node sends `update_commit` to commit any outstanding changes before replying, but it could theoretically reconnect instead, which simply erases all outstanding uncommitted changes.
|
||||
|
||||
## Closing negotiation: `close_signature`
|
||||
### Closing negotiation: `close_signature`
|
||||
|
||||
Once shutdown is complete and the channel is empty of HTLCs, the final
|
||||
current commitment transactions will have no HTLCs, and closing fee
|
||||
@ -391,7 +391,7 @@ the channel.
|
||||
* [8:fee-satoshis]
|
||||
* [64:signature]
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
Nodes SHOULD send a `close_signature` message after `shutdown` has
|
||||
been received and no HTLCs remain in either commitment transaction.
|
||||
@ -420,7 +420,7 @@ Once a node has sent or received a `close_signature` with matching
|
||||
`fee-satoshis` it SHOULD close the connection and SHOULD sign and
|
||||
broadcast the final closing transaction.
|
||||
|
||||
### Rationale
|
||||
#### Rationale
|
||||
|
||||
Note that there is limited risk if the closing transaction is
|
||||
delayed, and it will be broadcast very soon, so there is usually no
|
||||
@ -469,7 +469,7 @@ what matters is whether both sides have irrevocably committed to a
|
||||
particular HTLC or not (the final state, above).
|
||||
|
||||
|
||||
## Risks With HTLC Timeouts
|
||||
### Risks With HTLC Timeouts
|
||||
|
||||
|
||||
HTLCs tend to be chained across the network. For example, a node A
|
||||
@ -502,7 +502,7 @@ deadline, and MUST fail the channel if an HTLC which it offered is in
|
||||
either node's current commitment transaction past this deadline.
|
||||
|
||||
|
||||
## Adding an HTLC
|
||||
### Adding an HTLC
|
||||
|
||||
|
||||
Either node can send `update_add_htlc` to offer a HTLC to the other,
|
||||
@ -526,7 +526,7 @@ is destined, is described in [BOLT #4].
|
||||
* [1254:onion-routing-packet]
|
||||
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
A sending node MUST NOT offer `amount-msat` it cannot pay for in the
|
||||
remote commitment transaction at the current `fee-rate` (see "Updating
|
||||
@ -556,7 +556,7 @@ commitment of that HTLC. A receiving node MAY fail the channel if
|
||||
other `id` violations occur.
|
||||
|
||||
|
||||
### Rationale
|
||||
#### Rationale
|
||||
|
||||
|
||||
Invalid amounts are a clear protocol violation and indicate a
|
||||
@ -574,7 +574,7 @@ reconnection purposes; allowing them at other times simplifies the
|
||||
recipient code, though strict checking may help debugging.
|
||||
|
||||
|
||||
## Removing an HTLC: `update_fulfill_htlc` and `update_fail_htlc`
|
||||
### Removing an HTLC: `update_fulfill_htlc` and `update_fail_htlc`
|
||||
|
||||
For simplicity, a node can only remove HTLCs added by the other node.
|
||||
There are three reasons for removing an HTLC: it has timed out, it has
|
||||
@ -597,7 +597,7 @@ For a timed out or route-failed HTLC:
|
||||
* [8:id]
|
||||
* [154:reason]
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
A node SHOULD remove an HTLC as soon as it can; in particular, a node
|
||||
SHOULD fail an HTLC which has timed out.
|
||||
@ -615,14 +615,14 @@ A receiving node which closes an incoming HTLC in response to an
|
||||
field to the outgoing `update-fail-htlc`.
|
||||
|
||||
|
||||
### Rationale
|
||||
#### Rationale
|
||||
|
||||
|
||||
A node which doesn't time out HTLCs it risks channel failure (see
|
||||
"Risks With HTLC Timeouts").
|
||||
|
||||
|
||||
## Committing Updates So Far: `commitsig`
|
||||
### Committing Updates So Far: `commitsig`
|
||||
|
||||
|
||||
When a node has changes for the remote commitment, it can apply them,
|
||||
@ -637,7 +637,7 @@ sign the resulting transaction as defined in [BOLT #3] and send a
|
||||
* [4:num-htlcs]
|
||||
* [num-htlcs*64:htlc-signature]
|
||||
|
||||
## Requirements
|
||||
#### Requirements
|
||||
|
||||
|
||||
A node MUST NOT send a `commitsig` message which does not include any
|
||||
@ -655,7 +655,7 @@ its local commitment transaction once all pending updates are applied. A receiv
|
||||
A receiving node MUST respond with a `revocation` message.
|
||||
|
||||
|
||||
## Rationale
|
||||
#### Rationale
|
||||
|
||||
|
||||
There's little point offering spam updates; it implies a bug.
|
||||
@ -664,7 +664,7 @@ There's little point offering spam updates; it implies a bug.
|
||||
The `num-htlcs` field is redundant, but makes the packet length check fully self-contained.
|
||||
|
||||
|
||||
## Completing the transition to the updated state: `revocation`
|
||||
### Completing the transition to the updated state: `revocation`
|
||||
|
||||
|
||||
Once the recipient of `commitsig` checks the signature, it knows that
|
||||
@ -694,7 +694,7 @@ The description of key derivation is in [BOLT #3](03-transactions.md#key-derivat
|
||||
* [4:num-htlc-timeouts]
|
||||
* [num-htlc-timeouts*64:htlc-timeout-signature]
|
||||
|
||||
### Requirements
|
||||
#### Requirements
|
||||
|
||||
|
||||
A sending node MUST set `per-commitment-secret` to the secret used to generate keys for the
|
||||
|
||||
Loading…
Reference in New Issue
Block a user