Topic: [BOUNTY - 25 BTC] Audio/Modem-based communication library - page 4. (Read 11820 times)

Great!  I'm excited to see someone taking a serious shot at this, and hopefully something will come out of it.  Admittedly, Casascius has significantly lowered my expectations, so any positive progress seems all that much exciting

By the way, if you are going to not put it into public domain, please do realize that part of the reason I'm doing this as a bounty is in exchange for giving me unrestricted rights to the code to use in Armory.  Armory is AGPLv3, but if I ever decided to do some kind of closed-source add-on (or, say, corporate version), I don't want to have to get approval from other copyright holders who have less than 1% contribution (no offense).  Therefore, if you are going to put it under a license and still want the bounty, I request some kind of verifiable statement of transfer (GPG email is probably fine). 

We'll deal with it when there's bounty-ready code to transfer, but I just wanted to throw that out there so that there's no surprised.  A 20 BTC bounty is a lot (for me) but that's why I'm offering it.

OK, you got me really interested in this, but I haven't done any DSP stuff in a long time... So tonight I coded up an extremely rough 16-QAM modulator/demodulator (& in python too!) Right now it just writes to and reads back the samples in a file, but pyaudio is already working on the speakers side so you can hear the data. Currently I'm in the mid 1980s, at 4 kbits/second. It wouldn't work at all in the real world though, maybe kinda through a cable. But the proof of concept is there.

The code is at https://github.com/notespace/python-scripts/tree/master/python-qam, and you can run it:
And it should show a nice diagram of the received constellation.

I'll release it under AGPL-3, just like Armory. There is still a ton of work to do to make it robust of course, and huge amounts of cleanup; not to mention choosing some standard data rates and implementing handshaking for real bidirectional comms. We'll see if I get any time to work on it.

Well anything in C++ would work, as it's trivial for me to pull it into python.  I just thought that python would be "easier" since it creates a nice platform-independent interface to the audio devices.  But if you created a C++ implementation that works for one platform, I'm sure it can be adapted it to my needs.

Not even sure how I came across this thread.... interesting, so, I'll throw in my two cents.

Data over audio really isn't all that complicated folks.  It's been done many many times.

Modem stuff obviously is not the best to emulate, since everything about it is designed for use on POT lines, which have very limited frequency response.

