The bitcoin band

[MoonShadow]

Much has been discussed, including by myself, on the value of bitcoin devices that don't require constant Internet access in order to transact.  Part of this would likely include some kind of ad-hoc p2p wireless networking ability between devices, as well as the ability to monitor a set band for bitcoin related data.  I had an idea.

Wifi uses the 2.5 & 5 gigahertz ISM bands, not because they are ideal, but because they are unlicensed AND they are wide enough bands to support the channel width required for high speed data transactions.  None of the ISM bands of a lower frequency (in this case, better transmission & propogation characteristics), however there is nothing that I know of that prevents a narrowband digital part 15 device (unlicensed intentional transmission) from working in the lower frequency ISM bands.  I've personally mentioned using Dash7 sensor tech (433 Mhz ISM band) for this purpose, and this might yet happen anyway, but Dash7 radios are still vapor-gear.  However, basic radio modems on chips are not.  Their bandwidth is narrow & data throughput is slow, but they can also operate on better bands & individual transactions are neither large nor subject to problems if distorted. (due to internal checksumming)  So error correction is unnecessary.  If we were to establish a 'standard' frequency and mode for the literal broadcasting of transactions from disconnected devices, then such devices could be sold that can monitor that frequency and either store transactions that it sees to be released to the Internet latter, or simply as base stations (inside brick & mortar vendors?) which forward the transactions immediately.  The transmitting device doesn't necessarily even need to know if other devices heard it; it could simply transmit in a standard pattern.  I.E., a buyer's device could transmit immediately, repeat again 5 minutes later, and again an hour later, then perhaps once each day until it sees it's own transaction in a block (or a supporting server tells it to stop).  This would both protect against a device not being heard due to no other devices being within range of the buyer's device, as well as protect against a broadcast 'collsion'.  The seller's device could ack the transaction, permitting the buyer's device to quit, but this shouldn't be required should the seller's device not support monitoring the bitcoin channel itself, such as a standard computer client or an android client.  Of course, it's in the interest of both seller & buyer that another bitcoin device that can act as a gateway to the internet does exist.

To be clear, this frequency would be for the movement & broadcasting of transactions only.  These disconnected devices would have to get blocks by some other method, but an occasional wifi connection to promote updating the local blockchain would work fine, permitting stand alone devices to exist that could literally act as bitcoin wallets in meatspace.

