The Lightning Network FAQ

[LoyceV]

Phoenix wallet which is your custodian to use Lightning

LN on Phoenix Wallet is only custodial while opening the channel. After that, your wallet is in full control.

[Wind_FURY]

Just to make it absolutely clear, the unconfirmed transaction is only a “problem” between you and Phoenix wallet which is your custodian to use Lightning, and that Phoenix wallet itself cannot open a channel in Lightning without a confirmed transaction.

In this case, Phoenix Wallet (or more precisely ACINQ) initiates the payment from their node rather than route it from you. They expect you to pay them back once the channel between you and them has become active. How can they trust you? Well, you are using their software which was programmed to do that automatically.

Because I’m made to believe that it’s possible to open a channel WITHOUT an onchain transaction.

Under normal circumstances, it would not be possible. If you set up your own node then it's impossible for someone to open a channel to you without a valid on-chain transaction. In fact, by default, that transactions needs to have either 1 or 3 confirmations (it depends on the implementation) before the channel becomes active.

OK, thanks. Then once again it’s very clear that franky1 has been very dishonest in this instance again, calling LN a network of IOUs and he’s trying to make technical-newbies like me believe it’s a fact. He almost gaslighted me again. Hahaha.

[TangentC]

Just to make it absolutely clear, the unconfirmed transaction is only a “problem” between you and Phoenix wallet which is your custodian to use Lightning, and that Phoenix wallet itself cannot open a channel in Lightning without a confirmed transaction.

In this case, Phoenix Wallet (or more precisely ACINQ) initiates the payment from their node rather than route it from you. They expect you to pay them back once the channel between you and them has become active. How can they trust you? Well, you are using their software which was programmed to do that automatically.

Because I’m made to believe that it’s possible to open a channel WITHOUT an onchain transaction.

Under normal circumstances, it would not be possible. If you set up your own node then it's impossible for someone to open a channel to you without a valid on-chain transaction. In fact, by default, that transactions needs to have either 1 or 3 confirmations (it depends on the implementation) before the channel becomes active.

OK, thanks. Then once again it’s very clear that franky1 has been very dishonest in this instance again, calling LN a network of IOUs and he’s trying to make technical-newbies like me believe it’s a fact. He almost gaslighted me again. Hahaha.

The only gaslight is from the people claiming LN is not an IOU system.

@Rath_ , You keep letting everyone else talk about IOUs.

https://coingeek.com/lightning-strikes-out/

If you’re unclear how Lightning Network is supposed to work, LN is a ledger of payment channels that parenthetically connect to the small block BTC network for occasional settlement. While BTC coins are locked in a Segwit address and issued into a channel by a two-way peg and controlled by smart contract rules, tokenized “IOUs” of BTC units can be traded back and forth and kept on a separate tally (like a bar tab) that can be settled eventually on the BTC blockchain. First debuted in 2015, the Lightning Network was supposed to move from concept to full operation in 18 months, but now, five years later, competing implementations from Lightning Labs and Blockstream are still not stable enough for common use.

https://electriccoin.co/blog/bolt-private-payment-channels/

How does this work? Alice and Bob both agree to an initial IOU splitting funds they put in the channel (e.g. they each put in $50 and the IOU is Alice: $50, Bob: $50). This money is held in escrow on the blockchain and released only by a valid IOU signed by both Alice and Bob. For Alice to pay Bob $5, she verifiably destroys her old IOU, and she and Bob sign a new IOU “Alice: $45, Bob: $55.” They can do this repeatedly until either party wants to cash out. At this point, either Alice or Bob can post the latest IOU to the blockchain (or both can post, in the event of a dispute). Thus only channel opening and closure are recorded on the blockchain.

https://www.skalex.io/lightning-network/

Their innovative solution involves creating a second layer that sits atop the current Bitcoin network where users can essentially trade IOUs back and forth before settling accounts on the blockchain.

FYI:
Geez , how thick headed are you bitcoin cult members?  
LN IOU system is right in your face and you want to claim it ain't.

[Rath_]

@Rath_ , You keep letting everyone else talk about IOUs.

If you (or anyone else here) are concerned about the way I moderate this thread, feel free to PM me or create your own thread.

-snip

Let me throw a couple of random quotes at you as well!

Some people seem to see an IOU at work here. They might see bitcoin on Lightning like casino chips, which are tokens for money — as if users traded in their “real” bitcoin for “token” Lightning credit, like IOUs to be cashed in for “real money” at the end of the night.

But unlike a casino, you never relinquish custody of your money on Lightning. Not your keys, not your bitcoin. We’ve all heard that mantra a thousand times. But it’s true. And the converse is also true: as long as you hold the keys, you hold the bitcoin. Therefore, any non-custodial wallet — whether on-chain or off-chain — gives the user more control over her money than any custodial wallet on-chain or off-chain.

An IOU is different. It implies a counterparty claim. If a friend lent you $100, he may have a claim on it — at least in the sense that you probably shouldn’t let him see you on Instagram treating yourself to front-row seats until you’ve paid back the debt. With an IOU, custody of the funds doesn’t translate into the freedom to use them.

An IOU differs from a promissory note in that an IOU is not a negotiable instrument and does not specify repayment terms such as the time of repayment.

An IOU does not specify the repayment terms? What is a negotiable instrument then?

