Pages:
Author

Topic: New vulnerabilities in the advent of off-the-shelf ASIC mining - page 2. (Read 4434 times)

kjj
legendary
Activity: 1302
Merit: 1026
The miner timestamp.  We already enforce rules on the miner-provided timestamps,
No, the rule is enforced between blocks strung together, not the blocks on their own. Block 2 can not be more than 2 hours before block 1 or whatever the rule is. If another whole chain of blocks come along from a common point, as long as they follow that one rule about block X+1 being less than 2 hours before block X, then it is valid.

In main.cpp, the two rules are:

CBlock::CheckBlock ensures that a block's timestamp is no more than 2 hours into the future at the time it is first seen by a node.
CBlock::AcceptBlock ensures that a block's timestamp is greater than the median of the timestamps of the 11 blocks before it.

AcceptBlock is called before a block is written to disk, CheckBlock is called earlier.

In practice, this gives you about 3 hours of wiggle room.

Quote
Read his attack again, it depends on timestamp manipulation to multiply the amount of DOS-blocks generated by a factor of 16 (per month).
It does not depend on timestamp manipulation, it depends on creating a chain with a very low difficulty with the intent to spam the network. I don't think Sergio's specific example works because of the 2016 block requirement for changing difficulty though.

By starting from the latest checkpoint and waiting a month, he is able to generate 16 times as many blocks as he would otherwise be able to generate.  The amount of blockspam is directly connected to the interval between the block chosen for his starting point (typically the latest checkpoint), and today.

Quote
There is absolutely no reason why the network should consider a block mined today, with a timestamp from today, as a candidate to create a month-old fork.
Well perhaps you should check the code then, because it is perfectly valid. The only thing preventing this is hard-coded checkpoints.

Yes, thank you, my entire point was that the code as written today allows this case.  I'm suggesting that it might maybe be a good idea to change that.  Did you even read my posts?

