Just dropped you a PM...
We would like to see if a collaboration with our Hamradiocoin team might be possible.
https://bitcointalk.org/index.php?topic=856464.new#new
Topic: The Sound of a Bitcoin (Read 9161 times)
Yes I think I will try putting it into MultiBit as an another input/ output option.
I plan to revamp the UI in the New Year so will add it in then.
Good marketing idea to encode a few private keys and releasing the sound publically. If you can decode it, you can have the BTC ! :-)
I plan to revamp the UI in the New Year so will add it in then.
Good marketing idea to encode a few private keys and releasing the sound publically. If you can decode it, you can have the BTC ! :-)
broadcast a few BTC explaining what it is... and see if they get cashed in!
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!
"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!
+1
I just want to draw your attention to the fact that this is in principle very similar to the data transimission used for fax copiers.
And now look how widespread this technology still is in the industry and private business despite much the internet and much faster data transmission technologies!
Personally I think that the use case pointed out by Gary will be the most used.
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).
It is such a nice combination of low tech and high tech.
Jim, I want to encourage you to implement it in MultiBit and see if it gains followers.
@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! :-)
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! :-)
@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.
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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.
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.
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.
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.
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).
Anyway, I found out transactions have some potential for compression using GZip (up to 25% reduction).
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.
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.
+ 
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.
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.
@cbeast - that made me laugh. :-)
+
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.
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.
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.
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.
Jump to: