{"type":"rich","version":"1.0","author_name":"npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","author_url":"https://nostr.ae/npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-05-10\n📝 Original message:Your idea of moving the Merkle root to the second chunk does not work.\n\nThe AsicBoost can change the version bits and it does not need to find a\ncollision.\n(However *Spondoolies patent *only mentions Merkle collisions:\nhttps://patentscope.wipo.int/search/docservicepdf_pct/id00000032873338/PAMPH/WO2016046820.pdf\n)\n\nBack in 2014 I designed a ASIC-compatible block header that prevents\nAsicBoost in all its forms.\n\nYou can find it here:\nhttps://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/\n\nBasically, the idea is to put in the first 64 bytes a 4 byte hash of the\nsecond 64-byte chunk. That design also allows increased nonce space in the\nfirst 64 bytes.\n\nBut it you want to do a simpler change, you can more easily use the first\n32 bits of the Parent Block Hash (now currently zero) to store the first 4\nbytes of the SHA256 of the last 16 bytes of the header. That way to \"tie\"\nthe two header chunks. It's a minimal change (but a hard-fork)\n\nBut some ASIC companies already have cores that are better (on power, cost,\nrate, temperature, etc.) than competing companies ASICs. Why do you think a\n10% improvement from AsicBoost is different from many of other improvements\nthey already have (secretly) added? Maybe we (?) should only allow ASICs\nthat have a 100% open source designs?\n\nIf we change the protocol then the message to the ecosystem is that ASIC\noptimizations should be kept secret. It is fair to change the protocol\nbecause we don't like that certain ASIC manufacturer has better chips, if\nthe chips are sold in the market and anyone can buy them? And what about\nusing approximate adders (30% improvement), or dual rail asynchronous\nadders (also more than 10% improvement) ? How do we repair those?\n\nDisclaimer: I have stake in AsicBoost, but I'm not sure about this.\n\n\nOn Tue, May 10, 2016 at 5:27 PM, Tier Nolan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\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 be\n\u003e 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 2nd\n\u003e 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 would\n\u003e 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 \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e As part of the hard-fork proposed in the HK agreement(1) we'd like to\n\u003e\u003e make the\n\u003e\u003e patented AsicBoost optimisation useless, and hopefully make further\n\u003e\u003e similar\n\u003e\u003e optimizations useless as well.\n\u003e\u003e\n\u003e\u003e What's the best way to do this? Ideally this would be SPV compatible, but\n\u003e\u003e if it\n\u003e\u003e requires changes from SPV clients that's ok too. Also the fix this should\n\u003e\u003e be\n\u003e\u003e compatible with existing mining hardware.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 1)\n\u003e\u003e https://medium.com/@bitcoinroundtable/bitcoin-roundtable-consensus-266d475a61ff\n\u003e\u003e\n\u003e\u003e 2)\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-April/012596.html\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160510/e98fa60e/attachment-0001.html\u003e"}