Mastering the Lightning Network book

[darkv0rt3x]

Hi.

I started reading this book, written by Antonopoulos, Osuntokun and Pickardt, right at github, here.

I have created this thread to ask questions about the contents of the book whenever I'm unable to understand a sentence, a subject, an example or watever question I may have.

If others also want to ask questions on top of my questions, feel free but I would like to keep the thread kind of limited to my questions and people's answers so that I don't lose focus on each question/answer.

When I have a question, I'll try to link it and provide the most information possible to it and/or context.

To start, I'm at the middle of Chapter 3, reading further down in Section Protocol Breach (the ugly way).

The part I'm not fully understanding is this:

If you fail to detect the protocol breach and the timelock expires, you will receive only the funds allocated to you by the commitment transaction your partner published. Any funds you received after this will have been stolen by your partner. If there is any balance allocated to you, you will have to pay on-chain fees to collect that balance.

Specifically this part:

Any funds you received after this will have been stolen by your partner.

If we are not able to detect te cheater peer, we only get the funds that were allocated by the commitment transaction broadcast by the cheating peer, right? So, if this is correct, what are this "any funds I received after this will have been stolen by your partner"??

[1714248025]

1714248025

[1714248025]

1714248025

[1714248025]

1714248025

[1714248025]

1714248025

[1714248025]

1714248025

[1714248025]

1714248025

[BitMaxz]

I think it talks about closing a channel?

Based on what I understand the timelock expires is I think the dispute period according to the wiki if you didn't find the protocol breach all the funds that you received from your open channel will be gone but the deposit amount when you open a channel you can still able to take them out with fees.

protocol breach looks like you need proof that your partner is a cheater or doing fraud most cheaters or fraudsters send/broadcast outdated data with the incorrect distribution. So to avoid it you need to broadcast the most up-to-date settlement transaction to the network.

I think wiki explains better that the link you shared above read this https://en.wikipedia.org/wiki/Lightning_Network

[BitDane]

Specifically this part:

Any funds you received after this will have been stolen by your partner.

If we are not able to detect te cheater peer, we only get the funds that were allocated by the commitment transaction broadcast by the cheating peer, right? So, if this is correct, what are this "any funds I received after this will have been stolen by your partner"??

Cheats happen when a party broadcasted an outdate version of the commitment transaction. It means the cheater shows you an old balance or the one that does not reflect the latest balance in the channel.  With these action of broadcasting an outdated version, the cheater trick you to believe that they have a bigger balance than he is entitled to.  This is called breach or a channel counterparty breach where the cheater can claim more fund that what he should have at the expense of the other party.

Here is an example:

For example, let's say the channel has a balance of 1 BTC and the other party has sent 0.5 BTC. The cheater can broadcast an old commitment transaction that shows a balance of 0.7 BTC in their favor, claiming the 0.2 BTC that they shouldn't have.

https://www.researchgate.net/figure/Lightning-Channels-Each-party-has-a-Commitment-Transaction-that-only-they-can-broadcast_fig6_304621007

[darkv0rt3x]

I think I understand the concept behind the penalty transaction. What I don't understand from that quote is what other funds there are that "any funds you received after this have been stolen by my partner".

So let's say 2 nodes (A and B) have a channel with 40% / 60%, respectively. Then, a new balance was updated and ended up with 30% / 70%. Supposedly, the 40% / 60% commitment transaction is revoked and no longer valid. However, node B goes offline and node A broadcast the revoked commitment transaction with 40 % / 60% and node B fails to detect this breach because it was offline long enough for the timelock to expire. In this scenario, node B will get only the 60% of the funds that were allocated by the broadcast of the revoked commitment transaction by node A.

The mentioned quote says:

Any funds you received after this will have been stolen by your partner

So, what any other funds there are to be received by node B other than the 60%??? This is the part I'm not understanding!

[BitDane]

So, what any other funds there are to be received by node B other than the 60%??? This is the part I'm not understanding!

In an example person A and person B had agreed to send 0.5 BTC each making the channel balance 1 BTC.  Person A send 0.5 to person Person B and person B send 0.1 making the balance Person A = 0.1 BTC and person B = 0.9 BTC.

Then person B goes offline and Person A wanted to cheat Person B by sending an outdated version of the commitment transaction to the blockchain showing a balance of Person A 0.6 BTC and person B 0.4 BTC. and the person B due to being offline failed to detect the cheat before the timelock expires.  Person B will only be able to claim 0.4 instead of the 0.9 BTC and the rest will be claimed by the cheater person A which is 0.6 BTC instead of 0.1 BTC

This way the cheater is able to get more BTC in expense of the other party.  I hope I explain it clear enough.

[n0nce]

Specifically this part:

Any funds you received after this will have been stolen by your partner.

If we are not able to detect te cheater peer, we only get the funds that were allocated by the commitment transaction broadcast by the cheating peer, right? So, if this is correct, what are this "any funds I received after this will have been stolen by your partner"??

Here's an example: you are A and your channel partner is B.

Code:

[0] B opens 1BTC channel towards A
State 0: A [0] --- B [1]

[1] B sends A 0.1BTC
State 1: A [0.1] --- B[0.9]

[2] B sends A 0.2BTC
State 2: A [0.3] --- B[0.7]

If B now broadcasts channel state 1, you will lose any funds received after this, i.e. the 0.2BTC payment. In the meantime you may already have shipped some goods or provided a service, so those 0.2BTC are considered to have been 'stolen' from you.


Again, there's a period of time after B broadcasts such a state (closes the channel unilaterally), during which you can come back online and provide a newer state (state 2). This will not only give you your full balance of 0.3BTC, but actually punish B for trying to publish an old state.

So, what any other funds there are to be received by node B other than the 60%??? This is the part I'm not understanding!

I believe you actually understood the concept but the wording confused you. I hope the step-by-step scenario I described above helps clear it up. 'Any funds you received after this' refers to the funds bringing your channel balance (in your example) from 60% to 70%. Since you received those funds after signing the 60/40 channel state.

[darkv0rt3x]

Specifically this part:

Any funds you received after this will have been stolen by your partner.

If we are not able to detect te cheater peer, we only get the funds that were allocated by the commitment transaction broadcast by the cheating peer, right? So, if this is correct, what are this "any funds I received after this will have been stolen by your partner"??

Here's an example: you are A and your channel partner is B.

Code:

[0] B opens 1BTC channel towards A
State 0: A [0] --- B [1]

[1] B sends A 0.1BTC
State 1: A [0.1] --- B[0.9]

[2] B sends A 0.2BTC
State 2: A [0.3] --- B[0.7]

If B now broadcasts channel state 1, you will lose any funds received after this, i.e. the 0.2BTC payment. In the meantime you may already have shipped some goods or provided a service, so those 0.2BTC are considered to have been 'stolen' from you.


Again, there's a period of time after B broadcasts such a state (closes the channel unilaterally), during which you can come back online and provide a newer state (state 2). This will not only give you your full balance of 0.3BTC, but actually punish B for trying to publish an old state.

So, what any other funds there are to be received by node B other than the 60%??? This is the part I'm not understanding!

I believe you actually understood the concept but the wording confused you. I hope the step-by-step scenario I described above helps clear it up. 'Any funds you received after this' refers to the funds bringing your channel balance (in your example) from 60% to 70%. Since you received those funds after signing the 60/40 channel state.

Ah ok, I see it now. Thanks for the step-by-step guide. It was helpful.
I will finish Chapter 3 probably tomorrow!

[n0nce]

Ah ok, I see it now. Thanks for the step-by-step guide. It was helpful.
I will finish Chapter 3 probably tomorrow!

