Hi

I know this book is intended to focus on the Lightning Network protocol and the software that's built around it (e.g. lnd, c-lightning, eclair etc.). However, there's a greater need for hardware knowledge in Lightning than in Bitcoin because:

• Nodes need to be online at all times to receive payment and enforce channel penalties (not so in Bitcoin)
• Channels do not exist on the blockchain, and are only known by the partners. So there is a need for channel backups (e.g. on cloud storage) to prevent loss of funds (only need to backup your seed in Bitcoin)
• If don't want to rely on custodial services for funding transactions and penalties, you need to run a Bitcoin node and have 200+GB of disk space (and you still need to be your own Lightning Node at least. No 'SPV Lightning' for now)

So far, most of the user discussion is centered around using Lightning as a user on a mobile. There are users who run their own Bitcoin + Lightning node on dedicated hardware like a Raspberry Pi + Hard Drive. In the future, I can see off-the-shelf Bitcoin+Lightning PoS Terminals being sold to retailers and users. For now, you pretty have much have to build it yourself. Some good open-source examples right now are:

MyNode: https://mynodebtc.com/
Raspiblitz: https://github.com/rootzoll/raspiblitz

Any ideas to incorporate this info into the book?

Which part needs editing?
01_introduction.asciidoc
section: === Motivation for the Lightning Network

What editing does this need?
Not sure if centralization should be the first / main argument when discussing why increasing blockspace / decreasing blocktime does not work.

I think it is an important argument but it comes with ideology - as bitcoin - and thus it seems to open up space for discussions. There are actually simple technical arguments that demonstrate that even from a pure technical / non ideological point of view it does not make sense. Since I would love to stop the discussion and give people better (?) / technical arguments. I am not strongly opinionated on this feedback though but thought I mention it.

How does it currently read?
However, simply increasing block size does not solve the problem because it has the undesirable effect of centralizing the network. Because blockchains are gossip protocols, each node is required to know and validate every single transaction that occurs on the network

How should it read?
We could argue how much data was to process and how expensive it would become to run a bitcoin node (even without mining) how much internet traffic this would need and so on. The plain argument of a broadcast replicated system in which every participant needs to process everything is something that you already give so we could focus on that

Which part needs editing?
Chapter 1, most likely all others as well.

What editing does this need?
Simplify

How does it currently read?
very cheap, very low cost, ... very expensive

Users of the Lightning Network can route payments to each other for very low cost and in real time.
... so he uses the Lightning Network to accept bitcoin payments almost instantaneously and for very low fees.
Remittance companies and banks charge very high fees

How should it read?
Low? Very low? This is all relative. What is a "very low" fee or a "very low cost" payment? It is different for different readers. We should not create expectations that are too high. Remember when Bitcoiners spoke about "very low fees" on Bitcoin and micro-payments on bitcoin? In just a handful of years the perception has changed. The expectations should be as realistic as possible and if in doubt I would rather suggest to under-hype than to over-hype a technology. Hence, I suggest to simply replace the "very low" and "very cheap" etc phrasing with simply "low", i.e. remove the word "very".

Users of the Lightning Network can route payments to each other for low cost and in real time.
... so he uses the Lightning Network to accept bitcoin payments almost instantaneously and for low fees.
Remittance companies and banks charge high fees ...

If people agree with reducing the suggested reduction in expectations, I'd be happy to put all the changes into a single PR. Just let me know.

When planning chapter 3 it was still chapter 2 (c.f. #67 ) but we decided that it seemed too technical for chapter 2. Now we moved it to chapter 3 to give a nice / rather technical overview of lightning. I started writing about multisig, P2SH and P2WSH (c.f. https://github.com/lnbook/lnbook/blob/4ed6de50ba61b91078387f1117235422ef5a40fa/ch03.asciidoc) but after a day I think this would already go to deep. I am currently thinking of still giving an overview of all the components / concepts of lightning but allow to blackbox. Just say it is a multisig address and refer to later chapters that would explain in detail to the last Byte what is happening.

I think we will first have to transport an understanding of the important concepts and don't dive deep right away.

We have discussed and agreed upon that our initial roadmap should look like the following:

1. define terms for the book (happening in the glossary.asciidoc)
2. define topics for the book
3. define user stories (happening in ch01.asciidoc )
4. come up with a preliminary working draft for a structure / outline of the book.

I have just transferred the glossary from my solo attempt to write the lightning network book. I also merged it with the one from mastering bitcoin. there are many open stylistic questions which should be collected. also there are terms missing.

Additionally we need to define user stories (similar to the ones in mastering bitcoin) Maybe we could even extend some of the user stories from mastering bitcoin.

in any case input from the community for step 1 to 3 at this stage is very wellcome!

for example I imagine that Alice has a channel to Bobs coffee shop who has a chennel to a softare merchant who has a channel to the gamer Gloria. Those seem to be reasonable relations. We migh need others throughout the book and work with them.

in getting started we write:

While this trade-off simplifies the user interface and user experience, it introduces a Single Point of Failure (SPoF) and a potential privacy compromise, as these "hub nodes" become indispensable and can see all the user's transactions.

they can see all payments of a user but not to whom those payments go. unless of course the destination is also using such a hub...

The situation might be a little different in the Phoenix case where route computation is also deligated to the ACINQ server. While they promise that with trampoline this can be outsourced to any set of trampoline nodes this is still tricky

Why do chapter 1 and 2 filenames start with 01_... and 02_... while chapter 3 starts with ch03? If there is no specific reason, please name the files consistently.

Which part needs editing?
Filenames

What editing does this need?
Rename chapter files to make them consistent

How does it currently read?
01_..., 02_..., ch03

How should it read?
Have all the chapter files named consistently, e.g. ch01_..., ch02_..., ch03_... etc.

Many headlines contain acronyms. I suggest to replace these acronyms in the headlines wherever possible. I am not talking about the paragraphs, I am just talking about the headlines.

A book where nearly every single headline has an acronym in it does not seem very user friendly or very readable to me. If someone (e.g. before reading the book) scans the Table of Content, he will be overwhelmed or confused as he finds so many (still unknown) acronyms. Put the acronyms in the text but not in the headers and use acronyms sparingly.

For example, in chapter 2 there are many headlines that contain "LN Wallet", "LN Channel" and similar. I suggest to replace these acronyms in the headlines with "Lightning Wallet", "Lightning Channel".

Which part needs editing?
Many headlines

What editing does this need?
Replace acronym with full text, e.g. replace LN with "Lightning"

How does it currently read?
e.g. LN Wallets

How should it read?
Lightning Wallets

If people like this idea, I can do the changes and submit the corresponding PR. Just let me know.

In chapter two / getting started we currently write: The most common components of lightning wallet software include: A keystore that securely holds secrets, such as private keys.

I am not sure how secure the keystore currently is on LN nodes.

I believe in early days there was no way to encrypt wallet.dat and wallet.dat has been stolen leaked. in a same way for example in c-lightning we have hsm_secret that stores the private master key in plain binary format and the entire state is stored in plain text in a sql database. For state information it will be even more tricky to encrypt this as the state will / should change without user interaction. while hsm_secret could be encrypted the decrypted version would have to be in main memory and could be found with a full memory dump. there are not too many variables to check in a full mem copy.

I am not sure how comfortable I feel suggesting that lighting implementations have a secure keystore.

I added a video by using the asciidoc TIP style. I thought it would be neat if we had a MEDIA style for such videos. will that be possible?

I would guess American English but just wanted to double check before making any grammatical or spelling edits. Either way, it might be worth stating it in CONTRIBUTING.md?

from getting started:

Lightning wallets can be installed on a variety of devices, including laptops, servers, and mobile devices. To run an LN node and a Bitcoin node, you will need to use a server or desktop computer, as mobile devices and laptops are usually not powerful enough in terms of capacity, processing, battery life, and connectivity.

before we also have the non-custodial wallet but not full node. I would argue that the question that is intersting for us is the question of running a bitcoin node / participating in gossip. with those things removed a lightning node can easily run on a low battery device as there is hardly any computation involved.

Maybe we should refine the introduced terminology?

Both "Gossip protocol" and "gossip protocol" are used throughout the book. I propose using "gossip protocol" everywhere.

Both "bitcoin" and "bitcoins" are used in plural form throughout the book. We should decide on a plural form to use going forward. Andreas uses "bitcoin" in the plural in Mastering Bitcoin while Jimmy Song uses "bitcoins" in Programming Bitcoin. Either form is OK as long as it's used consistently.

The PR #29 added automatic spell checking of new pull requests using codespell. For that to work the Travis-GitHub integration must be enabled.

The README.md has a dead image hyperlink. It expects an image to be in the repository that isn't there.

The Lightning Network is not itself a blockchain, nor does it produce a blockchain, it is a network that relies on existing blockchains for its security.

This is a bit confusing/misleading, it implies Lightning is a single network that relies on multiple existing blockchains for its security. I understand what is meant, but it doesn't quite convey that. Perhaps rephrase to:

The Lightning Network is not itself a blockchain, nor does it produce a blockchain, it is a network protocol that relies on existing blockchains for its security.

Or:

The Lightning Network is not itself a blockchain, nor does it produce a blockchain, it is a network that relies on an existing blockchain for its security.

(This doesn't imply that it only works for the Bitcoin blockchain)

Use of "an LN node": I've seen it mentioned in another comment, but I'd like to reiterate that reading it as "an LN node" feels wrong. It feels very wrong to read it as "an elle-en node". Personally when I see it I read "an LN node" as "an Lightning Network node" or "an Lightning node". For these reasons I think it might be better to use "a Lightning node" or "a Lightning wallet" wherever LN is used.

The section "Lightning Network Basic Concepts" uses uppercase items, e.g. "Node" and "Blockchain". The section "Lightning Network Use Cases, Users, and Their Stories" uses lowercase items, e.g. consumer, merchant. It's just a nit, but might want to change it to one or the other for consistency.

Wei has implemented a liquidity provider service that rents inbound channel capacity on the Lightning Network, charging a small bitcoin fee for each rental period.

As an experienced Lightning user, that sentence is a little confusing to me. Is the capacity inbound to Wei's node and he then rents that out for people to use (such as a custodial wallet service)? Or is it inbound to the users? I realize it means it is inbound to the users, but it is somewhat ambiguous and to new readers it will probably go over their heads. It might make sense to simplify it to something like the following:

Wei has created a service that charges a small bitcoin fee to provide channel liquidity on the Lightning Network.

Both "on-chain" and "onchain" are used throughout the book. We should decide on one correct form to be used going forward. I lean towards "on-chain".

Where should we upload new figures to? And how do we properly display them in the asciidoc.
I've tried the syntax, but it does not display the figure correctly :(

This is not for section 3 but we should somewhere describe how fees are computed from destination to sender as the fee rate is multiplicative and later fees on the path have an impact on the fees to be charged by earilier hops. Not clear yet which chapter to put this.

Current CH1 ends with:

"She also wants a mobile wallet so that she can use it for small payments on-the-go, so she chooses the Eclair wallet, a popular non-custodial mobile LN wallet."

Can I take a stab at writing a short guide on setting up an LN Wallet on Eclair for Android, and sending a small payment? And should this go in CH1 or CH2?

Some minor details about chapter 1.

"However, increasing block size simply shifts the problem to node operators, where each increase is multiplied by an order of magnitude."
This seems not well defined to me. A multiplication by an order of magnitude still assumes linear scaling. Is this correct? Also an order of magnitude in what. I would suggest to rephrase this part to make it more obvious to the reader.

Finally I noticed that some of the fictional characters are localised in the world, while others are not. I would suggest to localise all of them and put Alice and Bob somewhere in the USA or the Netherlands and Wei to China.

Also I think it should be made more obvious that these characters are fictional and given the current state of the acceptance of the lighting network it may be hard to reproduce their story in real life.

In order to make it easier for users to follow the examples, we have made two decisions to standardize the development environment. These decisions will be implemented as part of Chapter 4

1. We will be using a Docker container to build a consistent environment in which all the examples can be run and tested. The Dockerfile will be shared on this repository and instructions to run it will be included in the text

2. We will be using Bitcoin in REGTEST mode, and providing instructions on how to deploy and use regtest and LN on top of it. This will alleviate the need to bootstrap a node and help developers understand the power of using regtest in a dev environment.

Maybe one day we can "backport" both of these ideas into Mastering Bitcoin, if we execute successfully here...

Topics for discussion:

• Is Docker the right choice?

I think it will help users of Windows, Mac and various other systems load a standardized dev environment. Though many developers in our space run some version of Linux, there are also many readers who do not and would find it difficult to replicate our examples. We can't offer tools and examples for every OS, so we have to pick one

• If Docker, what OS and image

I think we should standardize on Ubuntu 18.04 LTS, because it is the most supported OS across all the open source projects. As an LTS version (Long Term Support), it will be supported until April 2023. By then we will be in a second edition and can move to the next LTS version. The downside is that an Ubuntu 18.04 image is much "heavier" than say alpine, but the purpose of this container is to be very very standard and have the most well known tools, so it is worth paying the price in disk space for Ubuntu.

• How much of the dev environment should be packaged in the Docker image?

I think at least the basic dev tools and pre-requisite libraries for the various tools we will install (eg. all the things you apt install before bitcoin, Go support for lnd, etc). Do we also pre-install bitcoind latest from PPA? Or do we include that in the examples so that people can learn how to do it on their own? Mastering Bitcoin already covers all that in chapter 3 and I don't want to repeat too much.

• Separate repository?

Should we make a separate repository for the Docker image, scripts and examples, so that we can clone it and make it part of the Docker container, without having to pull in the book itself? I think so....

Please add your thoughts and suggestions!

Seems like a trivial question but after starting to work on first drafts of it I am not so sure anymore. Depending on the reason why to include it the section could look very different. Here are two main reasons that come to my mind:

1. For completeness of the topic and having an overview
2. For educational / didactic purpose

While writing the section about unilateral payment channels I had the feeling I was already mixing the two purposes which I personally consider bad style. Thus my question.

Completeness reason

It was brought to my attention that Aaron van Wirdum has done a very nice piece about the history of the Lightning Network for bitcoin magazine. This seems from the main milestones similar to the resources that we have included so far. His style seems about completeness of events.

Educational / Didactic purpose

I was surprised to see how things have been invented over time. In particular the unidirectional payment channel seems extremely easy to understand and contains many of the concepts that we use for our current payment channels. namely:

1. multisignature wallet
2. funding transaction
3. timelocked refund
4. off-chain double spend of the funding tx to encode the balance
5. asymmetric information (in this case only the recipient has both signatures and the sender only has their own signature)

My feeling is that this would be an amazing example to start with / introduce terms and move on to show the more technical details of the penalty mechanism that fixes the flaws that the unidirectional channel still had.

Meta:

I am leaning towards the second reason for writing about the history of payment channels. While in communication of knowledge usually laying down the entire thought process by telling a story how the solution was build is considered bad style (at least in academia) in this concrete case it seems like a nice step by step approach to introduce concepts and terms.

Maybe we could even have both reasons but separated. Meaning a text similar to what Aaron did for Bitcoinmagazin and then the more didactic versions in later chapters.

What are your thoughts?

Something in the travisCi configuration file is causing it to crash. Can someone fix it and do a PR please?

We want to do some basic linting and style checks. Don't need to be overly strict, so remove rules if you have to!

** What topic should be added? **
Running LN clients over TOR

** Who is this topic for [audience]? **
Everyone

in c299e45 I tried to introduce the path finding problem. as it is connected to transport / routing I run into some trouble of clear separation. We might have to change the order to start with routing and only discuss path finding as a follow up problem.

Maybe as path finding is my research topic I am currently making it more complicated as it is. Would still be good to have the discussion and a round or feedback

I want to avoid writing "Lightning Network" a thousand times in this book. So I want to use the acronym "LN", as a shortcut. In many places this works well.

For example "a LN node" or even (sic) "an LN node". Similarly, wherever we use Lightning Network as a qualifier to another noun such as node, wallet, transaction, channel etc.

However, in practice, I have found it difficult to read and write the LN acronym if we are not using it as a qualifier. For example the sentence:

"The Lightning Network is a layer-2 network that operates..."

In that kind of sentence, where the Lightning Network is the subject of the sentence and not a qualifier, it feels weird to write and difficult to read as an acronym:

"The LN is a layer-2 network that operates..."

I propose that we use the acronym "LN" where it is used as a qualifier (LN node, LN transaction, LN wallet) and write "The Lightning Network" in full where it is the subject of the sentence and not a qualifier.

Thoughts?

What topic should be added?

Lightning Explorer List

Who is this topic for [audience]?

Developers, and wallet users.

Additional context

I wanna add a Lightning Explorer List to the book :

• 1ML - 1ML explorer (mainnet + testnet)
• Lightblock - lightning network explorer mainnet.
• Lightning network explorer - Lightning network explorer (testnet)
• Robtex Bitcoin Lightning Explorer - Robtex Bitcoin Lightning Explorer (mainnet)

But not sure which chapter it should be placed in?

I have seen that many pictures have been included in chapter two and I want to make sure that we are legally allowed to use them. Should we for example get a written agreement by the folks from ACINQ / Eclair? I am pretty sure they will not mind / object but I guess it is better to just resolve this before problems happen. Similarly the picture of the ATM or the screenshots of the pictures of the cops of coffe.
Should we have a file somewhere where we keep track of copyright and licences of used pictures?

The asciidoc directive:

[role="pagenumrestart"]

instructs the rendering engine to restart page numbering from "1", which is used to switch from the preface/glossary numbering of "i, ii, iii" in chapter 1.

This directive should not be repeated in subsequent chapters, as that would cause the page numbering to restart from 1 each chapter. Because other chapters have been copied from chapter 1, they erroneously include this directive.

Chapter 2 has this categorization:

[[lnwallet-categories]]
.Broad Categories of "LN Wallets"
|===
| Wallet Type | LN Node | Keystore/Custody | Technical Skill
| Full Node & Wallet | Full Node | Non-Custodial | High
| Non-Custodial Wallet | 3rd-party node | Non-Custodial | Medium
| Custodial Wallet | 3rd-party node | Custodial | Low
|===

It is not perfect. It is not ideal. It sort of implies that a "Full Node & Wallet" is not a "Non-Custodial Wallet" because they are 2 different categories. It also states that a "Non-Custodial Wallet" uses "3rd-party node" for LN Node which is not the true definition. In order to simplify, things are getting mixed up here and we are not communicating a clear message.

The term "Custodial Wallet" is independent of which LN Node is used.
We should rethink this table and categorization.

Which part needs editing?
table Broad Categories of "LN Wallets"

What editing does this need?
Correction, clearer distinction, more precise distinction

How does it currently read?
see above

How should it read?
Here is a first draft, but this might not be perfect either, but at least this draft is consistent:

There are many ways wallets can be characterized or categorized. From all characteristics the two most important criteria are LN Node use and fund custody. Correspondingly the two most important questions to ask about a specific wallet are:

• Does this Lightning wallet have a full LN Node or does it use a 3rd-party LN Node?
• Does this Lightning wallet store its own keys or are the keys held be a 3rd-party custodian?

From these two questions we can derive 4 possible categories. However, the wallet category where a full LN node is used but the keys are held by a custodian is so rare that we ignore it from our discussion. That leaves us with three commonly found categories, but again remember that this is just one way of categorizing Lightning wallets.

[[lnwallet-categories]]
.Three commonly found categories of "LN Wallets"
|===
| Wallet Category | LN Node | Keystore/Custody | Technical Skills Required
|===
| Full-Node Non-Custodial Wallet | Full Node | Non-Custodial | High
| 3rd-Party-Node Non-Custodial Wallet | 3rd-party node | Non-Custodial | Medium
| 3rd-Party-Node Custodial Wallet | 3rd-party node | Custodial | Low
|===

Sometimes people use the term "Light wallet" as a way to refer to a wallet that does not include a full node. So, when you hear someone talk about a "Light wallet" she or he is referring to a wallet that uses a 3rd-party LN node. A "Light wallet" could be custodial or non-custodial.

What do you think about that? Ideas? Suggestions? Improvements?
Once the team agrees on something I'd be happy to put it into a PR.

Merged #25 and as discussed at: #23 (comment) this person is very real. We need to figure out if we are allowed to use this story or if it is too close.

c.f.: https://bitcoinist.com/bitcoin-pictures-lightning-network/

@bitcoina implied in one of his comments that (s)he is a parent of the 9 year old and offered proof that the story may be used. in this case the discussion would be much easier

Which part needs editing?
Getting started

What editing does this need?
what does make the lightning network?

How does it currently read?

 First, nodes must communicate on a peer-to-peer basis with other LN nodes. This communication forms the Lightning _Network_ itself.

How should it read?
There are actually two networks. The network of payment channels and the peer to peer network. while every payment channel also needs a peer connection between the channel partners the other way is not around. however having a peer connection is not really useful without opening / operating a payment channel afterwards.

So I am not sure if the peer 2 peer network actually makes the lightning network (not the protocol but the actual network) or if it is rather the network of payment channels.

We do not need to elaborate on the differences but we should be clear about the term that we use / introduce.

** sidenode ** : I agree with the three ingreedients of a lightning node / software but I always say the lightning network consists of 3 ingreedients:

1. The ability to open, operate and close payment channels
2. The ability to trustless route payments through a network of payment channels
3. a family of cryptographic and communication protocols to make sure that the network operats in the desired way.

All terms should be used consistently.

In chapter 2 there is a lot of talk about Lightning wallets. These are the terms I found:

• lightning wallet
• Lightning wallet
• LN Wallet

I suggest to always consistently use a single term: e.g. Lightning wallet. (Uppercase L, lowercase w). As in: "Alice is using a Lightning wallet."

Lightning wallet is just one example. There are many other terms that I have seen used differently in different paragraphs. (Blockchain vs blockchain, etc.)

Which part needs editing?
everything needs to be revised

What editing does this need?
replace with agreed upon term(s)

How does it currently read?
e.g.

• lightning wallet
• Lightning wallet
• LN Wallet

How should it read?
e.g.

• Lightning wallet

Again, if people think this is a good idea and should be done, then I can start a list, make the agreed upon changes and submit the corresponding PR(s). Just let me know.

Hi All:

We are one of well-known Blockchain We-Media community named "Lan hu bi ji (蓝狐笔记)" in China.
We are existing that your guys working on writing a new book about Lightning Network. We agree that the off-chain Lighting network channel can speed up bitcoin to our daily life.

It will be great if we can contribute to translate this new Mastering the Lightning Network to Chinese users.

We have lots of experience in blockchain/bitcoin article and whitepaper translation. It will be great if we have a chance to contribute to Lightning Network.

Many thanks.

Anthony

@aantonop and I have discussed that the structure of the second chapter should be similar to the one from Mastering Bitcoin but adapted to the topics of the lightning network.

Reading through the second chapter of Mastering bitcoin we see that a user is getting a nice overview of most terms / concepts being used in bitcoin while staying with a rather simple example and a very end user oriented perspective. I tried to transfer this to lightning. I might have been a little bit too technical when you actually ready the bulletpoints that I also added to the section headers but I guess that is something that we will quickly figure out when we start writing everything.

I am also not sure about the layer cake: https://blockstream.com/img/blog/2018-04-30/lightning-layers.png In general I like this separation of components a lot. My feeling is thought that we write from an end user perspective rather than the perspective of a BOLT developer. Still I wanted to throw in the layer cake:

multihop - SPHINX
transfer - HTLC
update - LN-Penalty / Eltoo / Gossip
base - framing - feature negotiation
transport - noise_xk

At this time I would be happy about your thoughts and comments. Maybe I should do a video in which I just discuss the two outlines and how I understand the content in them. Would that help to get ideas in or is video the wrong format to start such a discussion?

in the follwing you can see the two structures

How Bitcoin Works

=== Transactions, Blocks, Mining, and the Blockchain
==== Bitcoin Overview
==== Buying a Cup of Coffee
=== Bitcoin Transactions
==== Transaction Inputs and Outputs
==== Transaction Chains
==== Making Change
==== Common Transaction Forms
=== Constructing a Transaction
==== Getting the Right Inputs
==== Creating the Outputs
==== Adding the Transaction to the Ledger
===== Transmitting the transaction
===== How it propagates
===== Bob's view
=== Bitcoin Mining
=== Mining Transactions in Blocks
=== Spending the Transaction

How the Lightning Network Works

=== Payment channels
==== Multisig address
==== Funding Transaction
==== Commitment Transaction
==== Announcing the channel
==== closing the channel
=== Invoices
==== Payment Hash
==== Meta Data
=== Delivering the payment
==== Finding a path
==== Onion routing
==== Payment Forwarding Algorithm
=== Comparison with Bitcoin

alternative structure for the invoice section

=== Invoices
==== create an invoice
==== decode an invoice
==== pay an invoice

It'll be written million times in the book. Maybe it would make sense to consider to use LN consistently instead of Lightning Network after the first paragraph.

Maybe it would be even better done so to use Lightning Network in titles and LN in bodies.

Note: this is a repost of Issue #128 in the new format

What topic should be added?

Hardware considerations in setting up a self-hosted Lightning Node

I know this book is intended to focus on the Lightning Network protocol and the software that's built around it (e.g. lnd, c-lightning, eclair etc.). However, there's a greater need for hardware knowledge in Lightning than in Bitcoin because:

• Nodes need to be online at all times to receive payment and enforce channel penalties (not so in Bitcoin)

• Channels do not exist on the blockchain, and are only known by the partners. So there is a need for channel backups (e.g. on cloud storage) to prevent loss of funds (only need to backup your seed in Bitcoin)

• If you don't want to rely on custodial services for funding transactions and penalties, you need to run a Bitcoin node and have 200+GB of disk space (and you still need to be your own Lightning Node at least. No 'SPV Lightning' for now)

Who is this topic for [audience]?

Users wishing to host their own Lightning Nodes without relying on custodial wallets, cloud providers, or SPV for Bitcoin transactions

Additional context

So far, most of the user discussion is centered around using Lightning as a user on a mobile. There are users who run their own Bitcoin + Lightning node on dedicated hardware like a Raspberry Pi + Hard Drive. In the future, I can see off-the-shelf Bitcoin+Lightning PoS Terminals being sold to retailers and users. For now, you pretty have much have to build it yourself. Some good open-source examples right now are:

MyNode: https://mynodebtc.com/
Raspiblitz: https://github.com/rootzoll/raspiblitz
Casa Node: https://github.com/Casa (node soon to be open source)

Hello,

My name is Michael, I am a content creator and marketer. I have been in blockchain since 2014. I produced the explainer video for Namecoin as well as others. I worked with Adam Levine on Tokenly. Currently I am working on a couple projects in the space: Tokensquare.com and Cone.io.

You can see some of my video work at reach.video

I am here to offer illustrations, diagrams and maye some support videos covering topics in the book to help promote it once it launches.

I am happy to collaborate with some of the experts here to fully understand and produce any visuals the book might need. so just let me know.

Hi

Just a suggestion that might make it easier to get more out of your contributors. Perhaps create a to do list of:

• Stubs or topics you want written
• Existing chapters you want expanded or edited
• Specific feedback you're interested in

Right now I'm looking and I'm not really sure where I can contribute and I figure there must be others thinking the same

This was merged in dae192a

and I think the language could be imporoved a little bit

There is a comment in the text reading:

but there is no "SPV" functionality in the LN peer to peer communication right? they have to have full funcionality?

Well you could and eventually might run a LN node without the gossip protocol / BOLT 07. You could then rely on a third party service to make suggestions for path finding and routing. This can even be somewhat decentralized and covered by the protocol in the form of Trampoline routing.

I believe Phonex uses that trick to remove load from the user phone as gossip produces quite some internet traffic which most mobile plans might not support. this can be a privacy issue and protocol improvements for that are still under construction.

Not sure where and how we include this to the book.

Both "Bitcoin" and "bitcoin" are used throughout the book to refer to the overarching Bitcoin network. I propose "Bitcoin" be used consistently to refer to the network while "bitcoin" be used to refer to the currency.

When I first read Mastering Bitcoin, I have to admit I wasn't impressed, it was dry and had nothing from Andreas's enthusiasm in it. But over the years, as I walked my path towards becoming a Bitcoin dev, I found myself coming back to it over and over again, because it was the only coherent and comprehensive resource available with correct information in it, so I slowly turned into the target audience of the book. This time however I am sure I am the target audience and I hope I'll somehow find the time to properly contribute to it.
I also hope this book will finally bring my lack of knowledge on the Lightning Network to a fine level with that I should be able to figure out the how and the right timing of LN integration to Wasabi.

Anyhow I just wanted to chime in and give my best wishes for this important work and remember, the next generation of Bitcoin devs will be learning from this book and every mistake you'll make here will multiply and start a terrible chain reaction, but no pressure :)

Cheers and keep up the good work, can't wait to read it!

The term trustless occurs in several sections in the book so far (10/25/19), namely:
glossary.asciidoc:117
glossary.asciidoc:205
glossary.asciidoc:214
ch02.asciidoc:7
ch01.asciidoc:8
ch01.asciidoc:81
ch01.asciidoc:89
ch01.asciidoc:90
topics.asciidoc:55

I would like to discuss and consider using the term "trust minimized" instead as I feel it conveys a more responsible and accurate version of the message intended for the reader.

Although Satoshi did use the term trustless several times, I don't believe it was as appropriate as one might think given these factors:
For a user of the system to rely on the claims of the proposed system, they have to rely on the following:

1. Trust the hardware manufacturer for not introducing application specific dishonest logic
2. Trust majority of miners to behave rationally (from an economic standpoint)
3. Trust software developers and reviewers to not behave dishonestly

The key factor that makes the above claims close to a non-issue is un-likelyhood that they would take place, however, it is still a significant deviation from a zero probability situation ( or trustless situation ). Trust-minimized implies recognition of the non-zero probability while conveying the importance of trying to remove reliance on trust.

If there is agreement, I'll be happy to submit a pull request with the changes.

as soon as https://bitcoin.stackexchange.com/questions/95355/why-does-every-htlc-in-a-commitment-transaction-rquire-its-own-signature is answered routing.asciidoc should be updated.

The best non-custodial LN wallet for iOS, in my opinion, is Breez. Breez gives you a free 0.01 BTC incoming channel to start with. Sats App & Zeus LN are phenomenal non-custodial iOS LN wallets too. BlueWallet can be non-custodial with the ability to plug-in your own Bitcoin Full node through Electrum Personal Server (EPS), ElectrumX or Electrs.

Probably not the right place to put this, but nevermind.

I've been waiting for a good place to point the lightning.guide URL to, and I think this is it.

lightning.guide

So I commit to leaving this url pointing to this github page for the next year (or when the book is published). Thx.. Bitcoina