As for the choices of ISM bands... (http://en.wikipedia.org/wiki/ISM_band)

The ISM band near 27 Mhz is very close to the Citizens' Band (USA) and the 11 meter ham band, so the propgation characteristics should be fair and the ISM is tiny, so it's rarely used by any other widespread tech that I know of.  So it shouldn't have to deal with much interference.  As the entire band is only 320 KHertz wide, even Dash7 wouldn't fit well using it's narrowest mode.  I'd say that a modern 'sound card' mode such as PSK31/63/125/250/500 would be ideal, but this requires both a sound processing chip (no longer a high requirement) and a tiny, single frequency (crystal controlled?) SSB transceiver (not so easy) to be within the portable device.

I don't like 40 Mhz, because the ISM band there is only 40 Khz wide, so PSK31 would be the only available mode narrow enough to fit without interfering into nearby licensed bands, which might bring the hammer down via the FCC; if only as an excuse. I don't consider PSK31 to be a fast enough mode to reliablely move a transaction, because it would take far too long to complete. (EDIT, I don't know what I was thinking here, except perhaps I was temporarily conflating Khertz with hertz; for PSK31 is only a 31 Hertz wide mode, not 31 Khertz.  A number of PSK500 channels could coexist on this band just fine.)

I don't like the 433 Mhz band, because it's already in use by many other consumer devices (garage door openers, being one) and the future might have that band packed with Dash7 devices.

I don't like bands of lower frequency than 27mhz, because even the 27 mhz band is going to require some fairly inefficient antennas to fit into handheld consumer devices, and anything of a lower freq is going to be worse.

[1714189550]

1714189550

[1714189550]

1714189550

[1714189550]

1714189550

[MoonShadow]

Perhaps the 40 Mhz ISM band would be ideal, after all.  It would permit smaller antennas of reasonable gain than 27 Mhz.  And if the standard mode chosen is PSK500 or PSK1000, at least 10 devices could be transmitting at the same time, and a single computer with a sound card could decode & forward all those transactions at the same time.  Also, a standard 2Kb or smaller transaction would take less than 20 seconds to burst.  Granted, less than one second is ideal, but I'm not sure how that's going to work unless we were to use higher quality radio modems (read more expensive).

[jim618]

Hi MoonShadow,

You know a lot more about it than me, but it looks like 40 MHz is *just* achievable by software defined radios you can buy commercially.
Have a look at:

http://www.ssb.de/product_info.php?language=en&info=p1390_Perseus-SDR--10-kHz---40MHz.html

I think that means you could prototype it using what I think of as "my workshop in the garage" technology.

That 40MHz ISM band does look nice as it is narrow enough that noone would be very interested in it, but wide enough for transmission of bitcoin transactions in a reasonable timescale.
 

[MoonShadow]

Good God, those are expensive!

[MoonShadow]

I almost didn't view this topic, because I thought it was about a music band, not a radio frequency band!

You surely want to use a higher frequency than 27 or 40 MHz, for two reasons: a much smaller antenna, and much lower power consumption. Additionally, there's quite a lot of diathermy equipment that still operates on 27MHz, which creates a lot of interference.

While this is true, the higher frequency ISM bands are in heavy use by existing part 15 technologies.  Obviously, Wifi dominates 2.5 & 5 gigahertz, but many other techs compete for this same band.  433 Mhz is commonly used by simpler devices, such as garage door openers and car remotes, but is still a very viable band.  I reject it only because of the potential that Dash7 transceivers could come to dominate the band if they ever make it into cell phones.  Dash7 would make an ideal p2p meshing tech for bitcoin to piggyback  upon, but that would happen regardless of any alternatives.

Before choosing a frequency band, I suggest to find one that is available in a wide range of countries. Some ISM bands are US-only.

And some are Europe only, which is another reason that the higher ISM bands are so crowded, because they are nearly worldwide.  No ISM band is universal, however.  I'm considering only the best solutions wherein realistic enforceablitly of public spectrum regs exist.  No one cares what laws Iran may pass, they can't prevent such devices from their public anyway.

Is 433 MHz really an ISM frequency? If so, it's right inside the 70cm ham radio band, so it should be possible to work with kits and modules sold for ham radio use. Unless it's a requirement that the ISM equipment must be type-approved by the FCC.

Yes, 433 Mhz is a near-global ISM band.  More widely respected than 900Mhz, less than 2.5 Ghtz or 5 Ghtz.  I doubt that 40 Mhtz is a worldwide ISM band, but it is in USA, Canada and Europe.  The rest of the world can adapt or use a different band.

[jim618]

And I imagine we would be using pretty low power levels (the lower the better) as we are not trying to transmit the transactions very far.
It is a human to human distance.

That would improve reusability of the frequency slots (assuming that our signals were the main cause of interference).

Lots of people whispering to each other in a room rather than a bloke on a soapbox with a megaphone.

[grue]

why not use the existing packet radio band? it even has satellites to relay communications between huge distances.

[MoonShadow]

Wouldn't it be simpler to specify a Bitcoin Transaction protocol for Bluetooth?

That's fine too, but that is a different goal.  It's not enough to just send a transaction to your seller, although that's certainly possible with any direct wireless peer model, because if I were to buy something of great value from you, and have a deal with a local thug that if he mugs you before you can get to a signal to send that transaction to the Internet, then all the security against double spending is useless.  Thug just mugs you, steals your device, and smashes it and I give him half and keep the bitcoins to spend again.

No, the idea here is different than just the ability to trade person to person while offline, the idea is to have a standardized (& relatively cheap) method of broadcasting that transaction to the wild, so at least the parties involved don't know that said transaction hasn't been heard by other bitcoin devices nearby.  A bitcoin gateway, such as I am presenting here, doesn't need to even have a transmitter, and as such isn't limited in the quality of the receiving equipment.  Done right, even low power burst transmissions of transactions could travel for miles in the open or blocks in the city.  Using an offline device affords a different kind of security model, even where Internet access is readily available, but there needs to be some method of getting those transactions out there.  There also needs to be some way of getting block data processed and into the devices, but one thing at a time.

[MoonShadow]

why not use the existing packet radio band? it even has satellites to relay communications between huge distances.

Can't.  Part 15 devices that are intentional emitters are limited to the ISM bands, otherwise everyone who has such a device must also have a license with the FCC.  That would kinda kill any anonimity of using bitcoin with an offline device.  I'm mostly trying to start a conversation about starting a standard, so that hardware experimenters can use a common set of standards to make their devices comminicate more effectively with a bit of prior planning; rather than just let some incompatible devices talk past each other until a defacto standard arises.  First the transaction broadcasting method, then perhaps the block data method if one is necessary.  I don't think that they will be, because an offline device that can occasionally connect via wifi to collect updated info concerning it's own address balances and new transaction inputs can create transactions and continue to spend it's own known change until it's balance is zero.

[MoonShadow]

Anyone else care to weigh in?

Any other radio geeks with an opinion on the best band to use, or the best mode?

[Revalin]

If your goals are to create something for widespread popular use, I suggest creating a standard on top of 802.11 ad-hoc mode.  This would give you:

Built in radios in most smartphones
economical battery use
Very high data rates / short bursts
The ability to both broadcast the blockchain and unicast requests for old blocks
Reasonable range as bidirectional ISM devices go
Quite good range (much better than you get with usual wifi usage) when blind-broadcasting the blockchain from a fixed station (IIRC you can use up to 2w total, and you won't hit the EIRP limits with an omni antenna)
Mature multiple-access and collision recovery implementation
No hardware development cost
The convenience of developing on top of IP

If your goals are to have a fun radio hacking project, carry on. 

[MoonShadow]

If your goals are to create something for widespread popular use, I suggest creating a standard on top of 802.11 ad-hoc mode.  This would give you:

My goal is to create a transaction broadcasting channel that other devices can listen to, but not compete with existing tech.  Wifi can be used regardless.

[MoonShadow]

In my research on the feasabilty of using the 27.120 MHz & 40.680 MHz ISM bands with low power ( half watt or less) devices to broadcast the transactions, I noticed something interesting.

I was concerned that 1) efficient antennas in these frequency ranges would be too big to be practical and 2) occasional 'skip' would interfere with devices far afield from the one trying to broadcast locally.  But then I though that using skip characteristics intentionally might be useful in it's own right.  The problem being that, since the F layer of the ionosphere is about 150 miles up, the devices that produce 1/2 watt transmissions would have to be detectable by a computer that was listening at least 300 miles away, because the only way to deliberately use F-layer skip to this end is to use Near Vertical Incidental Skywave to exclude interference from broadcasting towers & prevent radio shadows from buildings & geography.  The quality of the transmitting gear is important, but not as important as the quality of the receiving gear and the digital mode chosen.  Now the range of NVIS is roughly 300 miles max, simply because the practical useful angles are from 45 to 90 degrees from the horizontal; so with a reflector at 150 miles up, the emission wave simply can't travel farther than this reliablely.

However, the frequency that is best for using NVIS changes from season to season and from night to day.  For this reason, using NVIS with very low power devices is going to require the ability to change bands.  So I went back to the ISM bands listed on Wikipedia, and was looking to see if there were any lower frequency bands that could be used, and I saw these.

6.780 MHz
13.560 MHz

Now, for a simple device that can switch from one band to a completely different one, it's best to have a set of frequencies that are harmoncis of one another.  This turned out to be simple, because 6.78, 13.56, 27.12 and 40.68 just happen to be exact even multiples of 3.39 Mhtz.  This little bit of data, combined with the fact that there are no other ISM bands on lower frequancies than 40.680 Mhtz, makes me wonder what the hell uses 3.39 Mhtz and could produce harmonic resonate emissions to any degree to justify the establishment of a protected band for the harmonics; particularly one that could produce significant interference all the way to the 12th harmonic (40.68 Mhtz)

According to a quick google search, 3.39 Mhtz happens to be the primary frequency for HAARP.  I can find no other data to contradict such claims, and no other purpose for 3.39 Mhtz to offer another explaination.  Also the fact that Wikipedia says that HAARP uses 3.5 megawatts of transmitter power would tend to support the position that those harmonic frequencies wouldn't be useful for anyone trying to communicate.

I'm not much of a conspiricy theory believer, so I'm not going to address that topic, but it might be safe to say that any attempt to establish a frequency & mode standard for Part 15 bitcoin devices on any of these bands is destined for frustration & failure.  I had intended to set up a high quality listening station in order to monitor these bands for quality over an extended period of time, and test out a few QRP modes for the purpose (such as PSK10), but I think that might be a pointless endeavor.

[MoonShadow]

A little OCD is sometimes productive.  I've discovered a couple other unlicensed Part 15 device bands that the FCC explicitly permits public use of, even though they are all officially federal government bands.  To be specific, they are vhf bands likely reserved for military functions.  And yet, according to this little gizmo (http://reboot.fcc.gov/spectrumdashboard/searchSpectrum.seam) there is a fairly wide spectrum available between 255 Mhz and 322 Mhz and again between 335.4 Mhz and 399.9 Mhz that Part 15 devices are permitted to use.  I tripped over them due to this website (http://www.pocketwizard.com/wheretobuy/frequency/).  I would suspect that these bands are fairly wide open, since they are not worldwide bands.  Great for practical testing of devices and communication protocols, certainly.  It shouldn't be difficult at all to make small & portable devices that can communicate over distances of a klick or more even in an RF noisy urban area.  And with so much bandwidth (potentially) available, more robust and modern communication methods should be available as well.  Regular wifi radios can be used for devices to connect to the internet or (in ad-hoc mode) directly to each other to trade blocks.  So what is really needed is some means of a one-to-many message broadcasting mode.  I don't know if it'd be better to use phase shift keying modes & modified varicode, or multi-frequency shift keying with forward error correction to transmit bitcoin network messages as raw data.  And off the top guess, and I'd say starting at the top end of the higher open band at 399.9 Mhz and moving down in channelized sets would let devices communicate well to great distances by shifting to narrower & higher signal-to-noise versions of the chosen mode in order to extend their clear propogation reach when necessary or wider & more bursty versions when a selection of other bitcoin devices can be heard to mesh with.  I'd say that QPSK1000 would be the widest practical version of PSK, potentially narrowed all the way down to BPSK10 on the narrow, slow and far-reaching end.  Or prehaps a single quarter-channel wifi radio (5 Mhz protocol instead of the standard 20 Mhz that is used in the 2.5 Ghz band) for the reuse of common chipsets, with a batman like mesh network constantly trying to find other bitcoin devices.  This would make the interfaces with normal wifi routers, as well as the development of bitcoin specific routers, both cheaper and easier to interface.  Or perhaps using Dash7's open source protocol OpenTag as a baseline would be more appropriate.

I really can't keep this up alone without my head exploding.  I need some help from some other radioheads on this forum.

[jim618]

Sorry to hear that your head is about to explode, MoonShadow.

Your posts cover the whole gamut of crypto-bitcoin-mesh-radio-DSP-algorithms so it is not surprising.

Time to take a break and go for a walk in the mountains closest to your home!

:-)