No worries! I need to get myself a physical copy of it and read through it, as well. I remember really enjoying reading 'Mastering Bitcoin' many years ago, and have now read parts of 'Mastering LN' on GitHub. But these books are also written in a way that makes it pleasant to read front to back.

[BlackHatCoiner]

I believe you actually understood the concept but the wording confused you.

I agree. The sentence "any funds you receive after this will have been stolen by the partner" can also been interpreted as "you get stolen after you've been ripped off by cheating partner", which doesn't make any sense.

@darkv0rt3x, that book is good. I had read it until onion routing, because that was the chapter whom I had the most questions.

[Rath_]

So to avoid it you need to broadcast the most up-to-date settlement transaction to the network.

Again, there's a period of time after B broadcasts such a state (closes the channel unilaterally), during which you can come back online and provide a newer state (state 2).

Actually, you don't broadcast another commitment transaction. If that was the case then there would not be any punishment.

Every commitment transaction has at least two outputs (to_local and to_remote).

to_remote refunds the other party their share of funds. This output can be spent immediately.
to_local refunds the person who broadcast the commitment transaction their balance. This output can be spent:

1) after X number of blocks have been mined since this commitment transaction was confirmed, where X is usually 144 blocks by default,
2) immediately using revocation private key and other party's signature.

So if A attempts to cheat and broadcasts an outdated commitment transaction, B can construct a penalty transaction which consumes A's to_local output and sends it to their wallet.

How does B know the revocation private key? Well, it's complicated. Long story short, when both parties sign a new commitment transaction, they exchange secrets (in a specific order) which can be used to generate the revocation private key for the commitment transaction that is being revoked.

[n0nce]

So to avoid it you need to broadcast the most up-to-date settlement transaction to the network.

Again, there's a period of time after B broadcasts such a state (closes the channel unilaterally), during which you can come back online and provide a newer state (state 2).

Actually, you don't broadcast another commitment transaction. If that was the case then there would not be any punishment.
Every commitment transaction has at least two outputs (to_local and to_remote).

That's true; I just simplified it that way since darkv0rt3x's misunderstanding wasn't about commitment vs. punishment transaction. I had also read in this very thread that he knew about punishment transactions, so I simply left those out of the picture for now in order to solve this question.

But thanks for the concise & correct explanation.

[darkv0rt3x]

Ok, new small question.
Yet on Chapter 3, now on Onion routing Section, where they tell us about its properties, one of them says:

Onions can have up to around 26 hops, or onion layers if you prefer. This allows for sufficiently long paths. The precise path length available depends on the amount of bytes allocated to the routing payload at each hop.

Does this means that a route can ever have more than 26 hops? Or what happens to the Onion package if it needs to exceed 26 hops in the route?

Edited;
Another one. They will keep coming now... And at a faster pace! xD

In the same section, it is said:

    The node decrypts the outer layer of the onion and checks the message’s integrity.

    It confirms that it can fulfill the routing hints, based on the channel fees and available capacity on the outgoing channel.

    It works with its channel partner on the incoming channel to update the channel state.

    It adds some padding to the end of the onion to keep it at a constant length since it removed some data from the beginning.

    It follows the routing hints to forward the modified onion package on its outgoing payment channel by also sending an update_add_htlc message which includes the same payment hash and the onion.

    It works with its channel partner on the outgoing channel to update the channel state.

There are the conceptional steps of a payment forwards algorithm.
I'm not understanding the fowllwoing 2 steps:

It works with its channel partner on the incoming channel to update the channel state.
...
It works with its channel partner on the outgoing channel to update the channel state.

What I'm not quite understanding is the incoming and the outgoing channels. Like, When a node is "taking care" of its onion layer, isn't it using a channel to the next hop? It's a single channel with liquidity on the 2 sides yes? So, I'm not sure I understand why they refer to incoming and outgoing channels as if there were 2 channels involved! What am I misunderstanding here?

