Mastering the Lightning Network book

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

Actually, I didn't even thought thoroughly about the question I made.
In fact, and correct me if I'm wrong, if it happens that one of the peers broadcast a old commitement transaction into the blockchain, this transaction is already constructed and signed by both parties, right?
My question was non-sense because I was asking how could Alice broadcast (I was thinking about constructing it and signing it rather than just broadcasting it) the transaction thinking she would be using only her private key when, this transaction is already signed by both but not yet broadcast!

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: darkv0rt3x on March 22, 2023, 05:55:16 PM

1 - If this is a 2-of-2 multisig address, how could Alice broadcast it on her own?

I think what the author means in that part is that Alice should not broadcast the funding transaction before she constructs the refunding transaction. The reason is that Alice must be sure she will get her money back, even non-cooperatively if needed.

Quote from: darkv0rt3x on March 22, 2023, 05:55:16 PM

2 - Even if shw can do that, in what sense whould her funds be at risk?

If you send funds to a 2-of-2 multi-sig, wherein you only possess 1 private key, then you might be unable to spend if your partner simply disappears. You need him to sign the refunding transaction, and then you can send the money knowing that even if he does not respond, you can refund the channel.

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

Quote from: darkv0rt3x on March 22, 2023, 05:55:16 PM

--snip--

Actually, 2 questions:
1 - If this is a 2-of-2 multisig address, how could Alice broadcast it on her own?
2 - Even if shw can do that, in what sense whould her funds be at risk?

You can find answer to these question if you continue reading chapter 7. I skimmed it and it looks like section "Cheating with Old Commitment Transactions" and "Cheating and Penalty in Practice" answer your question in detail. But the short answer is,
1. Alice simply broadcast TX which represent current or older state of LN channel.
2. After bob detect cheating attempt (by broadcast TX which represent older state of LN channel), Bob could broadcast penalty transaction where Bob take all coin on LN channel.

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

Back to reading the book.

I have a question in Chapter 7, Section Constructing the Funding Transaction.

They show the image of the way a Funding Transaction is created (conceptually) with a 2-of-2 multisig address.
Then, below the image, they say:

Quote from: Mastering LN

Alice does not broadcast this transaction because doing so would put her 140,000 satoshi at risk.

Actually, 2 questions:
1 - If this is a 2-of-2 multisig address, how could Alice broadcast it on her own?
2 - Even if shw can do that, in what sense whould her funds be at risk?

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

Well, with the help of someone, I was able to fix this shit and kinda move on. I even created a small PR in this book github repository.
Tomorrow I'll continue with this!

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

Quote from: n0nce on January 14, 2023, 08:34:44 PM

Quote from: darkv0rt3x on January 14, 2023, 05:15:36 PM

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.

Quote from: ?? on ??

Quote from: darkv0rt3x on January 12, 2023, 06:46:36 PM

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

n0nce

hero member

Activity: 924

Merit: 5943

not your keys, not your coins!

Quote from: darkv0rt3x on January 14, 2023, 05:15:36 PM

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

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

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

hero member

Activity: 924

Merit: 5943

not your keys, not your coins!

Quote from: darkv0rt3x on January 14, 2023, 10:21:17 AM

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'.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: darkv0rt3x on January 14, 2023, 10:21:17 AM

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).

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

Quote from: BlackHatCoiner on January 14, 2023, 09:59:32 AM

Quote from: darkv0rt3x on January 14, 2023, 07:54:44 AM

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.

Quote from: darkv0rt3x on January 14, 2023, 07:54:44 AM

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

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: darkv0rt3x on January 14, 2023, 07:54:44 AM

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.

Quote from: darkv0rt3x on January 14, 2023, 07:54:44 AM

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.

n0nce

hero member

Activity: 924

Merit: 5943

not your keys, not your coins!

Quote from: darkv0rt3x on January 14, 2023, 07:54:44 AM

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

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

Quote from: darkv0rt3x on January 14, 2023, 07:54:44 AM

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:

Quote from: https://github.com/lightningnetwork/lightning-onion/blob/master/path.go#L307

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.

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

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

Quote

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:

Quote

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:

Quote

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:

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

hero member

Activity: 924

Merit: 5943

not your keys, not your coins!

Quote from: Rath_ on January 13, 2023, 05:56:08 PM

Quote from: BitMaxz on January 12, 2023, 08:37:50 PM

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

Quote from: n0nce on January 13, 2023, 09:30:59 AM

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.

Rath_

legendary

Activity: 1876

Merit: 3139

Quote from: BitMaxz on January 12, 2023, 08:37:50 PM

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

Quote from: n0nce on January 13, 2023, 09:30:59 AM

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.

BlackHatCoiner

legendary

Activity: 1512

Merit: 7340

Farewell, Leo

Quote from: n0nce on January 13, 2023, 09:30:59 AM

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.

n0nce

hero member

Activity: 924

Merit: 5943

not your keys, not your coins!

Quote from: darkv0rt3x on January 13, 2023, 10:38:20 AM

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.

darkv0rt3x

hero member

Activity: 1274

Merit: 681

I rather die on my feet than to live on my knees

Quote from: n0nce on January 13, 2023, 09:30:59 AM

Quote from: darkv0rt3x on January 12, 2023, 06:46:36 PM

Specifically this part:

Quote

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.

Quote from: darkv0rt3x on January 13, 2023, 05:12:16 AM

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

hero member

Activity: 924

Merit: 5943

not your keys, not your coins!

Quote from: darkv0rt3x on January 12, 2023, 06:46:36 PM

Specifically this part:

Quote

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.

Quote from: darkv0rt3x on January 13, 2023, 05:12:16 AM

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.

Topic: Mastering the Lightning Network book (Read 362 times)