[BOUNTY - 25 BTC] Audio/Modem-based communication library

[Raize]

Raize has offered to send the 5 BTC to me for Armory development.  So what I think I will do is keep the bounty open, and switch from {Me: 20BTC, Raize: 5BTC} to {Me: 25BTC, Raize: 0}.  That way ATI gets the 5 BTC to use for development if the bounty is never claimed, but it's still available to someone like goatpig who still wants to take a shot at it.  I think everyone wins.

Yes, this sounds good to me. You're going to have a better idea of what meets your requirements anyway. I just wanted to see such a thing done.

I think we determined that over-the-air wasn't going to work.  If it did it would strictly be a bonus -- I intend to use/require the double-ended audio cables.

Agreed. Also, I would prefer something that can't be easily eavesdropped/recorded for analysis later (assuming third and second parties are occasionally allowed into the room where the Armory offline client is stored). At least with a direct audio link this isn't even a factor. I realize there are Tempest-like ways of catching interference even with a direct audio link, but those can be mitigated both electronically and physically(a quality van-Eck-phreaking device isn't going to be easily hidden on one's person).

Thanks.

[etotheipi]

Agreed. Also, I would prefer something that can't be easily eavesdropped/recorded for analysis later (assuming third and second parties are occasionally allowed into the room where the Armory offline client is stored). At least with a direct audio link this isn't even a factor. I realize there are Tempest-like ways of catching interference even with a direct audio link, but those can be mitigated both electronically and physically(a quality van-Eck-phreaking device isn't going to be easily hidden on one's person).

By the way, there is no security issues with the transfer unless you are concerned about privacy, which probably isn't worth an TEMPEST attack itself.   The data moving between the devices is simply an unsigned transaction (online to offline) and a signed transaction (offline to online), which eventually ends up in the blockchain anyway.   So just like with the USB keys, there's nothing useful to an attacker besides learning that you have access to some given addresses and where you are sending money.  But if they're crazy enough to use such an attack they probably got your watching-wallet anyway.

So I'm not too concerned about that.  If someone is going to TEMPEST the room, they would better off trying to probe the buses on the device circuitboards. And if that's what's driving you, you can always get yourself a Faraday Tent
 

[goatpig]

It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.

[etotheipi]

It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.

I see no reason to spend any effort on securing the channel, beyond making sure that the offline device is getting data from the correct online device (no injection).  But given the SNR of a direct audio cable, I'm not concerned about that either.  This is purely a bandwidth issue.

Compression would be great, except I wouldn't count on it to help very much, since the transactions are mostly hashes which aren't compressible.  I would guess you'd get no more than 5%-10% compression.  So again, the real bottleneck here is how many bits-per-second you can reliably push over the audio channel.

[goatpig]

It's entirely possible to secure the channel however. My primary intention was to compress the data to be sent and uncompress it on the other side, since the bottleneck is channel bandwidth rather than CPU cycles, however, it could be used without compression and a SSL handshake kind of setup to secure the channel. That would be kinda slow however.

I see no reason to spend any effort on securing the channel, beyond making sure that the offline device is getting data from the correct online device (no injection).  But given the SNR of a direct audio cable, I'm not concerned about that either.  This is purely a bandwidth issue.

Compression would be great, except I wouldn't count on it to help very much, since the transactions are mostly hashes which aren't compressible.  I would guess you'd get no more than 5%-10% compression.  So again, the real bottleneck here is how many bits-per-second you can reliably push over the audio channel.

5-10% would pay for the packet headers and CRC overheads, I'd be fine with that. Snappy is overly way too easy to implement to just pass on that.

Regarding bit rate, I just setup a second PC in my room. Expect some results in a week or 2, depending on my schedule.

[goatpig]

Quick Update:

OpenAL isn't open source anymore. It's mainly maintained under a proprietary license for Windows only. There is a fork of the original implementation that's somehow maintained but I've decided to move on to PortAudio, an open source cross platform audio library.

PortAudio comes with built in ASIO support, which is a low latency cross platform audio driver under a proprietary license. However the SDK and drivers are free to download and use, and the license is free of fees and royalties. They essentially only ask to be mentioned and have their logo added to product boxes and websites.

If that's not ok, I'll dump ASIO. However I think it would allow easier cross platform deployment to have a unified driver. Waiting on your input.

