it's very true that LN is not a bitcoin network. it's interoperable with the bitcoin network, and that's what is important. this means it can be used to help scale bitcoin.
its not helping scale bitcoin though. its helping divert people away from the bitcoin network
its diluting away the utility of the bitcoin network
Plus I believe no one is saying that IT IS "a Bitcoin network", like franky1 insists. Although we do need Bitcoins to open channels, and use the Lightning Network.
first of all. you are quoted here saying something that SUBTLY IMPLIES that i insist it is a bitcoin network(should your chums take your words out of context). .. which is not the first time i seen you trying to make out that i am the one advocating stuff.. when infact i am doing the opposite.
secondly many people do say its part of bitcoin with the "layer" buzzword. i am simply informing people to clarify to them that LN is SEPARATE.
EG coinbase is not a bitcoin layer. its a separate service/company that accepts multiple coins
since the blockchain scales linearly, it can only be improved so much by optimizing things like transaction size. schnorr is one such method. but it provides very limited scale compared to things like LN.
blockchains dont scale linearly. bitcoins blockchain hard drive usage if all blocks were full would appear linear, because scaling is not happening. scaling would allow data/utility expansion to move away from a straight line. should real scaling occur onchain
oh and also. dont then say exponential like the old myth of "gigabytes by midnight".. scaling is not a zero or full only 2 options scenario
..
and also schnorr is not about helping scaling. infact its to try to avoid new bloated transaction features from reducing tx counts per block. thus not scaling up, but just trying to avoid reducing utility, while they add more bloated complex tx formats
Storage was never a big problem for on-chain scaling, bandwidth is.
the old myth of 'online games wont work. streaming live video wont work, because bandwidth'
maybe you should tell skype, applefactime, livestream, youtube, twitch, facebook messenger, and all other such services that deal with large amount of data. that they should not use their services as bandwidth is a problem(its not).
bitcoin uses far less bandwidth than online games and streaming media
pre millenion kodak had the ignorant mindset that digital media for photo storage cant scale..
home users that have bad internet suppliers dont need to be nods with 100 connections. they could set there node to only have a few connections, they would have a better experience that way.
EG its like someone taking a shower. the bandwidth myth is that people thing a shower has to be full pressure water supply or turn off the water supply.. because it will cost them alot on their water bill. they never thing to adjust the taps to just use less water while taking a shower
telling people that the future involves avoiding a shower and using water from a sink to flanel wash their privates is the future is not the right thing to be informing people
again because i know how this scripted propaganda is played out. its not a linear or exponential (server farm full on or nothing scenario). only two option debate.
there are multiple ways to scale bitcoin onchain without having to divert utility away from the network
as the misleading concept that scaling is full on or nothing is the same rhetoric that bankers done with gold in the 18th century 'its too heavy, lock up your gold with a trusted partner/service and use these promissory notes instead"
oh and dont rebuttal that blockchains couldnt scale due to the legacy linear sigops validation problem.(which still exists and remains unsolved even now)
solution was easy. dont let a block allow itself to be deemed full by having just 5 tx of sigop bloat.
reduce the maxtxsigops from being just a 5th of maxblocksigops
eg instead of maxblocksigops=80,000 maxtxsigops=maxblocksigops/5(16,000)
eg instead of maxblocksigops=80,000 maxtxsigops=maxblocksigops/1000(80)
then you will find people can still pay many others in one go without some malicious transactor filling a block with just 5 tx that take ages to verify under legacy conditions
and to pre-empt your rebuttal that segwit helps with this using witness scale factor to miss-count actual sigops of legacy by making legacy tx of say 4000 sigops appear as being 16,000 max ex sigops.
as i said it doesnt solve the issue of 5tx filling the block. infact the wishy wash code of misleading actual count by using witness scale factor makes it far easier to fill a block using just 4000 sigops
again solution to allow more transactions throughput per block can be solved by making maxtxsigops/1000 so that there is never a case where a block is deemed full with under 1000 tx included due to a "sigops attack"