mirror of
https://github.com/lightning/bolts.git
synced 2025-01-19 05:33:37 +01:00
Massive Changes to Glossary
This is a big change to the glossary in BOLT-0. The overarcing changes are: 1.) Reorganized glossary to be alphabetical 2.) Add copious "See also:" lines to cross-reference containers, contents, and other related entries. *Changed Definitions:* Peer and node were revised based in on discussions with Rusty; commitment revocation secret key was changed to be commitment revocation private key based on #377. *New Definitions:* New words added based on their usage in the bolts were: announcement, closing transaction, final node, hop, origin node, processing, node, receiving node, receiving peer, revoked commitment transaction, sending node, sending peer. (I suspect the reorg will make the diffs almost useless, so this is the list of stuff to look at.)
This commit is contained in:
Shannon Appelcline
Rusty Russell
parent
f159d3f5a6
commit
88ed1ac10c
@ -25,94 +25,11 @@ This is version 0.
|
|||||||
|
|
||||||
## Glossary and Terminology Guide
|
## Glossary and Terminology Guide
|
||||||
|
|
||||||
* *Node*:
|
* *Announcement*:
|
||||||
* A computer or other device connected to the Bitcoin network.
|
* A gossip message sent between *peers* intended to aid the discovery of a *channel* or a *node*.
|
||||||
|
|
||||||
* *Peers*:
|
|
||||||
* *Nodes* transacting bitcoins with one another through a *channel*.
|
|
||||||
|
|
||||||
* *MSAT*:
|
|
||||||
* A millisatoshi, often used as a field name.
|
|
||||||
|
|
||||||
* *Funding transaction*:
|
|
||||||
* An irreversible on-chain transaction that pays to both *peers* on a *channel*.
|
|
||||||
It can only be spent by mutual consent.
|
|
||||||
|
|
||||||
* *Channel*:
|
|
||||||
* A fast, off-chain method of mutual exchange between two *peers*.
|
|
||||||
To transact funds, peers exchange signatures to create an updated *commitment transaction*.
|
|
||||||
|
|
||||||
* *Commitment transaction*:
|
|
||||||
* A transaction that spends the *funding transaction*.
|
|
||||||
Each *peer* holds the other peer's signature for this transaction, so that each
|
|
||||||
always has a commitment transaction that it can spend. After a new
|
|
||||||
commitment transaction is negotiated, the old one is *revoked*.
|
|
||||||
|
|
||||||
* *HTLC*: Hashed Time Locked Contract.
|
|
||||||
* A conditional payment between two *peers*: the recipient can spend
|
|
||||||
the payment by presenting its signature and a *payment preimage*,
|
|
||||||
otherwise the payer can cancel the contract by spending it after
|
|
||||||
a given time. These are implemented as outputs from the
|
|
||||||
*commitment transaction*.
|
|
||||||
|
|
||||||
* *Payment hash*:
|
|
||||||
* The *HTLC* contains the payment hash, which is the hash of the
|
|
||||||
*payment preimage*.
|
|
||||||
|
|
||||||
* *Payment preimage*:
|
|
||||||
* Proof that payment has been received, held by
|
|
||||||
the final recipient, who is the only person who knows this
|
|
||||||
secret. The final recipient releases the preimage in order to
|
|
||||||
release funds. The payment preimage is hashed as the *payment hash*
|
|
||||||
in the *HTLC*.
|
|
||||||
|
|
||||||
* *Commitment revocation secret key*:
|
|
||||||
* Every *commitment transaction* has a unique *commitment revocation* secret-key
|
|
||||||
value that allows the other *peer* to spend all outputs
|
|
||||||
immediately: revealing this key is how old commitment
|
|
||||||
transactions are revoked. To support revocation, each output of the
|
|
||||||
commitment transaction refers to the commitment revocation public key.
|
|
||||||
|
|
||||||
* *Per-commitment secret*:
|
|
||||||
* Every *commitment transaction* derives its keys from a per-commitment secret,
|
|
||||||
which is generated such that the series of per-commitment secrets
|
|
||||||
for all previous commitments can be stored compactly.
|
|
||||||
|
|
||||||
* *Mutual close*:
|
|
||||||
* A cooperative close of a *channel*, accomplished by broadcasting an unconditional
|
|
||||||
spend of the *funding transaction* with an output to each *peer*
|
|
||||||
(unless one output is too small, and thus is not included).
|
|
||||||
|
|
||||||
* *Unilateral close*:
|
|
||||||
* An uncooperative close of a *channel*, accomplished by broadcasting a
|
|
||||||
*commitment transaction*. This transaction is larger (i.e. less
|
|
||||||
efficient) than a *mutual close* transaction, and the peer whose
|
|
||||||
commitment is broadcast cannot access its own outputs for some
|
|
||||||
previously-negotiated duration.
|
|
||||||
|
|
||||||
* *Revoked transaction close*:
|
|
||||||
* An invalid close of a *channel*, accomplished by broadcasting a revoked
|
|
||||||
*commitment transaction*. Since the other *peer* knows the
|
|
||||||
*commitment revocation secret key*, it can create a *penalty transaction*.
|
|
||||||
|
|
||||||
* *Penalty transaction*:
|
|
||||||
* A transaction that spends all outputs of a revoked *commitment
|
|
||||||
transaction*, using the *commitment revocation secret key*. A *peer* uses this
|
|
||||||
if the other peer tries to "cheat" by broadcasting a revoked
|
|
||||||
*commitment transaction*.
|
|
||||||
|
|
||||||
* *Commitment number*:
|
|
||||||
* A 48-bit incrementing counter for each *commitment transaction*; counters
|
|
||||||
are independent for each *peer* in the *channel* and start at 0.
|
|
||||||
|
|
||||||
* *It's ok to be odd*:
|
|
||||||
* A rule applied to some numeric fields that indicates either optional or
|
|
||||||
compulsory support for features. Even numbers indicate that both endpoints
|
|
||||||
MUST support the feature in question, while odd numbers indicate
|
|
||||||
that the feature MAY be disregarded by the other endpoint.
|
|
||||||
|
|
||||||
* `chain_hash`:
|
* `chain_hash`:
|
||||||
* Used in several of the BOLT documents to denote the genesis hash of a
|
* The genesis hash of a
|
||||||
target blockchain. This allows *nodes* to create and reference *channels* on
|
target blockchain. This allows *nodes* to create and reference *channels* on
|
||||||
several blockchains. Nodes are to ignore any messages that reference a
|
several blockchains. Nodes are to ignore any messages that reference a
|
||||||
`chain_hash` that are unknown to them. Unlike `bitcoin-cli`, the hash is
|
`chain_hash` that are unknown to them. Unlike `bitcoin-cli`, the hash is
|
||||||
@ -122,6 +39,165 @@ This is version 0.
|
|||||||
(encoded in hex):
|
(encoded in hex):
|
||||||
`6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000`.
|
`6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000`.
|
||||||
|
|
||||||
|
* *Channel*:
|
||||||
|
* A fast, off-chain method of mutual exchange between two *peers*.
|
||||||
|
To transact funds, peers exchange signatures to create an updated *commitment transaction*.
|
||||||
|
* _See closure methods: mutal close, revoked transaction close, unilateral close_
|
||||||
|
|
||||||
|
* *Closing transaction*:
|
||||||
|
* A transaction generated as part of a _mutual close_. A closing transaction is similar to a _commitment transaction_, but with no pending payments.
|
||||||
|
* _See related: commitment transaction, funding transaction, penalty transaction_
|
||||||
|
|
||||||
|
* *Commitment number*:
|
||||||
|
* A 48-bit incrementing counter for each *commitment transaction*; counters
|
||||||
|
are independent for each *peer* in the *channel* and start at 0.
|
||||||
|
* _See container: commitment transaction_
|
||||||
|
* _See related: closing transaction, funding transaction, penalty transaction_
|
||||||
|
|
||||||
|
* *Commitment revocation private key*:
|
||||||
|
* Every *commitment transaction* has a unique commitment revocation private-key
|
||||||
|
value that allows the other *peer* to spend all outputs
|
||||||
|
immediately: revealing this key is how old commitment
|
||||||
|
transactions are revoked. To support revocation, each output of the
|
||||||
|
commitment transaction refers to the commitment revocation public key.
|
||||||
|
* _See container: commitment transaction_
|
||||||
|
* _See originator: per-commitment secret_
|
||||||
|
|
||||||
|
* *Commitment transaction*:
|
||||||
|
* A transaction that spends the *funding transaction*.
|
||||||
|
Each *peer* holds the other peer's signature for this transaction, so that each
|
||||||
|
always has a commitment transaction that it can spend. After a new
|
||||||
|
commitment transaction is negotiated, the old one is *revoked*.
|
||||||
|
* _See parts: commitment number, commitment revocation private key, HTLC, per-commitment secret_
|
||||||
|
* _See related: closing transaction, funding transaction, penalty transaction_
|
||||||
|
* _See types: revoked commitment transaction_
|
||||||
|
|
||||||
|
* *Final node*:
|
||||||
|
* The final recipient of a packet that is routing a payment from an _origin node_ through some number of _hops_. It is also the final *receiving peer* in a chain.
|
||||||
|
* _See category: node_
|
||||||
|
* _See related: origin node, processing node_
|
||||||
|
|
||||||
|
* *Funding transaction*:
|
||||||
|
* An irreversible on-chain transaction that pays to both *peers* on a *channel*.
|
||||||
|
It can only be spent by mutual consent.
|
||||||
|
* _See related: closing transaction, commitment transaction, penalty transaction_
|
||||||
|
|
||||||
|
* *Hop*:
|
||||||
|
* A *node*. Generally, an intermmediate node lying between an *origin node* and a *final node*.
|
||||||
|
* _See category: node_
|
||||||
|
|
||||||
|
* *HTLC*: Hashed Time Locked Contract.
|
||||||
|
* A conditional payment between two *peers*: the recipient can spend
|
||||||
|
the payment by presenting its signature and a *payment preimage*,
|
||||||
|
otherwise the payer can cancel the contract by spending it after
|
||||||
|
a given time. These are implemented as outputs from the
|
||||||
|
*commitment transaction*.
|
||||||
|
* _See container: commitment transaction_
|
||||||
|
* _See parts: Payment hash, Payment preimage_
|
||||||
|
|
||||||
|
* *It's ok to be odd*:
|
||||||
|
* A rule applied to some numeric fields that indicates either optional or
|
||||||
|
compulsory support for features. Even numbers indicate that both endpoints
|
||||||
|
MUST support the feature in question, while odd numbers indicate
|
||||||
|
that the feature MAY be disregarded by the other endpoint.
|
||||||
|
|
||||||
|
* *MSAT*:
|
||||||
|
* A millisatoshi, often used as a field name.
|
||||||
|
|
||||||
|
* *Mutual close*:
|
||||||
|
* A cooperative close of a *channel*, accomplished by broadcasting an unconditional
|
||||||
|
spend of the *funding transaction* with an output to each *peer*
|
||||||
|
(unless one output is too small, and thus is not included).
|
||||||
|
* _See related: revoked transaction close, unilateral close__
|
||||||
|
|
||||||
|
* *Node*:
|
||||||
|
* A computer or other device that is part of the Lightning network.
|
||||||
|
* _See related: peers_
|
||||||
|
* _See types: final node, hop, origin node, processing node, receiving node, sending node_
|
||||||
|
|
||||||
|
* *Origin node*:
|
||||||
|
* The _node_ that originates a packet that will route a payment through some number of _hops_ to a _final node_. It is also the first _sending peer_ in a chain.
|
||||||
|
* _See category: node_
|
||||||
|
* _See related: final node, processing node_
|
||||||
|
|
||||||
|
* *Payment hash*:
|
||||||
|
* The *HTLC* contains the payment hash, which is the hash of the
|
||||||
|
*payment preimage*.
|
||||||
|
* _See container: HTLC_
|
||||||
|
* _See originator: payment preimage_
|
||||||
|
|
||||||
|
* *Payment preimage*:
|
||||||
|
* Proof that payment has been received, held by
|
||||||
|
the final recipient, who is the only person who knows this
|
||||||
|
secret. The final recipient releases the preimage in order to
|
||||||
|
release funds. The payment preimage is hashed as the *payment hash*
|
||||||
|
in the *HTLC*.
|
||||||
|
* _See container: HTLC_
|
||||||
|
* _See derivation: payment hash_
|
||||||
|
|
||||||
|
* *Peers*:
|
||||||
|
* Two *nodes* that are in communication with each other.
|
||||||
|
* Two peers may gossip with each other prior to setting up a channel.
|
||||||
|
* Two peers may establish a *channel* through which they transact.
|
||||||
|
* _See related: node_
|
||||||
|
|
||||||
|
* *Penalty transaction*:
|
||||||
|
* A transaction that spends all outputs of a *revoked commitment
|
||||||
|
transaction*, using the *commitment revocation private key*. A *peer* uses this
|
||||||
|
if the other peer tries to "cheat" by broadcasting a *revoked
|
||||||
|
commitment transaction*.
|
||||||
|
* _See related: closing transaction, commitment transaction, funding transaction_
|
||||||
|
|
||||||
|
* *Per-commitment secret*:
|
||||||
|
* Every *commitment transaction* derives its keys from a per-commitment secret,
|
||||||
|
which is generated such that the series of per-commitment secrets
|
||||||
|
for all previous commitments can be stored compactly.
|
||||||
|
* _See container: commitment transaction_
|
||||||
|
* _See derivation: commitment revocation private key_
|
||||||
|
|
||||||
|
* *Processing node*:
|
||||||
|
* A *node* that is processing a packet that originated with an *origin node* and that is being sent toward a *final node* in order to route a payment. It acts as a _receiving peer_ to receive the message, then a _sending peer_ to send on the packet.
|
||||||
|
* _See category: node_
|
||||||
|
* _See related: final node, origin node_
|
||||||
|
|
||||||
|
* *Receiving node*:
|
||||||
|
* A *node* that is receiving a message.
|
||||||
|
* _See category: node_
|
||||||
|
* _See related: sending node_
|
||||||
|
|
||||||
|
* *Receiving peer*:
|
||||||
|
* A *node* that is receiving a message from a directly connected *peer*.
|
||||||
|
* _See category: peer_
|
||||||
|
* _See related: sending peer_
|
||||||
|
|
||||||
|
* *Revoked commitment transaction*:
|
||||||
|
* An old *commitment transaction* that has been revoked because a new commitment transaction has been negotiated.
|
||||||
|
* _See category: commitment transaction_
|
||||||
|
|
||||||
|
* *Revoked transaction close*:
|
||||||
|
* An invalid close of a *channel*, accomplished by broadcasting a *revoked
|
||||||
|
commitment transaction*. Since the other *peer* knows the
|
||||||
|
*commitment revocation secret key*, it can create a *penalty transaction*.
|
||||||
|
* _See related: mutal close, unilateral close_
|
||||||
|
|
||||||
|
* *Sending node*:
|
||||||
|
* A *node* that is sending a message.
|
||||||
|
* _See category: node_
|
||||||
|
* _See related: receiving node_
|
||||||
|
|
||||||
|
* *Sending peer*:
|
||||||
|
* A *node* that is sending a message to a directly connected *peer*.
|
||||||
|
* _See category: peer_
|
||||||
|
* _See related: receiving peer_.
|
||||||
|
|
||||||
|
* *Unilateral close*:
|
||||||
|
* An uncooperative close of a *channel*, accomplished by broadcasting a
|
||||||
|
*commitment transaction*. This transaction is larger (i.e. less
|
||||||
|
efficient) than a *mutual close transaction*, and the *peer* whose
|
||||||
|
commitment is broadcast cannot access its own outputs for some
|
||||||
|
previously-negotiated duration.
|
||||||
|
* _See related: mutual close, revoked transaction close_
|
||||||
|
|
||||||
## Theme Song
|
## Theme Song
|
||||||
|
|
||||||
Why this network could be democratic...
|
Why this network could be democratic...
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user