The comic didn't say 12 random characters.  Most people don't use 12 random characters for their password.  So was the problem the example in the comic or your understanding of the example in the comic?

which is useful against a set of random words how?

Forget a full bar, I will never buy because I can't afford a full ton.  Everyone knows a full bar is just a fractional ton and who buys a fraction of anything.

Once again making false statements as fact.  Why not say "I believe it is redundant" or "I can't see a scenario where miners unknown to each other don't duplicate work accidentally?".  You state you don't know much about Bitcoin but you feel confident about making absolute statements of fact about something you don't know much about?

The different computers (1, 2, a trillion it doesn't matter) use different inputs and thus (barring some isolated implementation errors) never attempt work which has already been attempted.  Miners aren't hashing some random value, they are hashing the blockheader and Satoshi designed it so there would be no duplication of work.

https://en.bitcoin.it/wiki/Block_hashing_algorithm

Even if everything else is the same in a block, the coinbase tx for each miner will be unique and thus the hash for that tx will be unique and thus the merkle tree will be unique and thus the merkle root hash will be unique and thus the blockheader will be unique.

The fastest known algorithms to derive a private ECC key from the public key are O ( 2^(n/2) ) where n is key length.  Now if the attacker ignores this faster solution and simply tried random (or sequential) private keys until a match was found then it would take much longer (2^256 not 2^128) however security is based on the fastest possible solution.

It is important to point out that the fastest algorithms require the PubKey to be known.  If the PubKey is not known then the only method would be an exhaustive attack on the private key and computing the PubKey.  This is another good reason to not reuse addresses (and thus the pubkey remains unknown).

Key size doesn't necessarily equal security.

All of these key/digest sizes have 128 bit security
128 bit AES (symmetric encryption)
128 bit SHA-2 (hashing algorithm)
256 bit ECC (public key cryptography - elliptical curve)
3,072 bit RSA (public key cryptography - Integer factorization)

Generally hashing algorithms and symmetric key systems have a security equal to their key length (unless they have vulnerabilities or weaknesses).  However due to the nature of public key systems (the public key has a mathematical relationship to the private key) this not true for public key systems.  The key size will always be larger than the effective security (or key strength).  How much larger depends on how difficult it is to derive the private key from the public key.  If you look at RSA and ECC you can see that to achieve the same security RSA requires much larger keys (and signatures).  This makes ECC based systems more useful in decentralized systems like Bitcoin.

I am not going to waste my time if you can't even realize that flops aren't ever used in brute forcing private keys.

That is my point and until 100% of nodes upgrade their software they would be vulnerable to an isolation attack.  It creates a more fragile and exploitable system than users wallets simply being able to switch to the longest chain with no action required on the part of the user.

Someone with a lot of bitcoins could do a public contest.  Brute forcing a 256 bit ECDSA key (has 128 bit security) is infeasible so nobody would attempt it (well not anyone with any real power) however one could make the problem simpler.

For example move 1,000 BTC to an address and provide publicly half of the private key.  This would mean someone could brute force the key on average in 2^64 attempts.  The blockchain will be proof of if someone accomplished it or not.  Even that would be an incredibly difficult problem, but it is feasible (back to the whole infeasible vs improbable).

If/when someone can steal those coins just keep in mind that brute forcing a full key would be 2^64 = 18,446,744,073,709,600,000 x harder/longer.

That is 100% incorrect.  In the future how about phrasing things you don't know as a question.  There are no redundant attempts on each block (baring the implementation issue at a specific pool where the pool incorrectly issues the same work to more than one worker).

Your wallet already does that.  Bitcoin doesn't work on the concept of balances it works on the concept of creating and destroying outputs.

So if you have an output worth 10 BTC and you want to send me two your client creates a tx which destroys the 10 BTC output and creates two new outputs valued at 2 BTC (to me) and 8 BTC (to a new address in your wallet).


Zero.  We are interested in integer math when brute forcing private keys.  Flops refers to floating point math.  There is no conversion factor which would work for all systems.  Generally speaking computer science doesn't look at the individual implementations to determine if something is infeasible.

As an example say a given computer would require 1000 steps to make one attempt to brute force a key and it will take more energy than 20 of our suns and 10 billion years.  Now lets say you could reduce that to a single step.  Ok now it only takes 1 billion years and more energy than 2 of our suns.  Either way it is infeasible.

Any classical computing problem which is more complex then O (2^128) is generally viewed as infeasible.  Some people use the word improbable but infeasible is a stronger word.  It is improbable you will win the lottery however it is infeasible that you will brute force a 128 bit symmetric key (simply requires material and energy on a scale the human race is utterly incapable of).  In comparison to the lottery it would be like you win seven lotteries in a row by purchasing just a single ticket.

The main issue is that in the event of a flaw which causes the network to fork you have now hard coded that fork.

For example if the db bug issue which caused a fork in the network, miners on the longer fork modified their blockchains to support the shorter fork.  So some intervention was required but for all 100,000+ other nodes they simply saw a re-org once the the shorter fork became the longer one.  If they used ratcheting checkpoints they would have been permanently locked onto a minority fork and attackers could have exploited that.

There may be some merit in using a ratcheting checkpoint system however it would have to be set much much deeper than 6 blocks.  Even 144 blocks (one day) may be insufficient.  Something like 1,024 blocks (~1 week) is more the range that would be conservative enough.

Also understand a ratcheing checkpoint system only helps existing nodes.  Bootstraping nodes would be remain vulnerable as they haven't seen the longest chain yet.

Addresses are the Public Key Hash (PubKeyHash) along with with version and checksum information encoded in Base58.  When you send funds to a user you are sending it to their PubKeyHash (which your client reverses from the address you provide).  This is why one reason why address reuse is discouraged.  Once funds are spent from an address the actual PubKey is known (it included in the input so other nodes can validate the signature).

Which is still essentially nothing.  For classical computing you move the timescale from quadrillions of years down to only millions of years.  Congratulations.  

No we haven't, no key with 128 bit strength has been brute forced. You can't simply compare key size.  A 256 bit ECC key has equivalent strength to a 3,072 bit RSA key and a 128 bit symmetric key/hash.  You may be talking about some individual algorithms being cryptographically broken, it is hard to tell because you are all over the place.  I already pointed out that is possible but it has nothing to do with


No people like me would have been warning that 56 bits was insufficient due to the fact that it was within 1000x of what current computing power was capable of.  That is a far cry from saying 128 bit key strength is secure because it uses energy on a scale that would make brute infeasible.   If we pretend the entire Bitcoin network (30 PH/s) "could" brute force symmetric keys at the same speed instead it would be able to brute force an 80 bit symmetric key in about one year.  If it was 1000x more powerful it could brute force a 96 bit symmetric key in about a century.  If it was a million times powerful it would still take on average a millennium to brute force a 128 bit symmetric key.  To do it in a year would require a system which is a billion times more powerful.


Proven doesn't mean what you think it means.  Proven doesn't mean spouting out false statements, gibberish, and strawmen.


Dwave's system is not capable of implementing Shor's algorithm.  It uses a process called quantum annealing.  Quantum Computing isn't some super duper magical bullet which solves all problems all the time.   Quantum annealing is a pretty cool concept for solving certain types of problems like pathfinding, simulating organic processes, network optimization, etc.   It is completely useless for the purposes of breaking cryptographic keys.

On the progress of building a true general purpose quantum computer capable of implementing shor's algorithm the progress has been very slow.  15 was factored in 2001 using Shor's algorithm and a 4 qubits QC.  By 2012 that had progressed to factoring 21 in using 5 qubits.  One estimate for the total physical qubits (including circuits for error control and correction) necessary for breaking 256 bit ECC is on the order of 40,000 qubits.  We went from 4 to 5 in the space of a decade and the "finish line" is 40,000 qubits.  That could be doubled by switching to a 512 bit curve.  Quantum Decoherence is a bitch.  

The problem becomes increasingly difficult as the size of the computer grows.  It may not be possible to accomplish that in our lifetimes.  Wake me up when someone factors 32 bit number using quantum computing.  If QC becomes a credible threat Bitcoin can evolve to addresses which use post-quantum cryptography.

Which for the purpose of this dubious scenario is like the guy with a bucket emptying the ocean laughing at the guy with a teaspoon trying to do the same thing.

In depends on what you mean by "time".  If given an infinite amount of computing power, an infinite amount of storage space and an infinite amount of time.  However under more realistic constrainsts you may never see a 160 bit collision before the heat death of the universe.  So saying "there will be collisions" especially the plural is dubious.  There may eventually be a collision but even that isn't guaranteed.

The later is only assuming a QC with sufficient qubits (~40,000) to implementing Shor's algorithm against 256 bit keys is ever possible.  The largest quantum computer which has implemented Shor's algorithm is 5 qubits.  It "cracked" the number 21 into the prime factors 7 & 3 (5 bit encryption if you want to call it that) after a mere 9 months.

Still you misunderstand that scope.   It doesn't matter how many addresses have been used in the past.  To steal funds you would need to produce a collision with a funded address.

Given a max of 2.1 quadrillion satoshis there simply can never be more than 2.1 quadrillion funded addresses.  Even if you assume 2.1 quadrillion funded addresses (dubious but good for an absolute upper bound) that puts the possibility of a preimage attack at 2^160 / ~2^50 = 2^110 which is many magnitudes beyond what is possible with brute force.

Another way to look at it is the Bitcoin network has ~30 PH/s.  Let assume all of that could be used to brute force keys instead.  Now lets also assume that it is as easy to compute and check a pubkeyhash (it isn't).  There are roughly 1 million funded PubKeyHashes.  If the entire network attempted to brute force them it would take on average 823,233 years to break a single pubkeyhash and the payoff would be a random amount of bitcoins but the average reward would be ~2.1 BTC.   The chance of a collision in a century would be 0.0121%. 

No those of us that understand math won't keep saying that because it is accurate.  Of course is you are worried about flawed PRNG then use a true hardware random number generator (quantum effect or avalanche noise).

There is no known bias to the distribution of ECDSA public keys.  Even if some bias did exist 2^256 is a large space it would take a rather massive bias in distribution in order for there to even be a 1% chance of collision in the thousand years.

Correct.  The rules for the "main chain" would need to be modified to enforce using blocks from the "secondary chain" for the purposes of validation.   Still even if those changes were possible you don't really gain anything from just using a smaller block interval on the main chain.  It is a lot of complexity to just reinvent a network with a smaller block interval.

Using the term "address funded" is still incorrect but yes.  However understand that a 0-confirm tx can be double spent (in theory it is harder to accomplish than most people imagine) and a 0-conifrm tx which relies on an unconfirmed tx for its input is doubly risky.  If the parent tx is double spent, fails to confirm (not included in a block due to insufficient fees), or has its tx id mutated then the child tx will never confirm (it now has an invalid input).

That would not provide any security.  Just because the tx is confirmed in the "second blockchain" doesn't mean the attacker can't still double spend it in the "main blockchain".  To enforce such requirement would mean a radical change of the Bitcoin protocol, and a change like this is simply not going to happen.

Bitcoin doesn't work on the concept of balances.  All transactions in their input reference a specific unique unspent output (by tx id and index) on the network.  That output either exists or it doesn't.  If it doesn't the transaction is simply invalid.