Desert island economy on Bitcoin without being connected to the internet?

[when]

So in my theoretical example, a group of 50 of so people takes 100kBTC and goes to live on a desert island.  They have a local network, but no connection to the internet as a whole.  They attempt to run an economy.

What problems might arise?  Would mining still work?  Could transactions be verified?

Now consider that someone takes a copy of their local wallet with 500BTC that they earned growing carrots back into the world and tries to spend it.  Does it work? 

Is there any way to adapt Bitcoin to solve any problems with this scenario?

Can someone point me to a reference that would answer this type of question?

[weex]

So in my theoretical example, a group of 50 of so people takes 100kBTC and goes to live on a desert island.  They have a local network, but no connection to the internet as a whole.  They attempt to run an economy.

What problems might arise?  Would mining still work?  Could transactions be verified?

Now consider that someone takes a copy of their local wallet with 500BTC that they earned growing carrots back into the world and tries to spend it.  Does it work? 

Is there any way to adapt Bitcoin to solve any problems with this scenario?

Can someone point me to a reference that would answer this type of question?

Their immediate problem will be mining. Since the difficulty is recorded in the blockchain they've all been using, they'd better bring a reasonable fraction of the total network hashrate with them. If conact is ever made with the real world all their confirmations will likely be erased when the rest of the world's ostensibly more cumulative difficulty chain over takes theirs.

It'd be better for them to each have a miner and start a new block chain.

Later transfers would then be done at a new exchange rate that would arise between the local chain and global chain's currency.

[Babaji]

Myself, the one hacker on this island, would take all of the BTC for myself and then begin my dictatorship!

[lassdas]

There would be no need for mining and no way to copy a wallet,
if those 100kBTC they take are paper-coins, or otherwise physical bitcoins (e.g. casascius) to start with.

Problems solved.  

[Mosrite]

There would be no need for mining and no way to copy a wallet,
if those 100kBTC they take are paper-coins, or otherwise physical bitcoins (e.g. casascius) to start with.

Problems solved.  

Brain wallet, for the win.

[sn_ppcoin]

very interesting question.

[weex]

lol... that is so true!

[scintill]

Interesting question.  I'll put as many references as I can, but I don't know if there's enough material addressing many of these questions directly.  I'm also not a bitcoin pro, but I'll explain as best as I understand.  Anyone feel free to correct me if necessary.  

Remember that bitcoins are just numbers that are a key to unlocking other numbers stored in the blockchain (wiki Private_key explains this somewhat.)

If the people take their private keys and a copy of the blockchain from the time they left, they can transfer coins among each other on the island using their own nodes over their island network, with their new fork of the blockchain.  They can also mine on that blockchain.  Keep in mind that it is a fork -- they are creating their own transaction history, which sort of means these are no longer Bitcoins, but IslandCoins.  "If multiple different software packages [...] disagree on the protocol and the rules for transactions, this could potentially cause a fork in the block chain, with each faction of users being able to accept only their own version of the history of transactions."  In this case it is multiple networks, isolated from each other, but the end result is still two chains with disagreeing history.

I will use the term "mining" for the process of maintaining the blockchain, and "coin generation" for the process of receiving coins in exchange for maintaining the blockchain (as currently happens.) Mining [...] is the process of adding transaction records to Bitcoin's public ledger of past transactions.