edit: how about: rather than trying to solve all the issues with transmitting bitcoin generally, you produce the simplest "bitcoin radio" project that you can think of as a demonstrator.

Have you seen the thread I have in Alternative Clients on a serial line hack ? :
https://bitcointalk.org/index.php?topic=76004.0

There I am trying to push bitcoin down to the custom hardware level but that is too big for me to do so I am just trying to do the simplest demonstrator (aka hack) I could think of.

I am thinking the bitcoin radio equivalent of 1 + 1 = 2.

[apetersson]

a very interesting future method of transaction proppagation could be NFC.
i think it would be very interesting to use nfc bidirectionally to exchange both payment addresses and also signed transactions.
this would enable the customer to pay with 0-conf without having any internet connection and the merchant could optionally have a net connection to still be able to detect double-spends.

this sounds now very obvious to me - has this maybe been discussed before?

[jim618]

Andreas Schildbach has put NFC support (and certainly experimented with transactions) in his Bitcoin Android Wallet.

I think the (current) stumbling block is that not many phones have NFC in them yet.

[Stephen Gornick]

This isn't in the frequency ranges you are looking for but could be related to some degree:

The Federal Communications Commision granted the Free Network Foundation a nationwide license to use the frequencies from 3650MHz to 3700MHz for use in common carrier, non-common carrier, and private communications activities.

