This quick glossary contains many of the terms used in relation to Bitcoin and the Lightning Network. These terms are used throughout the book, so bookmark this for a quick reference.
address::
Bitcoin 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 script that defines more complex spending conditions. The preceding example is a bech32 address encoding a witness program locking funds to the hash of a public key (See _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.
Bitcoin 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 script that defines more complex spending conditions. The preceding example is a bech32 address encoding a witness program locking funds to the hash of a public key (See _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.
asymmetric cryptographic system::
@ -29,13 +29,13 @@ balance::
See _capacity_.
bech32::
bech32 refers to a generic check-summed base32-encoded format featuring strong error-detection guarantees. While bech32 was originally developed to be used as the address format for native SegWit outputs (BIP-173), it is also used to encode lightning invoices (BOLT #11). While native SegWit version 0 outputs (P2WPKH and P2WSH) use bech32, higher native SegWit output versions (e.g., Pay-to-Taproot or P2TR) use the improved variant bech32m (BIP-350). Bech32(m) addresses are sometimes referred to as "bc1" addresses, reflecting the prefix of such addresses. Native SegWit outputs are more blockspace-efficient than older addresses and therefore may reduce transaction fees for the owner of such an address.
bech32 refers to a generic check-summed base32-encoded format featuring strong error-detection guarantees. While bech32 was originally developed to be used as the address format for native SegWit outputs (BIP-173), it is also used to encode lightning invoices (BOLT #11). While native SegWit version 0 outputs (P2WPKH and P2WSH) use bech32, higher native SegWit output versions (e.g., Pay-to-Taproot or P2TR) use the improved variant bech32m (BIP-350). bech32m addresses are sometimes referred to as "bc1" addresses, reflecting the prefix of such addresses. Native SegWit outputs are more blockspace-efficient than older addresses and therefore may reduce transaction fees for the owner of such an address.
Bitcoin Improvement Proposal (BIP)::
A proposal that members of the Bitcoin community have submitted to improve Bitcoin. For example, BIP-21 is a proposal to improve the Bitcoin uniform resource identifier (URI) scheme. BIPs can be found at https://github.com/bitcoin/bips[GitHub].
bitcoin, Bitcoin::
Depending on the context, could refer to the name of the currency unit (the coin), the network, or the underlying enabling protocol. Written as bitcoin with a lowercase "b" usually refers to the currency unit. Bitcoin with an uppercase "B" usually refers to the protocol, or system.
Depending on the context, could refer to the name of the currency unit (the coin), the network, or the underlying enabling protocol. Written as bitcoin with a lowercase "b" usually refers to the currency unit. Bitcoin with an uppercase "B" usually refers to the protocol or system.
Bitcoin mining::
Bitcoin mining is the process of constructing a block from recent Bitcoin transactions and then solving a computational problem required as proof of work.
@ -59,7 +59,7 @@ blockchain::
an attacker would need to outdo existing proof of work to replace already published blocks, making each block probabilistically immutable as it is buried under subsequent blocks.
BOLT::
BOLT, or Basis Of Lightning Technology, is the formal specification of the Lightning Network. Unlike Bitcoin, which has a reference implementation that also serves as the protocol's specification, the various LN 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[GitHub].
BOLT, or Basis of Lightning Technology, is the formal specification of the Lightning Network. Unlike Bitcoin, which has a reference implementation that also serves as the protocol's specification, the various LN 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[GitHub].
capacity::
The capacity of a payment channel is equivalent to the amount of bitcoin provided by the funding transaction.
@ -80,7 +80,7 @@ CLTV::
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 BIP-34 must first feature the current block height to ensure that coinbase transactions are unique.
The coinbase allows up 100 bytes of arbitrary data, but since BIP-34, it must first feature the current block height to ensure that coinbase transactions are unique.
Not to be confused with coinbase transaction.
coinbase transaction::
@ -109,14 +109,14 @@ contract::
Diffie–Hellman Key Exchange (DHKE)::
On the Lightning Network, the Elliptic Curve Diffie–Hellman (ECDH) method is used.
It is an anonymous key agreement protocol that allows two parties, each having an elliptic-curve public-private key pair, to establish a shared secret over an insecure communication channel.
It is an anonymous key agreement protocol that allows two parties, each having an ellipticcurve public-private key pair, to establish a shared secret over an insecure communication channel.
This shared secret may be directly used as a key, or to derive another key.
The key, or the derived key, can then be used to encrypt subsequent communications using a symmetric-key cipher.
An example of the derived key would be the shared secret between the ephemeral session key of a sender of an onion with the node's public key of a hop of the onion as described and used by the SPHINX Mix Format.
An example of the derived key would be the shared secret between the ephemeral session key of a sender of an onion with the node's public key of a hop of the onion, as described and used by the SPHINX Mix Format.
digital signature::
A digital signature is a mathematical scheme for verifying the authenticity and integrity of digital messages or documents.
They can be seen as cryptographic commitments in which the message is not hidden.
It can be seen as a cryptographic commitment in which the message is not hidden.
double-spending::
Double-spending is the result of successfully spending some money more than once.
@ -126,7 +126,7 @@ Elliptic Curve Digital Signature Algorithm (ECDSA)::
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by the holder of the correct private key.
Eclair::
Implementation of the LN Protocol by the Parisbased company https://acinq.co[ACINQ]. It is written in Scala. Source code is at https://github.com/ACINQ/eclair[GitHub].
Implementation of the LN Protocol by the Paris-based company https://acinq.co[ACINQ]. It is written in Scala. Source code is at https://github.com/ACINQ/eclair[GitHub].
encoding::
Encoding is the process of converting a message into a different form. For example, converting a number from decimal to a hexadecimal.
@ -135,13 +135,13 @@ Electrum server::
An Electrum server is a Bitcoin node with an additional interface (API). It is often required by bitcoin wallets that do not run a full node. For example, these wallets check the status of specific transactions or broadcast transactions to the mempool using Electrum server APIs. Some Lightning wallets also use Electrum servers.
ephemeral key::
Ephemeral keys are keys that are only used for a short time and not retained after use. They are often derived for use in one session from another key that is held longterm. Ephemeral keys are mainly used within the SPHINX Mix Format and onion routing on the Lightning Network.
Ephemeral keys are keys that are only used for a short time and not retained after use. They are often derived for use in one session from another key that is held long-term. Ephemeral keys are mainly used within the SPHINX Mix Format and onion routing on the Lightning Network.
This increases the security of transported messages or payments.
Even if an ephemeral key leaks, only information about a single session becomes public.
feature bits::
A binary string that Lightning nodes use to communicate to each other which features they support.
Feature bits are included in many Lightning Messages as well as BOLT #11.
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.
@ -176,7 +176,7 @@ hash::
hash-based message authentication code (HMAC)::
HMAC is an algorithm for verifying the integrity and authenticity of a message based on a hash function and a cryptographic key.
It is used in onion routing to ensure the integrity of a packet at each hop, as well as within the Noise protocol variant used for message encryption.
It is used in onion routing to ensure the integrity of a packet at each hop, as well as within the Noise Protocol variant used for message encryption.
hash function::
A cryptographic hash function is a mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size (a hash) and is designed to be a one-way function, that is, a function that is infeasible to invert.
@ -186,7 +186,7 @@ hashlock::
A hashlock is a Bitcoin Script spending condition that restricts the spending of an output until a specified piece of data is revealed. Hashlocks have the useful property that once any hashlock is revealed through spending, any other hashlocks secured using the same key can also be spent. 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.
hash time-locked contract (HTLC)::
A hash time-locked contract (HTLC) is a Bitcoin Script that consists of hashlocks and timelocks to require that the recipient of a payment either spends the payment prior to a deadline by presenting the has preimage or the sender can claim a refund after the timelock expires.
A hash time-locked contract (HTLC) is a Bitcoin Script that consists of hashlocks and timelocks to require that the recipient of a payment either spends the payment prior to a deadline by presenting the hash preimage or the sender can claim a refund after the timelock expires.
On the Lightning Network, HTLCs are outputs in the commitment transaction of a payment channel and are used to enable the trustless routing of payments.
invoice::
@ -194,43 +194,43 @@ invoice::
Invoices include the payment hash, the amount, a description, and the expiry time. Lightning invoices are defined in BOLT #11.
Invoices can also include a fallback Bitcoin address to which the payment can be made in case no route can be found, as well as hints for routing a payment through a private channel.
JIT-Routing::
Just-in-time routing is an alternative to source-based routing that was first proposed by coauthor René Pickhardt.
With JIT-Routing, intermediary nodes along a path can pause an in-flight payment, to re-balance their channels before proceeding with the payment.
just-in-time (JIT) routing::
Just-in-time (JIT) routing is an alternative to source-based routing that was first proposed by coauthor René Pickhardt.
With JIT routing, intermediary nodes along a path can pause an in-flight payment to rebalance their channels before proceeding with the payment.
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. Lightning messages are the main building block of the Messaging layer.
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. Lightning messages are the main building block of 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.
Lightning Network Protocol Suite::
The Lightning Protocol Suite consists of five Layers that are responsible for various parts of the protocol.
From bottom (the first layer) to the top (the fifth layer), these layers are called the Network Communication Layer, the Messaging Layer, the Peer 2 Peer Layer, the Routing Layer, and the Payment Layer.
Lightning Network protocol suite::
The Lightning Network protocol suite consists of five layers that are responsible for various parts of the protocol.
From bottom (the first layer) to the top (the fifth layer), these layers are called the network communication layer, the messaging layer, the peer-to-peer layer, the routing layer, and the payment layer.
Various BOLTs define parts of one or several layers.
Lightning Network node, Lightning node::
A computer participating in the Lightning Network, via the Lightning Peer-to-Peer protocol.
A computer participating in the Lightning Network, via the Lightning peer-to-peer protocol.
Lightning nodes have the ability to open channels with other nodes, send and receive payments, and route payments from other users.
Typically a Lightning node user will also run a Bitcoin node.
Typically, a Lightning node user will also run a Bitcoin node.
lnd::
Implementation of the LN Protocol by the San Francisco-based company https://lightning.engineering[Lightning Labs].
It is written in Go. Source code is at https://github.com/lightningnetwork/lnd[GitHub].
Local features (field: +localfeatures+)::
Localfeatures of a LN node are the configurable features of direct interest to its peers.
They are announced in the `init` message of the peer protocol as well as the `channel_announcement` and `node_announcement` messages of the gossip protocol.
local features (field: +localfeatures+)::
Localfeatures of an LN node are the configurable features of direct interest to its peers.
They are announced in the `init` message of the peer protocol as well as in the `channel_announcement` and `node_announcement` messages of the gossip protocol.
Locktime::
locktime::
Locktime, or more technically nLockTime, is the part of a Bitcoin transaction that 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 for ensuring an encrypted and secure communication and exchange of information via the chosen Network Connection Layer protocol.
messaging layer::
The messaging layer builds on top of the network connection layer of the Lightning Network protocol suite.
It is responsible for ensuring 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 #1.
The feature bits defined in BOLT #9 are also part of this layer.
@ -238,8 +238,8 @@ Messaging 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 on, nor can they be settled on, the Bitcoin network.
multipart payment (MPP)::
A multipart payment (MPP), often also referred to as a multipath payment, is a method for splitting the payment amount into multiple smaller parts and delivering them along one or more paths. Since MPP can send many or all parts over a single path, the term multipart payment is more accurate than multipath payment. In computer science, multipart payments are modeled as network flows.
multipart payments (MPP)::
Multipart payments (MPP), often also referred to as multipath payments, are a method for splitting the payment amount into multiple smaller parts and delivering them along one or more paths. Since MPP can send many or all parts over a single path, the term multipart payment is more accurate than multipath payment. In computer science, multipart payments are modeled as network flows.
multisignature::
Multisignature (multisig) refers to a script that requires more than one signature to authorize spending.
@ -247,17 +247,17 @@ multisignature::
In the standard case of a two-party payment channel, a 2-of-2 multisig address is used.
node::
See _Lightning Network Node_.
See _Lightning Network node_.
network capacity::
LN capacity is the total amount of bitcoin locked and circulated inside the Lightning Network.
It is the sum of capacities of each public channel.
It reflects the usage of the Lightning Network to some extent because we expect that people put bitcoin into Lightning channels to spend it or forward other users' payments.
Hence the higher the amount of bitcoin in Lightning channels, the higher the expected usage of the Lightning Network.
Note that since only public channel capacity can be observed, the true network capacity is unknown. Also, since a channel's capacity can enable an unlimited number of payments back-and-forth, network capacity does not imply a limit of value transferred on the Lightning Network.
Note that since only public channel capacity can be observed, the true network capacity is unknown. Also, since a channel's capacity can enable an unlimited number of payments back and forth, network capacity does not imply a limit of value transferred on the Lightning Network.
Network Connection Layer::
The lowest layer of the Lightning Network Protocol Suite.
network connection layer::
The lowest layer of the Lightning Network protocol suite.
Its responsibility is to support internet protocols like IPv4, IPv6, TOR2, and TOR3, and use them to establish a secure cryptographic communication channel as defined in BOLT #8, or to speak DNS for the bootstrapping of the network as defined in BOLT #10.
Noise_XK::
@ -273,29 +273,29 @@ onion routing::
The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes.
output::
The output of a Bitcoin transaction, also called an Unspent Transaction Output (UTXO).
The output of a Bitcoin transaction, also called an unspent transaction output (UTXO).
An output is an indivisible amount of bitcoin that can be spent, as well as a script that defines what conditions need to be fulfilled for that bitcoin to be spent.
Every bitcoin transaction consumes some outputs of previously recorded transactions and creates new outputs that can be spent later by subsequent transactions.
A typical bitcoin output will require a signature to be spent, but outputs can require the fulfillment of more complex scripts.
For example, a multisignature script requires two or more key holders sign before the output can be spent, which is a fundamental building block of the Lightning Network.
Pay To Public Key Hash (P2PKH)::
Pay-to-Public-Key-Hash (P2PKH)::
P2PKH is a type of output that locks bitcoin to the hash of a public key. An output locked by a P2PKH script can be unlocked (spent) by presenting the public key matching the hash and a digital signature created by the corresponding private key.
Pay To Script Hash (P2SH)::
P2SH is a versatile type of output that allows the use of complex Bitcoin Scripts. With P2SH the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, value is locked to the hash of a script, which must be presented and fulfilled to spend the output.
Pay-to-Script-Hash (P2SH)::
P2SH is a versatile type of output that allows the use of complex Bitcoin Scripts. With P2SH, the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, value is locked to the hash of a script, which must be presented and fulfilled to spend the output.
P2SH address::
P2SH addresses are Base58Check encodings of the 20-byte hash of a script. P2SH addresses start with a "3." P2SH addresses hide all of the complexity, so that the sender of a payment does not see the script.
Pay To Witness Public Key Hash (P2WPKH)::
P2WPKH is the SegWit equivalent of P2PKH, using a segregated witness. The signature to spend a P2WPKH output is put in the witness tree instead of the scriptSig field. See _SegWit_.
Pay-to-Witness-Public-Key-Hash (P2WPKH)::
P2WPKH is the SegWit equivalent of P2PKH, using a segregated witness. The signature to spend a P2WPKH output is put in the witness tree instead of the ScriptSig field. See _SegWit_.
P2WPKH address::
The "native SegWit v0" address format, P2WPKH addresses are bech32-encoded and start with "bc1q".
Pay To Witness Script Hash (P2WSH)::
P2WSH is the SegWit equivalent of P2SH, using a segregated witness. The signature and script to spend a P2WSH output is put in the witness tree instead of the scriptSig field. See _SegWit_.
Pay-to-Witness-Script-Hash (P2WSH)::
P2WSH is the SegWit equivalent of P2SH, using a segregated witness. The signature and script to spend a P2WSH output is put in the witness tree instead of the ScriptSig field. See _SegWit_.
P2WSH address::
The "native Segwi v0" script address format, P2WSH addresses are bech32-encoded and start with "bc1q".
@ -316,17 +316,17 @@ payment channel::
In a typical payment channel only two transactions, the funding transaction and the commitment transaction, are added to the blockchain.
Payments sent across the channel are not recorded in the blockchain and are said to occur "off-chain".
Payment Layer::
The top and fifth Layer of the Lightning Network Protocol Suite operates on top of the Routing Layer.
payment layer::
The top and fifth layer of the Lightning Network protocol suite operates on top of the routing layer.
Its responsibility is to enable the Payment process via BOLT #11 invoices.
While it heavily uses the Channel Graph from the Gossip Protocol 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 important to ensure reliability of the payment delivery process, we included it in this book.
peer::
The participants in a Peer-to-Peer network. In the Lightning Network, peers connect to each other via encrypted, authenticated communication through a TCP socket, over IP or Tor.
The participants in a peer-to-peer network. In the Lightning Network, peers connect to each other via encrypted, authenticated communication through a TCP socket, over IP or Tor.
Peer-to-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.
peer-to-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 for defining the syntax and semantics of information exchanged between peers via Lightning Messages.
This consists of control messages as defined in BOLT #9, channel establishment, operation and closing messages as defined in BOLT #2 as well as gossip and routing messages as defined in BOLT #7.
@ -362,8 +362,8 @@ revocation key::
RIPEMD-160::
RIPEMD-160 is a cryptographic hash function that produces a 160-bit (20-byte) hash.
Routing Layer::
The fourth Layer of the Lightning Network Protocol Suite operates on top of the Peer-to-Peer layer.
routing layer::
The fourth layer of the Lightning Network protocol suite operates on top of the peer-to-peer layer.
Its responsibility is to define the cryptographic primitives and necessary 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.
@ -446,7 +446,7 @@ transport layer::
In computer networking, the transport layer is a conceptual division of the methods used by computers (and ultimately applications) to talk to each other.
The transport layer provides communication services between computers such as flow control, verification, and multiplexing (to allow multiple applications to work on a computer at the same time).
kristen@oreilly.com
3 years ago