Settling offline transactions 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.


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.
Then, let there be multiple transactions between the merchant and buyer such that the balance is always updated locally in the wallets only.
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.
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
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: 


Use an internal system for tracking what's what. What's been paid, what needs to be paid.
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. 
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.