rich1.0npub1a9hemj8hf6exprh5q6w8y70n9mm36h6pt5vlp2wtl9gjwfzaqjrqeuvwuqhttps://nostr.ae/npub1a9hemj8hf6exprh5q6w8y70n9mm36h6pt5vlp2wtl9gjwfzaqjrqeuvwuqnjumphttps://nostr.ae📅 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