Strange miner reward patterns - Attack?

Mining
#1

zchain.png1209×777 127 KB

from https://explorer.zcha.in/ Not the first strange set of rewards I’ve noticed. First see 8261 at 21:48:04, then 6 seconds later 8262 at 21:48:10, then the next block 8263 was solved somehow 8 minutes earlier at 21:40:14, then the next block 34 seconds after block 8262 at 21:48:44. This in the midst of the Sol/s bouncing around by millions of sol/s.

Is Zcash successfully being attacked? Or is this some normal quirk? Maybe related: https://github.com/zcash/zcash/issues/998 https://github.com/zcash/zcash/issues/1015

#2

Block timestamps (displayed on that screen) are set by miners - they aren't necessarily comparable. More likely several pools / miners have out-of-sync system clocks.

At some point later this week I'm planning to set up several geographically distributed nodes to record when blocks are received where to provide a better reference for comparison.

1 Like
#3

How much of the network is attempting to game the difficulty level with this timestamp bs? What if, say, 10% of the network started rejecting blocks on the basis of dodgy timestamps? Would the small risk of losing a block be enough to reform this behaviour?

#4

Quite possibly that activity looks like some kind of timewarp attack relaed to bugs in Zcash as discribe in the issue... well spotted :smile:

#5

#6

The time warp attack is only possible if a miner has more than 25% of the S/s. Only 1 miner has about 10% (see suprnova, 1 M S/s for anon who has donated 2% of his 3800 ZEC to the pool (? the pool seems to say the donation was 75 ZEC). There have been only about 10 timestamps more than -2000 seconds. I think the max is 3600, which was a carry-over from bitcoin that they should have changed to 3600/4 = 900 seconds. I don't know what happens to the block when the miner is more than an hour off. I don't know how daylight saving's time affects things as only part of the world observes it. About 4% of the timestamps are clearly wrong. I tmied blocks coming into my node, avoiding the need to look a the timestamps and it is following a Poisson distribution (unlke testnet which had 2 things preventing this) so everything seems fine.

1 Like
#7

It’s almost less that there’s a old stamp in there and more that the same tight configuration of rushed miner rewards fall around it in such a similar configuration so often, and I’m not even looking for it. I just notice it in the most recent transactions when I check zchain to see what the difficulty is.

4 rewards in 60ish seconds, one well out of time sync. I gather the rewards wouldn’t roll out like clockwork regardless of timestamp, but how likely is this particular pattern to keep repeating so often that I keep spotting it off-handedly at the top of recent tx?

I know this could just be noise, but I may keep posting it from time to time in hopes of inspiring someone smarter and more heavily vested in Zcash to take a closer look, because it sure smells like a signal. A smart attacker may well avoid abusing the attack to avoid detection, but if I’ve spotted it this many times without looking, what would a smart search for that pattern unveil?

Edit: just switched over to close zchain, and noticed hashrate down below 10million sol/s, right before I took that screenshot, there was 20+million sol/s. Assuming that’s measuring accurately, it would appear all this is happening around massive bounces in hashrate as well. Something else that smells to me.

#8

Maybe not miner but the pool doing attack

#9

To do make the attack profitable, It would need to be someone who is having to pay for hash time. They need to want to do surges of hash power. They can't get more than if they simply left the miners on all the time, but their cost per hash (electricity or renting) goes down. Miners would leave the pool from not making as much coin as they expect.

Otherwise, they might be able to lower the difficulty artificially, but there are the right number of blocks per day, so that's not happening.

@CCQ 4 blocks in a row that are less than 3 minutes apart should happen several times a day, even if clocks were right. With clocks wrong as often as they are, my guess is that it's occurring 10 times a day. All the wrong clocks are making the difficulty swing more wildly than it needs to. For constant-on mining, it all works out, unless someone is renting hash power and taking advantage of the swings that honest miners are accidentally throwing into the network.

I think one big thing that is catching your eye is that the miner of block 11118 is a big miner and is always about 20 minutes behind on his clock.

It would help stabilize the difficulty and prevent certain non-pool actors from potentially taking away blocks if pools submit the right time.

#10

You might be able to find out who that big miner is (if he's a pool) and ask him to correct his clock.