How does someone find a 17 blocks in 4 seconds? Time warp attack?

Mining
21

Block 6671 came in to my computer 60 seconds after the previous block, but was timestamped 45 minutes later. Then about 40 blocks came in to my computer in the 40 minutes, about 60 secs per block. So it was a computer than was only 150/60 = less than 3x the network hashrate. If the difficulty algorithm had been looking at my clock, it would have raised the difficulty 400%, 8% per block, matching the 100% + 300% hash rate of the network. But because it was looking at the timestamps of the blocks he was sending in, it started at 180 and ended at 60 after 23 blocks, a 70% drop. There is lag to the algo, but it was supposed to be rising rapidly after fewer than 17 blocks. As it slowly rose back to the non-attack hashrate (1/3 what it was supposed to be at), he got about another 17 blocks.

They’ve had practice doing this on active coins. This appeared to be their first try on testnet with perfect success. They add exactly 3000 seconds to the clock. It’s a different kind of attack than the 10x brute force we saw earlier. They’re going to do it again when this coin launches unless other people try to copy their methods and thereby make it harder for them to do by competition.

1 Like
22

Top sleuthing @zawy. Apologies if it sounded like I didn’t have faith in you! I was just playing devil’s advocate.

1 Like
23

Ethereum uses a world clock timestamp when syncing.

24

Charts:
Difficulty before, during, and after attack
Solution times. Spikes indicate attack.
Block issued per hour. Supposed to be 24.
The last chart shows it most clearly: It’s timestamp manipulations where +1 = advanced it 3000 seconds, -1 = solves were timestamped within 1 second of each other. The dark bands at the bottom are where a lot of blocks are obtained.

Screenshot from 2016-09-08 03-24-18.png868×479 77.2 KB

Screenshot from 2016-09-08 04-55-07.png921×528 51.2 KB

25

Using a world clock external to the network is trusting an oracle (aka 3rd party).

Zcash could limit the maximum amount the clock can be advanced, and reset it to that limit when a block with an advanced timestamp comes in. I think bitcoin added a limit of 2 hours very early on, and it’s probably still used. By doing this, it will limit how many blocks can be stolen, and it will add a limit to how fast the difficulty can drop. That is the reason for not making a shorter limit: if the difficulty needs to drop, you need to let drop by allowing the miner assign the correct time if it took a long time to solve the block. As a first guess, Zcash should use 1/4 what bitcoin did, which would be 30 minutes. Then he would not have been able to add 3000 seconds each time.

But there is already a limit of the difficulty dropping in Zcash, 16%. I have advised them to remove these limits (especially the up limit) because they switched to a good averaging method, but they’re keeping the limits, which will enable all types of attacks to go on longer. This attack doubles the number of blocks stolen by keeping the limit to 8% rise per block. The reason for the limits no longer exist, which I explained at the same time I explained why they needed to go to an average of the past difficulties instead of last block (to remove the oscillations). The limits are no longer reducing the oscillations because any current oscillation is a real oscillation. The limits are uniquely helping attackers.

However, the limit going down does not directly enable more blocks to be stolen like the limit going up. It prevents other miners from getting something closer to a fair share when the attack stops. A limit of 2 hours between blocks with the selected averaging period of 17 blocks enables a maximum forced drop in difficulty to be about 1 - (2.5 min x 17) / (120 min + 2.5 x 16)= 70%. But if a 16% drop per block is going to be the limit, then it can be used to limit a time warp attack like this in an unexpected way:

As a first try to show to show what is simple but not good enough, solve for a fixed MaxTimeStamp advance to force no newest block. “Simple” means it will assume past blocks were coming in at average time: 0.16 = 1- (2.5 x 17) / (x + 2.5 x 16) => x = 10.5 minute max allowed time to next block’s timestamp. But if an attacker does several N blocks in a row with a timestamp advanced 10.5 minutes ahead of the last, the difficulty will drop by 0.84^N and the time will advance ahead further, at some point enabling retarding times again to get blocks. This is not good so the max time needs to be adjusted dynamically: back-calculate max allowed next-block-time (and re-assign timestamp if exceeded) with:

0.16 = 1 - (2.5 x 17) / ( maxTimeStampIncrease + avgPast16TimeStampIncreases x 16)

