I've pasted several ChatGPT answers here. You guys don't seem to like them, so you ignore them.
These were not related to my question but to some irrelevant topic. And you continue to evade the question, and any technical details.
They were absolutely relevant, and I've gone over (and over and over and over) technical details.
LN is indeed a bit of a bundling mechanism, but most transactions (nearly all of them) never need to see the chain. Why would you cheat if you're punished in nearly all cases, because all the "victim" needs is a Bitcoin client able to broadcast a transaction? The risk-reward profile is simply too bad for an attacker.
In the world of info security, "nearly" is also known as, "100% compromised".
But okay, fine, I'll use some of the LN nomenclature instead of talking in generalities about architectural trade-offs. I've been doing this a long time and tend to trust undeniable paradoxes and have thus learned that the details don't matter, but... what the heck...
Lighting works by
first making a transaction on the Bitcoin blockchain to transfer sats into a shared (two key) wallet.
Right off the bat, this is a non-starter for most transaction contexts, since most typical services on the Internet will not know ahead of time with whom they are transacting. Hence, in most applications, they will need to perform an on-chain transaction for every single new transaction. This is probably the first reason LN doesn't seriously compete with native digital currencies--because in all practicality, you need to perform an on-chain (read: slow/expensive) transaction for every interaction.
Hence, using Lightning without the Lightning Network is, for almost every application, a pointless waste of time and needless increased complexity and risk, aka you are much better using the Bitcoin chain directly.
Now, if you use LN, you have a different set of problems, and in all practicality you are going to be doing a lot of on-chain transactions in order to provide liquidity to the given destination. For starters, you need to take money out of your wallet and put it in a channel--and if you want it back, you need to close your channel, and when you close your channel, you need to make an on-chain transaction. And also, as we've discussed, LN breaks the religion of Bitcoin's decentralization since you are now absolutely dependent on a small number of well-connected servers.
Hence when you use Lightning with your own channel, or when LN doesn't facilitate the transaction (which can happen a LOT), you actually do DOUBLE the amount of on-chain transactions (open, transact, close).
Now, one could argue that LN solves this
as long as every single Bitcoin user uses LN--hence you would just keep all of your Bitcoin locked in your channel, and thus not available to spend on anything non-LN.
In other words, if the WHOLE WORLD was LN, and that's the way every single Bitcoin transaction occurred, then you would probably see consistently lower transaction latency, but then there wouldn't be any reason to have the Bitcoin chain itself.
So YES, I absolutely understand how Lighting and LN works, and NO, it doesn't create magic that gets you around universal trade-offs. Centralized=fast, decentralized=slow. That's the law of the land.
