Bitcoin Scaling Solution Without Lightning Network... - page 6.

cfbtcman

member

Activity: 264

Merit: 16

Quote from: pooya87 on November 17, 2018, 12:37:31 AM

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.

DooMAD

legendary

Activity: 3934

Merit: 3190

Leave no FUD unchallenged

Quote from: cfbtcman on November 16, 2018, 10:25:57 PM

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?

bones261

legendary

Activity: 1806

Merit: 1828

A node already has the option to implement pruning to limit the data stored on the hard disk. The big hurdle to huge blocks is the bottlenecks found in relaying the blocks and verifying the transactions. I believe it takes a node at least 20 seconds to verify the transactions of a full block. I'm not certain how you can really split these duties and remain relatively trustless.

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: bones261 on November 17, 2018, 01:47:50 AM

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.

bones261

legendary

Activity: 1806

Merit: 1828

Quote from: pooya87 on November 16, 2018, 11:55:54 PM

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??? Huh

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. Cheesy

I'll keep the faith; I guess. Huh

Zin-Zang

member

Activity: 364

Merit: 13

Killing Lightning Network with a 51% Ignore attack

FYI:

You could just ignore BTC altogether and instead use Litecoin with LN instead. Wink

pooya87

legendary

Activity: 3472

Merit: 10611

Quote from: cfbtcman on November 17, 2018, 12:21:07 AM

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.

Quote

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.

Quote

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?

cfbtcman

member

Activity: 264

Merit: 16

Quote from: pooya87 on November 16, 2018, 11:55:54 PM

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

legendary

Activity: 3472

Merit: 10611

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

member

Activity: 264

Merit: 16

Quote from: ABCbits on November 16, 2018, 10:35:00 PM

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?

ABCbits

legendary

Activity: 2870

Merit: 7490

Crypto Swap Exchange

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

member

Activity: 264

Merit: 16

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?

Topic: Bitcoin Scaling Solution Without Lightning Network... - page 6. (Read 1727 times)