Re: [bitcoin-dev] A Small Modification to Segwit

[Pavel Moravec <pavel.moravec@braiins.cz>]

Jimmy,

>> Until all miners update (firmware or hardware), the change encourages
>> large difference in mining efficiency. And IMO it gives another
>> advantage to large mining operations in general.
>
> Certainly, there would have to be changes for stratum, pool software, etc.
> But the monetary incentives align to all the changes needed.

I agree. I only wanted to make clear, that the impact would be
significant. Lot of parties would be involved with nonequivalent
starting positions.

> Remember, overt ASICBoost can get something like a 12.5% efficiency boost
> from toggling a single bit in the version (equivalent to 2 colliding work
> items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4% from
> 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf). In lieu
> of an explicit allowance of overt ASICBoost, the monetary incentives lead to
> odd BIP9 signaling, especially if 4 or more proposals signal at once. There
> really isn't a practical way to block overt ASICBoost without forcing the
> version bits to be some value.

You can e.g. place the version number into a coinbase, similarly to
block height. Then, it is the same (number of operations) as modifying
the coinbase directly.

A cost of version in coinbase is 4B per block, sure, but it allows to
save all bits for "more useful" purposes. Either for BIP9 signalling
or other future purposes I cannot see now. And it removes an incentive
to mess with version bits.

Mining empty blocks and finding collisions by toggling bits there can
be prevented as well.

> In other words, the question isn't about allowing/disallowing ASICBoost at
> this point. The question is whether we want ASICBoost open or hidden.

I think the ASICBoost can and should be prevented completely.


Pavel