Pavel Moravec [ARCHIVE] on Nostr: 📅 Original date posted:2017-04-08 📝 Original message:Jimmy, >> Until all miners ...
📅 Original date posted:2017-04-08
📝 Original message: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
📝 Original message: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