diff --git a/01-messaging-crypto-and-init.md b/01-messaging-crypto-and-init.md index 1a5e61a..2a3d4d4 100644 --- a/01-messaging-crypto-and-init.md +++ b/01-messaging-crypto-and-init.md @@ -682,7 +682,7 @@ features supported or required by this node. Odd features are optional, even features are compulsory ("it's OK to be odd!"). The meaning of these bits will be defined in future. -1. type: 16 (`MSG_INIT`) +1. type: 16 (`init`) 2. data: * [4:gflen] * [gflen:globalfeatures] @@ -707,7 +707,7 @@ The receiving node MUST fail the channels if it receives a not understand. -Each node MUST wait to receive MSG_INIT before sending any other +Each node MUST wait to receive `init` before sending any other messages. @@ -730,7 +730,7 @@ For simplicity of diagnosis, it is often useful to tell the peer that something is incorrect. -1. type: 17 (`MSG_ERROR`) +1. type: 17 (`error`) 2. data: * [8:channel-id] * [4:len] @@ -743,15 +743,15 @@ following field. ### Requirements -A node SHOULD send `MSG_ERROR` for protocol violations or internal +A node SHOULD send `error` for protocol violations or internal errors which make channels unusable or further communication unusable. -A node MAY send an empty [data] field. A node sending `MSG_ERROR` MUST +A node MAY send an empty [data] field. A node sending `error` MUST fail the channel referred to by the `channel-id`, or if `channel-id` is 0xFFFFFFFFFFFFFFFF it MUST fail all channels and MUST close the connection. A node MUST NOT set `len` to greater than the data length. -A node receiving `MSG_ERROR` MUST fail the channel referred to by +A node receiving `error` MUST fail the channel referred to by `channel-id`, or if `channel-id` is 0xFFFFFFFFFFFFFFFF it MUST fail all channels and MUST close the connection. A receiving node MUST truncate `len` to the remainder of the packet if it is larger. diff --git a/02-peer-protocol.md b/02-peer-protocol.md index 17e603a..22bf264 100644 --- a/02-peer-protocol.md +++ b/02-peer-protocol.md @@ -68,7 +68,7 @@ fails. This message contains information about a node, and indicates its desire to set up a new channel. -1. type: 32 (`MSG_OPEN_CHANNEL`) +1. type: 32 (`open_channel`) 2. data: * [8:temporary-channel-id] * [8:funding-satoshis] @@ -162,7 +162,7 @@ This message contains information about a node, and indicates its acceptance of the new channel. -1. type: 33 (`MSG_ACCEPT_CHANNEL`) +1. type: 33 (`accept_channel`) 2. data: * [8:temporary-channel-id] * [8:dust-limit-satoshis] @@ -193,7 +193,7 @@ This message describes the outpoint which the funder has created for the initial commitment transactions. After receiving the peer's signature, it will broadcast the funding transaction. -1. type: 34 (`MSG_FUNDING_CREATED`) +1. type: 34 (`funding_created`) 2. data: * [8:temporary-channel-id] * [32:txid] @@ -212,7 +212,7 @@ This message gives the funder the signature they need for the first commitment transaction, so they can broadcast it knowing they can redeem their funds if they need to. -1. type: 35 (`MSG_FUNDING_SIGNED`) +1. type: 35 (`funding_signed`) 2. data: * [8:temporary-channel-id] * [64:signature] @@ -227,7 +227,7 @@ The recipient MUST fail the channel if `signature` is incorrect. 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. -1. type: 36 (`MSG_FUNDING_LOCKED`) +1. type: 36 (`funding_locked`) 2. data: * [8:temporary-channel-id] * [8:channel-id] @@ -292,7 +292,7 @@ The exact calculation used for deriving the fee from the fee rate is given in [BOLT #3]. -1. type: 37 (`MSG_UPDATE_FEE`) +1. type: 37 (`update_fee`) 2. data: * [8:channel-id] * [4:feerate-per-kw] @@ -368,7 +368,7 @@ Either node (or both) can send a `shutdown` message to initiate closing, and indicating the scriptpubkey it wants to be paid to. -1. type: 38 (`MSG_SHUTDOWN`) +1. type: 38 (`shutdown`) 2. data: * [8:channel-id] * [4:len] @@ -421,7 +421,7 @@ signs the close transaction with the `script_pubkey` fields from the process terminates when both agree on the same fee, or one side fails the channel. -1. type: 39 (`MSG_CLOSING_SIGNED`) +1. type: 39 (`closing_signed`) 2. data: * [8:channel-id] * [8:fee-satoshis] @@ -551,7 +551,7 @@ The format of the `route` portion, which indicates where the payment is destined, is described in [BOLT #4]. -1. type: 128 (`MSG_UPDATE_ADD_HTLC`) +1. type: 128 (`update_add_htlc`) 2. data: * [8:channel-id] * [8:id] @@ -618,7 +618,7 @@ failed to route, or the payment preimage is supplied. The `reason` field is an opaque encrypted blob for the benefit of the original HTLC initiator as defined in [BOLT #4]. -1. type: 130 (`MSG_UPDATE_FULFILL_HTLC`) +1. type: 130 (`update_fulfill_htlc`) 2. data: * [8:channel-id] * [8:id] @@ -626,7 +626,7 @@ original HTLC initiator as defined in [BOLT #4]. For a timed out or route-failed HTLC: -1. type: 131 (`MSG_UPDATE_FAIL_HTLC`) +1. type: 131 (`update_fail_htlc`) 2. data: * [8:channel-id] * [8:id] @@ -665,7 +665,7 @@ sign the resulting transaction as defined in [BOLT #3] and send a `commitsig` message. -1. type: 132 (`MSG_COMMIT_SIG`) +1. type: 132 (`commit_sig`) 2. data: * [8:channel-id] * [64:signature] @@ -720,7 +720,7 @@ This message also supplies the signatures for the sender's HTLC-timeout transact The description of key derivation is in [BOLT #3](03-transactions.md#key-derivation). -1. type: 133 (`MSG_REVOKE_AND_ACK`) +1. type: 133 (`revoke_and_ack`) 2. data: * [8:channel-id] * [32:per-commitment-secret] diff --git a/07-routing-gossip.md b/07-routing-gossip.md index 82d397d..3162779 100644 --- a/07-routing-gossip.md +++ b/07-routing-gossip.md @@ -21,7 +21,7 @@ on-chain bitcoin key to the lightning node key, and vice-versa. The channel is not really usable until at least one side has announced its fee levels and expiry using `channel_update`. -1. type: 256 (`MSG_CHANNEL_ANNOUNCEMENT`) +1. type: 256 (`channel_announcement`) 2. data: * [64:node-signature-1] * [64:node-signature-2] @@ -104,7 +104,7 @@ This allows a node to indicate extra data associated with it, in addition to its public key. To avoid trivial denial of service attacks, nodes for which a channel is not already known are ignored. -1. type: 257 (`MSG_NODE_ANNOUNCEMENT`) +1. type: 257 (`node_announcement`) 2. data: * [64:signature] * [4:timestamp] @@ -166,7 +166,7 @@ channel shortid which matches the `channel_announcement` and one byte to indicate which end this is. It can do this multiple times, if it wants to change fees. -1. type: 258 (`MSG_CHANNEL_UPDATE`) +1. type: 258 (`channel_update`) 2. data: * [64:signature] * [4:blockheight]