It is possible that this is part of the reason some miners are blocking SegWit but there is more to it. Core (the main Bitcoin development team) promised to provide a block size scaling solution and then reneged. This pissed a lot of people off and led to the blocking of SegWit. I don't see ASCIBOOST as a real problem for Bitcoin.
It often incentivizes miners to reorder or drop transactions until they hash to a specific value. (A certain mining pool is publishing a significant number of empty blocks.) Miners exist to verify transactions, and Bitcoin was designed with transaction fees in order to incentivize miners to include transactions. A competing force pushing miners away from including transactions that can be trivially fixed is just a bug.
Imagine a mining "optimization" which involved miners making only empty blocks. That goes against why Bitcoin has mining in the first place, and would delay transactions eventually to a halt as more took advantage of the optimization. A trick that only often encourages miners to make empty blocks isn't categorically different, and it's something suboptimal about Bitcoin that can be fixed.
Without protocol upgrades that include commitments to other parts of the block (E.g. committed utxo, committed bloom filters, stxo, segwit, fraud proofs, etc) you can simply compute 4096 variations of left- side of the tree by altering the coinbase transaction and 4096 versions of the right side of the tree by just substituting any transaction on the right side with alternatives. Then combine the two in to the ~2^24-ish needed for a collision with only a single operation per try which is independent of the size of the block.
The lack of a commitment gets you another effective sqrt speedup and makes all the other costs negligible.
Now, as far as permutation goes, if you want to permute instead of replace you need only permute 7 transaction on the right side to get the variations you need. Virtually no blocks with more than a dozen transactions don't have at least 7 on the right side with no dependencies at all.
This is still a non-issue as a solid GPU farm can crunch the SegWit version trivially and there are ASICBOOST compatible optimizations for SegWit that have not been publicly discussed.
One should look at the R&D on ZCash's equihash to see some of the work that has gone into collision finding.
Transaction fees are going up and the block reward is dropping so long term this won't be a problem. Miners mining empty blocks will not make money any more.
And it's not true that a "significant" number of blocks are empty. Only ~2% of them are.
Furthermore the reason some blocks are empty is not due to Asicboost. It's because after a new block is found, there is a small delay until a miner can assemble the new set of txs, and during this period of time the hardware has to mine on something (empty block).
Above all, it would be in an Asicboost miner's interest to include as many tx as possible in order to gain a ~10% increase in revenues from tx fees!
So, no, I disagree that Asicboost is a "problem". It's not. It looks like Gregory Maxwell either misunderstands/misanalyzed the "risks" or is simply dramatizing the situation for his own personal (political) reasons which would be part of his plan (Blockstream's plan?) to attack and discredit large-scale miners in the overall debate of Segwit vs. Bitcoin Unlimited.
Asicboost could hypothetically become a problem only if (a) mining profit margins became very thin caused for example by a multi years period of BTC losing value or remaining flat, (b) if somehow the 3 Asicboost patents (Bitmain's, KnC's, Hanke's) were never licensed to anyone else, (c) if the patents owners actually did evil things by abusing their patent rights, and (d) while all this chaos is happening everyone else sits on their hands instead of ignoring the patent and adding the optimization to their ASICs for the benefit of Bitcoin's health or survival if it came to that...
It's very unlikely that (a) (b) (c) (d) all occur at the same time.
4 patents (applications) from 4 different holders! This provides enough competing interests that it is even less likely that asicboost will ever turn out to be a "problem".
This is not true at all and highly deceptive. They originally were supportive of doubling the transaction count via an increase to 2MB blocks and then realized they could accomplish this without a hard fork via SegWit.
SegWit does in fact allow for 1.7x the number of single-signature transactions per block and 4x for multi-signature transactions.
Core absolutely could have handled the communications around this better. But to say they reneged on providing a scaling solution is wrong.
It's also important to keep in mind that what matters is not the block size but the number of transactions that can fit into a block. Block size doubling and cutting transaction sizes in half each double the throughput.
Regardless of your position in the debate, to say that many well-known Core developers reneged is absolutely defensible, given than they signed this: https://medium.com/@bitcoinroundtable/bitcoin-roundtable-con...
The agreement between all these parties was that they'd all support a SegWit soft-fork if Core developers also provided code and support for a ~2mb hard fork.
You can only cut transaction sizes in half once, but you can always double the block size again. Let's just double the block size?
Regardless, Core signed an agreement with a majority of miners that they would implement a block size increase, not an effective block size increase but a real one. They reneged on this promise and are instead telling everyone that they are going to do as they please because miners don't control BitCoin.
If we have two competing successors (S_1 and S_2) to a Block B, an ASICBOOST miner can mine both simultaneously by creating Chunk 1's with different parent blocks.
I call it "The Oliver Twist Attack".
Increasing the Oprhan rate is incredibly costly to affected miners, this has the effect of making it also increase the hash rate of the attacker.
Also, their 20% figure is unclear. The more collisions you can find, the more hash per second you should be able to gain.
But the chance of finding three blocks with the necessary 4 byte collision is much more difficult. It's the same problem as finding 3 people with the same birthday. You need 87 people to have a 50/50 chance of three people having the same birthday vs. 23 for two people who share a birthday. That's nearly a 4x increase in required computation for a small increase in effective hash rate.