2
0
mirror of https://github.com/lnbook/lnbook synced 2024-11-04 18:00:26 +00:00

added stubs for further chapters and a note for chapter 3. this is WIP and has happened long ago but I wanted to push it for discussions. Not fixed yet

This commit is contained in:
Rene Pickhardt 2020-01-06 22:34:13 +01:00
parent 03d5ffb77b
commit e5eea53baa
4 changed files with 74 additions and 0 deletions

View File

@ -189,6 +189,12 @@ The penalty for broadcasting an old commitment transaction is to give the other
This means that Bob would have the ability to claim 10 mBTC from the output that belonged to Alice in her original Commitment transaction if she publishes it after she has agreed to a second commitment transaction in which she would only own 7 mBTC and Bob would own 3 mBTC.
With such a strong penalty mechanism in Place Alice should never purposely publish an old state as she would almost always loose her remaining funds in the channel.
[Note]
====
In Mastering Bitcoin Andreas states it very elegantly:
A key characteristic of bitcoin is that once a transaction is valid, it remains valid and does not expire. The only way to cancel a transaction is by souble-spending its inputs with another transaction before it was mined. That's why we used timelocks [...] to ensure that more recent commitments could be spent before older commitments were valid.
====
We will now see how such a pentality mechanism can be included to the above construction of the commitment transactions.
Usually the commitment transaction has at least two outputs.
One for each partner.

21
ch04.asciidoc Normal file
View File

@ -0,0 +1,21 @@
[role="pagenumrestart"]
[[ch04_The_communications_protocol]]
== The communication protocol
After you discovered the overview of how the lightning network protocol worked in the last chapter we now want to present a few more details about the actual communication that takes place between the nodes to fulfill the most important tasks like opening a channel, forwarding a payment and closing the channel.
All communication takes place over a secure, encrypted and authenticated connection.
[NOTE]
====
While the specification of how to set up such a connection is part of the lightnig network protocol and can be read upon in BOLT08 we will omit this in the book.
The reason is that BOLT08 mainly follows the handshake patterns from the noise protocol framework which is a standard template system for secure cryptographic handshakes.
This protocol framework is also used by Whatsapp and Wireguard and is very well documented.
If you want to learn more we suggest you check out http://www.noiseprotocol.org/
====
=== Ligtning Messages
=== Opening a Payment channel
=== forwarding, making and receiving a payment
=== closing the channel

15
ch05.asciidoc Normal file
View File

@ -0,0 +1,15 @@
[role="pagenumrestart"]
[[ch05_set_up_a_lightning_node]]
== Set up your Lightning Network Node
The Lightning Network is specified in the lightning-rfc by the open source community.
The lightning-rfc is also called Basics of Lightning Technology (BOLT) which is a collection of documents (BOLTs) that specify the components needed for the protocol.
There are several teams who implement the BOLTs as software which you can run on your computer or a server.
All those teams also contribute to the BOLTs.
In this chapter you will learn how to set up each of the software packages for each of the Lightning Network implementations.
We presented them in alphabetical order to emphasize that we generally do not prefer or recommend one over the other.
It will depend on your preferences which of the software packages you might want to work with.
=== c-lightning
=== eclair
=== lightning network daemon (lnd)
=== Comparing the implementations

32
ch06.asciidoc Normal file
View File

@ -0,0 +1,32 @@
[role="pagenumrestart"]
[[ch06_Maintaining_a_lightning_node]]
== Running and Maintaining a Lightning Network Node
=== Implications of Configurations
=== Backups
==== Static channel backups
=== Security of your machine
==== Hot wallet risk
==== Watchtowers
=== Channel management
In order to participate on the Lightning Network you need to have payment channels on your Lighting networknode.
It might be confusing to decide with whom to open channels and which parameters to set for the specific channel policies.
An obvious strategy might be to open channels with shops where you want to buy products.
But what happens if those shops do only accept large channels which are beyond your funds or do not accept public channels at all?
Also if you are not a consumer but a vendor you want to receive payments on the Lightning Network.
Therefor you need others to open channels with you or you need to open channels and use submarine swaps and rebalancing techniques to provide yourself with the ability to receive payments.
Both techniques will be discussed later in this chapter.
==== Autopilots
==== Rebalancing
==== submarine swaps
==== Fees and Centrality