Not when someone with tunnel vision keep accusing Jihan of stop supporting SegWit once he realized he can't use ASICBoost on it.

The SegWit agreement was already derailed by Greg's 'dipshits' comment right after the agreement was signed, it was later furter derailed by Greg+gang changing the story to 'SegWit was the blocksize increase'.

The key here is Jihan was not the only miner who was pissed at Blockstream/Core and switched to BU. Pinning the entire mass exodus from Core on ASICBoost is just another distraction from the real issue: The 1M blocksize limit.


Irrelevant word play, when you resort to nitpick on a micro level, you should know the HK Agreement wasn't even a legally binding contract, but an acknowledgement of consensus between miners and Blockstream/Core.

Adam Back represented Blockstream when he signed the HK Agreement (he used a bait and switch at the last minute, but f2pool corrected him afterwards), Greg was part of Blockstream and Core, so everyone in Blockstream is in the same party that signed the agreement.

Greg actively and vocally went against the HK agreement right after it was signed, Greg's bullshit continued to this day. Greg wasn't the only one from Blockstream/Core working against the agreement, but he was the most vocal, that's why he's now called "One Meg Greg", miners switched to BU once it was clear that Blockstream/Core wasn't going to keep their promises and offer 2MB non witness blocks as promised.

This Blockstream circus has been going on for over a year, you have to be intentionally dishonest or grossly uninformed to claim Greg didn't break the HK Agreement.


I knew you'd fall for it. Ext Block had always been immune to ASICBoost, simply because its design is base on BIP-141 (SegWit), which hash all regular and side tx into the coinbase merkle root.

And now I know you really are a paid troll, only a paid troll would act stupid all the time then suddenly become smart enough to pick up on small details and try go for a kill. But you were lazy and didn't check commit history, so you didn't notice it was just a bait.

The funny thing is this time I'll use Greg's ASICBoost inhibiting proposal and BIP-141(SegWit) to prove you wrong, using one shill against another just for kicks.

Take a look at Greg's ASICBoost inhibiting proposal on 5 Apr 2017:

Notice the bold part, the key here is "BIP-141 commitment structure".

What this means is that if your proposal uses BIP-141(SegWit)'s commitment structure, then it is immune to ASICBoost. (BIP-141 is what Extension Block is base on, that's why Extension Block is immune to ASICBoost)

