Archives/lnbook
2
0
Fork 0
mirror of https://github.com/lnbook/lnbook synced 2024-11-06 21:20:29 +00:00
Code Issues Projects Releases Wiki Activity

Merge pull request #496 from tigeryant/develop

Browse Source 
Minor changes to punctuation and grammar
This commit is contained in:
Andreas M. Antonopoulos 2020-09-21 16:13:12 -04:00 committed by GitHub
commit 9dae4f6544
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
2 changed files with 3 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
01_introduction.asciidoc
View File

@ -23,7 +23,7 @@ Many users will increase the fees they're willing to pay in order to buy space f
At the same time, an increasing number of users are left behind.
Their transactions, e.g. microtransactions such as common small spendings, are not economically qualified to be on the network.
We could increase the block size to create space for these smaller transactions.
However increasing block size simply shifts the problem to node operators, and requires them to expend resources to faciliate these additional transactions.
However, increasing block size simply shifts the problem to node operators, and requires them to expend resources to faciliate these additional transactions.
Because blockchains are gossip protocols, each node is required to know and validate every single transaction that occurs on the network. Furthermore, once validated, each transaction and block must be propagated to the node's "neighbors", multiplying the bandwidth requirements. As such, the greater the block size, the greater the bandwidth, processing, and storage requirements for each individual node, effectively limiting the amount of scaling that can be done this way. Furthermore, scaling in this fashion has an undesirable side effect of centralizing the network by reducing the number of nodes and node operators. Since node operators are not compensated for running nodes, if nodes are very expensive to run, only a few well funded node operators will continue to run nodes.
@ -43,7 +43,7 @@ But what if each node wasn't required to know and validate every single transact
In February 2015, Joseph Poon and Thaddeus Dryja proposed a possible solution to the Bitcoin Scalability Problem, with the publication of _"The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments"_
footnote:[Joseph Poon, Thaddeus Dryja - "The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments" (https://lightning.network/lightning-network-paper.pdf).]
In the meanwhile outdated whitepaper, Poon and Dryja estimate that in order for Bitcoin to reach the 47,000 transactions per second processed at peak by Visa, it would require 8 GB blocks.
In the now outdated whitepaper, Poon and Dryja estimate that in order for Bitcoin to reach the 47,000 transactions per second processed at peak by Visa, it would require 8 GB blocks.
This would make running a node completely untenable for anyone but large scale enterprises and industrial grade operations.
The result would be a network in which only a few users can actually validate the state of the ledger.
Bitcoin relies on users validating the ledger for themselves, without explicitly trusting third parties, in order to stay decentralized.

1
preface.asciidoc
View File

@ -186,6 +186,7 @@ Following is an alphabetically sorted list of all the GitHub contributors, inclu
* Haoyu Lin (@HAOYUatHZ)
* Hatim Boufnichel (@boufni95)
* Imran Lorgat (@ImranLorgat)
* John Davies (@tigeryant)
* Julien Wendling (@trigger67)
* Kory Newton (@korynewton)
* Luigi (@gin)