Pages:
Author

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

legendary
Activity: 1204
Merit: 1002
As a Bitcoin network, packet forwarding ought to cost some small fee, paid in Bitcoins. The problem is that the Bitcoin system chokes on micropayments. But think about that as an idea for congestion control. Maybe you have to do some proof of work to send packets.

I've thought about very low value bitcoin tipping for forwarding, but I don't know how to do it.  Any suggestions?
The problem is keeping the accounting traffic from exceeding the useful traffic. If each packet is billed separately, the accounting traffic is huge, much bigger than the useful traffic. The usual solutions are to have virtual circuit metering (like X.25 and cellular telephony) or end-link metering (like DSL and cable modem connections.) You can meter "flows" (as in what's now called "software defined networking"), but that requires more central control, like the old Telenet system. It's hard to do in an open mesh network.

Keeping someone from hogging the network, though, is quite feasible, and the mesh network people have looked at that problem. Congestion control is statistical; it doesn't have to be perfectly accurate. If you bill, you have to get it right, which is harder.
legendary
Activity: 1708
Merit: 1010
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).


This doesn't need that, as the rules of the machine can determine when and under what circumstances the datagram is repeated.  Similar to how packet radio works, only slower.

Quote
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.


It'd be usefull anyway, but particularly during a Internet blackout of a limited term.  If the Internet is permnently and irreversablely destroyed, Bitcoin won't work anymore; but if that were to ever happen, I think I might have bigger problems.
legendary
Activity: 1708
Merit: 1010
As a Bitcoin network, packet forwarding ought to cost some small fee, paid in Bitcoins. The problem is that the Bitcoin system chokes on micropayments. But think about that as an idea for congestion control. Maybe you have to do some proof of work to send packets.

I've thought about very low value bitcoin tipping for forwarding, but I don't know how to do it.  Any suggestions?
legendary
Activity: 1708
Merit: 1010

Yeah, that video has been there for years.  I've been stalling because I was hoping it would amount to more than vaporware.
member
Activity: 106
Merit: 10
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
legendary
Activity: 1204
Merit: 1002
As a Bitcoin network, packet forwarding ought to cost some small fee, paid in Bitcoins. The problem is that the Bitcoin system chokes on micropayments. But think about that as an idea for congestion control. Maybe you have to do some proof of work to send packets.
legendary
Activity: 1204
Merit: 1002
The filing isn't quite done, but I have the frequency allocation proposal finished.  It's filling number with the FCC is 0158-EX-PL-2014, if anyone is interested.  I filed it as an experimental license application, because there really wasn't a better method.  The FCC doesn't have a method for suggesting completely new ideas.
That's how the FCC does do new ideas. Digital AM radio and digital cellular telephony started under experimental licenses. You usually get two years, with a possible 5 year extension. If you propose a geographical limit on your stations, it's more likely to be approved, because applications are checked against a database of every other licensed service for conflicts. If you don't limit, you'll get a conflict with any other 27MHz station in the US.
legendary
Activity: 1708
Merit: 1010
What would be the expected use cases ? To be able to transmit transactions in areas where you cannot get any cell signal ?
Like buying some goods from a traveler in remote mountains ?

That would be a use case, but certainly not the only one.

Quote
Let's say I want to pay with bitcoins, I build the transaction and broadcast it to the network using my portable CB.
How will a node acknowledge and prove to me the transaction has been correctly transmitted to the Bitcoin network ?

