Bitcoin Forum

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.

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

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

Good God, those are expensive!

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.


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.


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.

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.

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

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.

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.

Anyone else care to weigh in?

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

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.  :)

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.

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.

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.

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

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?

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.

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

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

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.

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.

Dude!  That's awesome!  I'm all over this, thanks!

@MoonShadow

That is a very nice little transceiver you have found there. Are those frequencies usable in Europe ?

For the initiation of payments you could do something like:

1) the Bitcoin radio device has a pseudonym (nym) that you configure in sync software. (I am stealing from that thread of mine on 'dedicated bitcoin devices and untrusted networks'). Say mine is 'Jim618'.
2) the PoS terminal has a list of the active devices in the neighbourhood. Say sorted by signal strength or, if there is GPS data, distance. That puts 'Jim618' at the top of the list 
3)When the checkout person wants you to pay they would have to check you were the top nym (or you would say your nym to him/her). Their POS terminal then initiates a payment request by broadcasting a bitcoin URI and the nym e.g.

'jim618 please pay: bitcoin:1<address>&amount=1.234&label=yourgoods

Your device hears the transaction, the nym matches so it asks you on screen if you want to pay. You answer yes, a tx for the amount is created and signed by you and transmitted. Other devices also hear the payment request but the nym does not match and they totally ignore it. The payment tx is then dealt with the same as you have written before.

The nyms are not registered anywhere or even unique, if another Jim618 is in the store shopping they get asked if they want to pay for my goods but of course they say no.  You could change your nym at any time. It could also be used as the username in messaging:

@Jim618 - I see you are in the neighbourhood - want to meet up for coffee ? - Henrietta3


I think you should do a hack to get that transceiver hooked up to a USB output together with a reasonable aerial. The datasheet says it takes serial input. That way developers with breadboarding skills can make a couple and start trying them out. You can crowdsource the writing of the mesh network software ! :-)

The 433 mhz band is an international ISM band, just like 2.45 Ghz that wifi uses, so it's legal at less than half a watt most places and no one cares much about the rest since they still work just fine.


That would work, assuming that the 'heartbeat' function was turned on.  However, I'm concerned about a man-in-the-middle type attacker, who places a hacked device hidden near a POS system and randomly attempts to pretend to be the POS register, or just uses a beam antenna from across the street.  Most of the time it wouldn't work anyway, but if it works at all it's a problem.  There would have to be some kind of challenge & response crypto standard, say to display a four digit pin on both the POS system checkout screen and your device so that you can look at them and make certain that they match.  This wouldn't matter for the messaging system, because messages could be encrypted to the receiver's public key, which you aquired some time ago in a 'bump' kind of fashion when tapping the two (gps known and in radio contact) devices together.  If public key encryption is too much for the device (probably not, if it's got to do the bitcoin encryption anyway) the devices could trade a set of random data to be used as one-time-pads.  Actually, for texting this would be better, for public key encryption has the habit of making the messages much longer than any simple text message could be, which is one reason that SMS isn't encrypted normally.  Longer than necessary messages would be a killer for the app.  The messaging functions of the device would simply have to collect entrophy data, and then package that into a one-time-pad, trade that data in near proximity (this is where NFC shines) and encode messages with a 1/1 byte ratio, then add a header that told the receiving device where the message starts in thier pad in case there were unreceived messages, then change all used pad data to zeros.  Any device that used the same nym wouldn't be able to see the message.  Plus we would have to assume that there would be nodes that saved all traffic, so privacy would require encryption anyway.  The device would have to have enough flash memory to keep a several kb of pad data per saved contact.  5kb for the sending pad, 5kb for the receiving pad and you're good for several hundred texts before you have to get close again.  The app could warn you when your pads were getting low.


I think you should do a hack to get that transceiver hooked up to a USB output together with a reasonable aerial. The datasheet says it takes serial input. That way developers with breadboarding skills can make a couple and start trying them out. You can crowdsource the writing of the mesh network software ! :-)
[/quote]

NFC or a cradle at the checkout that you put your device in would make it easier for the POS and paying device to be more certain of each other and pair up. You would not need nyms then.

I am thinking a cradle where the transceivers are close to each other to make it virtually impossible for another transmitter to overpower the signal.

For trading one time pads you also want to make sure you cannot be overheard so you do want to be able to whisper to each other and to be paired.

One time pads would be a great way of maintaining privacy and quick to encode/decode.

This is true, and exactly why NFC tech is being included into some phones these days for Google Wallet and other similar credit card substitutions.  I don't know that I would want to depend upon NFC being in every hardware device, however.  I'd much rather start with a single radio device that can manage to do everything that it needs to with that one radio first, if that's possible.

Although this is a cool project, and I'm sure that I'll participate when the time comes, it's not really relevant to the topic problem.  However, this group is bound to be a great resource regarding the FCC process should a licensed band prove necessary.

I realized today that I left out an important step in my previous description of the simple biased gossip protocol.  The header of any packet must contain a simple hash of the data, so that (lacking forward error correction) a receiving node can know when the message it heard was corrupted, and simply discard it.  Again, I don't think error correction would be worthwhile because 1) although AM is a noisy mode, UHF tends to not be that bad, at least concerning natural noise and 2) it's not actually necessary that a transaction be heard and forwarded by other devices, it's just beneficial.  The repeated transmission at intervals takes care of the redundancy of data issue without error correction.  I'm guessing it would, anyway.

Seems relevant to the thread.


Check out this good deal!
https://bitmit.net/en/trade/i/2383-418-433-mhz-wireless-commnunications-total-value-82/description


 8)

Yes, relevant.

How did you get ahold of these so cheap, and how many do you have?  I'm going to bid just so I can play with it, but I might need two.

Sorry, i only have a set in 418 MHZ and a set in 433 Mhz.
I had them for a while for a project. That project will never materialize.
The funny thing is, I was trying to figure out what I would do with them today and ran into this thread.
Pure coincidence!

I paid full price and I'm glad to liquidate them to someone who will put them to good use.

Yes - it would also be less integration work just to have one radio. Keep It Simple.
For transfer of secret data you could use - dare I suggest it - a wire. :-)

If I must, but most users are too lazy to do that everytime it's actually necessary.

Maybe this GNU Radio Software Defined Radio project is something that can be of help:

http://dev.emcelettronica.com/gnu-radio-open-source-software-defined-radio

SDR's still cost too much.