Topic: [OUTDATED] The Lightning Network FAQ - page 7. (Read 3260 times)

Shower thought question. There were a group of Bitcoiners who wanted a use case for zero-conf in Bitcoin. I read some comments that Roger Ver, and some big blockers, also wanted zero-conf for Bitcoin Cash.

Can Lightning be considered something like a suspended zero-conf?

HTLC's can be reneged on
HTLC's are not even bitcoin transactions (msats units) a HTLC will not broadcast to a blockchain
renegociating how much they OWE each other without actually settling up, is the very definition of an IOU

as for fractional reserves. because LN is off chain. because its not community audited and the contracts are private between 2 people. they CAN both agree privately to say they have more then they really do.
EG instead of having $10 of real balance in a channel. they can say they have $160 in a channel thus letting others outside the partnership form route through them for $160 and thus the other outside part hand over $160
a[$160:$000]b[$010:$000]c   here A wants to pay C $160. but it wouldnt happen because B has only $10 hand to C
a[$160:$000]b[$160:$000]c   B:C can privately agree to say B has $160 to give to C just to get A to hand B $160

yes its possible because A does not get all the private details of b:c channel
you probably are wondering why would C agree to a lie about $160 in B:C if all C can get in 'real value' is $10
well there are many reasons. hacks, blackmail, extortion, friendship, malicious intent,, future owings, previous owings

LN has no auditors its just private agreements between counterparts and yes this can be abused
pleas take some time using LN, not with a fluffy unicorn utopia hat. but a critical thinking bug spotting hat/mindset. then when you spot the bugs and flaws that can be abused. you will see not only why LN is not that great. but you will start to appreciate why bitcoin(the real bitcoin with a blockchain) IS so great.
hopefully then you will start to recognise the double spend solution the byzantine generals solution and the other features of bitcoin which before 2009 were unsolved and had cypherpunks scratching their heads for years prior trying to solve.

at this moment LN nodes are already handing out channels with funds even before the supposed pegged bitcoin blockchain transaction gets a confirm.
at this moment LN nodes are already handing out channels with funds even without a bitcoin blockchain transaction. because the entities funded each other in other methods(coinbase balance, fiat, gold, altcoin)
(research-> bitrefill: thor turbo channel)

this is where things like factories start becoming part of the conversation too. but i think you need to start on the basic research before progressing to the more detailed stuff.

I stand corrected.  CLTVs are indeed the lock used on Bitcoin's blockchain.  However, this doesn't negate the point about there being no fractional reserve or IOUs.



There is still an appreciable difference between an "IOU" and a transaction that has been signed and approved by both parties.  It is far easier to renege on an IOU than it is to renege on a payment channel where both parties have revoked the previous commitment state.  You can certainly keep calling it an IOU if you want, but I suspect I'm not the only one who will never accept such a crass definition.

bitcoin locks on the blockchain are not HTLC's, the blockchain tx's are timelocked multisigs using CLTV
bitcoins on the blockchain use a different type of lock

i can see where you can get easily confused with simple 4 letter acronyms  CLTV vs HTLC

the HTLC's in LN are the temporary 'payment/invoice' IOU contracts
what you might want to do is read some code.

but first. a challenge for you
go to bitcoins github. and in the search type in msat
go to LNs github. and in the search type in msat

what you will notice is bitcoin does NOT have a single reference to millisats or msats
https://github.com/bitcoin/bitcoin/search?q=millisat&unscoped_q=msat
" We couldn’t find any code matching 'msat' in bitcoin/bitcoin
You could search all of GitHub or try an advanced search. "

https://github.com/lightningnetwork/lnd/search?q=msat&unscoped_q=msat
" 70 code results in lightningnetwork/lnd or view all results on GitHub"

what you then do if you start reading more code is learn a HTLC is not a "final state" transaction

hopefully what you realise is that the VALUE that changes as temporary IOU (it changes as different agreements of who OWES what changes) is measured in LN as millisats. which is a different unit of account than bitcoins/satoshi's. infact a unit of account bitcoin dos not recognise

have a nice day with your research

