The Sound of a Bitcoin

[MoonShadow]

And since it's already java based, an Android app should be trivial.

[1713887660]

1713887660

[1713887660]

1713887660

[1713887660]

1713887660

[jim618]

In this recent thread about SMS and transactions:
https://bitcointalk.org/index.php?topic=51849.0

DeathAndTaxes gave 800-900 bytes for a transaction. The Varicode used in PSK  is ASCII ie 7 bits so that would be about 1000 ASCII chars. That's about 8000 symbols at 250 baud. 32 seconds. Hmm that is too long.

Re frequencies. I don't think you can go under 100 Hz because the things we are interested in would have rubbish bass response. I know on my iPhone it has ok response up to 20 kHz so that might be where to put it. I know I can't hear above 14 kHz

I think it would certainly be doable on an Android phone yes. I have used expensive sine and cosine calls in the code that might need to be swapped for a lookup table but if there are already apps to do PSK31 it must be possible.

[jim618]

On my Mac the sound available in java is sampled at 8kHz so if other machines are similar it would be difficult to sample ultrasonics just in software.

[jim618]

Reading the whole of that SMS / transaction thread the example tx they gave had 404 bytes and could be converted to 460 ASCII chars. At around 8 symbols per char and at 250 baud the transmit time is just under 15 seconds. Still too long but not as bad as 32 seconds.

[jim618]

I got the faster PSK500 mode working today. 

To transmit:
"xb:1KAcxZPRc495U8ZQxnY1ZnhRE46HvA6nUc?a=4.025&l=Bitcoin Booksy1234z"

Sound file:   http://multibit.org/jdigi/sample500.au
Screen shot: http://multibit.org/jdigi/screenShot2.png
Time taken:  1.55 seconds

To transmit the 404 byte tx mentioned earlier at 500 baud would take : 404 * 8/7 * 8 / 500 = 7.4 seconds

In theory you could double the speed again by implementing QPSK rather than BPSK.   This transmits a second signal 90 degrees out of phase with the first (the Q is for quad and B is for binary).   I think I would need a larger brain to write that though.   :-)


It has already all been done !
There are two very interesting complementary projects which implement email for Ham radio that use this same technique (and more).   
They are both developed by the same people:
Java desktop client: PSKMail: http://pskmail.org/
They also have written an *Android* client.

They also have produced a protocol where they add a CRC check to blocks and retransmit faulty ones.   Looks pretty impressive.

[cbeast]

+
Using one-way media for BTC sending is awesome. Moon lasers, dog whistles, shortwave, semaphore, secret handshakes, and dance moves, are just a few ways to use Bitcoin.

[jim618]

@cbeast - that made me laugh. :-)

[MoonShadow]

+
Using one-way media for BTC sending is awesome. Moon lasers, dog whistles, shortwave, semaphore, secret handshakes, and dance moves, are just a few ways to use Bitcoin.

First off, it's not a one-way media.  Every smartphone has both a speaker and a microphone.  Second, using psk500 or something similar to transmit complete blocks into a specific shortwave frequency would allow specialized devices that don't have or need direct Internet access to collect a blockchain on a continuous basis.

[jim618]

Andreas Schildbach (aka goonie on this forum), the author of Android Bitcoin Client, has been doing some work on encoding bitcoin transactions as QR codes.

Mainly for fun, I have scanned one and re-encoded it into a sound file using my PSK500 codec.   Here it is:

http://multibit.org/jdigi/sample_transaction.au
(6.9 seconds)

This is quite a short transaction (258 bytes).  According to Andreas, they are typically around 500 bytes but can be as high as 1200.


It is a bit too slow to be practical yet but is doable.

[Andreas Schildbach]

Actually to clarify this, Transactions can be much larger than 1200 bytes. However, the typical POS transaction will hopefully not be larger than about 1k, mainly depedant on how many inputs from how many addresses are spent. Clients can do their best to keep sizes down. I hope this number won't go up as Bitcoin gains traction.

Anyway, I found out transactions have some potential for compression using GZip (up to 25% reduction).

[BTCurious]

Screen shot: http://multibit.org/jdigi/screenShot2.png

It looks like you will probably need some marker that says "End of data", otherwise you get this gibberish behind your info.

[jim618]

Agreed.
Also at the moment there is no lower limit to the signal it 'believes' is data. It needs a 'squelch mode' to ignore noise. This needs a bit more work to figure out a level that ignores noise but captures signal.

[MoonShadow]

Agreed.
Also at the moment there is no lower limit to the signal it 'believes' is data. It needs a 'squelch mode' to ignore noise. This needs a bit more work to figure out a level that ignores noise but captures signal.

That's going to be a real problem for audio, because PSK's strength is in the ability to produce a coherent data stream that is below the threshhold of human hearing, so anyone talking out even in the mall's promenade is going to trip the sqelch anyway.  If the sqelch limit is set high enough to exclude such nearby talk, the effective range of communication might be too limited.  More than a squelch, there needs to be a DSP filter code that simply excludes anything beyond it's assigned frequency range.

[BTCurious]

There are a few things you could still do:
Add a START and STOP marker.
Add a checksum.
Add a Signal to noise measurement -- clearly there is signal. How much other noise was there, compared to if we only had measured the signal? Maybe a threshold could be set for this?

[jim618]

I have just been looking at the DSP code (that I have inherited from the znuradio code).

What he does is:
1) Filter to the frequency window of interest (not sure how wide the bandwidth is) using a couple of low pass filters.
2) Finds where in the (time) transmission window for a symbol there is a maximum phase difference compared to the same point in the previous symbol - this is equivalent to where the PSK phase reverses + 1/2 a symbol transmission time.
3) Tweaks where this position in the transmission window is iteratively using an algorithm I don't understand yet.   There is a preamble in the signal that is there so you can sync up to where the phase is reversing (getting the beat, so to speak)
4) Works out a 'quality measure' of the signal using the phase and a metric I don't understand yet.

There is a bit of DSP and coding for me to learn yet !
If you are interested in DSP it is pretty interesting.

[jojkaart]

if you've got 2 smartphones and a way to encode transactions as sound, then it sounds to me that it should be reasonably simple to just match the phones so that one phone's speaker is matched with the other's microphone for contact audio. That way, even reasonably "loud" signal would not really be audible to anyone nearby, except for the other phone. If you can somehow squeeze enough data into the audio to allow data transfers to complete in under a second, this could be nearly as handy as NFC.

[MoonShadow]

If you can somehow squeeze enough data into the audio to allow data transfers to complete in under a second, this could be nearly as handy as NFC.

More, since NFC devices today can't actually communicate to each other in any kind of ad-hoc fashion, and thus require the kind of infrastructure that is to be found at a retail point-of-sale.  That, and my phone has a speaker and a mic, but not a NFC transceiver.  It's not that NFC is incapable of ad-hoc, just that (much like wifi in smartphones) such direct  communications require root access even if the hardware is capable of doing so.  I wonder, considering all of the people who are willing to 'bump' if stacking your cell phone would become as reasonable an activity for those who wish to transfer bitcoins directly.  I still consider a Dash7 transceiver a more viable long term solution, but this is certainly a workable one with current hardware.

[jim618]

I agree with MoonShadow - in the longer term you would want to use Dash7/ WiFi/ bluetooth/ NFC but for the current crop of phones QR codes and sound transfer are workable alternatives.  

Kind of:  It will do for 2012.

If I can get the codec reliable enough, I am tempted to add it into MultiBit as another way of transfering bitcoin URIs in and out in addition to the existing QR codes/ swatches.   At under 2 seconds to transfer it I think it is acceptable and I think Java sound is supported on all of Mac/ Win/ Linux (I will have to look into that).

Bluetooth would be better to be honest - I have also volunteered to look into that but it needs a bit more £££ investment (new Android phone to buy ! )  

There are not many phones with NFC in yet - I think there is just the Samsung/Google Nexus for Android and no iOS devices yet.

Edit: And if the protocol/code to do the transfers is well written we should be able to slot in a new physical transport layer as they become available.

[MoonShadow]

@jim618

I reiterate that an android client that can communicate 'directly' to another such client using wifi, via a piratebox or any other form of mutually accessible wifi hotspot, can be accomplished right now using a multicast/broadcast client-server setup.  If both phones can connect to the same access point, it doesn't even matter if the access point has Internet access (or does, but blocks ports) because one phone can set itself up as a 'server' and announce itself across IP broadcast so that the second phone can see it, connect to it via it's temporary, local IP number and send the data.  There are android apps that use this trick very effectively for transfering files to and from a home pc over a home wifi network by letting the pc log into the phone as if it was an ftp server.

Of course, a piratebox with a local bitcoind would make this trivial for clients that don't have this capability also, even if the local bitcoind cannot or does not have a blockchain.

[jim618]

@MoonShadow.

That is interesting - I like the idea of a PirateBox running bitcoind especially.

RE: WiFi direct connections phone to phone.

I think I am going to buy a Samsung Galaxy phone as it has WiFi Direct - point to point transfers.
http://mobilesociety.typepad.com/mobile_life/2011/03/wi-fi-direct-coming-to-an-android-phone-near-you.html

With all the technologies that are becoming available it is 'only' a matter of making it actually all work!   :-)