{"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:#bitcoin at freenode:\n 00:04    gmaxwell| lol poon pretending that he isn't complicit in all this stuff.\n\nAre you *fucking* serious? Is this how you resolve all problems? I'm\ntaking you seriously and having second thoughts and want to make public\ncommitments to do the right thing without any evidence and you come out\nand say *this*?\n\nOn Thu, Apr 06, 2017 at 12:17:17AM +0000, Gregory Maxwell via bitcoin-dev wrote:\n\u003e On Wed, Apr 5, 2017 at 11:05 PM, theymos via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e This seems to be a serious security problem.  Would it be possible to have\n\u003e \u003e a flag-day softfork included in Bitcoin Core as soon as 0.14.1? I think that a trigger\n\u003e \u003e 3-6 months from release should be sufficient for enough of the economy to upgrade,\n\u003e \u003e given the severity of the issue.\n\u003e \n\u003e Not 0.14.1 because that is in RC already and will hopefully be out in a week.\n\u003e \n\u003e I think the speed of adoption depends a lot of the level of support\n\u003e from the community. I don't believe there are any technical hurdles to\n\u003e implementing this relatively quickly (and I specifically propose using\n\u003e the users choice of the segwit commitment or a modified form in order\n\u003e to lower the technical complexity and risk).\n\u003e \n\u003e \u003e BIP 141 says that the the commitment is optional if there are no SegWit transactions in\n\u003e \u003e the block,  so will today's SegWit-ready miners always produce it even when optional\n\u003e \u003e according to BIP 141, as required by this softfork?\n\u003e \n\u003e This is the default behavior as of 0.13.2, but I haven't gone out to\n\u003e measure this which is why the backwards compatibility section of the\n\u003e BIP isn't written yet.\n\u003e \n\u003e \n\u003e While I'm posting, I've had a dozen off-list emails that presented me\n\u003e with some FAQ:\n\u003e \n\u003e Many people asked what other protocol upgrades beyond segwit could run\n\u003e into the same incompatibility.\n\u003e \n\u003e Many proposed improvements to Bitcoin require additional\n\u003e transaction-dependent commitment data.\n\u003e \n\u003e Examples include:\n\u003e \n\u003e (1) Segwit.\n\u003e (2) UTXO commitments. (non-delayed, at least)\n\u003e (3) Committed Bloom filters\n\u003e (4) Committed address indexes\n\u003e (5) STXO commitments (non-delayed).\n\u003e (6) Weak blocks\n\u003e (7) Most kinds of fraud proofs\n\u003e -- to state a few.\n\u003e \n\u003e Unfortunately, putting *any* commitment to data dependent on the right\n\u003e hand side of the hash tree in the left hand side (e.g. coinbase) means\n\u003e a massive increase in the computation required for covert boosting,\n\u003e because it means you can't use the left+right side combinations to\n\u003e eliminate most of the hashing.\n\u003e \n\u003e It's plausible, in fact, that this extra computation could completely\n\u003e nullify the ASICBOOST advantage-- though this depends a lot on the\n\u003e fine details of the implementation.\n\u003e \n\u003e This proposal does not itself propose nullifying ASICBOOST entirely,\n\u003e it proposes severely handicapping the covert form of it, and\n\u003e eliminating the differential advantage for boosting miners related to\n\u003e the use of transaction-dependent commitments.\n\u003e \n\u003e Basically there are two completely separate concerns: that boosting\n\u003e can produce a monopoly advantage which could be severely harmful to\n\u003e the ecosystem, and that the efficient implementation of _covert_\n\u003e boosting can severely harm many useful protocol improvements.   My\n\u003e proposal only addresses the second concern, by (I believe) completely\n\u003e leveling the playing field so that opposing commitments will not break\n\u003e boosting any worse, and by making covert boosting less appealing in\n\u003e general.\n\u003e \n\u003e Use of the segwit-style commitment even in non-segwit blocks is sufficient\n\u003e because the segwit commitment commits to all  transactions  (except\n\u003e the coinbase) and not just segwit ones.\n\u003e (It was designed this way so that lite clients that needed witness\n\u003e data could work with just one tree).\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\n-- \nJoseph Poon"}