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@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@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 <shaolin...@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@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
