Topic: Subnetworking as a solution? (Read 1005 times)
I made a similar proposal a few weeks ago on the mailing list, and now I put it on the forum: https://bitcointalksearch.org/topic/scaling-bitcoin-with-subchains-1083345. The blockchains don't have to depend on the geographical region, but yes, you end up with children chains, and children of children chains. They would be validated by hashes made by the parent chains (parent always has the final say on which child block is correct in case of forks), and at most two sibling chains can participate in a transaction at once (to limit duplicate transactions).
If a subset of nodes is not 100% in sync with other subnets, would it make double spending easier? A potential scammer can connect to different child nodes in 2 different subnets with tor and broadcast double spends.
Spends from an address should be restricted to only one subnet. I.e addresses are divided into subnets much like how IP addresses are.
Does this not give a lot of centralization in the bitcoin network as opposed to a fully decentralized network? I think the subnets would be very powerful in this regard. If a subnet gets the authority to spend addresses, how do you prevent abuse?
I think it does
If a subset of nodes is not 100% in sync with other subnets, would it make double spending easier? A potential scammer can connect to different child nodes in 2 different subnets with tor and broadcast double spends.
Spends from an address should be restricted to only one subnet. I.e addresses are divided into subnets much like how IP addresses are.
Does this not give a lot of centralization in the bitcoin network as opposed to a fully decentralized network? I think the subnets would be very powerful in this regard. If a subnet gets the authority to spend addresses, how do you prevent abuse?
If a subset of nodes is not 100% in sync with other subnets, would it make double spending easier? A potential scammer can connect to different child nodes in 2 different subnets with tor and broadcast double spends.
Spends from an address should be restricted to only one subnet. I.e addresses are divided into subnets much like how IP addresses are.
If a subset of nodes is not 100% in sync with other subnets, would it make double spending easier? A potential scammer can connect to different child nodes in 2 different subnets with tor and broadcast double spends.
More options, less concentrated attention witch could lead to big problems. Hackers this days only look for opportunities such as this, if you make the system more disperse it will be more troublesome in the future!
I think this increases some problems (like block propagation) and raises order problems (would all the blockchains reach consensus? would people take advantage of locations with less transactions so they could broadcast with a smaller, or no fee at all?)
I'm not a tech pro, but this is what comes to mind
It will probably raise less problems just switching to 20mb blocks.
I'm not a tech pro, but this is what comes to mind
It will probably raise less problems just switching to 20mb blocks.
A potential solution to the block size debate is the division of the bitcoin network into subnets that feed into a main (backbone) network.
Thus the subnets will process only a subset of transactions (e.g. geographically local transactions) and then feed the results into the main network and hence the main blockchain. This would require for the subnets to have their own mini blockchains.
In this way the cost of hosting a (child) node would not be increased (unlike a block size increase) and the number of nodes will not be reduced for the whole network.
There would be a need to change the algorithm.
Has this solution been proposed by any of the developers?
Thus the subnets will process only a subset of transactions (e.g. geographically local transactions) and then feed the results into the main network and hence the main blockchain. This would require for the subnets to have their own mini blockchains.
In this way the cost of hosting a (child) node would not be increased (unlike a block size increase) and the number of nodes will not be reduced for the whole network.
There would be a need to change the algorithm.
Has this solution been proposed by any of the developers?
Jump to: