Block 3536 was found in 1 second. How does that work? Does that mean they also found block 3535?
Starting at block 6995, someone found 19 blocks in 4 seconds. And block
7004 through 7030 were found BEFORE block 7003. Is this not a problem?
How can we view IP addresses of miners?
@zawy First question, first: how you put that nice paste in with courier text and grey background?! 
It’s the preformatted text option next next to the quotes in the reply box.
Cool! Thanks
At first sight, it seems like a problem, but a problem that fundamental is unlikely. Thing to do is plot a distribution of the blocktimes. Should be a poisson distribution with mean 150 seconds, if I understand correctly. Not sure what the probability of 1 second is, but certainly the chances of finding 19 blocks in < 1 second each must be near zero!
So either there is a problem, or we’re interpreting the output wrong. For example, what do the negative times mean, and why are there repetitions of blocks? I suspect there is more than meets the eye. Can you post the specific blocks you are talking about, because 3536 wasn’t in your original dump.
The negative times are when blocks are being rejected. Those are just something in my debug file that I think are is expected behavior. I do not think 19 blocks in 7 seconds is possible, many of them in the same second. That would be like 1000x the current network hashrate.
My understanding is that timestamps are be chosen by the miner, and I believe consensus accepts them as long as they are within some range. So the timestamps themselves are not inherently trustworthy. Thus, it is unlikely that any miner found 19 blocks in 4 seconds, but that a miner is altering timestamps for some reason (testing an attack?).
If you are seeing this in your debug.log, are you looking at the times your zcashd receives the block? It could be possible that your connection to the network went out, and when it reconnected you received all the blocks simultaneously.
It’s in the block explorer. It started around 6700. It’s on-going. Many blocks occur 1 hour AFTER the next 17 or so blocks are found in a few seconds, so it looks like a time warp attack. Str4d had mentioned something about miners on testnet were being allowed to mess with timestamps, so hopefully this is not a surprise nor how things will be in beta. The block explorer does not show when the blocks were actually solved, but I have a log file that shows when they came in to my computer.
They’re making it issue blocks nearly 50% faster than the desired schedule, 1800 blocks in 2 days. 800 blocks in the past 24 hours on the block explorer.
Today I haven’t found a single block, while I found 5 in roughly the same timeframe yesterday. Diff is on-average the same.
Something is very wrong.
If you look at the block explorer you see that a large portion of those blocks are accepted next to each other with difficulty of 1.0: block 6713,6711,6707,6704,6702. Since this is testnet, it is allowed to mine blocks with difficulty of 1 when there is no block found after the blocktime limit. The interesting part is that the timestamp of those blocks are apart by ~1 hour since the one mining the difficulty 1.0 blocks is having an out of sync clock, perhaps a small bug on the network. On the mainnet, this is not allowed and I guess we will not see that behavior.
@zawy: What are the largest difficulty spikes you are seeing (if you are looking)?
The largest I have seen the past few days was ~518 and ~720, but it ranges between 260-380 with a few 1s.
Here is the difficulty a day before and a day after it started. I’ve been working for a month trying to come up with a good difficulty algorithm. I thought I had one because it did well on the testnet, but str4d showed me it falls apart with a poisson process. Testnet is not a poisson process because the reset D=1 after 5 minutes and because CPU solver times have a hard minimum at ~ 15 seconds. Both these will change in the future, making it a poisson process. I’m currently testing other ideas, starting with a poisson process generator. I am afraid their current plan is going to allow 15-block thefts in 10 minutes every 1 to 2 hours with 5 to 10x hash rate. Ironically, I think competing thieves is limiting the problem once coins are established.
In this post I gave the code to log difficulty. It records things as
the info comes in if you keep it running all the time, so it can be used to diagnose trickery in the blockchain.
https://forum.zcashcommunity.com/t/somebody-already-has-a-gpu-rig/1410/13
7608 Sep 7, 2016 8:22:12 PM
7607 Sep 7, 2016 8:16:54 PM
7606 Sep 7, 2016 8:18:30 PM
Strange stuff right here
@trolloniex : Zcash inherits it’s block timing code from Bitcoin. According to the Bitcoin Wiki,
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. As a result, block timestamps are not exactly accurate, and they do not even need to be in order. Block times are accurate only to within an hour or two.
So it is entirely possible to have blocks have the timestamps you’ve pasted, and it may mean nothing more than the fact that some miners are sloppy with their clocks.
But it’s strongly affecting the difficulty setting and issuing too many blocks per day. And 19 blocks in a few seconds seems like a single miner messing with his clock on purpose. [edit: I guess you’re just referring to his particular timestamps ]
By setting a block timestamp ahead 1 hour, and then keeping the next timestamps low by mining faster than others, he is tricking the difficulty algorithm into thinking block issuance is not too fast which keeps difficulty low. He can mine 16 blocks and the algorithm will think it has not yet issued enough coins for the hour, and it will even keep bringing the difficulty down. It’s only useful if you can mine as fast as or a good bit faster than the network. The difficulty algorithm is apparently subtracting the median timestamp from the newest timestamp (the oldest block number which he mined first). He has determined both and thereby controls the difficulty and block issuance. At the 17th block, the old block with the newest time is out of the averaging window and suddenly the algorithm sees a lot of blocks were issued in a short time, and the difficulty starts rising. But he leaves it alone until others have a few blocks and so that the difficulty will reach its peak then start coming down again, and he can start over. He can do it 11 times a day x 17 which is pretty close to the 200 excess blocks per day it is issuing. Lowering difficulty for a while is a side effect, not exactly the purpose. The purpose is to spend only a little money on server time for a few minutes without the difficulty algorithm knowing it is issuing too many blocks. He can then stop and let others get blocks and they won’t notice a big difference. This assumes the algorithm uses the most recent timestamp out of all the blocks as a type of “current time” to subtract from instead of using the highest-numbered block’s timestamp. But switching to that may cause another problem. A fix would be [edit: wrong, see edit below] to make sure block times are always increasing, leaving the miner’s the responsibility of keeping a universal time so they do not lose blocks. Then maybe they could make the difficulty algorithm substantially more accurate by using mean instead of median.
[edit]
You can’t simply force newest blocks to have a higher timestamp because everyone would be forced to make it issue blocks faster than real time: the cheater would add a lot of time to a block in the hopes others would not notice and then only his future blocks with a high timestamp would be valid. And so everyone would see the trick and keep adding time to stay ahead so their blocks are accepted. But this would lower the difficulty if they push it ahead too far, causing all blocks to be issued in a few days. A limit on advancing the time can be used (and already is), but as the difficulty lowers from people constantly pushing it there, they’ll be able to push it there faster.
Given that the timestamp is so unreliable, what is the point of having it in block headers?
As an estimate of how long it took to solve the block so that difficulty can be adjusted to keep block issuance on track with real-world time. I don’t see any solution to this which is why he is so brazen. The only solution is to not have any big concentrated mining. It seems to me we could collude to manipulate our timestamps to trick a coin into issuing all it’s coins quickly. But if there is no collusion to share the rewards, then other miners trying this trick will block each other from enabling it to work.
A solution might be for people like Austin Williams to show people how to do it. With cheaters competing to turn on their EC2 servers when the conditions warrant, they lose the ability to get enough blocks to justify their EC2 expenses, so the market dries up, except for the most efficient operators. But it would still cause the coins to be issued too fast.