Topic: The Lightning Network FAQ - page 38. (Read 33677 times)

You guessed right, ser. Those altcoin “Lightning Networks” are their developers implementing it for themselves, probably truly as a computer science experiment/test, but to some of them, probably just for riding the bandwagon.


Lightning is an “off-chain” layer and doesn’t impact the Bitcoin blockchain/the base layer.

awesome faq, was a pleasure to read


the wording here is a little bit off imo. i guess you are not talking about the lightning technology used on another network than bitcoin. that means the lightning network it is clearly dependent on the bitcoin network and also i would say, that both networks have an impact on each other. i agree with the last part, that no one is force to use neither networks (some say people in el salvador are now force to use it, but that is another topic)

only read the first post for now, sorry if this already came up, will catch up soon

Yes I was going to keep both running a lnd based node in a box and a c-lightning regular build, both VMs. The machine I put them I thought had 16GB of ram so I could run 2 VMs and still have plenty to spare. But it only had 8 so I was running both with just 3GB of RAM. So I was just going to shut it down, pull out the 2 4GB sticks and put in 2 16GB sticks. Also add a 2nd 2 TB  so I could mirror the drive. Had issues and going back to tired / hungry instead of going though stuff slowly I decided to just to a bunch of things at once. (Flash BIOS / different ram / pull 2nd drive) Things went downhill from there. Nothing of which should have caused the issues, but both VMs became unstable.

And the last backup I had done was last week when I moved them to the new box. So no help there. Will wipe everything and start again.

-Dave

By the way, it is not cost-effective at all times. Assuming that it is a one-time thing, I would rather eat the loss than pay extra for an uncooperative channel close. Apparently, c-lightning will be taking that into account soon.

Also, if anyone is wondering how to open multiple channels in a single transaction (c-lightning), here's a command that I used a few moments ago.

lightning-cli multifundchannel -k destinations='[{"id": "03cde60a6323f7122d5178255766e38114b4722ede08f7c9e0c5df9b912cc201d6", "amount": 5000000}, {"id": "037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba", "amount" :1000000}]' feerate=1000perkb minchannels=2


Weren't you going to move your c-lightning node and keep it running?

So we all know this, but let me say it because I just did it.
Do not work on your Lightning Node OR ANY CRYPTO THINGS THAT INVOLVE REAL MONEY when you are distracted / busy / tired.

I have had several things I wanted to do including getting my c-lightning node back up and updating a few other things.

It was a busy couple of weeks and finally, today I figured it's the 4th of July, the office is closed, I can go in and take care of Dave's stuff.

Yeah, well. I was up late last night, got up early today and really should have just stayed around the house and relaxed.
But, I took care of a bunch of stuff around the house, did a bunch of "beginning of the month paperwork and bills" and then went to the office, skipped lunch and began moving hardware before I did the software updates. Which I screwed up...big time...because I was tired and hungry.

I managed to get the node back up and broadcast the close channels.
And, no I did not do a backup because why bother for some minor hardware work, I'll do it before I do the software upgrade.

Stupid....stupid....stupid.

I know better. Never touch hardware without doing a complete backup. But I was hungry and tired and wanted to get it done and get home and watch the fireworks.

-Dave

I would point out that you really do not "deposit" any coin to a lighting node.

You open a channel with another lightning node, and as long as both of you have the relivant keys, the state of the channel can change provided both of you are in agreement. If the node that you opened a channel with losses access to its keys, it will be unable to ever update the channel state, and you will eventually need to close the channel.

However if your node losses access to the relivant keys, your channel partner will need to eventually close the channel. If you have also lost the keys to the address the closing transaction will be sent to, you will have lost access to that coin, as would happen in any other case in which you lose access to your keys.

The confirmation have to go further, in other case the payment is considered incomplete. If stopping in the middle would be possible, then Alice sending coins to Daniel through Bob and Charlie could be convinced that coins reached Daniel, where in fact they reached Charlie. But because the recipient holds some information necessary to confirm the whole payment, it is impossible to stop in the middle without reaching the recipient of the message. And when that property is true in both directions, then the whole message is passed between Alice and Daniel or it fails and all nodes know it failed, because they didn't receive all pieces before the timeout.

