What happens when network is split for prolonged time and reconnected?

[em3rgentOrdr]

Suppose that BitCoins are being widely used all across the globe.  Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network.  Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network.  Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.

Now after several years existing independently, what happens when the two networks are reconnected?

[1714042244]

1714042244

[1714042244]

1714042244

[1714042244]

1714042244

[1714042244]

1714042244

[Anonymous]

Suppose that BitCoins are being widely used all across the globe.  Suppose that all internet connections between two countries are blocked (eg China and US go to war) and people still engage in transactions inside each network.  Now all transactions within each network are broadcasted to all nodes inside its network, but not to the other network.  Within each network, the longest chain in each would be considered valid, and the BitCoin economy would continue to exist inside each network.

Now after several years existing independently, what happens when the two networks are reconnected?

If the US and China go to war you will have more things to worry about than bitcoins.

[kiba]

Now after several years existing independently, what happens when the two networks are reconnected?

Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).

[throughput]

Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).

For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.

Question: who can be that entity, whitepaper says there is not any central authority, at all ?

kiba what you say, that's impossible or whitepaper lies?

If the US and China go to war you will have more things to worry about than bitcoins.

Is it typical to ignore real threats here, by the way?

Now after several years existing independently, what happens when the two networks are reconnected?

[kiba]

Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).

For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.

Question: who can be that entity, whitepaper says there is not any central authority, at all ?

kiba what you say, that's impossible or whitepaper lies?

It does not require an entity to know what happen if the design of the bitcoin network didn't anticipated this kind of event. If it does happen anyway, than it may or may not be intended to deal with it.

[em3rgentOrdr]

Maybe they won't be reconnected. Instead, we will effectively have two currencies. This will lead to the creation of an Eastern-Western bitcoin currency exchange market(s).

For that to happen, someone should
a) notice what's happened
b) understand what's happened
c) make a decision on technically isolating two economies for ever
d) force that decision somehow.

Question: who can be that entity, whitepaper says there is not any central authority, at all ?

kiba what you say, that's impossible or whitepaper lies?

Thanks for addressing my concern!  I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly).  It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist.  I suppose each bitcoin community would properly fork the source code to do something along this line.

If the US and China go to war you will have more things to worry about than bitcoins.

I don't know...I actually think that BitCoin would become popular as a resistance currency in wartime.  The State likes to enact all sorts of totalitarian BS during war, such as massive government spending, massive inflation, collection of all scap or private metal, confiscation of private property.  Even FDR in the economic emergency during 1933 outlawed private ownership of gold.  But bit coin would be resistant to such measures, as long as the government doesn't shut down the internet, which I doubt they would do since it would seriously cripple the economy and thereby destroy the tax base (although, I forgot how stupid can be sometimes), or somehow outlaw cryptography by regular folk, institute a mega police force that can break into people's houses to inspect their hard drive, demand passwords at gunpoint, steal everyone's computer and network cables, shut down power, etc..

[kiba]

Thanks for addressing my concern!  I think you are right...I wrongly assumed that people are stupid enough to blindly reconnect the two bitcoin networks (at which point the more powerful network would wipe out all the bitcoins created in the weaker network and transactions performed in the weaker network, if I understand bitcoin correctly).  It seems the proper thing that the bitcoin community should do upon such a massive disconnect is to add some sortof marker to every block chain indicating which network it belongs to, so that upon reconnection, the two bitcoin currencies can coexist.  I suppose each bitcoin community would properly fork the source code to do something along this line.

It would seem to me it still warrant a bitcoin exchange market.

[bytemaster]

I think the bitcoin system need to be designed to allow parallel transaction block chains with periodic transfers between them.    At the very least you enable "division of labor" and allow the "little guys" to keep up with the data rates required under heavy transaction loads.   Failure to provide some means of breaking the chain and then transferring coins back and forth between chains at full value means that eventually only big players with low-latency high bandwidth connections will be able to handle the transaction volume.

[knightmb]

