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

Merge pull request #110 from bolatovumar/fix-106

Browse Source 
Replace "Bitcoin" with "bitcoin" when referring to currency unit
This commit is contained in:
Andreas M. Antonopoulos 2020-01-24 13:40:23 -05:00 committed by GitHub
commit eec384b31e
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
5 changed files with 17 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
ch01.asciidoc
View File

@ -30,7 +30,7 @@ This would make running a node completely untenable for anyone but large scale e
The result would be a network in which only a few users can actually validate the state of the ledger, which ultimately breaks the trust model of Bitcoin. The result would be a network in which only a few users can actually validate the state of the ledger, which ultimately breaks the trust model of Bitcoin.
The Lightning Network proposes a new network, a "second layer", where users can transact with each other peer-to-peer, without publishing every transaction to the Bitcoin blockchain. The Lightning Network proposes a new network, a "second layer", where users can transact with each other peer-to-peer, without publishing every transaction to the Bitcoin blockchain.
Users may transact on the Lightning Network as many times with as many users as they want, making use of the Bitcoin blockchain only in order to load Bitcoin onto the network initially and to "settle", that is: remove Bitcoin from the Lightning Network. Users may transact on the Lightning Network as many times with as many users as they want, making use of the Bitcoin blockchain only in order to load bitcoin onto the network initially and to "settle", that is: remove bitcoin from the Lightning Network.
The result is that many more Bitcoin transactions can take place "off-chain", with only the initial loading and final settlement transactions needing to be validated and stored by Bitcoin nodes. The result is that many more Bitcoin transactions can take place "off-chain", with only the initial loading and final settlement transactions needing to be validated and stored by Bitcoin nodes.
Aside from reducing the burden on nodes, these transactions will be cheaper for users as they do not need to pay blockchain fees, and more private for users as they are not published to all participants of the network. Aside from reducing the burden on nodes, these transactions will be cheaper for users as they do not need to pay blockchain fees, and more private for users as they are not published to all participants of the network.
@ -38,20 +38,20 @@ While the Lightning Network was initially conceived for Bitcoin, it is able to b
=== Lightning Network Basic Concepts === Lightning Network Basic Concepts
* 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. * 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. * 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. * 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. ** 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. ** 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. * 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 * 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" * 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. * 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 ** 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. * 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. ** 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. ** 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. ** 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.

6
ch02.asciidoc
View File

@ -17,12 +17,12 @@
** discuss that a general phising scheme might consist of tricking you to download a similar looking software ** discuss that a general phising scheme might consist of tricking you to download a similar looking software
[[getting_first_bitcoin]] [[getting_first_bitcoin]]
==== Getting Your First Bitcoin on the Lightning Network ==== Getting Your First bitcoin on the Lightning Network
* Trade fiat for Bitcoin (as in Mastering Bitcoin) * Trade fiat for bitcoin (as in Mastering Bitcoin)
[[using_own_bitcoin]] [[using_own_bitcoin]]
==== Process for people who already own Bitcoin ==== ==== Process for people who already own bitcoin ====
* send bitcoin to lightning wallet (1 onchain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoin to the lightning network wallet first) * send bitcoin to lightning wallet (1 onchain transaction - soon nodes / wallets may support funding a channel directly without sending bitcoin to the lightning network wallet first)
* find a node to open a channel with (Node explorer / Autopilots / ...) * find a node to open a channel with (Node explorer / Autopilots / ...)

2
ch03.asciidoc
View File

@ -121,7 +121,7 @@ You already learnt that one of the most important building blocks of a payment c
To open a payment channel one must send bitcoin to that address. To open a payment channel one must send bitcoin to that address.
The Bitcoin transaction - which will be included to the Bitcoin Blockchain - that sends the bitcoin to that 2-2 multisignature address is called the funding transaction. The Bitcoin transaction - which will be included to the Bitcoin Blockchain - that sends the bitcoin to that 2-2 multisignature address is called the funding transaction.
While there is the possibility for 2 participants of the Lightning Network to open a private payment channel, this transaction will always be publicly visible to the Bitcoin network. While there is the possibility for 2 participants of the Lightning Network to open a private payment channel, this transaction will always be publicly visible to the Bitcoin network.
The amount of Bitcoin sent to the multisignature address is called the capacity of the channel. The amount of bitcoin sent to the multisignature address is called the capacity of the channel.
Two channel partners will never be able to conduct larger payments on that channel than the channel capacity. Two channel partners will never be able to conduct larger payments on that channel than the channel capacity.
What cannot publicly be seen from the funding transaction is how the funds in that open channel are being distributed between the two channel partners. What cannot publicly be seen from the funding transaction is how the funds in that open channel are being distributed between the two channel partners.

6
contrib/history.asciidoc
View File

@ -56,8 +56,8 @@ A fundamental blocker to deploying payment channels in production was the issue
In the worst case, this could be exploited by an attacker to prevent a party from closing the channel on-chain as their settlement transaction had a chance to become invalidated if the funding transaction has it's transaction ID inadvertently changed. In the worst case, this could be exploited by an attacker to prevent a party from closing the channel on-chain as their settlement transaction had a chance to become invalidated if the funding transaction has it's transaction ID inadvertently changed.
Also as a payment channel this system was not too useful as the channel could only at total send the total amount of provided Bitcoin in the funding transaction. Also as a payment channel this system was not too useful as the channel could only at total send the total amount of provided bitcoin in the funding transaction.
Once the timelock was over or all Bitcoin were sent to B the channel would have to be closed. Once the timelock was over or all bitcoin were sent to B the channel would have to be closed.
The obvious idea of opening two channels one from A to B and one from B to A would not have helped as each of those channels would have to be closed and reestablished once it ran dry. The obvious idea of opening two channels one from A to B and one from B to A would not have helped as each of those channels would have to be closed and reestablished once it ran dry.
The core breakthrough for the LN to become a reality was the ability to create payment channels which technically can live forever and can send money back and forth as often as the peers wish to in combination with routing payments among several channels. The core breakthrough for the LN to become a reality was the ability to create payment channels which technically can live forever and can send money back and forth as often as the peers wish to in combination with routing payments among several channels.
@ -82,7 +82,7 @@ Andresen's work led to many discussions on Bitcointalk forum, and later on the b
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.
The key difference was that a trusted party would have co-signed the spend of the funding transaction. The key difference was that a trusted party would have co-signed the spend of the funding transaction.
The Ultra Server was not able to steal Bitcoin. The Ultra Server was not able to steal bitcoin.
The next day, probably in response to Gavin's blogpost, Meni Rosenfeld started a discussion related to how these ideas could be combined.footnote:[Meni Rosenfeld on Bitcointalk - July 5th 2012 - Trustless, instant, off-the-chain Bitcoin payments http://web.archive.org/web/20190419103457/https://bitcointalk.org/index.php?topic=91732.0] The next day, probably in response to Gavin's blogpost, Meni Rosenfeld started a discussion related to how these ideas could be combined.footnote:[Meni Rosenfeld on Bitcointalk - July 5th 2012 - Trustless, instant, off-the-chain Bitcoin payments http://web.archive.org/web/20190419103457/https://bitcointalk.org/index.php?topic=91732.0]
As Hashed Timelocked Contracts have neither been invented nor seen to solve the issue of trustless routing, Rosenfeld imagined trusted routing nodes. As Hashed Timelocked Contracts have neither been invented nor seen to solve the issue of trustless routing, Rosenfeld imagined trusted routing nodes.

1
preface.asciidoc
View File

@ -186,6 +186,7 @@ Following is an alphabetically sorted list of all the GitHub contributors, inclu
* Ricardo Marques (@RicardoM17) * Ricardo Marques (@RicardoM17)
* Simone Bovi (@SimoneBovi) * Simone Bovi (@SimoneBovi)
* Omega X. Last (@omega_github_id) * Omega X. Last (@omega_github_id)
* Umar Bolatov (@bolatovumar)
Without the help offered by everyone listed above, this book would not have been possible. Your contributions demonstrate the power of open source and open culture, and we are eternally grateful for your help. Without the help offered by everyone listed above, this book would not have been possible. Your contributions demonstrate the power of open source and open culture, and we are eternally grateful for your help.