Topic: The Sound of a Bitcoin - page 2. (Read 9186 times)

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.

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.

In this recent thread about SMS and transactions:
https://bitcointalksearch.org/topic/sms-big-enough-for-bitcoin-payment-instruction-51849

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.

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

Okay, I have to admit, that's just slick.  Sortof like NFC by sound alone.  But how long would it take to transmit an entire transaction at psk250?  Could the carrier be set so that it's all below human hearing?  Or would that even be desireable?  Certainly don't want it set too high, for if it can be heard the higher pitches are annoying.

I got the faster mode PSK250 working tonight so to transmit:

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

is down to 2.95 seconds.

http://multibit.org/jdigi/sample250.au

I did some work at the weekend on my Java sound codec. (http://jdigi.net)
It can now convert ASCII text to sound and back again.

Here is a sound file and screenshot of the text "xb:1KAcxZPRc495U8ZQxnY1ZnhRE46HvA6nUc?a=4.025&l=Bitcoin Booksy1234z" being transmitted and received with a carrier frequency of 1000Hz.   (I'll explain the text in a moment).

Sound file: http://multibit.org/jdigi/sample.au
Screenshot: http://multibit.org/jdigi/screenShot1.png

Time taken to transmit text: 5.75 seconds.

Format of transmitted text
For the text, it is based on a bitcoin URI but I have abbreviated the usual 'bitcoin:', "amount", "label" to shorten the length.
I am thinking:
1) Start the text with an ASCII 0x02 STX - start of text - shown as the letter "x" above.
2) Separate the end of the main URI text from the checksum with ASCII 0x03 - end of text - shown as letter 'y'.
3) Add a 4 character checksum for error detection (or something more sophisticated to give some error correction) - shown as text '1234'
4) Finish the message with ASCII 0x04 - end of transmission - shown as letter 'z'

Bandwidth
If you look on the screenshot at the spectrum at the bottom (called a waterfall because it scrolls downwards) you can see that the signal is using about 500 Hz of bandwidth.   It is PSK125.
Looking on the Android market place I see there is an existing PSK codec available as https://market.android.com/details?id=com.wolphi.psk31&hl=en.   The top frequency on its waterfall is 2000 Hz so let us limit ourselves to that.

With bandwidth of 100Hz - 2000Hz you could:
1) Frequency multiplex the transmit signal two fold to half the transmit time - 2 x 500Hz = 1000Hz.   Transmit time < 3 seconds.
2) Have a 'back channel' (perhaps PSK63 = 200Hz bandwidth)

The back channel would be used to acknowledge the message has been received ok.

Usage
I am thinking it would be practical to:
1) Have a standalone wallet, "the wallet", that has a microphone and speaker and a USB connection.
2) You use it to literally talk with a networked device, "the host", as follows:

2.1) Host squawks bitcoin URI to wallet to ask for some bitcoin.
2.2) Wallet acknowledges bitcoin URI, asks user if they would like to pay
2.3) User agrees to pay, wallet signs a transaction and squawks it to the host
2.4) Host acknowledges transaction and forwards it to the bitcoin network (it will always do this as it wants the money!).
2.5) Wallet keeps track of the transactions and perhaps you sync it at home via USB so that it checks the blockchain for the transactions and so that you can put some more cash on it.

A little standalone wallet with a microphone, little speaker, small keypad and display would not cost very much.   You could also have it as an Android app.

p.s. I also wanted to add that the jdigi code is based on the znuradio code :
Copyright (c) 2004 Leigh L. Klotz, Jr. <[email protected]>  
This is MIT licence.

Don't forget that if there is a built-in mobile phone app that can respond to a "sonic swatch" (great name!) then it could monitor the phone conversation and quietly add it to it's address book.

"Thank you for your order, sir. How would you like to pay?"
"With bitcoins, please."
"No problem, sir. Since we're on the phone do you support sonic swatches, and is it active?"
"Yes, and hold on while I switch it on.... done."
"Thank you. Sending now, it will have an address starting with 12qk for 3.25 BTC."

"The swatch has been sent, sir."
"Hold on... Looks OK... sending... and done."
"Thank you, sir. I can see an unconfirmed transaction against that address. Once it has fully confirmed we will send you an email to confirm the despatch details. Is there anything else I can help you with today?"

