A Protocol for Offline Bitcoin Over Radio Transactions

A Protocol for Offline Bitcoin Over Radio Transactions

As a man of many pursuits, I find the most efficient waste of time in bundling my hobbies together into convenient packets of unproductivity.  Occasionally, I am able to convince myself that one of these projects may be of interest (if not actual use) to others.  This particular project may have more function as a proof-of-concept for future development, but does actually do something in itself.

As a possible improvement over the traditional method of using a flash drive to transfer an unsigned transaction to an offline computer, there is never a bi-directional data connection made to an offline computer holding precious private keys.  This eliminates a possible mode of malware infection.  The file transfers over radio are pretty limited in their capabilities and only unidirectional for each transfer, so it would be an extraordinarily unlikely mode of infection.

An additional benefit is that only the payee requires an internet connection.  This allows for the payer to carry simpler hardware and have greater anonymity in the transaction (as soon as you connect to a mobile phone network to access the internet, the carrier can triangulate your position).

There is a lot of text following, but the process is conceptually fairly simple: payer sends payee wallet address, payee sends payer an unsigned copy of the proposed transaction, payer signs transaction and returns to payee, payee finalizes transaction.  I have been verbose in the instructions to attempt to keep folks on the right path their first time through these woods.

Hardware Requirements

  • A radio transceiver.  Any band that you have privileges to use data on will work.  For the sake of anonymity, simplicity, and cost, the unlicensed Multi-Use Radio Service (MURS) (151.82, 151.88, 151.94, 154.57, and 154.60 MHz) is a good option (other unlicensed services such as FRS or CB do not allow data: FCC Part 95.631).  New radios certified specifically for MURS (FCC Part 95) are still somewhat obscure and expensive, but old radios that were certified for business band (FCC Part 90) and grandfathered into MURS service are everywhere and cheap.  A grandfathered MURS transceiver must be certified before 2002, have a max output of 2 watts, have no way to easily switch to an output higher than 2 watts, and not allow wide-band operation on 151MHz frequencies (FCC Part 95.603g, 95.632, 95.639h).  The frequencies where wide-band operation is allowed (154MHz) were marketed as “green dot” and “blue dot” channels to business band users, which makes them easy to pick out.  I have had good luck finding these units with the following eBay search string (may need to include description search and narrow by category):

(MURS, “blue dot”, “green dot”, “154.57″, “154.570″, “154.57mhz”, “154.570mhz”, “154.6″, “154.600″, “154.60″, “154.6mhz”, “154.600mhz”, “154.60mhz”) (radio, transceiver, walkie, walkietalkie)

  • A computer with a speaker and microphone.  A headset wrapped around the transceiver works quite well for both transmit and receive.

 

Software Requirements

 

FLDIGI Setup

1)      When started for the first time, a configuration wizard will come up.  If you are operating on a licensed radio service, you must provide your callsign.  If you are operating on MURS, leave blank.  Select your soundcard microphone and speaker in the device setup.  The rest of the wizard can be skipped through for this configuration.

2)      FLDIGI → Op Mode → MT63-2000L

3)      Adjust center frequency to 1500 Hz (bottom, center of FLDIGI window)

 

Payer Offline Bitcoin Armory Setup

For privacy reasons, generate (Armory → Create Wallet) and fund (Armory → Receive Bitcoins) a new wallet for this procedure.

 

Payee Online Bitcoin Armory Setup

Payee’s online install of Armory will require a couple days to sync with the Bitcoin network when started for the first time.

 

Payer Sends Paying Address to Payee

1)      Armory → double-click wallet → Export Watching-Only Copy → Save to Text File

Wallet Properties

2)      Drag *.rootpubkey.wallet into FLWRAP and wrap without compression

FLWRAP

3)      Drag *.rootpubkey.wallet.wrap into transmit (blue) frame of FLDIGI, hold down PTT button on transceiver, and press FLDIGI “TX >|” button.  It should take less than a minute to transmit the file.

 

Payee Generates and Sends Unsigned Transaction to Payer

1)      Drag *.rootpubkey.wallet.wrap (found in FLDIGI → File → Folders → NBEMS files → WRAP → recv) into FLWRAP to unwrap

2)      Armory → Import or Restore Wallet → Import watching-only wallet data → Load from Text File → open *.rootpubkey.wallet → Restore Wallet

Restore WalletWatch-Only Wallet

3)      Armory → Offline Transactions → Create New Offline Transaction → select Payer “Watching-Only” wallet and enter Payee address and transfer amount under “Recipients” → Continue → Save unsigned transaction as *.unsigned.tx file → Continue → Done

Offline TransactionSend from WalletUnsigned Transaction

4)      Drag *.unsigned.tx into FLWRAP and wrap without compression

5)      Drag *.unsigned.tx.wrap into transmit (blue) frame of FLDIGI, hold down PTT button on transceiver, and press FLDIGI “TX >|” button.  It will take a minute or two to transmit the file.

 

Payer Signs Transaction and Returns to Payee

1)      Drag *.unsigned.tx.wrap (found in FLDIGI → File → Folders → NBEMS files → WRAP → recv) into FLWRAP to unwrap