It is possible to run an experiment just to see what happens. It would take 4 separate clients though running at the same time (probably help to have 4 different PC to do this)

Basically, take a fresh install of 2 PC, have them only connect to each other and let them generate blocks starting at 1, build up some coin, transfer between the two in a few transactions, then shut them down. Do the same thing on 2 different PC, build some coin for longer (more blocks), transfer some coin around, shut them down. Then fire up all 4 at the same time and have all 4 connected to each other and see what happens when one pair had a longer block chain than another.

My guess is the longer block chain will win and the lesser of the pair would lose all of their history/coins.

So if this was on a much larger scale (east vs. west), then whoever had the longest block chain would win once the networks started to merge back together.

Thinking about that thought experiment, one could run their own internal micro-payment system for fun 

[throughput]

I think the bitcoin system need to be designed to allow parallel transaction block chains with periodic transfers between them. 

Double that.
Triple that.
That is not possible by current design.

But network splits are inevitable future.

Not every merchant will agree to lose his money due to a network split, which may sound
really abstract to him.
Those who will still agree will demand a means of determining, whether a network split is
in effect now, to limit their possible loses.

Is it at all possible to monitor Bitcoin for network splits?

[knightmb]

Is it at all possible to monitor Bitcoin for network splits?

Not easily because it would entail finding out what "blocks" everyone else has. Since everyone is working off the current chain, if you did find a client with "another" chain, it would either be silly short or hacker longer.

[knightmb]

I'm running an experiment to give everyone a more definitive answer.

I have two fresh PC each running the BitCoin client (new install, no blocks, transactions, etc) and they are only network to each other. I'm having them generate coin against each other.

I think that if such a large network split did happen, it would be from the client standpoint (basically someone would compile a client that uses a different bootstrap method, so in essence you would have a "new" bitcoin chain that would forever be separate from everyone else).

[throughput]

Is it at all possible to monitor Bitcoin for network splits?

Not easily because it would entail finding out what "blocks" everyone else has. Since everyone is working off the current chain, if you did find a client with "another" chain, it would either be silly short or hacker longer.

I, as a merchant, will only care about whether my network is a majority network,
so after a reconnect my transactions will be accepted.
So it will be enough for me to be able to monitor the current number of distinct nodes.
Put that into a graph and stop processing transactions if that number suddenly halves.
It may be a service on a web-server running a Bitcoin node.

But is there a way to monitor that number at all?
If not, it would be wise to add some feature to the standard, which will
allow to determine in real time what is the number of distinct nodes running.

[knightmb]

But is there a way to monitor that number at all?
If not, it would be wise to add some feature to the standard, which will
allow to determine in real time what is the number of distinct nodes running.

Maybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)

As of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now.

[throughput]

But is there a way to monitor that number at all?
If not, it would be wise to add some feature to the standard, which will
allow to determine in real time what is the number of distinct nodes running.

Maybe not official, but I compile my own BitCoind to run unlimited connections (well, in theory I set the limit for 65535)

As of now, I have about 7,100 connections going, so I would assume *at least* that many nodes are out there now.

But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not
connect to you by themselves. Still being connected to the network.

This is a task of counting distinct nodes in a graph. Too bad. 

[knightmb]

But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not
connect to you by themselves. Still being connected to the network.

This is a task of counting distinct nodes in a graph. Too bad. 

The connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading "generic" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program.

[throughput]

But there may be others, who have their connections limit in effect, so they refuse to accept your connections and do not
connect to you by themselves. Still being connected to the network.

This is a task of counting distinct nodes in a graph. Too bad. 

The connection limit is just a suggestion, you can connect more than 8 clients even without a custom compile. The limit was setup to prevent a home PC from making thousands of connections and overloading "generic" home routers that can't handle that kind of connection state table. Think of the 8 limit as more of a soft-limit for sanity reasons for the typical user of the program.

