{"type":"rich","version":"1.0","author_name":"npub17w8rw3wtcr03zdsdjhmcj37w0g6l79gsspleltsznexdktv0qw0qd3nc05","author_url":"https://nostr.ae/npub17w8rw3wtcr03zdsdjhmcj37w0g6l79gsspleltsznexdktv0qw0qd3nc05","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-08\n📝 Original message:Pavel,\n\nUntil all miners update (firmware or hardware), the change encourages\n\u003e large difference in mining efficiency. And IMO it gives another\n\u003e advantage to large mining operations in general.\n\u003e\n\nCertainly, there would have to be changes for stratum, pool software, etc.\nBut the monetary incentives align to all the changes needed.\n\nRemember, overt ASICBoost can get something like a 12.5% efficiency boost\nfrom toggling a single bit in the version (equivalent to 2 colliding work\nitems), 18.5% from 2 bits (equivalent to 4 colliding work items), 23.4%\nfrom 4 bits (see https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf).\nIn lieu of an explicit allowance of overt ASICBoost, the monetary\nincentives lead to odd BIP9 signaling, especially if 4 or more proposals\nsignal at once. There really isn't a practical way to block overt ASICBoost\nwithout forcing the version bits to be some value.\n\nIn other words, the question isn't about allowing/disallowing ASICBoost at\nthis point. The question is whether we want ASICBoost open or hidden.\n\n\n\u003e You make a strong assumption that the new optimization is not\n\u003e compatible with overt ASICBoost. If it is compatible, ASICBoost\n\u003e doesn't help you with \"defending against\" the new optimization at all.\n\u003e And it can be the case that the new optimization is based on ASICBoost\n\u003e so you can make the situation \"worse\" by allowing it.\n\u003e\n\nThis would only be the case if overt ASICBoost were not possible at all. It\nis currently possible to use overt ASICBoost, so optimizations based on\novert ASICBoost would also be possible unless something were done to\nactively block it.\n\n\u003e Certainly, if only one company made use of the extra nonce space, they\n\u003e would have an advantage.\n\u003e\n\u003e Can you explain why the reality should be significantly different? In\n\u003e sufficiently near future.\n\n\nMarket incentives, I would imagine. How quickly that would be is not\nsomething I'm qualified to answer.\n\n\n\u003e We don't have to deal with any such theoretical situation now. You\n\u003e proposal goes in opposite direction, by adding support for patented\n\u003e algorithm. I don't know myself what the possible legal implications\n\u003e are (maybe only for a subset of miners) so I consider it as an\n\u003e unnecessary risk. At least before some conclusive legal analysis says\n\u003e differently.\n\u003e\n\nI'm not adding support as much as explicitly allowing what's implicitly\nallowed. Whatever risks you imagine for this proposal exist on the network\ncurrently, with unmodified BIP-141 and with modified BIP-141. The\ndifference in adding the modification is that overt ASICBoost is explicitly\nallowed in the modified BIP-141 as to not hide it.\n\nJimmy\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170408/14268b35/attachment.html\u003e"}