I shall begin this brief (for me) essay by defining terms. For the purposes of this writing, secure computing shall be defined as any combination of software and hardware that offers a low probability of unauthorized software running with functional privileges via an authorized method of access. There are lots of methods of reaching a computer that don't exist on 99% of all computers, this does not mean those computers are secure.
Cryptography shall concern methods that are not broken at time of writing. Good cryptography concerns cryptography where no analysis, quantum methods or AI is likely to establish a shorter solution than brute-forcing within the next 20 years. Good cryptography includes One Time Pads generated by essentially random number sources (such as galactic noise sources), but that's about it. Good cryptography is extremely easy to falsify, but very difficult to prove.
Cryptocurrencies are adequately defined, but I shall define a Robust Cryptocurrency as being any cryptocurrency that does not replace one dependency with another. It should be entirely self-contained, making it impossible for any entity to disable, trace/codebreak via injectable errors or timing attacks, etc. It needs to make the currency in the Shadowrunner books look medieval. As yet, nobody knows how to make cryptocurrencies robust.
Since I've effectively said that two thirds of the problems are unsolved (perhaps unsolvable), I'll limit myself to security in this first post.
There are several approaches to security. The first is remote access. This is the focus of the OpenBSD group. Through their auditing and analysis, they can truthfully say their system is essentially impervious to remote exploits. You'll notice they're more cautious about DoS attacks, although it has been a while since I've heard of any DoS vulnerability that could take down a box. It's a limited environment but it's good.
A second approach is documented in the Rainbow Books and in the Common Criteria. These require that users cannot access data/programs not intended for them, that data/programs not intended for them cannot be made available (even a sysop would find it complex) and that this extends to data/programs sent over networks. That last bit is somewhat buried in the documents, but even network packets are supposed to be subject to mandatory access controls. The most complete versions should be mathematically proven correct as far as possible, with unprovable components kept isolated and required to work through the proven security code. Some documents require that hardware is used to enforce separation of content, tamper-proofing, etc.
Typically, proofs involve proving that for a given function, the precondition will be true and that there is no path through the function that can produce an invalid postcondition. Going one stage further, you might use a dialect of a programming language that doesn't permit surprises and which also guarantees the binary does what the source code instructs (eg: Verified C, Spark2014). You can even go further, using models to prove timing behaviours and to establish that all states that can be entered are valid. This is not popular, as many real systems have a lot of states.
To make sure that integrity is maintained, there are additional standards (such as FIPS) that govern trustworthy algorithms and trusted implementations.
Combining the two above, you would have a system that was difficult to break into, impossible to abuse without breaking out of the restricted envelope and very difficult to identify an improperly handled state that can be utilized to escape into the wider machine.
If you're only 95% paranoid, this is sufficient. Very few governments go this far, even when they're supposed to. But can you go further? Oh, sure!
Tamper-proofing makes it impossible to remove a hard drive. Encrypting it (provided the encryption was adequate), would make doing so pointless. Processor-in-Memory architectures provide some intriguing possibilities for RAM, but it's not a terribly vulnerable target at this point.
Ok, so we can envisage a system that (prior to adding on firewalls, active network intrusion detectors and host intrusion detectors) is pretty secure. Almost useless, but secure. I'd trust such a system to handle the financial side of eCommerce, bank-to-bank transfers via SWIFT, the database of everyone enrolled in the VA, the sorts of critical systems they actually use store-bought laptops for.
Could such a system be used for cryptocurrencies? Only if you were interested in a hardware implementation, similar to Mondo card only impervious, and only if blockchain was modified. You have no determinate time for a card to synchronize with the Internet, every offline blockchain has an indeterminate fraction of the whole genuine blockchain, you have to use Game Theory and statistics to identify just how indeterminate a transaction is.
Just as Mondo cards had a public and private key pair for securing and signing transactions, you'd need to have transactions digitally signed and counter-signed. Until merged with the blockchain, you'd need all cards that have seen the transaction to sign that they saw it and, if they recognize a previous signing key, to verify that the signing key is valid.
But could you do this? Sure, a Faraday cage, Flash RAM, an ASIC and a mobile processor will do wonders. SEL4 and the necessary software, all doable in principle. In practice, you'd end up with something larger than a 1960s Star Trek communicator, very limited popularity amongst cryptocurrency fans (since, by definition, it has to be a closed standard, although not closed tech, in meatspace) and zero popularity with governments or banks (as you can trace regular cryptocurrency transactions).
But this has nothing to do with being practical. This has to do with playing with ideas to see where they lead. And, for that, this meander works great.
As I'm increasingly fond of saying, the world is shaped by doers.
https://opendime.com/
It's effectively a USB stick that stores a private key that can only be read once the external drive is physically broken, meaning you know whether the contents are secure or not. Transactions associated with that private key are still tracked by the blockchain.
The biggest blocker to security is making so it's not... well... a blocker. If it's difficult, people simply won't do it. Look at PGP, it's been around for years, yet OpenWhisper Systems have gone and implemented e2e encryption for everyone by DEFAULT on WhatsApp by making it easy to use! That's one hell of a conversion rate.
You are absolutely right that difficulty is the main obstacle to adoption.
OpenDime is an interesting system, it's not as multi-use as I'd like and I'd question whether it is as secure as it appears. Certainly, it's not as secure as I'd like. Having said that, it looks extremely efficient and effective at what it does do. If I was to use a disposable system that was an equivalent of a cheque or a traveller's cheque (and I used to use both extensively, it's only since I came to the US, where there was no cheque guarantee card and a whole host of restrictions on who accepted them that I've essentially stopped using both) then OpenDime looks like the system I'd use.
Yes, it is a matter of doing. What I have in mind is a lot more powerful than OpenDime and necessarily a lot more secure, but built from a similar premise of off-grid transactions.
When it comes to doing, I plan to be doing quite a bit on security (I'm working on a secure network appliance at the moment) but I point you to Plato's Republic where he says the wealthy don't bother to work well and the poor can't afford to. The same is true today, only the market is now exceedingly complex. "Poor", in the sense Plato meant, doesn't refer to absolute money but to the relative amount needed to enter a given market. The barriers are often higher than one would like.
Yes, making security something that's everyday and below the conscious level (it just works) was one of the original goals of IPv6, until certain agencies ripped that out. Making it "just there" for everyone is still doable, but unless you want to go one service at a time, it's going to require a degree of cunning. It can be done, though.