Same happens in this quote:

Of course, these steps are interrupted and aborted if an error is detected, and an error message is sent back to the originator of the update_add_htlc message. The error message is also formatted as an onion and sent backward on the incoming channel.

The "incoming channel" is bugging me! :|

[n0nce]

Does this means that a route can ever have more than 26 hops?

I'm pretty sure that's right, yes.

Or what happens to the Onion package if it needs to exceed 26 hops in the route?

The software probably just doesn't try to build paths longer than 26 hops. I.e., if a path has 26 hops and hasn't reached its destination, it won't be extended any further.

In LND, there's a comment explaining how that's limited by a max. size of 1300 bytes in a routing info block:

Code:

// NumMaxHops is the maximum path length. There is a maximum of 1300 bytes in
// the routing info block. Legacy hop payloads are always 65 bytes, while tlv
// payloads are at least 47 bytes (tlvlen 1, amt 2, timelock 2, nextchan 10,
// hmac 32) for the intermediate hops and 37 bytes (tlvlen 1, amt 2, timelock 2,
// hmac 32) for the exit hop. The maximum path length can therefore only be
// reached by using tlv payloads only. With that, the maximum number of
// intermediate hops is: Floor((1300 - 37) / 47) = 26. Including the exit hop,
// the maximum path length is 27 hops.

[BlackHatCoiner]

Does this means that a route can ever have more than 26 hops?

Yes, as said above. I'm not quite sure if that number was chosen arbitrarily (the 1300 bytes in the end) or not, but I can confidently say that 26 hops is a lot lot. Average lightning transaction doesn't take more than 5 hops. Moving a fair amount of money, like 500,000 sats, via 26 hops, and prepare to pay some good chunk in fees. It'll cost much more than an on-chain transaction.

It's a single channel with liquidity on the 2 sides yes? So, I'm not sure I understand why they refer to incoming and outgoing channels as if there were 2 channels involved!

Note that it's talking about intermediary nodes, not sender neither receiver. As far as I understand (and please correct me if I'm wrong), the forwarding path looks like that:

Code:

[...] --> A --- 0.1 BTC --> B --- 0.1 BTC --> C --> [...]

Let me rewrite what the book says, in terms of A, B and C as intermediary nodes.

• Node B decrypts the outer layer of the onion it received from node A, and checks the message’s integrity.
• It confirms that it can fulfill the routing hints, based on the channel fees and available capacity on the outgoing channel, which is the channel B and C have.
• It works with its channel partner on the incoming channel (the one between B and A) to update the channel state.
• It adds some padding to the end of the onion to keep it at a constant length since it removed some data from the beginning.
• It follows the routing hints to forward the modified onion package on its outgoing payment channel (B's and C's, again) by also sending an update_add_htlc message which includes the same payment hash and the onion.

[darkv0rt3x]

Does this means that a route can ever have more than 26 hops?

Yes, as said above. I'm not quite sure if that number was chosen arbitrarily (the 1300 bytes in the end) or not, but I can confidently say that 26 hops is a lot lot. Average lightning transaction doesn't take more than 5 hops. Moving a fair amount of money, like 500,000 sats, via 26 hops, and prepare to pay some good chunk in fees. It'll cost much more than an on-chain transaction.

It's a single channel with liquidity on the 2 sides yes? So, I'm not sure I understand why they refer to incoming and outgoing channels as if there were 2 channels involved!

Note that it's talking about intermediary nodes, not sender neither receiver. As far as I understand (and please correct me if I'm wrong), the forwarding path looks like that:

Code:

[...] --> A --- 0.1 BTC --> B --- 0.1 BTC --> C --> [...]

Let me rewrite what the book says, in terms of A, B and C as intermediary nodes.

