<blockquote>
  <p>How does the transfer between the payer and payee's wallet actually happen if both nodes are offline? </p>
</blockquote>

<p>From the paper:</p>

<blockquote>
  <p>Because both, the payerX and the payeeY, have no on-line connection during the payment, the offline transaction τo is sent via local interfaces (e.g., Near Field Communication (NFC) or Bluetooth Low Energy (LTE)), in contrast to regular (online) Bitcoin transactions which are transferred via the Bitcoin peer-to-peer network.</p>
</blockquote>

<p>So basically, whatever way the two devices can communicate will work just fine to communicate the transaction.</p>

<blockquote>
  <p>Does the offline wallet operate as a Layer 2 protocol somewhat allowing for deferred settlement like LN?</p>
</blockquote>

<p>I would not say it is analogous to LN, the function and trust model is different. From the paper:</p>

<blockquote>
  <p>These  mechanisms achieve probabilistic security to guarantee that the attack probability is lower than the desired threshold.</p>
</blockquote>

CC BY-SA 4.0
2018-06-27T08:37:54.483Z
Thanks, so the funds are transferred between offline wallets if I understand correctly? How does the rest of the network know about the transaction? What’s the incentive/impediment for the sender/receiver not to collude and not double spend?
methuselah
CC BY-SA 4.0
2018-06-27T20:20:40.200Z
@methuselah The network hears about the tx when the user that was paid reconnects and broadcasts the payment tx. I am not deeply familiar with the mechanisms proposed in that paper, so I would recommend reading the paper in depth to learn more. From what I understand, a purpose-built trusted hardware wallet will have a hardcoded key, and any user that is double spent against can publish proof of this attack, along with the malicious key, to a central address on the network. So the security comes from a 'it costs more to attack than you'll gain' idea. Hence the 'probabilistic security' model.
chytrik
CC BY-SA 4.0
2018-06-27T08:14:56.317Z
2018-06-27T08:14:56.317Z
chytrik
<p>A paper titled Secure Wallet-Assisted Offline Bitcoin Payments with Double-Spender Revocation (<a href="https://www.ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/system-security-group-dam/research/publications/pub2017/asia084.pdf" rel="nofollow noreferrer">https://www.ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/system-security-group-dam/research/publications/pub2017/asia084.pdf</a>) was published a while ago. The paper proposes the first solution for secure Bitcoin offline payments using an offline wallet with several novel security mechanisms to prevent double-spending and to verify the coin validity in offline setting.</p>
<p>There are three phases:</p>
<ol>
<li><p>Online Bitcoin preloading.</p>
</li>
<li><p>Offline Bitcoin payment.</p>
</li>
<li><p>Online redemption of coins and revocation of double spending attacks.</p>
</li>
</ol>
<blockquote>
<p>In the first phase, the payer X generates pre-loading transaction τl (step 1) that transfers some bitcoins from her standard Bitcoin account x to the offline wallet’s account w, so that the balance of w becomes positive. This is done by means of standard online Bitcoin transaction, for which the network generates n-transaction confirmation n -Tl.</p>
<p>In the second phase the payer X requests W to generate an offline transaction τo with the desired amount destined to the account y (step 3).</p>
<p>In the third phase, the payee Y redeems the bitcoins he received offline by broadcasting τo into the Bitcoin network (step 4) and optionally obtaining network confirmation n -To (step 5).</p>
<p>The network confirmation will only be issued, if the network has not detected a double-spending attack against τo. Otherwise, the payee Y will trigger an optional double-spender revocation procedure, which includes sending a double-spender revocation transaction τr (step 6) to the Bitcoin network and obtaining corresponding confirmation n -Tr (step 7).</p>
</blockquote>
<p>How does the transfer between the payer and payee's wallet actually happen if both nodes are offline? Does the offline wallet operate as a Layer 2 protocol somewhat allowing for deferred settlement like LN?</p>

<offline-transactions>
A Secure Offline Bitcoin Payment System
methuselah
# A Secure Offline Bitcoin Payment System

(Asked by: username_0 on 2018-06-27)

A paper titled Secure Wallet-Assisted Offline Bitcoin Payments with Double-Spender Revocation (<https://www.ethz.ch/content/dam/ethz/special-interest/infk/inst-infsec/system-security-group-dam/research/publications/pub2017/asia084.pdf>) was published a while ago. The paper proposes the first solution for secure Bitcoin offline payments using an offline wallet with several novel security mechanisms to prevent double-spending and to verify the coin validity in offline setting.

There are three phases:

1. Online Bitcoin preloading.
2. Offline Bitcoin payment.
3. Online redemption of coins and revocation of double spending attacks.

> In the first phase, the payer X generates pre-loading transaction τl (step 1) that transfers some bitcoins from her standard Bitcoin account x to the offline wallet’s account w, so that the balance of w becomes positive. This is done by means of standard online Bitcoin transaction, for which the network generates n-transaction confirmation n -Tl.
>
> In the second phase the payer X requests W to generate an offline transaction τo with the desired amount destined to the account y (step 3).
>
> In the third phase, the payee Y redeems the bitcoins he received offline by broadcasting τo into the Bitcoin network (step 4) and optionally obtaining network confirmation n -To (step 5).
>
> The network confirmation will only be issued, if the network has not detected a double-spending attack against τo. Otherwise, the payee Y will trigger an optional double-spender revocation procedure, which includes sending a double-spender revocation transaction τr (step 6) to the Bitcoin network and obtaining corresponding confirmation n -Tr (step 7).

How does the transfer between the payer and payee's wallet actually happen if both nodes are offline? Does the offline wallet operate as a Layer 2 protocol somewhat allowing for deferred settlement like LN?

**Tags:** offline-transactions


---

## 1 answers

### Answer by username_1 on 2018-06-27. Score: 1

> How does the transfer between the payer and payee's wallet actually happen if both nodes are offline?

From the paper:

> Because both, the payerX and the payeeY, have no on-line connection during the payment, the offline transaction τo is sent via local interfaces (e.g., Near Field Communication (NFC) or Bluetooth Low Energy (LTE)), in contrast to regular (online) Bitcoin transactions which are transferred via the Bitcoin peer-to-peer network.

So basically, whatever way the two devices can communicate will work just fine to communicate the transaction.

> Does the offline wallet operate as a Layer 2 protocol somewhat allowing for deferred settlement like LN?

I would not say it is analogous to LN, the function and trust model is different. From the paper:

> These mechanisms achieve probabilistic security to guarantee that the attack probability is lower than the desired threshold.

> **Comments:**
> **username_0**: Thanks, so the funds are transferred between offline wallets if I understand correctly? How does the rest of the network know about the transaction? What’s the incentive/impediment for the sender/receiver not to collude and not double spend?  
> **username_1**: @username_0 The network hears about the tx when the user that was paid reconnects and broadcasts the payment tx. I am not deeply familiar with the mechanisms proposed in that paper, so I would recommend reading the paper in depth to learn more. From what I understand, a purpose-built trusted hardware wallet will have a hardcoded key, and any user that is double spent against can publish proof of this attack, along with the malicious key, to a central address on the network. So the security comes from a 'it costs more to attack than you'll gain' idea. Hence the 'probabilistic security' model.  

---