Edit: you probably asked about https://lightning.network/lightning-network-paper.pdf point "8.1 Decrementing Timelocks" in LN whitepaper version 0.5.9.2.

Node A sends a confirmation. This confirmation passes through M1, M2, etc. The Mk node fails. And then the confirmation does not go further. Nodes A, M1, M2, ... Mk-1 will assume that the transaction is completed. After the timeout, the other nodes will assume that the transaction was interrupted.

That is the only option, because in other cases some nodes will receive payments and others do not. And that's not how it works: you have a route from A to B and this route as a whole is either completed or not. If it is completed, then fine, every node updates its closing transaction. But if there is any problem at any point of this transaction chain, then everything is rolled back to the state as if that payment from A to B was never started. If some node will try to use any state of "half-baked coins", then some penalty transaction will be broadcasted by some other node.

As far as I understand, there are two options:

1) If node B does not receive confirmation during the timeout period, the transaction is considered incomplete.

2) If node B does not receive a denial during the timeout period, the transaction is considered completed.

It is solved by timeouts. You start from some huge timeout of "N*unit" and decrease it by "unit" for each node. In this way, timeouts are reached from the last node to the first. That means the first node cannot simply run away with its coins, because the timeout for the last node occurs first. Also, there are penalty transactions, so each node doing stupid things is putting the whole channel balance at risk.

Closing channel transactions are not updated simultaneously, but sequentially, node by node.

Let A be the last node that has a closing channel transaction updated. How does node B know that everything ended well and all nodes were updated.

You always have your channel closing transaction after depositing coins. And that means if someone is not cooperating, it does not matter if that node lost the keys or if is simply offline, you can always close the channel and then open another one with someone else.

Every time you deposit something, the closing transaction is constructed and signed upfront, in this way you are always protected when another party stops cooperating.

Because of Segwit, it is possible to create the first transaction, create the second transaction taking inputs from the first, and sign that second transaction without signing the first one. That means transactions are signed in reversed order than they are created, so the final signatures for the first transaction are exchanged where everything else is ready.

Edit: Then, the whole chain is cancelled and another route is tried.

They don't, because nodes don't blindly trust that LN internal transactions (with HTLC and millisatoshis) are final. They are final only when closing channel transactions are updated for each node.

Were you the one that deleted my post response to Franky that was posted PRIOR to your threat, but occurred after you decided to be judge, jury and executioner in someone else's thread given you are not the OP of this thread?

During the transaction through LN, the information is transmitted sequentially. Any participant of the transaction can transfer information only to the previous one or to the next one. This means that all participants cannot simultaneously come to a single decision regarding the transaction status.
For example, let's take the status of a transaction - that it is completed and cannot be canceled. and we have a chain of nodes
A<->M1 <-> M2 <-> ... Mk ... <-> Mn <-> B.
Let node A decide that the transaction is final and passes information about it to node M1. M1 passes M2, etc. the information reaches node B. What happens if the Mk node fails at the time of transmitting this information. Nodes A, M1, ..., Mk-1 will assume that the transaction is completed. And the nodes Mk+1,...Mn,B will remain in uncertainty.

These are theoretical reflections. I don't see a solution to this problem. Therefore, it is interesting to know how this problem is solved in LN.

What would happen if the lightning node you chose, lost its multi-sig key after you deposited your coins? I obviously know the answer, I just want to ensure that it can't happen in my future deposits.

Any further posts by Franky1 will be removed. I've heard your complaints. Sorry for letting him fester.

If he posts again, do no reply, don't quote it. Just report it.  If you reply your replies are going to get removed.

If you want to continue discussing this subject with Franky1, use PM.

An IOU is an “I Owe yUo”, it’s an INFORMAL document acknowledging DEBT to a counterparty. There’s nothing like that in the Lightning Network. They are signed transactions that have not been broadcasted in the Bitcoin network, and included in the blockchain yet. No one is sending anything worthless to the counterparty. They are actual BITCOINS.

