Bitcoin Scaling Solution Without Lightning Network...

[cfbtcman]

Today i read a tweet from Roger Ver that says bitcoin cant scale, LN dont work, Craig Wright says the same...

What about this:

 - Adjust actual Bitcoin blocksize for more MB (like BCH done)
 - Dinamically Split blocksize data in many parts like BTC Nodes Type A, B, C, etc (related to the number of total nodes running)

Example:

If we double the blocksize, we double the Type of nodes:

More nodes = more split types = bigger blocksize

This way we could save a lot of diskspace in nodes network, its sufficient that in a group of 1000 nodes, 500 save backup of 50% of the data (Type A node) and the other 50% can save backup of the other 50% of the data (Type B node), its a waste of space all the nodes in the network save all information repeated thousands of times.

Then each node Type A can "ask" to other node Type B the information is trying to find and vice-versa and gets the information anyway dont wasting so much space and solving the problems of centralized big block sizes data full nodes that no common mortal can manage like will happen in BCH with the use of big blocksize like BCHSV going to 128MB and planning keep scaling.

What you guys think about this?

[1715458968]

1715458968

[1715458968]

1715458968

[1715458968]

1715458968

[1715458968]

1715458968

[1715458968]

1715458968

[ABCbits]

This has been discussed many times and unfortunately, majority of Bitcoiner would disagree since increasing block size would increase the cost of running full nodes.
Split block data to many different nodes type is called Sharding and already proposed many times such as BlockReduce: Scaling Blockchain to human commerce
Besides, IMO sharding open lots of attack vector, increase development complexity and requiring more trust.

Additionally, LN help bitcoin scaling a lot, even though it's not perfect solution. Those who said that clearly don't understand how LN works and it's potential.
Lots of cryptocurrency including Ethereum are preparing 2nd-layer/off-chain as scaling solution because they know it's good scaling solution.

[cfbtcman]

This has been discussed many times and unfortunately, majority of Bitcoiner would disagree since increasing block size would increase the cost of running full nodes.
Split block data to many different nodes type is called Sharding and already proposed many times such as BlockReduce: Scaling Blockchain to human commerce
Besides, IMO sharding open lots of attack vector, increase development complexity and requiring more trust.

Additionally, LN help bitcoin scaling a lot, even though it's not perfect solution. Those who said that clearly don't understand how LN works and it's potential.
Lots of cryptocurrency including Ethereum are preparing 2nd-layer/off-chain as scaling solution because they know it's good scaling solution.

This idea dont require to upgrade blocksize, you can split nodes even with 2MB block, you could save a lot of space in nodes and reduce the cost of running full nodes, but, if you upgrade blocksize and at same time split the nodes in a way like dinamically P2P data, the cost of running nodes will be the same as before.

Even with LN there will be a huge of data space wasted in all the nodes repeating informations and a pain in the ass to install and run a full node.

If today there is 9000 nodes and if tomorrow another 9000 are added to network, dont make sense to repeat the information so many times, its a waste of space.

Im not 100% inside how LN works, but what happens if i switch off my LN node with all the channels inside forever, there is loss of bitcoins or not?

[pooya87]

the problem with increasing block size as the only solution for scaling is that no matter how much you increase it, it will not be enough for a global payment system which has to process a lot of transactions per second.

you will eventually need a solution that doesn't need block space for increasing availability. and that is the second layer solution like lightning network.

[cfbtcman]

the problem with increasing block size as the only solution for scaling is that no matter how much you increase it, it will not be enough for a global payment system which has to process a lot of transactions per second.

you will eventually need a solution that doesn't need block space for increasing availability. and that is the second layer solution like lightning network.

I understand your point of view, but i think if all the world uses LN the 2MB blocksize would not be sufficient to do the ONCHAIN transactions the people would want to do from blockchain to off-chain and vice-versa, so, block size needs to upgrade sooner or later, it would have been much better for everyone  if it was done without BTC/BCH split, LN can run over BCH too, so...