I guess every single person on planet Earth is going to have to update their definition of the word "fallacies", as apparently franky1 has decided it means something new now.  Or maybe that's why franky1 also decided to come up with a brand new spelling for it.  

There are no fallacies in the above text unless you don't understand LN.  

There are no custodians in Lightning.  A custodian is a third party who holds and controls your funds directly.  If you make a payment via a bank transfer or card payment, a bank is generally the custodian you are required to place trust in.  With LN, the transaction is between you and the other person, peer to peer.  If your payment is routed through other users, those users are not in direct control of your funds.

Bitcoins in a hashed time lock contact, or HTLC, do not leave the Bitcoin blockchain.  Fractional reserve is not possible and there are no "IOUs".  Whatever total amount is placed in the initial HTLC CLTV, it will be the same total that is broadcast back to the blockchain when the channel is closed.  

You also repeat the same thing, and accuse me of not learning anything, when everything I have learned is nothing but the truth, and no sane Bitcoiner can accept your opinions because "IOU pegged promises to pay in Lightning" is simply, wrong.

You can trick the newbies though, which I encourage, to make them have actual learning experience with the "different" people in the community. But they will also know the truth sooner, or later. Sorry.

you repeat the same thing, but have no clue. get a clue and see if your repeats matches your own clue.
i gave you a clue, its called millisat. now its time you go out and search about it and learn it then go learn beyond it taking more steps until you find your own clue

Why should I be the only one who needs to update "my research", when everyone with a sane mind knows that there are no "IOU pegged promises to pay tokens" in Lightning?

You're not convincing anyone, except maybe some newbies, and which I encourage them to believe you to make them actually learn from experience.

i guess this is where windfury gets his mis-information.
so lets atleast state the obvious. seeing as he thinks the link he quotes is his bible to LN. lets use it against him with some obvious falacies

Q 7: Will there be any form of custodian risk in a Lightning Network?
Do I need to trust anyone to hold my money on my behalf?
A: No, this system is not based on trust; you remain in full control of your money.
vs
Q13:
A Holding value on a Lightning Network means that you are in possession of double-signed transactions. .....
The transactions you are holding are of the 2 of 2 multi-signature type.
Both you and your counterparty will sign, and you will both store the transactions locally.

---

Q 8: I’ve heard that Lightning transactions are happening “off-chain”…Does that mean that my bitcoin will be removed from the blockchain?
A: No, your bitcoin will never leave the blockchain.
vs
Q 9: I’ve heard that the Lightning Network will require my bitcoins to be locked up…Is this correct?
A: “Locked up” is a very misleading term in this case.
Lightning will not make your money less accessible.
Your money will actually become more accessible when held in a Lightning channel.

---

and then there is the big facepalm of Q14

the long waffle that bitcoin has no coin and is just signed message so if signed messages are involved then it must be bitcoin

what the article DOES NOT correctly mention is that the payments within LN are measured in MILLISATS as the unit of account. but the bitcoin network is measured in sats.

a LN payment signed in millisats would not be accepted onto the bitcoin network.
this is why people on LN lose value/get locked out when errors arise as the LN system does not use 8 decimal(sat) transactions at all times. it only uses them for the opening/closing
when people go offline, or you lose your data or someone on a route does not agree to the route in time. 'value' in LN gets locked because its not just using standard bitcoin transactions of 8 decimal where all thats needed is the privkey to move value.


windfury. please do yourself the biggest favour, and update your research

OP, Brand7 also made a Lightning FAQ on Medium, https://medium.com/@The1Brand7/lightning-faq-67bd2b957d70

There might be some questions answered there that are not in your post that newbies need to read before they succumb to the FUD, and misinformation from people who either are gaslighting or don't understand how it works.

I have just updated this thread with answers to the following questions. Do I have to generate an invoice every time I want someone to send me coins over the Lightning Network? Can I refill my channel? Why can't I receive coins? Don't hesitate to ask questions either in this thread or in the Lightning Network discussion one.

There is nothing wrong with the article. Being online all the time is mandatory for receiving payments. There are still many channels which have low capacity. I am not surprised that payments higher than $200 fail. There are two reasons for that. The Lightning Network is still in an early state and people don't want to lose money. It was designed to handle mostly micro-transactions due to low transactions cost and their instant.