So, you see IOU's in transactions inside LN, where final transactions "ready to broadcast on-chain" are not yet baked. But notice that in this state you still cannot spend such "not yet baked coins". When your node is trying to find a route, you cannot take that kind of transaction and get some satoshis out of it. In the same way you could say that sharing block header is IOU from miner's perspective, because the network does not know yet about the content of that block. But as miners cannot spend that headers directly without revealing block content and getting 100 confirmations, it is not IOU. The same here, with "not yet baked coins" in LN. They can vanish at any time and every serious node knows about that. To trust that kind of transactions, "elthree" is needed. And not just any "elthree", but standardized and compatible across the network, allowing any parties to join transactions, something like Pedersen Commitments. Until then, that transactions are just temporary and as long as nobody is building on top of them, it is fine.

Edit: even better example: using your logic you could say that Bitcoin on-chain transactions are IOU's, because first you create your unsigned transaction and then sign it. You could say that there is some internal state where you have "not yet baked coins" and for that reason Bitcoin on-chain is IOU. Also, using the same logic you can say that CoinJoin is based on IOU's, because when nodes are constructing transaction, they are first building it in unsigned state and later everyone signs it. Every system can be decoupled into smaller parts and everywhere you can find a state where things are not yet ready and you can call it IOU's. But what makes IOU is not that middle state alone, but the fact that people are building on top of it and then suddenly their coins vanish.

So, to sum up: you would be right if LN nodes would trust such middle-state transactions and update their "real, ready to broadcast" transactions immediately after receiving any of such middle-state tranaction. But it is not the case, such transactions are simply removed if something goes wrong and another route is tried, so it is not IOU for that reason.

there we go again.. people talking about spending commitments(facepalm)

ok well.
i think ill give it one last chance. and i will try to speak slowly

commitments have a output promise with a condition hash160(secret)
but a commitment is not the HTLC itself. its the link to a HTLC that needs to be provided


however until the intended recipient has the "secret" the recipient cant spend that value. so is owed it but cant collect

let me explain
the commitment of, for instance alice-bob of 0.001 each where alice wants to pay dave0.0005 via bob

would be like:
before:
bc1qalicebobfundting(0.002) -> 1bobleg4cy4ddr3s5 0.001
                                           -> 14lic3l3g4cy4ddr3s5 0.001
XX
becoming
bc1qalicebobfundting(0.002) -> 1bobleg4cy4ddr3s5 0.0005
                                           -> 14lic3l3g4cy4ddr3s5 0.001
                                           -> 1bobleg4cy4ddr3s5 +condition: hash160(secret)
YYY

what most people are missing it seems. is the multiple rounds of communication at the "XX" part
where although alice and dave have no commitment.. alice and dave are sending communication direct
to offer and invoice eachother

some call them HTLC some call them offers. some call them invoices depending on the direction, current status and details of the messages

being rhetorical:
after all how does alice get the public key=hash160(secret) from dave.. to start the ball rolling
after all how does bob get to path find the routes and offer the chains of hash160(secret) to all participants along a route to dave.
how does alice then decide which route to accept/reject causing the rejected route to undo it all to free up their funds
hint: its not all done via commitments

as for the YYY part where dave passes "secret" to his partner who passes it to his back down the route
all the potential flaws, bugs, offline, fund loss, locks, that can cause bob to not get the secret

well a new attempt must be made via another negotiated route leaving bob at a loss this time
(sarcasm: i hear windfury/rath say: dang it i was sure bob was guaranteed those funds)
no 'secret' no money.. even if the commitment is signed

these htlc's and invoices are not commitment transactions between the commited partners. but separate agreement of promise outside the commitments(travelling around the network)
and where at the YYY stage bob still does not have 'secret' yet to be able to spend.
hense IOU.. he cant spend it yet but is promised it.

point being a commitment is not a HTLC
a commitment is a bitcoin zero-confirm with a potential utxo which requires a secret from a HTLC/invoice
a HTLC/invoice is the flimsy non bitcoin denomimated IOU parts(that some people avoid thinking about)