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

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?

I think so. In order to use L3, you need transaction batching feature, so some kind of Pedersen Commitments or things like that are needed. I guess in L3 you cannot join any transaction with any script type, just that transaction types when it will be enabled, for example only those with some kind of future Segwit version address or those with some kind of future-tapscript (because taproot is self-upgradeable).

Yes, because in other case it won't be L3, but just another L2.

I guess that garlonicon's way of thinking is "what needs to be outside". In Segwit, signatures are outside. In taproot, signatures are batched. In L2, transactions are outside. In L3, transactions will be batched. In L4, everything will be reduced to single commitment. So I guess in L5, commitments would be batched, for example instead of using one commitment per block, it could be one commitment per 2016 blocks.

If you want to create L3, you have to "push something outside" and because channel creation/destruction transactions are the only things that are present on-chain, then something related to that should be "outside". And batching is "pushing things outside", because in that case you can open some channel, you broadcast channel opening transaction to the "L2 mempool". Then, you do your L3 transactions, but "L2 mempool" is very congested. Finally, you close your L2 channel, but your channel opening transaction is not yet settled on L1. So, it can be reduced by using Pedersen Commitments or some other kind of transaction batching. Of course, to avoid double-spending, some kind of "honest batching proof" will be needed, because if Alice opened a channel with Bob, and Bob opened a channel with Charlie, it should be possible to close all channels and create a payment from Charlie to Alice without worrying if it should be from Charlie to Daniel.

Going further, if you have batched transactions on L3 and it is still not enough, then you have to "push something else outside". And the only thing I can think of is pushing transactions outside. For that, you collect all L3 transactions and create a 256-bit commitment. Going even further from L4 to L5, you have to "push something else outside". You have single 256-bit number per block. How to reduce that? Make one commitment per 2016 blocks. I still wonder how to create L6 by using that kind of logic, but it seems that L5 will be sufficient for a long time.

But, still, only 6.77 billion can hold 28 grams of gold. No matter the number of people who own gold, the 28 grams' scarcity will remain the same. Only if the supply increased, the scarcity would decrease.

So L1 is the block chain and L2 is the Lightning Network, okay I got it. In order to use L2, you need L1; does the same apply for L3 & L4? Would L3 need L2 to operate? To me, it seems that, by the way you wrote it, L3 is a L2 update (?).

Simple, because when L1 does not work as intended, people created L2. When L2 still has problems, people will create L3. And when L3 will have another issues, people will create L4. If L1 would be good enough, people would never create L2, because it would never be needed (as you can see on many altcoins where you don't have L2 or where you will never see L2 by design).

L1 does not work as intended, because if you use BTC extensively and make many transactions, then they have to be stored forever. There is block size limit, so mempool is sometimes congested when there are too many transactions. For that reason L2 is needed. On BCH you have no L2, because they decided to do everything on L1 and they promise to never introduce L2.

L2 does not work as intended, because when L1 is congested, then you cannot settle your L1 transactions. You cannot open and close channels without L1. You cannot send coins to someone who never used BTC when L1 is congested. You cannot close your L2 channel for one satoshi per byte when there are 100 MB other transactions waiting in mempool.

L1 does everything on-chain. L2 does channel opening and closing on-chain and everything else off-chain. I guess L3 would batch matching channel opening and closing on-chain transactions into single on-chain transaction. From L1 it would look like channels will be closed before opening transaction will settle on-chain. I guess L4 would push some kind of 256-bit commitment to the nearest block and everything would happen off-chain. From L1 it would look like some coins are still part of the chain, but no L1 miner knows who owns what in L4 and how many channels are there, the only visible thing would be that there is X BTC locked in the whole L4 layer. But of course L3 and L4 design is just guessing and I am not 100% sure how it will work in practice.

Why “thus less scarcity”? I don't get that. If I gave you 0.999999999999 ounces of gold, I wouldn't make 1 ounce less scarce just because I can cut it in smaller pieces.

sats have always been a shareable unit.
there have always been a rule that the circulation from 5000000000sats per block will halv after 210k blocks and cause a result near on 2100000000000000 sat total cap eventually
yep since day one only 2100000000000000 shareable units.
thats the real scarity

something is not more scarce because redefining 2100000000000000 parts into a buzzword for human eyes as 21m..
because sharing divisions of this buzzword has always been possible. the shareable potential still remains

heck if i created a new buzzword of just 21,000megabitcoins does not make it more scarce
because there is still currently still only 2100000000000000 shareable units (sats limit of future circulation)

however to increase the sharability reduces the scarcity.

imagine something is set in stone.. a round whole pizza can only be shared as a round whole pizza. a pizza is the smallest unit..
ordering 10 pizza's = only 10 people max can share
but but inventing sliced pizza..
means more can share and suddenly pizza is not as scarce as more then 10 can get a slice
(research share dilution.. same company. but more shares)
..
many people think bitcoin was invented from btc with decimal divisions being the temporary flimsy buzzwords that can change

when reality it was built from satoshi mutliples up where btc is the empty buzzword of just human visual
changing the 'must consume sats in whole units' sats rule.. to allowing slices of sats. is allowing more sharing and thus less scarcity


the coding decisions making using bitcoin less useful and less fair, was done purposefully just to promote new features by swaying people "they save money by using new features".. while at code level its purposefully making old standard features more expensive and NOT making the new features cheaper then ever before... but just cheaper then the new recently added extra premium added to old feature

.take the vbyte to bytes that put legacy transactions at a premium 4x fee
 its never been a segwit is 4x cheaper then fee formulae of 2016
 its legacy is 4x more then 2016 and segwit is less then new legacy high premium

.take the lack of any tx fee formula to actually accurately gauge value/age of coin to set true
 premium/discount that has real purpose
 EG coins under 10 confirms should for efficiency purposes cost more then coins over 144 confirms..
 (as it makes spamming tx more expensive)
 someone moving $1billion pays the same fee as someone moving $20.. (thats bad methodology)
 someone moving a coin every block pays same as someone moving once a month (thats bad too)

.take having everyone pay more than 2016 levels .. as a lame excuse to deter spammers just makes everyone not want to use it as much

there are many websites that have turned off bitcoin support and moved to accepting altnet currencies just due to the fee cludgy decisions

after all if paypal started saying that people gotta pay $2+ each time they do something on ebay. people would pay for things using a different payment service

i avoid any ATM that has fees when there are other ATM's that dont. and thats the point

Hi, would you, or anybody else, mind explaining me why there are so many layers of the lightning network? I googled it, but as always, I wasn't assisted properly. I'm a LN newbie BTW and willing to dive into the details now that I have some available time.

Actually it doesn't; it'd have the same scarcity after all, whether we hard forked msats in the source code or not. The number 21,000,000 BTC would never be exceeded. It wouldn't even touch it.

Why is this the funniest part and why are you forced to “spend your value” with LN?

though bitcoin even since 2009 has always been denominated in satoshis. where every raw tx on the blockchain has always been in sats.
which is not easy to break out of, while remaining 'backward compatible'
(there are many ways but that involves having old nodes ignore/accept without validation new tx formats)

by the time it gets to about 2045 there may then and only then be a case to change the value denomination to sub satoshi levels as the block reward would soon then become
sats:                 year:
4882812.5   2049
2441406.25   2053
1220703.125   2057
610351.5625   2061
76293.94531   2073
9536.743164   2085
596.0464478   2101

however that then plays into  the 'shareable' units (scarcity) debate. of adding more shareable units available at the bottom end