- git grep -iE '(^| )(\w+) \2(\.|,|:|;| |$)' -- "*.asciidoc" "*.md" && echo "^ Detected lexical illusion in the form of a duplicated word. Please correct." && exit 1 || true
- for FILE in $(git ls-files -- "*.asciidoc" "*.md"); do if [[ $(tail -c1 $FILE) != "" ]]; then echo "File ${FILE} does not end with a newline character (\n)."; exit 1; fi; done
- git grep "" -- "*.asciidoc" "*.md" | uniq -c | grep -1 "^ [2-9] " | cut -b9- | sed 's/:$/:[more-than-one-blank-line-here-please-remove]/' | grep ":" && echo "^ Multiple blank lines detected. Please use only one blank line between paragraphs." && exit 1 || true
- git grep -E "^[= ]*[a-z]" -- "*.asciidoc" "*.md" | grep -vE '(:(link|pass):|::$)' | grep -vE ':[= ]*(http|https)' | grep -E "[a-z]" && echo "^ The first letter of the sentence should be capitalized. The end of the sentence should be on the same line as the beginning of the sentence. Please correct." && exit 1 || true
@ -30,29 +30,24 @@ The `nSequence` field was intended to allow users to transmit updated versions o
Such a payment channel would then be valid as long as the transaction was not mined.
According to a Mailinglist post in 2013 by early Bitcoin developer Mike Hearn, Satoshi Nakamoto envisioned this construction for the use case of high frequency trading.footnote:HearnBitcoinDev[Mike Hearn on Bitcoin-dev - April 16th 2013 - Anti DoS for tx replacement http://web.archive.org/web/20190501234757/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html.]
There were however some weaknesses in this initial formulation, which limited its potential. Firstly, the payment channel would only be open until the transaction was mined by the miners, either limiting the duration the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number, making this mechanism effectively useless.
However, there were some weaknesses in this initial formulation that limited its potential. Firstly, the payment channel would only be open until the transaction was mined in a block, either limiting the duration the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number, rendering this mechanism effectively useless.
The Revocable Sequence Maturity Contracts (RSMC) which form the payment channels in the first version of the LN have taken part of their name from their property of fixing the `nSequence` field.
This is achieved by creating an economic incentive via a penalty mechanism if not the most recent transaction in the payment channel is published to the Bitcoin network.
Effectively the most recent update of the payment channel (encoded as a bitcoin transaction) becomes enforceable in this way.
The Revocable Sequence Maturity Contracts (RSMC), which formed payment channels in the first version of the Lightning Network, reference in their name the fact that they fixed this weakness of the `nSequence` field.
This is achieved by creating an economic incentive via a penalty mechanism; otherwise, the most recent transaction or update in the payment channel is published to the Bitcoin network, and becomes enforcable in this way.
// find / add sources for some of the claims
In July of 2011, on the bitcointalk.org forum, a pseudonomous user by the name of _hashcoin_ proposed the usage of Timelocks via the `nLockTime` function of the bitcoin network to solve the custody problem of exchanges.footnote:[Hashcoin on Bitcoin talk on July 4th 2011 - Instant TX for established business relationships (need replacements/nLockTime) http://web.archive.org/web/20190419103503/https://bitcointalk.org/index.php?topic=25786.0]
The idea was to be able to quickly trade / sell Bitcoin without the necessity to send all the bitcoins to the exchange in the first place.
Hashcoin effectively proposed what we would call an unidirectional payment channel today.
With this mechanism a user Alice could fund a multisig address between her and another user Bob together with a timelocked transaction sending all bitcoins back to Alice.
Hashcoin imagined Bob to be an exchange.
The transaction that is used to fund the multisignature address between Bobs and Alice kee is naturally called funding transaction.
This transaction would not be signed and broadcasted by Alice before Bob provided a signature for the spend.
The setup allows Alice to send bitcoin to Bob.
Whenever she wanted to do so she could create a newer spend of the funding transaction which would send less Bitcoin back to Alice and more bitcoin to Bob.
This transaction could not be mined without a signature from Bob.
Alice would send the partially signed transaction to Bob how would sign it and keep it private.
Note that keeping it private and not sharing the fully signed transaction back to Alice is crucial.
Since Alice never has both signatures for a spend of the multisignature wallet besides the timelocked refund transaction she can't send an outdated spend of the funding transaction to the bitcoin network.
Bob on the other hand could do so but he would have no interest in publishing an old state since a newer state would always provide him with more bitcoin than any older state.
Alice is not able to have the refund transaction mined into a block before the timelock expires.
This gives Bob the security to receive more updates as long as the channel would be `open`.
In July of 2011, on the bitcointalk.org forum, a pseudonymous user by the name of _hashcoin_ suggested using Timelocks via the `nLockTime` function of the Bitcoin network to solve the custody problem of exchanges.footnote:[Hashcoin on Bitcoin talk on July 4th 2011 - Instant TX for established business relationships (need replacements/nLockTime) http://web.archive.org/web/20190419103503/https://bitcointalk.org/index.php?topic=25786.0]
The goal was to build a conduit for quick trades, without the necessity to send bitcoins to an exchange in the first place.
What Hashcoin proposed would eventually be termed a unidirectional payment channel.
With this mechanism, user "Alice" could fund a multi-signature address between herself and another user, "Bob", together with a timelocked transaction that 'refunded' the bitcoin back to Alice.
In their scenario, Hashcoin imagined Bob to represent an exchange.
The transaction used to fund the multi-signature address, which is controlled by Bob's and Alice's keys, is naturally called the funding transaction.
Alice would send the partially signed transaction to Bob, who would sign it and keep it private.
Note that keeping it private is crucial. If Bob does not share the fully signed transaction with Alice, she does not have both signatures needed to spend funds from the multi-signature address. Except for the timelocked refund transaction, she can't send an outdated spend of the funding transaction to the Bitcoin network.
Bob, on the other hand, could do so, but he would have no interest in publishing an old channel state. The newer state would provide him with more bitcoin than the older state.
Alice cannot effectively broadcast the refund transaction to be mined in a block before the timelock expires.
Therefore, Bob can securely receive more updates to the channel balance as long as it remains `open`.
This mechanism would allow two users to engage into several smaller transactions which all happened outside of the Bitcoin network.
While this construction of the unidirectional payment channel would have solved the custody problem of exchanges it has never been widely implemented.
@ -81,7 +76,7 @@ Andresen noted that there might be a better construction which would require les
Andresen's work led to many discussions on Bitcointalk forum, and later on the bitcoin-development mailing list. These discussions resulted in the first construction of the first unidirectional payment channels.
to sum this up: Andresen used a similar construction as the unidirectional channel.
To sum this up: Andresen used a similar construction as the unidirectional channel.
They key difference was that a trusted party would have co-signed the spend of the funding transaction.
an alternative structure for the subsections of the invoice section (while covering the same topics) could be: (creating, decoding, paying as 3 sub chapters)
An alternative structure for the subsections of the invoice section (while covering the same topics) could be: (creating, decoding, paying as 3 sub chapters)
Nodes should aim to have balanced channels with similar inbound and outbound capicities.
bech32::
tbd.
TBD.
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.
@ -136,7 +136,7 @@ double-spending::
The Revocable Sequence Maturity Contracts used to construct payment channels heavily attempt to double-spend bitcoin.
downstream payment::
tbd.
TBD.
ECDSA::
Elliptic Curve Digital Signature Algorithm or ECDSA is a cryptographic algorithm used by Bitcoin to ensure that funds can only be spent by their rightful owners.
@ -145,7 +145,7 @@ Eclair::
Implementation of the Lightning Network Protocol by the Paris based company ACINQ. It is written in Scala.
encoding::
tbd.
TBD.
Ephemeral Key::
Ephemeral keys are mainly within the SPHINX Mix Format and Onion Routing on the Lightning Network.
@ -215,7 +215,7 @@ Lightning Network::
Other components of the lightning network are the gossip protocol, the transport layer and payment requests.
Lightning Network Node::
tbd.
TBD.
lnd::
Implementation of the Lightning Network Protocol by the San Francisco based company Lightning Labs.
@ -311,7 +311,7 @@ Proof-of-Work::
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, the difficulty target.
Relative Timelock::
tbd.
TBD.
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.
ScriptSig or signature script, is the data generated by a spender which is almost always used as variables to satisfy a pubkey script.
Second stage HTLC::
tbd.
TBD.
secret key (aka private key)::
The secret number that unlocks bitcoin sent to the corresponding address. pass:[<span class="keep-together">A secret</span>] key looks like the following:
@ -408,16 +408,16 @@ Transaction::
Transactions can also contain contracts and should not be confused with payments.
Transaction Malleability::
tbd.
TBD.
Transport Layer::
tbd.
TBD.
unspent transaction output (UTXO)::
UTXO is an unspent transaction output that can be spent as an input to a new transaction.
upstream payment::
tbd.
TBD.
wallet::
Software that holds all your bitcoin addresses and secret keys. Use it to send, receive, and store your bitcoin.
Andreas M. Antonopoulos
5 years ago
committed by
GitHub