• Node B decrypts the outer layer of the onion it received from node A, and checks the message’s integrity.
• It confirms that it can fulfill the routing hints, based on the channel fees and available capacity on the outgoing channel, which is the channel B and C have.
• It works with its channel partner on the incoming channel (the one between B and A) to update the channel state.
• It adds some padding to the end of the onion to keep it at a constant length since it removed some data from the beginning.
• It follows the routing hints to forward the modified onion package on its outgoing payment channel (B's and C's, again) by also sending an update_add_htlc message which includes the same payment hash and the onion.

Ok, I think I understand. Although I could argue that we could also call channel between B an C as incoming (funds are going "into" C node channel), depending on the point of view, no? Same for the mentioned incoming channel between A nd B. Could also be called outgoing channel in the sense that the funds are going "out" of node A via channel between A and B. Or not? Would it be completely wrong?
(Just finished chapter 3).

[BlackHatCoiner]

Would it be completely wrong?

No it wouldn't. Funds come and go depending on the side you're looking at. But since it says about intermediary nodes, I suppose the author focuses on B-like nodes, which they receive money from a prior node (AKA receiving / incoming capacity) and they send money to subsequent nodes (AKA sending / outgoing capacity).

[n0nce]

Although I could argue that we could also call channel between B an C as incoming (funds are going "into" C node channel), depending on the point of view, no?

Correct, 'incoming' or 'outgoing' depends on the individual transaction we're looking at. B could route a transaction from A to C and would call its channel AB 'incoming', meanwhile a payment from C back to A would make that same AB channel 'outgoing'.

[darkv0rt3x]

Ok, I'm now in that stage in Chapter 4 of installing bitcoind and c-lightning as docker containers. I'm not familiar with docker at all. I'm using it for the first time.
I have successfully built the docker container for bitcoind to run on regtest as mentioned here.
I am now running a bitcoind docker and minning 6 blocks every 10 seconds.

Later I am instructed that for runnig a bitcoind docker and a c-lightning docker, we need to create a network between both so that c-lightning can communicate with bitcoind.
The instructions are:

Code:

$ docker network create lnbook

This one is ok.
Then, I am said that for c-lightning to work, needs a bitcoind docker running. So, I am given the command to start bitcoind docker connected to the newly created network.

Code:

$ docker run -it --network lnbook --name bitcoind lnbook/bitcoind

But before I run this command, I think to myself: "Wait, I already have a bitcoind docker running that is actually minning blocks, from previous instructions. Should I start yet another one? Should I stop the one that is running and start this one now? What about the blocks that were minned by the bitcoind container from previous instructions? That docker was not connected to the network that was created later in the instructions.
So, I went to the docker that was running, hit CTRL+C and then tried the command above, getting this message:

Code:

$ docker run -it --name bitcoind lnbook/bitcoind
docker: Error response from daemon: Conflict. The container name "/bitcoind" is already in use by container "15d2c58b441707ae2777050a99f330c013639d37805cd9b1573f4db1faccd30e". You have to remove (or rename) that container to be able to reuse that name.
See 'docker run --help'.

Now, I have no iea what to do. I am using docker for the first time!


Edited;
Ok, I just managed to run the docker container conencted to the created networrk.
I had to run

Code:

$ docker rm bitcoind
$ docker run -it --network lnbook --name bitcoind lnbook/bitcoind

[n0nce]

Edited;
Ok, I just managed to run the docker container conencted to the created networrk.
I had to run

Code:

$ docker rm bitcoind
$ docker run -it --network lnbook --name bitcoind lnbook/bitcoind

That's correct; even if you stopped the docker container, it still 'existed' and you therefore need to delete / remove it (rm).

If you followed the book step by step, I'd honestly consider this a 'bug' / error and would recommend to create an issue with description and fix (those 2 terminal commands).

[darkv0rt3x]

Edited;
Ok, I just managed to run the docker container conencted to the created networrk.
I had to run

Code:

$ docker rm bitcoind
$ docker run -it --network lnbook --name bitcoind lnbook/bitcoind