For example, there is an open source fax patch for Asterisk that emulates a fax modem over VoIP. (http://www.zoiper.com/foip/ for those interested)  But its limited to ~14.4kbps max I believe.

PC sound cards and smart phone sound cards and the like are much higher quality in most cases.  Granted, you probably would need a decent effort to get decent speeds, still, but, it's certainly not impossible. I'd say 64kbit/sec (4MB in ~8 min) would be reasonably easy to achieve even with mono audio, and even with single direction comm.  Granted that this would work best as a two way link (speaker and mic on each device).

I've actually considered using audio data transfer for another project, but, never got around to making the code.  And I'll never write something like this for python, so, not going to be much help here anyways.

Just pointing out that it's possible!

-wk

Actually I am getting closer to this possibility already...

Think of a "kindle like" device that has an "animation" capability built in but *zero* internet capability (I have one and it was cheap and was able to store QR codes with around 1K on each image that could be read by a webcam with no problem - and yes it's just a starting point - am sure it could be vamped up).

Fair enough.  You're right I was a little hasty in adding you to the bounty.  I should remove that.  Honestly, I wasn't sure this was going to work, and the original bounty was intended give some incentive for someone to try.  I am not confident enough that this is so doable as to bet 20 BTC in the event that I was wrong -- I was simply willing to pay if it led me to something usable.

But to be fair, to say it works better than RS232 is a bit extreme.  The point of this exercise was to demonstrate that there is a reasonable alternative to RS232 -- one that is effectively isolated other existing modes of transfer (and thus have infrastructure/autorun stuff to assist with it that might be a security vulnerability).  My goal was not to have it perform faster.  It just has to transmit at least the same order-of-magnitude of data reliably (1/3 or more?), since that would enable me to implement the capability.

You are saying "I bet no one can create a better xfer protocol on audio than RS232."  That's not my goal.  My goal is "create an alternative that has similar performance."

But I'm not willing to bet 20 BTC that it's strictly possible, I was only offering 20 BTC for a working solution (with probably partial bounty for someone demonstrating that it can't).  But I don't want to add another 20 BTC to the failure case.

Just to be clear, before I'd consider any effort a success for the purpose of my "bet" offer statement, I'd require that one successfully implement an audio-based bidirectional data interface that exceeds the utility of an RS232 port and that is not significantly more difficult to set up than a null modem connection.

Typical max of RS232 ports on computers is 11.5 kilobytes per second, with an error rate that is substantially zero.  This would have to be achieved or exceeded, with a zero error rate.  (RS232 can go higher, but 11.5 KBytes/second is the typical max that the hardware is commonly configured with as shipped on PCs, a capability that can be assumed to exist on pretty much every PC with a serial port, and therefore the value I will use).

I'm not offering to pay 20 BTC for a demonstration that someone could get some data over a sound card - since I have no doubt it's possible.  Also, my statement that I'd be willing to "bet" is not a public bounty, but a private offer that I made to etotheipi and is technically contingent on him accepting it and being willing to pay me 20 BTC in case of failure... a restriction I would probably relax in the face of overwhelming evidence I was wrong.

It needs to support all platforms (since the goal is to get it to work in a platform-agnostic way).  Python, as usual, is pretty good about handling the platform-dependent details, and gives you a uniform interface to the audio objects.  I suppose to be supported on Android, it would need a custom java implementation, but that can be dealt with after the original implementation is demonstrated.

This needs to be accessible from python.  If it's a C++ implementation ,I can use swig to access it from python like I do a lot of other things.  But my guess is that you would want to do it in Python, and SWIG-in libraries that will do quick encoding/decoding for you ...?  (i.e. python handles the interface to the audio devices, but hands off all the data to a fast C++ backend for doing encoding/decoding).

I'm not entirely clear about the best way, but it definitely needs to be supported on Windows, Linux and Mac... under the assumption that the audio devices are already configured correctly.

I would recommend doing some research, but don't go too crazy with it yet.  Report back any revelations you have before actually trying to implement it -- if this looks like it's going to terrible (like difficult hardware support, requires complicated algorithms for handling various line qualities, has problems with feedback, etc... then we should probably think about another way).

On the other hand, there's nothing wrong with developing a pseudo-serial connection over audio.  Technically, this doesn't have to be bitcoin- or armory-specific.  As casascius suggested, perhaps the thing to is for me to write the communication assuming that there is a serial-like interface, and then it could operate over serial ports, IR, TOSLINK, or audio, as long as there's a "pipe" for it.

What platform/s would this need to support in order to collect the bounty?

[EDIT]

"only allow for sending and receipt of ASCII data"

Why no binary?

Modems are so slow, because by standard, telephone signals are cut off after 3400(4000) hertz. And you can use only 7200-8000 hertz quantization. This is mono signal, and because of bad cables you can use no so many bits per quant.
33.6 uses 2400 hertz and 14 bit
56 uses 8000 hertz and 7+1 bit

With common audio cards you have 44100hz*16bit*2ch=1411kbps.
Theoretical maximum is about 160 Mb per 2 minutes.

Whole industry was involved because people wanted to get a maximum theoretical wire utilization. With this task all following bits are harder then previous.
We need only 160/5 = 3% from the theoretical bandwidth for done this task. This is a way simpler than 33.6 on a crappy telephone line.
We can use 97% from the theoretical bandwidth for code correction. Are we really should worried about all this stuff with so huge reserve?

Yeah, I recanted that statement in a later post, I guess I should update the top post.  If I do go with the audio solution, the rare 5 MB will just require patience on the part of the user...

Would this help?

http://www.slideshare.net/Sudar/transfering-data-using-audio-signal-in-android

http://mobileembeddedsystems.blogspot.com.es/2010/03/data-transfer-over-audio-port.html

* Data to move   5   MB
* Data to move   5242880   bits
* Max audio date rate   9600   bits pr sec
* Time to transfer data   546,1   sec
* Time to transfer data   9,1   min

Add some error correction and stuff we are talking 15 min to move 5 MB.

It is not practical to transfer using audio.

yeah, i was going to suggest animated QR codes. but every demo i've seen so far has a really slow frame rate.

By the way, one the other reasons I was so set on audio, was because I also wanted to enable smartphones to be used as the offline signing devices.  Take an old smartphone, disable WiFi, remove the SIM card, and then only connect it via audio.  That seemed to be a nice bonus to the audio solution (despite having to buy some adapters).

Now, casascius is doing a good job of persuading me that the challenges of audio are too great, and the risks of serial ports can be mitigated.  I'll be doing more research, but my question then becomes:  is there any hope for the smartphones?  Obviously, you can move the microSD card around, but that's what I'm trying to avoid in this thread/bounty.  What other options are there besides QR codes?

Or is there a way to make QR codes work for real?  If I have to move 1 MB, could I perhaps create a tagged list of 50 QR codes and play them in a video (looped), and let the other device just keep watching until it picks up all of them?  This is less of a problem than I originally mentioned to CIYAM, because you only need one webcam/wire, and there's no confusion about which device to point where (obviously, you can't point a smartphone's camera at itself).

There's gotta be a better way!  

No. and one needs exclusive access to the port, for things to work as expected.

My original concern was that most linux systems still have tty logins enabled by default over serial.  Given that most users' username/passwd will be the same as one of the ones in their firefox/chrome saved passwords file, this could actually be the cause of many people losing coins.  Lots of people will do the minimum amount of work to just hook up the serial cable and use it if it "works".  Meanwhile, an attacker may be able to waltz onto the offline computer and have their way with it, while the user sits snugly on their couch thinking there's nothing that could go wrong.

But Casascius rightfully pointed out that many of these SNAFU conditions are detectible.  A user may not want to read even a simple set of instructions to set it up properly, but if I can actually disable offline Armory until the problem is fixed, then it makes it much more feasible.  I'll be thinking about that, and doing some research on what it would take to detect and close this attack vector.

Also, audio "listening" is not the problem.  None of the data being transferred is secret.  It's just transaction data that will end up in the blockchain, anyway.  And even if it was, 99.9%+ of the threat vector is not threats in the same room* (if the threat has physical access to your system, you're probably already screwed).  It's from having to link the offline computer to the internet (indirectly) and exposing it to the entire world of hackers and viruses.

*EDIT:  I shouldn't generalize:  I'm sure there are applications/scenarios where physical threats are a concern -- but the vast majority of users are not them, and the ones that do care know they need some kind of extra security measures.

why not a stupid old serial cable? why the sound stuff? sound stuff is much vulnerable, as it can be listened to.

Here's old tech, that can work over about any fidelity including phone as long as there aren't wholesale dropouts:

http://en.wikipedia.org/wiki/Kansas_City_standard

It uses two tones: one cycle of 1200hz = 0 bit, two cycles of 2400hz = 1 bit. This is 1200 baud, so it's going to be good for things like an audio address exchange, not for 10MB of data. One could use different frequencies for full duplex signaling (ie the receiver could send "ready to receive your transmission" or "error, retransmit" messages with 1700/3400hz audio). Sounds like this: basicode.wav.

Here is an encoder/decoder written in Forth for the original 300 baud version: http://www.netbay.com.au/~dxforth/#kcs
Here's one in perl: http://www.cse.dmu.ac.uk/~mward/martin/software/index.html#CUTS

This is very easy to program for sending data. Just make a LUT of the two waveforms, and dump the data out as a 12KHz sampling rate wav.

For reading the data, you will need a simple fft able to discriminate which is the dominant tone and a transition-following clocker.

For actually coding, one would look at simple coding like RLL, with words encapsulated with ECC or sequence numbers. Data could be packetized into IP MTU-sized packages.

One must remember how slow even the height of v.90 modem tech was - it would take 20 minutes just to download this web page.

Hold your phone up to your computer speakers to transfer data...

S/PDIF / TOSLINK: This would be another avenue that I didn't think of, with the only real deal breaker is that support for it isn't ubiquitous - but not rare either.  You couldn't depend on two arbitrarily chosen computers having support for it to recommend it as "the" solution.

S/PDIF / TOSLINK, being a digital audio link, would work just fine for digital information, and is often used for one-off data transfer applications.  As an example, I have an audio receiver whose firmware you can flash by downloading a WAV file containing the firmware, burning it to CD, and playing it through a CD player into the S/PDIF input while holding down some magic keys.  Because no analog conversion occurs anywhere along the process, it works.  (Of course, there must not be any kind of modification to the data along the way.  For example, the CD player can't have its own volume control, and the CD burning software can't resample the audio in any way - they tell you "don't burn with Windows Media Player or it won't work" for this very reason).

TOSLINK is completely another story for another reason.  TOSLINK is essentially the same signal but over a low-grade fiber optic cable - would definitely add a serious "cool" factor to the air gap, even if someone had to pay for hardware to add it (and there'd have to be two fiber "cables", one per direction).  In fact, so cool that it would be worthy as a way for companies to say "Yeah, our wallet is optically isolated from the internet", even if they laid out a couple hundred bucks in the process to get it.

As 2112 mentioned, TOSLINK definitely has the bandwidth to sustain the kind of transfer needed for this application.  You probably can't expect bit-for-bit copy between computers (the sending computer will be recoding the audio to implement any volume or EQ controls), but you can expect a high degree of usable bandwidth without having to deal with things like losing part of your spectrum to noise or having to deal with detecting and rejecting noise.

Regardless, it's still probably best implemented as an application that primarily talks to a serial port, with the TOSLINK functionality provided in the form of a driver or program that does the audio transformation in a separate process and provides the data link in the form of a pipe or a fake serial port so the application itself isn't concerned with the physical layer.