If Kryptoradio in Finland can do broadcasts in only a 7.5kbps channel. Then instead of only broadcasting in UHF line of site. The same service could broadcast on SW/LW/MW over digital AM to much larger regions from a single transmitter using Digital Radio Mondiale technology. A single LW transmitter could potentially give coverage to the whole of Scandinavia.
Using the Digital Radio Mondiale codec you could broadcast =>7.1kbps over a 5kHz channel on SW/MW/LW. Although renting SW transmitter broadcast time costs around $25k per month for 24/7/365 broadcasts. 5kHZ though is about half the bandwidth that AM stations use on MW.
Another idea to look at terrestrial broadcasts although this time with full duplex is UHF IEEE 802.11ah meshnetworks. With a good external antenna you could get very good local range at 900Mhz so it could really work well for mesh-networking. The first IEEE 802.11ah chips are supposed to come out next year while the protocol should be finalised by 2016. Plus it's an unlicensed band so no one would need a ham license to set up a low power node.
Topic: Bitcoin and ham radio (Read 4536 times)
ex-G0--F (removed my call sign) here... i was into Ham radio 20 year ago (ouch), I used to be on Packet Radio on 144mhz and also did HF packet (which didn't work very well). I used to run a repeater 20 miles away which used to pass traffic to somewhere else, it was okay for listing your 'email' as it was back then, took ages to get a message and the packet radio would be stuffed if it did hear another transmission. If I was at the repeater and turned on the radio you would hear hundreds of packet radios trying to transmit all the time, it was that slow, just a big pile up of radio transmissions and the strongest would be king. The problem was is the amount of time it took before re-transmission.
Here is a video, about 4 minutes in you can hear the signals.
https://www.youtube.com/watch?v=9dfqPQui4NU
Other technologies like RTTY/PACTOR/AMTOR could allow you to do it over HF, AMTOR had the abilities to locking a connection so you could keep talking and have mistakes corrected. This is PACTOR, I didn't use it myself but you see a file transfer going on https://www.youtube.com/watch?v=RaAKJRfaKiE
Here is a video, about 4 minutes in you can hear the signals.
https://www.youtube.com/watch?v=9dfqPQui4NU
Other technologies like RTTY/PACTOR/AMTOR could allow you to do it over HF, AMTOR had the abilities to locking a connection so you could keep talking and have mistakes corrected. This is PACTOR, I didn't use it myself but you see a file transfer going on https://www.youtube.com/watch?v=RaAKJRfaKiE
how about a radio that calculates the frequency randomly for every packet by continuously SHA256 hashing an initial seed.
that way if you want to communicate with someone who knows the initial seed you can do it without the authorities knowing which frequencies are being used.
that way if you want to communicate with someone who knows the initial seed you can do it without the authorities knowing which frequencies are being used.
There's also the new 802.11ah: WiFi Standard for 900MHz coming out.
This may work better for WiFi mesh-networks.
Quote
EE Times says the spec aims to support a range of options from throughput of 150 Kbits/s with a 1 MHz band to as much as 40 Mbits/s over an 8 MHz band. Distances supported could be about 50 percent longer than those of the streamlined 802.11n - http://www.dailywireless.org/2013/08/30/802-11ah-wifi-standard-for-900mhz
This may work better for WiFi mesh-networks.
6 blocks/hr * 1048576 * 8 = 50331648 bits/hr
50331648 bits/hr / 3600 seconds = 13981 bps = 13.981 kbps (with no additional overhead)
For 7 blocks/hr, 16.311 kbps (with no additional overhead)
These rates exceed conventionally available AX.25 packet radio / TNC throughputs for HF and VHF ham bands (generally 300 baud FSK for HF, and 1200 baud AFSK or 9600 baud AFSK for VHF/UHF). Either use of higher frequency bands or a custom modulation format that would tend to have a bandwidth exceeding amateur radio rules in most ITU countries on HF, VHF and UHF frequencies would be needed. At that point you might as well just set up a 900MHz, 2.4GHz or 5GHz 802.11 link.
50331648 bits/hr / 3600 seconds = 13981 bps = 13.981 kbps (with no additional overhead)
For 7 blocks/hr, 16.311 kbps (with no additional overhead)
These rates exceed conventionally available AX.25 packet radio / TNC throughputs for HF and VHF ham bands (generally 300 baud FSK for HF, and 1200 baud AFSK or 9600 baud AFSK for VHF/UHF). Either use of higher frequency bands or a custom modulation format that would tend to have a bandwidth exceeding amateur radio rules in most ITU countries on HF, VHF and UHF frequencies would be needed. At that point you might as well just set up a 900MHz, 2.4GHz or 5GHz 802.11 link.
Yeah it looks like the full blockchain over HF is a no go'er. We'd be best supporting the Bitcoins in Space project - https://bitcointalksearch.org/topic/bitcoins-in-space-334701 - Or in setting up a project to build a cheap WiFi mesh-networking router that can hold bitcoind. As even the public PMR446 UHF band only permits 3.6kbit/s per channel. Although possibly maybe we could use the unlicensed 900MHz 33cm UHF band for a custom mesh-network with better propagation than the 2.4GHz 802.11n. There's off the shelf license free 802.11g 900MHz 33cm UHF equipment like this - http://www.alvarion.com/products/product-portfolio/breezeaccess/breezeaccess-900 - and this - http://www.xgtechnology.com/xMax-articles/xmax-system-overview.html - That we could attach a cheap lightweight nettop too to hold bitcoind.
Woah, I want that but I think we'd all prefer it to be plug-n-play on all operating systems...
You'd need about 2kbps to download seven 1MB blocks an hour. That's a lot of bandwidth 24/7/365 on a global HF network. I think the Bitsat project and the use of UHF and SHF for a lot more relative bandwidth is the best solution for a global wireless network - https://bitcointalksearch.org/topic/bitcoins-in-space-334701
6 blocks/hr * 1048576 * 8 = 50331648 bits/hr
50331648 bits/hr / 3600 seconds = 13981 bps = 13.981 kbps (with no additional overhead)
For 7 blocks/hr, 16.311 kbps (with no additional overhead)
These rates exceed conventionally available AX.25 packet radio / TNC throughputs for HF and VHF ham bands (generally 300 baud FSK for HF, and 1200 baud AFSK or 9600 baud AFSK for VHF/UHF). Either use of higher frequency bands or a custom modulation format that would tend to have a bandwidth exceeding amateur radio rules in most ITU countries on HF, VHF and UHF frequencies would be needed. At that point you might as well just set up a 900MHz, 2.4GHz or 5GHz 802.11 link.
Yes, anyone can tune in to listen to ham radio, but it's important that we have parts of the radio spectrum to ourselves, otherwise all frequencies from DC to daylight would be licensed for commercial and public safety (much of which isn't listenable without buying horrifically expensive gear, if it isn't completely encrypted for no reason other than to eliminate transparency) use.
$10 to $15 for a Realtek-based DVB-T USB receiver dongle used as an SDR (software defined radio), and you can receive whatever you want from 24 to 1766MHz (in the case of versions of the dongle using an R820T RF front end).
http://sdr.osmocom.org/trac/wiki/rtl-sdr
There's some discussion here https://bitcointalksearch.org/topic/broadcasting-the-blockchain-74924
I don't think anyone has tried this yet. And, he hasn't said this to my knowledge, but I get the impression that MoonShadow may be a HAM so you might ask him.
I don't think anyone has tried this yet. And, he hasn't said this to my knowledge, but I get the impression that MoonShadow may be a HAM so you might ask him.
Look up the TNC-PI for how packet radio can be realised.
Not a ham operator but I've looked into it a bit. Problem is it has to little bandwidth for full nodes. It could possibly be used in a SPV manner for linking a specific payment terminal to a radio connected to a full node. But considering the block limit today is 1MB and that will have to be increased I don't think it can be used for the kind of emergency network I'm thinking of.
a packet radio that is specifically listening for signed bitcoin transactions to be sent to the network.
sending the blockchain through sound.. hmm thats the equivalent to using dialup to download a 20gb file. but without the ability to check packets are complete without errors.
useful for sending signed tx's. but not useful for whole blockchains. so keep this concept to signed tx's only
useful for sending signed tx's. but not useful for whole blockchains. so keep this concept to signed tx's only
Convert address into audio, pass audio through radio, pay address
HAM is basically regulating the airwaves that anybody can tune in, isn't it?
Yes, anyone can tune in to listen to ham radio, but it's important that we have parts of the radio spectrum to ourselves, otherwise all frequencies from DC to daylight would be licensed for commercial and public safety (much of which isn't listenable without buying horrifically expensive gear, if it isn't completely encrypted for no reason other than to eliminate transparency) use. US.gov doesn't really make much from ham radio, and could easily say "fuck it, this is worthless, time to make some money, bye hams".
The only fees they collect are for the radio equivalent of vanity license plates; vanity callsigns. To get a randomly assigned callsign is free, but most of them are hard to copy under poor radio conditions, so some of us get vanities. Currently they're $16.10 for 10 years, but the FCC is seeking to increase it: http://w6sg.net/site/?p=1270
HAM is basically regulating the airwaves that anybody can tune in, isn't it?
So there's the receiving the blockchain side, what about just sending transactions and not bothering to wait for an ack?
It seems like there would need to be a worldwide net of receiving nodes with internet access listening for TXes on whatever frequencies we/the ITU decides are standard, then if 2 or more are able to clearly receive decodable TXes from the same sender, the better. Byte sizes of my last 5 received TX: 440 225 257 374 439. Since I don't have any higher tech, let me run the 440 byte hex through a morse code generator at 80 WPM (assuming digital decode) and see how long it takes. 3 mins 20 secs.
Or on Q15X25 http://www.calctool.org/CALC/prof/computing/transfer_time says 1.37500 seconds.
It seems like there would need to be a worldwide net of receiving nodes with internet access listening for TXes on whatever frequencies we/the ITU decides are standard, then if 2 or more are able to clearly receive decodable TXes from the same sender, the better. Byte sizes of my last 5 received TX: 440 225 257 374 439. Since I don't have any higher tech, let me run the 440 byte hex through a morse code generator at 80 WPM (assuming digital decode) and see how long it takes. 3 mins 20 secs.
Or on Q15X25 http://www.calctool.org/CALC/prof/computing/transfer_time says 1.37500 seconds.
You'd need about 2kbps to download seven 1MB blocks an hour. That's a lot of bandwidth 24/7/365 on a global HF network. I think the Bitsat project and the use of UHF and SHF for a lot more relative bandwidth is the best solution for a global wireless network - https://bitcointalksearch.org/topic/bitcoins-in-space-334701
How would http://www.short-wave.info/ stations work for 2kbps?
Quote
https://en.wikipedia.org/wiki/Q15X25
Q15X25 is a digital signal processor-intensive mode designed to pass AX.25 packets on HF with speed and reliability much greater than traditional HF ARQ modems. It uses 15 QPSK modulated carriers separated by 125 Hertz, each modulated at 83.333 baud. Q15X25 uses forward error correction (FEC), and like MT63, uses time- and frequency-interleaving in order to avoid most error sources. The raw transmission data rate is typically 2500 bit/s.
Q15X25 is a digital signal processor-intensive mode designed to pass AX.25 packets on HF with speed and reliability much greater than traditional HF ARQ modems. It uses 15 QPSK modulated carriers separated by 125 Hertz, each modulated at 83.333 baud. Q15X25 uses forward error correction (FEC), and like MT63, uses time- and frequency-interleaving in order to avoid most error sources. The raw transmission data rate is typically 2500 bit/s.
So 6.67 minutes to download a 1MB block at 2.5kbps. You'd need to operate on two channels so that you had a 2.5kbps receive and 2.5kbps transmit at the same time.
Well I'm pretty up to date on stuff and I've never even heard of ham radio so I'm going to look into it. Just by following the thread though, you're not saying to use ham radio as a replacement for the bitcoin network right? Because that needs miners Rex. You're just talking about using it to send certain transactions? Or data too?
You'd need about 2kbps to download seven 1MB blocks an hour. That's a lot of bandwidth 24/7/365 on a global HF network. I think the Bitsat project and the use of UHF and SHF for a lot more relative bandwidth is the best solution for a global wireless network - https://bitcointalksearch.org/topic/bitcoins-in-space-334701
How would http://www.short-wave.info/ stations work for 2kbps?
Most certainly interesting. But yes, this would indicate a very very severe problem.
Jump to: