I've been thinking about this one for some time, and I have an early proposal that I'd like to flesh out with the brainiacs to see if there are any glaring errors that I've made, before I make a formal purposal to the FCC. No, I'm not joking.
Nice! I thought about "Bitcoin over radio" as well. Didn't get to the point of deciding exactly which frequencies or modes would be best for the task, though. Just thought about the general idea, using the model of a ham radio repeater that serves a given geographical region.
The idea is to have some way of ensuring Bitcoin transactions can still be made, even if the Internet is down/unavailable/suppressed in the region. It would work similar to a ham radio repeater, many of which already support various digital modes.
The repeater (good radio station on a mountaintop or something like that, so it has good reach) would be the only node that would require Internet connectivity. It would have an output frequency (always transmitting), and an input frequency (always receiving).
The repeater would broadcast the blockchain as it came in, on its output frequency. The repeater would also broadcast local transactions that have not yet been confirmed, to acknowledge them.
Individual users would transmit to the repeater, on its input frequency, the transaction they wish to make. Only the repeater needs to receive the transmission, other individual users don't need to, as long as everybody remains within range of the repeater. As with traditional ham radio, this lowers the cost dramatically and makes it easier to use, as only the repeaters need to have really good antenna locations, as users can reach other users through the repeater.
If the Bitcoin node at the repeater deemed that transaction to be acceptable (stored it in mempool and relayed it to other nodes over the Internet), then that transaction would be rebroadcast on the output of the repeater, so that all within radio range would know it, as well as over the Internet. Thus, the sender of the transaction would get acknowledgement that it had been accepted.
If there is enough downtime between blocks, the repeater would rebroadcast historical blocks, so that anybody who missed a block due to static/interference or whatever could have another chance to stay fully synchronized.
An additional sophistication could be to add the ability to subscribe to addresses of interest (using filters for privacy), so that unconfirmed transactions matching those filters would also be broadcast on the radio, not just blocks. This would provide faster notification of incoming transactions, without having to wait for them to appear in a block, similar to outgoing transactions.
The idea is to have the ability to transact by Bitcoin be very survivable. If the traditional Internet connections are knocked out, either by disaster or intentionally by government trying to do suppression/censorship, the ability to do Bitcoin by radio could be very useful.
Josh
