{"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:Replies inline.\n\nOn 05/10/16 21:43, Sergio Demian Lerner via bitcoin-dev wrote:\n-snip-\n\n\u003e But some ASIC companies already have cores that are better (on power,\n\u003e cost, rate, temperature, etc.) than competing companies ASICs. Why do\n\u003e you think a 10% improvement from AsicBoost is different from many of\n\u003e other improvements they already have (secretly) added? Maybe we (?)\n\u003e should only allow ASICs that have a 100% open source designs?\n\nOne is patented and requires paying a license fee to a group, or more\nlikely, ends up with it being impossible to import hardware from other\njurisdictions into the US/western world. The other requires more\ninvestment in R\u0026D, and over the long run, there is no guaranteed\nadvantage to such groups.\n\n\u003e If we change the protocol then the message to the ecosystem is that ASIC\n\u003e optimizations should be kept secret.\n\nTo some extent, this is the case, but there is a strong difference\nbetween a guaranteed advantage enforced by the legal system and one that\nis true due to intellectual superiority. In the long run, I am confident\nthe second will not remain the case. For example, AsicBoost was\nindependently discovered by at least two companies/individuals within a\nyear or two.\n\n\u003e It is fair to change the protocol\n\u003e because we don't like that certain ASIC manufacturer has better chips,\n\u003e if the chips are sold in the market and anyone can buy them? And what\n\u003e about using approximate adders (30% improvement), or dual rail\n\u003e asynchronous adders (also more than 10% improvement) ? How do we repair\n\u003e those?\n\nAs far as I'm aware neither of these are patented. Is this not the case?\n\n\u003e Disclaimer: I have stake in AsicBoost, but I'm not sure about this.\n\u003e  \n\u003e \n\u003e On Tue, May 10, 2016 at 5:27 PM, Tier Nolan 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     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\n\u003e     except for the nonce.  With 4 bytes, the birthday paradox means\n\u003e     collisions can be found reasonable easily.\n\u003e \n\u003e     If hard forks are allowed, then moving more of the merkle root into\n\u003e     the 2nd chunk would make things harder.  The timestamp and target\n\u003e     could be moved into chunk 1.  This increases the merkle root to 12\n\u003e     bytes in the 2nd chunk.  Finding collisions would be made much more\n\u003e     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\n\u003e         like to make the\n\u003e         patented AsicBoost optimisation useless, and hopefully make\n\u003e         further 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\n\u003e         this 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\n\u003e         \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     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"}