New vulnerabilities in the advent of off-the-shelf ASIC mining

[Mike Hearn]

FWIW I like the idea of being able to add checkpoints via RPC. Yes, there's potential for abuse but Bitcoin has always had "last resort" safety mechanisms in it, like the ability for alerts to shutdown the RPC interface, checkpoints themselves, etc.

If anything "addcheckpoint" is not really the right solution. What we really need is a "markinvalid" RPC that marks the given transaction as rejected, triggering a hard-fork point. Otherwise you can only checkpoint blocks that were already mined. If something goes wrong and miners are all working on a chain that is broken somehow, you really want the ability to temporarily switch to an alternative chain. If it's the block itself that you want to kill off then just mark the coinbase as invalid.

If there's no central distribution list for these and it's up to miners/merchants to invoke the RPC by hand, IMHO it feels safe enough. In a worst case scenario of a sustained attack a set of scripts that downloads a list of bad transactions from a central place and auto-blacklists them could be thrown together in a hurry, but I doubt it'd survive to become some kind of central authority in the absence of tremendous external pressure (like governments forcing miners to use their blacklists).

[1715152723]

1715152723

[1715152723]

1715152723

[1715152723]

1715152723

[1715152723]

1715152723

[1715152723]

1715152723

[flower1024]

as it is possible that a user checkpoints a chain which becomes orphan i think we need a mechanismen to override user checkpoints by checkpoints from new bitcoin versions

[Sergio_Demian_Lerner]

First, I just want to thank kjj for linking the code that shows how BF work, gmaxwell for his proposal and all for this excellent discussion.

Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...

Or even we could create a special Alert message that comes with a new checkpoint embedded.

This would be a mid point between Gavin and gmaxwell positions.

I vote for signed checkpoints, with a confirmation dialog shown to the user. +1

[gmaxwell]

How would an attacker re-write the timestamps in the blocks that everyone already has?  The original chain has a sequence of blocks with (more or less) evenly spaced timestamps, and there is no possible way for an attacker to make that look like it has a jump in it.  The best the attacker could do would be to pile up the timestamps, one after another, in his attack chain.  He can't go backwards to make a jump.
Essentially, if we are looking at a possible fork from, say, a month ago, the first block in the newly presented fork really should have a timestamp from a month ago too.

He would cut back one week, and create a fork with a bunch of consecutive timestamps.  e.g. 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 ....

Then a new bootstrapping node would startup and see "1 1 1 1 1 1 2 2 2 2 2 2 3 3 3". Then it would hear the valid chain, and see "1 600 1200..." and think that it jumped.

which would be a de facto protocol change.

Then any bugfix that changes the typical network behavior is a 'protocol change'. Not really a useful distinction, in my view. We're just arguing over defintions, which is a waste of time. The important point is that a fixed node is fixed without upgrading any of its peers.  Call that whatever you like.

If there's no central distribution list for these and it's up to miners/merchants to invoke the RPC by hand

Of course there would be, otherwise it would be a config option and not an RPC.

We do not have any 'dynamic risk' "last resort" mechanisms anymore: no safemode alerts. Checkpoints only get changed by updating the software.
Your reject-txn sounds like sipa's fork-mode patch.

Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...
Or even we could create a special Alert message that comes with a new checkpoint embedded.
This would be a mid point between Gavin and gmaxwell positions.

0_o I don't consider that a midpoint at all. We'd first have to rename Gavin "Bitcoin Bernanke", but fortunately I know he's smart enough to not accept that job.  I don't quite see how making it possible for anyone who kidnaps Gavin to shut down bitcoin is an improvement over your million dollar scale attack, as I expect it would cost much less than a million dollars to do so...

[Gavin Andresen]

Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...

No. Absolutely not.

[kjj]

He would cut back one week, and create a fork with a bunch of consecutive timestamps.  e.g. 1 1 1 1 1 1 2 2 2 2 2 2 3 3 3 ....

Then a new bootstrapping node would startup and see "1 1 1 1 1 1 2 2 2 2 2 2 3 3 3". Then it would hear the valid chain, and see "1 600 1200..." and think that it jumped.

But that is less than 10 minutes, well inside the range to be "not a jump".  A timestamp discontinuity isn't "more than the last few blocks", it is "more than the rules say".

which would be a de facto protocol change.

Then any bugfix that changes the typical network behavior is a 'protocol change'. Not really a useful distinction, in my view. We're just arguing over defintions, which is a waste of time. The important point is that a fixed node is fixed without upgrading any of its peers.  Call that whatever you like.

The nodes that do not use your algorithm would still be flooding the network (or at least each other) with BS blocks.  The only way to prevent that is to force nodes to switch to your algorithm, which would be a protocol change.  Currently, they are allowed to do it however they want, as long as the end result is the same.  The difference is subtle today, but I think it will be less so as the network outgrows the current homogeneous period.

If there's no central distribution list for these and it's up to miners/merchants to invoke the RPC by hand

Of course there would be, otherwise it would be a config option and not an RPC.

We do not have any 'dynamic risk' "last resort" mechanisms anymore: no safemode alerts. Checkpoints only get changed by updating the software.

Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...
Or even we could create a special Alert message that comes with a new checkpoint embedded.
This would be a mid point between Gavin and gmaxwell positions.

