0

Is it possible to confirm a transaction offline in the following scenario:

  1. the "receiving" device is first online. There is no restriction at this point. Especially, it can prepare anything needed for the following steps.

  2. the "receiving" device goes offline. It generates a payment request for a specific amount that was not known before and shares it to the "sending" device via an offline means, such as a QR code for instance.

  3. the "sending" device which is always online, completes the transaction.

  4. How could the "receiving" device, while staying offline, can get a confirmation that the transaction has really occurred? In other words, what should the "sending" device share (by QR code for instance) to the "receiving" device that will let it confirm the transaction without being fooled?

Could the "receiving" device have a public key that would verify a signed version of the transaction?

Improve this question

1 Answer 1

Reset to default
0

It depends precisely how secure you need to be. Generally speaking, the entire block containing the transaction and the next 100 block headers should be sufficient. The validation should consist of ensuring that the first block actually contains the transaction and is a valid Bitcoin block, the other 100 blocks form a valid chain, and all 100 blocks meet a reasonable difficulty target.

The easy way to create such a chain is to get the transaction confirmed and wait for all the world's miners to produce 100 blocks. Other than that, you'd have to find all 100 blocks yourself, which is an awful lot of work to do just to fake one transaction.

Note that this method would fail should the Bitcoin network's total hashing power ever fall below what the device expects as the real blocks wouldn't meet the "reasonable difficulty target". You do, to some extent, have to predict the future Bitcoin difficulty to make this work.

This assumes that having no central authority is a requirement. If you can accept a central authority, then that central authority can periodically issue a signed statement of the current minimum difficulty and number of blocks the device should accept. Updating this every year or so should be more than sufficient. That would allow you to wait for far fewer confirmations. 100 confirmations will take 17 hours or so.

Improve this answer
2
  • Thanks for the answer. I'm concerned about the size of the required transfer from the "sending" device to the "receiving" one in step 4. Block header is 80 bytes so that should be fine. But I guess that an entire block can be big. How could the required transfer be optimized with the assumption that the transaction amount is limited to something 'small' (1 BTC for instance) and this transfer should happen within minutes of the transaction?
    – gregoiregentil
    Apr 5, 2014 at 15:51
  • You can include just the transaction, enough of the Merkle tree to prove the transaction is in the block, and the headers of only a few blocks.
    – David Schwartz
    Apr 5, 2014 at 16:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.