Manipulating the difficulty?

[bittercoin]

Hello.

What will happen if a node announces a block whose timestamp is false (i.e. earlier or later than the real creation time)? AFAIK, the difficulty is affected by the timestamps. If so, isn't it possible for an attacker to manipulate the difficulty if the network accepts such block?

Thank you.

[1714835396]

1714835396

[1714835396]

1714835396

[1714835396]

1714835396

[nanotube]

there are certain timestamp validity checks:
https://en.bitcoin.it/wiki/Block_timestamp

[bittercoin]

there are certain timestamp validity checks:
https://en.bitcoin.it/wiki/Block_timestamp

Thank you. I forgot to check the wiki.

[Jim Hyslop]

What will happen if a node announces a block whose timestamp is false (i.e. earlier or later than the real creation time)? AFAIK, the difficulty is affected by the timestamps.

Difficulty is based on the number of blocks created, and is adjusted every 2016 blocks.

[nanotube]

What will happen if a node announces a block whose timestamp is false (i.e. earlier or later than the real creation time)? AFAIK, the difficulty is affected by the timestamps.

Difficulty is based on the number of blocks created, and is adjusted every 2016 blocks.

no, difficulty is based on the number of blocks created /per unit of time/.

[Jim Hyslop]

What will happen if a node announces a block whose timestamp is false (i.e. earlier or later than the real creation time)? AFAIK, the difficulty is affected by the timestamps.

Difficulty is based on the number of blocks created, and is adjusted every 2016 blocks.

no, difficulty is based on the number of blocks created /per unit of time/.

Thanks for the correction. However, I'm going to add a trivial correction to your correction   Difficulty is based on how long it takes to generate the 2016 blocks. If it takes longer than expected (two weeks), the difficulty is reduced. If it takes less than two weeks, then the difficulty is increased.

[molecular]

What will happen if a node announces a block whose timestamp is false (i.e. earlier or later than the real creation time)? AFAIK, the difficulty is affected by the timestamps.

Difficulty is based on the number of blocks created, and is adjusted every 2016 blocks.

no, difficulty is based on the number of blocks created /per unit of time/.

Thanks for the correction. However, I'm going to add a trivial correction to your correction   Difficulty is based on how long it takes to generate the 2016 blocks. If it takes longer than expected (two weeks), the difficulty is reduced. If it takes less than two weeks, then the difficulty is increased.

Without the constraints, though, if an attacker mined the 2016th block and put a timestamp a year in the future and that somehow got accepted, the difficulty would drop really low. Next thing to happen: the following 2016 blocks would be mined within a couple of hours and the difficulty would readjust to previous value after that.

[Jered Kenna (TradeHill)]

What will happen if a node announces a block whose timestamp is false (i.e. earlier or later than the real creation time)? AFAIK, the difficulty is affected by the timestamps.

Difficulty is based on the number of blocks created, and is adjusted every 2016 blocks.

no, difficulty is based on the number of blocks created /per unit of time/.

Thanks for the correction. However, I'm going to add a trivial correction to your correction   Difficulty is based on how long it takes to generate the 2016 blocks. If it takes longer than expected (two weeks), the difficulty is reduced. If it takes less than two weeks, then the difficulty is increased.

Without the constraints, though, if an attacker mined the 2016th block and put a timestamp a year in the future and that somehow got accepted, the difficulty would drop really low. Next thing to happen: the following 2016 blocks would be mined within a couple of hours and the difficulty would readjust to previous value after that.

In the end I'm not saying that would be  a huge problem in that it would basically just jump us ahead 2 weeks but how possible is that for someone to pull off? It seems like a pretty good sized vulnerability. Especially if a couple large miners all decided to do it.

[molecular]

In the end I'm not saying that would be  a huge problem in that it would basically just jump us ahead 2 weeks but how possible is that for someone to pull off? It seems like a pretty good sized vulnerability. Especially if a couple large miners all decided to do it.

Doesn't seem simple to pull off:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

So to set a block's time considerably into the future one would have to control quite a portion of the network (>50%?), it seems. On the other hand, you don't seem to need to have a lot of compute power, if any.

Unfortunately for the attacker:

Network time is never adjusted more than 70 minutes from local system time, however.

So it seems quite impossible to pull off setting a block's timestamp into the future considerably.

[Jered Kenna (TradeHill)]

In the end I'm not saying that would be  a huge problem in that it would basically just jump us ahead 2 weeks but how possible is that for someone to pull off? It seems like a pretty good sized vulnerability. Especially if a couple large miners all decided to do it.

Doesn't seem simple to pull off:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

So to set a block's time considerably into the future one would have to control quite a portion of the network (>50%?), it seems. On the other hand, you don't seem to need to have a lot of compute power, if any.

Unfortunately for the attacker:

Network time is never adjusted more than 70 minutes from local system time, however.

So it seems quite impossible to pull off setting a block's timestamp into the future considerably.

Good, it seems like everytime I get a little worried there's a fix built in to the system.

[molecular]

Good, it seems like everytime I get a little worried there's a fix built in to the system.

Yeah, same here. The more I learn about bitcoin, the more brilliant I think it is.

[Jered Kenna (TradeHill)]

Good, it seems like everytime I get a little worried there's a fix built in to the system.

Yeah, same here. The more I learn about bitcoin, the more brilliant I think it is.

Yeah it still worries me a little because I feel like it's impossible to have thought of everything.

[deadlizard]

Yeah it still worries me a little because I feel like it's impossible to have thought of everything.

A Multi-Terra hash miner entering the market while the difficulty is low and taking all the blocks until the difficulty rises then leaving until it falls again. rinse and repeat.

[Jered Kenna (TradeHill)]

Yeah it still worries me a little because I feel like it's impossible to have thought of everything.

A Multi-Terra hash miner entering the market while the difficulty is low and taking all the blocks until the difficulty rises then leaving until it falls again. rinse and repeat.

Doesn't seem worth it to me like that.

[deadlizard]

Yeah it still worries me a little because I feel like it's impossible to have thought of everything.

A Multi-Terra hash miner entering the market while the difficulty is low and taking all the blocks until the difficulty rises then leaving until it falls again. rinse and repeat.

Doesn't seem worth it to me like that.

It would shake out small miners and keep the difficulty lower in the long run than if you ran 24/7/365.
and if you where taking a majority of the blocks while online it would be more than worth it.

[MoonShadow]

Good, it seems like everytime I get a little worried there's a fix built in to the system.

Yeah, same here. The more I learn about bitcoin, the more brilliant I think it is.

Yeah it still worries me a little because I feel like it's impossible to have thought of everything.

Even if this were a realistic exploit, the difficulty has an adjustment rule that prohibits an adjustment of greater than a factor of four in either direction.  So the difficulty couldn't be cut down to less than a quarter of the prior difficulty.  It's still something to consider, as this is one attack avenue I don't think that I've seen discussed on this forum before.  But before we consider how difficult the attack vector may be, we need to determine what the goal would be.  If the goal is simply to spoof the difficulty calculations in order to make it easier to capture some blocks in a short period of time, (perhaps someone decided to buy a couple of hours of mining capacity on Amazon's cloud?) then really no great harm done, and if such things were to become an ongoing thing, a tighter difficulty adjustment parameter could undercut such activities.  However, if the goal was to actually harm the network in some fashion, the impracticality of the attack may not be a great defense.  How might this harm the network. or introduce another fraud vector?  thoughts?

[ryepdx]

It's still something to consider, as this is one attack avenue I don't think that I've seen discussed on this forum before.

Remember the Mystery Miner?

How might this harm the network. or introduce another fraud vector?

Well, there's that double-spend vector that keeps getting kicked about. Also...

It would shake out small miners...

...which could lead to a person eventually taking control of over 50% of the network with computing power equal to a value less than 50% of the network's power at the time of the attack's commencement.

[MoonShadow]

It's still something to consider, as this is one attack avenue I don't think that I've seen discussed on this forum before.

Remember the Mystery Miner?

Are you implying that the 'Mystery Miner' was such an exploit? 

How might this harm the network. or introduce another fraud vector?

Well, there's that double-spend vector that keeps getting kicked about. Also...

Okay, so how would this attack vector aid in a double spend fraud? 

It would shake out small miners...

...which could lead to a person eventually taking control of over 50% of the network with computing power equal to a value less than 50% of the network's power at the time of the attack's commencement.

How?

[PLATO]

Imagine Google can summon 5.4 TH/s of power. The current hashrate is .6 TH/s. For the sake of simplicity let's say difficulty adjusts every 2000 blocks.

Blocks 1-10000: Business as usual; network ends at .6 TH/s.
Block 10001: Difficulty resets. Google turns on their network; starts hashing.
Blocks 10001-12000: Google finds these blocks approximately 10 times faster than they should, or, approximately one per minute.
Block 12001: Difficulty spikes to approximately 10 times the last difficulty. Google shuts off their network; hashrates are now .6 TH/s again.
Block 12001-14000: The network finds these blocks approximately 10 times slower than they should; or, approximately, one block per hour. Instead of taking two weeks, the next difficulty reset takes five months.

[MoonShadow]

Imagine Google can summon 5.4 TH/s of power. The current hashrate is .6 TH/s. For the sake of simplicity let's say difficulty adjusts every 2000 blocks.

Blocks 1-10000: Business as usual; network ends at .6 TH/s.
Block 10001: Difficulty resets. Google turns on their network; starts hashing.
Blocks 10001-12000: Google finds these blocks approximately 10 times faster than they should, or, approximately one per minute.
Block 12001: Difficulty spikes to approximately 10 times the last difficulty. Google shuts off their network; hashrates are now .6 TH/s again.
Block 12001-14000: The network finds these blocks approximately 10 times slower than they should; or, approximately, one block per hour. Instead of taking two weeks, the next difficulty reset takes five months.

Except that can't work.  As I mentioned earlier, there is a difficulty adjustment parameter rule that prohibits the difficulty from adjusting up or down by more than a factor of four.  So the max that can be expected is that the Google can do is move the difficulty by that factor of four, which may or may not actually be worthwhile, but if the attack cannot be repeated in consecutive cycles (maybe, but I would say that it would be very unlikely to work out that way) then it's probably not a worthwhile means of manipulation for profit motives alone.  What kind of harm to the system itself could such an attack cause?