<p>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.</p>

<p>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. </p>

<p>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. </p>

<p>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: </p>

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

<p>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. </p>

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

CC BY-SA 4.0
2018-12-16T22:11:21.983Z
"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
CC BY-SA 4.0
2018-12-16T22:40:46.277Z
My 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
CC BY-SA 4.0
2018-12-16T22:52:00.657Z
Wait 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
CC BY-SA 4.0
2018-12-16T22:59:26.560Z
"Almost like an internal ledger." Bingo! I know, this is stretching a lot. Hence, the other option on updates when connectivity is available.
cogitoergosum
CC BY-SA 4.0
2018-12-16T20:45:15.583Z
2018-12-16T20:45:15.583Z
cleanmarker
<p>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. </p>

<p>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". </p>

CC BY-SA 3.0
2018-04-29T17:37:51.750Z
I dont think bitcoin run on bluetooth or even any wallet that exist allow to do so
zhiyan114
CC BY-SA 3.0
2017-08-03T19:00:21.287Z
2017-08-03T19:00:21.287Z
David D.
<h1>Use Case</h1>

<p>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.</p>

<ol>
<li>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.</li>
<li>Then, let there be multiple transactions between the merchant and buyer such that the balance is always updated locally in the wallets only.</li>
<li>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.</li>
<li>Sometime, in the future, when either/both of the wallets are online, all the offline transactions are published to blockchain and are confirmed.</li>
</ol>

<h2>Blockchain Sync</h2>

<p>There are two things that can happen at this point. </p>

<p>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.</p>

<p>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.</p>

<h3>Question</h3>

<p>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?</p>

<h2>Analogy</h2>

<p>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.</p>

<p>Spawned off of: <a href="https://bitcoin.stackexchange.com/a/41356/6975">https://bitcoin.stackexchange.com/a/41356/6975</a></p>

CC BY-SA 3.0
2017-01-11T15:19:58.967Z
This sounds a lot like the way the lighning network is implemented. https://lightning.network/
Ian Purton
CC BY-SA 3.0
2017-01-11T18:32:30.643Z
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
CC BY-SA 3.0
2018-04-29T09:44:44.400Z
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](https://github.com/bitcoin/bitcoin/issues).
Willtech
CC BY-SA 3.0
2018-04-29T09:53:12.087Z
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
CC BY-SA 3.0
2018-04-29T12:37:12.020Z
@willtech exactly my point (About a party never going online.)! How do you mean `mempool` and bypass broadcast?
cogitoergosum
CC BY-SA 3.0
2018-04-30T03:10:20.793Z
I 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
CC BY-SA 3.0
2018-04-30T03:11:00.123Z
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
CC BY-SA 4.0
2020-04-02T15:47:25.320Z
Analogy is poor: the transactions are _settled_ when customer gets the ticket and operator gets paid. Transactions are simply _counted_ when the farebox returns to the depot. That's a big difference. First, there is never a negative balance that could affect the customer as a result of the offline ledger syncing to the main ledger, unlike bouncing paper checks. Second, there is no way to resolve discrepancy between tickets counted at the depot and tickets actually sold (some could have been lost, destroyed, etc.). Also: strong motivator for underreporting (conductors can steal the difference).
nothingisnecessary
<transactions><blockchain><offline>
Settling offline transactions
cogitoergosum
# Settling offline transactions

(Asked by: username_0 on 2017-01-05)

# 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>

**Tags:** transactions, blockchain, offline

> **Comments:**
> **username_1**: This sounds a lot like the way the lighning network is implemented. https://lightning.network/  
> **username_0**: 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.  
> **username_2**: 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](https://github.com/bitcoin/bitcoin/issues).  
> **username_2**: 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.  
> **username_0**: @username_2 exactly my point (About a party never going online.)! How do you mean `mempool` and bypass broadcast?  
> **username_2**: I 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.  
> **username_2**: 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.  
> **username_3**: Analogy is poor: the transactions are _settled_ when customer gets the ticket and operator gets paid. Transactions are simply _counted_ when the farebox returns to the depot. That's a big difference. First, there is never a negative balance that could affect the customer as a result of the offline ledger syncing to the main ledger, unlike bouncing paper checks. Second, there is no way to resolve discrepancy between tickets counted at the depot and tickets actually sold (some could have been lost, destroyed, etc.). Also: strong motivator for underreporting (conductors can steal the difference).  

---

## 2 answers

### Answer by username_4 on 2018-12-16. Score: 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.

> **Comments:**
> **username_0**: "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).  
> **username_4**: My 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.  
> **username_4**: Wait 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.  
> **username_0**: "Almost like an internal ledger." Bingo! I know, this is stretching a lot. Hence, the other option on updates when connectivity is available.  

---

### Answer by username_5 on 2017-08-03. Score: -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".

> **Comments:**
> **username_6**: I dont think bitcoin run on bluetooth or even any wallet that exist allow to do so  

---