2)      Armory → Offline Transactions → Sign and/or Broadcast Transaction → Load File → open *.unsigned.tx → verify information and Sign → Done

Load Unsigned Transaction

3)      Drag *.signed.tx into FLWRAP and wrap without compression

4)      Drag *.signed.tx.wrap into transmit (blue) frame of FLDIGI, hold down PTT button on transceiver, and press FLDIGI “TX >|” button.  It will take a minute or two to transmit the file.

 

Payee Broadcasts Finalized Transaction to Bitcoin Network and Funds are Transferred

1)      Drag *.signed.tx.wrap (found in FLDIGI → File → Folders → NBEMS files → WRAP → recv) into FLWRAP to unwrap

2)      Armory → Offline Transactions → Sign and/or Boadcast Transaction → Load File → open *.signed.tx → Broadcast

 

Cleanup

Payer may choose to delete the temporary wallet created for this transaction after verifying that the funds have been successfully transferred.

 

Future Directions

There is absolutely room for improvement in this process.  This procedure represents my attempt to hack together something with the tools I am aware of.  One limitation of using Armory is that a transaction must be initiated by an online computer, which in this case is the payee (https://bitcoinarmory.com/tutorials/armory-advanced-features/offline-wallets/).  Ideally, the payee would just provide an address to send funds, the payer would generate and sign the transaction, and return it to the payee for broadcast.  This would limit the amount of private information that both parties are required to exchange.

Additionally, there are much faster modes for the radio transmissions.  In this example, MT63-2000L is used for its robustness; it is able to achieve a low error rate even with high background noise out-of-box, but it sacrifices speed.  If noise is reduced with a cabled connection between the transceiver and computer—either through the soundcard or a terminal node controller (TNC)—a faster protocol, such as MultiCarrier PSKR, may work after optimization (http://wpaares.org/html/nbems.html).

Occasionally, you will have bad luck with Armory’s choice of sync times.  If you are not in a particular hurry to complete a transaction, you may save yourself some frustration by setting up a BBS environment where the other party can request and download the files whenever they are available.  This eliminates the need for both parties to be present at their computers at the same time.  BPQ is one possibility (http://www.cantab.net/users/john.wiseman/Documents/BPQ%20Mail%20and%20Chat%20Server.htm) and it can be setup to run on top of FLDIGI (http://www.cantab.net/users/john.wiseman/Documents/FLDigiDriver.html).  NOTE: store and forward operation is not permitted on MURS.

There are also ways that hardware can be improved.  I like the idea of using a small mobile device for offline storage of private keys for signing transactions on the go.  There is a recent port of FLDIGI to Android (http://www.w1hkj.com/vk2eta/) and several other single-mode modems for Android from Wolphi (http://www.wolphi.com/ham-radio-apps/droidpsk/), which could be useful with a mobile offline wallet such as Bither (http://bither.net/).  There are also MURS modules for mobile devices currently in development that could potentially be hacked into something useful for this project (goTenna and Beartooth are two I am aware of).  Another option would be a single-board computer such as the Raspberry Pi.  There is an Armory image for the Raspberry Pi (http://coldpi.com/manuals/install-image.html) and there are projects to turn the Pi into a radio transceiver (https://github.com/ha7ilm/qtcsdr).  NOTE: un-certified equipment is only permitted under FCC part 97 rules.

Ultimately, I would love to see someone apply these concepts toward a purpose-build system to execute offline bitcoin transactions over low-power, extremely short-range radio communication—such as RFID or NFC—between personal devices and point-of-sale terminals.

 

Share This

About the author

Rob finds himself in a never-ending string of projects. If there is a question arises, he cannot rest until an answer is found. He is an Immunology researcher by day and an amateur radio operator (KD0FTJ), amateur horticulturist, amateur cryptocurrency miner, and amateur…most everything else by night. His accrual of embarrassing injuries, nearly functional Linux-loaded gadgetry, and minor fires are (almost) tolerated by his wife and relished by his children.

View all articles by Rob Stiles

5 comments

  1. Mark

    Interesting project, we need some consulting help for a related project, if you have any interest can you please get in touch? Thanks!

  2. Tim

    I like it! I wonder who will be the first to bounce some BTC off the moon with EME. What about the first BTC DXCC? Or do you think the FCC would interpret Part 97 to frown upon such a thing? :-)

    73 de N4GN

    1. Rob

      It’s hard to know where exactly the FCC would draw the line on Part 97 usage. It could be argued that small transactions for the purpose of experimentation are not commercial and it may even be permissible to send BTC over the amateur bands as payment for radio equipment or some specific amateur services (97.113(a)(3)).

      One consideration would be the prohibition against “messages encoded for the purpose of obscuring their meaning” (97.113(a)(4)). Even if it is not your intention to obscure what you are doing, the files just look like random strings of characters to onlookers. It may be a good idea to announce exactly what you are doing before beginning the file transfer.

      Do report back on your BTC DXing experiences.

      Rob
      KD0FTJ

Leave a Reply to Evan Carter Cancel reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>