proposed changes to the gossip protocol. removed a few terms and added others. tried to address the feedback given by the community and focus on terms that are used several times in the book
This quick glossary contains many of the terms used in relation to Bitcoin. These terms are used throughout the book, so bookmark this for a quick reference.
////
Proposed entries to remove:
AMP::
Atomic Multipath Payments is an extension to the protocol that allows triggering a spontaneous payment (no invoice required) that splits up a payment into multiple parts and uses additive secret sharing to ensure that the payment can only be pulled once all parts arrive. Additionally, each path of a AMP payment uses a distinct payment hash.
Breach Remedy Transaction::
A transaction claiming the outputs of a Revocable Sequence Maturity Contract with the help of the revocation key.
This can only happen if a channel partner was not following the protocol and tried to publish (willingly or due to a software bug) an old channel state.
computationally easy::
A problem is considered to be computationally easy if there exists an algorithm that is able to compute the solution to the problem relatively quickly (in polynomial time complexity).
computationally hard::
A problem is considered to be computationally hard if no algorithm exists or is known that is able to compute the solution to the problem relatively quickly (in polynomial time complexity).
downstream payment::
TBD.
HODL/Hold Invoices::
HODL/Hold invoices are effectively standard HTLC LN invoices with the exception that the recipient can “hold” the funds, deferring to settle the transaction until some condition has been met. The sender remains committed unless the recipient opts to cancel the transaction.
Neutrino:: (in the conclusion as a future thing also SPV not in glossary, too detailed)
Neutrino is a later alternative to SPV that also verifies whether certain transactions are contained in a block without downloading the entire block. However, it offers a number of improvements over SPV: Neutrino does not transmit any information that would allow a third party to determine users’ identities, it facilitates the use of non-custodial apps, and it reduces the computational load on full nodes. The trade-off for these improvements is that Neutrino requires more data from the full node than SPV.
penalty transaction::
See _Breach Remedy Transaction_.
Second stage HTLC::
TBD.
upstream payment::
TBD.
zombie channel::
An open channel where one of the channel partners has gone permanently offline.
Zombie channels cannot be used to route payments and have only downsides to the online partner.
It is good practice to close zombie channels although they can be tricky to identify as the online partner can't always be sure if the offline party will stay offline.
++++
TODO:
Some additional definitions, to be cleaned up and moved into alphabetic order are in the commented-out area below
++++
////
* blockchain: a single distributed ledger agreed upon by a network of participating nodes. The Lightning Network does not use a blockchain to transact, but requires transactions recorded in a blockchain in order for bitcoin to enter and leave the network.
* channel: a channel is a financial relationship between two nodes on the Lightning Network. Two users can open a channel with each other using a Bitcoin transaction, and transact with each other by moving bitcoin from one side of the channel to the other.
@ -33,8 +72,6 @@ Some additional definitions, to be cleaned up and moved into alphabetic order ar
address::
Bitcoin invoice addresses compactly encode the information necessary to pay a receiver. A modern address consists of a string of letters and numbers that starts with bc1 and looks like +bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4+. An address is shorthand for a receiver's locking script which can be used by a sender to sign over funds to the receiver. Most addresses either represent the receiver's public key or some form of redeemscript that defines more complex spending conditions. The above example is a bech32 address encoding a witness program locking funds to the hash of a public key (Pay to Witness Public Key Hash). There are also older address formats that start with 1 or 3 that use the base58check address encoding to represent public key hashes or script hashes.
AMP::
Atomic Multipath Payments is an extension to the protocol that allows triggering a spontaneous payment (no invoice required) that splits up a payment into multiple parts and uses additive secret sharing to ensure that the payment can only be pulled once all parts arrive. Additionally, each path of a AMP payment uses a distinct payment hash.
Asymmetric Cryptographic System::
Asymmetric cryptography, or public-key cryptography, is a cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner.
@ -90,10 +127,6 @@ blockchain::
BOLT::
BOLT, or Basis Of Lightning Technology, is the formal specification of the Lightning Network protocol. Unlike Bitcoin, which has a reference implementation that also serves as the protocol's specification, the various Lightning Network implementations follow BOLT so they can work with one another to form the same network. It is available at https://github.com/lightningnetwork/lightning-rfc.
Breach Remedy Transaction::
A transaction claiming the outputs of a Revocable Sequence Maturity Contract with the help of the revocation key.
This can only happen if a channel partner was not following the protocol and tried to publish (willingly or due to a software bug) an old channel state.
capacity::
The capacity of a payment channel is equivalent to the amount of bitcoin provided by the funding transaction.
As the funding transaction is publicly visible on the blockchain, and the channel is announced via the gossip protocol, the capacity is public information.
@ -112,6 +145,9 @@ closing transaction::
After exchanging signatures for a closing transaction, no further channel updates should be made as this one allows one side to enforce the closing transaction on the blockchain.
Mutually closing a channel with the help of a closing transaction has the advantage that fewer blockchain transactions are required to claim all funds, in comparison to unilaterally forcing a channel close by publishing a commitment transaction. Additionally, funds for both parties are immediately spendable from a closing transaction.
CLTV::
CLTV is a shortform for the bitcoin OP code OP_CHECKLOCKTIMEVERIFY. This defines an absolute blockheight before an output can be spend. The atomicity of the routing process heavily depends on CLTV values in HTLCs. Routing nodes announce their CLTV expiry deltas that they wish for an incoming and outgoing htlc to have at least via the gossip protocol.
coinbase::
The coinbase is a special field only permitted in the sole input of coinbase transactions.
The coinbase allows up 100 bytes of arbitrary data, but since BIP34 must first feature the current block height to ensure that coinbase transactions are unique.
@ -137,12 +173,6 @@ Commitment Transaction::
At any point, the channel can be closed by either Alice or Bob if they submit their commitment transaction to the Bitcoin blockchain.
Submitting an older (outdated) commitment transaction is considered "cheating" (i.e. a protocol breach) in the Lightning network and can be penalized by the other party, claiming all the funds in the channel for themselves.
computationally easy::
A problem is considered to be computationally easy if there exists an algorithm that is able to compute the solution to the problem relatively quickly (in polynomial time complexity).
computationally hard::
A problem is considered to be computationally hard if no algorithm exists or is known that is able to compute the solution to the problem relatively quickly (in polynomial time complexity).
confirmations::
Once a transaction is included in a block, it has one confirmation. As soon as _another_ block is mined on the same blockchain, the transaction has two confirmations, and so on. Six or more confirmations are considered sufficient proof that a transaction cannot be reversed.
@ -168,9 +198,6 @@ double-spending::
Double-spending is the result of successfully spending some money more than once.
Bitcoin protects against double-spending by verifying that each transaction added to the blockchain plays by the rules; this means checking that the inputs for the transaction have not previously already been spent.
downstream payment::
TBD.
ECDSA::
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
@ -193,14 +220,15 @@ ephemeral key::
feature bits::
A binary string that Lightning nodes use to communicate to each other which features they support.
Feature bits are included in many types of communication, such as invoices or channel announcements.
Feature bits are included in many Lightning Messages as well as BOLT #11.
They can be decoded using BOLT #9, and will tell nodes which features the node has enabled, and whether these are backward-compatible.
Also known as feature flags.
fees::
In the context of Bitcoin, the sender of a transaction pays a fee to miners for including the transaction in a block.
In the context of the Lightning Network, nodes will charge routing fees for forwarding other users' payments.
Individual nodes can set their own fee policies which will be calculated as the sum of a fixed _base_fee_ and a _fee_rate_ which depends on the payment amount.
In the context of Bitcoin, the sender of a transaction pays a fee to miners for including the transaction in a block.
Bitcoin transaction fees do not include a base fee and only depende linearly on the size of the transaction in Bytes but not on the amount.
funding transaction::
The funding transaction is used to open a payment channel.
@ -224,7 +252,7 @@ Gossip Protocol::
hardware wallet::
A hardware wallet is a special type of Bitcoin wallet which stores the user's private keys in a secure hardware device.
Currently, hardware wallets are not available for Lightning Network nodes as they need to be online to participate in the protocol.
As of writing the book, hardware wallets for consumers are not available for Lightning Network nodes as they need to be online to participate in the protocol.
Several groups are currently working on solutions.
hash::
@ -247,8 +275,6 @@ hash function::
hashlocks::
A hashlock is a type of encumbrance that restricts the spending of an output until a specified piece of data is publicly revealed. Hashlocks have the useful property that once any hashlock is opened publicly, any other hashlock secured using the same key can also be opened. This makes it possible to create multiple outputs that are all encumbered by the same hashlock and which all become spendable at the same time.
HODL/Hold Invoices::
HODL/Hold invoices are effectively standard HTLC LN invoices with the exception that the recipient can “hold” the funds, deferring to settle the transaction until some condition has been met. The sender remains committed unless the recipient opts to cancel the transaction.
HTLC::
A Hashed TimeLock Contract or HTLC is a class of payments that use hashlocks and timelocks to require that the receiver of a payment either acknowledges receiving the payment prior to a deadline by generating cryptographic proof of payment (usually called the preimage of the payment hash) or forfeits the ability to claim the payment, returning it to the payer.
@ -266,13 +292,17 @@ JIT Routing::
This might allow them to successfully forward payments that might otherwise have failed due to a lack of outgoing capacity.
Lightning message::
A Lightning message is an encrypted data string that can be sent between two peers on the Lightning Network. Similar to other communication protocols, Lightning messages consist of a header and a body. The header and the body have their own HMAC. This ensures that the headers of fixed length will also be encrypted and adversaries won't be able to deduce what messages are being sent by inspecting the length.
A Lightning message is an encrypted data string that can be sent between two peers on the Lightning Network. Similar to other communication protocols, Lightning messages consist of a header and a body. The header and the body have their own HMAC. This ensures that the headers of fixed length will also be encrypted and adversaries won't be able to deduce what messages are being sent by inspecting the length. Lightning Messages are the core building block that is defined in the Messaging layer.
The Lightning Network is a protocol on top of Bitcoin (or other cryptocurrencies).
It creates a network of payment channels which enables the trustless forwarding of payments through the network with the help of HTLCs and Onion Routing.
Other components of the Lightning Network are the gossip protocol, the transport layer, and payment requests.
The source code is available at https://github.com/lightningnetwork.
Lightning Network Protocol Suite::
The Lightning Protocol Suite consists of 5 Layers which are responsible for various parts of the protocol.
From bottom (the first layer) to the top (the fifth layer) these layers are called: Network Communicatin Layer, Messaging Layer, Peer 2 Peer Layer, Routing Layer, Payment Layer.
Various BOLTs define tasks on one or several layers.
Lightning Network Node, Lightning Node::
A participant on the Lightning Network.
@ -291,20 +321,24 @@ localfeatures::
Locktime::
Locktime, or more technically nLockTime, is the part of a transaction which indicates the earliest time or earliest block when that transaction may be added to the blockchain.
Messaging Layer:
The Layer builds on top of the Network Connection Layer of the Lightning Network Protocol Suite.
It is responsible to ensure an encrypted and secure communication and exchange of information via the chosen Network Connection Layer protocol.
The messaging layer defines the framing and format of Lightning Messages as defined in BOLT 01.
The feature bits defined in BOLT 09 are also part of this layer.
millisatoshi::
The smallest unit of account on the Lightning Network. A millisatoshi is one hundred billionth of a single bitcoin. A millisatoshi is one thousandth of one Satoshi. Millisatoshis do not exist, nor can they be settled on the Bitcoin network.
mpp::
A multipart payment (which is often also referred to as multipath payment) is a method for payments where the sender can split the payment amount into multiple smaller parts and deliver them potentially along multiple potentially disjoint paths. As the MPP strategies do not require one to send the smaller splits along different paths we find the term multipart payment more accurate than multipath payment.
A multipart payment (which is often also referred to as multipath payment) is a method for payments where the sender can split the payment amount into multiple smaller parts and deliver them potentially along multiple potentially disjoint paths. As the MPP strategies do not require one to send the smaller splits along different paths the term multipart payment is more accurate than multipath payment. In computer science multipart paryments are modelled as network flows.
multisignature::
Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction.
Payment channels are always encoded as multisignature addresses requiring one signature from each peer of the payment channel.
In the standard case of a two-party payment channel, a 2-of-2 multisignature address is used.
Neutrino::
Neutrino is a later alternative to SPV that also verifies whether certain transactions are contained in a block without downloading the entire block. However, it offers a number of improvements over SPV: Neutrino does not transmit any information that would allow a third party to determine users’ identities, it facilitates the use of non-custodial apps, and it reduces the computational load on full nodes. The trade-off for these improvements is that Neutrino requires more data from the full node than SPV.
node::
See _Lightning Network Node_
@ -316,12 +350,17 @@ network capacity::
Note that since only public channel capacity can be observed, the true network capacity is unknown.
See _private channel_.
Network Connection Layer::
The lowest layer of the Lightning Network Protocol Suite.
Its responsability is to support internet protocols like IPv4, IPv6, TOR2 and TOR3 and use them to establise a secure cryptographic communication channel on top of them as defined in BOLT8 or to speak DNS for the Bootstrapping of the Network as defined BOLT 10.
Noise_XK::
The template of the Noise protocol framework to establish an authenticated and encrypted communication channel between two peers of the Lightning Network.
X means that no public key needs to be known from the initiator of the connection.
K means that the public key of the receiver needs to be known.
More particular (from: http://www.noiseprotocol.org/noise.html) the protocol enables encryption to a known recipient and strong forward secrecy. This payload is encrypted based on an ephemeral-ephemeral DH as well as an ephemeral-static DH with the recipient's static key pair. Assuming the ephemeral private keys are secure, and the recipient is not being actively impersonated by an attacker that has stolen its static private key, this payload cannot be decrypted. Sender authentication is resistant to key-compromise impersonation (KCI). The sender authentication is based on an ephemeral-static DH ("es" or "se") between the sender's static key pair and the recipient's ephemeral key pair. Assuming the corresponding private keys are secure, this authentication cannot be forged.
// the noise protocol documentation is according to their IPR section public domain. The author is Trevor Perrin (noise@trevp.net)
onion routing::
Onion routing is a technique for anonymous communication over a computer network.
@ -368,12 +407,20 @@ payment channel::
The other transactions are not included in the blockchain and are said to occur "off-chain".
There are various methods of constructing a payment channel discussed further in the chapter on channel construction.
Payment Layer::
The top and fifth Layer of the Lightning Network Protocol Suite operates on top of the Routing Layer.
Its responsability is to enable the Payment process via BOLT #11 invoices.
While it heaviliy uses the Channel Graph from the Gossip Protcol as defined in BOLT #7 the actual strategies to deliver a payment are not part of the specification of the Protocol and left to the implementations.
As this topic is very import to ensure reliability of the Payment process and Payment deliver we included it in this book.
peer::
Two parties which form a payment channel are called peers.
In particular, they are connected via an encrypted, authenticated communication over a TCP Socket.
penalty transaction::
See _Breach Remedy Transaction_.
Peer 2 Peer Layer::
The Peer to Peer layer is the third layer of the Lightning Network Protocol Suite and works on top of the Messaging Layer.
It is responsible to define the syntax and semantics of Information exchanged between peers via Lightning Messages.
This consists of Control messages as defined in BOLT #9, Channel esablishment, operation and closing messages as defined in BOLT #2 as well as Gossip and Routing Messages as defined in BOLT #7.
private channel::
A channel not announced to the rest of the network.
@ -397,6 +444,9 @@ proof of work::
In Bitcoin, miners must find a numeric solution to the SHA256 algorithm that meets a network-wide target, called the difficulty target.
See _bitcoin mining_.
PTLC::
A PTLC is the short form for Point Timelock contract. Similar to an HTLC it is a Bitcoin script that allows a conditional spend either on the presentation of a secret or after a certain blockheight has passed. The secret in PTLCs does not depend on a preimage of a hash function but rather on the private key from an elliptic curve point. The security assumption is thus based on the discret logarithm. PTLCs are not yet used on the Lightning Network.
Relative Timelock::
Relative Timelock is a type of timelock which allows an input to specify the earliest time the input can be added to a block. The time is relative and is based on when the output referenced by that input was included in a block. Such a feature is jointly achieved by nSequence field and CheckSequenceVerify opcode, which was introduced by BIP68/112/113.
@ -418,6 +468,11 @@ revocation key::
RIPEMD-160::
RIPEMD-160 is a 160-bit cryptographic hash function. RIPEMD-160 is a strengthened version of RIPEMD with a 160-bit hash result, and is expected to be secure for the next ten years or more.
Routing Layer::
The fourth Layer of the Lightning Network Protocol Suite operats on top of the Peer 2 Peer Layer.
Its responsability is to define the cryptographic primitives and neccessary communication protocol to allow the secure and atomic transport of bitcoin from a sending node to a recipient node.
While BOLT #4 defines the onion format that is used to communicate transport information to remote peers with whom no direct connections exist the actual transport of the Onions and cryptographic primitives are defined in BOLT #2.
topology::
The topology of the Lightning Network describes the shape of the Lightning Network as a mathematical graph.
Nodes of the graph are the Lightning Network nodes or participants.
@ -433,6 +488,9 @@ satoshi::
Satoshi Nakamoto::
Satoshi Nakamoto is the name used by the person or group of people who designed Bitcoin and created its original reference implementation, Bitcoin Core. As a part of the implementation, they also devised the first blockchain database. In the process, they were the first to solve the double-spending problem for digital currency. Their real identity remains unknown.
Schnorr Signature::
A linear sceme for digital signatures that is supposed to be activated in Bitcoin during November 2021. It enables many improvements on the Lightning Network like PTLCs which are supposed to superceed HTLCs.
Script::
Bitcoin uses a scripting system for transactions called Script. Forth-like, it is simple, stack-based, and processed from left to right. It is purposefully not Turing-complete, with no loops.
ScriptSig or signature script is the data generated by a spender, which are almost always used as variables to satisfy a pubkey script.
Second stage HTLC::
TBD.
secret key (aka private key)::
The secret number that unlocks bitcoin sent to the corresponding address. pass:[<span class="keep-together">A secret</span>] key looks like the following:
+
@ -485,7 +540,7 @@ SPHINX Mix Format::
The paper can be found at https://cypherpunks.ca/~iang/pubs/Sphinx_Oakland09.pdf
Submarine Swap::
A Submarine Swaps enables transfers between on-chain Bitcoin addresses and off-chain locations, like the Lightning Network. Just as standard LN transfers chain payments by means of HTLCs that make the final claim on funds conditional on the recipient revealing a secret to all links in the chain, Submarine Swaps use the same logic and procedure to transfer funds across the on-chain/off-chain barrier with minimal trust. They can also be used to enable transfers from another chain, say Litecoin, to an off-chain LN address. Reverse Submarine Swaps allow bitcoin transfers in the opposite direction, from an off-chain LN location to an on-chain address.
A Submarine Swaps enables transfers between on-chain Bitcoin addresses and off-chain locations, like the Lightning Network. Just as standard LN transfers chain payments by means of HTLCs that make the final claim on funds conditional on the recipient revealing a secret to all links in the chain, Submarine Swaps use the same logic and procedure to transfer funds across the on-chain/off-chain barrier with minimal trust. Reverse Submarine Swaps allow bitcoin transfers in the opposite direction, from an off-chain LN node to an on-chain address.
timelock::
A timelock is a type of encumbrance that restricts the spending of some bitcoin until a specified future time or block height. Timelocks feature prominently in many Bitcoin contracts, including payment channels and Hashed Timelock Contracts.
@ -510,11 +565,8 @@ transport layer::
unspent transaction output (UTXO)::
See _output_
upstream payment::
TBD.
wallet::
A wallet is a piece of software that holds Bitcoin addresses and secret keys. It is used to send, receive, and store bitcoin.
A wallet is a piece of software that holds Bitcoin addresses and secret keys. It is used to send, receive, and store bitcoin. In the context of the Lightning Network it should also hold revocation secrets of old channels state and the latest presigned commitment transactions.
watchtower::
Watchtowers are a security service on the Lightning network that monitor channels.
@ -524,9 +576,4 @@ watchtower::
Watchtowers can be run by the channel partners themselves, or as a paid service offered by a third party.
Watchtowers have no control over the funds in the channels themselves.
zombie channel::
An open channel where one of the channel partners has gone permanently offline.
Zombie channels cannot be used to route payments and have only downsides to the online partner.
It is good practice to close zombie channels although they can be tricky to identify as the online partner can't always be sure if the offline party will stay offline.
Some contributed definitions have been sourced under a CC-BY license from the https://en.bitcoin.it/wiki/Main_Page[Bitcoin Wiki], https://en.wikipedia.org[Wikipedia], https://github.com/bitcoinbook/bitconbook[Mastering Bitcoin] or from other open source documentation sources.
Rene Pickhardt
3 years ago