As to what the 'commitment structure' is, it is described in the spec of BIP-141 (haven't changed since 2016):


So, in BIP-141, you have a new commitment hash (a new markel root) in the coinbase called the 'witness root hash', this hash is base on all the 'wtxid' in the block, 'wtxid' is all the tx in the block, including both witness and non-witness tx.

That means, in plain english, in BIP-141 (aka SegWit, which Extension Block is also base on), every time you reorder/add/remove/replace a transaction from the block (to generate a new hash), the coinbase is changed.

By placing the hash of all the tx on the left side (witness root hash inside the coinbase), everytime you change the right side (reorder tx), you also change the left side at the same time.

This renders ASICBoost useless since one of the shortcut ASCIBoost relies on, is the fact that in Bitcoin when you change the tx order (right side of the Markel Tree), the coinbase (left side) doesn't change, which makes it much cheaper to generate and filter hash collisions (which will then be used for the sha256 msg expansion short cut in the mining outer loop).

Greg further explained BIP-141's ASICBoost immunity here:


Greg is a well-known for his lying, but he is also hell-bent on destroying Jihan and it took him a year to come up with this, so I might as well use it against another shill.

Now, about Extension Block, and why your accusations and prophecies don't stand up to facts.

On 3 Apr 2017, Jinhan posted this on twitter:" I love the extension block proposal. It is compitable with BU."

This was the spec of Extension Block on 1 Apr 2017 (2 days before Jihan's tweet, 5 days before the so-called ASICBoost patch):

This establishes three facts:
1. Extension Block uses the same commitment structure as BIP-141(SegWit), which is immune to ASICBoost.
2. In Extension Block, all txid, regular block or extension block, are all included in the Merkle Root. (Changing right side of the Merkle Tree = changing the left side = high tx reorder cost = immune to ASICBoost)
3. The Extension block spec Jihan supported on 3 Apr 2017, was immune to ASICBoost.

In 4 Apr 2017, 1 day after Jihan voiced his support for Extension block, chjj, an Ext Block dev, made the following changes in the Ext Block spec:

In this commit, chjj basically tried to remove the ASICBoost immunity from Extension Block.

What he did here was changed the spec to no longer include regular txid into the coinbase merkle root, this means miners can reorder regular txid (changing right side of the tree), without changing the coinbase (left side of the tree), this allow ASICBoost to efficiently generate and filter collision hashes for the mining loop short cut.

But he did a half ass job, because the line above still read:
"The commitment serialization and discovery rules follows the same rules defined in BIP141"

Following BIP-141 means all regular/extended tx is still in the new merkle root in the coinbase, still immune to ASICBoost.  

On the surface, it may look like chjj had no idea what he was doing.
(this is also the part where you got fucked over, thinking ASICBoost actually would work on Extension Block after chjj's botched edit)

This is evidenced by the issue he created the next day, 5 Apr 2017, soon after Greg posted the ASICBoost inhibiting proposal:

chjj's edit lasted only for one day, quickly fixed after some knee jerk reaction from the devs on Greg's ASICBoost inhibiting proposal.

A more experienced dev, indutny, made the following comment the next day:

indutny was correct, Extension Block has always been immune to ASICBoost, Ext Block's commitment structure was base on BIP-141/SegWit, so add/remove/reorder/replace any regular/extension tx has the same effect as SegWit - it changes the coinbase, making ASCBoost's collision filtering short cut no longer works, hash collision generation and filter too costly.

But one thing is curious tho, chjj removed 2 lines from the Ext Block spec to make it look like Extension Block wasn't immune to ASICBoost, at the same time Greg was posing the ASICBoost inhibiting proposal.

Right after he removed that line, he created an issue to ask for help on dealing with ASICBoost, then quickly accepted a PR to 'fix' the ASICBoost issue.

Delete ASICBoost immunity > Ask for Help on ASICBoost > Accept PR to deal with ASICBoost, all within 2 days. The delete commit was also burried under a bunch of other edits, with a disguised description.

What a series of strange coincident. It's as if chjj wanted to make a big deal out of ASICBoost in the Ext Block issue/pull request while Greg was also making a big deal out of ASICBoost at the same time.


I just established, using verifiable facts, that Jihan/Bitmain/AntPool supported Extension Block, which was and still is immune to ASICBoost.


Again, still no proof that ASICBoost was ever used in production.

With all these screaming you'd expect at least a little proof, but nope, just a bunch of idiots regurgitating the same script.

The real reason Jihan even put ASICBoost on the market but not enabled it was because 'first to market' is how you win patent wars. ASICBoost was being patened by other people in other countries, obviously the next move was to put ASICBoost on market to defend the patent.

That's also why Jihan Wu made the 'ASICBoost? Do you have any basic understanding of patent law' tweet then deleted it, him or his lawyer probably realized speaking that truth wasn't going to be helpful to future patent lawsuits.

And the real current issue here is a bunch of trolls are suffering from verbal diarrhea, trying to distract people from the real issue: the blocksize increase.


All the knee jerk responses, screaming and finger pointing, foaming at the mouth baseless accusations about ASICBoost suggest otherwise.


You made the accusations, the burden of proof is on you, back up your own words instead of cry wolf nonstop then looking around like a moron waiting for someone else to clean up your mess.


The blockchain (that immutable thing you call 'faulty data') has always been out there for everyone to see.
There are no long strings of empty blocks.
There are no pattern of funny version numbers.
There are no pattern of weird tx orders.

If there is some kind of secret way to use ASICBoost that can hide this well from everyone for this long, then ASICBoost automatically become yet another optimization. But then again, there aren't any abnormal hashrate:blockrate ratio.

You made accusations with absolutely nothing but bullshit prophecies, then you complain about people showing up with facts dating back months? Normal people just can't be that silly, trolling as a job is one thing, but this is just bad acting, very unprofessional.


Again, no long strings of empty blocks.
No abnormal hashrate/blockrate ratios.

It takes time to calculate the next block template, during which miners mine empty blocks, AntPool has the highest hash rate, naturally they'll have more empty blocks than others.
 
Empty blocks existed before ASIC was even in the picture.

Try look for some abnormal patterns from the blockchain, instead of keep pulling crystal balls out of your rear.


He did say why Greg was wrong.

Why are you even arguing for Greg. Greg doesn't even understand the difference between 1MB and 2MB.


Or they should investigate why there are so many unprofessional trolls posting similar bullshit narratives non stop.

No logic, no facts, wrong every time, yet keep repeating them like their jobs depend on it.

Sometimes they don't even remember what they posted a page ago, like they're working on multiple sites at the same time, or more than one PR worker is using the account.


1. You are laughable.
2. They can, I did, and you have.
3. Cult prophet wannabe proof:
AgentofCoin: In time, all will be revealed.
AgentofCoin: within the next two months or less, someone will publish a full scientific report
AgentofCoin: Jihan will no longer support that Ext Block proposal.

In time, you'll find a better job than acting like a robot online all the time.


You do realize you just got out trolled because you asked for it by name on page 1, right? Here:


And you do realize I was just using you to explain to people Extension Block is immune to ASICBoost, right?

This whole ASICBoost bullshit is just another distraction from Core keeping the blocksize at 1M slowing everything down.

The ASICBoost write paper used a lot of tech jargon, that's why after a year over half the devs still don't know how it works.

ASICBoost is:
1. A programming short cut of using 3 sha256 operations instead of 4 when mining a block hash.

2. It is possible because sha256 processes data in 64 bytes chunks, but the header is 80 bytes long.

3. So the block header is split into 2 chunks when sha256 computes its hash.

4. The merkle root inside the block header, spans over the position that sha256 split the chunks.

5. The merkle root is 32 bytes, 28 bytes of it (head) ends up in the first chunk, 4 bytes of it (tail) ends up in the 2nd chunk.

6. The second chunk has 16 bytes of data and 48 bytes of padding.

7. Of the 16 bytes of the data in the second chunk, 4bytes is the merkle root tail, the other 12 bytes are  time/difficulty/nonce, all known values by the miner.

8. That means if a miner can generate a bunch of hash with the same last 4 bytes, then the entire 2nd chunk, all 16+48 bytes of it becomes a fixed known value.

9. This allows miners to simplify the sha256 mining loop, so that it only uses 3 sha256 operations instead of 4, and increase performance.

10. The more hash with the same last 4 bytes a miner can generate, the more times they can use the short cut, the more performance gain, this process is called 'finding partial hash collision'.

11. To generate these partial hash collisions, miners have to keep changing the data on the block then get a new hash at high speed, but different ways have different costs, only a few of them is worth while.

12. One of the fastest way to find hash collisions is to keep changing the extranonce in the coinbase, at the same time keep reordering tx in the block. This modify both side of the merkle tree parallelly and allow further math shortcuts to take place.

13. Changing the coinbase and reordering tx is computationally costly, it is only worthwhile if you can do both at the same time without affecting each other.

14. In regular Bitcoin, modifying tx changes the right side of the merkle tree, and modifying the coinbase changes the left side of the merkle tree, the coinbase on the left doesn't care what happens to the tx on the right, and vice versa. There are no double overhead modifying data on any side, so in the end you can gain a 20% advantage with ASICBoost.

15. But if the coinbase merkle root includes the hash of all the tx, then ASICBoost is no longer worth the effort, in fact it'd make mining slower, because now every time you reorder the tx, the coinbase also changes, and you have to use an extra 10 or so operations to update the left side of the merkle tree. That 20% advantage is gone.

16. This is what happens in BIP-141 SegWit, the coinbase has a new merkle root call the 'witness root hash', that includes all regular and side tx. This makes reordering tx also updates the coinbase, miners have to spend 10 extra operations for each tx reordering, this double overhead makes it too costly to use ASICBoost.

17. Extension Block is base on BIP-141, they have the same commitment structure, so Extension Block is immune to ASICBoost.

18. If anyone is using ASICBoost, the 'overt' method involves modifying block header data directly, so you'll see strange version numbers and other weird data, the 'covert' method involve reordering of tx, or empty blocks, these are also obvious.

19. If there is a new way to use ASICBoost without obvious side effects, then it's just another valid optimization on generating hash, optimization happens all the time.

20. The excuse of ASICBoost patent may lead to centralization is just silly, there are so many patent involved with mining already, from chip to connectors to cooling, everywhere you look there is a patent. This field is so competitive, every year there are a bunch of new optimizations with a new bunch of patents.

So, ASICBoost doesn't work on Extension Block, and ASICBoost was never used in production.

Stop crying about it being used and just show us the proof for all your accusations.