It seems to me that you are conflating "offline" with "air-gapped". An air-gapped system is a system that is never online and/or lacks the ability to even connect. The idea of using an air-gapped system is that that system contains your private keys and no other system does, ever. So, there is simply no way for a hacker, no matter how clever, to siphon away your private keys(1).

It doesn't matter very much if you disconnect a non-airgapped computer while you perform sensitive operations because a hacker may have installed some malicious code that is recording your session whether you are online or not. The moment you re-connect, the malicious code begins "relaying" its session recordings back to home base.

For reference, here's the wiki on cold storage.

(1) - There are still risks. A Windows system with autoplay can launch code from a dirty USB key, for example.

Note: DNA is not unique, identical twins have identical DNA.


1) Uniqueness is easy. The most secure method would be to assign a random number (or, rather, allow the individual to assign themselves a random number) and register its hash with a blockchain-based notary.

2) This constraint is impossible to satisfy through any non-interactive system because it requires a continuous proof-of-life. Let's say Alice and Bob are in a room together. They can each be sure that the other is alive simply by observing the other person (let's call this "visual verification of liveness"). As soon as Bob leaves the room, however, Alice cannot be certain that Bob is still alive without some updated proof-of-life. Even if he gave her a public key just before he left the room and a message arrives one hour later signed with the matching private key, someone could have kidnapped Bob, composed the message, forced him to sign it, and then shot him. So, when Alice acts on the belief that Bob is alive - based on "his" message (as verified by the PK signature), she is mistaken about his actual state of liveness. Instead, Alice would need a provably fresh "proof-of-life" or "remote verification of liveness" and, no matter how you set this verification mechanism up, it must by definition be interactive since the definition of "Bob is presently alive" is "Bob can be presently interacted with."

That said, if your need for identification is sufficiently paramount, then the individual to be ID'd can be troubled with an interactive verification. There's an ID company I read about recently (the name escapes me) that is using a multi-factor ID system pioneered by intelligence agencies that uses three (or four, depending on how you count) factors to verify identity. These boil down to "something you know, something you are, and something you have." So, you might know a passphrase, for example, you might be your fingerprint or retinal scan, and might have some kind of tamper-proof dongle. We can add the blockchain into that in order to prove presence (i.e. that the verification is interactive and not stale or pre-recorded). There is no "fire-and-forget" method that will substitute for this, however, so this is not the kind of ID that you use for buying alcohol and cigarettes, it's the kind a CEO uses to remotely validate a business decision or which a President uses to remotely authorize a politically sensitive air-strike.

3) This is also easy, what with the blockchain.

Precisely. What really makes Meltdown/Spectre so dangerous is that user-space code (read: "web browser") can potentially image your kernel memory. Secrets like passwords or keys may be stored in memory while it is being siphoned out to some remote party who is exploiting your machine and these secrets may, in turn, be useful in further breaking into your network, your system, your emails/logins, spoofing (certificates, public-keys), or - for crypto-holders - even your wallet. So, that's the risk profile for Meltdown/Spectre. These are strictly read-only attacks. Folks, go read the whitepapers and the official announcements from the affected companies (I have) before spreading FUD.

This is why you shouldn't be running untrusted user-code on a router. A router is (ought to be, anyway) a standalone device for this very reason.


Who is using a network platform for browsing the web? Please name names so they can be fired immediately.


No, that's not the best wording because Meltdown/Spectre require the presence of malicious, user-space code in order to operate. If your kernel is compromised, for example, you have no need to worry about Meltdown/Spectre because the software that has compromised your kernel can do far worse things than anything that Meltdown/Spectre attacks can do. The level of FUD on this particular news story is astounding to me. This is my field, I worked for one of the companies involved in this for nearly a decade, in computer architecture.


Meltdown/Spectre are very specific attacks. The security problem is separate. Any self-contained hardware/software environment is oblivious to Meltdown/Spectre, as long as it really is self-contained.


No, stating that they are insecure is overdoing the FUD.

No, your router is not vulnerable to Meltdown/Spectre because it's not running any applications, it's a standalone device.

It doesn't really matter because hardware wallets are not running applications - the hardware wallet is a "closed ecosystem".


