{"type":"rich","version":"1.0","author_name":"npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","author_url":"https://nostr.ae/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-05-10\n📝 Original message:Yea, I think in any hardfork that we should be talking about, a part of\nit should include 1) fix the version field so its a static constant, 2)\nthe merkle root becomes hash of the real block header 3) swap first 2\nbytes of the merkle root with the timestamp's two high-order bits, 4)\nswap the next 4 bytes of the merkle root with the difficulty field.\n\nI believe this should be compatible with all existing ASICs, with the\nexception, possibly, of some 21 Inc hardware. I believe this fixes\nAsicBoost (without thinking about it tooo much, so please critique).\n\nWhile this is somewhat nasty, the risks of AsicBoost and the precedent\nthat should be set necessitates a response, and it should be included in\nany hardfork.\n\nMatt\n\nOn 05/10/16 20:27, Tier Nolan via bitcoin-dev wrote:\n\u003e The various chunks in the double SHA256 are\n\u003e \n\u003e Chunk 1: 64 bytes\n\u003e version\n\u003e previous_block_digest\n\u003e merkle_root[31:4]\n\u003e \n\u003e Chunk 2: 64 bytes\n\u003e merkle_root[3:0]\n\u003e nonce\n\u003e timestamp\n\u003e target\n\u003e \n\u003e Chunk 3: 64 bytes\n\u003e digest from first sha pass\n\u003e \n\u003e Their improvement requires that all data in Chunk 2 is identical except\n\u003e for the nonce.  With 4 bytes, the birthday paradox means collisions can\n\u003e be found reasonable easily.\n\u003e \n\u003e If hard forks are allowed, then moving more of the merkle root into the\n\u003e 2nd chunk would make things harder.  The timestamp and target could be\n\u003e moved into chunk 1.  This increases the merkle root to 12 bytes in the\n\u003e 2nd chunk.  Finding collisions would be made much more difficult.\n\u003e \n\u003e If ASIC limitations mean that the nonce must stay where it is, this\n\u003e would mean that the merkle root would be split into two pieces.\n\u003e \n\u003e On Tue, May 10, 2016 at 7:57 PM, Peter Todd via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \n\u003e     As part of the hard-fork proposed in the HK agreement(1) we'd like\n\u003e     to make the\n\u003e     patented AsicBoost optimisation useless, and hopefully make further\n\u003e     similar\n\u003e     optimizations useless as well.\n\u003e \n\u003e     What's the best way to do this? Ideally this would be SPV\n\u003e     compatible, but if it\n\u003e     requires changes from SPV clients that's ok too. Also the fix this\n\u003e     should be\n\u003e     compatible with existing mining hardware.\n\u003e \n\u003e \n\u003e     1)\n\u003e     https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff\n\u003e \n\u003e     2)\n\u003e     http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html\n\u003e \n\u003e     --\n\u003e     https://petertodd.org 'peter'[:-1]@petertodd.org \u003chttp://petertodd.org\u003e\n\u003e \n\u003e     _______________________________________________\n\u003e     bitcoin-dev mailing list\n\u003e     bitcoin-dev at lists.linuxfoundation.org\n\u003e     \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}