Bitcoin Forum

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

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?

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

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.

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.


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 (http://www.usgovernmentspending.com/spending_history), massive inflation (http://mises.org/daily/3010), collection of all scap or private metal (http://tvh.bfn.org/metal.html), confiscation of private property (http://en.wikipedia.org/wiki/United_States_home_front_during_World_War_II#Taxes_and_controls).  Even FDR in the economic emergency during 1933 outlawed private ownership of gold (http://en.wikipedia.org/wiki/Executive_Order_6102).  But bit coin would be resistant to such measures, as long as the government doesn't shut down the internet (http://www.huffingtonpost.com/2010/06/25/internet-kill-switch-appr_n_625856.html), 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..

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  ;D

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?

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

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.

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

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.

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 (http://www.dailytech.com/Bad+to+Worse+Fifth+Undersea+Cable+Cut+in+Middle+East/article10598c.htm) or here (http://www.cnn.com/2008/WORLD/meast/02/01/internet.outage/index.html)) 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 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.

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.

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 :)

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.

Woot! Real facts! Nice!

Cool time machine thread too. Nice analysis!

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

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.

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


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

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.

:(

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


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

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.

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

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.

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?

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.

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.

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.

Either you are misunderstanding or I am, both are possible.

From the perspective of the vendor's client, it doesn't matter *why* the average block time has doubled, only that it has.  The watchdog daemon simply notifiys the vendor that a problem could exist.  It's an alarm, but the vendor still would have to determine if it's a problem for him or not.  I think that he could still make valid transactions, if he was willing to risk the possibility that he could be left with invalid coins when the grid come back up.  The real cash economy has similar risks, as no one can really know with any degree of certainty that the 20's in his cash drawer are not counterfit.  I'm pretty sure that only the coins created since the break are at risk, since coins owned by people on the other side of the split are still theirs, and cannot be (honestly) traded on both sides, but honest trades on either side should still be reflected in the block chain once the grid comes back up.  At least that is the way I inderstand the functions of the system.  I could still be wrong.

Also, there is a case of diminishing risks as the number of blocks grows and the number of nodes continues to grow.  Relative to the existing coins, new coins represent a smaller percentage of the monetary base with passing time.  Even though the risks of catching a bad coin created since a split increases with time as well, they are relatively remote, and tend towards zero over the next 120 years.  But the risks also tend toward zero at a log, not in a linear progression.

What I'm saying here is, by the time that bitcoins catch on, the risks of trading with bad coins during a network outage drop as the popularity of the bitcoin increases *and* also decrease simply as the blockchain grows over time.

Thanks, that is a particularly useful result!

Note that it would actually be very hard to keep them separate in such a situation. It only takes one rogue node to connect the two and keep them in sync. I'd think there would be someone in some 3rd country who would act as go between (maybe somewhat like Switzerland did in WW2). It would seem probable to me there would even be many connections no matter how hard some authorities might wish to separate them. There could even be certain parties within the warring governments who would reconnect them for their own reasons (bankrolling spies?).

But if you knew there was a split in progress and you generated coins, you would want to spend them as quickly as possible, just in case you were on the shorter chain when the network reconnected.  This would keep the risks much higher than the math would suggest.

An honest client can't really do that without spending the older coins first.  It doesn't *have* to spend the older coins first, but an honest client will not show any preferences towards spending the newest coins.  This would require a previously hacked client, or some rapid coding skills.

You can just rename your wallet file, then any new coins you generate will go in the new wallet and since those are the only coins in there they will be spent first. 

After the re-join, if your chain loses, just copy the saved wallet file back.  If your chain wins, transfer the remaining coins from the new wallet to another machine then copy the wallet back.  No coding skills needed.

That still requires prior intent, along with the expectation that you will be the one on your side of the break to make bitcoins.  And the risks involved to others is still dropping at a log, proceeding from very unlikely risk currently to astronomicly improbable over time.

I'm not saying that it's impossible, but neither is it impossible that the Mayans had it right and we only have two years left to live.  Personally, I don't think that it's a problem worth spending much time on.

Thanks everyone for addressing my concerns!

I have come to realize that (A) there are a lot of smart people out there who would notice the network split and take steps to address the problem, and (B) there are a lot of cheap, open-source technologies to enable connectivity such as:

Mesh Potato (http://www.linuxjournal.com/magazine/mesh-potato) (open-source mesh router that automatically forms a peer-to-peer network and relays telephone calls without landlines or cell-phone towers)
Universal Software Radio Peripheral (http://en.wikipedia.org/wiki/Universal_Software_Radio_Peripheral) (an open-source high-speed, flexible, inexpensive hardware device facilitating the building of a software radio, GSM cell tower/base station, digital transciever)
openBTS (http://openbts.sourceforge.net) (an open-source application that uses the Universal Software Radio Peripheral (USRP) to present a GSM air interface to standard GSM handset and connects calls)
OR a good old-fashioned modem :)

Nice. I posted the mesh potato in other topics a few days ago.

If bitcoin stays small and bad internet stuff happens I guess it could get split, but if it gets any kind of size and distribution it'll ust be impossible to keep us apart (at least many of us, for very long).

You guys seem to be forgetting that the generated bitcoins can not be spent until the block has matured to 120 confirmations (120 blocks built on it). No honest nodes will accept your transaction if you try to send coins that haven't matured.

The likelihood of chain splitting for that long is fairly low, and even then once the longer chain wins the only losers are those who generated bitcoins on the shorter chain. While it sucks to be the guy that generates a block then loses the reward, those "lost" bitcoins are an exceedingly small portion of the total number of bitcoins in existence. All transactions from the shorter chain will be reincorporated into the longer one.

Interesting topic someone pointed me to.

1) Separating the main network in two networks is pretty difficult.
2) Keep them separated is near impossible for a long time

This is know by the time of Gnutella and Freenet, where was tested in simulations that larger is the network faster it reconnect if divided. When you are in the thousands of nodes it is not very different from slicing molasses.

In the event of war (or whatever) the two networks would connect to each other thru a rogue node, probably hosted in some neutral country and sync together.
A 64K would be enough to move enough data up and down to sync them.

But, even if we suppose there are no direct connections, the two networks could just broadcast their own data blindly to each other using AM radio packets. Slow but would work.
They could just broadcast the data using DVB-T, S or C.

The only people to suffer for the lack of full connection could be (depending on relative conditions) the miners in the network with less hashing power, because, due the lag in connecting to the other network, they would near always be later on receiving the last block mined and transmit it.