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