Thank you for your reply. 1) First, it doesn't particularly matter as long as they are not powerful enough to execute a 51% attack. Second, government securit

Thank you for your reply. 1) First, it doesn't particularly matter as long as they are not powerful enough to execute a 51% attack. Second, government security agencies (or rather, the laws granting them their powers) do get rolled back in practice once they're found to be unconstitutional or supremely unpopular. A few examples off the top of my head: * The US doesn't intern Japanese-Americans anymore, but did for "national security" reasons during WWII. * The US has suspended and later restored habeas corpus during the Civil War, Reconstruction, colonization of the Philippines, and WWII (again, due to "national security"). * The US passed and later repealed (or allowed the expiration of) the Alien and Sedition Acts (also "national security"). * The SCOTUS has limited the powers granted by the Espionage Act of 1917 over the course of the 20th century (particularly w.r.t. The Pentagon Papers). I personally think if the NSA started to attack its own citizens en masse via a 51% attack, the citizens and their representatives would soon look to curtail its power to do so (especially since there's money involved). Maybe I'm too optimistic, but time will tell. 2) Alice's goal is to make it so that it's not cost-effective for her adversary to compromise all of her private keys. She must estimate how much time and money her adversary is willing to spend, and then devise a way of storing her offline keys so that its not worth their while to compromise them. Effectively, she is insuring her keys against theft, just as she might insure another easily-stolen valuable asset. This means Alice can bring to bear the whole field of actuarial science ("predicting the future" as you call it) to find the best way to keep her keys safe. The final, and fatal, problem with this plan is that Alice's bindings to 'her' blockchain are subject to false flag operations / account compromises (OpenID, email, etc), or else they are relying on other PKI schemes (DNSSEC, TLS), which just pushes the problem back to the starting gate. Regarding account compromises, the public key bundle can only be written once, and Alice has (presumably) insured her private keys. This limits the effectiveness of false flag operations--once Alice (or whatever username she claims) puts a key bundle, no one else can do so without being caught and rejected. Before addressing full compromises, consider this thought experiment: if you were to one day meet me in person, how would you know it was me? Sure, I could say "I am jude- from Hacker News" and show you my GitHub page, my government proofs of identity, my fingerprints, etc. But, that could all be forged, and pretty easily by the likes of the NSA. Proving that I am who I say that I am will ultimately require a leap of faith on your part--there has to be some information I can show you that will convince you that I am who I say that I am (i.e. you believe the information I present would be infeasible for an imposter to forge--you can apply actuarial science to estimate the costs and payoffs to an impostor, as well as likelihoods and conditional probabilities that an impostor would want to spoof you, and so on). Now, maybe the actuaries got it wrong, and maybe it became feasible for Alice's adversaries to compromise all of her keys, and maybe that happens. In general, there are one of three solutions: * Alice uses a trusted 3rd party to vouch for her over the impostor (undesirable as you say, since this is DNSSEC and TLS all over again). * Alice posts all of the CSRs she generated earlier thereby revoking the impostor's identity, and then races and beats the impostor to re-generating the identity/keybundle. Not always possible, since Alice may have lost the CSRs, and/or Alice might lose the race. This leads to option 3: * Alice abandons the old identity and builds a new one. Granted, option 3 is messy and hard--a lot of people would be in a world of hurt if they lost their Facebook accounts, for example. However, this is why you have lots of offline keys stored in lots of different places in the first place--to avoid this situation altogether. Since we want to avoid centralized 3rd parties, I don't see any other way than to do our best to insure against total key compromises. Perhaps one extension to the protocol would be to devise a secure way for Alice to generate more public keys, if she still retains enough private keys...