{"type":"rich","version":"1.0","author_name":"npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8","author_url":"https://nostr.ae/npub1ej6vep7y2km5l6awukffelg8yeppkth2vjkjk9jypd5w336rxggs3p9cq8","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2017-04-05\n📝 Original message:Hi Greg,\n\nOn Wed, Apr 05, 2017 at 09:37:45PM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e Reverse engineering of a particular mining chip has demonstrated\n\u003e conclusively that ASICBOOST has been implemented\n\u003e in hardware.\n\u003e \n\u003e On that basis, I offer the following BIP draft for discussion.\n\u003e This proposal does not prevent the attack in general, but only\n\u003e inhibits covert forms of it which are incompatible with\n\u003e improvements to the Bitcoin protocol.\n\u003e \n\u003e I hope that even those of us who would strongly prefer that\n\u003e ASICBOOST be blocked completely can come together to support\n\u003e a protective measure that separates concerns by inhibiting\n\u003e the covert use of it that potentially blocks protocol improvements.\n\u003e \n\u003e [...]\n\u003e \n\u003e ==New consensus rule==\n\u003e \n\u003e Beginning block X and until block Y the coinbase transaction of\n\u003e each block MUST either contain a BIP-141 segwit commitment or a\n\u003e correct WTXID commitment with ID 0xaa21a9ef.\n\u003e \n\u003e (See BIP-141 \"Commitment structure\" for details)\n\u003e \n\u003e Existing segwit using miners are automatically compatible with\n\u003e this proposal. Non-segwit miners can become compatible by simply\n\u003e including an additional output matching a default commitment\n\u003e value returned as part of getblocktemplate.\n\u003e \n\u003e Miners SHOULD NOT automatically discontinue the commitment\n\u003e at the expiration height.\n\nDecentralized systems without patent encumbrance is an important topic\nfor me. We'd be very interested in adding this into extension blocks.\n\nClaims like these merit serious attention. If you can provide any kind\nof proof or documentation of this (doesn't need to be conclusive, just\nsomething), I will provide my word and promise publicly here and now\nthat I will personally see to it that a commitment which solves this\n(albeit possibly using a slightly different format to make it\ncompatible) is added into the Extension Blocks spec. If there is\nevidence, my support and authorship of the Extension Block specification\nis contingent upon resolving this issue.\n\nWe have added an issue here:\nhttps://github.com/tothemoon-org/extension-blocks/issues/6\n\nI'm interested in a more detailed explanation on how the Merle tree\nstructure works so we can add it to the spec, I didn't follow exactly\nthe new consensus rule and its mechanism in those several lines.\n\nWe will begin making a pull request adding it into our specification,\nbut more clarity on how to do it on its own would be helpful. We will\nalso consider the code exposure change to adding in SegWit on the\nCanonical/1MB chain if it is more elegant to implement.\n\nPackaging this into our proposal would not only be important, but\nhelpful to the end goals of this proposal as it becomes a standard\nsoft-fork consensus rule which has greater guarantees around\nenforcibility than user-actication.\n\nFurther, can you provide clarity and confirmation into why this\ncommitment wasn't required as part of SegWit? \n\n-- \nJoseph Poon"}