And if solve time since last block is negative, assign timestamp as if solve time was average of past 17 blocks. This does not stop users colluding to always assign the max timestamp and thereby constantly lowering difficulty by 0.84^N until it’s free to everyone as fast as latency allows and the network thinks it is the year 1,000,000. Even with this protection, Someone reaching 33% network hashrate could still get difficulty to drop 0.95 per block indefinitely, providing free blocks to everyone within 3 hours. It’s not more profitable anymore than their hashrate unless they have the lowest latency, but it would put a coin on an issuing schedule I think that is 4x faster. With a 2 hour limit, issuing I think could be 120 / 2.5 = 50x faster, destroying the coin. Has this been employed?

I believe this also removes need for using the median of past solve times in calculating the difficulty and the average can be used, which will reduce the errors and swings in difficulty and times to solve under normal non-attack conditions.

Problem solved?

To help more, remove the 8% up limit, which will infrequently be exceeded unless there’s an attack, in which case it needs to raise.

1 Like
26

Here’s an idea that might solve all the attack and difficulty problems:

Do not let difficulty decrease.

If the marketplace has decided the coin is not worth generating more, the supply should stop increasing until supply and demand have balanced.

If computing and algorithmic power will only increase, there is no reason to allow a long term decrease. I do not know what the short-term consequences are, but timely transactions are not important to those who want to hold the coin for value. Zcash is already working on a fast off-chain solution.

Faked long timestamps become pointless and fake short timestamps would force difficulty to rise. Someone might want to pay to harm the coin issuance rate, so a limit on how short the timestamp can be is needed. This would limit how fast the difficulty rises. I think a simple window average of 100 is long enough to be accurate, and short enough to not let a 10x hit and run get away with too many blocks before the difficulty was too high. A 10x hit would issue make all the timestamps = 2.5 minutes more (since > 2.5 min would be reset to 2.5 minute anyway to prevent difficulty decrease), but if he’s going at 10x, then he gets 10x the coin issuance rate by marking all of them 2.5 min when he gets one every 15 seconds without making the difficulty rise. I don’t understand why that is not done now. 10% of the time he would be beat by the network which should somehow be used to stop the cheating by raising the difficulty.

27

If the difficulty can never be reduced, subjective time is replaced by a value-determination system: Miners vote on how HIGH they want the difficulty to be via the timestamps they assign to the blocks they find. The timestamp would no longer have anything to do with time. It would be a vote via the average of the past 100 blocks received as to how expensive miners want to make it for future miners to get the blocks. It’s their decision as a group to decide the minimum COST to get new blocks. It would be the marketplace’s decision to decide how MANY coins it needs based on how much it is willing to pay.

When difficulty of a coin can never decrease:

The marketplace decides the MAXIMUM value of the coins.

The miners decide the MINIMUM cost of new coins.

Miners want to get coins cheaply, but the marketplace wants high-value coins. They are opposing forces who are forced work together to reach an agreement by only being able to vote for what the other side wants. They can’t vote for their self-interest, they can only vote for the interest of the person who can only vote for their interests.

Speculators wanting cheap coins to sell later are not the marketplace. The marketplace is people who need high value coins to buy other things, or to store value.

If demand falls below supply, then it is a measure of how defunct the coin has become. Creating new coins under those circumstances does not help anything.

Isn’t this an ideal solution to defining coin value and keeping it stable?

A side effect is that you do not need to set a limit on the coins produced or a timetable. It is an arbitrary guess and decision that needs to be removed. The competing forces of the marketplace and miners should be doing that.

So cryptocurrency programming should not need to deciding the difficulty, the time, the number of coins, or the timetable. The only thing they need to do is require that miners can only increase the difficulty.

28

If the difficulty doesn’t decrease but overall network mining power does, won’t that cause slower block times? Wouldn’t that open the network to a novel denial of service type attack?

29

Yes, slower block times. I do not know about the relevance to DoS attacks or to most other things, but it does solve all the attacks and unfair mining I am aware of. It solves some things I have never liked about cryptocurrencies, mainly the arbitrary nature of assigning coin quantity and issuance schedule, and above all the “value” that has never been more than speculation. I also like that I was at a loss as to what to do about the difficulty variations, and then the timestamp problem seemed impossible to solve as well. It’s the only solution I have for either and it seems to solve both, in the simplest way. It brings votes directly into the value of the coins. It is the result of trying to protect against attacks and attacks are supposed to make things stronger.

If a coin can’t survive on transaction fees now, why should people believe it can survive on transaction fees when the mining greatly slows? If it does not survive on transactions fees at the end, then in hindsight it would be fair for the last holders to call it a Ponzi scheme.

30

Unless there’s some correlation of difficulty and transaction volume, difficulty should decrease when overall mining power decreases to avoid an impact on transaction capacity and confirmation time.

