Someone pointed me to that post with an explanation of why the other thread was locked. Is this true? It is disturbing to say the least...

Was just to remain covert - any big timestamp diffs would be obvious.

Btw, the way valiron handled the first few people who trolled him in this thread is probably indicative of the way I should handle monsterer, but what was more shocking is how gmaxwell and his gang railroaded valiron and even apparently deleted Come-from-Beyond's post wherein CfB had linked to this white paper just today:

http://rakeshk.crhc.illinois.edu/dac_16_cam.pdf

What is incredible is to see gmaxwel (and the other huge egos over there in Bitcoin Technical Discussion) have his arrogant, totalitarian ass (their arses) handed to him (them) by valiron (who is apparently a PhD level researcher) and so what does Gmaxwell do? Today when CfB posts, he locks the thread and does his usual Hitler tactics.

Fucking amazing.

I will do my damn best to make the Bitcoin killer and dethrone Blockstream. I hope you all have noticed that Blockstream's Segregated Witness proposal is a Trojan Horse takeover of Bitcoin.

Now that is a load of bullshit. You mean to say that moderators are not allowed to participate in discussion in which they are interested and have expertise in? Moderators are participants in this forum too, and were posters before they became moderators. I am posting as myself, not as a moderator, nor am I posting on behalf of the forum.

Reverse engineering has found that the mining chips used in Bitmain's Antminer S9's and R4's (and perhaps more, I don't know off of the top of my head) contain the circuitry necessary for asicboost to work. It was also found that antpool and the publicly available firmware for the antminers contains the codepaths and api calls necessary for overt asicboost to work, and in fact people have managed to get their miners to use overt asicboost. See https://www.reddit.com/r/Bitcoin/comments/63yo27/some_circumstantial_evidence_supporting_the_claim/dfy5o65/

The recent events he is referring to is the fact that it was recently discovered that Bitmain has implemented and possibly used the covert version of asicboost in their own mining operations.

No, I can't. I was not a moderator at that time. It was probably locked because the topic was beaten to death.

No, Asicboost does not make mining hardware run faster and somehow generate blocks faster. Your original question, assumption, and theory is still invalid; those "fast" blocks are due to variance in block finding. Asicboost does not make miners make blocks faster, just more efficient so they end up consuming less electricity and thus have fewer costs.

I withdrew any claim. So, stop repeating the same thing over and over. Already Mr gmaxwell rated me as a scammer (at the same level as other people having stolen bitcoins to others) and has tried to bullshit my expertise, which I think at this point says more about him than about me.

But I do believe and I will repeat that some unusual patterns do deserve attention, in particular when the numbers show that these events are extremely rare.

