Did Satoshi Nakamoto leave the door open for a heist?

[KenJackson]

The Nakamoto paper said in the introduction,

The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.

So I'm just wondering how much thought has been given to the possibility that some evil-doers are borrowing processing power and ramping it up for a short-timeframe heist of beau coup bitcoins.

"The cloud" has bazillions of terraflops of available computing power.  And who knows how much processing power you could muster for a while by wheeling and dealing and using leverage.

The more bitcoins are worth, the more the attack will be worth it.

[1713942481]

1713942481

[1713942481]

1713942481

[jgarzik]

Read the whole paper.

You cannot "steal" existing coins without the proper keys.

With sufficient CPU power you can double-spend, and mine a lot of new coins for yourself.

[KenJackson]

You cannot "steal" existing coins without the proper keys.

The statement I quoted seems to have been stated with mathematical precision--implying theft is possible with enough processing power to overwhelm the honest nodes.

And only so many bit coins can be mined in a given time, but that raises another issue.  I wonder at what price it will be profitable to hire the cloud to do legitimate bitcoin mining. And if that will happen.  And what effect it will have on the bitcoin economy.

[deepceleron]

Read the whole paper.

You cannot "steal" existing coins without the proper keys.

With sufficient CPU power you can double-spend, and mine a lot of new coins for yourself.

With sufficient CPU power I hash my forged block that transfers all the coins to my account. Then with sufficient CPU power I confirm it six times in a row. Your version of history where I don't have all the coins is now an unofficial fork of the blockchain that the clients delete.

[jgarzik]

Read the whole paper.

You cannot "steal" existing coins without the proper keys.

With sufficient CPU power you can double-spend, and mine a lot of new coins for yourself.

With sufficient CPU power I hash my forged block that transfers all the coins to my account. Then with sufficient CPU power I confirm it six times in a row. Your version of history where I don't have all the coins is now an unofficial fork of the blockchain that the clients delete.

To repeat, for the cheap seats:  you cannot steal existing coins without the proper keys.

[deepceleron]

Read the whole paper.

You cannot "steal" existing coins without the proper keys.

With sufficient CPU power you can double-spend, and mine a lot of new coins for yourself.

With sufficient CPU power I hash my forged block that transfers all the coins to my account. Then with sufficient CPU power I confirm it six times in a row. Your version of history where I don't have all the coins is now an unofficial fork of the blockchain that the clients delete.

To repeat, for the cheap seats:  you cannot steal existing coins without the proper keys.

If we suppose "sufficient CPU power" to be arbitrary and overwhelming power greater than the Bitcoin network's existing hash rate, and a greater number of malevolent actor clients on the network than legitimate, can you educate me why this, or even pushing out a new genesis block, cannot be done? The clients can verify the entire blockchain of hashed blocks from the first to the last and know that mine needs to be hashed against the previous, but what is it in the raw block that still requires private keys if I want to craft a block of my evil design and have the network resources to say that the block is legitimate?

[JoelKatz]

With sufficient CPU power I hash my forged block that transfers all the coins to my account. Then with sufficient CPU power I confirm it six times in a row. Your version of history where I don't have all the coins is now an unofficial fork of the blockchain that the clients delete.

That won't work. Forged blocks will not be accepted regardless of how the long the chain containing them is. The length comparison only applies when the client is confronted with multiple *valid* chains.

In order to create a valid block that transfers bitcoins from any source other than mining that very block, you must meet the requirements of the transaction that sent those bitcoins. In the typical case, that will require a signature from the recipient's key.

The paper was talking specifically about security against having transactions 'undone' and possibly replaced with conflicting transactions. Undoing a transaction does little harm, the transaction can just be re-posted. Replacing with a conflicting transaction is only possible if the attacker can get his hands on a conflicting transaction. If I'm sending the coins, only I can generate a conflicting transaction. So he cannot take my coins if they've already been sent to me.

[Rob P.]

With sufficient CPU power I hash my forged block that transfers all the coins to my account. Then with sufficient CPU power I confirm it six times in a row. Your version of history where I don't have all the coins is now an unofficial fork of the blockchain that the clients delete.

That won't work. Forged blocks will not be accepted regardless of how the long the chain containing them is. The length comparison only applies when the client is confronted with multiple *valid* chains.

In order to create a valid block that transfers bitcoins from any source other than mining that very block, you must meet the requirements of the transaction that sent those bitcoins. In the typical case, that will require a signature from the recipient's key.

The paper was talking specifically about security against having transactions 'undone' and possibly replaced with conflicting transactions. Undoing a transaction does little harm, the transaction can just be re-posted. Replacing with a conflicting transaction is only possible if the attacker can get his hands on a conflicting transaction. If I'm sending the coins, only I can generate a conflicting transaction. So he cannot take my coins if they've already been sent to me.

+1, cannot happen.  Owning > 50% of the hashing power of the entire network only grants you the *ability* to double spend your own coins and/or reverse transactions on your own coins.  Even then, you'd also have to maintain that position in the hashpower hierarchy, or risk having your entire branch reverted to the "correct" one, thus undoing all of your double-spends (and all of their children).

The coins live in the network.  You only have rights to move them around, they cannot be destroyed, only lost.

[KenJackson]

+1, cannot happen.

I hope you guys are right.  But the very words "cannot happen" seem very dangerous--a dare.

The Domain Name System (DNS) was regarded as solid and secure for almost two decades.  Then three years ago somebody found a flaw that allowed an attacker to trivially hijack an arbitrary website, e.g. a bank.

In that case, fortunately, the guy that found it behaved very responsibly and it was fixed before it became public knowledge.  But incidents like that make me nervous when I hear a chorus of people saying "cannot happen".

[JoelKatz]

+1, cannot happen.

I hope you guys are right.  But the very words "cannot happen" seem very dangerous--a dare.

What we mean when we say "cannot happen" is that we know precisely what it would take to make that particular attack work, and know that it is beyond anyone's capability for the foreseeable future.

The Domain Name System (DNS) was regarded as solid and secure for almost two decades.  Then three years ago somebody found a flaw that allowed an attacker to trivially hijack an arbitrary website, e.g. a bank.

Well that's always the big risk -- that someone will find an attack you didn't think of. That has happened to bitcoin in the past (the overflow attack), and the fact that it was dealt with so well is encouraging.

In that case, fortunately, the guy that found it behaved very responsibly and it was fixed before it became public knowledge.  But incidents like that make me nervous when I hear a chorus of people saying "cannot happen".

It's easy to judge the possibility of a particular proposed scheme, especially where the design was specifically made with that attack in mind. Bitcoin uses a specific cryptograph algorithm precisely the way it was designed to be used to protect against precisely this attack. We know exactly what it would take to break that scheme, and judge the scheme still reliable.

No only that, but if there were any hints that it could not be relied upon any longer, we know exactly what we would have to do to solve that problem and how to do it. It would take two years or so to do it smoothly, but it could be done even faster in an emergency. The community as a whole has an interest in protecting the value of bitcoins themselves.

[makomk]

That won't work. Forged blocks will not be accepted regardless of how the long the chain containing them is. The length comparison only applies when the client is confronted with multiple *valid* chains.

Note that this only applies to the official client. SPV clients - such as the Android one - will accept any longest chain, including ones that spend bitcoins that don't actually exist.