But i have a new idea, my purpose can be implemented without changing the block size, only to save data space in nodes and i think it can be possible to apply without hardforking, for example, we can create a new version node that stays 100% compatible with actual core and splits/communicates with the new node types to save disk space and act as normal node to comunicate with actual nodes.

That would be something very nice!

Some expert could help to implement it?

[pooya87]

I understand your point of view, but i think if all the world uses LN the 2MB blocksize would not be sufficient to do the ONCHAIN transactions the people would want to do from blockchain to off-chain and vice-versa, so, block size needs to upgrade sooner or later,

i completely agree! and i think everyone already knows that LN relies on on-chain scaling. it is called second layer for a reason, it is a layer that comes on another layer which needs to be functioning well.

it would have been much better for everyone  if it was done without BTC/BCH split, LN can run over BCH too, so...

that fork-off had nothing to do with scaling in my opinion, it was more like an attempt to take over and make money. not to mention that the whole motto of BCH is that the only way for scaling is on-chain scaling. so no, LN or any other second layer solution name it may be called will not "run over BCH" ever.

500 save backup of 50% of the data (Type A node) and the other 50% can save backup of the other 50% of the data (Type B node)

so lets say there is a transaction Tx1 and it is in the other half of the "data" in node Type B. and say i run node Type A. if someone pays me by spending Tx1, i do not have it in my database (blockchain) so how can i know it is a valid translation? am i supposed to assume that it is valid on faith?! or am i supposed to connect to another node and ask if the transaction is valid and then trust that other node to tell me the truth? how would you prevent fraud?

[bones261]

the problem with increasing block size as the only solution for scaling is that no matter how much you increase it, it will not be enough for a global payment system which has to process a lot of transactions per second.

you will eventually need a solution that doesn't need block space for increasing availability. and that is the second layer solution like lightning network.

That's not entirely accurate. 10GB blocks would be sufficient to scale on the level of Visa. However, many nodes would find it hard or impossible to keep up with that kind of capacity. However, in a decade or so, handling that capacity will probably be trivial. The LN network definitely will be less resource intensive. Unfortunately, I do not personally trust the LN in its current state. I find it particularly troubling that I could end up closing a channel in an earlier state due to a system issue on my end. Then end up getting penalized harshly like I was trying to scam someone.

Edit: OMG, just did a little more research and found this gem. https://bitcoin.stackexchange.com/questions/58124/how-do-i-restore-a-lightning-node-with-active-channels-that-has-crashed-causing
Really? If my node crashes I can loose all of my funds???   That's even worse than my first concern. How long has this been in development? It appears that LN developers have a long way to go before than can make this pig fly.   I'll keep the faith; I guess.  

[pooya87]

That's not entirely accurate. 10GB blocks would be sufficient to scale on the level of Visa.

no it won't be enough because you can't spam VISA network but you can spam bitcoin blocks and fill them up.
besides when it comes to block size it is not just about having more space, you have to consider that you have to download, verify and store 10GB of transaction data every 10 minutes on average and also upload even more depending on how many nodes you connect to and how much you want to contribute.
ask yourself this, would you be willing to run or capable of running a full node that requires 1.44 TB disk space per day, an internet speed of at least 20 Mbps and an internet cap of above 3 TB per day? that is 43 TB per month. can your hardware (CPU, RAM) handle verification of that much data.

[DooMAD]

its sufficient that in a group of 1000 nodes, 500 save backup of 50% of the data (Type A node) and the other 50% can save backup of the other 50% of the data (Type B node), its a waste of space all the nodes in the network save all information repeated thousands of times.

Then each node Type A can "ask" to other node Type B the information is trying to find and vice-versa and gets the information anyway

Bitcoin was designed to be trustless.  The idea of running a node is that you can validate and verify every single transaction yourself.  If you run a Type A node, you would have to trust the Type B nodes to do half of the validation for you.  If you're going to do that, why not just trust Visa and forget all about Bitcoin?