Just give it a few more months. Lightning Network Specification 1.1 is currently being written. I will write about it today in another thread.

In this article some big concerns are being raised


what do you think

https://cryptobriefing.com/whats-holding-back-the-lightning-network/

As I mentioned in my other thread, this problem has been addressed in the v0.5 release of LND. I have just edited the topic and included proper explanation. I have also included a few questions which were answered by me in this thread.

I have just added a few new questions and I am still looking for more. Don't be afraid to ask! The new ones are: Which wallet is the best one?, Do I have to run a full Bitcoin node?, How do I set up a Lightning Network node?, What happens if some nodes go temporarily offline?


Thanks for catching that! Fixed.

That makes sense, thanks for the clarification.

However, a workaround shouldn't be difficult: the client of the "customer" could simply save the "intention" of the transaction, and it would get carried out if the second node pops up before a timeout is reached. In this case, the route is decided only at the moment both nodes are online.

Yep, that sounds more logical. Unfortunately, that would provide incentives for hubs.

OK, I'll probably soon test an updated Eclair again and look how it's implemented there.

And regarding your response to Vigme86: I agree with a conservative block size policy, and I have some hopes that the sidechain concept isn't fully forgotten because it could serve as an excellent intermediate layer. We could then have the following structure:

Mainchain -> Sidechains/Pegged chains -> Channel factories/Superchannels -> "reloadable channels"

Suggested edit:

Lightning Network Risk Prevention Measures

FMyGdTk6iXFqfnSbvBtte

The Lightning Payment Layer 1 private key (cold storage) is generated offline, and the second layer private key is generated by using the wallet address as the brain wallet seed, and is cyclically calculated to the 100th layer. Use the last layer 100 public key as the public key for lightning payment. If the lightning private key is stolen, the layer 99 public key is broadcast in time to invalidate the 100th layer public key. It can prevent stolen 100 times.

Lightning channel establishment:
1. Sign the authorized private key with cold storage to authorize the lightning payment of the layer 100 public key, and all lightning payments do not use the original private key. Both the original private key and the lightning layer 1 private key are cold storage (offline) and are very secure.
2, in order to control the risk, you must set the daily payment limit of each party (such as: daily maximum limit: 60 yuan for one party, 70 yuan for B party). If the lightning private key of Party B is stolen, Party B will use cold storage for original private use. The key closes the channel on the chain, and at most, it will only lose the maximum payment of 70 yuan for the day.

In order to save the blockchain space, when the lightning channel is established, the blockchain only stores the hash value of the lightning-paid third-layer public key and the daily payment limit. The party applying to close the channel must provide the original information for the miner to verify the Lightning Payment Level 100 public key for both parties and the maximum daily payment limit.

Welcome to support BTC address: 18cZYPCppT5LbUjwDoqdjVGUP8jFoCPGcE

One of the problems is that even if the other party would come back online for a few seconds after 24 hours, the route might have changed so the transaction would not take place. The word "watching" was probably the worst one that I could have used. I was thinking of a service which would accept payments on behalf of someone (connection to both nodes would have to exist) and then send it to the destination node on demand.


I'm quite sure that locktime is being negotiated while you are trying to open a channel therefore it will vary for your each connection with the other node. Finding someone with the same channel policy might be a bit difficult.


I didn't write that we have to increase the block weight 30 times. There are plenty of things that can be done in the future before increasing the block weight, for example, implementing channel factories which allow users to create new Lightning Network channels from existing ones - no need to broadcast closing and opening transaction. I have changed the sentence you quoted in order to make it more neutral  

Very interesting and helpful topic, I would merit if I still had it.
From a user point of view sounds like LN it's a potential breaktrough innovation but still with some big issue to fix
(opening a channel 24/7 is clearly impossible, and it's not clear to me how you can manage negative balance once a user wants to close his channel).

Anyway there's a sentence that sounds really disappointing to me


It's one year since BCH fork, and after all that debate here's the conclusion  .
I quite disagree with it. Block weight should stay 1 MB forever. Makes no sense to me increasing it.