This is pretty exciting for us, as it means that we’ll be able to help folks use this very clean frequency for fixed wireless mesh networks across the country.

If you’re interested in operating a free network at these frequencies, let us know by emailing info [at] free network foundation [dot] org.

There is lots of hardware out there that can operate at these frequencies, and with the proliferation of Software Defined Radio, it is often simply a matter of updating the radio firmware. We look forward to doing our first 3650 experiments in the coming days as we deploy the core infrastructure for our Kansas City research network.

- http://freenetworkfoundation.org/?p=859

[MoonShadow]

Breaks over.

This little IC transceiver seems ideal for the purpose...

http://www.linxtechnologies.com/resources/data-guides/trm-xxx-lt.pdf

The chip doesn't impose any protocol of it's own on the dataset, so a simple form of 'gossip' mesh seems ideal for the dissimination of signed bitcoin transactions.  Such as transmitting a transaction in the raw with a lead-in signal (a "hello, listen up I've got a transaction here" header, really) with a hop-number in the header that would be retransmitted by other devices after deducting 1 from the hop limit.  Perhaps the hop limit would always be the same (say 7 max) but if a device hears the same transaction with a lower hop numer, it takes the lower hop number when it is it's own turn.  Devices would only retransmit the transaction with a semi-random delay (this is how packet radio avoids collisions) and cancels it's own broadcast if it hears the same transaction again within it's wait time.  The initial device transmits the transaction three times; once immediately (or as soon as the channel is clear), once about 5 minutes later (5 minutes plus a random anti-collision delay following the last transmission by others, again packet radio method) and again after about an hour.  No listening devices respond with an ACK, but store this transaction for later transmission.  The listening devices then wait about 7 minutes (6 minutes + a random wait of 0-100 seconds) but cancels the broadcast if it sees another transmission of the same transaction during that time frame.  (i.e. it could still be near the original device, could be near another secondary device, either way there is no need to retransmit at this time) The secondary device then will attempt to retransmit again at about an hour (60 minutes + random delay of 0-100 seconds) but also cancels the transmission if it hears another first.  All devices then go quiet about that particular transaction until in range of a wifi hotspot (if equipt) and dumps it's transaction pool onto the Internet.  Since a mangled transaction would simply fail to pass the checks of a full client & a gossip protocol is very resilient otherwise, we don't need any additional error corrections or ACK packets.

  This same device would work just as well as a p2p texting device, something like Jabber over the air, if hashing of the data & a directional bias for the gossip were used.  For example, assuming that devices had a gps chip, and broadcast headers always included a MAC address for the originating device and the presently broadcasting device, and a (shortened) last known gps location for the presently transmitting device; all devices in the area could establish a short lived 'directional' routing table.  A sending device could choose up to three of the devices that it calculates to be in the best general direction & best distance for it's destination (i.e. the 60 degree sector of the last known position of the intend recipient node) and name them via their mac addresses in the header.  Since those same three devices know where they are & where the originating device is (generally, with a gps code intentionally reduced for accuracy) they can jude for themselves the direction intended, and (nearly) immediately rebroadcast the packet with three more mac addresses and one less on the hop variable.  This continues in that direction until the hop count drops to zero.  If the intended device recieves it, it sends back an ACK in the opposite direction.  The package can be expected to proceed in teh general direction (assumeing that there is sufficient node density) and generally fan out as the hops progress, but no interferance in the opposite direction of the intended direction occurs, so the max hop number could be higher, say 15.  With a standard range of about a klick, a hop limit of 15 has a max possible range of 15 kilometers in an urban area with optimum density, but due to line-of-sight losses and interference, teh practical limit would be closer to 10 klicks.  Still not bad for infrastructure-less digital communications that doesn't cost anything.
 


  The radio has decent range at a decent throughput, about a klick at 10kbps.  Add an ecapselating mesh packet header protocol, and we're good to go there.  I'm not sure how to handle in-person initiations of transactions, however.  In other words, I don't know how to get a POS device to request a payment amount from a device over the air.  

EDIT: If a biased routing sceam, such as above, were used; a 'heartbeat' for devices that have not transmitted within a ten minute time frame would be required, so thta nearby devices could know that there still is a device in that direction.  This would just be a very short burst, contianing only the devices's mac, the shortened gps code and (maybe) a basic vector.  (I.E, moving 5 miles per hour NNW).  If the device has another packet to broadcast, or is moving faster than 25 miles per hour, a heartbeat packet would be pointless.  This same kind of biased gossip mesh could work well if the devices stored knowledge of fixed base nodes with Internet access and directed their transactions in that general direction.  The obvious disadvantage would be that there would be no way to hide your location information.

[MoonShadow]

Andreas Schildbach has put NFC support (and certainly experimented with transactions) in his Bitcoin Android Wallet.

I think the (current) stumbling block is that not many phones have NFC in them yet.

NFC would be great for point-of-sale or in-person trades, but not transaction dissemination.  NFC has a practical range of about half a foot, so users' devices would have to be placed beside each other and deliberately told to interact.