[cfbtcman]

so lets say there is a transaction Tx1 and it is in the other half of the "data" in node Type B. and say i run node Type A. if someone pays me by spending Tx1, i do not have it in my database (blockchain) so how can i know it is a valid translation? am i supposed to assume that it is valid on faith?! or am i supposed to connect to another node and ask if the transaction is valid and then trust that other node to tell me the truth? how would you prevent fraud?

We ask the other Type B node for the other part of data and we check it, there will be houndred or thousands of nodes Type A and Type B, we could check that agains more then a only one node Type B, but think about a pair of nodes Type A and Type B as a full node, they connect together to have 100% of block data and that can be checksumed and verified, is like reading from our own disk in another cluster.

How many more nodes we have more splits we can do and if my Type A node saves 2MB of block information and your Type B saves other 2MB and Type C another 2MB we have 6MB blocks representing only 2MB in each Type node.

[odolvlobo]

We ask the other Type B node for the other part of data and we check it, ...

If A nodes must also download B blocks and B nodes must also download A blocks, then you have accomplished nothing by splitting them.

[DooMAD]

We ask the other Type B node for the other part of data and we check it, ...

If A nodes must also download B blocks and B nodes must also download A blocks, then you have accomplished nothing by splitting them.

I assumed it was meant as a partial SPV setup.  Each type of node would be 50% SPV.  But yeah, it's not something that most users would be interested in pursuing as a concept.

[cfbtcman]

We ask the other Type B node for the other part of data and we check it, ...

If A nodes must also download B blocks and B nodes must also download A blocks, then you have accomplished nothing by splitting them.

I assumed it was meant as a partial SPV setup.  Each type of node would be 50% SPV.  But yeah, it's not something that most users would be interested in pursuing as a concept.

Yeah, something like that, we will ask only the data of the blocks we need and we can test is integrity by checksum or simply by asking the same information to other Type B node randomly, if the result is the same for 2, 3 or 4 other nodes that proves integrity.

I cant see other way of shrinking blockchain sizes and this technique is like P2P file sharing, each seed dont need to have all file since there would be sufficient trusted seeds in the network with some % of the file that alltogether have whole information.

Its genius, i am Satoshi 

[buwaytress]

We ask the other Type B node for the other part of data and we check it, ...

If A nodes must also download B blocks and B nodes must also download A blocks, then you have accomplished nothing by splitting them.

I assumed it was meant as a partial SPV setup.  Each type of node would be 50% SPV.  But yeah, it's not something that most users would be interested in pursuing as a concept.

Yeah, something like that, we will ask only the data of the blocks we need and we can test is integrity by checksum or simply by asking the same information to other Type B node randomly, if the result is the same for 2, 3 or 4 other nodes that proves integrity.

I cant see other way of shrinking blockchain sizes and this technique is like P2P file sharing, each seed dont need to have all file since there would be sufficient trusted seeds in the network with some % of the file that alltogether have whole information.

Its genius, i am Satoshi 

Doesn't make sense to me, if the result is the same for 4 nodes but only for particular blocks, that proves only that these nodes share the same on those particular blocks, but unless your node has verified every block once, there's no way to prove integrity by this random checking.

And besides, in P2P file sharing, a seed technically is a peer with 100% of the files. You're not seeding until you have the full file, anything less than 100% just makes you a peer

Pruning already works for size concern also?

[cfbtcman]

We ask the other Type B node for the other part of data and we check it, ...

If A nodes must also download B blocks and B nodes must also download A blocks, then you have accomplished nothing by splitting them.

I assumed it was meant as a partial SPV setup.  Each type of node would be 50% SPV.  But yeah, it's not something that most users would be interested in pursuing as a concept.

Yeah, something like that, we will ask only the data of the blocks we need and we can test is integrity by checksum or simply by asking the same information to other Type B node randomly, if the result is the same for 2, 3 or 4 other nodes that proves integrity.

I cant see other way of shrinking blockchain sizes and this technique is like P2P file sharing, each seed dont need to have all file since there would be sufficient trusted seeds in the network with some % of the file that alltogether have whole information.

Its genius, i am Satoshi  

Doesn't make sense to me, if the result is the same for 4 nodes but only for particular blocks, that proves only that these nodes share the same on those particular blocks, but unless your node has verified every block once, there's no way to prove integrity by this random checking.

And besides, in P2P file sharing, a seed technically is a peer with 100% of the files. You're not seeding until you have the full file, anything less than 100% just makes you a peer

Pruning already works for size concern also?

That particular blocks are the blocks that contain information you are trying to find like the movements for specific address transactions.

4 Types of nodes is not static thing, as the block size increase the number of splited parts increase too, we can have Type A,B,C,D,E,F and so on to keep the size of each block data in only 2MB for each node type.

Each Type of node would have 100% of his 50% so could be a seed, but if you want you can call it peer.

Look this simple logic, if you have 1 million nodes this moment, you think it would be logic to have 1 million of full nodes running?
For me that would be a complete waste of resources and for sure more safety to put some node in the moon!

Its like storjcoin service, for sure they calculate a safety limit of backups around all the world to have redundance and dont have more backups than the reasonable.

About validation/verification, i think could be done a way to each Type of node validates/verifies his part of data.

[bones261]

That's not entirely accurate. 10GB blocks would be sufficient to scale on the level of Visa.

no it won't be enough because you can't spam VISA network but you can spam bitcoin blocks and fill them up.
besides when it comes to block size it is not just about having more space, you have to consider that you have to download, verify and store 10GB of transaction data every 10 minutes on average and also upload even more depending on how many nodes you connect to and how much you want to contribute.
ask yourself this, would you be willing to run or capable of running a full node that requires 1.44 TB disk space per day, an internet speed of at least 20 Mbps and an internet cap of above 3 TB per day? that is 43 TB per month. can your hardware (CPU, RAM) handle verification of that much data.

     First off, it would be nice if you quoted enough of my text to keep it in context...

That's not entirely accurate. 10GB blocks would be sufficient to scale on the level of Visa. However, many nodes would find it hard or impossible to keep up with that kind of capacity. However, in a decade or so, handling that capacity will probably be trivial.

     I've already acknowledged this isn't practical, right now. However, unless technology has somehow reached it's limits, it may be feasible in a decade or so. Also, in order to combat "spam," miners already have the option to not include transactions below a certain fee. They can make it very expensive for someone to try and spam the network. Also, with bigger blocks, it probably won't be worth the waste of resources for a miner to attempt to drive up the fee market by including spam in their blocks.
    Furthermore, in another thread, Greg Maxwell himself has acknowledged that a pruned node is a full node. There is really no need for every single full node to also store the entire blockchain, permanently. There are sufficient entities out there like exchanges, large pools, and hardware wallet providers, who would probably want to store the entire blockchain. I think the number of nodes that would run "archival" nodes would be of sufficient number to have the network remain decentralized.   
   I also acknowledge in my original post that a second layer solution will always end up using less resources. However, the current LN carries large risks of someone losing their funds due to either system errors or human error. I'm certainly not going to hang my hat on the LN until the developers and network itself can show results that are acceptable. Right now, I wouldn't store 1 sat in a channel on the Lightning Network. The risk of losing funds is just too high.

[cellard]

The main problem is that most of these scaling solutions that are being proposed will first require a hardfork. This means we'll have the drama of 2 competing bitcoins trying to claim that they are the real one (see the BCash ABC vs BCash SV ongoing war right now). This will not end well. Without consensus we will just end up with 2 bitcoins which are in sum of lesser value than before the hardfork happened.

Most bitcoin whales don't support any of the proposed scaling solutions so far so your scaling fork will end up dumped by tons of coins.

[bones261]

