Concerns regarding SegWit + Lightning Network?

[ir.hn]

What is so difficult to understand here?  Invalid blocks are not “in the blockchain”.  The only way to add a block to the blockchain, is to mine a valid block.  Those who produce invalid blocks “never actually have any say as to what makes it into the blockchain.”

Who can decide whether or not an invalid block makes it into the blockchain?  Who determines whether a block is valid or not?  Isn't it the miner who mines the next block?  They decided to mine on the last block so they say the last block was valid, no one else's say matters.  Then the only thing left is do is either the miners mine on that last persons block, or say it is invalid and remine the previous block.  No where in this process are non-mining nodes.  They are not part of the block confirmation process.

The problem with segwit is that the block will appear valid and can be validated in the blockchain without the signature being present.  This is the whole point of segwit, so that the signature is not needed in the blockchain.  In order to see if the signature is valid the miner would have to wait for the witness block before they start mining on the last block which takes extra time.

[1714724848]

1714724848

[1714724848]

1714724848

[1714724848]

1714724848

[nullius]

What is so difficult to understand here?  Invalid blocks are not “in the blockchain”.  The only way to add a block to the blockchain, is to mine a valid block.  Those who produce invalid blocks “never actually have any say as to what makes it into the blockchain.”

Who can decide whether or not an invalid block makes it into the blockchain?  Who determines whether a block is valid or not?  Isn't it the miner who mines the next block?  They decided to mine on the last block so they say the last block was valid, no one else's say matters.  Then the only thing left is do is either the miners mine on that last persons block, or say it is invalid and remine the previous block.  No where in this process are non-mining nodes.  They are not part of the block confirmation process.

The problem with segwit is that the block will appear valid and can be validated in the blockchain without the signature being present.  This is the whole point of segwit, so that the signature is not needed in the blockchain.  In order to see if the signature is valid the miner would have to wait for the witness block before they start mining on the last block which takes extra time.

“Who can decide whether or not an invalid block makes it into the blockchain?”  Full nodes, that’s who.  “They [full nodes] are not part of the block confirmation process.”  Wrong.  As has been explained to you numerous times in the past few days by several different people, full nodes validate blocks and decide which fully validated chain has the highest total proof-of-work.  Miners can never force full nodes to accept anything invalid.

By analogy, BCH miners could create 8MB blocks and try to entice Bitcoin nodes to accept them.  Could they force full nodes accept those blocks?  No:  Full nodes would reject those blocks, because they are invalid blocks.  A block missing witness data (signatures) would also be invalid.  A block containing invalid transactions is also invalid.

Contra what you say, in Segwit, there is no “witness block”.  Segwit witness data is included inside the same block as the rest of the transaction data.  Signatures are always present.  “This is the whole point of segwit, so that the signature is not needed in the blockchain.”  False.  You have not even the slightest idea of what Segwit is, or how Segwit works; you’re just spouting off nonsense which you evidently make up on the spot.

[ir.hn]

Miners can never force full nodes to accept anything invalid.

Right.  But can full nodes force miners to reject anything?  If not then what full nodes think is valid or not doesn't effect the blockchain.

Contra what you say, in Segwit, there is no “witness block”.  Segwit witness data is included inside the same block as the rest of the transaction data.  Signatures are always present.  “This is the whole point of segwit, so that the signature is not needed in the blockchain.”  False.  You have not even the slightest idea of what Segwit is, or how Segwit works; you’re just spouting off nonsense which you evidently make up on the spot.

If this is so then why not just hash the signatures into the transaction?  Then it would be the same as we have now yet it would be a block size increase to 4mb.  Segwit signatures are not hashed into the UTXO transaction and thus cannot be verified via traditional means.  As far as I understand segwit is done to save space in the UTXO.

[codewench]

Right.  But can full nodes force miners to reject anything?  If not then what full nodes think is valid or not doesn't effect the blockchain.

