LN settling to main chain would cause bottleneck in blockchain anyways?

[bpwallace]

I can't remember where I read the article/post but it brought up many good points I hadn't thought of before.

Lets say we are processing all of visa txs on LN. There are 40 million merchants accepting LN payments and at the end of day just 1% of them settle to main chain. This would cause an additional 400,000 txs to the main chain, which we cannot do.

Is the argument that merchants wouldn't settle to main chain? To me it seems like we still need to get on-chain txs to at least 100/sec to have any chance at real world usability. (100 was just a rough calculation)

What am I missing in this scenario?

[1714154540]

1714154540

[1714154540]

1714154540

[1714154540]

1714154540

[1714154540]

1714154540

[1714154540]

1714154540

[1714154540]

1714154540

[mocacinno]

I can't remember where I read the article/post but it brought up many good points I hadn't thought of before.

Lets say we are processing all of visa txs on LN. There are 40 million merchants accepting LN payments and at the end of day just 1% of them settle to main chain. This would cause an additional 400,000 txs to the main chain, which we cannot do.

Is the argument that merchants wouldn't settle to main chain? To me it seems like we still need to get on-chain txs to at least 100/sec to have any chance at real world usability. (100 was just a rough calculation)

What am I missing in this scenario?

Sure, at the moment a block is limited to 1 Mb, excluding the witness data (in case of segwit wallets). At the moment, i estimate an average sw transaction to be around ~200 bytes, so the number of transactions/day could be
(1000000*6*24)/200 = 720.000 transactions per day (mind you, this is a very, very, very raw estimation i made without looking up references or completely thinking about all possible factors).
A lightning channel has to be opened and closed by an on-chain transaction, so if more than 360.000 channels are opened (and respectively closed) per day, all blocks could potentially be filled by opening and closing transactions.

However, if i open a channel, i do plan on creating more than 2 lightning transactions using this channel before i close it, otherwise i would have just used one or two on-chain transactions... So if everybody only used the LN (so all transactions in all blocks from now on were solely for the purpose of opening or closing channels) and all lightning channels were used to create/pay at least 3 lightning invoices, the overall throughput of the bitcoin network would increase by 50%.

PS: there is no need to have your closing transaction in the very next block. Lightning transactions are almost instant, and there is no need to close a channel after your lightning invoice got payed. If you wish to close your channel, you can do so whenever you want, but preferably you'd wait untill there was no more use for the channel.

A (simplified) scenario (using simplified terminology, and disregarding fees and stuff) like this one would be perfectly fine:
1) you find a local seller of dog food, he accepts BTC and has an LN node and is properly setup to generate lightning invoices
2) on the 1st of may you open a channel to this seller, the opening transaction has a value of 0.02 BTC
3) from now on, you use the channel to the seller to buy 0.0005 BTC of dog food from this seller every single day
4) on the 31st of may, your "side" of the channel has (0.02 - 31*0.0005 BTC) = 0.0045 BTC. The seller's "side" has 31*0.0005 BTC = 0.0155 BTC
5) at this point, you decide to switch sellers, and close the channel, the closing transaction funds your address with 0.0045 BTC, and the seller's address with 0.0155 BTC. A miminum fee is required, but there is no need for this closing transaction to be included in the next couple of blocks (unless either you or the dog food seller is in a hurry).

Without the LN: 31 transactions
With the LN: 2 transactions
Risk to the seller: neglectible, even when the channel was open for 31 days
Risk to you: neglectible
Sound like we saved on a lot of fees, and a lot less data was permanently stored on the blockchain

[1Referee]

Long term speaking, some level of scaling needs to happen on-chain in case we want Bitcoin to handle high volumes later on. Even if all merchant transactions are being processed through the second layer, on-chain scaling needs to happen one way or another. I however find it quite difficult to even imagine what would be needed in order to make Bitcoin scale properly.

People think it's just a matter of a few simple tweaks and that's it, but that's not how it works. Every minor adjustment can have major opposite effects on how the protocol functions. I can perfectly understand why the Core devs are pretty conservative with how they operate. One mistake can have a tremendous impact on Bitcoin, which is what you at all cost want to avoid.

Also, LN needs to prove itself as well. The real stress test happens when the mass gets involved. There are various sides to each story.

[BlakeMye]

Large numbers of bitcoin transaction are occurring by the help of block chain technology. But we the investors are think it is a easy tricks. In this transaction if one mistake will occur then create big problem.

[mocacinno]

Large numbers of bitcoin transaction are occurring by the help of block chain technology. But we the investors are think it is a easy tricks. In this transaction if one mistake will occur then create big problem.

I'm sorry, but i really fail to understand what you're trying to say here...
 
Blockchain transactions do not occur with the help of blockchain technology, blockchain technology is used to build a decentral ledger, in bitcoin's case this ledger is used to store transactions to avoid double spends and make sure the ledger is decentral, trusless and immutable. You can generate a transaction and broadcast it without blockchain technology, it's only when a miner decides to put this broadcasted transaction into the block he's currently trying to solve AND this miner actually succeeds in solving and broadcasting this block before an other miner broadcasts a valid block that a transaction becomes a permanent record in the blockchain.

Which investors trick who?

If you make a mistake in a transaction, broadcast the transaction and wait untill it's included in the blockchain, you can lose the value of the unspent outputs you used when creating this transaction. The network, however, does not care about wether or not you made a mistake. For the network: the transaction is either valid, in which case they put it in their mempool untill it gets mined or pruned.... Or the transaction is invalid in which case it gets rejected without any big problems being created.

[Tankdestroyer]

I however find it quite difficult to even imagine what would be needed in order to make Bitcoin scale properly.  

I'd say that it is still too early to worry about things like that. IMO, the community still got a year or more to make bitcoin scale properly to be able to handle the number all of visa's txs because it needs to be legalized more by other countries who still are not paying attention to it as of now(and I suspect that the least amount of time bitcoin needed to catch their attention is one year).

[franky1]

if hubs have many channels and users need to add more funds oor move their funds out of a channel into other channels because certain routes are empty. then yes this can cause bottle necks.

the other risk to btc is that devs are adding features that if users are not careful and unable to read/understand raw transactions, they can become victims of blackmailers, extorion and outright theft

did you know that due to LN dvs want transactions to NOT sign output(destination) part of a tx. so that the amounts going to the destination can be altered after signing to then be able to adjust.

Procedure for Hashtype SIGHASH_NONE

    The output of txCopy is set to a vector of zero size.
    All other inputs aside from the current input in txCopy have their nSequence index set to zero

Think of this as "sign none of the outputs-- I don't care where the bitcoins go."

devs pretend this is to allow a broadcaster to manipulat who pays the onchain fee. but the reality is that the broadcaster could knock funds going to person A to zero and increase the amount going to person B up.

they also want features to not have the specific input(utxo) signed.
https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki

Any participant can take a transaction and rewrite it by changing the hash reference to the previous output[utxo], without invalidating the signatures.

funnily decker puts a human warning that PEOPLE should not use this feature anywhere else.
but its like telling a kid not to grab a cookie.. suddenly its in the kids mind that grabbing a cookie is an option.....

in a LN system where the nodes are distributed and the sourcecode is open to be altered without peer review.. if this bip is added to the protocol. then there is no way of stopping people from playing around with tx's they want others to sign OFFCHAIN because while offchain there is no code based audit/peer review of node sourcecode of an LN counterparty. and when that tx is then broadcast onchain the blocks would see it as a valid tx

 thus able to add or remove an input without requiring extra signatures after editing a tx.
devs pretend its so users can add more funds any time they like. but the reality is it can be used to remove utxo's too thus person B can remove their stake and not spend their own funds while taking all of person A's

and with all the locktimes and chargebacks and just the requirement of needing a counterparty. its obvious unless your techy that thee people not checking raw tx data to know what and HOW the tx is created/formatted and signed. someone can lose out.

for something as simple as changing
1000000bytes, 20kblock sigops, 4ktx sigops
to
4000000bytes and 80k sigops. and 500tx sigops
which could have been done ages ago

they strangely avoided all of that and wnt with the serialisd buzzwording to cover up the legacy limitation of 1mb that still exists. and then added in new features that can literally rip people off if they are not manually checking what they are signing at code level

anyway... the main important thing to know is that LN is and never was intended to be a solution to bitcoin.. its a network of its own that will allow other currencies on it. this is the whole point of segwit. to allow better identification of transaction currency (bc1q.. LTC1q) while also adding in and then hiding who gets to sign, how many signatories a multisig truly has, as well as all th backdoor loop hole victim causing opcodes that most people cant see/understand unless able to read the technical raw tx data.

while other currencies wont have these loopholes and backdoors on LN and btc bottlenecks. it will inevitably end up with people prefering to exit LN by atomic swapping to a currency thats not BTC because the devs are actually screwing up btc... not solving its issues.

[johnabrar]

Well, many investors prefer that there should be scaling in on-chain. This is necessary for high volume transactions of Bitcoin in future. Besides, yes,we need the on-chain txs 100/s atleast for a better tomorrow.