0_o I don't consider that a midpoint at all. We'd first have to rename Gavin "Bitcoin Bernanke", but fortunately I know he's smart enough to not accept that job.

+1

[gmaxwell]

But that is less than 10 minutes, well inside the range to be "not a jump".  A timestamp discontinuity isn't "more than the last few blocks", it is "more than the rules say".

Perhaps you need to speak more concretely then. What rule?
Any rule you can imagine could be met by a natural block gap. E.g. you set it to two hours. Then a natural two hour gap happens, and an attacker can create a chain killer fork that covers that gap.

The nodes that do not use your algorithm would still be flooding the network (or at least each other) with BS blocks.

No. They wouldn't. Nodes only propagate what they believe to be the best chain.

[Sergio_Demian_Lerner]

An answer to a bit old post...

Third, what gets passed to the device is the midstate.  The device has no idea what the current block height is, nor does it have access to any sort of keys.  (See here for an example of what exactly gets sent to the device.)

gmaxwell has pointer out that to me that there are some fields that are passed to the bitforce hardware. They are:

- timestamp    
- difficulty target

Any one of them can be used code a "time bomb".

I would have been better if Hash(Hash(Header-without-nonce) || nonce) would be chosen for PoW instead of Hash(header) for Bitcoin.

[kjj]

But that is less than 10 minutes, well inside the range to be "not a jump".  A timestamp discontinuity isn't "more than the last few blocks", it is "more than the rules say".

Perhaps you need to speak more concretely then. What rule?
Any rule you can imagine could be met by a natural block gap. E.g. you set it to two hours. Then a natural two hour gap happens, and an attacker can create a chain killer fork that covers that gap.

Sorry, I thought that I had been quite clear about it.

The rule that I suggested was "not more than X hours newer than the deep block with the same height", where X is >=3.  Keep in mind that this is only for deep replacement, that is important.

As in, I'm currently on block # 197,710.  I get a new block claiming to be # 193,001.  The timestamp on the new block is from yesterday, which is ~2.5 million seconds later than the block # 193,001 that I already have, thus I conclude that the new block is bogus and drop it.

However, if there was a natural network gap of more than X hours, and an attacker presented a chain during that time, that chain wouldn't really be an attack, it would be the chain.

[kjj]

gmaxwell has pointer out that to me that there are some fields that are passed to the bitforce hardware. They are:

- timestamp    
- difficulty target

Any one of them can be used code a "time bomb".

I would have been better if Hash(Hash(Header-without-nonce) || nonce) would be chosen for PoW instead of Hash(header) for Bitcoin.

Ouch, you are right, the ASIC producers really could create timebomb chips.  Nice catch.  If we ever figure out who Satoshi is, we'll have to give him a little crap for missing that potential attack.  But honestly, who could have seen that one coming?

The good news is that there are several ASIC designs ongoing, and they will presumably all come out of different fabs, so in the long run, the diversity of the network should provide some safety.

Maybe we should put this on the hardfork wishlist.  Changing the hashing method entirely would be, well, bad.  But we could accept two different hashing methods, the old way and the new safer way that doesn't leak any information to the hashing device.  That way we aren't breaking the large investment into current ASICs, while allowing miners the option of safer hashing when they expand/replace their gear.

(Verification would be trivial, wouldn't even need a new block version.  If the normal hash attempt doesn't work, try it again with the header's nonce field set to zero and the external nonce value set to whatever was in the block.)

Amusingly, on IRC we were talking about chips that could accept the entire header as their input rather than the midstate.  This way, ASIC designers could build their chips to refuse to participate in certain kinds of attacks, which would reduce the amount of trust that miners need to have in the pools they use.  I'm curious how the mining world would balance these two concerns with contradictory solutions.

[Sunny King]

Maybe we could implement the idea of dynamic checkpoints (Gavin) but only if they come signed by the Alert signing key ...

No. Absolutely not.

Good to know that Gavin is willing to stand the ground. I am happy that Bitcoin has good leadership who's going to reject any compromise of the core principles of Bitcoin's design.

And the PPcoin results convinces me that there is a fairly substantial part of the community that doesn't really grok decenteralized systems— and that they would use a checkpoint RPC foolishly if given a chance, especially if guided by leaders that don't understand the technology themselves (e.g. people who run justly loved services, but understand bitcoin poorly enough, or are indifferent enough to it, to pick the worst transaction styles for scalability)— since with PPcoin people are willing to pay a premium for coins which are checkpointed block by block by some anonymous authority (I mined a bit and even had one of my blocks orphaned by one of their centrally controlled checkpoints!).  Perhaps, because of this reality, bitcoin is already doomed to become a failed experiment— a modest money maker for the earliest participant but something that eventually becomes undifferentiated from all the rules-of-convenience based currencies, but I hope not.

I would like to make a statement here as ppcoin's designer I fully understand the purpose of decentralization. We plan to phase out ppcoin's central checkpointing mechanism gradually as the network matures and gains strength against powerful attackers. Well I understand some folks would always doubt about our sincerity, but as of our v0.2 I am confident ppcoin can indeed remove dynamic checkpoints eventually. If you really thought about how an alter chain is started you would know that 51% attack is a serious threat to a young chain.