|
|
[preface]
|
|
|
[[glossary]]
|
|
|
== Quick Glossary
|
|
|
|
|
|
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.
|
|
|
* capacity: channels require bitcoin to be pre-loaded into them before they can be used. This becomes the maximum amount of bitcoin that can be transacted using this channel i.e. it's capacity.
|
|
|
** in-bound capacity: the maximum amount of bitcoin that can be received using a channel. Your in-bound capacity is increased when a user opens a channel with you, or you make a payment to another user.
|
|
|
** out-bound capacity: the maximum amount of bitcoin that can be sent using a channel. Your out-bound capacity is increased when you open a channel with another user, or you receive a payment from another user.
|
|
|
* invoice: a request for payment from another user that can take the form of a text string or a QR code. Lightning Invoices can be specified with a description and an amount the invoicer is requesting.
|
|
|
* node: a node is a participant on the Lightning Network. Nodes can open and close channels with each other, route payments from other nodes, and manage their own wallets. Typically a Lightning Network node user will also run a Bitcoin Node to keep track of the status of on-chain payments
|
|
|
* on-chain/off-chain: a payment is considered "on-chain" if it is included in the Bitcoin (or other underlying) blockchain where it is publicly visible to all nodes. Payments that are not visible in the underlying blockchain are "off-chain"
|
|
|
* route: when making a payment from one user to another, the payment will move along many intermediary nodes before reaching the receiver. This path from the sender to the receiver forms a route on the network.
|
|
|
** routing fees: each intermediary node will request a fee for transmitting the payment. The sum of these are the routing fees paid by the sender
|
|
|
* transaction: a payment from one user to another. Lightning Network transactions are Bitcoin transactions not yet recorded on the Bitcoin blockchain.
|
|
|
** funding transaction: a transaction that locks bitcoin into a smart contract to open a channel.
|
|
|
** settlement transaction: a transaction that closes a channel, and allocates the locked bitcoin to the channel owners according to the final balance of the channel.
|
|
|
** penalty transaction: if one user tries to "cheat" by claiming a prior state of the channel, the other user can publish a penalty transaction to the Bitcoin blockchain, which allocates all bitcoin in that channel to them.
|
|
|
* wallet: an application that manages private keys in order to send and receive bitcoin. Lightning Wallets have additional features over and above Bitcoin Wallets in that they can open and close channels, and send and receive Lightning payments.
|
|
|
|
|
|
////
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions.
|
|
|
Effective security only requires keeping the private key private; the public key can be openly distributed without compromising security.
|
|
|
https://en.wikipedia.org/w/index.php?title=Public-key_cryptography&oldid=877579180
|
|
|
|
|
|
Autopilot::
|
|
|
Autopilot is a recommendation engine for Lightning Network nodes that uses statistics of the known topology to suggest which nodes they should open channels with.
|
|
|
Depending on the implementation of the autopilot, the channel capacity may also be recommended.
|
|
|
Autopilots are not part of the Lightning Network Protocol.
|
|
|
|
|
|
balance::
|
|
|
The balance of a payment channel is the amount of bitcoin that belongs to each channel partner.
|
|
|
For example, Alice could open a channel with Bob for the value of 1 BTC.
|
|
|
The channel balance is then 1 BTC to Alice and 0 BTC to Bob.
|
|
|
As the users transact the channel balance will update.
|
|
|
For example if Alice sends 0.2 BTC to Bob, then the balance is now 0.8 BTC to Alice and 0.2 to Bob.
|
|
|
When the channel is closed the bitcoin in the channel will be divided between the two channel partners according to the latest balance encoded in the commitment transaction.
|
|
|
In the Lightning Network, the ability to send and receive payments is limited by channel balances.
|
|
|
See _capacity_.
|
|
|
|
|
|
bech32::
|
|
|
Bech32 refers to a generic checksummed base32 encoded format featuring strong error detection guarantees. While bech32 was originally developed to be used as the address format for native segwit outputs (BIP173), it is also used to encode lightning invoices (BOLT11). While native segwit version 0 outputs (P2WPKH and P2WSH) use bech32, higher native segwit output versions (e.g. P2TR) use the improved variant bech32m (BIP350). Bech32(m) addresses are sometimes referred to as "bc1" for the prefix of such addresses. Native segwit outputs are more blockspace efficient than older output types and therefore may require lower fees to be spent.
|
|
|
|
|
|
bip, BIP::
|
|
|
Bitcoin Improvement Proposals. A set of proposals 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.
|
|
|
|
|
|
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. See https://www.bitcoin.org for general information. The source code can be found at https://github.com/bitcoin/bitcoin.
|
|
|
|
|
|
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.
|
|
|
It is the process by which the shared bitcoin ledger (i.e. the bitcoin blockchain) is updated and by which new transactions are included in the ledger.
|
|
|
It is also the process by which new bitcoin is issued.
|
|
|
Every time a new block is created, the mining node will receive new bitcoin created within the coinbase transaction of that block.
|
|
|
|
|
|
block::
|
|
|
A block consist of a header and a body of valid transactions.
|
|
|
The block is marked with a timestamp and commits to a specific predecessor block.
|
|
|
When hashed, the block header provides the proof of work which makes the blockchain probabilistically immutable.
|
|
|
Blocks must adhere to the rules enforced by network consensus to extend the main blockchain.
|
|
|
When a block is appended to the blockchain, the included transactions are considered to have their first confirmation.
|
|
|
|
|
|
blockchain::
|
|
|
The blockchain is a distributed log of all Bitcoin transactions.
|
|
|
Transactions are grouped in discrete updates called blocks limited to up to 4 million weight units.
|
|
|
Blocks are produced approximately every ten minutes via a stochastic process called mining.
|
|
|
Each block includes a computationally intensive "proof of work".
|
|
|
The proof of work requirement is used to regulate the block intervals and protect the blockchain against attacks to rewrite history:
|
|
|
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 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.
|
|
|
|
|
|
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.
|
|
|
It does not reveal any information about how much bitcoin each of the channel partners owns in the channel.
|
|
|
A high capacity does not guarantee that the channel can be used for routing in both directions.
|
|
|
The capacity does not change if some of the capacity is locked up in HTLCs.
|
|
|
This means that even a high capacity channel could at any time be unable to route a payment of a certain amount in both directions.
|
|
|
Not to be confused with the balance.
|
|
|
|
|
|
c-lightning::
|
|
|
Implementation of the Lightning Network Protocol by the Victoria based company https://blockstream.com[Blockstream]. It is written in C. Source code is at https://github.com/ElementsProject/lightning.
|
|
|
|
|
|
closing transaction::
|
|
|
If both channel partners agree to close a channel they will create an exercise settlement transaction that reflects the most recent commitment transaction.
|
|
|
It does not include any Hashed Time Lock Contracts or Revocable Sequence Maturity Contracts.
|
|
|
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.
|
|
|
Not to be confused with coinbase transaction.
|
|
|
|
|
|
coinbase transaction::
|
|
|
The first transaction in a block which is always created by a miner and which includes a single coinbase.
|
|
|
The coinbase transaction may claim the block reward and assign it to one or more outputs.
|
|
|
The block reward consists of two parts.
|
|
|
First, newly generated coins. The amount of allowed coins to be generated is part of the consensus rules and decreases over time based on the current block height.
|
|
|
Second, the miner may also claim all the fees of transactions included in the current block.
|
|
|
Coinbase outputs can only be spent after maturing for 100 blocks.
|
|
|
If the block includes any segwit transactions, the coinbase transaction must include a commitment to the witness transaction identifiers in an additional nulldata output.
|
|
|
Not to be confused with coinbase.
|
|
|
|
|
|
cold storage::
|
|
|
Refers to keeping an amount of bitcoin offline. Cold storage is achieved when Bitcoin private keys are created and stored in a secure offline environment. Cold storage is important to protect bitcoin holdings. Online computers are vulnerable to hackers and should not be used to store a significant amount of bitcoin.
|
|
|
|
|
|
Commitment Transaction::
|
|
|
A commitment transaction is a Bitcoin transaction, signed by both channel partners, that encodes the latest balance of a channel.
|
|
|
Every time a new transaction is made or forwarded using the channel, the channel balance will update, and a new commitment transaction will be signed by both parties.
|
|
|
Importantly, for a channel between Alice and Bob, both Alice and Bob keep their own version of the commitment transaction, which is also signed by the other party.
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
contract::
|
|
|
A contract is a set of Bitcoin transactions which together result in a certain desired behavior.
|
|
|
Examples are RSMCs to create a trustless, bi-directional payment channel or HTLCs to create a mechanism which allows trustless forwarding of payments through third parties.
|
|
|
|
|
|
Diffie Hellman (DH) Key Exchange::
|
|
|
On the Lightning Network, the Elliptic Curve Diffie-Hellman 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.
|
|
|
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.
|
|
|
Via https://en.wikipedia.org/w/index.php?title=Elliptic-curve_Diffie%E2%80%93Hellman&oldid=836070673
|
|
|
|
|
|
digital signature::
|
|
|
A digital signature is a mathematical scheme for verifying the authenticity of digital messages or documents.
|
|
|
A valid digital signature gives a recipient reason to believe that the message was created by a known sender, that the sender cannot deny having sent the message, and that the message was not altered in transit.
|
|
|
They can be seen as cryptographic commitments in which the message is not hidden.
|
|
|
https://en.wikipedia.org/w/index.php?title=Digital_signature&oldid=876680165
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Eclair::
|
|
|
Implementation of the Lightning Network Protocol by the Paris based company https://acinq.co[ACINQ]. It is written in Scala. Source code is at https://github.com/ACINQ/eclair.
|
|
|
|
|
|
encoding::
|
|
|
Encoding is the process of converting a message into a different form.
|
|
|
For example, converting a human-readable form to a digitally space-efficient form.
|
|
|
|
|
|
Electrum server::
|
|
|
An Electrum server is a Bitcoin node with an additional interface (API) 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, so even if they are non-custodial, they may compromise user sovereignty in that users trust the Electrum server to provide accurate information and privacy in that calls made to the Electrum server may reveal private information.
|
|
|
|
|
|
|
|
|
ephemeral key::
|
|
|
Ephemeral keys are mainly within the SPHINX Mix Format and Onion Routing on the Lightning Network.
|
|
|
They are generated for each execution of the routing process.
|
|
|
This increases the security of transported messages or payments.
|
|
|
Even if an ephemeral key leaks, only information about a single payment 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.
|
|
|
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 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.
|
|
|
From the perspective of the Bitcoin network, the process of opening a channel by creating a RSMC is started by creating the funding transaction and finished by broadcasting it to the Bitcoin network and have it included in the blockchain.
|
|
|
The value of the funding transaction is exactly the capacity of the payment channel.
|
|
|
The output of the funding transaction is a 2-of-2 multisignature script (multisig) where each channel partner controls one key.
|
|
|
It will eventually be spent by one of the commitment transactions or by the closing transaction.
|
|
|
Due to its multisig nature, it can only be spent mutually.
|
|
|
It is part of the RSMC to ensure that either side of the channel can withdraw their funds without the necessity to trust the channel partner.
|
|
|
|
|
|
globalfeatures::
|
|
|
Globalfeatures of a Lightning Network node are the features of interest for all other nodes.
|
|
|
Most commonly they are related to supported routing formats.
|
|
|
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.
|
|
|
|
|
|
Gossip Protocol::
|
|
|
Lightning Network nodes send and receive information about the topology of the Lightning Network through gossip messages which are exchanged with their peers.
|
|
|
The gossip protocol is mainly defined in BOLT 7 and defines the format of the _node_announcement_, _channel_announcement_ and _channel_update messages_.
|
|
|
In order to prevent SPAM, node announcement messages will only be forwarded if the node already has a channel and channel announcement messages will only be forwarded if the funding transaction of the channel has been confirmed by the Bitcoin network.
|
|
|
Usually, Lightning nodes connect with their channel partners, but it is fine to connect with any other Lightning node in order to process gossip messages.
|
|
|
|
|
|
hardware wallet::
|
|
|
A hardware wallet is a special type of Bitcoin wallet which stores the user's private keys in a secure hardware device.
|
|
|
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::
|
|
|
A digital fingerprint of some binary input.
|
|
|
|
|
|
hash-based message authentication code (HMAC)::
|
|
|
An HMAC is a message authentication code method 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 Norse 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 which is infeasible to invert.
|
|
|
The only way to recreate the input data from an ideal cryptographic hash function's output is to attempt a brute-force search of possible inputs to see if they produce a match, or use a rainbow table of matched hashes.
|
|
|
The ideal cryptographic hash function has five main properties: It is deterministic, so the same message always results in the same hash.
|
|
|
It is quick to compute the hash value for any given message.
|
|
|
It is infeasible to generate a message from its hash value except by trying all possible messages.
|
|
|
A small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value.
|
|
|
It is infeasible to find two different messages with the same hash value.
|
|
|
https://en.wikipedia.org/w/index.php?title=Cryptographic_hash_function&oldid=868055371
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
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.
|
|
|
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::
|
|
|
The payment process on the Lightning Network is initiated by the payee who issues an invoice.
|
|
|
Invoices include the payment hash, the amount, a description and the expiry time.
|
|
|
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.
|
|
|
An alternative to source-based routing was first proposed by co-author René Pickhardt.
|
|
|
With JIT routing, intermediary nodes along a path can pause an in-flight payment to rebalance their channels.
|
|
|
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. Lightning Messages are the core building block that is defined in the Messaging layer.
|
|
|
|
|
|
Lightning Network, Lightning Network Protocol, Lightning Protocol::
|
|
|
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 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 Communication 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.
|
|
|
A Lightning user will run Lightning node software in order to interact with other Lightning nodes.
|
|
|
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.
|
|
|
|
|
|
lnd::
|
|
|
Implementation of the Lightning Network 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.
|
|
|
|
|
|
localfeatures::
|
|
|
Localfeatures of a Lightning Network node are the configurable features of direct interest of the peer.
|
|
|
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.
|
|
|
|
|
|
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 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.
|
|
|
|
|
|
node::
|
|
|
See _Lightning Network Node_
|
|
|
|
|
|
network capacity::
|
|
|
Lightning network 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 lock bitcoin into Lightning channels in order to spend it or forward other users' payments.
|
|
|
Hence the higher the amount of bitcoin locked in 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.
|
|
|
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.
|
|
|
In an onion network, messages are encapsulated in layers of encryption, analogous to layers of an onion.
|
|
|
The encrypted data is transmitted through a series of network nodes called onion routers, each of which peels away a single layer, uncovering the data's next destination.
|
|
|
When the final layer is decrypted, the message arrives at its destination.
|
|
|
The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes.
|
|
|
https://en.wikipedia.org/w/index.php?title=Onion_routing&oldid=870849217
|
|
|
|
|
|
output::
|
|
|
The output of a bitcoin transaction, also called an Unspent Transaction Output or UTXO.
|
|
|
An output is essentially an 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 the outputs of the sender and creates new outputs that can be spent later by the receiver.
|
|
|
A typical bitcoin output will require the signature of the owner to be spent, but outputs can require the fulfillment of more complex scripts.
|
|
|
For example, a multisignature script requires that two or more users to sign before an output can be spent, which is a fundamental building block of the Lightning Network.
|
|
|
|
|
|
P2PKH::
|
|
|
P2PKH or Pay-to-PubKey-Hash is a type of transaction that pays a Bitcoin address that contains P2PKH scripts.
|
|
|
An output locked by a P2PKH script can be unlocked (spent) by presenting a public key and a digital signature created by the corresponding private key.
|
|
|
|
|
|
P2SH::
|
|
|
P2SH or Pay-to-Script-Hash is a powerful type of transaction that greatly simplifies the use of complex transaction scripts. With P2SH the complex script that details the conditions for spending the output (redeem script) is not presented in the locking script. Instead, only a hash of it is in the locking script.
|
|
|
|
|
|
P2SH address::
|
|
|
P2SH addresses are Base58Check encodings of the 20-byte hash of a script, P2SH addresses use the version prefix "5", which results in Base58Check-encoded addresses that start with a "3". P2SH addresses hide all of the complexity, so that the person making a payment does not see the script.
|
|
|
|
|
|
P2WPKH::
|
|
|
The signature of a P2WPKH (Pay-to-Witness-Public-Key-Hash) contains the same information as a P2PKH spending, but is located in the witness field instead of the scriptSig field. The scriptPubKey is also modified.
|
|
|
|
|
|
P2WSH::
|
|
|
The difference between P2SH and P2WSH (Pay-to-Witness-Script-Hash) is the location change of the cryptographic proof from the scriptSig field to the witness field and the modification of the scriptPubKey.
|
|
|
|
|
|
payment::
|
|
|
A payment occurs if bitcoin is transferred within the Lightning Network.
|
|
|
Payments are generally not seen on the blockchain.
|
|
|
The recipient initiates a payment by creating an invoice.
|
|
|
The invoice includes a payment hash which is the hash of a secret preimage.
|
|
|
This payment hash is used by the Hashed Time Lock Contracts during the routing process.
|
|
|
|
|
|
payment channel::
|
|
|
A payment channel is a financial relationship between two nodes on the Lightning Network, created using a multisignature bitcoin transaction.
|
|
|
The channel partners can use the channel to send bitcoin back and forth between each other without committing all of the transactions to the Bitcoin blockchain.
|
|
|
In a typical payment channel only two transactions, the funding transaction and the commitment transaction, are added to the blockchain.
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
Technically "private" is a misnomer as these channels can still be identified through routing hints and commitment transactions.
|
|
|
They are better described as "unannounced" channels.
|
|
|
With an unannounced channel, the channel partners can send and receive payments between each other as normal.
|
|
|
However, the rest of the network will not be aware of it and so cannot typically use it to route payments.
|
|
|
As the number of and capacity of unannounced channels is unknown, the total public channel count and capacity only accounts for a portion of the total Lightning Network.
|
|
|
|
|
|
preimage::
|
|
|
In mathematics, given a function $f$ and a value $h$ the preimage of $h$ with respect to $f$ is the set of values $R = \{r_1,r_2,...\}$ such that $f(r_i) = h$ for all $\r_i \in R$.
|
|
|
In layman's terms, it is the set of values which is mapped to $h$ by the function $f$.
|
|
|
This preimage set can be empty, finite or infinite.
|
|
|
In cryptography, the function $f$ is usually taken to be a hash function.
|
|
|
Cryptographers use the term preimage for an arbitrary element of $R$.
|
|
|
In particular, when using SHA-256, it should be stated that each element has an infinite number of preimages.
|
|
|
However, it is still believed to be computationally hard to find such a preimage.
|
|
|
|
|
|
Proof of Work (PoW)::
|
|
|
A piece of data that requires significant computation to find.
|
|
|
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_ for more information.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Revocable Sequence Maturity Contract::
|
|
|
This contract is used to construct a payment channel between two Bitcoin or Lightning Network users who do not need to trust each other.
|
|
|
The name comes from a sequence of states which are encoded as commitment transactions and can be revoked if wrongfully published and mined by the Bitcoin network.
|
|
|
These contracts are commonly referred to as RSMCs.
|
|
|
Unlike an HTLC, whose timeout is to make an HTLC temporary, and therefore should be absolute; a RSMC timeout is meant to only start when a commitment transaction is mined, and therefore should be using a Relative Timelock.
|
|
|
|
|
|
revocation key::
|
|
|
Each Revocable Sequence Maturity Contract contains two revocation keys.
|
|
|
Each channel partner knows one revocation key.
|
|
|
Knowing both revocation keys, the output of the Revocable Sequence Maturity Contract can be spent within the predefined timelock.
|
|
|
Revocation keys are used to disincentivize channel partners from broadcasting an old channel state.
|
|
|
While negotiating a new channel state, the old revocation keys are being shared.
|
|
|
Revocation keys are used instead of signatures since they can be derived with an HD key derivation scheme.
|
|
|
This makes it less cumbersome to store all revocation keys of old states.
|
|
|
|
|
|
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.
|
|
|
The edges of the graph are the payment channels.
|
|
|
The topology of the Lightning Network is publicly broadcast with the help of the gossip protocol unless nodes decide to act privately.
|
|
|
This means that the Lightning Network may be significantly larger than the announced number of nodes.
|
|
|
Knowing the topology is of particular interest in the source-based routing process of payments in which the sender discovers a route.
|
|
|
Also, the topology is important for features such as the autopilot.
|
|
|
|
|
|
satoshi::
|
|
|
A satoshi is the smallest denomination of bitcoin that can be recorded on the blockchain. It is the equivalent of 0.00000001 bitcoin and is named after the creator of Bitcoin, Satoshi Nakamoto. ((("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.
|
|
|
|
|
|
ScriptPubKey (aka pubkey script)::
|
|
|
ScriptPubKey or pubkey script, is a script included in outputs which sets the conditions that must be fulfilled for those satoshis to be spent. Data for fulfilling the conditions can be provided in a signature script.
|
|
|
|
|
|
ScriptSig (aka signature script)::
|
|
|
ScriptSig or signature script is the data generated by a spender, which are almost always used as variables to satisfy a pubkey script.
|
|
|
|
|
|
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:
|
|
|
+
|
|
|
----
|
|
|
5J76sF8L5jTtzE96r66Sf8cka9y44wdpJjMwCxR3tzLh3ibVPxh
|
|
|
----
|
|
|
|
|
|
Segregated Witness::
|
|
|
Segregated Witness is an upgrade to the Bitcoin protocol that adds a new witness for signatures and other transaction authorization proofs. This new witness field is exempt from the calculation of a new transaction ID, which solves most classes of 3rd party transaction malleability. Segregated Witness was deployed as a soft fork and is a change that technically makes Bitcoin’s protocol rules more restrictive.
|
|
|
|
|
|
SHA::
|
|
|
The Secure Hash Algorithm or SHA is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST). The Bitcoin protocol currently uses SHA256.
|
|
|
|
|
|
short channel id (scid)::
|
|
|
Once a channel is established, the index of the funding transaction on the blockchain is used as the short channel id to uniquely identify the channel.
|
|
|
The short channel id consists of 8 bytes referring to 3 numbers.
|
|
|
In its serialized form it depicts these 3 numbers as decimal values separated by the letter **x**.
|
|
|
The first number (4 bytes) is the block height.
|
|
|
The second number (2 bytes) is the index of the funding transaction with the blocks.
|
|
|
The last number (2 bytes) is the transaction output.
|
|
|
|
|
|
simplified payment verification (SPV)::
|
|
|
SPV or simplified payment verification is a method for verifying particular transactions were included in a block without downloading the entire block. The method is used by some lightweight Bitcoin clients.
|
|
|
|
|
|
source-based routing::
|
|
|
On the Lightning Network, the sender of a payment decides the route of the payment.
|
|
|
While this decreases the success rate of the routing process, it increases the privacy of payments.
|
|
|
Due to the SPHINX Mix Format used by onion routing, all routing nodes do not know the originator of a payment or the final recipient.
|
|
|
Source-based routing is fundamentally different to how routing works on the Internet Protocol.
|
|
|
|
|
|
soft fork::
|
|
|
Soft fork, or Soft-Forking Change, is a protocol upgrade that's forwards+backwards compatible so it allows old nodes and new nodes to both continue using the same chain.
|
|
|
|
|
|
SPHINX Mix Format::
|
|
|
A particular technique for Onion Routing used in the Lightning Network and invented by George Danezis and Ian Goldberg in 2009.
|
|
|
With the SPHINX Mix Format, each message of the onion package is padded with some random data so that no single hop can estimate how far along the route it has traveled.
|
|
|
While the privacy of the sender and receiver of the payment is protected, each node is still able to return an error message along the path to the originator of the message.
|
|
|
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. 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.
|
|
|
|
|
|
transaction::
|
|
|
Transactions are a binary format used by the Bitcoin protocol to transfer bitcoin from one address to another.
|
|
|
Several transactions are built into a block which has to be confirmed by the Bitcoin network through the process of mining.
|
|
|
Transactions can only be included in a block if they contain a valid signature (more precisely a valid input script) matching the output script defined by the previous owner.
|
|
|
The first transaction in each block is called the coinbase and generates new bitcoin.
|
|
|
Transactions can also contain contracts and should not be confused with payments.
|
|
|
|
|
|
transaction malleability::
|
|
|
Transaction malleability is a property that the hash of a transaction can change without changing the semantic of the transaction (the UTXOs it is spending, the destinations and the corresponding amounts).
|
|
|
For example, altering the signature can change the hash of a transaction, because of the non-deterministism of ECDSA signing.
|
|
|
A commitment transaction needs the hash of a funding transaction and if the hash of the funding transaction changes, transactions depending on it will become invalid. This will make users unable to claim the refunds if there are any.
|
|
|
The Segregated Witness soft fork addresses this issue and is therefore an important upgrade to support Lightning Network.
|
|
|
|
|
|
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).
|
|
|
|
|
|
unspent transaction output (UTXO)::
|
|
|
See _output_
|
|
|
|
|
|
wallet::
|
|
|
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.
|
|
|
In the case that one of the channel partners goes offline or loses their backup, a watchtower keeps their own backups and can restore their channel information.
|
|
|
They also monitor the Bitcoin blockchain and can submit a penalty transaction in the case that one of the partners tries to "cheat" by broadcasting an outdated state.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|