Without being paranoic it is conceivable that some people found a boost on the mining performance (it wouldn't be the first time this happens), and they try to hide it for their own interest.

I fully agree that this possibility has to be treated with caution, but it cannot be ignored and we should be on the look up. If this appears to be the case at the end, some people in this forum will have collaborated concealing this fact. They will bear that responsibility.

On my side I would restrict my comments to statistical facts.

It is unclear to me what you are talking about. What specifically are you referring to by "blocktime validation"?  Are you talking about the ntime gaps?  Blocks of very slow miners should have lower timestamps because they do not frequently update their midstate (e.g. they would claim older times because that was when they started); modern fast miners blow through the range quickly, and thus have plenty of opportunities to increment their time. (Much of the single tx blocks back then were believed to be a botnet that verified nothing).

If you are saying smaller blocks take less time to validate largely. This is mostly untrue at the tip of the chain.  Leave your node running for 24-48 hours and then look at the block verification times. You'll see that the actual blocks, in spite of being huge, typically verify in a few milliseconds (-benchmark will enable ms resolution timing results in the logs). This is because almost all the verification is cached from the transactions being relayed earlier.

I believe one thing valiron is talking about is the practice (which I recall reading about, I've no idea if it's still in use, or ever has been) of pool operators sending out work for empty blocks to their miners immediately after a new block is found, to get the miners working on the new chain ASAP, and then creating a non-empty block & merkle tree at their leisure and updating miners once it's ready.

There is plenty of technical information put together in this long thread (given by gmaxwell explicitly, and DannyHamilton's analysis on which parts of the block header can be used as nonce, and my very old posts about modifications to the Bitcoin header) to ease you discover one of such tricks. Take some time to think about it, take aside all posts with personal insults, and you'll probably find the solution right in front of your eyes.

I think gmaxwell is right, there is not enough evidence in those 4 blocks to suggest that there has been a breakthrough in mining ASICs.

On the other hand I guess valiron is also right, he knows (and probably can't disclose) that some mining companies may be testing new tricks to improve their ASIC hashing power. Maybe he hacked into one company computer or he was told by a friend who works in one of them and he promised not to say anything.

Mining companies want to maximize their profits and they are not obligated to disclose their engineering achievements. Those are trade secrets and nobody has ever complained about ASIC Mining companies having close designs. I don't even think that the Bitcoin community can even enforce ASIC companies to open their designs, because they are already using other companies IPs that they can't disclose, and because they can always go anonymous to avoid disclosing anything.

There is plenty of technical information put together in this long thread (given by gmaxwell explicitly, and DannyHamilton's analysis on which parts of the block header can be used as nonce, and my very old posts about modifications to the Bitcoin header) to ease you discover one of such tricks. Take some time to think about it, take aside all posts with personal insults, and you'll probably find the solution right in front of your eyes.

I'm not that clever so there may be more tricks to discover.

However, a trick can only give you a certain speedup, say 20%, based on a reorganization of the SHA256D operations, or the pre-computation of some operations that change less often. Other changes (such as reducing the fabrication node) can give you much higher speedups. So this isn't alarming.

A completely different thing is to find a way to invert SHA256D, which I'm absolutely sure nobody will ever be able to do without some revolutionary quantum computer that does not exists even in theory.

The only attack I was thinking of when I wrote the Bitcoin header post, was all mining companies adopting tricks that give them some little advantage, but at the same time they degrade the performance of the network as a by-product. One of such attacks is cited when I posted about using approximate adders, and the danger that a monoculture of approximate ASICs can get stuck in a header that always generates a faulty addition.
 
If such problem ever arises, the community will probably find the way out by doing the right hard fork to prevent it.

IMHO the cryptographic security of SHA256D function of Bitcoin will never be seriously compromised.
However if there were a single mining company manufacturing ASICs being 200% faster than the competition, that would clearly hurt Bitcoin in a practical econo-socio-political way. The good news is that the accumulation of tricks probably will never reach such an improvement.

Best regards,
 Sergio.
 

There aren't very many other fields to change.  That's why the block has a nonce in the first place.  There's nothing special or magical about changing the nonce, it's just 4 bytes added to the header specifically for the purpose of being very fast and easy to change.

The other fields of the block header are:

• The block version number. This 4 byte field cannot be changed without invalidating the block you are mining.
• The hash of the previous block in the chain. This 32 byte field cannot be changed without invalidating the block you are mining.
• The merkle root of the transaction list. This 32 byte field cannot be changed without modifying or rearranging the transactions in your transaction list.  This would be a MUCH slower and more complicated thing to change than the nonce. However, a pool will create MANY different merkle roots (by modifying the extranonce in the coinbase transaction) so that they can give a different block header to each miner.  This allows each individual miner to only need to deal with the nonce (and timestamp) and not need to recompute the entire merkle root.  It is also possible for the pool to provide enough information for individual miners to modify the extranonce themselves along with the nonce.  Keep in mind though that modfying the extranonce increases the time and effort involved, so it makes more sense to exhaust the nonce range available to the equipment before making any effort to move on to a new extranonce.
• The timestamp.  This is a 4 byte field that some miners change after they've run out of nonces.  It essentially becomes a secondary nonce. However, it is very limited on allowable ranges.  Since the miner would need to test to make sure a value is within the allowable range before hashing the block, it very slightly increases the effort as compared to simply using the usual nonce.  If someone chooses to modify this instead of the nonce (or while keeping the nonce in a tight range), then this field BECOMES a nonce.  There is no benefit of manipulating these 4 bytes instead of the other 4 bytes.
• The current difficulty (represented as "bits"). This 4 byte field cannot be changed without invalidating the block you are mining.
• The nonce. This 4 byte field exists solely so that is is fast and easy to modify the header before hashing it again.  It serves no other purpose, and has no restrictions on its value.  This is also the field that you are saying NOT to change when "you change other fields".

That's 4 bytes + 32 bytes + 32 bytes + 4 bytes + 4 bytes + 4 bytes = 80 bytes.

That's it.  There's the 80 bytes that are hashed during mining.  I'm very curious to know which of those fields you think might be better to change instead of the nonce?

Those in red cannot be changed without invalidating the block.  Those in green are already manipulated as part of the typical mining process, and the typical mining process already manipulates them in the most efficient order.  If there is a benefit to manipulating the timestamp or merkle root INSTEAD of the nonce, I'd be very curious to know what you think that benefit might be.

I'm not certain, but I don't think you can adjust the merkle root without needing to recompute the midstate as well?

But you DO fabricate the block hash from the Block Header, which includes the other data in addition to the nonce. It is this hash, not a hash of the nonce itself that has to beat the Target. I am not sure if you understand how hashing works to suggest that with entirely different block header data a similar nonce could be exploiting the end hash.

Is it just me, or is it silly to consider the nonce without considering the rest of the data in the block header?

Edit: Perhaps OP could provide detail on the merkleroot and transactions of the blocks in question.... I mean, if they were empty blocks it would indeed be suspect, but to produce a valid nonce and still manage to include a solid transaction set from the pool, come on now....

Couple of years ago when I said BFL are crooks and low life 10 people I respected (incl. mods) told me I was wrong. They were just bribed by BFL to do so. At that time mods were not in a hurry to label BFL as scammers.

If we brush off all the pseudo scientific gibberish what gmaxell is basically saying we should treat all the irregularities as regular because of the big figures. Do we have to accept this knowledgeable explanation and move on just for the sake of protecting bitcoin from possible FUD?

I mean no disrespect. I only hope that you can be this type of enlightened individual.