https://nostr.ae https://nostr.ae/npub1a9hemj8hf6exprh5q6w8y70n9mm36h6pt5vlp2wtl9gjwfzaqjrqeuvwuq https://nostr.ae/nevent1qqsv298grtv0wkks7d3wlh8tv4yrajhqs48sqypxd6sc6fa7tvz2dkgzyr5kl8wg7a8tycyw7srfcune7vh0w82lg9w3nu9fe0u4zfeyt5zgvn3sm0h In reply to <a href='/nevent1qqs9gch3vj5r45vm7ecxsyyl69zkvk3xf2mkuduqj32r0qeqzvu35wcnkh59g'>nevent1q…h59g</a><br/>_________________________<br/><br/>📅 Original date posted:2017-04-08<br/>📝 Original message:Jimmy,<br/><br/>&gt;&gt; Until all miners update (firmware or hardware), the change encourages<br/>&gt;&gt; large difference in mining efficiency. And IMO it gives another<br/>&gt;&gt; advantage to large mining operations in general.<br/>&gt;<br/>&gt; Certainly, there would have to be changes for stratum, pool software, etc.<br/>&gt; But the monetary incentives align to all the changes needed.<br/><br/>I agree. I only wanted to make clear, that the impact would be<br/>significant. Lot of parties would be involved with nonequivalent<br/>starting positions.<br/><br/>&gt; Remember, overt ASICBoost can get something like a 12.5% efficiency boost<br/>&gt; from toggling a single bit in the version (equivalent to 2 colliding work<br/>&gt; items), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4% from<br/>&gt; 4 bits (see <a href="https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf">https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf</a>). In lieu<br/>&gt; of an explicit allowance of overt ASICBoost, the monetary incentives lead to<br/>&gt; odd BIP9 signaling, especially if 4 or more proposals signal at once. There<br/>&gt; really isn&#39;t a practical way to block overt ASICBoost without forcing the<br/>&gt; version bits to be some value.<br/><br/>You can e.g. place the version number into a coinbase, similarly to<br/>block height. Then, it is the same (number of operations) as modifying<br/>the coinbase directly.<br/><br/>A cost of version in coinbase is 4B per block, sure, but it allows to<br/>save all bits for &#34;more useful&#34; purposes. Either for BIP9 signalling<br/>or other future purposes I cannot see now. And it removes an incentive<br/>to mess with version bits.<br/><br/>Mining empty blocks and finding collisions by toggling bits there can<br/>be prevented as well.<br/><br/>&gt; In other words, the question isn&#39;t about allowing/disallowing ASICBoost at<br/>&gt; this point. The question is whether we want ASICBoost open or hidden.<br/><br/>I think the ASICBoost can and should be prevented completely.<br/><br/><br/>Pavel 2023-06-07T17:59:48Z https://nostr.ae/nevent1qqs8vzucgjzyragfdv06syr4c8x465ak36dvsyulgezcnk22n0meqlczyr5kl8wg7a8tycyw7srfcune7vh0w82lg9w3nu9fe0u4zfeyt5zgv37k0c0 In reply to <a href='/nevent1qqsfzwvmqqgnv845888arsv7q4rwlwst0egnfgesehavvxhlh78hvtgyyqvhw'>nevent1q…qvhw</a><br/>_________________________<br/><br/>📅 Original date posted:2017-04-08<br/>📝 Original message:&gt; Second, we can make this change relatively quickly. Most of the Segwit testing stays valid and this change can be deployed relatively quickly.<br/><br/>It is true only for nodes software. Most of the world&#39;s mining<br/>infrastructure (at least for pool mining) is not ready for such<br/>change. Current version of Stratum protocol doesn&#39;t support block<br/>version changing. A broad adoption would require:<br/><br/>- A new standard extension to the mining protocol (generally, we want<br/>the hash rate to be free to change the used pool without efficiency<br/>loss)<br/>- Pool operators must change their software.<br/>- All miners must update their firmware IF they have compatible<br/>hardware (we know there is compatible hardware out there but<br/>definitely not all of the currently used). The firmware can be changed<br/>after the mining protocol extension is settled.<br/><br/>Until all miners update (firmware or hardware), the change encourages<br/>large difference in mining efficiency. And IMO it gives another<br/>advantage to large mining operations in general.<br/><br/>&gt; But think of it this way, if some newer ASIC optimization comes up, would you rather have a non-ASICBoosted hash rate to defend with or an ASICBoosted hash rate? Certainly, the latter, being higher will secure the Bitcoin network better against newer optimizations.<br/><br/>You make a strong assumption that the new optimization is not<br/>compatible with overt ASICBoost. If it is compatible, ASICBoost<br/>doesn&#39;t help you with &#34;defending against&#34; the new optimization at all.<br/>And it can be the case that the new optimization is based on ASICBoost<br/>so you can make the situation &#34;worse&#34; by allowing it.<br/><br/>&gt; Certainly, if only one company made use of the extra nonce space, they would have an advantage.<br/><br/>Can you explain why the reality should be significantly different? In<br/>sufficiently near future.<br/><br/>&gt; Is that patented in any jurisdiction, all jurisdictions or only certain jurisdictions? Would a patent granted for SHA256 in Swaziland be sufficient for Bitcoin to change the Proof of Work algorithm?<br/><br/>We don&#39;t have to deal with any such theoretical situation now. You<br/>proposal goes in opposite direction, by adding support for patented<br/>algorithm. I don&#39;t know myself what the possible legal implications<br/>are (maybe only for a subset of miners) so I consider it as an<br/>unnecessary risk. At least before some conclusive legal analysis says<br/>differently. 2023-06-07T17:59:47Z