Something that would help all of these efforts would be a protocol more designed for intermittent than TCP/IP?
What if something much more lightweight could be used on mobile phones via bluetooth, searching for nodes, passing packets whenever available and allowing the user to have some manual input on what priority to give to relayed info. This could then sync over other networks as and when they become available.
Bitcoin is too heavyweight for this AFAIK. It could be used however to share more basic information. You could walk around in China with your phone spamming one and all with Tor relay node IPs for example.
I think we have limits on the disruption potential of Bluetooth? I think to relise the potential you would need to work at a lower level than simple application... anyone care to comment?
At the lower levels, one of the more interesting things I've run across is Bernstein's curvecp: http://curvecp.org/
At a higher level, the Bitcoin protocol is actually pretty good due to certain of the inherent characteristics of the early (including current) implementation. Or more accurately, it's 'being' for lack of a better description. In fact that was one of the major draws of it to me.
1) It is not real-time and has a high latency by most network standards. That is to say, the block frequency is 10 minutes though of course this is variable and random which are two very useful features of a system which is hard to analyze and attack...though in fairness not terribly relevant to this discussion. Latency kills when doing high-speed network analysis or shaping.
2) It is compact. An entire message can fit into one frame. This is key because it is fairly difficult to perform stream and correlation analysis when there is no stream. Of course there will be a handshake, but by the time a payload is inspected, it is likely already gone. The only defense is to perform DPI and filtering in real-time rather than to cut off the first payload packet when it is discovered to contain objectionable content, but doing this on all syn payload data would be expensive. Another very useful feature of a tiny and discrete message is that it can more readily hide in various cracks and crevices. I think there may even be enough frame space to effectively obscure packets in such a way that it would give filters grief but I am not sure about this.
I don't claim to be a guru at this stuff, but do have some experiences with it and again these natural defenses attracted me to the solution when I first heard about it. Basically from early on I figure that if Bitcoin never needs to protect itself against a robust and dedicated network level attack, there would not be a very compelling need for the the solution at all. Which would be great actually.
To be more clear, I probably should mention that I'm thinking more about how/if individuals can perform individual transactions in hostile jurisdictions. Hopefully it would be possible for heavier support infrastructure (e.g., miners) to operate in more 'free' environments meaning either jurisdictionally friendly locales or private networks or both.
Maybe even atmospheric sensors to detect how dedicated our repair militant was to getting the thing online again 
