Settling offline transactions

8

4

Use Case

My use case is around a scenario where both customer and merchant possess offline wallets with a balance that has had confirmation on the blockchain.

  1. To begin with, let us say that, the merchant and the buyer's wallets show balances of 20 BTC and 10 BTC respectively. These balances are the one that are confirmed on the block-chain.
  2. Then, let there be multiple transactions between the merchant and buyer such that the balance is always updated locally in the wallets only.
  3. All of the transactions, in 2 above, happen in an offline mode; i.e. no access to network. The period of no access can run into days.
  4. Sometime, in the future, when either/both of the wallets are online, all the offline transactions are published to blockchain and are confirmed.

Blockchain Sync

There are two things that can happen at this point.

First, the wallets are so secure that, all updates (credits and debits) happen locally without ever having to 'sync' up with the blockchain. The only time the wallets may sync with blockchain is to post the transactions and their sequence; and, also to update their wallet with the credits that happened since the last time the wallet went online. Or, regulatory pressure requires posting transaction data every set frequency.

Second, all credit updates are made to the wallets via the blockchain. This requirement is enough motivation to seek network connectivity; even if it is once in a week or fewer.

Question

In either case, we are looking at a scenario, where a value, confirmed by blockchain, is used in transactions offline to be confirmed online later. How do we implement this?

Analogy

Bus conductors may issue tickets with an offline machine to passengers who board the bus at various points throughout the journey. When the bus reaches its destination, the machine is used at the depot to arrive at a list of tickets sold and the amount collected thereof. Thus, this is an example of an offline transaction where transactions are 'settled' when 'connectivity' is eventually available.

Spawned off of: https://bitcoin.stackexchange.com/a/41356/6975

cogitoergosum

Posted 2017-01-05T05:38:02.903

Reputation: 317

This sounds a lot like the way the lighning network is implemented. https://lightning.network/

– Ian Purton – 2017-01-11T15:19:58.967

Can you please elaborate? I did read their pdf here - https://lightning.network/lightning-network-summary.pdf My key point is, two wallets, who have balances that can be corroborated by the ledger, can execute transactions without having to connect to network again. Once connected, they retroactively get/post their transactions to the ledger and update their wallets as well. I think, Lightning Network is sort of a escrow.

– cogitoergosum – 2017-01-11T18:32:30.643

So, what is needed is a method of exporting/importing signed transactions into the mempool directly, bypassing the broadcast mechanisms. A fine idea. You should consider discussing this on [bitcoin-dev] or else post it under the feature heading on GitHub.

– Willtech – 2018-04-29T09:44:44.400

Further, even if one part decides to never go online or to abandon the transactions before they are broadcast, the other party's node must be capable of retaining and broadcasting the transaction(s) without having previously dropped them. – Willtech – 2018-04-29T09:53:12.087

@willtech exactly my point (About a party never going online.)! How do you mean mempool and bypass broadcast? – cogitoergosum – 2018-04-29T12:37:12.020

1I can create a transaction even while offline with Bitcoin Core. That transaction is in the mempool. Ordinarily, when a node is online it broadcasts transactions to other nodes, they are received into those nodes mempool also. All that is required is a transaction export which will provide plain text of the signed transaction on the one end and, an import feature for the other end. Each party can exchange transactions offline and when either party goes online all transactions need to be broadcast. – Willtech – 2018-04-30T03:10:20.793

This means that imported transactions will have to received into the mempool with special rules so that they are never dropped. Ordinarily, a transaction is dropped from the mempool after a time period but, it is usually expected that the transaction would be confirmed prior to this. – Willtech – 2018-04-30T03:11:00.123

Answers

1

I'd say there are number of issues at play here. If the system is "offline" then the only update you'll have to balances is whatever was last stored. The assumption here is both sources are trusted, and the system in the middle is trusted. Might as well make it a centralized asynchronous system. You'd have far more control and less reliance on 3rd party tools at that point.

The system proposed would be "nice" but a solution in the meantime would be to develop an internal ledger. You know party A, and party B. You know their balances, and you trust their transactions. This system assumes you know their keys as well, or can obtain them as needed.

Based on the most recent balance store your transactions in a normal DB. Running balance, again based off most recent information. Whenever the node is able to connect, update the current balances (trust but verify), check any previous transactions you may have submitted for failures (lack of gas, improper transaction, lack of funds etc), then process the transactions.

If there are A -> B and B -> A transactions then you could resolve transaction balances internally (assuming that is legal for what's intended). Otherwise you can put in all kinds of logic to resolve each transaction. To summarize:

  1. Use an internal system for tracking what's what. What's been paid, what needs to be paid.
  2. When node connects, get as much info as you can. Current balance, confirmed transactions from previous submissions, transactions that are still waiting to be confirmed. Identify transactions that outright failed for whatever reason (this is assuming a short 'up time' for connection with the node. It wouldn't stay connected long enough to see transactions hit the first block), still sitting in mempool (not enough gas to be picked up and go stale), etc.
  3. Process based off the information above. Transactions will ultimately be resolved or unresolved. A FIFO can be used to resolve the oldest transactions, or if the ideal situation is to resolve the greatest number of transactions first regardless of age then a large transaction may get backlogged while many other transactions get taken care of.

This is all a matter of striking a balance of "trust" vs "timing". If i own 2 wallets, and i'm the only one with the keys, i could run every transaction in a back end system tracking what "it should be" and resolving it whenever i want.

The provided suggestion is a balance between available technology(and circumstances), security, and accuracy.

cleanmarker

Posted 2017-01-05T05:38:02.903

Reputation: 335

"The assumption here is both sources are trusted, and the system in the middle is trusted." The trust comes from confirmed balance on the blockchain. Not sure about the system in the middle. The crux of this question is to eliminate the central system (as mentioned in this answer). – cogitoergosum – 2018-12-16T22:11:21.983

1My response and assumption stems from "First, the wallets are so secure that, all updates (credits and debits) happen locally without ever having to 'sync' up with the blockchain." To me that means trust can be derived without interaction from the blockchain. If this is not the case, then trust always goes to zero if you can't first submit to the chain and confirm the transaction is valid because the crypto can already be spent elsewhere. Thus this only works with implicit trust from both sources that funds will not be spent while this system is offline. – cleanmarker – 2018-12-16T22:40:46.277

1Wait i think i get your point. You're saying the wallets cannot interact outside of the node, therefore they can do their business on this node without being sync'd with the rest of the world. Almost like an internal ledger. I was approaching this as a way for 2 trusted wallets to resolve transactions and using the blockchain as a "final" record. So i think i get what you're intending now. In all, due to the need for confirming that a transaction is valid I don't see how this can be accomplished without extreme trust and/or resolution process in place from a central authority. – cleanmarker – 2018-12-16T22:52:00.657

1"Almost like an internal ledger." Bingo! I know, this is stretching a lot. Hence, the other option on updates when connectivity is available. – cogitoergosum – 2018-12-16T22:59:26.560

-3

This can be accomplished by using Bluetooth/NFC connectivity with a unique wallet (must be same for both ends) that is capable of storing encrypted offline transactions without actually syncing them with the Blockchain. However, as for the paying side, the initial funds must come from buying and syncing with the blockchain.

The Lightning network is still in concept stage as far as I know. There are still issues to be solved, especially regarding possibly misleading the system to believe that you received payment from someone that did NOT actually send it - by repeating a (real) previous transaction like in "man in the middle".

David D.

Posted 2017-01-05T05:38:02.903

Reputation: 101

I dont think bitcoin run on bluetooth or even any wallet that exist allow to do so – zhiyan114 – 2018-04-29T17:37:51.750

Asked: 2017-01-05T05:38:02.903

Viewed: 2 799 times

Active: 2018-12-16T20:45:15.583