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 9231 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.
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.
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
"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.
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!
"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!
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.
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.
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.
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.
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.
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
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
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.
What good is this? If you were working on a way that hams could transact over radio links without Internet access, I could see the value in it, even though actual hams couldn't ever use it due to the prohibition on business transactions. I still can't imagine a use case, though. But to encode a bitcoin address, URI or even an entire transaction into a modulated audio stream seems entirely useless to me.
Entirely useless? Check.
Totally awesome? Check.
Wow. what about broadcasting your URI's as something like a numbers station? You could secretly pay someone with 100% anonymity.
Not any more than you can via an encrypted chat over Tor. Less so, even because I can find your numbers station with the right gear.
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.
I don't know anything about the feasibility,
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.
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
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
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
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
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.
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.
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 ?
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 ?
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 ?
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 ?
Wow. what about broadcasting your URI's as something like a numbers station? You could secretly pay someone with 100% anonymity.
Not any more than you can via an encrypted chat over Tor. Less so, even because I can find your numbers station with the right gear.
What good is this? If you were working on a way that hams could transact over radio links without Internet access, I could see the value in it, even though actual hams couldn't ever use it due to the prohibition on business transactions. I still can't imagine a use case, though. But to encode a bitcoin address, URI or even an entire transaction into a modulated audio stream seems entirely useless to me.
Wow. what about broadcasting your URI's as something like a numbers station? You could secretly pay someone with 100% anonymity.
Have you ever thought what a bitcoin would sound like ?
One of the projects I started before bitcoin came along was a Java modulator/ demodulator for the Ham Radio digital mode called PSK31. (http://aintel.bi.ehu.es/psk31.html).
The basic idea is to convert typed text into a narrow bandwidth signal that you can pump out of a ham radio.
Anyhow, I realised that it could be used to convert bitcoin URIs into an audio stream that you could use to, say, encode a payment URI into an MP3 or any other sort of audio signal.
I have resurrected the code and put it in its current, grumbling, rough as a broken bottle form into github.
It is at:
http://jdigi.net
which relocates to:
https://github.com/jim618/jdigi
I have put it in a separate project as a Java PSK31 codec would be more generally useful than just for bitcoin.
There is a modulator at: net.jdigi.modems.bpsk.BPSKModulator and a demodulator with spectrum analyser (a waterfall display) at: net.jdigi.ui.JDigi (the demodulator is not fully working yet).
It is a pretty experimental idea but if you are interested watch the code in github or drop me a line.
One of the projects I started before bitcoin came along was a Java modulator/ demodulator for the Ham Radio digital mode called PSK31. (http://aintel.bi.ehu.es/psk31.html).
The basic idea is to convert typed text into a narrow bandwidth signal that you can pump out of a ham radio.
Anyhow, I realised that it could be used to convert bitcoin URIs into an audio stream that you could use to, say, encode a payment URI into an MP3 or any other sort of audio signal.
I have resurrected the code and put it in its current, grumbling, rough as a broken bottle form into github.
It is at:
http://jdigi.net
which relocates to:
https://github.com/jim618/jdigi
I have put it in a separate project as a Java PSK31 codec would be more generally useful than just for bitcoin.
There is a modulator at: net.jdigi.modems.bpsk.BPSKModulator and a demodulator with spectrum analyser (a waterfall display) at: net.jdigi.ui.JDigi (the demodulator is not fully working yet).
It is a pretty experimental idea but if you are interested watch the code in github or drop me a line.
Jump to: