Imagine that even a small percentage of smartphones had dash7 radios in an urban area such as NYC, and you wanted to send an encrypted text to your friend. You know your friend's dash7 id (or rather your phone does) and you use bitcoin to pay very small amounts to the smartphones of those who "hop" the text to it's destination (or forwards it across the Internet on your behalf, if that is more efficient)
I've had a similar idea before, when I was thinking on possible ways to reward independent, anonymous routers. I was thinking of Tor relays first, but then I realized the same protocol could be used to pay for MANET independent routers like the ones you describe.
Such a thing would be wonderful, for the reasons jim618 describes above: you tackle both the banking industry and the telecoms, not to mention all governmental Internet censorship.
But it is not that easy to come by with such a protocol. The main problem I see is that the service of hoping a little amount of data has to have near zero costs. One would expect to pay something like what BitcoinTorrentZ charges for his downloads, that is, bitcents per gigabyte. But how do you do that in a no-trust scenario? Your routers would want the money right away, to route even little messages. But you can't pay with bitcoin like that, you would have a huge amount of microtransactions. Transaction fees would be much higher than the actual amount per packet you want to pay to each router, it's unfeasible. And also there's the fact that bitcoin transactions are a big chunk of data to be included in every data package you want to send to a network.
Unless scripts can somehow help with microtransactions. I wonder, is it possible to use scripts to create a transaction of, say, 1BTC, but which isn't yet redeemable, and then, together with each data packet, you send a little key which allows the receiver of that 1BTC to redeem a small fraction of it, like 0,1mBTC for example? If you ever route 10.000 packets through that router, it would be able to redeem the entire transaction, otherwise he can only redeem what you've authorized and the rest must be sent back to you. Maybe instead of a "little key" you send a new signature of the total amount the receiver can spend, I don't know. It's important that whatever you're sending isn't very big, because it will go together with every data package.
I'm totally ignorant on how powerful can transaction scripting be.
PS: Although answering to messages on the topic, I realize I'm getting off-topic here. Should we open a new one?