The main problem is that most of these scaling solutions that are being proposed will first require a hardfork. This means we'll have the drama of 2 competing bitcoins trying to claim that they are the real one (see the BCash ABC vs BCash SV ongoing war right now). This will not end well. Without consensus we will just end up with 2 bitcoins which are in sum of lesser value than before the hardfork happened.

Most bitcoin whales don't support any of the proposed scaling solutions so far so your scaling fork will end up dumped by tons of coins.

     Unlike, BCH, the BTC network already has consensus mechanisms in place that they are willing to use in order to ensure the vast majority of the network is on the same page before proceeding. As demonstrated by the UASF, we can also implement ways to ensure the miners can be persuaded to go along with the wishes of the non-mining users. If someone doesn't want to wait for a high consensus in order to implement their "improvements," they are free to go fork off. That's why we already have hundreds of alt coins right now. As I have already acknowledged, the "bigger block" solution probably won't be practical for at least a decade or so. I have also acknowledged that the second layer solution would probably end up being more efficient with the resources. However, it is nice to know that there is a plan "B" to the scaling solution, just in case the problems with the LN cannot be overcome.

[ABCbits]

     Unlike, BCH, the BTC network already has consensus mechanisms in place that they are willing to use in order to ensure the vast majority of the network is on the same page before proceeding. As demonstrated by the UASF, we can also implement ways to ensure the miners can be persuaded to go along with the wishes of the non-mining users. If someone doesn't want to wait for a high consensus in order to implement their "improvements," they are free to go fork off. That's why we already have hundreds of alt coins right now. As I have already acknowledged, the "bigger block" solution probably won't be practical for at least a decade or so. I have also acknowledged that the second layer solution would probably end up being more efficient with the resources. However, it is nice to know that there is a plan "B" to the scaling solution, just in case the problems with the LN cannot be overcome.

Looks like no one remember about transaction compression (reduce transaction size). This is similar scenario with internet scaling in past where people only focus on increasing bandwidth rather than compress the content and compression format such as MP3 solve many problem (including internet scaling a bit).

IMO, bitcoin need all of it (n-layer network, higher block size limit and lower transaction size) to be able to scale without lots of security/decentralization trade-off.

[cellard]

The main problem is that most of these scaling solutions that are being proposed will first require a hardfork. This means we'll have the drama of 2 competing bitcoins trying to claim that they are the real one (see the BCash ABC vs BCash SV ongoing war right now). This will not end well. Without consensus we will just end up with 2 bitcoins which are in sum of lesser value than before the hardfork happened.

Most bitcoin whales don't support any of the proposed scaling solutions so far so your scaling fork will end up dumped by tons of coins.

     Unlike, BCH, the BTC network already has consensus mechanisms in place that they are willing to use in order to ensure the vast majority of the network is on the same page before proceeding. As demonstrated by the UASF, we can also implement ways to ensure the miners can be persuaded to go along with the wishes of the non-mining users. If someone doesn't want to wait for a high consensus in order to implement their "improvements," they are free to go fork off. That's why we already have hundreds of alt coins right now. As I have already acknowledged, the "bigger block" solution probably won't be practical for at least a decade or so. I have also acknowledged that the second layer solution would probably end up being more efficient with the resources. However, it is nice to know that there is a plan "B" to the scaling solution, just in case the problems with the LN cannot be overcome.

You can't really know if "the vast majority of the network" is on the same page or not until the D day actually comes. We have already seen miners voting supposed "intention" to support something with their hashrate, then when the day come some of then backpeddle. You would also need all exchanges on board. And ultimately you would need all whales on board, and many of them may not bother to say their opinion at all, then the day of the fork comes and you see an huge dump on your forked coin.

You basically need 100% consensus for a hardfork to be a success and not end up with 2 coins, and I don't see how this is even possible ever when a project gets as big as Bitcoin is (I mean it's still small in the grand scheme of things, but open source software development/network effect wise, it's big enough to not be able to ever hardfork seamlessly again. Maybe im wrong and there is a consensus in the future for a hardfork, but again I don't see how.