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

View Satoshi only

External link

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?
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. Sad



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).
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?

Quote
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?
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.
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. Sad

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

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.
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.
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  Grin
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?
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'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).
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.
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 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.  Sad
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.  Sad
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.
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.  Sad
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.
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.
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.
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  Wink 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.
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.  

This is interesting to me. What is most robust?

1000 nodes all with 9 connections

1000 nodes with 8 connections and one with 1000 connections

1000 nodes with 8 connections and ten with 100 connections

If you only connect with nodes 'near' your node then having only a few seems like a problem. If it's totally distributed then I think having the connections distributed would be better, but I really don't know.

Another thing to consider is how huge the profit opportunity will be if the network starts to get fractured. Everyone will want their transactions to get put in the next block for sure before an actual split and the fee will get bid up, this will give nodes incentive to make sure they can stay connected to those at risk and collect their fees. And thereby the network will not get split. I mean if a government ties down traffic they might actually run the nodes themselves for profit or some corrupt official who knows how to get away with it (n/m, no corruption in governments).
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.  

This is interesting to me. What is most robust?

1000 nodes all with 9 connections

1000 nodes with 8 connections and one with 1000 connections

1000 nodes with 8 connections and ten with 100 connections

If you only connect with nodes 'near' your node then having only a few seems like a problem. If it's totally distributed then I think having the connections distributed would be better, but I really don't know.

Another thing to consider is how huge the profit opportunity will be if the network starts to get fractured. Everyone will want their transactions to get put in the next block for sure before an actual split and the fee will get bid up, this will give nodes incentive to make sure they can stay connected to those at risk and collect their fees. And thereby the network will not get split. I mean if a government ties down traffic they might actually run the nodes themselves for profit or some corrupt official who knows how to get away with it (n/m, no corruption in governments).
I would say everyone connected to everyone (first option) because the one big node that has 1,000 other clients connected through it is great for redundancy, but also gives a good central point of attack. It's easier to attack a single node than to try and attack them all.
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. Sad

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..
Quote
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..
They can do all those things now......the only real thing stopping them is bad pr - hence banning you filming bureaucrats now that so many are being shown for what they are Smiley
I have a definitive answer for you all.

I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the "outside" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.

So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.
I have a definitive answer for you all.

Woot! Real facts! Nice!

Cool time machine thread too. Nice analysis!
I have a definitive answer for you all.

I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the "outside" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.

So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.

Cool. I guess you aren't seeing the transactions being redone because the accounts had no valid coins at all, right?
I have a definitive answer for you all.

I built a test network on 5 computers, each running the client stock (fresh install) and had them all network to each other. They generated blocks all day (it's easy when the difficulty is 1.000), and after some transactions between them all (built up to 50 blocks doing this), I then connected them back to the "outside" world and as soon as they got in sync with the network, all the generated coin and transactions were wiped out and replaced by what is current on the network now.

So to answer your question, if the network is split and merges days/weeks/years later, whoever has the longest block chain (most CPU time) will win and the previous block chain will be wiped.

So, I suggest not to concentrate heavily on preventing the network split, since that is inevitable event in the life of Internet,
but to invent some method to monitor connected computing power, to allow those, who bother, to stop processing transactions,
until the network's majority reconnects back.

Perhaps that would not be a realtime method, but a reasonable and fixed delay will still be accepted.
I'm sure, GUI client or daemon should inform you about total computing power, but how can it be computed?
Difficulty? It is too slowly updated.
What is your variants?
If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.

Imagine a cable cut, or series of cable cuts that isolated a block of countries.

- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection

These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.

Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.

Imagine a cable cut, or series of cable cuts that isolated a block of countries.

- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection

These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.

Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?
Satoshi posted about this concern:
http://bitcointalk.org/index.php?topic=241.msg2071#msg2071

Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?

You think people would fail to notice an entire ISP/country/continent falling off the Internet?
Satoshi posted about this concern:
http://bitcointalk.org/index.php?topic=241.msg2071#msg2071

Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?

You think people would fail to notice an entire ISP/country/continent falling off the Internet?

Why do you think, that what you describe will be the only reason for a Bitcoin network split?
And if some people will know that a continent is disconnected, then why all others will be as informed?
And even if everyone will know, that some amount of Internet is disconnected from the rest, then
how would they decide whether that is a good reason to stop processing (and sending) transactions?
ISP disconnectivity is not a rarity today, single misconfiguration may shutdown routing for a whole AS.
Will that be enough reason to stop processing transactions or not?
The same with a country and continent.

The question is not wheter there exists some parts of Internet or Bitcoin network, that will reconnect later.
You may always answer YES here, at every moment they exists. My phone loses signal very often, for example.

The actual question is
Quote
Whether I am connected with a network, that will be a majority of nodes on reconnect, or not?

It is not possible to give a definitive answer about future, but you may estimate that almost accurately based on the size
of the network before the split and the size of the network after the split.
If your network is not going to be a majority later, then it is safer to use another payment method, I suppose.
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..
They can do all those things now......the only real thing stopping them is bad pr - hence banning you filming bureaucrats now that so many are being shown for what they are Smiley

Sad

I suppose you are right, unfortunately: They can do all those things now...the only real thing stopping them is bad pr.

If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.

Imagine a cable cut, or series of cable cuts that isolated a block of countries.

- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection

These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.

Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.

^^^ good points...I suppose that the demand for connectivity in the smaller network would produce an strong incentive to find some way, no matter how primitive, to connect the two networks.  It could even be as primitive as using (physical) snail mail or dialup.
If enough people are using the network, and the split were not due to open hostilities, it is possible that there would be intermittent connectivity between the two networks.  This would serve to re-sync the block chains but could hurt the reliability of the system with transactions disappearing at random.

Imagine a cable cut, or series of cable cuts that isolated a block of countries.

- Someone with bitcoin might initiate an oversees dialup connection
- someone might have a satellite connection

These would probably be intermittent since they may spend most of their time on their 'normal' internet since most of what they want is there.  Everytime they connected the blocks would start flowing from their computer to the rest of the world, then when they re-connected to their normal service they would flow to the rest of their country.

Someone with bitcoin might fly to one of those countries to visit, when they connected to a local service, the blocks on their computer would flow to the disconnected countries, the longest block chain wins.  When they come back, again, the blocks from the disconnected countries would flow to the rest of the world.
Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?


No, I am saying that given enough bitcoin users this is likely to happen, there is no need for them to notice that the bitcoin network split, either they notice that they can't check email/access websites outside of their local area and initiate a temporary alternate connection to the "rest of the world" or they just happen to take a laptop with bitcoin on an airplane.

I am also not saying it is a good thing.  having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system.
I am also not saying it is a good thing.  having a single split for a fairly long period of time lets people come up with a solution, having many splits that each last for a few hours means that transactions randomly disappear and that hurts confidence in the system.
Transactions won't disappear if they're valid.  They'll just move to the longer block chain.

Invalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain).

Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.