Right now, an attacker doesn't even need to create much of a chain.  He can just generate enough blocks to trigger the difficulty adjustment a few times, and then keep generating the lowest difficulty block over and over again.
staff
Activity: 4242
Merit: 8672
The only way to recover from these attacks is by downloading a new version of the client with a new checkpoint with a much higher block difficulty. I can't think of any other possible patch. Maybe the interval between new releases
during the transition from GPUs to ASICs could be decreased.
Good idea, and easy to do.
I've got a half-finished "user-defined checkpoint" patch in my personal git tree, so users, merchants, and big mining pools can decide for themselves to add checkpoints on-the-fly (via an 'addcheckpoint' RPC command) to protect against this type of attack.
I feel fairly leery about this. In terms of the general baddness, having nodes on mutually inconsistent forks, _regardless of the details_, is actually much much worse than just about anything that can happen short of some kind of long sustained attack (which can't be fixed by adding checkpoints if it really is sustained).  The ability to add a checkpoint is basically a big footgun because it sounds pretty attractive in the short term or with simplistic analysis (ignoring what happens when everyone else doesn't do the same thing as you).   Basically, getting a transaction finney attacked on you _sucks_ and there surely would be a temptation to try to go around and convince people to set some checkpoint to undo it. Perhaps you might even get some friends to join some co-conspiring network to coordinate it a bit and allow you to pay the participants ala GPUMAX (introducing an ugly bit of central control if it grew to a relevant size). But actually getting enough of a majority of hash-power onto it would be very hard... and as bad as your finny attack is, the currency being split in two for potentially days or weeks as this is resolved would be much much worse to everyone collectively (though this is mostly an externalized cost that you don't care about when you start the snowball). And if it _isn't_ hard to get the hashpower onto it, then it really is a highly vulnerable central point of control itself.

We think and work so hard to make sure that any BIP rule change we'd introduce doesn't carry the risk of triggering a hardfork... An addcheckpoint RPC could just as easily be called addhardfork.

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.

As far as "any other possible patch" goes, I believe the correct (and really boring) solution to any all orphan/weak-chain flooding concerns, which doesn't depends on any checkpoints or other potentially risky compromises:   Select the best chain first based on headers only (very small! 10 years worth is under 50 MB), then only switch to a second best if the best fails validation. I wrote about this sometime back, and originally suggested it somewhat earlier when roconnor went a bit fatalistic thinking that there was no way to produce a DOS resistant node without checkpoints. IIRC, roconnor was satisfied that header based chain selection was sufficient.  Though I haven't bothered writing any code for it, as I don't think it's actually important. For me it's enough to know that it's possible, without any incompatible changes, or especially difficult implementation.  This remedy would be greatly improved by either reducing the timewarp attack surface by making the timestamp rules slightly stricter, or increasing the min difficulty after some height to, say, 10000 (~irrelevant hardfork risk: only a risk if bitcoin fails), or both... but generally solves the problem even without those tweaks.
hero member
Activity: 798
Merit: 1000
The miner timestamp.  We already enforce rules on the miner-provided timestamps,
No, the rule is enforced between blocks strung together, not the blocks on their own. Block 2 can not be more than 2 hours before block 1 or whatever the rule is. If another whole chain of blocks come along from a common point, as long as they follow that one rule about block X+1 being less than 2 hours before block X, then it is valid.

Quote
Read his attack again, it depends on timestamp manipulation to multiply the amount of DOS-blocks generated by a factor of 16 (per month).
It does not depend on timestamp manipulation, it depends on creating a chain with a very low difficulty with the intent to spam the network. I don't think Sergio's specific example works because of the 2016 block requirement for changing difficulty though.

Quote
There is absolutely no reason why the network should consider a block mined today, with a timestamp from today, as a candidate to create a month-old fork.
Well perhaps you should check the code then, because it is perfectly valid. The only thing preventing this is hard-coded checkpoints.
kjj
legendary
Activity: 1302
Merit: 1026
* This suggests a potentially useful patch.  I haven't checked, maybe something like this is already implemented.  If you get a block that could potentially replace block N, but the new block's timestamp is more than X hours after the timestamp in block N, refuse to relay it.

Besides the fact that timestamps are added by the miner creating the block, if you mean the time when the blocks are received this breaks the "unified vision" of one block chain. Forks can exist permanently without users or miners having done anything wrong. But this is also along the same lines of what Gavin suggested. This is mostly in the case of a network split though which I think is pretty unlikely and shouldn't be guarded against when it leaves the network open to certain types of more important attacks. If there is a permanent fork, then leave it up to the users and the community to decide which chain is the correct one. In the case of a network split where one country's internet is cut off or something, it is obvious.

The miner timestamp.  We already enforce rules on the miner-provided timestamps, this is just one more.  It shouldn't cause any problems for honest forks, even when X is pretty low.

Read his attack again, it depends on timestamp manipulation to multiply the amount of DOS-blocks generated by a factor of 16 (per month).  There is absolutely no reason why the network should consider a block mined today, with a timestamp from today, as a candidate to create a month-old fork.

The only legitimate reason to allow this is for cases like the infamous overflow bugfix.  I doubt that such a fix would work the same way today as it did back then, but if that is a concern, setting X to something high, like 168, should provide plenty of time.
legendary
Activity: 4522
Merit: 3183
Vile Vixen and Miss Bitcointalk 2021-2023
2. What would happen if miners switch ALL to this cheap 30X ASIC solution and this vendor has build-in a backdoor in the chip to:

- Stop working after block height N
- Hide some private information (e.g. part of the private key) in the nonce (as a side channel attack)

...

In the second case, an attacker may compromise the wallets of all miners!
The second scenario is impossible. Mining software (that isn't a wallet-stealing trojan) does not have access to your private keys, and the hardware has no access to any kind of data except for what the software sends to it. There is no way for an ASIC (or any other kind of mining hardware) to know about your private keys. It isn't even necessary (or even useful) to run a miner on the same system that has your private keys on it in the first place.
hero member
Activity: 798
Merit: 1000
* This suggests a potentially useful patch.  I haven't checked, maybe something like this is already implemented.  If you get a block that could potentially replace block N, but the new block's timestamp is more than X hours after the timestamp in block N, refuse to relay it.

Besides the fact that timestamps are added by the miner creating the block, if you mean the time when the blocks are received this breaks the "unified vision" of one block chain. Forks can exist permanently without users or miners having done anything wrong. But this is also along the same lines of what Gavin suggested. This is mostly in the case of a network split though which I think is pretty unlikely and shouldn't be guarded against when it leaves the network open to certain types of more important attacks. If there is a permanent fork, then leave it up to the users and the community to decide which chain is the correct one. In the case of a network split where one country's internet is cut off or something, it is obvious.
kjj
legendary
Activity: 1302
Merit: 1026
I just don't see any part of this working.

First, a million dollars won't do it because a million dollars worth of available ASICs don't exist.  I guess the million could be spent stealing (or developing) a clone, but that is just an argument in favor of getting ASIC miners into peoples' hands ASAP.

Second, the attack chain would be laughably invalid.  Currently, I think you might be right about the DOS potential here, but only from flooding the network with blocks that can never be connected.  See * below for mitigation.

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.)

* This suggests a potentially useful patch.  I haven't checked, maybe something like this is already implemented.  If you get a block that could potentially replace block N, but the new block's timestamp is more than X hours after the timestamp in block N, refuse to relay it.  X=3 fits with the currently allowed amount of clock skew in the network, but X=6, X=12 or X=24 would be more conservative, and any of them would work.
hero member
Activity: 798
Merit: 1000
doesn't benefit the attacker at all,
Have to stop having this mentality when the potential exists for someone who just wants to ruin the network. Otherwise it's head-in-sand.

Quote
is easy to fix, and that would be easy for the network to recover from.
Anything that requires developer intervention and community consensus is not an easy fix and is very bad for the reputation of the network.

Quote
I've got a half-finished "user-defined checkpoint" patch in my personal git tree, so users, merchants, and big mining pools can decide for themselves to add checkpoints on-the-fly (via an 'addcheckpoint' RPC command) to protect against this type of attack.
So *some* *might* be protected by an option that isn't required or part of the protocol. Who just lost 250k because of an unencrypted wallet?

Instead have a second difficulty determined by bitcoin days destroyed over the last 2016 blocks and work some kind of formula around that so it is easy for a legitimate block chain to overtake an attacking chain with significantly less hashing power. Only a client update, no options needed, no breaking changes, secure from sustained 51% attack. Unless the attacker controls more bitcoin days destroyed than the entire rest of the network activity during the time frame of a history rewrite, it will be ignored. If anyone is worried about this possibility, then there could be a further addition to the formula similar to checkpoints on the fly.
legendary
Activity: 1652
Merit: 2301
Chief Scientist
First: I think it is extremely unlikely that somebody would spend a million dollars on an attack that takes months to pull off, doesn't benefit the attacker at all, is easy to fix, and that would be easy for the network to recover from.

The only way to recover from these attacks is by downloading a new version of the client with a new checkpoint with a much higher block difficulty. I can't think of any other possible patch. Maybe the interval between new releases
during the transition from GPUs to ASICs could be decreased.
Good idea, and easy to do.

I've got a half-finished "user-defined checkpoint" patch in my personal git tree, so users, merchants, and big mining pools can decide for themselves to add checkpoints on-the-fly (via an 'addcheckpoint' RPC command) to protect against this type of attack.
hero member
Activity: 728
Merit: 500
165YUuQUWhBz3d27iXKxRiazQnjEtJNG9g
Quote
People should use open source mining solutions....

I want people to use open source solutions, but for-profit miners are going to use whatever works best for them.

This is one of many reasons that it's important to keep developing Litecoin and other alternative chains.
hero member
Activity: 555
Merit: 654

In the following months Butterfly Labs (http://www.butterflylabs.com/) will be introducing a new ASIC miner product.
This will increase the MHash/s/$ approximately 30 times. Other vendors such as http://www.btcfpga.com are building competing products.

Let's take the "BitForce Single SC" (BF) as reference:

- 40GH/s
- $1,299

Although at a first glance this look like a huge benefit for the network, there are new vulnerabilities we must face:

1. There will be a window of time where new vulnerabilities will be exposed to a government or anyone willing to invest 1M USD to temporarily (1 week?) disrupt Bitcoin and generate a rush to the coin (a big price fall). An attacker can exhaust the bandwidth of all the connections in the Bitcoin network.

The attacked needs a 820 BF (1M USD) to achieve 32800 GH/s (or 2^45 hash/s).

The attacker chooses the root block at index 193000 (which has an PoW of 2^53 hashes (53 zero bits)).
From checkpoints.cpp: (193000, uint256("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))

Since block 193000 was issued at date 2012-08-09, the attacker waits 4 months so ComputeMinWork() allows the acceptance of
PoW of 4 bits less. (This lowers the money required 16 times)

He can reach 2^53 hashes in 53-4-45=16 seconds. Then he starts creating a branch from block 193000, each block being 1 Megabyte long, with current (not past) block time, and having a single coinbase transaction, and extending the chain of the previous created block.
Sending 1 block every 16 seconds.
All nodes start spreading these past blocks, possibly filling the entire network bandwidth and blocking normal blocks for as long as most of the nodes upgrade.
Also the attacker will be filling 5.4 GB of hard disk every day, and the blockchain on disk will need to be manually pruned to cut the offending branch so it is compacted to its normal size.
The only way to recover from these attacks is by downloading a new version of the client with a new checkpoint with a much
higher block difficulty. I can't think of any other possible patch. Maybe the interval between new releases
during the transition from GPUs to ASICs could be decreased.

2. What would happen if miners switch ALL to this cheap 30X ASIC solution and this vendor has build-in a backdoor in the chip to:

- Stop working after block height N
- Hide some private information (e.g. part of the private key) in the nonce (as a side channel attack)

In the first case, the network will suddenly stop and, because of a higher difficulty reached, there will one block every 5 hours during a
period of 14*30 days=420 days !!

This will destroy Bitcoin for a long while and will require a manual adjustment in the difficulty.

In the second case, an attacker may compromise the wallets of all miners!

People should use open source mining solutions....

Best regards,
 Sergio.
 
Pages:
Jump to: