Topic: The Lightning Network FAQ - page 37. (Read 32053 times)

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)

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


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.


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.


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.

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

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:


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

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.


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



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


That totally sounds like a commitment transaction to me.

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/

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

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

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.

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.

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

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.


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.

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. Because I’m made to believe that it’s possible to open a channel WITHOUT an onchain transaction.

If that "elthree" is centralized, then yes, sure. But if you want to use your "elthree" across many exchanges or across any parties, then that thing should be somehow standardized and it should have an option where you control your funds all the time. For example: you can do "eltwo" by depositing funds to exchange (instead of channel opening), trading (instead of "eltwo" transactions) and withdrawing them (instead of channel closing). Is it "eltwo"? Yes, it is on the same level as LN. Is it centralized? Yes. You cannot control your coins directly and that's the difference between "globally recognized and standardized elthree" and "exchange/wallet centralized elthree". The former will be created, the latter exist today in custodial LN wallets.

to save more meandered off topic rebuttles from certain people. have scarcity debate here
https://bitcointalksearch.org/topic/m.57340802


custodial services take the deposits and funds become theirs. (like exchanges do)
they can then using their app have their customers be giving HTLC millisat balance that never need to broadcast onchain. whereby the HTLC get re-aggregated by the service when users want to close channels
so its not that complicated to do "elthree" stuff
after all channels are not network wide audited so only need to be agreed by the counterparties within the channels (a level below the service) where the service manages any disagreements. thus no special onchain rules need apply
much like bitcoin does not need to fork due to an exchange changing how it saves its customers MYSQL balance in their database
much like how MTGox-BTC-e years ago didnt need to request a bitcoin fork to allow mtgox/btc-e to have 'payment codes' for their in exchange payments between customers

heck people can make elthree stuff where the HTLC balance of all service customers is measured in kittens cats and tigers. where the aggregation converts it into sats by the service at close session

I can confirm this has happened to me, but it's because channel opening in Phoenix Wallet is custodial, and since it only connects to their own node (which they trust), they're not risking anything and I can already make transactions before the on-chain transaction is confirmed.

It's true. But even though I didn't expect it, it makes sense, I don't think it's a terrible thing in this case.
See Opinions on Phoenix Wallet? (and later posts).

To answer TangentC's post: to the rest of the LN-network is doesn't matter that my transaction isn't confirmed yet. My channel is with a node, and that node has confirmed channels to the rest of the world. So as far as the rest of the world is concerned, they don't risk any funds by accepting my transaction.
Opening a channel in Phoenix Wallet is custodial, which means I trusted the wallet with my money already. It's a smart way of making channel opening more user friendly when on-chain fees rise.

Can anyone confirm this? Rath_, achow, gmaxwell? If it’s true, then it’s true, and we would need to review our standpoint/opinions. BUT if it’s not true, and franky1 is caught with disinformation/gaslighting again, then what are you doing franky1?