* minor cleanup, consistent naming, etc
- typo
- consistent naming:
- uppercased all "lightning" to "Lightning"
- all Lightning networks, to "Lightning Network"
- remove "oldid" URL REST parameter from wikipedia links
- added links where appropriate
- etc
* put the oldid argument in the 4 or 5 URLs back in
@ -26,7 +26,7 @@ Some additional definitions, to be cleaned up and moved into alphabetic order ar
** 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.
* 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.
////
@ -52,16 +52,16 @@ Balance::
If the channel balance is completely on one side of the channel, i.e. one channel partner has all of the bitcoin in the channel, this particular partner cannot receive any payments through this channel. This partner can, however, send payments and forward HTLCs.
The balance that a node has on its own side of the channel (and is thus able to spend) is called the outbound capacity.
The node's channel partner would refer to that balance as its inbound capacity, i.e. the amount that it is able to receive.
Nodes should aim to have balanced channels with similar inbound and outbound capicities.
Nodes should aim to have balanced channels with similar inbound and outbound capacities.
bech32::
A checksummed base32 address format. It is native to segregated (BIP173). Also referred to as "bc1" because of the starting values of each address. Transactions made using bech32 are smaller in most cases, and therefore, may only require a lower fee.
A checksummed base32 address format, at most 90 characters long, and capable of error correction. It is native to segregated witness (BIP173). Also referred to as "bc1" because of the current starting values of each address. Transactions made using bech32 are smaller in most cases, and therefore, may only require a lower fee.
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.
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::
Depending on context, could refer to the name of the currency unit (the coin), the network or the underlying enabling protocol. Written as bitcoin with a "b" in lowercase usually refers to the currency unit.
bitcoin, Bitcoin::
Depending on 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 serves two purposes.
@ -79,7 +79,7 @@ Blockchain::
New blocks have a statistical probability of being produced every ten minutes.
BOLT::
BOLT, or Basics Of Lightning Technology, is the formal specification of the Lightning Network Protocol. It serves only as such without delving into implementation, unlike Bitcoin, in which both are one and the same. It is available in its entirety on the lightning network's github page, in the lightning-rfc repository.
BOLT, or Basics Of Lightning Technology, is the formal specification of the Lightning Network Protocol. It serves only as such without delving into implementation, unlike Bitcoin, in which both are one and the same. It is available in 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.
@ -95,7 +95,7 @@ Capacity::
It is not to be confused with the balance.
c-lightning::
Implementation of the Lightning Network Protocol by the Victoria based company Blockstream. It is written in C.
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.
@ -142,7 +142,7 @@ Contract::
Diffie Hellman 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.
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 secrete between the ephemeral session key of a sender of an onion with the nodes public key of a hop of the onion as described and used by the SPHINX Mix Format.
@ -166,7 +166,7 @@ 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 ACINQ. It is written in Scala.
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.
@ -183,8 +183,8 @@ Ephemeral Key::
fees::
The sender of a transaction often includes a fee to the network for processing the requested transaction.
Not to be confused with a routing fee for payments on the lightning network.
Nodes on the Lightning network are allowed to take a routing fee for forwarding payments.
Not to be confused with a routing fee for payments on the Lightning Network.
Nodes on the Lightning Network are allowed to take a routing fee for forwarding payments.
The routing fee is the sum of a fixed _base_fee_ and a _fee_rate_ which depends on the payment amount.
Funding Transaction::
@ -208,9 +208,9 @@ Gossip Protocol::
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.
Currently, hardware wallets are not available for lightning network nodes as user nodes need to be online to follow through the protocol.
Several groups are working on solutions.
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.
Several groups are currently working on solutions.
hash::
A digital fingerprint of some binary input.
@ -241,19 +241,20 @@ Invoice::
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.
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 figure out 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 figure out what messages are being sent by inspecting the length.
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.
Other components of the Lightning Network are the gossip protocol, the transport layer, and payment requests.
The source code is availble at https://github.com/lightningnetwork.
Lightning Network Node::
Lightning Network Node, Lightning Node, node::
TBD.
lnd::
Implementation of the Lightning Network Protocol by the San Francisco based company Lightning Labs.
It is written in Go.
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.
@ -263,8 +264,7 @@ 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.
Millisatoshi::
The smallest unit of account on the lightning network.
The value cannot be enforced on chain.
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.
multisignature::
Multisignature (multisig) refers to requiring more than one key to authorize a Bitcoin transaction.
@ -274,8 +274,11 @@ multisignature::
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
Noise_XK::
The template of the Noise protocol framework to establish an authenticated and encrypted communication channel between two peers of the lightning network.
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.
@ -453,7 +456,7 @@ Transaction Malleability::
Transaction Malleability is a property that 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, 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 is.
Segregated Witness soft fork addresses this issue and therefore is an important upgrade to support Lightning network.
Segregated Witness soft fork addresses this issue and therefore is an important upgrade to support Lightning Network.
Transport Layer::
In computer networking, the transport layer is a conceptual division of methods of a model of how computers talk to each other.
8go
4 years ago
committed by
GitHub