Imagine if you could have that conversation with your local railway station car park management company. Once they've sent you their address, you don't need to phone them again. It's unique between you and them so can be tied into their number plate recognitiion system.

There are loads of opportunities for a system like this. Good work, Jim!

I really value your input, but I have to partially disagree with what you wrote.

Conducting business over amateur radio bands is officially prohibited, yet pretty much every QSL request I've seen included "green stamps". Please think of the few bitcoins transmitted a replacement for the "green stamps".

The problems you describe with the path-sensitive reception problems are all related to the non-coherent receivers using crude demodulators. With a mix-signal FPGA in the head-end you could get a phase-coherent rake-receiver working like charm for almost no additional money.

Complementary to the above the synthetic phase-array antenna with some modulation scheme offering LPI (low probability of intercept or low probability of interference) would safeguard the transmitter, again thanks to the mixed-signal FPGA driving the final.

Moreover I'm not advocating breaking any laws. What I'm advocating is a change in the way amateur radio is governing itself. This is the decade of change. AARL and others started dropping the fist & ear CW requirements. And I heard that they reaped the fruit of one of the highest number of new licenses granted in a year. The whole landscape is going to change with the drop of mandatory CW.

Last, but not least: FCC has no jurisdiction over the entire globe. What me (and others) are proposing are way less harmful to all the spectrum users that the current long-distance cordless phone transmissions emanating mostly from CIS and Far East.

Overall, I do believe that the change in the access to the radio waves is possible.

As far as using soundcard modes to encode data into an actual audiostream, the number of mics and speakers (and people who talk) is counterproductive, as it basicly all creates a high level of background static for the signal to overcome, and PSK31 doesn't exactly promote a pleasant feeling in human listeners.  And it's also obvious to anyone who has heard it before.  433mhz is a relatively quiet band, and can mesh well over useful ranges, unlike wifi bands.  I consider the success of Dash7 devices in smartphones to be the greatest possibility for Bitcoin, and a Dash7 specific p2p texting app to be the killer bitcoin app there.  Imagine that even a small percentage of smartphones had dash7 radios in an urban area such as NYC, and you wanted to send an encrypted text to your friend.  You know your friend's dash7 id (or rather your phone does) and you use bitcoin to pay very small amounts to the smartphones of those who "hop" the text to it's destination (or forwards it across the Internet on your behalf, if that is more efficient) and your text could cross up to 7 or so kilometers without any infrastructure in place at all, or you having a service plan.  This would also work very well as an unstoppable communications medium in the event of a power outage (or Internet outage) for emergency communications.  It would make efforts like Serval look downright primitive in comparison.  What if, instead of smartphones with a monthly service fee, someone starts making smartphone sized android tablets (already done) with wifi & dash7 radios (not done) and young people start using them to communicate directly using texting & bitcoin in a modern version of the CB radio craze of the 1970's.

I admit that a moonbounce transaction would be just geek chic for the hell of it, but from a practical standpoint, using an amateur radio sat to do the same thing would be at least as location anonymous, which is to say not very much from any nation-state entity that has sats of their own.  And the location anonimity is exactly why we have to transmit our callsigns regularly, anonymouns transmissions are not permitted, and neither are business transactions.  Either of these would get my license suspended in a heartbeat.  I've had mine suspended for forgetting to update the FCC when I moved two miles away.  Bitcoin transactions over ham gear on ham bands could actually violate international treaties, and then get me arrested.  I don't like the risks there.  It's not like it used to be, it's technically quite easy to triangulate a transmitter broadcasting in the frequency ranges capable of exiting the troposphere to make a moonbounce or sat repeat.  It's the very low bands that remain location non-specific, simply because their wavelength is so long that a hidden antenna in an urban environment wouldn't implicate anyone in particular.  Which is also why numbers stations use the shortwave radio bands.  And soundcard encoding type modes, such as psk31, don't really do well with either moonbounce or a polar propogation path, because both forms of indirect (non-line-of-sight) propogation can arbitrarily reverse the orientation of the signal, the practical effect being that the signal changes because phase shift keying involves the intentional reversal of the orientation of the signal. 

Entirely useless?  Check.
Totally awesome? Check.

Maybe, but in theory tracing a computer on a network is easier than finding a receiver within the range of a transmitter. As far as anyone listening, I'm the only one with the code book from jim618.     
I suppose your basically right though, The Internet has replaced numbers stations for spies.  But I still like the idea. Kinda like I like the idea of a cigarette lighter installed on a computer.

It isn't feasible immediately today. But the feasibility is just around the corner. The main required components would be mixed-signal FPGAs. Xilinx had already started sampling them (Kintex-7) and has plans for even cheaper version Artix-7. Costwise they would be replacement for Spartan-6 family and lower end of Virtex-6 family. Xilinx Spartans is what you'll see both in currently available Bitcoin FPGA miners as well as various commercially available SDRs (software-defined radios).

Mixed-signal FPGAs are what it takes to cheaply commercialize some technologies that thus far were eiher military or research: low probability of intercept, synthetic aperture antennas (nowadays used mostly in radars),  pre-distortion stage to compensate for nonlinearities in linear power amplifiers, etc.

Haha, awesome. I don't know anything about the feasibility, if it is do it. If not write articles about doing it for the fun press.

Guys, why going underground and audio waves?

May I suggest that you look up? E-M-E (Moon bounce) is exactly what Bitcoin needs to free itself from the strangehold of the Internet providers. Just come up with the outline of the broadcast protocol for Bitcoin over PSK(whatever) bounced from the visible side of the Moon. Completely untraceable commerce lies ahead.

Even if you don't get a working implementation you'll get a round of applause from your presentation at the next year's Bitcoin Conference.

I tried to plant this idea with Lolcust and his planned money laundering operation with GeistGeld and Tenebrix. But he's more of a graphic designer and you guys have the required amateur radio background.

Support the free trade on Earth by banking on the Moon!

Actually, Lolcust's idea of "The Darkside Transaction Mixer" could be implemented as a literal "Underground" extension to the global Moon-bounce protocol. Use Moon-bounce to relay the transactions above the ground and use the ultrasonic carrier to relay the transactions underground.

Please don't abandon this concept!

https://bitcointalksearch.org/topic/m.556294

Cool but I don't see any usefulness.

This did inspire me to make a vanity address that is my HAM callsign, though

Yes you are right PSK31 is too slow but it is the easiest mode to begin coding up.

A bitcoin URI is roughly a kilobit, so if you can use, say, 10kHz of audio spectrum you should be able to get it transmitted in a second or so.

My understanding is that PSK63 and PSK125 are fairly common.   There is also a PSK250 - do you know why it is not widely supported in Ham software ?   Is it just 'pushing the envelope' too much ?

Anyhow, PSK31 takes up about 100 Hz of spectrum, so PSK125 must take up - say - 500 Hz.   You could frequency multiplex the signal say 10 times in the audio spectrum (500 Hz gaps) so your signal rate (with not too complicated algorithms that I *think* you can decode in real time in Java) would then be 1250 baud.   That seems to give you a fast enough data rate for a kilobit transfer in a second or two including a fair amount of data correction.

You are right - there are lots of other possible ways of transmitting data.   Probably myriads.   I guess my interest in audio is that it is so ubiquitous.   How many microphones and speakers are there on the planet ?

The PSK* family I know there are already open source C codecs for so they seem a good choice for wider compatibility.

You are clearly interested in the 'transport layer' i.e the actual way the data gets from A to B so I am interested in what you think.

I can't imagine how even an ultrasonic chat system would be worthwhile even in a crowd.  A piratebox (http://wiki.daviddarts.com/PirateBox) would serve this function better in that use case, and when Dash7 radios (http://en.wikipedia.org/wiki/DASH7) are half as common in smartphones as wifi, I could text chat across a crowed city block or two, with a building in the path.  And PSK31 is so slow for this, that it would take many seconds to transmit even a single bitcoin address, and a lot can change in the signal in that time unless the two parties are close enough to each other to just simply talk like real people.

(I'm a ham too, BTW)

The question "What good is this?" is a very good question !


The ham radio connection is just how I got started with it.   It is really about encoding a data signal into a modulated form that we can both encode and decode in software (no special hardware required - as long as you can do a 1024 point FFT at your data rate in software you are good to go.).

My original idea for the code many moons ago was to use it for an ultrasonic chat system that would work on mobiles where you did not have network access (for instance the London Underground).   I wanted to finish off the codec as it was about 2/3rds done and just have a feeling it might have a bitcoin-ey application.

Sound is a pretty ubiquitous medium for transfering information - why should we *not* have access to it !  
Once you have software to encode/ decode a signal onto a carrier wave, well, what can't you do ?