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.