Yes, ofcourse, I meant, you may be disallowed to connect to some nodes by the nodes themselves because they already have
too much connections, so the actual number of active nodes may be larger.
Or how should I understand the connection limit? Is it only an outgoing connection limit?

By the way, I myself run two nodes on public addresses and two other behind a firewall.
The last two are only allowed to connect to first two, and not not the Internet.
AFAIK, it counts as being connected to the network, so they generate blocks.

[knightmb]

Yes, ofcourse, I meant, you may be disallowed to connect to some nodes by the nodes themselves because they already have
too much connections, so the actual number of active nodes may be larger.
Or how should I understand the connection limit? Is it only an outgoing connection limit?

By the way, I myself run two nodes on public addresses and two other behind a firewall.
The last two are only allowed to connect to first two, and not not the Internet.
AFAIK, it counts as being connected to the network, so they generate blocks.

Exactly why a good count would be difficult as it currently is setup. I could have hundreds of clients behind a node and the outside world (Internet) would never know from what I know about how everything works.

[omegadraconis]

I think the idea of "super nodes" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating. These losses may be small but, I don't know yet. I plan to compile a super node later on tonight and fire it up and the test network later on tonight. I will try and do some testing to see how the number of connections affects cpu and bandwidth usage.

Also I was thinking that if country A goes to war with country B both countries will still most likely maintain a connection to country C, D, E, and F which can maintain the network and prevent a split. If country A blocks all internet access and country B does not then Country A looses because, Country B still connects to C,D,E, and F; Therefor country A's block chain will be shorter. If Country A and B both block internet all together they both loose because C,D,E, and F have the longer block chain. IF A, B, C go to war with D,E,F and they block access to each other on the internet then we have two bit markets now.

I agree that if the world goes to hell in a hand basket a network split would be the least of our worries and it is probable that a split would not likely be due to war. I would think a network split is more likely to be caused by a country with an over zealous government repressing their own citizens via their national firewall. Another possibility would be a mass technical problem such as the rapid undersea cable cuts in 2008 (see Here or here) that cause some countries internet connection to slow to a crawl. The worst case scenario I can think of is that a large number of under sea cables or other link failures segment a large chunk of the worlds computer. The nodes outside the segment keep going like nothing happened and the same is true for the nodes in the segment. At some point we have the networks links fixed (would probably less then a week or so for another link to be established be it other land links come online or satellite links take over more bandwidth and a month at most for a more permanent fix.) I would guess that the network with the larger chunk of nodes would win out and the smaller segment would loose. The biggest problem would be that in this type of split there is not much time to try and work out a solution. Though it could be possible that in this situation if there were a super node or two in the segmented group it could still be able to make a connection to other super nodes and keep a split to a minimum.

[knightmb]

I think the idea of "super nodes" or hubs will help limit the possibility of a split. The more connected the network is the less the possibility of a split. I know not everyone can run a node that supports 7000+ connections but, if there were some highly connected super nodes running 1000 or so connections and these nodes could be inter-networked with each other this would allow for a stronger connection. Even if a node is at a connection limit and doesn't connect to the super node, it would be probable that one of the other nodes would be connected to a super node. The down side to running a super node is you spend more cpu time and bandwidth making connections and less cpu time generating. These losses may be small but, I don't know yet. I plan to compile a super node later on tonight and fire it up and the test network later on tonight. I will try and do some testing to see how the number of connections affects cpu and bandwidth usage.

I can already tell you, it has almost no impact on the CPU, it will shave off some khash/s, but the big difference is bandwidth and memory.

When running the program by itself (8 connection limit), you'll use between 16 and 28 MB of RAM for the program, 300MB a month for bandwidth (24/7 operation basically)

When you run *nearly* unlimited connections, the memory usage jumps up to about 128MB of RAM, bandwidth usage also jumps way up as well to where you are using 100MB in a day instead of a month.

Truthfully though, for a "super node" as you've now coined it  it's not really that hard spec wise for any server to handle, my old celeron server could easily handle this kind of load if it was shaved down to just a few thousand connections.