A negotiable instrument is a document guaranteeing the payment of a specific amount of money, either on demand, or at a set time, whose payer is usually named on the document. More specifically, it is a document contemplated by or consisting of a contract, which promises the payment of money without condition, which may be paid either on demand or at a future date.

That totally sounds like a commitment transaction to me.

[DooMAD]

coingeek

I suspect your post is going to be deleted, but just so you know for future, you're only deducting credibility points from yourself by attempting to cite Calvin Ayre and his gutter-press website as a reputable source of information.  Anyone who knows their stuff disregards that website for the trash it is.

Some of us would rather not see misnomers find their way into the everyday vernacular.  It's bad enough we have to put up with everyone saying "51% attack" when that's not necessarily accurate and now people are here deliberately attempting to subvert language again.  But this ends now:

I will be removing any IOU related posts from now on.

It's a misnomer.  Not an accurate representation.  Incorrect on a technical level. 

[franky1]

But unlike a casino, you never relinquish custody of your money on Lightning. Not your keys, not your bitcoin. We’ve all heard that mantra a thousand times. But it’s true. And the converse is also true: as long as you hold the keys, you hold the bitcoin. Therefore, any non-custodial wallet — whether on-chain or off-chain — gives the user more control over her money than any custodial wallet on-chain or off-chain.

funny part is..
the sender holds the keys..
the receiver is promised the funds. but does not have the key.
the receiver only ever gets a key to the funds. to make the previous commitment void of spending.

EG i sign a tx giving value to rath.. i dont broadcast it..
is rath guaranteed to be paid.. nope because the funds are not on his keys, not confirmed on the blockchain
the funds are still on my locked UTXO

but one layer down. a HTLC is not even a bitcoin format contract. thus not even having the potential of rath broadcasting. whats needed to be done is convert a htlc contract(i ou) into a commitment transaction..
but again even this commitment is not yet broadcast. so not yet a guaranteed settlement

..
the other item of discussion.. the channels being unbalanaced by not always being pegged to a utxo.
even loyce and rath have quoted that due to users using a services wallet. the wallet creates the unbacked htlc's with the supposed premise that "normally" they wil get paid later. whereby its a game of trust and honour. and not a fixed rule of guarantee.

as rath quotes
an IOU is NOT an instrument guaranteeing payment
and a HTLC does not guarantee payment
a HTLC is not even a bitcoin transaction.. thus a htlc is an IOU

a HTLC at a later time is negotiated into a commitment..
meaning a HTLC is not a negotiated instrument of guarantee.. a commitment transaction is.


here is the thing..
there is nothing wrong with some choosing to use zero-confirms and services of trust.. as long as people highlight and honestly tell people of the lack of guarantee so that people can be aware and not have to risk large sums.
much like people warn others about risk of using exchanges where they tell people that the mysql balance on the order books is not the same as a utxo under the persons control

meaning if you just admit the risks and actually say its ok for coffee amounts as losses might be low, but not lambo amount.. fine tell them the risks and let them decide.

but to pretend its a 'guaranteed/secure/no fault' all utopian fluff of security levels that match a confirmed transaction on a blockchain.. is being very very misinforming and not morally correct aswell

[Rath_]

the sender holds the keys..
the receiver is promised the funds. but does not have the key.

Since the funds are locked in a 2-of-2 multi-signature address, both the "receiver" and "sender" hold the keys.

the receiver only ever gets a key to the funds. to make the previous commitment void of spending.

Both the "receiver" and "sender" exchange revocation keys (in an appropriate order) before signing a new commitment transaction. The revocation key can be used only if one of them broadcasts an old commitment transaction.

EG i sign a tx giving value to rath.. i dont broadcast it..
is rath guaranteed to be paid.. nope because the funds are not on his keys, not confirmed on the blockchain
the funds are still on my locked UTXO

Your example is completely irrelevant. In this case, I would not be able to broadcast your transaction (because you never gave it to me) and you would be able to double-spend that UTXO fairly easily (since the funds are not on a multi-signature address). In the Lightning Network, both parties can broadcast a commitment transaction at any given time, they cannot send the coins anywhere without the agreement of the other peer and they can punish each other for any fraudulent behaviour. I wouldn't be able to do any of that.

a HTLC at a later time is negotiated into a commitment..

You should not accept an HTLC if you did not negotiate a new commitment transaction which includes that HTLC as one of the outputs. "At a later time" sounds just wrong.

[franky1]

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)

[garlonicon]

hense IOU.. he cant spend it yet but is promised it

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.

[Wind_FURY]

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.

[gmaxwell]

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.

[BlackHatCoiner]

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.

[GGUL]

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.

[Timelord2067]

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.

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?

[garlonicon]

What would happen if the lightning node you chose, lost its multi-sig key after you deposited your coins?

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.

I obviously know the answer, I just want to ensure that it can't happen in my future deposits.

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:

What happens if the Mk node fails at the time of transmitting this information.

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

Nodes A, M1, ..., Mk-1 will assume that the transaction is completed. And the nodes Mk+1,...Mn,B will remain in uncertainty.

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.

[GGUL]

Nodes A, M1, ..., Mk-1 will assume that the transaction is completed. And the nodes Mk+1,...Mn,B will remain in uncertainty.

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.

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.

[garlonicon]

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.

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.

[GGUL]

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.

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.

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.

[garlonicon]

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

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.

[GGUL]

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

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.

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.