📅 Original date posted:2017-05-23
📝 Original message:On Tue, May 23, 2017 at 5:51 AM, Kekcoin <kekcoin at protonmail.com> wrote:
> I think there may be merit to this idea, allowing for political compromise
> without sacrificing the technological integrity of Bitcoin. There are a few
> mechanical problems I see with it, though.
>
> 1. It should change its activation logic from BIP9-style to BIP8-style with
> a flagday of August 1. This to maintain backwards compatibility with the
> current deployment of BIP148 nodes. This proposal seems to be a measure to
> prevent a chainsplit, so it must make sure to avoid triggering one.
That can be done as a separate proposal, it's not mutually exclusive
to this one for those who intend to run BIP148.
>
> 2. This should be for miners only; non-miners should not enforce this. It
> severely weakens the block-signalling activation mechanism in several ways
> (lowered threshold, short deployment timeframe, no "locked in" delay before
> activation) and by doing so opens up attack vectors for
> consensus-partitioning attacks using malicious false signalling. For
> non-miners that seek to take their fate into their own hands, enforcing
> BIP148 is enough.
I disagree that it should be only run by miners, enforcement of
segsignal mandatory signalling by economic nodes strongly discourages
any false signaling.
>
> 3. Even for miners this is more risky than usual; only 31% of hashrate is
> required to false-signal the activation to fork-off honest miners. This
> attack vector is magnified by the lack of "locked in" delay that would allow
> laggards to upgrade before activation. I suggest adding in at least a 1-week
> lock-in period (given the shorter timeframes 2 weeks may eat up too much of
> the available voting time before the brick wall of BIP148 activation on
> August 1).
Those who can should still upgrade for segsignal, the more that
upgrade ahead of activation the more secure it is. Those who don't
upgrade would want to wait for more confirmations anyways. I didn't
think a lock in period was all that good an idea here due to the
fairly short deployment timeline.
>
> Under the assumption that this is indeed compatible with the terms of the
> Silbert agreement, we can presume the involved miners are willing to trust
> eachother more than usual so such a short lock-in period should be
> acceptable.
>
> -------- Original Message --------
> Subject: [bitcoin-dev] Reduced signalling threshold activation of existing
> segwit deployment
> Local Time: May 23, 2017 1:40 AM
> UTC Time: May 22, 2017 10:40 PM
> From: bitcoin-dev at lists.linuxfoundation.org
> To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
>
> I would like to propose an implementation that accomplishes the first
> part of the Barry Silbert proposal independently from the second:
>
> "Activate Segregated Witness at an 80% threshold, signaling at bit 4"
> in a way that
>
> The goal here is to minimize chain split risk and network disruption
> while maximizing backwards compatibility and still providing for rapid
> activation of segwit at the 80% threshold using bit 4.
>
> By activating segwit immediately and separately from any HF we can
> scale quickly without risking a rushed combined segwit+HF that would
> almost certainly cause widespread issues.
>
> Draft proposal:
> https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki
>
> Proposal text:
> <pre>
> BIP: segsignal
> Layer: Consensus (soft fork)
> Title: Reduced signalling threshold activation of existing segwit deployment
> Author: James Hilliard <james.hilliard1 at gmail.com>
> Status: Draft
> Type: Standards Track
> Created: 2017-05-22
> License: BSD-3-Clause
> CC0-1.0
> </pre>
>
> ==Abstract==
>
> This document specifies a method to activate the existing BIP9 segwit
> deployment with a majority hashpower less than 95%.
>
> ==Definitions==
>
> "existing segwit deployment" refer to the BIP9 "segwit" deployment
> using bit 1, between November 15th 2016 and November 15th 2017 to
> activate BIP141, BIP143 and BIP147.
>
> ==Motivation==
>
> Segwit increases the blocksize, fixes transaction malleability, and
> makes scripting easier to upgrade as well as bringing many other
> [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].
>
> This BIP provides a way for a simple majority of miners to coordinate
> activation of the existing segwit deployment with less than 95%
> hashpower. For a number of reasons a complete redeployment of segwit
> is difficulty to do until the existing deployment expires. This is due
> to 0.13.1+ having many segwit related features active already,
> including all the P2P components, the new network service flag, the
> witness-tx and block messages, compact blocks v2 and preferential
> peering. A redeployment of segwit will need to redefine all these
> things and doing so before expiry would greatly complicate testing.
>
> ==Specification==
>
> While this BIP is active, all blocks must set the nVersion header top
> 3 bits to 001 together with bit field (1<<1) (according to the
> existing segwit deployment). Blocks that do not signal as required
> will be rejected.
>
> ==Deployment==
>
> This BIP will be deployed by a "version bits" with an 80%(this can be
> adjusted if desired) activation threshold BIP9 with the name
> "segsignal" and using bit 4.
>
> This BIP will have a start time of midnight June 1st, 2017 (epoch time
> 1496275200) and timeout on midnight November 15th 2017 (epoch time
> 1510704000). This BIP will cease to be active when segwit is
> locked-in.
>
> === Reference implementation ===
>
> <pre>
> // Check if Segregated Witness is Locked In
> bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const
> Consensus::Params& params)
> {
> LOCK(cs_main);
> return (VersionBitsState(pindexPrev, params,
> Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==
> THRESHOLD_LOCKED_IN);
> }
>
> // SEGSIGNAL mandatory segwit signalling.
> if ( VersionBitsState(pindex->pprev, chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE
> &&
> !IsWitnessLockedIn(pindex->pprev, chainparams.GetConsensus()) &&
> // Segwit is not locked in
> !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus()) ) //
> and is not active.
> {
> bool fVersionBits = (pindex->nVersion & VERSIONBITS_TOP_MASK) ==
> VERSIONBITS_TOP_BITS;
> bool fSegbit = (pindex->nVersion &
> VersionBitsMask(chainparams.GetConsensus(),
> Consensus::DEPLOYMENT_SEGWIT)) != 0;
> if (!(fVersionBits && fSegbit)) {
> return state.DoS(0, error("ConnectBlock(): relayed block must
> signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
> }
> }
> </pre>
>
> https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1
>
> ==Backwards Compatibility==
>
> This deployment is compatible with the existing "segwit" bit 1
> deployment scheduled between midnight November 15th, 2016 and midnight
> November 15th, 2017. Miners will need to upgrade their nodes to
> support segsignal otherwise they may build on top of an invalid block.
> While this bip is active users should either upgrade to segsignal or
> wait for additional confirmations when accepting payments.
>
> ==Rationale==
>
> Historically we have used IsSuperMajority() to activate soft forks
> such as BIP66 which has a mandatory signalling requirement for miners
> once activated, this ensures that miners are aware of new rules being
> enforced. This technique can be leveraged to lower the signalling
> threshold of a soft fork while it is in the process of being deployed
> in a backwards compatible way.
>
> By orphaning non-signalling blocks during the BIP9 bit 1 "segwit"
> deployment, this BIP can cause the existing "segwit" deployment to
> activate without needing to release a new deployment.
>
> ==References==
>
> *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html
> Mailing list discussion]
> *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283
> P2SH flag day activation]
> *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]
> *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]
> *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]
> *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for
> Version 0 Witness Program]]
> *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]
> *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]
> *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]
> *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]
>
> ==Copyright==
>
> This document is dual licensed as BSD 3-clause, and Creative Commons
> CC0 1.0 Universal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 18:01:40
in reply to nevent1q…9yvc
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 18:01:40Event JSON
{
"id": "27d18bff4371d53b9c0484034e9dc829efb23dd23500db4b6b52619193e2d0ee",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686160900,
"kind": 1,
"tags": [
[
"e",
"0e75dbe41c43695b529774e7d664595889f129a79adf29751285b1cdd12ecad4",
"",
"root"
],
[
"e",
"a21a6c3bd1412c7395e6d8fbc2412c7881f8678e7c478621873f2e607eb9bf5b",
"",
"reply"
],
[
"p",
"2d272e6c463fa727a30075c3ed5c8a190036906ed39b99c44574197c7fd0c9aa"
]
],
"content": "📅 Original date posted:2017-05-23\n📝 Original message:On Tue, May 23, 2017 at 5:51 AM, Kekcoin \u003ckekcoin at protonmail.com\u003e wrote:\n\u003e I think there may be merit to this idea, allowing for political compromise\n\u003e without sacrificing the technological integrity of Bitcoin. There are a few\n\u003e mechanical problems I see with it, though.\n\u003e\n\u003e 1. It should change its activation logic from BIP9-style to BIP8-style with\n\u003e a flagday of August 1. This to maintain backwards compatibility with the\n\u003e current deployment of BIP148 nodes. This proposal seems to be a measure to\n\u003e prevent a chainsplit, so it must make sure to avoid triggering one.\nThat can be done as a separate proposal, it's not mutually exclusive\nto this one for those who intend to run BIP148.\n\u003e\n\u003e 2. This should be for miners only; non-miners should not enforce this. It\n\u003e severely weakens the block-signalling activation mechanism in several ways\n\u003e (lowered threshold, short deployment timeframe, no \"locked in\" delay before\n\u003e activation) and by doing so opens up attack vectors for\n\u003e consensus-partitioning attacks using malicious false signalling. For\n\u003e non-miners that seek to take their fate into their own hands, enforcing\n\u003e BIP148 is enough.\nI disagree that it should be only run by miners, enforcement of\nsegsignal mandatory signalling by economic nodes strongly discourages\nany false signaling.\n\u003e\n\u003e 3. Even for miners this is more risky than usual; only 31% of hashrate is\n\u003e required to false-signal the activation to fork-off honest miners. This\n\u003e attack vector is magnified by the lack of \"locked in\" delay that would allow\n\u003e laggards to upgrade before activation. I suggest adding in at least a 1-week\n\u003e lock-in period (given the shorter timeframes 2 weeks may eat up too much of\n\u003e the available voting time before the brick wall of BIP148 activation on\n\u003e August 1).\nThose who can should still upgrade for segsignal, the more that\nupgrade ahead of activation the more secure it is. Those who don't\nupgrade would want to wait for more confirmations anyways. I didn't\nthink a lock in period was all that good an idea here due to the\nfairly short deployment timeline.\n\u003e\n\u003e Under the assumption that this is indeed compatible with the terms of the\n\u003e Silbert agreement, we can presume the involved miners are willing to trust\n\u003e eachother more than usual so such a short lock-in period should be\n\u003e acceptable.\n\u003e\n\u003e -------- Original Message --------\n\u003e Subject: [bitcoin-dev] Reduced signalling threshold activation of existing\n\u003e segwit deployment\n\u003e Local Time: May 23, 2017 1:40 AM\n\u003e UTC Time: May 22, 2017 10:40 PM\n\u003e From: bitcoin-dev at lists.linuxfoundation.org\n\u003e To: Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\n\u003e I would like to propose an implementation that accomplishes the first\n\u003e part of the Barry Silbert proposal independently from the second:\n\u003e\n\u003e \"Activate Segregated Witness at an 80% threshold, signaling at bit 4\"\n\u003e in a way that\n\u003e\n\u003e The goal here is to minimize chain split risk and network disruption\n\u003e while maximizing backwards compatibility and still providing for rapid\n\u003e activation of segwit at the 80% threshold using bit 4.\n\u003e\n\u003e By activating segwit immediately and separately from any HF we can\n\u003e scale quickly without risking a rushed combined segwit+HF that would\n\u003e almost certainly cause widespread issues.\n\u003e\n\u003e Draft proposal:\n\u003e https://github.com/jameshilliard/bips/blob/bip-segsignal/bip-segsignal.mediawiki\n\u003e\n\u003e Proposal text:\n\u003e \u003cpre\u003e\n\u003e BIP: segsignal\n\u003e Layer: Consensus (soft fork)\n\u003e Title: Reduced signalling threshold activation of existing segwit deployment\n\u003e Author: James Hilliard \u003cjames.hilliard1 at gmail.com\u003e\n\u003e Status: Draft\n\u003e Type: Standards Track\n\u003e Created: 2017-05-22\n\u003e License: BSD-3-Clause\n\u003e CC0-1.0\n\u003e \u003c/pre\u003e\n\u003e\n\u003e ==Abstract==\n\u003e\n\u003e This document specifies a method to activate the existing BIP9 segwit\n\u003e deployment with a majority hashpower less than 95%.\n\u003e\n\u003e ==Definitions==\n\u003e\n\u003e \"existing segwit deployment\" refer to the BIP9 \"segwit\" deployment\n\u003e using bit 1, between November 15th 2016 and November 15th 2017 to\n\u003e activate BIP141, BIP143 and BIP147.\n\u003e\n\u003e ==Motivation==\n\u003e\n\u003e Segwit increases the blocksize, fixes transaction malleability, and\n\u003e makes scripting easier to upgrade as well as bringing many other\n\u003e [https://bitcoincore.org/en/2016/01/26/segwit-benefits/ benefits].\n\u003e\n\u003e This BIP provides a way for a simple majority of miners to coordinate\n\u003e activation of the existing segwit deployment with less than 95%\n\u003e hashpower. For a number of reasons a complete redeployment of segwit\n\u003e is difficulty to do until the existing deployment expires. This is due\n\u003e to 0.13.1+ having many segwit related features active already,\n\u003e including all the P2P components, the new network service flag, the\n\u003e witness-tx and block messages, compact blocks v2 and preferential\n\u003e peering. A redeployment of segwit will need to redefine all these\n\u003e things and doing so before expiry would greatly complicate testing.\n\u003e\n\u003e ==Specification==\n\u003e\n\u003e While this BIP is active, all blocks must set the nVersion header top\n\u003e 3 bits to 001 together with bit field (1\u003c\u003c1) (according to the\n\u003e existing segwit deployment). Blocks that do not signal as required\n\u003e will be rejected.\n\u003e\n\u003e ==Deployment==\n\u003e\n\u003e This BIP will be deployed by a \"version bits\" with an 80%(this can be\n\u003e adjusted if desired) activation threshold BIP9 with the name\n\u003e \"segsignal\" and using bit 4.\n\u003e\n\u003e This BIP will have a start time of midnight June 1st, 2017 (epoch time\n\u003e 1496275200) and timeout on midnight November 15th 2017 (epoch time\n\u003e 1510704000). This BIP will cease to be active when segwit is\n\u003e locked-in.\n\u003e\n\u003e === Reference implementation ===\n\u003e\n\u003e \u003cpre\u003e\n\u003e // Check if Segregated Witness is Locked In\n\u003e bool IsWitnessLockedIn(const CBlockIndex* pindexPrev, const\n\u003e Consensus::Params\u0026 params)\n\u003e {\n\u003e LOCK(cs_main);\n\u003e return (VersionBitsState(pindexPrev, params,\n\u003e Consensus::DEPLOYMENT_SEGWIT, versionbitscache) ==\n\u003e THRESHOLD_LOCKED_IN);\n\u003e }\n\u003e\n\u003e // SEGSIGNAL mandatory segwit signalling.\n\u003e if ( VersionBitsState(pindex-\u003epprev, chainparams.GetConsensus(),\n\u003e Consensus::DEPLOYMENT_SEGSIGNAL, versionbitscache) == THRESHOLD_ACTIVE\n\u003e \u0026\u0026\n\u003e !IsWitnessLockedIn(pindex-\u003epprev, chainparams.GetConsensus()) \u0026\u0026\n\u003e // Segwit is not locked in\n\u003e !IsWitnessEnabled(pindex-\u003epprev, chainparams.GetConsensus()) ) //\n\u003e and is not active.\n\u003e {\n\u003e bool fVersionBits = (pindex-\u003enVersion \u0026 VERSIONBITS_TOP_MASK) ==\n\u003e VERSIONBITS_TOP_BITS;\n\u003e bool fSegbit = (pindex-\u003enVersion \u0026\n\u003e VersionBitsMask(chainparams.GetConsensus(),\n\u003e Consensus::DEPLOYMENT_SEGWIT)) != 0;\n\u003e if (!(fVersionBits \u0026\u0026 fSegbit)) {\n\u003e return state.DoS(0, error(\"ConnectBlock(): relayed block must\n\u003e signal for segwit, please upgrade\"), REJECT_INVALID, \"bad-no-segwit\");\n\u003e }\n\u003e }\n\u003e \u003c/pre\u003e\n\u003e\n\u003e https://github.com/bitcoin/bitcoin/compare/0.14...jameshilliard:segsignal-v0.14.1\n\u003e\n\u003e ==Backwards Compatibility==\n\u003e\n\u003e This deployment is compatible with the existing \"segwit\" bit 1\n\u003e deployment scheduled between midnight November 15th, 2016 and midnight\n\u003e November 15th, 2017. Miners will need to upgrade their nodes to\n\u003e support segsignal otherwise they may build on top of an invalid block.\n\u003e While this bip is active users should either upgrade to segsignal or\n\u003e wait for additional confirmations when accepting payments.\n\u003e\n\u003e ==Rationale==\n\u003e\n\u003e Historically we have used IsSuperMajority() to activate soft forks\n\u003e such as BIP66 which has a mandatory signalling requirement for miners\n\u003e once activated, this ensures that miners are aware of new rules being\n\u003e enforced. This technique can be leveraged to lower the signalling\n\u003e threshold of a soft fork while it is in the process of being deployed\n\u003e in a backwards compatible way.\n\u003e\n\u003e By orphaning non-signalling blocks during the BIP9 bit 1 \"segwit\"\n\u003e deployment, this BIP can cause the existing \"segwit\" deployment to\n\u003e activate without needing to release a new deployment.\n\u003e\n\u003e ==References==\n\u003e\n\u003e *[https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013714.html\n\u003e Mailing list discussion]\n\u003e *[https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283\n\u003e P2SH flag day activation]\n\u003e *[[bip-0009.mediawiki|BIP9 Version bits with timeout and delay]]\n\u003e *[[bip-0016.mediawiki|BIP16 Pay to Script Hash]]\n\u003e *[[bip-0141.mediawiki|BIP141 Segregated Witness (Consensus layer)]]\n\u003e *[[bip-0143.mediawiki|BIP143 Transaction Signature Verification for\n\u003e Version 0 Witness Program]]\n\u003e *[[bip-0147.mediawiki|BIP147 Dealing with dummy stack element malleability]]\n\u003e *[[bip-0148.mediawiki|BIP148 Mandatory activation of segwit deployment]]\n\u003e *[[bip-0149.mediawiki|BIP149 Segregated Witness (second deployment)]]\n\u003e *[https://bitcoincore.org/en/2016/01/26/segwit-benefits/ Segwit benefits]\n\u003e\n\u003e ==Copyright==\n\u003e\n\u003e This document is dual licensed as BSD 3-clause, and Creative Commons\n\u003e CC0 1.0 Universal.\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",
"sig": "b8682a128602cc010565cdf77ca992a80272e8b548b8cba4b5e20b156df42d3a46d6212ddd4b113eef0b53cc12b240aa6c9d150afb49cd66db746a3a828f1a94"
}