📅 Original date posted:2017-03-13
📝 Original message:That's simply a 51% attack choosing to censor transactions. We could do
that today, ban all transactions that aren't approved by the PBoC.
You respond to that with a PoW hardfork, or by finding some way to prop up
/ subsidize non-censorship miners.
On Mar 13, 2017 5:59 AM, "Nick ODell via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The problem with modifying Bitcoin to work around community norms is that
> it's a two-way street. Other people can do it too.
>
> Let me propose a counter-fork, or a "Double UASF." This is also a BIP9
> fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is
> 1506812400. It enforces every rule that UASF enforces, plus one additional
> rule. If 60% of blocks in any retargeting period signal for Double UASF,
> any descendant block that creates or spends a segregated witness output is
> invalid.
>
> Double UASF signaling never coincides with UASF signaling, because the
> signaling periods don't overlap. Full nodes happily validate the chain,
> because Double UASF doesn't break any rules; it just adds new ones. Miners
> who adopt Double UASF don't need to understand segwit, because all segwit
> transactions are banned. Miners don't need to commit to a wtxid structure,
> either. Per BIP 141, "If all transactions in a block do not have witness
> data, the commitment is optional." Segwit is activated, but useless. Miners
> who *do* adopt segwit will lose money, as their blocks are orphaned.
>
> Thanks,
> --Nick
>
> On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I recently posted about so called "user activated soft forks" and
>> received a lot of feedback. Much of this was how such methodologies could
>> be applied to segwit which appears to have fallen under the miner veto
>> category I explained in my original proposal, where there is apparently a
>> lot of support for the proposal from the economy, but a few mining pools
>> are vetoing the activation.
>>
>> It turns out Bitcoin already used flag day activation for P2SH[1
>> <https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283>;],
>> a soft fork which is remarkably similar to segwit. The disadvantage of a
>> UASF for segwit is there is an existing deployment. A UASF would require
>> another wide upgrade cycle (from what I can see, around 80% of existing
>> nodes have upgraded from pre-witness, to NODE_WITNESS capability[2
>> <http://luke.dashjr.org/programs/bitcoin/files/charts/services.html>;][3
>> <https://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/>;].
>> While absolute node count is meaningless, the uprgrade trend from version
>> to version seems significant.
>>
>> Also it is quite clear a substantial portion of the ecosystem industry
>> has put in time and resources into segwit adoption, in the form of
>> upgrading wallet code, updating libraries and various other integration
>> work that requires significant time and money. Further more, others have
>> built systems that rely on segwit, having put significant engineering
>> resources into developing systems that require segwit - such as several
>> lightning network system. This is much more significant social proof than
>> running a node.
>>
>> The delayed activation of segwit is also holding back a raft protocol of
>> innovations such as MAST, Covenants, Schnorr signature schemes and
>> signature aggregation and other script innovations of which, much of the
>> development work is already done.
>>
>> A better option would be to release code that causes the existing segwit
>> deployment to activate without requiring a completely new deployment nor
>> subject to hash power veto. This could be achieved if the economic majority
>> agree to run code that rejects non-signalling segwit blocks. Then from the
>> perspective of all existing witness nodes, miners trigger the BIP9
>> activation. Such a rule could come into effect 4-6 weeks before the BIP9
>> timeout. If a large part of the economic majority publicly say that they
>> will adopt this new client, miners will have to signal bip9 segwit
>> activation in order for their blocks to be valid.
>>
>> I have drafted a BIP proposal so the community may discuss
>> https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full
>> text below).
>>
>> References:
>> [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/
>> main.cpp#L1281-L1283
>> [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html
>> [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden
>> ce_of_widespread_segwit_support_near50_of/
>>
>> Proposal text:
>>
>> <pre>
>> BIP: bip-segwit-flagday
>> Title: Flag day activation for segwit deployment
>> Author: Shaolin Fry <shaolinfry at protonmail.ch>
>> Comments-Summary: No comments yet.
>> Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????
>> Status: Draft
>> Type: Informational
>> Created: 2017-03-12
>> License: BSD-3-Clause
>> CC0-1.0
>> </pre>
>>
>> ==Abstract==
>>
>> This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as "segwit".
>>
>> ==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==
>>
>> Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.
>>
>> ==Specification==
>>
>> All times are specified according to median past time.
>>
>> This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.
>>
>> 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.
>>
>> === Reference implementation ===
>>
>> <pre>
>> // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive
>> if (pindex->GetMedianTimePast() >= 1538352000 && pindex->GetMedianTimePast() <= 1510704000 && !IsWitnessEnabled(pindex->pprev, chainparams.GetConsensus())) {
>> if (!((pindex->nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (pindex->nVersion & VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {
>> return state.DoS(2, error("ConnectBlock(): relayed block must signal for segwit, please upgrade"), REJECT_INVALID, "bad-no-segwit");
>> }
>> }
>> </pre>
>>
>> ==Backwards Compatibility==
>>
>> This deployment is compatible with the existing "segwit" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.
>>
>> ==Rationale==
>>
>> Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues
>>
>> By orphaning non-signalling blocks during the last month of 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://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].
>>
>> ==Copyright==
>>
>> This document is placed in the public domain.
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/b9619fd6/attachment-0001.html>;
David Vorick [ARCHIVE] /
npub14h…9yjx0
2023-06-07 17:57:16
in reply to nevent1q…nh6j
Author Public Key
npub14h948ndawt32ps3y225sslch8344tmw8k5z0lxuxr6wq9tu6sl2qj9yjx0Published at
2023-06-07 17:57:16Event JSON
{
"id": "37356fe1604962c7e095bd6ef58ebba100a7c4be6e4f6db349c5a6de43744cc9",
"pubkey": "adcb53cdbd72e2a0c22452a9087f173c6b55edc7b504ff9b861e9c02af9a87d4",
"created_at": 1686160636,
"kind": 1,
"tags": [
[
"e",
"c85e331219b41163c53d11241cf7a40c8747f1688f2c56a907ca61b00451e77b",
"",
"root"
],
[
"e",
"7b7eee5a43f4bebe5fcc7039262789e004f12877928c568d5a09625618e1c3c0",
"",
"reply"
],
[
"p",
"2a9b7d3423041901b738be6b1d40a6e4dd3f9041e7a5fa4a2d3c662d296814c7"
]
],
"content": "📅 Original date posted:2017-03-13\n📝 Original message:That's simply a 51% attack choosing to censor transactions. We could do\nthat today, ban all transactions that aren't approved by the PBoC.\n\nYou respond to that with a PoW hardfork, or by finding some way to prop up\n/ subsidize non-censorship miners.\n\nOn Mar 13, 2017 5:59 AM, \"Nick ODell via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The problem with modifying Bitcoin to work around community norms is that\n\u003e it's a two-way street. Other people can do it too.\n\u003e\n\u003e Let me propose a counter-fork, or a \"Double UASF.\" This is also a BIP9\n\u003e fork, and it uses, say, bit 2. starttime is 1489449600, and the end time is\n\u003e 1506812400. It enforces every rule that UASF enforces, plus one additional\n\u003e rule. If 60% of blocks in any retargeting period signal for Double UASF,\n\u003e any descendant block that creates or spends a segregated witness output is\n\u003e invalid.\n\u003e\n\u003e Double UASF signaling never coincides with UASF signaling, because the\n\u003e signaling periods don't overlap. Full nodes happily validate the chain,\n\u003e because Double UASF doesn't break any rules; it just adds new ones. Miners\n\u003e who adopt Double UASF don't need to understand segwit, because all segwit\n\u003e transactions are banned. Miners don't need to commit to a wtxid structure,\n\u003e either. Per BIP 141, \"If all transactions in a block do not have witness\n\u003e data, the commitment is optional.\" Segwit is activated, but useless. Miners\n\u003e who *do* adopt segwit will lose money, as their blocks are orphaned.\n\u003e\n\u003e Thanks,\n\u003e --Nick\n\u003e\n\u003e On Sun, Mar 12, 2017 at 9:50 AM, shaolinfry via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e I recently posted about so called \"user activated soft forks\" and\n\u003e\u003e received a lot of feedback. Much of this was how such methodologies could\n\u003e\u003e be applied to segwit which appears to have fallen under the miner veto\n\u003e\u003e category I explained in my original proposal, where there is apparently a\n\u003e\u003e lot of support for the proposal from the economy, but a few mining pools\n\u003e\u003e are vetoing the activation.\n\u003e\u003e\n\u003e\u003e It turns out Bitcoin already used flag day activation for P2SH[1\n\u003e\u003e \u003chttps://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283\u003e],\n\u003e\u003e a soft fork which is remarkably similar to segwit. The disadvantage of a\n\u003e\u003e UASF for segwit is there is an existing deployment. A UASF would require\n\u003e\u003e another wide upgrade cycle (from what I can see, around 80% of existing\n\u003e\u003e nodes have upgraded from pre-witness, to NODE_WITNESS capability[2\n\u003e\u003e \u003chttp://luke.dashjr.org/programs/bitcoin/files/charts/services.html\u003e][3\n\u003e\u003e \u003chttps://www.reddit.com/r/Bitcoin/comments/5yyqt1/evidence_of_widespread_segwit_support_near50_of/\u003e].\n\u003e\u003e While absolute node count is meaningless, the uprgrade trend from version\n\u003e\u003e to version seems significant.\n\u003e\u003e\n\u003e\u003e Also it is quite clear a substantial portion of the ecosystem industry\n\u003e\u003e has put in time and resources into segwit adoption, in the form of\n\u003e\u003e upgrading wallet code, updating libraries and various other integration\n\u003e\u003e work that requires significant time and money. Further more, others have\n\u003e\u003e built systems that rely on segwit, having put significant engineering\n\u003e\u003e resources into developing systems that require segwit - such as several\n\u003e\u003e lightning network system. This is much more significant social proof than\n\u003e\u003e running a node.\n\u003e\u003e\n\u003e\u003e The delayed activation of segwit is also holding back a raft protocol of\n\u003e\u003e innovations such as MAST, Covenants, Schnorr signature schemes and\n\u003e\u003e signature aggregation and other script innovations of which, much of the\n\u003e\u003e development work is already done.\n\u003e\u003e\n\u003e\u003e A better option would be to release code that causes the existing segwit\n\u003e\u003e deployment to activate without requiring a completely new deployment nor\n\u003e\u003e subject to hash power veto. This could be achieved if the economic majority\n\u003e\u003e agree to run code that rejects non-signalling segwit blocks. Then from the\n\u003e\u003e perspective of all existing witness nodes, miners trigger the BIP9\n\u003e\u003e activation. Such a rule could come into effect 4-6 weeks before the BIP9\n\u003e\u003e timeout. If a large part of the economic majority publicly say that they\n\u003e\u003e will adopt this new client, miners will have to signal bip9 segwit\n\u003e\u003e activation in order for their blocks to be valid.\n\u003e\u003e\n\u003e\u003e I have drafted a BIP proposal so the community may discuss\n\u003e\u003e https://gist.github.com/shaolinfry/743157b0b1ee14e1ddc95031f1057e4c (full\n\u003e\u003e text below).\n\u003e\u003e\n\u003e\u003e References:\n\u003e\u003e [1]: https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/\n\u003e\u003e main.cpp#L1281-L1283\n\u003e\u003e [2]: http://luke.dashjr.org/programs/bitcoin/files/charts/services.html\n\u003e\u003e [3]: https://www.reddit.com/r/Bitcoin/comments/5yyqt1/eviden\n\u003e\u003e ce_of_widespread_segwit_support_near50_of/\n\u003e\u003e\n\u003e\u003e Proposal text:\n\u003e\u003e\n\u003e\u003e \u003cpre\u003e\n\u003e\u003e BIP: bip-segwit-flagday\n\u003e\u003e Title: Flag day activation for segwit deployment\n\u003e\u003e Author: Shaolin Fry \u003cshaolinfry at protonmail.ch\u003e\n\u003e\u003e Comments-Summary: No comments yet.\n\u003e\u003e Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-????\n\u003e\u003e Status: Draft\n\u003e\u003e Type: Informational\n\u003e\u003e Created: 2017-03-12\n\u003e\u003e License: BSD-3-Clause\n\u003e\u003e CC0-1.0\n\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\n\u003e\u003e ==Abstract==\n\u003e\u003e\n\u003e\u003e This document specifies a BIP16 like soft fork flag day activation of the segregated witness BIP9 deployment known as \"segwit\".\n\u003e\u003e\n\u003e\u003e ==Definitions==\n\u003e\u003e\n\u003e\u003e \"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.\n\u003e\u003e\n\u003e\u003e ==Motivation==\n\u003e\u003e\n\u003e\u003e Cause the mandatory activation of the existing segwit deployment before the end of midnight November 15th 2017.\n\u003e\u003e\n\u003e\u003e ==Specification==\n\u003e\u003e\n\u003e\u003e All times are specified according to median past time.\n\u003e\u003e\n\u003e\u003e This BIP will be activate between midnight October 1st 2017 (epoch time 1538352000) and midnight November 15th 2017 (epoch time 1510704000) if the existing segwit deployment is not activated before epoch time 1538352000. This BIP will cease to be active when the existing segwit deployment activates.\n\u003e\u003e\n\u003e\u003e While this BIP is active, all blocks must set the nVersion header top 3 bits to 001 together with bit field (1\u003c\u003c1) (according to the existing segwit deployment). Blocks that do not signal as required will be rejected.\n\u003e\u003e\n\u003e\u003e === Reference implementation ===\n\u003e\u003e\n\u003e\u003e \u003cpre\u003e\n\u003e\u003e // mandatory segwit activation between Oct 1st 2017 and Nov 15th 2017 inclusive\n\u003e\u003e if (pindex-\u003eGetMedianTimePast() \u003e= 1538352000 \u0026\u0026 pindex-\u003eGetMedianTimePast() \u003c= 1510704000 \u0026\u0026 !IsWitnessEnabled(pindex-\u003epprev, chainparams.GetConsensus())) {\n\u003e\u003e if (!((pindex-\u003enVersion \u0026 VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) \u0026\u0026 (pindex-\u003enVersion \u0026 VersionBitsMask(params, Consensus::DEPLOYMENT_SEGWIT)) != 0) {\n\u003e\u003e return state.DoS(2, error(\"ConnectBlock(): relayed block must signal for segwit, please upgrade\"), REJECT_INVALID, \"bad-no-segwit\");\n\u003e\u003e }\n\u003e\u003e }\n\u003e\u003e \u003c/pre\u003e\n\u003e\u003e\n\u003e\u003e ==Backwards Compatibility==\n\u003e\u003e\n\u003e\u003e This deployment is compatible with the existing \"segwit\" bit 1 deployment scheduled between midnight November 15th, 2016 and midnight November 15th, 2017.\n\u003e\u003e\n\u003e\u003e ==Rationale==\n\u003e\u003e\n\u003e\u003e Historically, the P2SH soft fork (BIP16) was activated using a predetermined flag day where nodes began enforcing the new rules. P2SH was successfully activated with relatively few issues\n\u003e\u003e\n\u003e\u003e By orphaning non-signalling blocks during the last month of the BIP9 bit 1 \"segwit\" deployment, this BIP can cause the existing \"segwit\" deployment to activate without needing to release a new deployment.\n\u003e\u003e\n\u003e\u003e ==References==\n\u003e\u003e\n\u003e\u003e [https://github.com/bitcoin/bitcoin/blob/v0.6.0/src/main.cpp#L1281-L1283 P2SH flag day activation].\n\u003e\u003e\n\u003e\u003e ==Copyright==\n\u003e\u003e\n\u003e\u003e This document is placed in the public domain.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\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\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170313/b9619fd6/attachment-0001.html\u003e",
"sig": "9951ea4ae5a9b7a4fb1a667c27b17566ebb32fe3d8d879e265c445d3a75515109244054bf038ae5b29ae4ca869e5890e203e5b639eb4aad396da8630ac458692"
}