|
November 20, 2013, 07:06:21 PM Last edit: November 21, 2013, 04:05:39 AM by callem |
|
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.
|