For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).
For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).

It doesn't have to be someone trying to cheat.  You can be honest, and yet unlucky and get caught on the other side of a network split.  If you generate and spend coins on the unlucky side of the network split, the consequences are the same as for dishonest users.
Transactions won't disappear if they're valid.  They'll just move to the longer block chain.

Invalid transactions would be somebody trying to double-spend across the split chains (which would be tricky-- you'd have to run a modified client, or copy your wallet to a machine working on the other block chain).

Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.

For shorter splits, immature generated coins on the shorter chain will disappear when the chains merge, but that would be about the worst consequences for honest users (unless you were unlucky enough to get an invalid coin from somebody trying to cheat).

Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours), it should be able to merge back to together without too many issues. So coin generation would probably be the only victim (if no double-spending cheats took place), or more technically, coin generation would be assigned to someone else that was generating at the same time as those that split off.

If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?

Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?


I started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening.  Each block in a row that takes longer than the average increases confidence against a false positive.  So if one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network.


Yes...
But what you describe is only possible after someone have noticed and prooved the network split is happening.
Do you propose any method to detect the beginning of the network split?


I started another thread along this line elsewhere, but for an individual vendor, a simple watchdog daemon that tracks the average time between blocks since the last official change in difficulty and alerts the vendor if a single block takes more than twice as long as the average, perhaps suspending the acceptance of new coins until the vendor checks to see what is happening.  Each block in a row that takes longer than the average increases confidence against a false positive.  So if one block takes twice as long as average, followed by a series of blocks that take 75% longer than average, then you can be fairly certain that you are no longer on the majority network.



Really? It seems to me more likely that a bunch of people left/crashed than a whole new network half the size of the legit one has gotten to you.

I'm probably misunderstanding.
creighto: I agree with that idea.  After a few hours, it should be possible for the client to notice if the flow of blocks has dropped off by more than would be likely just by chance.  It could tell if it's not hearing the hum of the world anymore.

Or if the split lasted long enough (more than 100 blocks), transactions that involve generated coins on the shorter chain would be invalid at the merge.
Interesting info, so other than some double-spending issues, as long as the block chain isn't separated for more than 100 or so blocks (or 16+ hours),
In practice, splits are likely to be very asymmetrical.  It would be hard to split the world down the middle.  More likely it would be a single country vs the rest of the world, lets say a 1:10 split.  In that case, it would take the minority fork 10 times as long to generate 100 blocks, so about 7 days.  Also it would be super easy for the client to realize it's hearing way too few blocks and something must be wrong.

If there a hard coded limit on split delay? Meaning if I had a small network split from the public network, spent some coin around, came back a few days later and got them sync up to the public network (other than coin generation if it happened) transactions should be fine?
There's no time limit.  Assuming you weren't spending coins generated in the minority fork, or spending someone's double-spends you received, your transactions can get into the other chain at any time later.