That's correct; even if you stopped the docker container, it still 'existed' and you therefore need to delete / remove it (rm).

If you followed the book step by step, I'd honestly consider this a 'bug' / error and would recommend to create an issue with description and fix (those 2 terminal commands).

Yes maybe. I just need to fix another problem that just came up following this steps. But this is probably on my side.
After I wasa able to run the 2 containers connected to the same network, I tried to start the container for lnd but I failed to run the command correctly and got errors. Then, I spotted the problem and I ran the command with a small typo.
So, I run this:

Code:

$ docker pull lndbook/lnd
Using default tag: latest
Error response from daemon: pull access denied for lndbook/lnd, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

instead of running:

Code:

$ docker pull lnbook/lnd
Using default tag: latest
Error response from daemon: pull access denied for lndbook/lnd, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

It is a typo in lnbook versus lndbook

So, when I ran the wrong command and got that error, I went to search about that and end up finding another similar command in dockerhub. So I ran it:

Code:

$ docker pull lncm/lnd
Using default tag: latest
latest: Pulling from lncm/lnd
c9b1b535fdd9: Pull complete 
b022e8c69823: Pull complete 
be1ac9286ab7: Pull complete 
3e9d70ec7fb9: Pull complete 
35eacf42f633: Pull complete 
ac7b308c590f: Pull complete 
dc936d0a6ff0: Pull complete 
Digest: sha256:971d6b7d7d98217aeb3142de50ec538dfaabcf31b33f16c5b7a4c5b56ab79ebb
Status: Downloaded newer image for lncm/lnd:latest
docker.io/lncm/lnd:latest

But then, when I tried to move on, I got errors. I skipped some of the output because it's too long. It starated well, but then...

Code:

$ docker build -t lncm/lnd lnd
Sending build context to Docker daemon  11.78kB
Step 1/36 : ARG OS=ubuntu
Step 2/36 : ARG OS_VER=focal
Step 3/36 : ARG GO_VER=1.13
Step 4/36 : FROM ${OS}:${OS_VER} as os
 ---> d5447fc01ae6
Step 5/36 : FROM golang:${GO_VER} as go
1.13: Pulling from library/golang
d6ff36c9ec48: Pull complete 
c958d65b3090: Pull complete 
edaf0a6b092f: Pull complete 
80931cf68816: Pull complete 
813643441356: Pull complete 
799f41bb59c9: Pull complete 
16b5038bccc8: Pull complete
...
...
...
get "golang.org/x/crypto/acme/autocert": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/acme/autocert?go-get=1
get "golang.org/x/crypto/acme/autocert": verifying non-authoritative meta tag
The command '/bin/sh -c mkdir -p ${GOPATH}/src && 	cd ${GOPATH}/src && 	go get -v -d github.com/lightningnetwork/lnd && 	cd ${GOPATH}/src/github.com/lightningnetwork/lnd && 	git checkout tags/${LND_VER} && 	make clean && make && make install' returned a non-zero code: 1

After this, I spotted the typo in my first command and I end up running it again but fixing the typo.

Code:

$ docker pull lnbook/lnd
Using default tag: latest
latest: Pulling from lnbook/lnd
35807b77a593: Already exists 
ae922e9149d6: Already exists 
54b0859e8891: Pull complete 
6ec898f59cb9: Pull complete 
30910091372f: Pull complete 
fc2f3334d969: Pull complete 
6c0a14290d9a: Pull complete 
aac1c3f5cd1b: Pull complete 
add701ef0271: Pull complete 
bd9f43bdd10f: Pull complete 
564e40e79828: Pull complete 
c3a5779fc09f: Pull complete 
3a956cdc95e8: Pull complete 
376a33408dca: Pull complete 
d6703385ffea: Pull complete 
766fa2998f46: Pull complete 
cfda81712259: Pull complete 
Digest: sha256:ac176e7510c6a8a4e0174de4b334cfa2f004177b06e30234872e7d65f8227040
Status: Downloaded newer image for lnbook/lnd:latest
docker.io/lnbook/lnd:latest