Furthermore, the few volatile years that it takes for the typical coin supply to stabilise during the initial period of inflation pales into insignificance against the much longer periods of commerce that a trustworthy currency can support.

31

Hit-and-run attacks prefer down turns and cause up turns. The upturns result in another down turn as the coin tries to remain on schedule. As a result, I would not be surprised if an “up only” difficulty resulted in more stable confirmation times. It certainly can’t have up and down swings of any sort.

Zcash has said they are not fundamentally opposed to longer block times, maybe even 10 minutes like bitcoin, so it might easily survive a difficulty that somehow got 4x higher that the normal hashrate, effectively making it a 10-minute coin on a longer release schedule, until the market says the coin is worth enough to pay for better mining equipment.

People needing confirmations should want to support honest constantly-on miners. This means they should not force them to suffer low-difficulty problems and be willing to pay transaction fees. Confirmations also need a stable difficulty.

If they can’t pay confirmation fees, it’s a Ponzi Scheme as the mining comes to an end. Granted, an older coin should be more stable, if it is being used, and support fees. But that assumes it has reached stable value by the time the mining has run out. Not being able to mine due to a too-high difficulty is the result of a coin losing value. So mining stops, and blocks are held in reserve for the future if the coin is not gaining in value fast enough, so that when all-fees time arrives, everything is ready. Being able to survive on fees from time-to-time along the way in a way that gives the coin time to increase in value is the perfect way to ensure a smooth transition that comes at the right time.

They might use a timestamp from peers. This would not negate the importance of a difficulty that does not drop because as I have explained to them on github, even if this problem is fixed, they’re averaging method is going to allow at least 15 blocks every hour or two to be stolen in 10 minutes, especially since they did not drop the 8% limit on raising the difficulty which is like ringing the dinner bell for a cheater. Wait till beta comes out. We needed beta to test a difficulty that never falls. It only needs some rule to limit the increase.

Why would people be against a coin that is guaranteed to slow down in how fast it issues coins, if the market is not yet placing enough value on the coins?

They discussed time warp attacks on this difficulty algorithm here:

32

Are you failing to distinguish between miner activity and user activity?

33

You’ll have to quote me and maybe describe what you mean better.

34

What about varying reward with difficulty in addition to / instead of Slow Start?

35

You talk about the value of a network only in terms of how it’s supported by miners. But it’s the users that determine the merit of a network - why should they suffer for the mining shenanigans going on in the background?

36

I really can’t think of a way (yet) to make “up only” difficulty work, but I think varying the reward along with access to a real time would work. For example, if a solution is 20x faster than the median solve time, the miner gets only the percentage by which he was probably operating at the average hash rate, which I believe would be about 1/20th. This would pay miners to stay close to the historical average.

It is unlikely Zcash would do anything as Avant-Gard as “up-only” difficulty, and varying reward is just as drastic.

37

The users (transactions) should not suffer. By supporting “up only” difficulty they would be supporting a stable network hashrate. Granted an hour delay for the 100 blocks would not be good, so there is a limit to what they should have to go through. They only need to pay the necessary fees as they will when mining runs out. As transactions place more and more of a burden on the network, I really think transaction fees should be at the core of coins, not mining. Mining is just a viral trick meant to give coins hash power and popularity before there are enough fees to keep them self-sustained.

38

Up-only difficulty would allow the network to be stranded at a too-high difficulty level by anyone that added sufficient resources with either the express or unintended intention of removing them. This would leave the network with slow block times which, if they’re slow enough, would act like a denial of service - particularly during times of high demand.

btw Mining is more than a ‘viral trick’ - it solves the problem of issuance.

39

Fees when mining runs out have to prevent the double spending problem. Right, if a pool comes in at 20x for a day and then leaves, the network is stuck at 50-minute solves plus or minus 50 minutes or more, until enough mining comes in. For a new coin wanting everyone to share in it, that is not as big a problem as the 20x pool coming in 20 times a day indefinitely and getting away with 10% of all coins each day in only 2% of the time, sending the coin way ahead of its coin-release schedule.

40

Note that the bounds on difficulty adjustment were doubled in beta 1 – to 32% down, 16% up on each block.

Attacks that depend on having multiples of the hash power of the rest of the network are unlikely to be feasible on mainnet. Also, this attack appears to have been benefiting from the testnet-specific minimum difficulty behaviour, when the difference between block times exceeds double the target (i.e. 5 minutes), which has been removed in beta 1. On the other hand, I don’t think the problem has been solved completely because we’re still getting more-frequent than expected block issuance.