Full nodes can't force the miners to do anything. But full nodes (and their users) can reject anything the miners do.

In your scenario, the miners will be working away on their invalid blockchain, but the valid blockchain will stop growing. At that point all it takes in one miner doing CPU mining on an old Celeron to resume growing the valid blockchain. It may take several difficulty adjustment periods before the single miner can produce a block on schedule, but valid transactions will eventually resume. Meanwhile, the rogue miners will be unable to turn their BogusCoins into value.

[ir.hn]

Right.  But can full nodes force miners to reject anything?  If not then what full nodes think is valid or not doesn't effect the blockchain.

Full nodes can't force the miners to do anything. But full nodes (and their users) can reject anything the miners do.

In your scenario, the miners will be working away on their invalid blockchain, but the valid blockchain will stop growing. At that point all it takes in one miner doing CPU mining on an old Celeron to resume growing the valid blockchain. It may take several difficulty adjustment periods before the single miner can produce a block on schedule, but valid transactions will eventually resume. Meanwhile, the rogue miners will be unable to turn their BogusCoins into value.

One thing I have learned in the altcoin space is that value follows hashpower.  A coin with high hashpower will have a higher value on average, and as a coins hashpower increases, so does the value.  If the majority of Bitcoin miners start mining InvalidCoin fork, then that is the new Bitcoin.  Could a node point out that there was an invalid transaction and that miners should stop on their chain and restart on that old block?  Sure, but remember "One CPU one Vote", if the majority of miners just continue mining InvalidCoin, then the "CPU's" have spoken.

Forks happen all the time on altcoin chains and what it does is make it so the cartel is the only one who can mine and all other miners are out of luck.  The minority miners can't convince anyone that they are actually the ones mining the real altcoin.  Value follows hashpower.

[nullius]

Miners can never force full nodes to accept anything invalid.

Right.  But can full nodes force miners to reject anything?  If not then what full nodes think is valid or not doesn't effect the blockchain.

Miners are perfectly free to mine invalid chains, if they want.  As I’ve said elsewhere, they can mine chains of blocks filled with the output of /dev/random in lieu of transactions, if they want.  But those invalid chains will not exist to the Bitcoin network.  “What full nodes think is valid or not” absolutely does affect the blockchain:  Indeed, that determines what the blockchain is.

Right.  But can full nodes force miners to reject anything?  If not then what full nodes think is valid or not doesn't effect the blockchain.

Full nodes can't force the miners to do anything. But full nodes (and their users) can reject anything the miners do.

In your scenario, the miners will be working away on their invalid blockchain, but the valid blockchain will stop growing. At that point all it takes in one miner doing CPU mining on an old Celeron to resume growing the valid blockchain. It may take several difficulty adjustment periods before the single miner can produce a block on schedule, but valid transactions will eventually resume. Meanwhile, the rogue miners will be unable to turn their BogusCoins into value.

One thing I have learned in the altcoin space is that value follows hashpower.  A coin with high hashpower will have a higher value on average, and as a coins hashpower increases, so does the value.  If the majority of Bitcoin miners start mining InvalidCoin fork, then that is the new Bitcoin.  Could a node point out that there was an invalid transaction and that miners should stop on their chain and restart on that old block?  Sure, but remember "One CPU one Vote", if the majority of miners just continue mining InvalidCoin, then the "CPU's" have spoken.

Forks happen all the time on altcoin chains and what it does is make it so the cartel is the only one who can mine and all other miners are out of luck.  The minority miners can't convince anyone that they are actually the ones mining the real altcoin.  Value follows hashpower.

You have it precisely backwards:  Hashpower follows value.  In the altcoin space, I’ve been fascinated to watch as an ASIC-resistant, GPU-mined coin’s mining difficulty rises and falls immediately following fluctuation of the ratio of its value to the value of other GPU-mined coins.  Of course, many big mining farms have the switch set to occur automatically.

Bitcoin does not derive its value from mining hashpower.  Bitcoin’s value incentivizes and indeed, pays for hashpower.  As codewench says, if all the ASIC miners started churning out invalid blocks, Bitcoin could proceed with “an old Celeron”—but of course that would not happen, because miners want to make money.  Some miners such as Jihan (Bitmain) may have a long-term profit strategy driven by ulterior motives, and/or security exploits (substantially fixed by Segwit) which give them a profit advantage on a forkchain; and some may simply be fools, in the sense of bad businessmen.  But the rest will run to mine the coin with the highest value.  That is Bitcoin.  And to get their profits, the miners need their blocks to be accepted by full nodes—rejection by full nodes means no mining profits!  That’s one important part of what you keep missing.

More generally, you need to understand the purpose of mining.  I have repeatedly tried to explain that to you in these various different threads.  Look up Byzantine fault tolerance, the Byzantine generals problem, and the double-spend problem.  Start learning.

Contra what you say, in Segwit, there is no “witness block”.  Segwit witness data is included inside the same block as the rest of the transaction data.  Signatures are always present.  “This is the whole point of segwit, so that the signature is not needed in the blockchain.”  False.  You have not even the slightest idea of what Segwit is, or how Segwit works; you’re just spouting off nonsense which you evidently make up on the spot.

If this is so then why not just hash the signatures into the transaction?  Then it would be the same as we have now yet it would be a block size increase to 4mb.  Segwit signatures are not hashed into the UTXO transaction and thus cannot be verified via traditional means.  As far as I understand segwit is done to save space in the UTXO.

What you just said is such a long string of disconnected non sequitur that I don’t even know where to start.

The bird’s-eye overview of how Segwit actually works:  Segregated Witness transactions are serialized in such a manner that the “witness data” (public keys and signature) is dealt with separately from the input/output/script data, within the same block.  This permits witness data to be omitted in communications with old, non-upgraded nodes, and only with them.  Segwit nodes receive all transaction data, including signatures, within the same block.  None of this has anything to do with the UTXO set.

The principal purpose of segregating the witness data was to permit changing the blocksize without a hardfork.  Segwit doesn’t just change the blocksize limit:  It gets rid of the blocksize limit entirely.  Instead, Bitcoin now has a block weight limit of 4000000 bytes.  Transaction data in the old serialization format is weighted (much) more heavily; Segwit witness data is measured with much lighter “weight”, byte for byte.  The upshot is that old, non-upgraded nodes will continue seeing blocks with a maximum size of 1000000 bytes; whereas upgraded nodes can take advantage of larger blocks.  Instead of a hardfork which suddenly and totally breaks old nodes, we have a gradual transition which lets old nodes continue minimal function until their owners get around to upgrading.

That is the block capacity part of Segwit.  In my opinion, the most important parts of Segwit are that it also includes bugfixes for transaction malleability and the quadratic sighash scaling problem; and it includes a script versioning system, for forward-compatibility with future new features.  I’m not Litecoin user, but I do concur with what Charlie Lee said in favour of Segwit (as I just quoted in one of these other threads you started).  The block capacity upgrade was the smallest part of Segwit, so to speak.

Now unless you have something new to say, other than rehashing the same drastically incorrect bare assertions, or unless somebody else pipes up with something interesting, I will bow out of these threads for now so as to stop bumping them—and to not become this guy:

[Witrebel]

Bitcoin does not derive its value from mining hashpower.  Bitcoin’s value incentivizes and indeed, pays for hashpower.  As codewench says, if all the ASIC miners started churning out invalid blocks, Bitcoin could proceed with “an old Celeron”—but of course that would not happen, because miners want to make money.

This has always struck me as possibly the biggest realistic attack vector for the network, the lack of emergency difficulty adjustment.   The Celeron would work great, provided you get through 2016 or so blocks, but depending on how much hashpower you've lost, that could take a prohibitively long time?   Is the solution here pretty much "we can hardfork if the time ever comes"

[nullius]

Bitcoin does not derive its value from mining hashpower.  Bitcoin’s value incentivizes and indeed, pays for hashpower.  As codewench says, if all the ASIC miners started churning out invalid blocks, Bitcoin could proceed with “an old Celeron”—but of course that would not happen, because miners want to make money.

This has always struck me as possibly the biggest realistic attack vector for the network, the lack of emergency difficulty adjustment.   The Celeron would work great, provided you get through 2016 or so blocks, but depending on how much hashpower you've lost, that could take a prohibitively long time?   Is the solution here pretty much "we can hardfork if the time ever comes"

Wherefore ideas such as Malice Reactive Proof of Work Additions (MR POWA) (blogged, reblogged, discussed on this forum—theymos immediately pointed out one obvious problem).  I do not endorse that proposal; I think it’s interesting, but I have no desire to see collateral damage made of all the fine folks who invested their lives’ savings in SHA-256 hardware, and swore they would mine Bitcoin or nothing.

Thus far, Bitcoin has successfully stared down threats and active attempts to cause exactly what you describe.  Anti-Core/anti-Segwit/pro-BCH/2X/whatever watering holes have been perpetually filled with talk of “the flippening” and “killing off the legacy chain” (i.e. Bitcoin), amidst much bravado.  At one point just last month, there was a serious contest of hashpower accompanied by market manipulations which pumped-and-dumped BCH, whilst knocking down Bitcoin down 30% for all of a few days.  This was timed carefully, so that the desertion of malicious miners would hit right after a 2016th-block difficulty adjustment.  Bitcoin got kind of slow, as its hashpower plummeted; BCH supporters were jeering that Bitcoin would grind to a halt, predicting that hashpower would drop low enough that it would take months to reach the next difficulty adjustment.  That situation lasted for approximately 48 hours, until miners flocked back to where they could make the biggest profits.  The end of that battle was that Bitcoin’s hashpower stabilized, little guys who threw their money into BCH at its peak got wiped out—and Bitcoin’s exchange rate rebounded to a new all-time high within a week or so, thus giving miners all the more reason to stay with Bitcoin!

The more often Bitcoin faces such attacks, the worse it crushes its attackers; and thus, the more of a reputation it gains for being “anti-fragile” and a “honey badger” (or “money badger”).  From a public relations perspective, attempts at “flippening” away Bitcoin by draining its hashpower have made those who try such things look ridiculous.

The war isn’t over, of course; and I myself am worried about miner centralization as a matter of principle.  It is most worrisome that the world’s biggest vendor of SHA-256 ASICs is actively pro-BCH/anti-Bitcoin, and currently accepting payment in BCH instead of Bitcoin.  I want to see commodity SHA-256 ASICs sold cheaper than GPUs, and as readily available.  I think that’s probably the best solution, long-term.  Too bad I am not a hardware guy.

[marcelbit]

@ achow101: Thank you so much for your effort to cope for my questions! I very much appreciate that and have sent you a small donation. 

(Perhaps it will take quite long until the donation gets to you since I've set the fee to only 75 satoshi per bytes. My hardware wallet suggested a fee at approx. 600 s/byte which would have resultet in a much higher fee than the actual donation. By the way, at 60 s/byte I've got the error mesage "mempool min fee not met". I didn't know there is a minimum fee.)

A big thanks also to nullius for the very enlightening additions! 

By the way, I also run a Bitcoin full node on a VPS. 

Thank you for this very informative posts guys.

I wish you peaceful holidays.
Marcel

[Carlton Banks]

Who can decide whether or not an invalid block makes it into the blockchain?  Who determines whether a block is valid or not?  Isn't it the miner who mines the next block? 

After a miner mines an block, they send that block to other full nodes on the Bitcoin network. This includes miners and non-miners, there's no difference.

If the block breaks the rules, no other node will add it to their blockchain. The miner of a block can decide only on what their node accepts, not what everyone elses node accepts. Invalid blocks will be rejected


You're exploiting the way that decentralised networks are understood, and it's not very smart.

Every node has their own copy of the blockchain, there is no "the" blockchain. Bitcoin is designed to make all nodes agree on what the blockchain contains in the past, but the newest block is always in contention. So sure, a miner can add any total garbage non-conforming block to their own copy of the blockchain. And when that miner broadcasts non-compliant garbage, everyone else running the consensus rules will not add that to their version of the blockchain.

This is the beauty of the blockchain design, you're arguing as if it's still 2008 and you don't get it yet. Even the corporate and government mis-information services like Bloomberg or the BBC understand what you do not about how a blockchain works.

[nullius]

@ achow101: Thank you so much for your effort to cope for my questions! I very much appreciate that and have sent you a small donation. 

(Perhaps it will take quite long until the donation gets to you since I've set the fee to only 75 satoshi per bytes. My hardware wallet suggested a fee at approx. 600 s/byte which would have resultet in a much higher fee than the actual donation. By the way, at 60 s/byte I've got the error mesage "mempool min fee not met". I didn't know there is a minimum fee.)

A big thanks also to nullius for the very enlightening additions! 

By the way, I also run a Bitcoin full node on a VPS. 

Thank you for this very informative posts guys.

I wish you peaceful holidays.
Marcel

You’re welcome, and thanks for the kind words!  May I suggest you try running a node on your own hardware, in your physical possession.  Core has made great effort to keep requirements accessible; no big server or datacentre backbone connection is required.  Your keys, your hardware, your security, fully decentralized and in your control.  It all just fits together.

Peaceful holidays likewise.

Aside, the mempool minimum fee is a per-node rule, not a consensus rule.  (Of course, most will go with the default.)  That makes sense, because selection amongst consensus-valid transactions is in the discretion of miners; and:

There is no such thing as “the mempool” (and if there were, then we wouldn’t need miners).  Each and every node has a mempool [...]

Hmmm; compare and contrast the node’s view of data it has received without any attempt at Byzantine fault-tolerant ordering, and Satoshi’s decentralized BFT database in action:

Every node has their own copy of the blockchain, there is no "the" blockchain.

Excellent point, for obtaining a proper perspective in this particular discussion.

[...]

[...]

This is the beauty of the blockchain design, you're arguing as if it's still 2008 and you don't get it yet. Even the corporate and government mis-information services like Bloomberg or the BBC understand what you do not about how a blockchain works.

That’s because corporate and government mis-information services consist of misinformation professionals.  Also, disinformation professionals—a subtle distinction in the field of mass-scale lying.

[cellard]

In general, each user will have several open Lightning channels and that should all be handled by the client you are running. Even with several open channels, while each channel may not be able to make a single large purchase, it is possible for you to make a large payment by sending money through multiple channels.

While there may be several large hubs, it certainly does not introduce that much centralization. Hubs can't change the amount of money that you have and can't dictate anything that you do. If a hub is misbehaving, you can simply stop using them and use someone else or just not use LN.

The problem I see with the "just not use LN" argument, is that once Lightning network is widespread and we have channels all over the world filling flocks with all these microtransactions, the overall on-chain fee will be higher than ever, at some point it will be non-viable for most people to transact on-chain. For people using LN, it wouldn't matter, as their transactions will eventually go into a block mixed with the rest of LN transactions (btw, who sets the fee for an "LN-tx filled block"?) but for people that want to transact on-chain, it will be extremely expensive, unless im missing something here.

PS: Im not saying "make blocks bigger as soon as they get filled" and such nonsense are a solution, im just pointing out at how widespread LN usage could lead to unusable on-chain transactions.

[achow101]

The problem I see with the "just not use LN" argument, is that once Lightning network is widespread and we have channels all over the world filling flocks with all these microtransactions, the overall on-chain fee will be higher than ever, at some point it will be non-viable for most people to transact on-chain. For people using LN, it wouldn't matter, as their transactions will eventually go into a block mixed with the rest of LN transactions (btw, who sets the fee for an "LN-tx filled block"?) but for people that want to transact on-chain, it will be extremely expensive, unless im missing something here.

PS: Im not saying "make blocks bigger as soon as they get filled" and such nonsense are a solution, im just pointing out at how widespread LN usage could lead to unusable on-chain transactions.

What? No! That is not how LN works. There won't be "filling blocks with all these microtransactions" because the microtransactions are happening off chain. LN moves transactions off chain so there will be more block space for other transactions. Fees should be lower with LN, not higher.

[Witrebel]

What? No! That is not how LN works. There won't be "filling blocks with all these microtransactions" because the microtransactions are happening off chain. LN moves transactions off chain so there will be more block space for other transactions. Fees should be lower with LN, not higher.

During adoption, there will be a fee in the form of the on chain transaction to stake your coins and open a channel? So basically we are asking the userbase to endure a one time "adoption fee" in the name of lowering overall fees long term.  When lightning network is operational, and transactions are largely off chain, then the on chain demand is reduced creating the fee reduction.  That seems to be the biggest barrier to adoption, the requirement for "paying a fee to reduce fees". 

[achow101]

During adoption, there will be a fee in the form of the on chain transaction to stake your coins and open a channel? So basically we are asking the userbase to endure a one time "adoption fee" in the name of lowering overall fees long term.  When lightning network is operational, and transactions are largely off chain, then the on chain demand is reduced creating the fee reduction.  That seems to be the biggest barrier to adoption, the requirement for "paying a fee to reduce fees". 

Not everyone is going to suddenly start using LN at the same time. Some people will suck it up and be the first people to open a channel and pay higher fees. As their transactions move off chain, the fee will decrease, and more people will then join. That will happen so on and so forth; the fee will decrease gradually as more people use LN and more people will begin using LN as it becomes more widely accepted and the barrier to entry (i.e. the funding transaction's transaction fee) decreases.

[cellard]

The problem I see with the "just not use LN" argument, is that once Lightning network is widespread and we have channels all over the world filling flocks with all these microtransactions, the overall on-chain fee will be higher than ever, at some point it will be non-viable for most people to transact on-chain. For people using LN, it wouldn't matter, as their transactions will eventually go into a block mixed with the rest of LN transactions (btw, who sets the fee for an "LN-tx filled block"?) but for people that want to transact on-chain, it will be extremely expensive, unless im missing something here.

PS: Im not saying "make blocks bigger as soon as they get filled" and such nonsense are a solution, im just pointing out at how widespread LN usage could lead to unusable on-chain transactions.

What? No! That is not how LN works. There won't be "filling blocks with all these microtransactions" because the microtransactions are happening off chain. LN moves transactions off chain so there will be more block space for other transactions. Fees should be lower with LN, not higher.

No, I may not have been clear with my post.

I am obviously aware that LN transactions are happening off-chain, but then these off-chain transactions converge within a block and get settled blockchain. So what im claiming is: when LN gets widespread, the rate at which these blocks get filled with off-chain transactions will be faster.
Also, people opening and closing LN channels will lead to on-chain usage too.

Eventually I don't see how this wouldn't lead to higher fees for those using on-chain.

Sure, we'll have a period of lower fees once segwit + people using LN for smaller transactions kick in, but eventually the current block space wouldn't cut it for those wanting to transact on-chain.

How far are we from that? who knows. With the fake spam it's hard to evaluate actual usage. We will just need to wait and see how the mempool looks like with a widespread LN and segwit I guess.

[nullius]

What? No! That is not how LN works. There won't be "filling blocks with all these microtransactions" because the microtransactions are happening off chain. LN moves transactions off chain so there will be more block space for other transactions. Fees should be lower with LN, not higher.

No, I may not have been clear with my post.

I am obviously aware that LN transactions are happening off-chain, but then these off-chain transactions converge within a block and get settled blockchain. So what im claiming is: when LN gets widespread, the rate at which these blocks get filled with off-chain transactions will be faster.
Also, people opening and closing LN channels will lead to on-chain usage too.

LN transactions do not “converge within a block and get settled blockchain”.  No record of them ever reaches the blockchain.

The only LN use of the blockchain is channel maintenance transactions, “people opening and closing LN channels” as you said.

Imagine that you and I make an agreement to trade between each other, and track our trades in a private ledger.  We create an entry in a global public ledger, devoting funds to our private ledger transactions.  When we’re done and we want to settle accounts, we record our respective final balances from our private ledger in the global public ledger.  All else in the private ledger stays there, nowhere else.

Of course here, our “private ledger” is magical.  It provides each of us a unilateral recourse to force the current balances into the global ledger, in case of cheating; so there is no counterparty risk.

[savushkinTA]

You should do your own research because asking that directly in an open forum will only result in trolls swarming all over the place.

[nullius]

You should do your own research because asking that directly in an open forum will only result in trolls swarming all over the place.

Ouch.  I jumped into the middle, replying to a user who was making the same blatantly incorrect assertions about Segwit in many different threads simultaneously.  I somehow missed that this thread started with talk of “the flippening”, that link we’ve all seen, and blah blah blah about Blockstream.  Oops.  I should be more careful.

Well, OP here got useful replies; and he seems to have responded graciously enough.  For every troll, shill, and professional liar hawking a tall tale, there are n newbies being sincerely misled—for an uncomfortably large value of n.  Your advice to them is sound, savushkinTA; but how is a newbie to know that he’s tumbling down a rabbit hole, one wherein all the rabbits have been killed and eaten by poisonous snakes?

[cellard]

What? No! That is not how LN works. There won't be "filling blocks with all these microtransactions" because the microtransactions are happening off chain. LN moves transactions off chain so there will be more block space for other transactions. Fees should be lower with LN, not higher.

No, I may not have been clear with my post.

I am obviously aware that LN transactions are happening off-chain, but then these off-chain transactions converge within a block and get settled blockchain. So what im claiming is: when LN gets widespread, the rate at which these blocks get filled with off-chain transactions will be faster.
Also, people opening and closing LN channels will lead to on-chain usage too.

LN transactions do not “converge within a block and get settled blockchain”.  No record of them ever reaches the blockchain.

The only LN use of the blockchain is channel maintenance transactions, “people opening and closing LN channels” as you said.

Imagine that you and I make an agreement to trade between each other, and track our trades in a private ledger.  We create an entry in a global public ledger, devoting funds to our private ledger transactions.  When we’re done and we want to settle accounts, we record our respective final balances from our private ledger in the global public ledger.  All else in the private ledger stays there, nowhere else.

Of course here, our “private ledger” is magical.  It provides each of us a unilateral recourse to force the current balances into the global ledger, in case of cheating; so there is no counterparty risk.

Right, so the only on-chain activity that happens with LN is in the opening of a channel?

So I create a channel with 1 BTC, and now I can send instant cheap transactions out of that 1 BTC to any other open LN channel and none of that is ever recorded anywhere but it's still non gameable?

In any case, have simulation models of lightning network been performed to somehow predict what fees will be like once people all over the world are opening channels? like at what rate will people be opening channels? (from what I understand, closing a channel is irrelevant, on-chain transactions only happen when opening)

Let's say people load up $1000 bucks a month worth of BTC in a channel for the month to spend from... how do we know this will be viable and for how long?

What about spamming the LN? as in attackers opening and closing channels just like they do now to spam the network with regular spam.