But then, when I tried to run the next command from instructions. It starts well, but then:

Code:

$ docker build -t lnbook/lnd lnd
Sending build context to Docker daemon  11.78kB
Step 1/36 : ARG OS=ubuntu
Step 2/36 : ARG OS_VER=focal
Step 3/36 : ARG GO_VER=1.13
Step 4/36 : FROM ${OS}:${OS_VER} as os
 ---> d5447fc01ae6
Step 5/36 : FROM golang:${GO_VER} as go
 ---> d6f3656320fe
Step 6/36 : FROM os AS os-base
 ---> d5447fc01ae6
Step 7/36 : RUN DEBIAN_FRONTEND=noninteractive     apt-get update -qq && apt-get install -yqq 		curl unzip jq bash-completion
 ---> Using cache
 ---> 2e87c33d44ed
Step 8/36 : FROM go as lnd-build
 ---> d6f3656320fe
Step 9/36 : ENV GO_VER=${GO_VER}
 ---> Using cache
 ---> 18cffc28743d
Step 10/36 : ENV GOPATH=/go
 ---> Using cache
 ---> d2bae344e1d9
Step 11/36 : ARG LND_VER=v0.13.1-beta
 ---> Using cache
 ---> 9a1f66f38512
Step 12/36 : ENV LND_VER=${LND_VER}
 ---> Using cache
 ---> 42d6b61dfec7
Step 13/36 : RUN	mkdir -p ${GOPATH}/src && 	cd ${GOPATH}/src && 	go get -v -d github.com/lightningnetwork/lnd && 	cd ${GOPATH}/src/github.com/lightningnetwork/lnd && 	git checkout tags/${LND_VER} && 	make clean && make && make install
 ---> Running in 64d422918c9f
(AFTER THIS POINT ALL OUTPUT IS RED. NOT SURE IT IS SUPPOSED TO BE RED OR IF IT IS ALREADY A BAD SIGN)
github.com/lightningnetwork/lnd (download)
github.com/btcsuite/btcd (download)
github.com/decred/dcrd (download)
get "golang.org/x/crypto/sha3": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/sha3?go-get=1
...
...
get "golang.org/x/crypto/acme/autocert": found meta tag get.metaImport{Prefix:"golang.org/x/crypto", VCS:"git", RepoRoot:"https://go.googlesource.com/crypto"} at //golang.org/x/crypto/acme/autocert?go-get=1
get "golang.org/x/crypto/acme/autocert": verifying non-authoritative meta tag
The command '/bin/sh -c mkdir -p ${GOPATH}/src && 	cd ${GOPATH}/src && 	go get -v -d github.com/lightningnetwork/lnd && 	cd ${GOPATH}/src/github.com/lightningnetwork/lnd && 	git checkout tags/${LND_VER} && 	make clean && make && make install' returned a non-zero code: 1

I skipped some of the red output because it is too long.

Now, I don't know if this is because I ran the other command and tried to run this command or if this is due to something else.
I think I'll simply delete all the lnbook folder and will try again, from the beginning.

Hi.

I started reading this book, written by Antonopoulos, Osuntokun and Pickardt, right at github, here.

I have created this thread to ask questions about the contents of the book whenever I'm unable to understand a sentence, a subject, an example or watever question I may have.

If others also want to ask questions on top of my questions, feel free but I would like to keep the thread kind of limited to my questions and people's answers so that I don't lose focus on each question/answer.

I find this book very interesting based on its area of focus and am interested in this book reading it too and would love to follow up with you in this thread on future questions that might arise from you for more understanding. But I may not be putting down questions for the sake of not to intercept yours.

I think you can ask questions here if you're also reading the book. You are free to do so. I think we will manage a