That would require a back channel, if you needed to know.  Such a back channel could be a datacast stream from a DRM station (if you're patient) or an alternative service, such as Iridium Burst.

Quote
Without non taintable proof, I cannot finish the transaction and take the good.

Not with a full client, no.  The white paper does describe a 'light' style client with a reduced security model that could do offline transactions with limitations.  For example, the device would need to be able to communicate with the other light client, which is one use case of my proposal.  Additionally, the light client would need occasional access to a gateway node, in order to update it's wallet.dat; otherwise it would eventually run out of spendable inputs.

Quote

I like very much the idea of backup channels, to be able to use cryptos even if govt shut down the cell towers etc.

It's not really intended as a 'fallback' method.  It's intended as a primary communications method between portable, hardware based light clients; i.e. the kind that are not simply an app on a smartphone.  Additionally, it's intended as an efficient & mostly automatic digital communications mode.  Imagine if you had a device that could send and receive texts to/from people that you have already met IRL to a distance of 5+ miles radius in a single hop, but could also use multi-hop methods to cross a moderate sized city.  Without any kind of ongoing licesnsing or service fees.  A pocket sized device that is a cross between a texting FRS radio and a hardware wallet, that may or may not have a cell service data plan of it's own.  There are other use cases for a 'slow mesh' as well.
sr. member
Activity: 360
Merit: 250
CEO, Ledger
What would be the expected use cases ? To be able to transmit transactions in areas where you cannot get any cell signal ?
Like buying some goods from a traveler in remote mountains ?

Let's say I want to pay with bitcoins, I build the transaction and broadcast it to the network using my portable CB.
How will a node acknowledge and prove to me the transaction has been correctly transmitted to the Bitcoin network ?
Without non taintable proof, I cannot finish the transaction and take the good.

I like very much the idea of backup channels, to be able to use cryptos even if govt shut down the cell towers etc.

Eric

legendary
Activity: 1708
Merit: 1010
The filing isn't quite done, but I have the frequency allocation proposal finished.  It's filling number with the FCC is 0158-EX-PL-2014, if anyone is interested.  I filed it as an experimental license application, because there really wasn't a better method.  The FCC doesn't have a method for suggesting completely new ideas.

I'm thinking of calling it a "slow mesh" until I have a better name for it.  Any ideas?
legendary
Activity: 2912
Merit: 1060
legendary
Activity: 1708
Merit: 1010
legendary
Activity: 1708
Merit: 1010

Now, doing this in a lower band might work, but would take more RF power than Part 15 gear.


Yes, it would take more power than a Part 15 device is permitted.  My suggested power limits are way over  Part 15 limits, which is why I need to have a proposal at all.  If I could use Part 15 power limits and make it work, I wouldn't need the blessing of the FCC.  This was the root problem of a great many of the mesh networks that have been tried before, Part 15 device power levels just can't get any useful distance.  Combined with the fact that 2.45 GHz is an awful band for range anyway, and 900 Mhz isn't a whole lot better.  There is a corrolary between interference and range; because (generally speaking) the lower the frequency, the lower the attenuation rate of the ground wave.  This is why a legal limit CB transceiver can communicate over the visible horizon, and anything over 30 Mhz generally cannot.  Since such bands can travel farther via groundwave, you are more likely to experience manmade interference regardless of the current reflectivity of the ionosphere.

BTW, the first 6 channels of the 2.45 Ghz wifi band overlaps a ham radio band, and some hams use Part 95 power limit rules to make some truely awesome mesh networks from commercial gear.

http://www.broadband-hamnet.org/
legendary
Activity: 1204
Merit: 1002
This is what's called a "wireless mesh network".  It's been done before. Dewayne Hendricks used to have a company called "Tetherless Access" which, about 20 years ago, was going to build distributed radio networks something like this. He turned out to be all talk and no hardware. Then in the mid-1990s there was Ricochet Networks, which put little repeater nodes on street lights.  These standalone units forwarded packets until they reached a station with a wired connection to the Internet. Worked in the 900 MHz band. That worked fine, and was deployed in several cities.  I used to use their system.  You could get internet access at about 15Kb/s, later upgraded to about 50Kb/s.  So that went out when DSL came in.

More recently, there's Freifunk, a low-cost wireless network for rural areas being used in Zaire.

The basic problems are this:

- To get much range, at least one end of each link must have a decent antenna, up high in clear space and aimed in the right direction. It's better if both ends do. Building networks this way in rural areas works fine, if you can get line of sight to the next station.
- Short-range ad-hoc wireless mesh networks have been successful, but they need a lot of nodes in a small area. There are WiFi booster systems which network in this way.  That works fine, too.
- What doesn't work are sparsely distributed indoor antenna devices.

Now, doing this in a lower band might work, but would take more RF power than Part 15 gear.

The biggest headache is simply antenna location. If you can get people to put a whip antenna on their roof, this can work.

hero member
Activity: 503
Merit: 501
I believe it is a great idea and am enthused further by the interest shown by the U.S. Post Office targeting the 'underserved' and your idea complicates that wonderfully.

If you could somehow get a nod from the post office acknowledging how your proposal is aligned with their research I think it would be fantastic. As advanced as the US is in many regards, our broadband infrastructure is lacking and your goals and the Post Office goals compliment each other well.

If it was my decision to make, each Post Office in the US would be outfitted with repeaters using your solution.

http://www.uspsoig.gov/sites/default/files/document-library-files/2014/rarc-wp-14-007.pdf
legendary
Activity: 1708
Merit: 1010
Please copy the U.S. Post Office research department. Those ponies will need some beacons for the ride.

If you are calling my idea a throwback, that's part of the point.  Using less desirable spectrum in a novel manner is more likely to get approved than to attempt the same thing in the UHF or microwave bands.  As to the issue about interference from overpowered CB's, that's part of the reason for choosing very narrow bandwidths and phase shift keying has proven itself to be a very noise resilient mode on the shortwave ham bands.  PSK is so very different than AM or SSB spatter noise that it's often distingishable even in an otherwise noisy environment.  A quarter watt is a lot for PSK31 when your groundwave only has an expected radio horizen of about 10 miles.
hero member
Activity: 503
Merit: 501
Please copy the U.S. Post Office research department. Those ponies will need some beacons for the ride.
legendary
Activity: 1204
Merit: 1002
27MHz is still used for some industrial radio control. There's been some interest from the quadrotor crowd, who want more range, but they seem to be using 35MHz instead. The only big problem with 27MHz seems to be spillover from CB.

The receiver should probably just suck up the whole band and receive all the channels simultaneously, looking for packets of interest. Then no configuration is necessary. That will require a software-defined radio, but there are cheap chips for that now. There are boards available, but they usually won't go as low as 27MHz, because they're intended for cable TV.

The problem with all this is that it will take a reasonably good antenna to have any range, and nobody will put up big antennas any more.


         
legendary
Activity: 3066
Merit: 1147
The revolution will be monetized!
Me likey likey!   Grin

I'm watching this. Please do update if a test is run.
Pages:
Jump to: