Topic: New Digital CB "band" for cryptosystems, i.e. offline bitcoin transactions - page 2. (Read 1821 times)

Bump.

Still looking for commentary from the radio geeks.

I chose a total bandwidth of 12 Khtz wide, even though the space is probably 20 KHtz wide, because 12KHtz is the common passband of generic computer soundcards.  This would permit a station using consumer grade computer gear to listen to the entire band at the same time, while still being able to distingish between individual datagrams with overlapping broadcast times.  Better soundcards can listen to wider slices of spectrum, but I'm shooting for cheap here.

Notablely, there is a 4.8 Mhtz wide gap of useful spectrum in the GRMS/FRS band, situated between the simplex channels and the paired repeater input channels.  Between 462.7250 Mhtz (channel 22) and 467.5500 Mhtz.  And the channel spacing between the GRMS center frequencies are 125 Khtz wide but the channel is only permitted a 25 Khtz FM signal; which leaves at least 50Khtz of useful spectrum between each channel.  I don't know what these gaps are there for, but I'd wager that the 4.8 Mhtz gap is already allocated for something, I just don't know what.

Alternately, the PSK31 channels could be interlaced with the QPSK1000 channels, permitting 12 datagram channels and (with one PSK31 channel at the farthest 100 Hz on either side of each datagram channel) 24 live keyboard channels.  I doubt that a proper QPSK1000 signal is going to step on a full 2KHtz wide spectrum, but I rounded up the spaces so that they would fit well.  Interlacing would be a more efficient use of the spectrum anyway.

Thank you.  I expect that I'll be fleshing out a blockchain datacasting proposal as well in the near future, based upon Digital Radio Mondiale.  The idea being that disconnected nodes can listen for blockchain updates from any number of DRM broadcasters across the medium or shortwave bands (or even DRM+ channels in the FM band, if that ever happens) as well as broadcast both their own transactions to whomever may be listening.  The current purposal would also permit, with some modifications, an Electrum server within a 100 klick range to respond to requests.  It's extremely unlikely that the FCC would permit encrypted datagrams, but since no Bitcoin network objects require encryption as such, that should be okay.

Very interesting!

I have enjoyed your posts for years, and this thread is the sort of reason why.

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.

My proposal is to carve out a tiny 'band' about 12 kilohertz wide, centered at 27.095 Mhtz.  The radio heads will notice straight away that this is in the gap between channel #11 and #12 in the old Citizens' Band in the United States.  The reason there is such a gap there at all is because there is still a licensed remote controlled device frequency there.  I'm pretty sure that no serious remote controlled devices still use this frequency, since there are newer and more useful remote control bands in the 440 Mhz range.  If you have a device that uses this channel, it likely has one of those control pads with the huge pull out antenna.  If it has a "rubber ducky" antenna, or is shorter than 2 feet long, it's probably a 440 Mhz channeled device.

I propose that Quadrature Phase Shift Keying be employed, with forward error correction.  Between 27.089 Mhz and 27.091 Mhz would be as set of live "keyboard to keyboard" channels, each using a 100 Hz wide spectrum using transmission mode of PSK31 or QPSK31.  This yields 20 distinct channels within this 2 kilohertz wide band.  Transmittion powers would be limited to 1/2 watt peak envelope power in this section.

In the remaining 10kHtz wide section, between 27.091 and 27.101 would be a set of five 'datagram' channels wherein automatic rules based transmission and encoding would be required.  Each of these channels would be 2KHtz wide, and require the use of QPSK1000.  Within these channels, node to node or node to many broadcasts would be permitted; but a basic set of crash avoidance rules, similar to packet radio, would be expected of all players.  A single packet broadcast would be limited to 20 seconds, including preamble data and payload data, followed by a short postcode to let all other nodes know that the transmission is complete.  This should be large enough of a packet size that a normal sized transaction could fit into a single packet.  Other forms of datagrams would be permitted as well.  Peak Envelope Power in this section would be limited to 2 watts.  Packets do not require a destination node address, and any node listening that hears a datagram (such as a bitcoin transaction) can act upon that datagram depending upon it's configuration.  Alternatively, packets can contain gps directional information, and nodes would be permitted to "digipete" datagrams that it sees if it lays within 15% of the great circle path between the sender's gps code and the destination node's expected GPS code and/or the repeating node is within 100 kilometers of the destination node's expected GPS code.  This service would be "bursty" by design, and network protocols that require that content-less datagrams be broadcast (for the purpose of maintaining a virtual "circut" or persistant data connection, for example) are prohibited.