Potential bug in bitcoin: long-range attacks.

[agorism]

It is possible to build a new chain from the genesis to 300,000 in just 5 minutes with a terahash computer. When new nodes join the network, it is not possible for them to distinguish the real chain from fake chains. terahash computers only cost $3000

Minimum difficulty to mine blocks is 00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff or so.
When building your own chain, you can carefully select the time to write on the block so that difficulty stays at a minimum.

If someone created thousands of chains like this, would bitcoin survive?

[telepatheic]

This isn't a bug because chains are selected in terms of cumulative difficulty not length of chain. Very quickly a node can distinguish the real chain from the fakes.

[cbeast]

Hashes are slow to create and fast to verify.

[activebiz]

Where can one get a terrahashcomputer

[cbeast]

Potential bug in fiat:
Someone invents a 3D printer that can make perfect copies of any fiat currency.

[agorism]

Where can one get a terrahashcomputer

https://products.butterflylabs.com/homepage-new-products/1-th-bitcoin-miner.html

This isn't a bug because chains are selected in terms of cumulative difficulty not length of chain. Very quickly a node can distinguish the real chain from the fakes.

Aha! This was the information that I wanted. Thank you.

[bluemeanie1]

checkpoints.

[gmaxwell]

checkpoints.

Have nothing to do with this.  A general tip: if you are commenting on the security of Bitcoin and the word "checkpoint" comes to mind, you are probably confused.

This thread was answered completely and correctly in the very first response. This attack does not exist because Bitcoin chooses the chain with the most work, not the most blocks.

[jl2012]

Where can one get a terrahashcomputer

https://products.butterflylabs.com/homepage-new-products/1-th-bitcoin-miner.html

This isn't a bug because chains are selected in terms of cumulative difficulty not length of chain. Very quickly a node can distinguish the real chain from the fakes.

Aha! This was the information that I wanted. Thank you.

The fact that such an obvious and simple attack has never happened suggests it can't happen. Shouldn't you realize that?

[Evil-Knievel]

This message was too old and has been purged

[Meni Rosenfeld]

This isn't a bug because chains are selected in terms of cumulative difficulty not length of chain. Very quickly a node can distinguish the real chain from the fakes.

Then it is even easier to perform this attack, in theory.
All you would have to do is create a whole bunch of low-difficulty blocks with nearly the same timestamp, then after the "difficulty adjustment" in your branch of the blockchain would result in a super large difficulty. Solve that one block and the blockchain is broken.

This is a bit harder than you describe but it is indeed possible. See Section 4 ("The Difficulty Raising Attack") of Lear's paper. It's towards the end of the paper, the first half is about a different attack.

[gmaxwell]

The fact that such an obvious and simple attack has never happened suggests it can't happen. Shouldn't you realize that?

Well, take care there— lots of things are busted without ever being noticed.

Then it is even easier to perform this attack, in theory.
All you would have to do is create a whole bunch of low-difficulty blocks with nearly the same timestamp, then after the "difficulty adjustment" in your branch of the blockchain would result in a super large difficulty. Solve that one block and the blockchain is broken.

This from the guy who was going around claiming to sell a bogus magical ECDSA cracker. I guess the deadline has passed for my challenge, no keys broken? So sad for you.

In any case, no this isn't actually interesting either— because you have to do as much work as the whole network to get ahead of it in terms of expectation. So you might as well say "you could go mine as much as the network until you get ahead of it"— something you can't do without more computing power than it (much more, in the case that you start far behind it) since the expected required computing power would be equal. The only change is the variance. (and indeed, you can construct some kind of not very interesting very low probability example out of the difference in variance, but like your fraudulent ECDSA cracker, its not very interesting in practice)

(And— since you don't seem to understand any of the technical details about the system at all— I guess I also need to point out that the difficulty can only increase by a factor of four per retarget, though thats not really necessary for what what you're talking about to not bay a concern, though it does frustrate an attempt at a lucky roll).

[greatway]

I am not so sure, given that bitcoin has been around for quite some time already .. if there is a vulnerability ... someone would have exploited it.  I bet it is not easy.

[cr1776]

This isn't a bug because chains are selected in terms of cumulative difficulty not length of chain. Very quickly a node can distinguish the real chain from the fakes.

Then it is even easier to perform this attack, in theory.
All you would have to do is create a whole bunch of low-difficulty blocks with nearly the same timestamp, then after the "difficulty adjustment" in your branch of the blockchain would result in a super large difficulty. Solve that one block and the blockchain is broken.

Note cumulative, not last.

[jl2012]

This isn't a bug because chains are selected in terms of cumulative difficulty not length of chain. Very quickly a node can distinguish the real chain from the fakes.

Then it is even easier to perform this attack, in theory.
All you would have to do is create a whole bunch of low-difficulty blocks with nearly the same timestamp, then after the "difficulty adjustment" in your branch of the blockchain would result in a super large difficulty. Solve that one block and the blockchain is broken.

Note cumulative, not last.

He's talking about cumulative, but that's irrelevant. The expected work required for that "super large difficulty block*" equals to the cumulative work of all blocks in the past 5 years

(*ignoring the 4x adjustment rule)

[Meni Rosenfeld]

In any case, no this isn't actually interesting either— because you have to do as much work as the whole network to get ahead of it in terms of expectation. So you might as well say "you could go mine as much as the network until you get ahead of it"— something you can't do without more computing power than it (much more, in the case that you start far behind it) since the expected required computing power would be equal. The only change is the variance. (and indeed, you can construct some kind of not very interesting very low probability example out of the difference in variance, but like your fraudulent ECDSA cracker, its not very interesting in practice)

I think it's more interesting than you make it out to be. Consider the fact that if you try to reorg the entire blockchain, you have 100% chance to eventually succeed, no matter how low your hashrate (assuming that the ratio between your hashrate and the network's has a positive lower bound).

[gmaxwell]

I think it's more interesting than you make it out to be. Consider the fact that if you try to reorg the entire blockchain, you have 100% chance to eventually succeed, no matter how low your hashrate (assuming that the ratio between your hashrate and the network's has a positive lower bound).

Indeed, while I was well aware of growth making the historical hashing inconsequential (http://bitcoin.sipa.be/powdays-50k.png) and playing the reorg lottery I hadn't considered that particular possibility before reading that paper (thanks for the link). Though it does require also exponential growth, which is physically senseless in some sufficiently long run. It would probably be interesting to explore the probability distribution with a relaxed form of that assumption.

[Meni Rosenfeld]

I think it's more interesting than you make it out to be. Consider the fact that if you try to reorg the entire blockchain, you have 100% chance to eventually succeed, no matter how low your hashrate (assuming that the ratio between your hashrate and the network's has a positive lower bound).

Indeed, while I was well aware of growth making the historical hashing inconsequential (http://bitcoin.sipa.be/powdays-50k.png) and playing the reorg lottery I hadn't considered that particular possibility before reading that paper (thanks for the link). Though it does require also exponential growth, which is physically senseless in some sufficiently long run. It would probably be interesting to explore the probability distribution with a relaxed form of that assumption.

That's the beauty of it - the result doesn't require exponential growth (though it does help a bit). If the hashrate of attacker and network is fixed to eternity, the attacker still has a chance of 100% to succeed eventually. This is because the harmonic integral diverges (the cumulative PoW increases linearly, so his probability of success each day decreases inversely linearly. The sum of this goes to infinity and this can be translated to 100% probability of success).

A positive lower bound on the hashrate ratio is a sufficient (though not strictly necessary) condition for this guarantee.

[gmaxwell]

That's the beauty of it - the result doesn't require exponential growth (though it does help a bit). If the hashrate of attacker and network is fixed to eternity, the attacker still has a chance of 100% to succeed eventually. This is because the harmonic integral diverges (the cumulative PoW increases linearly, so his probability of success each day decreases inversely linearly. The sum of this goes to infinity and this can be translated to 100% probability of success).

But if the hashrate will not be increasing exponentially, you can prohibit difficulty adjustment patterns that do. Though practical fixes aren't needed against something whos probability becomes non-trivial only after life-of-the-solar-system timeframes, which was what I was going for when talking about working out the distribution and not just the asymptotic behavior.

[jl2012]

The fact that such an obvious and simple attack has never happened suggests it can't happen. Shouldn't you realize that?

Well, take care there— lots of things are busted without ever being noticed.

Yes, such as the OP_RETURN bug and the negative balance bug. The one suggested by OP, however, is too obvious comparing with the said ones.