Try reading the summary of the linked blog post. It's crucial to keep in mind that Meltdown and Spectre are (timing) side-channel attacks. This means there has to be something that's living "on the side", some applications or something. Since a hardware wallet is only running the wallet software (it literally can't run anything else), there is no side-channel. Really exotic side-channels like power-draw analysis still require physical access to the wallet. If you can't keep your wallet physically secure, you have bigger problems.

Security is a holistic problem and keeping this in mind is key to shutting down all this FUD.

It's a self-contradiction. See here. Specifically:

"In classical modal logic, a proposition is said to be possible if and only if it is not necessarily false (regardless of whether it is actually true or actually false);"

From this definition, "everything is possible" means "everything is not necessarily false", which is false, since there are necessarily false statements (contradictions). Thus, "everything is possible" is a self-contradiction.

First, bring it to 350 degrees. Bake for 6 to 8 hours, basting regularly to prevent drying out. Fork it gently to determine cookedness and remove it when it has become tender. A thermometer can help ensure that it has been thoroughly cooked.

 

So much FUD in this thread. I have written up a blog post explaining Meltdown and Spectre for the average person (who has some familiarity with computer terminology).

The NSA has no interest in stealing your Bitcoins. If they are stored on your PC and the NSA wanted to steal them, believe me, they could steal them and the Meltdown and Spectre attacks have nothing to do with how they'd take them. For most people, a hardware wallet is the best way to keep your coins secure. Hardware wallets are not vulnerable to the Meltdown/Spectre class of attacks.

If nothing is impossible, then "everything is impossible" is possible, in which case, nothing is possible.

Yes, thank you. Both provide quadratic speedup so I forget which is which. QC is not my field, I just see a lot of obvious misinfo and FUD on this forum and feel the urge to try to set the record straight as best I can.

Shor's algorithm only provides quadratic speedup. That means that the approx. 256 bits of security of secp256k1 becomes approx 128 bits of security in a world of readily-available, at-scale quantum computing. I wouldn't call 2¹²⁸ brute-forceable "in a reasonable amount of time."

It's unknown. The advice against address-reuse is based on the general risk of future breaks against ECDSA, which cannot be ruled out. It's certainly not susceptible to brute-forcing, since that is on the order of 2²⁵⁵, which is effectively infinite (more than the number of particles in the universe, etc. etc.) But if some clever mathematician figures out a cryptographic break against ECDSA that weakens ECDSA keys, it would be necessary to sweep funds from wallets secured only by ECDSA to something else. P2PKH/P2WPKH resolves this issue by publishing only the key-fingerprint instead of the entire pubkey. Even if there is a break against ECDSA, there is no short-term risk of your coins being stolen. Coins in long-term cold storage (timelocked), for example, need this feature.

Speculation: Big institutional player with HFT equipment? There has been a drastic change in the mempool since Dec 6, that's for sure.

Note that I made a mistake on the size of the secp256k1 key space - it is greater than 2²⁵⁵, not approximately 2¹²⁸.


"entire key space is bruteforced" --> It's difficult to give a good metaphor for how huge the secp256k1 keyspace is... it's effectively infinite.

The birthday paradox tells us that the average time to collision for an n-bit hash function is 2^n/2, in our case, 2¹²⁸. Fortunately, 2¹²⁸ is large enough that it can also be treated as "effectively infinite". At this writing, the hash rate is 8.4x10¹⁸ hashes per second. The average time to collision if you could test public keys at this rate (you can't) would be 585 billion years.


See above. If you owned all the hashing equipment in the entire Bitcoin network and could somehow use that equipment to test keys at the same rate as the hashrate, it would take 585 billion years to brute force any key. Clusters are powerful systems for computation but their compute power only grows linearly with cluster-size - a cluster of 10,000 nodes is only 10x as powerful as a cluster of 1,000 nodes. The difficulty of breaking cryptosystems grows exponentially in the number of bits of security (assuming there are no mathematical breaks).


I think your arithmetic is off by more than you realize.

Um. Wuuut?

Reality is quantum ... try it for yourself. Also.

The word "computer" has been changed by the transistor, integrated circuits, personal computers and the Internet. 50 years ago, the word "computer" had a lot more mystique and referred to a much broader class of systems. Today, the word "computer" refers to a very definite kind of system, the kind you're using to view this post. Prior to the rise of the digital computer, there were many types of computers, including mechanical computers and analog electronic computers. Analog computers are very efficient for specialized problem solving.

Quantum computers are best thought of as a very noisy analog computer. On a digital computer, we ask a question just once, and it either calculates the answer or hangs. On an analog computer, we pose a problem within the computer's domain and then we set it solving. Usually, the analog computation proceeds "directly" to the solution, that is, with a minimum of wait time. But the results of the analog computation are subject to limits of precision imposed by physical measurement - to get more digits of accuracy, you require finer measurement and more lossless action within the mechanism or circuit. For a quantum computer, we have the same measurement problem as with analog computers, plus the solutions it gives do not have the property that digital computers have - either correct or it hangs. Rather, the quantum computer will return a "distribution" of answers over repeated computations that hopefully clusters tightly around an average value, which we take to be the solution.

Imagine you're a physicist running simulations on some difficult problem of physics. Your options:

- Build a digital simulation (requires a lot of programming). Once finished, set the simulator running and walk away. When you come back, either the simulator will have solved your problem (exactly) or it will have hung.

- Build an analog simulator. You have to build a new simulator for each problem domain you want to solve. It also requires high-precision parts and cannot perform simulations to the level of precision of a digital computer. But, once built, it's much faster than a digital computer.

- Build a quantum computer. This also requires a lot of programming but you don't have to build a new quantum simulator for each problem domain since quantum computers are "general-purpose". It requires high-precision parts and other exotic measures to prevent "decoherence" (a problem that other computers do not have). It can, in principle, perform simulations to the level of precision of a digital computer but each "run" of a quantum computer is random, meaning, you don't get "the answer" on any particular run of the computer, you must run the problem repeatedly and take the average on the output. This makes quantum computers quite different from either analog computers or digital computers.

Happens to all of us. As I was falling asleep last night, I realized that I've been consistently thinking that the private key space for secp256k1 is 2¹²⁹ when it is actually 2²⁵⁶-2¹²⁹, a vastly larger number, close to 2²⁵⁵. Duh.

That's why abutingting's argument is a non sequitir. QC is not a direct threat to Bitcoin for a variety of reasons - the cost of quantum computing is a part of the reason that FUD about QC is ridiculous, but not because anyone is being "priced out" of quantum computing.

These could be added to Script as new opcodes and you can use P2WSH to implement a smart-contract that uses them.


You can use a script to hash-lock a transaction multiple times over. This would not really add any security, however, it would just be a silly way to subsidize miners with needless transaction fees.