[etotheipi]

Quick Update:

OpenAL isn't open source anymore. It's mainly maintained under a proprietary license for Windows only. There is a fork of the original implementation that's somehow maintained but I've decided to move on to PortAudio, an open source cross platform audio library.

PortAudio comes with built in ASIO support, which is a low latency cross platform audio driver under a proprietary license. However the SDK and drivers are free to download and use, and the license is free of fees and royalties. They essentially only ask to be mentioned and have their logo added to product boxes and websites.

If that's not ok, I'll dump ASIO. However I think it would allow easier cross platform deployment to have a unified driver. Waiting on your input.

Attribution is fine.  Adding their logo and acknowledgment to our website would probably be fine, too, if we actually integrate the solution into Armory.  If that's easiest for you, do it. 

[goatpig]

Attribution is fine.  Adding their logo and acknowledgment to our website would probably be fine, too, if we actually integrate the solution into Armory.  If that's easiest for you, do it. 

Sounds good. I will build the lib with ASIO and perform tests with and without. If it turns out to be significant in speed and/or portability, I will keep it.

[Garr255]

I remember reading about this idea a long time ago and talking about it on IRC, and I love it. I'll toss a BTC to whoever gets this done!

[roman.z]

Hi all,

I have been working during the last weeks on an audio modem library in Python: https://bitbucket.org/romanz/amodem
EDIT: moved to GitHub: https://github.com/romanz/amodem.

I am using a simple headset, whose speaker is connected to the transmitting PC and the microphone is connected to the receiving PC.
Then, I bring the speaker and the microphone close together and use the PC's sound cards to perform the communication.

The sender is modulating data.send binary file using send.py script into 32kHz audio file (tx.int16), which is played using aplay Linux utility.
The receiver is using arecord Linux utility to record the audio file into rx.int16 32kHz audio file, which is demodulated by recv.py script into data.recv binary file.
The process requires a single manual calibration step in order to find the maximal volume for the speaker, so that it won't saturate the microphone.

The modem's bitrate is currently 8kbps - so it should not have a problem sending a simple transaction in O(seconds).
Moreover, I am sure it can be optimized by using better modulation, error correction and better audio equipment.

Currently, the documentation is quite lacking, but today was the first time I successfully transmitted 1KB of random binary data between 2 PCs, so I am quite excited
The recorded audio file is currently stored at rx.int16 - and can be demodulated by running:

$ virtualenv env
$ source env/bin/activate
$ pip install reedsolo numpy
$ python recv.py

I would be happy to continue developing this library, in order to integrate it with popular Bitcoin wallets, aiming to support air-gapped transaction signing.

Comments are welcome

[CIYAM]

Whilst what you have done does sound quite impressive - did you not consider just using QR codes instead?

(much more reliable and simpler compared to using audio)

Am pretty sure even etotheipi has changed his mind about QR codes.

[roman.z]

Thanks for the compliment

I chose not to use QR codes, since my PC and laptop have no camera...

[etotheipi]

Am pretty sure even etotheipi has changed his mind about QR codes.

No, I haven't changed my mind about QR codes.  They're a non-starter, because the data transmission sizes are 1-2 orders of magnitude smaller than what is needed to handle standard transaction sizes.  Yes, it will handle 98% of transactions for some usage patterns, but only 5% of transactions for other wallet usage patterns.  It really needs to be 100% for all usage patterns.

OTOH, QR-video would work.  But that's significantly more complex than using static QR codes and there's very few libraries out there to choose from.

[CIYAM]

OTOH, QR-video would work.  But that's significantly more complex than using static QR codes and there's very few libraries out there to choose from.

I actually already split up GPG private key into 2 QR codes for the CIYAM Safe so I do understand the size issues but I really don't think it is very hard to work with multiple QR codes.

I guess having something that identified "how many images are coming" could be more handy though (as a header with the receiver then able to verify they have got everything).

[roman.z]

Some more technical details:
I am using 4 carrier frequencies (8, 9, 10 and 11 kHz), which are modulated using QPSK-4 (yielding 2 bits per symbol).
Each symbol duration is 1ms, so the bitrate of the modem is 8[kbps] = 2[bit/symbol] * 1000[symbol/second] * 4 (carriers).

The symbols' constellations are shown here: https://i.imgur.com/JAbGkIt.png. They can be plotted using:

$ source env/bin/activate
$ pip install matplotlib
$ PYLAB=1 python recv.py
Carrier detected at ~2242.0 ms @ 10.0 kHz: coherence=99.411%, amplitude=0.400
Carrier starts at 2241.688 ms
Prefix OK
Frequency error: 1.52 ppm
       8.0 kHz: Noise sigma=0.0790, SNR=22.0 dB
       9.0 kHz: Noise sigma=0.0407, SNR=27.8 dB
      10.0 kHz: Noise sigma=0.0348, SNR=29.2 dB
      11.0 kHz: Noise sigma=0.0288, SNR=30.8 dB
Decoded 5 blocks = 1150 bytes (ECC overhead 9.8%)
Decoded 1024 bytes
$ python errors.py data.send data.recv
0/8192 bit error rate: 0.000%

Note that the noise is higher on lower frequencies, probably due to "pink noise" (http://en.wikipedia.org/wiki/Pink_noise).

The received signal waveform and spectrogram are given here: https://i.imgur.com/JMuRbAZ.png.
They can be plotted using (after matplotlib package is installed):

$ python show.py rx.int16

By the way, is the BTC bounty still open?

[Raize]

By the way, is the BTC bounty still open?

I still have the coin to pay this. I don't think I ever got around to sending my bounty to etotheipi (we talked about me just donating, but he wanted to wait because I think goatpig was working on a solution), but assuming you can get it to meet the specifications, that sounds good. I think etotheipi's original bounty was for 5MB to be transferable within 15 minutes, however, and it looks like yours can do about 900KB in the same time frame?

In any event, I'll need some time to pull the bounty out of cold storage, I set aside some coin for doing this a long time ago and spent it when we hit $1k, but I can pull some more out of colder storage if needs be, ultimately I'm letting etothipi have the final say on a solution being viable, though, because what I really want is something like this to be built into Armory for cold storage purposes.

I do believe he said something about a partial bounty for code leading to a solution, too.

[roman.z]

Good news, every one

I have used today a proper audio cable (instead of a headset) to connect between my PC's audio output and input, so the noise went down dramatically.
This way I was able to achieve 36kbps (after ECC) to successfully transmit 64kB.

Note that there is an overhead of ~2 seconds for the training sequence of the modem, so the effective transfer time is ~15 seconds.

$ ./test.sh
+ set -e
+ dd if=/dev/urandom of=data.send bs=1024 count=64
64+0 records in
64+0 records out
65536 bytes (66 kB) copied, 0.00955402 s, 6.9 MB/s
+ python send.py
Running MODEM @ 40.0 kbps
Encoded 65536 bytes
$ arecord rx.int16 -q -f S16_LE -c 1 -r 32000
$ aplay tx.int16 -q -f S16_LE -c 1 -r 32000
Took 17.27 seconds
+ python recv.py
2014-07-09 08:38:23,480 INFO         Carrier detected at ~58.0 ms @ 1.0 kHz: coherence=100.000%, amplitude=0.402
2014-07-09 08:38:23,483 INFO         Carrier starts at 57.500 ms
2014-07-09 08:38:24,058 INFO         Prefix OK
2014-07-09 08:38:24,058 INFO         Frequency error: -0.02 ppm
2014-07-09 08:38:24,146 INFO                1.0 kHz: Noise sigma=0.0040, SNR=47.9 dB
2014-07-09 08:38:24,235 INFO                2.0 kHz: Noise sigma=0.0034, SNR=49.5 dB
2014-07-09 08:38:24,323 INFO                3.0 kHz: Noise sigma=0.0026, SNR=51.8 dB
2014-07-09 08:38:24,411 INFO                4.0 kHz: Noise sigma=0.0027, SNR=51.4 dB
2014-07-09 08:38:24,500 INFO                5.0 kHz: Noise sigma=0.0032, SNR=50.0 dB
2014-07-09 08:38:24,588 INFO                6.0 kHz: Noise sigma=0.0025, SNR=52.0 dB
2014-07-09 08:38:24,676 INFO                7.0 kHz: Noise sigma=0.0034, SNR=49.4 dB
2014-07-09 08:38:24,765 INFO                8.0 kHz: Noise sigma=0.0042, SNR=47.6 dB
2014-07-09 08:38:24,853 INFO                9.0 kHz: Noise sigma=0.0075, SNR=42.5 dB
2014-07-09 08:38:24,941 INFO               10.0 kHz: Noise sigma=0.0197, SNR=34.1 dB
2014-07-09 08:38:24,941 INFO         Demodulation started
2014-07-09 08:38:36,076 INFO         Demodulated 616560 bits : 77.070 kB @ 11.134 seconds
2014-07-09 08:38:37,469 INFO         Decoded 65.536 kB
+ python errors.py data.recv data.send
0/524288 bit error rate: 0.000%

The constellations are here: https://i.imgur.com/7kRtJb9.png

Using 36kpbs MODEM throughput, we can transmit 5MB = 40Mb in ~1111 seconds = 18.5 minutes.

[etotheipi]

Good news, every one

I have used today a proper audio cable (instead of a headset) to connect between my PC's audio output and input, so the noise went down dramatically.
This way I was able to achieve 36kbps (after ECC) to successfully transmit 64kB

...

Using 36kpbs MODEM throughput, we can transmit 5MB = 40Mb in ~1111 seconds = 18.5 minutes.

Awesome!  Those are very encouraging results.  I am busily working on the Armory 0.92 release, but after that I will have some time to see if I can reproduce your results locally.   If so, I think you deserve a bounty!    I encourage anyone else subscribed to this thread to collaborate with roman.z and see if you can get his solution working and verify that it works.  I pay out once I can use the solution to move a 2MB file between two laptops reliably, as long as the performance is somewhat close to what you just described.

Overachiever's goal:  can you find the right cables to move data back and forth between a smartphone or tablet?  How difficult would it be to demonstrate that you get sufficient performance?  I like the idea of taking a tx on your phone to the safe-deposit box, plugging in a 2-way cable between the phone and computer, and letting them do their thing.  Or two smartphones -- one online one offline.  Granted, android dev is a little out of scope for this bounty, but if we can at least propose a feasible path to getting there and expect that its performance will be acceptable, I think this solution will be 110% complete!



 

[W-M]

Hello roman.z,etothepi and other people.

I am mostly a webdeveloper by trade, but I tinker a lot with audio as well (amongst other things, creating 100% code-generated song covers known as 'Bytebeat'), and might aspire to become a full-fledged synthesizer developer or something of the likes in the future.



This truly is a very interesting idea. I would give it a shot myself, if it were not that roman.z was already doing such great work already; I don't want to make a competition about this and rather think that it's better to collaborate.

Some thoughts I stumbled upon while thinking about from your solution:
-Are you using mono or stereo audio cables right now? From the source cpde it seems to me you're not. Most computers have a built-in stereo input/output, and this would mean that you can effectively double the amount of carrier waves, and thus double the speed.
-You might want to look into QAM instead of using QPSK/8PSK, which basically adds amplitude-shift-keying on top of the phase-key shifting, greatly enhancing the amount of constellations (and thus the amount of data throughput)


Have a nice day,

~W-M

[roman.z]

Awesome!  Those are very encouraging results.  I am busily working on the Armory 0.92 release, but after that I will have some time to see if I can reproduce your results locally.   If so, I think you deserve a bounty!    I encourage anyone else subscribed to this thread to collaborate with roman.z and see if you can get his solution working and verify that it works.  I pay out once I can use the solution to move a 2MB file between two laptops reliably, as long as the performance is somewhat close to what you just described.

Overachiever's goal:  can you find the right cables to move data back and forth between a smartphone or tablet?  How difficult would it be to demonstrate that you get sufficient performance?  I like the idea of taking a tx on your phone to the safe-deposit box, plugging in a 2-way cable between the phone and computer, and letting them do their thing.  Or two smartphones -- one online one offline.  Granted, android dev is a little out of scope for this bounty, but if we can at least propose a feasible path to getting there and expect that its performance will be acceptable, I think this solution will be 110% complete!

Thanks a lot
I will work to improve the APIs, the usability and the documentation of the tools.
May be I'll even prepare an "HOWTO" video, to demonstrate the usage of the modem.

Regarding smartphone<->PC communication: it's indeed an interesting problem. I'll think on it...