The problem would be in trying to take any of the coins back to "civilization."  There is no way to transfer their newly-generated coins onto the mainline blockchain -- at least not without re-doing the generation (at the much higher "mainline" difficulty level.)  In fact, the generation of IslandCoin will "taint" the island's transactions, so that the only transactions that can be taken back to the internet, are ones that don't touch new coins at all.  As time goes on, most of the transactions will probably become tainted by IslandCoins.  Because of this, and the fact that the Bitcoin blockchain doesn't have any of the island's history, our carrot-farmer's wallet is useless, at face value.  However, if he also takes the island's blockchain back with him, he should be able to replay pure-Bitcoin transactions to his addresses* back to the Bitcoin network, giving him access to any coins that were not tainted by IslandCoins.  (*To his addresses, or anyone else's on the island's, for that matter.  In fact, if a single transaction sends to both his address and someone else's, he will have to leave it unchanged when importing it to the Bitcoin blockchain. However he still would only be able to spend coins from addresses he owns.)  The wiki on Transaction verification is the best place I can think to back this up, but it's pretty involved.

As weex pointed out, mining difficulty would be sky-high to begin with, so they would have to either wait for it to come back down, or maybe modify their nodes to reset the difficulty.

Since coin generation will ruin the value of their pre-owned coins, if there was any chance anyone would want to take their coins back to civilization, it would be best if nobody generated coins on the island.  They can subdivide the existing coins as small as they like (well, no smaller than can be taken back to the main blockchain, if that's an issue.)

One last note on mining that just came to mind: I think any mining fees collected on the island would also be unspendable on the mainline chain, since they are assigned through coinbase transactions that can only be created by the block miner, not relayed to anyone on the network.

[Stephen Gornick]

So in my theoretical example, a group of 50 of so people takes 100kBTC and goes to live on a desert island.  They have a local network, but no connection to the internet as a whole.  They attempt to run an economy.

What problems might arise?  Would mining still work?  Could transactions be verified?

Taking today's blockchain with them, and its difficulty of about today's 2.7 million, and assuming each of the 50 in the group has a typical high end 1.4 GHash rig, then to get a block on this isolated network to be solved, you would have to wait two days.  So to get a transaction to confirm would take nearly two weeks.

Now consider that someone takes a copy of their local wallet with 500BTC that they earned growing carrots back into the world and tries to spend it.  Does it work?

Well, ... all the blocks solved by your island would be orphaned once exposed to the main net because the current capacity of 20 Thashs/s has way more blocks solved than the island fork.  But the client wouldn't care, it would see the reorg and notice the transactions were back to being unconfirmed and would broadcast them again.  Presuming no double spending occurred then the transactions would be relayed and then included in blocks.  So rejoining is not a problem, as long as there were no dishonest who spent on the island and also spent those same coins on the main net as well.

Is there any way to adapt Bitcoin to solve any problems with this scenario?

Yes -- set up something like a dial up connection if you had to for just one of the nodes even so that you are never out of sync very far with the rest of the network.

[weex]

But the client wouldn't care, it would see the reorg and notice the transactions were back to being unconfirmed and would broadcast them again.  Presuming no double spending occurred then the transactions would be relayed and then included in blocks.  So rejoining is not a problem, as long as there were no dishonest who spent on the island and also spent those same coins on the main net as well.

Is there no time limit for the how long after a transaction is created that it would be rebroadcast? What happens if a transaction is based on another one that has not been rebroadcast?

[antares]

The problem would be in trying to take any of the coins back to "civilization."  There is no way to transfer their newly-generated coins onto the mainline blockchain -- at least not without re-doing the generation (at the much higher "mainline" difficulty level.)  In fact, the generation of IslandCoin will "taint" the island's transactions, so that the only transactions that can be taken back to the internet, are ones that don't touch new coins at all.  As time goes on, most of the transactions will probably become tainted by IslandCoins.  Because of this, and the fact that the Bitcoin blockchain doesn't have any of the island's history, our carrot-farmer's wallet is useless, at face value.  However, if he also takes the island's blockchain back with him, he should be able to replay pure-Bitcoin transactions to his addresses* back to the Bitcoin network, giving him access to any coins that were not tainted by IslandCoins.  (*To his addresses, or anyone else's on the island's, for that matter.  In fact, if a single transaction sends to both his address and someone else's, he will have to leave it unchanged when importing it to the Bitcoin blockchain. However he still would only be able to spend coins from addresses he owns.)  The wiki on Transaction verification is the best place I can think to back this up, but it's pretty involved.

This is only partially true - If you can ensure that there's no off-Island copies of the wallets containing the initial island, which means that the coins cant be spent by someone off island, the client would rebroadcast the transactions when it comes in contact with the off-island blockchain and adapts its blockchain. The transactions are after all still valid. then again this only applies, if everyone left the island, since the transactions prev_tx fields need to be validated as well. Transactions would take a long time to reprocess(get confirmed in the main blockchain) though, since they'd need to be rebroadcast in order. This means that if you have 50 people(everyone) return from the island, they will all rebroadcast their transactions every couple hours. The oldest transactions(with prev_tx already in the worldwide blockchain) will confirm. a few hours later, the clients will rebroadcast their transactions. this time, any transactions that have only prev_tx from the last round that have been confirmed in the mean time will get confirmed. and so on. Eventually all transactions can and will be confirmed, but that ofc needs all islanders on the worldwide blockchain at the same time. People could write a patch though to resolve dependencies on transactions and then relay them all in the right order. this way all transactions could be confirmed in n(where n is the amount of transaction generations, or the dependency depth)+1 blocks.
Remember: The disability to spend unconfirmed transactions is not a protocol limitation - its a client limitation that has been introduced after people had never-confirming transactions, because they spent inputs that didnt meet the networks requirements before they got confirmed. which resulted in a cascade of unconfirmed transactions.

[when]

OK, revise the question - if the connection to the rest of the world was spotty, say, once a week, instead of non-existent, how would that change things?

My reason for asking this is I am developing a product for deployment in the Third World that Bitcoin is a great fit for, but it must be able to function with only intermittent access to the blockchain and support 50-100 users.

[SgtSpike]

OK, revise the question - if the connection to the rest of the world was spotty, say, once a week, instead of non-existent, how would that change things?

My reason for asking this is I am developing a product for deployment in the Third World that Bitcoin is a great fit for, but it must be able to function with only intermittent access to the blockchain and support 50-100 users.

Besides spending an hour or so (on a fast connection) to download the last week's worth of transactions anyone on the island would also have to wait a week to truly see their transactions confirmed.  If they mined on their own, then they would create transactions for those coins, sure, but as soon as they hooked back up to the mainland, all of those transactions would be reversed/deleted, and they would have to wait until those transactions were processed by a miner on the mainland (or by them while they still had the connection to the mainland).

So:
- They couldn't mine coins, because they would be reversed when connected to the mainland.
- They couldn't send transactions, unless they didn't mind waiting for a week for each one to be confirmed and for the person receiving them to be able to spend them again.

Really, I think it'd be a good idea to create a local version of Bitcoin (not even a fork, just a start-from-block-1 Bitcoin Island Edition), and let them mine away.  They'll end up setting their own values for the coins as appropriate, and they would never have to connect to the mainland.  Perhaps there may arise some demand for these Island coins from people who visit the island (?), so an exchange could be created where island people could trade their island coins for regular Bitcoins, and use them on the mainland, etc.

[Stephen Gornick]

My reason for asking this is I am developing a product for deployment in the Third World that Bitcoin is a great fit for, but it must be able to function with only intermittent access to the blockchain and support 50-100 users.

Well, just to clarify ... if the users are running nodes and are connected to each other (e.g. on a LAN), then only one node needs to get blocks from the main net, and can peer with the remaining ones locally.

The bandwidth to receive the blockchain is about 100 MB per day.   Dialup internet provides way more than that even.

Mining requires continuous communications.  Mining doesn't require much bandwidth, (the same 100 MB per day would be plenty) but the worker continuously needs to be getting new work from the pool as mining is the process of verifying transactions and that batch of transactions can change second-to-second.   So if there's no continuous communications then there's no mining.

With your scenario of once-a-week connectivity, that would only work if all parties could trust each other that there was no double spending until connectivity is re-established.  Thus the nodes on the desert island would be stuck with whatever block was last received.  They can use Bitcoin just fine, just that the transactions will stay at 0/unconfirmed until the connection is restored and the transaction is relayed out resulting in blocks that have confirmations for those transactions.

Because the blockchain can be transmitted on a thumb drive, you could cut the time down before connectivity is reestablished by having the next motorcycle delivery bring a copy of the blockchain from somewhere that had connectivity.  The motorcycle could then also take a copy of the desert island village's blockchain back to where connectivity exists so those transactions will get confirmations in the longer blockchain.

Spend transactions could even be sent to the main network via smoke signal if you needed as there's not a whole lot of data.  A text message holds 160 characters and a raw Bitcoin transaction is typically under 500 characters.  These can be created using BrainWallet.org:
 - http://brainwallet.org/#tx

But overall, bitcoin is an online digital currency and doesn't work for desert islands without at least sporadic (e.g., hourly) occurrances of connectivity.   Casascius physical bitcoins (or similar) do, however, work in such an environment.

[Stephen Gornick]

Is there no time limit for the how long after a transaction is created that it would be rebroadcast?

Correct.  Until the transaction is included in a block the client will sporadically (e.g., once every half hour) rebroadcast it.

What happens if a transaction is based on another one that has not been rebroadcast?

The client would have to have both transactions so it broadcasts them both.

[Stephen Gornick]

But overall, bitcoin is an online digital currency and doesn't work for desert islands without at least sporadic (e.g., hourly) occurrances of connectivity.

Here are some related threads:

Transactions when only one party is online
 - http://bitcointalk.org/index.php?topic=77608.0

Options for offline-only users?
 - http://bitcointalk.org/index.php?topic=1838.0

[scintill]

Well, ... all the blocks solved by your island would be orphaned once exposed to the main net because the current capacity of 20 Thashs/s has way more blocks solved than the island fork.  But the client wouldn't care, it would see the reorg and notice the transactions were back to being unconfirmed and would broadcast them again.  Presuming no double spending occurred then the transactions would be relayed and then included in blocks.  So rejoining is not a problem, as long as there were no dishonest who spent on the island and also spent those same coins on the main net as well.

The graceful handling for reorg is a good point I hadn't thought of, but isn't there still a problem with newly-generated coins contaminating many of the transactions? If some of the coins in a transaction don't "exist" on the mainline chain (or at least not in the same coinbase from the island), they can't be spent on it.  (assuming the island can't make a longer chain than the Internet's chain.)

[Coinabul]

I feel like an extensive ledger filled with debts between island members could be kept. Whenever connection is made in the real world, debits and credits would be repaid.

[Stephen Gornick]

but isn't there still a problem with newly-generated coins contaminating many of the transactions? If some of the coins in a transaction don't "exist" on the mainline chain (or at least not in the same coinbase from the island), they can't be spent on it.  (assuming the island can't make a longer chain than the Internet's chain.)

Yup, good point. 

This is really an unrealistic hypothetical though.  If these desert islanders have computers they have data service.  If they don't have computers they'll have some local form of money and one person will do exchange and that person will have data service.

Wifi and other data services are becoming ubiquitous.  Not necessarily wi-fi everywhere, but everywhere you can find wi-fi nearby somewhere.

Here's a related post - a backpacker was talking Bitcoin to chalet owners on islands in Malaysia.
 - http://bitcointalk.org/index.php?topic=105464.0

[SgtSpike]

Well, ... all the blocks solved by your island would be orphaned once exposed to the main net because the current capacity of 20 Thashs/s has way more blocks solved than the island fork.  But the client wouldn't care, it would see the reorg and notice the transactions were back to being unconfirmed and would broadcast them again.  Presuming no double spending occurred then the transactions would be relayed and then included in blocks.  So rejoining is not a problem, as long as there were no dishonest who spent on the island and also spent those same coins on the main net as well.

The graceful handling for reorg is a good point I hadn't thought of, but isn't there still a problem with newly-generated coins contaminating many of the transactions? If some of the coins in a transaction don't "exist" on the mainline chain (or at least not in the same coinbase from the island), they can't be spent on it.  (assuming the island can't make a longer chain than the Internet's chain.)

Then the desert islanders simply don't create coins - i.e., they don't mine.  If they did mine and generated coins, they'd also have the problem of any transactions in the blocks they mined being reversed once the main blockchain overwrote it.  So, mining would be pointless and only add confusion in such a situation.