As a service, and entrepreneur could create a cryptocurrency for the event.
He could sell his Burning Man Coin (BMC) for 1000 BMC per bitcoin.
BMCs are like names in namecoin. Each BMC is indivisible.
At the end of the event he could buy them back at 0.95 bitcoin each.
He brings along a mining rig to defend his currency from double-spend,
and he makes the reward very tiny so that competing miners don't take
all the money.
He sets up an escrow before the event with each person who decides to
buy BMC. For every 0.001 bitcoin that is given to him, he locks
the bitcoin into a special wallet. The wallet is locked with a cryptographic
lock, so that only the owner of the corresponding BMC can open it.
Then the BMC is given to the partier, as a key.
In order to get the bitcoin back, you need (1) for the euntrepenuer to sign
the transaction, and (2) for the holder of the BMC to sign it.
Topic: Bitcoin with little or no internet access? (Read 1007 times)
The opencxp protocol (opencxp.org, decentralized POS system) can operate in completely offine mode (both customer and merchant). There is a risk to the merchant - as there always will be in any off-line system - including off-line Visa, MC, etc.
The risk is for double spends: If any of the inputs to a transaction have been spent during the interval between the blockchain being cached and the off-line tx finally hits the network, it will not confirm (it will be flagged as a "double spend"). Probably an acceptable risk for a food truck, etc. with a sporadic internet connection, for example - they already take these risks with off line credit card transactions.
Basically it works like this:
1. If the POS has access to a cached copy of the blockchain: The POS will hold a queue of signed transactions that will be transmitted to the network as soon as a connection is restored.
-or-
2. If there is no local copy of the blockchain (i.e. blockchain access is through an online API): The POS can retain the transaction details (addresses, private keys) in secure RAM and form the transactions and transmit them to the network as soon connection is restored.
These modes, while possible, are only really useful for low-value transactions with short term loss of connection, etc.
In case of long-term widespread internet outages, where the bitcoin network itself is disrupted, far more serious problems like compartmentalization and forking will occur. Low-bandwidth technologies such as packet-radio could theoretically connect bitcoin nodes but it's difficult to image a scenario like that where blockchain integrity would still be a priority. Concensus would either return things back to the pre-event state (the state that the most nodes accept as valid) as the network came back online, or the dominant fork would be adopted of it had the majority of nodes - and other forks (and their transactions) would be discarded.
The risk is for double spends: If any of the inputs to a transaction have been spent during the interval between the blockchain being cached and the off-line tx finally hits the network, it will not confirm (it will be flagged as a "double spend"). Probably an acceptable risk for a food truck, etc. with a sporadic internet connection, for example - they already take these risks with off line credit card transactions.
Basically it works like this:
1. If the POS has access to a cached copy of the blockchain: The POS will hold a queue of signed transactions that will be transmitted to the network as soon as a connection is restored.
-or-
2. If there is no local copy of the blockchain (i.e. blockchain access is through an online API): The POS can retain the transaction details (addresses, private keys) in secure RAM and form the transactions and transmit them to the network as soon connection is restored.
These modes, while possible, are only really useful for low-value transactions with short term loss of connection, etc.
In case of long-term widespread internet outages, where the bitcoin network itself is disrupted, far more serious problems like compartmentalization and forking will occur. Low-bandwidth technologies such as packet-radio could theoretically connect bitcoin nodes but it's difficult to image a scenario like that where blockchain integrity would still be a priority. Concensus would either return things back to the pre-event state (the state that the most nodes accept as valid) as the network came back online, or the dominant fork would be adopted of it had the majority of nodes - and other forks (and their transactions) would be discarded.
How would a community be able to use bitcoins if access to the internet and thus the bitcoin P2P network was either completely unavailable or only sporadically available from a small number of nodes?
Places such as Burning Man, remote villages and countries under civil strife come to mind.
There might have to be a level of trust for 0 confirmation transactions.
For example, would it be possible to create a separate, isolated bitcoin network with no mining and the disconnected network can get a trusted node to dump the latest block chain onto a USB stick every other day, and copy any information back onto the stick as needed (such as transactions).
What are the other ways to work? Has there been any testing, design or thought put into this type of situation?
Places such as Burning Man, remote villages and countries under civil strife come to mind.
There might have to be a level of trust for 0 confirmation transactions.
For example, would it be possible to create a separate, isolated bitcoin network with no mining and the disconnected network can get a trusted node to dump the latest block chain onto a USB stick every other day, and copy any information back onto the stick as needed (such as transactions).
What are the other ways to work? Has there been any testing, design or thought put into this type of situation?
Jump to: