mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2025-03-10 09:10:07 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 1, BOLT 2, BOLT 7: Remove message enums

Browse source 
The MSG_XXX is trivially derived from the name of the message if
people want to do that, so just change it to the actual message name.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2016-11-23 11:33:25 +10:30
parent fa448bd21e
commit b742d2f73d
3 changed files with 22 additions and 22 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

12
01-messaging-crypto-and-init.md
View file

@ -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 optional, even features are compulsory ("it's OK to be odd!"). The
meaning of these bits will be defined in future. meaning of these bits will be defined in future.
1. type: 16 (`MSG_INIT`) 1. type: 16 (`init`)
2. data: 2. data:
* [4:gflen] * [4:gflen]
* [gflen:globalfeatures] * [gflen:globalfeatures]
@ -707,7 +707,7 @@ The receiving node MUST fail the channels if it receives a
not understand. 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. messages.
@ -730,7 +730,7 @@ For simplicity of diagnosis, it is often useful to tell the peer that
something is incorrect. something is incorrect.
1. type: 17 (`MSG_ERROR`) 1. type: 17 (`error`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [4:len] * [4:len]
@ -743,15 +743,15 @@ following field.
### Requirements ### 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. 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` fail the channel referred to by the `channel-id`, or if `channel-id`
is 0xFFFFFFFFFFFFFFFF it MUST fail all channels and MUST close the is 0xFFFFFFFFFFFFFFFF it MUST fail all channels and MUST close the
connection. A node MUST NOT set `len` to greater than the data length. 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 `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. all channels and MUST close the connection. A receiving node MUST truncate `len` to the remainder of the packet if it is larger.

26
02-peer-protocol.md
View file

@ -68,7 +68,7 @@ fails.
This message contains information about a node, and indicates its This message contains information about a node, and indicates its
desire to set up a new channel. desire to set up a new channel.
1. type: 32 (`MSG_OPEN_CHANNEL`) 1. type: 32 (`open_channel`)
2. data: 2. data:
* [8:temporary-channel-id] * [8:temporary-channel-id]
* [8:funding-satoshis] * [8:funding-satoshis]
@ -162,7 +162,7 @@ This message contains information about a node, and indicates its
acceptance of the new channel. acceptance of the new channel.
1. type: 33 (`MSG_ACCEPT_CHANNEL`) 1. type: 33 (`accept_channel`)
2. data: 2. data:
* [8:temporary-channel-id] * [8:temporary-channel-id]
* [8:dust-limit-satoshis] * [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 the initial commitment transactions. After receiving the peer's
signature, it will broadcast the funding transaction. signature, it will broadcast the funding transaction.
1. type: 34 (`MSG_FUNDING_CREATED`) 1. type: 34 (`funding_created`)
2. data: 2. data:
* [8:temporary-channel-id] * [8:temporary-channel-id]
* [32:txid] * [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 commitment transaction, so they can broadcast it knowing they can
redeem their funds if they need to. redeem their funds if they need to.
1. type: 35 (`MSG_FUNDING_SIGNED`) 1. type: 35 (`funding_signed`)
2. data: 2. data:
* [8:temporary-channel-id] * [8:temporary-channel-id]
* [64:signature] * [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. 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: 2. data:
* [8:temporary-channel-id] * [8:temporary-channel-id]
* [8: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]. given in [BOLT #3].
1. type: 37 (`MSG_UPDATE_FEE`) 1. type: 37 (`update_fee`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [4:feerate-per-kw] * [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. and indicating the scriptpubkey it wants to be paid to.
1. type: 38 (`MSG_SHUTDOWN`) 1. type: 38 (`shutdown`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [4:len] * [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 process terminates when both agree on the same fee, or one side fails
the channel. the channel.
1. type: 39 (`MSG_CLOSING_SIGNED`) 1. type: 39 (`closing_signed`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [8:fee-satoshis] * [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]. is destined, is described in [BOLT #4].
1. type: 128 (`MSG_UPDATE_ADD_HTLC`) 1. type: 128 (`update_add_htlc`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [8: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 The `reason` field is an opaque encrypted blob for the benefit of the
original HTLC initiator as defined in [BOLT #4]. original HTLC initiator as defined in [BOLT #4].
1. type: 130 (`MSG_UPDATE_FULFILL_HTLC`) 1. type: 130 (`update_fulfill_htlc`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [8:id] * [8:id]
@ -626,7 +626,7 @@ original HTLC initiator as defined in [BOLT #4].
For a timed out or route-failed HTLC: For a timed out or route-failed HTLC:
1. type: 131 (`MSG_UPDATE_FAIL_HTLC`) 1. type: 131 (`update_fail_htlc`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [8:id] * [8:id]
@ -665,7 +665,7 @@ sign the resulting transaction as defined in [BOLT #3] and send a
`commitsig` message. `commitsig` message.
1. type: 132 (`MSG_COMMIT_SIG`) 1. type: 132 (`commit_sig`)
2. data: 2. data:
* [8:channel-id] * [8:channel-id]
* [64:signature] * [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). 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: 2. data:
* [8:channel-id] * [8:channel-id]
* [32:per-commitment-secret] * [32:per-commitment-secret]

6
07-routing-gossip.md
View file

@ -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 The channel is not really usable until at least one side has announced
its fee levels and expiry using `channel_update`. its fee levels and expiry using `channel_update`.
1. type: 256 (`MSG_CHANNEL_ANNOUNCEMENT`) 1. type: 256 (`channel_announcement`)
2. data: 2. data:
* [64:node-signature-1] * [64:node-signature-1]
* [64:node-signature-2] * [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, addition to its public key. To avoid trivial denial of service attacks,
nodes for which a channel is not already known are ignored. nodes for which a channel is not already known are ignored.
1. type: 257 (`MSG_NODE_ANNOUNCEMENT`) 1. type: 257 (`node_announcement`)
2. data: 2. data:
* [64:signature] * [64:signature]
* [4:timestamp] * [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 to indicate which end this is. It can do this multiple times, if
it wants to change fees. it wants to change fees.
1. type: 258 (`MSG_CHANNEL_UPDATE`) 1. type: 258 (`channel_update`)
2. data: 2. data:
* [64:signature] * [64:signature]
* [4:blockheight] * [4:blockheight]