Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the simplest and most straightforward process. While convenient there are a number limitations with this method.

Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it's likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades.

Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.

Thirdly, the signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community. The hash powers' role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions gets included in the block chain.

As such, soft forks rules are actually always enforced by the nodes, not the miners. Miners of course can opt-out by simply not including transactions that use the new soft fork feature, but they cannot produce blocks that are invalid to the soft fork. The P2SH soft fork is a good example of this, where non-upgraded miners would see P2SH as spendable without a signature and consider them valid. If such an transaction were to be included in a block, the block would be invalid and the miner would lose the block reward and fees.

So-called "censorship" soft forks do not require nodes to opt in, because >51% of the hash power already have the ability to orphan blocks that contain transactions they have blacklisted. Since this is not a change in validity, nodes will accept the censored block chain automatically.

The fourth problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to "make a decision" on behalf of the community: who is and isn't signalling becomes a huge public focus and may put pressures onto miners they are unprepared for. Some miners may not be in a position to upgrade, or may prefer not to participate in the soft fork which is their right. However, that miner may now become a lone reason that vetoes activation for everyone, where the soft fork is an opt-in feature! This situation seems to be against the voluntary nature of the Bitcoin system where participation at all levels is voluntary and kept honest by well balanced incentives.

Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don't), it would be better if a miner could chose to not participate in triggering activation of something they won't use, but, without being a veto to the process (and all the ire they may have to experience as a consequence).

The alternative discussed here is "flag day activation" where nodes begin enforcement at a predetermined time in the future. This method needs a longer lead time than a hash power based activation trigger, but offers a number of advantages and perhaps provides a better tradeoff.

Soft forks are still entirely optional to use post activation. For example, with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time of writing. Miners are free to not mine P2SH transactions, however, the incentives are such that miners should still validate transactions so they don't accidentally include invalid transactions and cause their block to be rejected. As an additional safety measure for well designed soft forks, relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default; a miner would have to purposefully mine an invalid transaction, which is against their own economic interest.

Since the incentives of the Bitcoin system rely on self validation, economic nodes (miners and users) should always remain safe by ensuring their nodes either validate the current rules, or, they can place their network behind a full node that will filter out invalid transactions and blocks at the edge of their network (so called firewall or border nodes).

A user activated soft fork is permissive. Miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned as was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66, BIP65-CLTV) which made it a compulsory upgrade for miners.

BIP9 "versionbits" soft fork activation method is also permissive in so far as non-upgraded miners are not forced to upgrade after activation because their blocks wont be orphaned. A recent case was the "CSV" soft fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork allows non-upgraded miners to continue mining so long as they didn't produce invalid blocks.

Miners always retain discretion on which transactions to mine. However, regardless of whether they actively include transactions using the new soft fork feature, or not, the incentive for hash power to upgrade in order to validate is strong: if they do not, they could be vulnerable to a rogue miner willing to waste 12.5BTC to create an invalid block, which may cause non-validating miners to build on an invalid chain similar to the BIP66 incident. Validation has always had a strong requirement.

A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. Even if only 10% of users ever wanted a feature, so long as the benefit outweighed the technical risks, it would not be rational to deny others the ability to opt-in.

My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout.

You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab

You've made many salient points, Shaolin, though I have a few questions:

1) How well does this model work under adversarial conditions? Fair pointabout signaling not being reliable, though it seems more vague in terms ofsafety given that you can't actually know what percentage of hashrate thatis /not/ signaling for the soft fork has taken the necessary precautions toavoid mining an invalid block and potentially causing a hard fork. It'sprobably safe to say that if a flag-day soft fork is activated, there willbe at least a few parties who will attempt to trigger a chain fork bycrafting transactions that are valid via non-fork rules but invalid via thesoft fork rules.

2) If the flag day soft fork is activated with only a minority of hashratesupport + safely opted-out hashrate, isn't it possible for the rest ofminers to coordinate orphaning any soft fork compatible blocks to kill thesoft fork chain? This would be a major difference from a miner-activatedsoft fork, correct? Unless perhaps many miners colluded to signal soft forksupport while not actually supporting it...

3) In terms of complexity for mining pool operators, how well does thismodel scale if there are N soft forks and the pool doesn't want to opt-into any of them? Couldn't this result in those pool operators having to runnot just one border node, but a multitude of "chained" border nodes if thesoft forks are spread across different software implementations?

It seems to me that this type of user-driven approach would preferably becoupled with assurances from major Bitcoin wallets / exchanges / paymentprocessors that they will not honor coins from a chain fork that resultsfrom invalid spends of outputs encumbered by soft fork rules. Though on theother hand, I don't see such an assurance being possible given thatexchanges have an incentive to take the first mover advantage in listing anew coin.

- Jameson

On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <

Post by shaolinfry via bitcoin-devSome thoughts about the activation mechanism for soft forks. In the pastwe used IsSuperMajority and currently use BIP9 as soft fork activationmethods, where a supermajority of hashrate triggers nodes to beginenforcing new rules. Hashrate based activation is convenient because it isthe simplest and most straightforward process. While convenient there are anumber limitations with this method.Firstly, it requires trusting the hash power will validate afteractivation. The BIP66 soft fork was a case where 95% of the hashrate wassignaling readiness but in reality about half was not actually validatingthe upgraded rules and mined upon an invalid block by mistake[1].Secondly, miner signalling has a natural veto which allows a smallpercentage of hashrate to veto node activation of the upgrade for everyone.To date, soft forks have taken advantage of the relatively centralisedmining landscape where there are relatively few mining pools building validblocks; as we move towards more hashrate decentralization, it's likely thatwe will suffer more and more from "upgrade inertia" which will veto mostupgrades.Upgrade inertia in inevitable for widely deployed software and can be seenfor example, with Microsoft Windows. At the time of writing 5.72% of allMicrosoft Windows installations are still running Windows XP, despitemainstream support ending in 2009 and being superseded by 4 softwaregenerations, Vista, 7, 8 and 10.Thirdly, the signaling methodology is widely misinterpreted to mean thehash power is voting on a proposal and it seems difficult to correct thismisunderstanding in the wider community. The hash powers' role is to selectvalid transactions, and to extend the blockchain with valid blocks. Fullyvalidating economic nodes ensure that blocks are valid. Nodes thereforedefine validity according to the software they run, but miners decide whatalready valid transactions gets included in the block chain.As such, soft forks rules are actually always enforced by the nodes, notthe miners. Miners of course can opt-out by simply not includingtransactions that use the new soft fork feature, but they cannot produceblocks that are invalid to the soft fork. The P2SH soft fork is a goodexample of this, where non-upgraded miners would see P2SH as spendablewithout a signature and consider them valid. If such an transaction were tobe included in a block, the block would be invalid and the miner would losethe block reward and fees.So-called "censorship" soft forks do not require nodes to opt in, because

contain transactions they have blacklisted. Since this is not a change invalidity, nodes will accept the censored block chain automatically.The fourth problem with supermajority hash power signaling is it drawsunnecessary attention to miners which can become unnecessarily political.Already misunderstood as a vote, miners may feel pressure to "make adecision" on behalf of the community: who is and isn't signalling becomes ahuge public focus and may put pressures onto miners they are unpreparedfor. Some miners may not be in a position to upgrade, or may prefer not toparticipate in the soft fork which is their right. However, that miner maynow become a lone reason that vetoes activation for everyone, where thesoft fork is an opt-in feature! This situation seems to be against thevoluntary nature of the Bitcoin system where participation at all levels isvoluntary and kept honest by well balanced incentives.Since miners already have the protocol level right to select whatevertransaction they prefer (and not mine those they don't), it would be betterif a miner could chose to not participate in triggering activation ofsomething they won't use, but, without being a veto to the process (and allthe ire they may have to experience as a consequence).The alternative discussed here is "flag day activation" where nodes beginenforcement at a predetermined time in the future. This method needs alonger lead time than a hash power based activation trigger, but offers anumber of advantages and perhaps provides a better tradeoff.Soft forks are still entirely optional to use post activation. Forexample, with P2SH, many participants in the Bitcoin ecosystem still do notuse P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the timeof writing. Miners are free to not mine P2SH transactions, however, theincentives are such that miners should still validate transactions so theydon't accidentally include invalid transactions and cause their block to berejected. As an additional safety measure for well designed soft forks,relay policy rules prevent non-standard and invalid transactions from beingrelayed and mined by default; a miner would have to purposefully mine aninvalid transaction, which is against their own economic interest.Since the incentives of the Bitcoin system rely on self validation,economic nodes (miners and users) should always remain safe by ensuringtheir nodes either validate the current rules, or, they can place theirnetwork behind a full node that will filter out invalid transactions andblocks at the edge of their network (so called firewall or border nodes).A user activated soft fork is permissive. Miners do not have to producenew version blocks and non-upgraded miners' blocks will not be orphaned aswas the case with IsSuperMajority soft forks (e.g. BIP34, BIP66,BIP65-CLTV) which made it a compulsory upgrade for miners.BIP9 "versionbits" soft fork activation method is also permissive in sofar as non-upgraded miners are not forced to upgrade after activationbecause their blocks wont be orphaned. A recent case was the "CSV" softfork that activated BIP68, BIP112 and BIP113. As such, the CSV soft forkallows non-upgraded miners to continue mining so long as they didn'tproduce invalid blocks.Miners always retain discretion on which transactions to mine. However,regardless of whether they actively include transactions using the new softfork feature, or not, the incentive for hash power to upgrade in order tovalidate is strong: if they do not, they could be vulnerable to a rogueminer willing to waste 12.5BTC to create an invalid block, which may causenon-validating miners to build on an invalid chain similar to the BIP66incident. Validation has always had a strong requirement.A user activated soft fork is win-win because it adds an option that somepeople want that does not detract from other peoples' enjoyment. Even ifonly 10% of users ever wanted a feature, so long as the benefit outweighedthe technical risks, it would not be rational to deny others the ability toopt-in.My suggestion is to have the best of both worlds. Since a user activatedsoft fork needs a relatively long lead time before activation, we cancombine with BIP9 to give the option of a faster hash power coordinatedactivation or activation by flag day, whichever is the sooner. In bothcases, we can leverage the warning systems in BIP9. The change isrelatively simple, adding an activation-time parameter which willtransition the BIP9 state to LOCKED_IN before the end of the BIP9deployment timeout.You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab[1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining[2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=1472043312917&to=1488030912918_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

You've made many salient points, Shaolin, though I have a few questions:

1) How well does this model work under adversarial conditions? Fair point about signaling not being reliable, though it seems more vague in terms of safety given that you can't actually know what percentage of hashrate that is /not/ signaling for the soft fork has taken the necessary precautions to avoid mining an invalid block and potentially causing a hard fork. It's probably safe to say that if a flag-day soft fork is activated, there will be at least a few parties who will attempt to trigger a chain fork by crafting transactions that are valid via non-fork rules but invalid via the soft fork rules.

In a well designed soft fork, transactions under the old rules are non-standard by default and will not propagate or be mined. A miner would have to deliberately include the invalid transaction in a block and mine it. The invalid block would be rejected by the network costing the miner block reward and fees.

If >51% of the hashrate does not upgrade or does not take steps to protect themselves from invalid blocks, they will fork if someone produces an invalid block. Game theory suggests the incentive for those who do not wish to participate, would be to do so safely. There is no incentive to allow an attacker to cause you to split off from the network and it is trivial to prevent it.

There is a valid concern about "spy" mining and I cited a previous incident with BIP66 activation and we should be working towards solutions that remove the incentive to spy mine. "Weak blocks", where miners propagate their proposed blocks before solving the PoW may provide better incentives against spy mining, while delivering more (~no propagation delay and full validation, and thus more security).

2) If the flag day soft fork is activated with only a minority of hashrate support + safely opted-out hashrate, isn't it possible for the rest of miners to coordinate orphaning any soft fork compatible blocks to kill the soft fork chain? This would be a major difference from a miner-activated soft fork, correct? Unless perhaps many miners colluded to signal soft fork support while not actually supporting it...

The basic assumption in the Bitcoin system is that miners will remain honest because it is in their economic interest to do so. Of course 51% of the hashrate can censor the minority hash by orphaning blacklisted transactions or blocks. I am fairly certain it would be considered an attack by as well as being very conspicuous. A 51% attack would likely cause a dramatic loss in confidence in the Bitcoin system and adversely affect price. It is reasonable to assume miners would not do that because mining has to remain profitable. Additionally, such a scenario would draw much ire from users who may escalate demands for a PoW change.

It is assuming good-faith and that miners would not want to deny people the ability to opt into something they wanted. All that is required of miners is to upgrade their border node. Miners should update their software anyway for security reasons.

3) In terms of complexity for mining pool operators, how well does this model scale if there are N soft forks and the pool doesn't want to opt-in to any of them? Couldn't this result in those pool operators having to run not just one border node, but a multitude of "chained" border nodes if the soft forks are spread across different software implementations?

While BIP9 allows for 29 parallel deployments I think it is unrealistic to expect there would be such a high number of active parallel deployments at any one time: History shows soft forks take a minimum of 6 months design, consensus building, coding and testing before deployment. With such a high bar, I do not envisage more than a couple of parallel deployments at any given time. I also do not envisage "conflicting" soft forks, as that would not meet consensus from the technical community on the basis of safety and sanity. In any case, the deployment strategy of each soft fork should be considered on a case by case basis.

It seems to me that this type of user-driven approach would preferably be coupled with assurances from major Bitcoin wallets / exchanges / payment processors that they will not honor coins from a chain fork that results from invalid spends of outputs encumbered by soft fork rules. Though on the other hand, I don't see such an assurance being possible given that exchanges have an incentive to take the first mover advantage in listing a new coin.

Soft fork consensus proposals should be sane, uncontroversial and have a reasonably high bar in terms of technical consensus as we have seen with other soft forks to date. There is an implicit assumption in my text, that the decision to deploy a soft fork (regardless of the activation method) is based on a reasonable expectation that users will make use of the new feature. Hashrate signalling is not a vote, but a coordination trigger. Soft forks are backwards compatible and opt-in; so long as they are well written and bug free, users should at worst, be agnostic towards them because they have a choice whether to safely use the new feature or not, without preventing others' enjoyment of the feature. A controversial or unreasonable soft fork would not gain traction and I believe it would be fairly self evident.

In short, I do expect wide ecosystem collaboration as part of any deployment strategy, both hashrate or flag day based.

Many thanks for taking the time to read over and consider my thoughts and proposal. I would be happy to discuss more if you have any further questions or suggestions.

Some thoughts about the activation mechanism for soft forks. In the past we used IsSuperMajority and currently use BIP9 as soft fork activation methods, where a supermajority of hashrate triggers nodes to begin enforcing new rules. Hashrate based activation is convenient because it is the simplest and most straightforward process. While convenient there are a number limitations with this method.

Firstly, it requires trusting the hash power will validate after activation. The BIP66 soft fork was a case where 95% of the hashrate was signaling readiness but in reality about half was not actually validating the upgraded rules and mined upon an invalid block by mistake[1].

Secondly, miner signalling has a natural veto which allows a small percentage of hashrate to veto node activation of the upgrade for everyone. To date, soft forks have taken advantage of the relatively centralised mining landscape where there are relatively few mining pools building valid blocks; as we move towards more hashrate decentralization, it's likely that we will suffer more and more from "upgrade inertia" which will veto most upgrades.

Upgrade inertia in inevitable for widely deployed software and can be seen for example, with Microsoft Windows. At the time of writing 5.72% of all Microsoft Windows installations are still running Windows XP, despite mainstream support ending in 2009 and being superseded by 4 software generations, Vista, 7, 8 and 10.

Thirdly, the signaling methodology is widely misinterpreted to mean the hash power is voting on a proposal and it seems difficult to correct this misunderstanding in the wider community. The hash powers' role is to select valid transactions, and to extend the blockchain with valid blocks. Fully validating economic nodes ensure that blocks are valid. Nodes therefore define validity according to the software they run, but miners decide what already valid transactions gets included in the block chain.

As such, soft forks rules are actually always enforced by the nodes, not the miners. Miners of course can opt-out by simply not including transactions that use the new soft fork feature, but they cannot produce blocks that are invalid to the soft fork. The P2SH soft fork is a good example of this, where non-upgraded miners would see P2SH as spendable without a signature and consider them valid. If such an transaction were to be included in a block, the block would be invalid and the miner would lose the block reward and fees.

So-called "censorship" soft forks do not require nodes to opt in, because >51% of the hash power already have the ability to orphan blocks that contain transactions they have blacklisted. Since this is not a change in validity, nodes will accept the censored block chain automatically.

The fourth problem with supermajority hash power signaling is it draws unnecessary attention to miners which can become unnecessarily political. Already misunderstood as a vote, miners may feel pressure to "make a decision" on behalf of the community: who is and isn't signalling becomes a huge public focus and may put pressures onto miners they are unprepared for. Some miners may not be in a position to upgrade, or may prefer not to participate in the soft fork which is their right. However, that miner may now become a lone reason that vetoes activation for everyone, where the soft fork is an opt-in feature! This situation seems to be against the voluntary nature of the Bitcoin system where participation at all levels is voluntary and kept honest by well balanced incentives.

Since miners already have the protocol level right to select whatever transaction they prefer (and not mine those they don't), it would be better if a miner could chose to not participate in triggering activation of something they won't use, but, without being a veto to the process (and all the ire they may have to experience as a consequence).

The alternative discussed here is "flag day activation" where nodes begin enforcement at a predetermined time in the future. This method needs a longer lead time than a hash power based activation trigger, but offers a number of advantages and perhaps provides a better tradeoff.

Soft forks are still entirely optional to use post activation. For example, with P2SH, many participants in the Bitcoin ecosystem still do not use P2SH. Only 11% of bitcoins[2] are stored in P2SH addresses at the time of writing. Miners are free to not mine P2SH transactions, however, the incentives are such that miners should still validate transactions so they don't accidentally include invalid transactions and cause their block to be rejected. As an additional safety measure for well designed soft forks, relay policy rules prevent non-standard and invalid transactions from being relayed and mined by default; a miner would have to purposefully mine an invalid transaction, which is against their own economic interest.

Since the incentives of the Bitcoin system rely on self validation, economic nodes (miners and users) should always remain safe by ensuring their nodes either validate the current rules, or, they can place their network behind a full node that will filter out invalid transactions and blocks at the edge of their network (so called firewall or border nodes).

A user activated soft fork is permissive. Miners do not have to produce new version blocks and non-upgraded miners' blocks will not be orphaned as was the case with IsSuperMajority soft forks (e.g. BIP34, BIP66, BIP65-CLTV) which made it a compulsory upgrade for miners.

BIP9 "versionbits" soft fork activation method is also permissive in so far as non-upgraded miners are not forced to upgrade after activation because their blocks wont be orphaned. A recent case was the "CSV" soft fork that activated BIP68, BIP112 and BIP113. As such, the CSV soft fork allows non-upgraded miners to continue mining so long as they didn't produce invalid blocks.

Miners always retain discretion on which transactions to mine. However, regardless of whether they actively include transactions using the new soft fork feature, or not, the incentive for hash power to upgrade in order to validate is strong: if they do not, they could be vulnerable to a rogue miner willing to waste 12.5BTC to create an invalid block, which may cause non-validating miners to build on an invalid chain similar to the BIP66 incident. Validation has always had a strong requirement.

A user activated soft fork is win-win because it adds an option that some people want that does not detract from other peoples' enjoyment. Even if only 10% of users ever wanted a feature, so long as the benefit outweighed the technical risks, it would not be rational to deny others the ability to opt-in.

My suggestion is to have the best of both worlds. Since a user activated soft fork needs a relatively long lead time before activation, we can combine with BIP9 to give the option of a faster hash power coordinated activation or activation by flag day, whichever is the sooner. In both cases, we can leverage the warning systems in BIP9. The change is relatively simple, adding an activation-time parameter which will transition the BIP9 state to LOCKED_IN before the end of the BIP9 deployment timeout.

You can find the proposal here https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab

Post by shaolinfry via bitcoin-dev3) In terms of complexity for mining pool operators, how well does this model scale if there are N soft forks and the pool doesn't want to opt-in to any of them? Couldn't this result in those pool operators having to run not just one border node, but a multitude of "chained" border nodes if the soft forks are spread across different software implementations?

While BIP9 allows for 29 parallel deployments I think it is unrealistic to expect there would be such a high number of active parallel deployments at any one time: History shows soft forks take a minimum of 6 months design, consensus building, coding and testing before deployment. With such a high bar, I do not envisage more than a couple of parallel deployments at any given time. I also do not envisage "conflicting" soft forks, as that would not meet consensus from the technical community on the basis of safety and sanity. In any case, the deployment strategy of each soft fork should be considered on a case by case basis.

The relationship between a codebase and chain fork implementations is similar to vendor lock-in, and is being used in a similar manner.

There is nothing preventing a single codebase from implementing all forks and exposing the option to apply any non-conflicting combination of them.

While this has not been the norm libbitcoin now utilizes this approach. Currently the options to apply any activated Bitcoin forks are exposed via config. I personally am not working to implement non-activated forks at this point, but that's just prioritization.

Recently I objected to BIP90. This hard fork is presented as a code simplification and a performance optimization. I showed in the discussion that it was neither. Nevertheless we implemented this additional code and give the user the option to apply it or not. It's application produces no performance benefit, but it ensures that the choice of forks remains in the hands of the user.

Without at least a majority hashrate validating blocks, it is possible just asingle invalid block could split the chain such that the majority continuebuilding a most-work on that invalid block.

This failure to validate a softfork is similar in some respects to a hardfork,but with one critical difference: the default behaviour of old nodes will beto follow the chain with the most-work that was valid under the pre-softforkrules. This actually *inverts* the benefit of the softfork over a hardfork,and makes a softfork deployed in such a manner de facto behave as if it hadbeen a hardfork, IF someone ever mines a single malicious block.

For this reason, I think a minority-hashrate softfork requires a much higherdegree of social support than merely the widespread agreement typical ofsoftforks. It might perhaps require less than the full ~100% consensushardforks require, but it likely comes somewhat close.

Once it gets over 50% hashrate enforcement, however, the situation improves alot more: a malicious block may split obsolete miners off the valid chain, butit will eventually resolve on its own given enough time. Due to naturalfluctuations in block finding, however, automatic measurement may need to lookfor >75%.

So I would suggest that instead of a simple flag day activation, this proposalwould be improved by changing the flag day to merely reduce the hashraterequirement from 95% to 75%.

(In addition to the above concerns, if >50% of miners are hostile to thenetwork, we likely have other problems.)

I think UASF is a great idea for the reasons mentioned before that itmore closely matches the balance of powers in bitcoin, and that its muchmore opt-in.

Many people are comparing an UASF fork with a hard fork. I disagree withthis view and I think there is a difference between the two kinds offorks. The situation between hard and soft forks is reversed.

In a fork between segwit-invalid and segwit-valid after a UASF, if thesegwit-valid chain ever ends up with more work then the segwit-invalidchain will be annihilated in a big re-organization asnon-segwit-enforcing nodes move to the segwit-valid chain. The less-workchain will simply cease to exist.

Only a miner that recodes their software can initiate such a fork,because segwit transactions are non-standard and won't be relayed bydefault.

A closer situation is the accidental fork created soon after the BIP66soft fork. The fork lasted a few blocks and did not mine anytransactions except the coinbase. It was annihilated with a monetaryloss to any miner that took part.

Here is an argument for why chain fork is unlikely to last long or becreated by a rational self-interested miner, assuming the bitcoineconomic majority even slightly enforces the UASF.

Because the segwit-invalid coins can be annihilated in this way andsegwit-valid coins cannot, segwit-invalid coins are more risky to holdas an asset, all else equal.

A more risky asset has a lower price, all else equal. Because investorsdemand higher risk premiums for holding it and also short sellers maysell down the price in the hopes of making a profit if it's value goesto zero.

In cryptocurrencies like bitcoin, hashpower follows price. This is veryclear from historical trends and the underlying economic forces.

A lower-hashrate chain will eventually be overtaken in work by ahigher-hashrate chain.

Therefore, the segwit-invalid chain will be annihilated sooner or laterif the price of its coin is higher.

Of course as the old saying goes markets can stay irrational longer thanwe can stay solvent, which is why I think UASF should only go ahead ifwe're sure that a big part of the economic majority will enforce it.This will make the value and liquidity of the segwit-invalid chain verylow and make the annihilating re-organization happen faster.User-activated means it _must_ be done by the users of bitcoin.

I also think that the UASF is a good idea. Hashrate follows coin price. Ifthe UASF has the higher coin price, the other chain will be annihilated. Ifthe UASF has a lower coin price, the user activated chain can still exist(though their coins can be trivially stolen on the majority chain).

The success of the UASF depends entirely on the price. And actually, theprice is easy to manipulate. If you, as an economically active full node,refuse to acknowledge the old chain and demand that incoming coins arriveover the UASF chain. In doing so, you drive down the utility of the oldchain and drive up the utility of the new chain. This ultimately impactsthe price.

I think it would be pretty easy to get high confidence of the success of aUASF. Basically you need all the major economic hubs to agree to upgradeand then exclusively accept UASF coins. I don't have a comprehensive list,but if we could sign on 75% of the major exchanges and payment processors,and get 75% of the wallets to upgrade, then the UASF would be very likelyto successfully obliterate the old rules, as miners would be unable to selltheir coins or pay their bills by stubbornly sticking to the old chain.It's less risky than a hard fork by far, because there is zero risk of coinsplit if the UASF has majority hashrate, which will follow majorityeconomic value.

A serious proposal I think would get all the code ready and merged, butwithout setting a flag day. Then we would get signatures from the majorinstitutions promising to use the software and saying that they are readyfor a flag day. After that, you release a patch with a flag day 12 monthsin the future. People can upgrade immediately, and have a full year totransition.

That gives tons of time for people to upgrade, and tons of confidence thatthe UASF will end up as the majority chain.

If we cannot get enough major exchanges, payment processors, and othereconomic hubs to upgrade, the flag day should remain upset, as the risk ofcoin split will be non-zero.

I would suggest that a carefully executed UASF is much riskier than a softfork, but far, far less risky than a hard fork.

There are two aspects of system security in Bitcoin, mining (hash power) and payment validation (economy). The security of each is a function of its level of decentralization. Another way to think of it is that a system with less decentralization has a smaller community (consensus). A large consensus is more secure in that it is more resistant to change (forks) than a system with a small consensus.

The fact that mining is highly centralized makes it relatively easy to enforce a fork via miner collaboration, and hard to do so without it.

So clearly the other option, as being discussed here, is to enforce a fork via the economy. Given the highly centralized nature of the economy, described below as "economic hubs", it is also relatively easy as well.

Independent of one's opinion on the merits of one fork or another, the state of centralization in Bitcoin is an area of great concern. If "we" can sit down with 75% of the economy and/or 90% of the hash power (which of course has been done) and negotiate a change to any rule, Bitcoin is a purely political money.

If "we" can do this, so can "they".

e

I also think that the UASF is a good idea. Hashrate follows coin price. If the UASF has the higher coin price, the other chain will be annihilated. If the UASF has a lower coin price, the user activated chain can still exist (though their coins can be trivially stolen on the majority chain).The success of the UASF depends entirely on the price. And actually, the price is easy to manipulate. If you, as an economically active full node, refuse to acknowledge the old chain and demand that incoming coins arrive over the UASF chain. In doing so, you drive down the utility of the old chain and drive up the utility of the new chain. This ultimately impacts the price.I think it would be pretty easy to get high confidence of the success of a UASF. Basically you need all the major economic hubs to agree to upgrade and then exclusively accept UASF coins. I don't have a comprehensive list, but if we could sign on 75% of the major exchanges and payment processors, and get 75% of the wallets to upgrade, then the UASF would be very likely to successfully obliterate the old rules, as miners would be unable to sell their coins or pay their bills by stubbornly sticking to the old chain. It's less risky than a hard fork by far, because there is zero risk of coin split if the UASF has majority hashrate, which will follow majority economic value.A serious proposal I think would get all the code ready and merged, but without setting a flag day. Then we would get signatures from the major institutions promising to use the software and saying that they are ready for a flag day. After that, you release a patch with a flag day 12 months in the future. People can upgrade immediately, and have a full year to transition.That gives tons of time for people to upgrade, and tons of confidence that the UASF will end up as the majority chain.If we cannot get enough major exchanges, payment processors, and other economic hubs to upgrade, the flag day should remain upset, as the risk of coin split will be non-zero.I would suggest that a carefully executed UASF is much riskier than a soft fork, but far, far less risky than a hard fork._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

the UASF has the higher coin price, the other chain will be annihilated. Ifthe UASF has a lower coin price, the user activated chain can still exist(though their coins can be trivially stolen on the majority chain).

I don't think that's true. Say there are two forks of Blahcoin. Alicethinks there's a 55% chance that Fork A will succeed. Bob thinks there's a55% chance that Fork B will succeed. Alice trades all of her Fork B coinsfor all of Bob's Fork A coins. Now, Bob and Alice both have a stake in onefork or the other succeeding. Alice starts spending more time around Fork Ausers; Bob starts spending his time with Fork B users.

A year passes, and Alice and Bob meet again. Bob tells Alice that Fork Bhas been doing much better than Fork A, and is trading at ten times theprice. Alice replies that it doesn't matter, since Fork B will soon splitinto B1 and B2. After all, if Fork B surrendered its principles once, itcan do so again. Bob replies that Fork B represents the true spirit ofBlahcoin. Alice replies that all of the people whose opinion she respectsbelieve that Fork B violates principles set down by the Founder (peace beupon him.)

Bob disagrees, and cites an annotated collection of the Founder's writings,which clearly show that if a situation like what provoked the Great Forkhappens, Fork B is in the right. All of the people Bob knows (except Alice)agree that this shows Fork A is invalid. Alice replies that Bob iscommitting the bandwagon fallacy; even if a thousand people believe thatred is green, that does not make it true. Also, the collection takesseveral of the Founder's comments out of context. If one looks at commentsmade prior to the release of Blahcoin, they lay out a framework thatenvisions Fork A. Bob replies that Alice can't use statements made prior tothe release of Blahcoin to establish original intent; the system hadn'tbeen designed yet.

Bob points out that Fork B has a higher total chainwork. Alice scoffs. Sheposits a Fork C, which is exactly like Fork A, except that chainwork isdefined to be the previous definition plus a quadrillion. Bob finds thatridiculous. Fork C would transgress upon intrinsic principles of Blahcoin.No more than Fork B does, Alice replies.

----

Each sentence above is true from some point of view. Each person sincerelybelieves in the rightness of their position. Is there some objectivemeasure, that both Alice and Bob can agree on, that resolves this? I don'tthink there is. Bob and Alice will sneer at each other for being idiotsforever. The schism will never resolve.

Satoshi Bless,--Nick

On Sun, Mar 5, 2017 at 11:10 AM, David Vorick via bitcoin-dev <

Post by David Vorick via bitcoin-devI also think that the UASF is a good idea. Hashrate follows coin price. Ifthe UASF has the higher coin price, the other chain will be annihilated. Ifthe UASF has a lower coin price, the user activated chain can still exist(though their coins can be trivially stolen on the majority chain).The success of the UASF depends entirely on the price. And actually, theprice is easy to manipulate. If you, as an economically active full node,refuse to acknowledge the old chain and demand that incoming coins arriveover the UASF chain. In doing so, you drive down the utility of the oldchain and drive up the utility of the new chain. This ultimately impactsthe price.I think it would be pretty easy to get high confidence of the success of aUASF. Basically you need all the major economic hubs to agree to upgradeand then exclusively accept UASF coins. I don't have a comprehensive list,but if we could sign on 75% of the major exchanges and payment processors,and get 75% of the wallets to upgrade, then the UASF would be very likelyto successfully obliterate the old rules, as miners would be unable to selltheir coins or pay their bills by stubbornly sticking to the old chain.It's less risky than a hard fork by far, because there is zero risk of coinsplit if the UASF has majority hashrate, which will follow majorityeconomic value.A serious proposal I think would get all the code ready and merged, butwithout setting a flag day. Then we would get signatures from the majorinstitutions promising to use the software and saying that they are readyfor a flag day. After that, you release a patch with a flag day 12 monthsin the future. People can upgrade immediately, and have a full year totransition.That gives tons of time for people to upgrade, and tons of confidence thatthe UASF will end up as the majority chain.If we cannot get enough major exchanges, payment processors, and othereconomic hubs to upgrade, the flag day should remain upset, as the risk ofcoin split will be non-zero.I would suggest that a carefully executed UASF is much riskier than a softfork, but far, far less risky than a hard fork._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Independent of one's opinion on the merits of one fork or another, thestate of centralization in Bitcoin is an area of great concern. If "we" cansit down with 75% of the economy and/or 90% of the hash power (which ofcourse has been done) and negotiate a change to any rule, Bitcoin is apurely political money.

If "we" can do this, so can "they".

e

There is no doubt that politics play a big role in all of this. Also nodoubt that broader decentralization would be superior. But miner activatedsoft forks and user activated soft forks do not need discussions withcentralized parties to move forward. It is merely two different methods forpushing a soft fork through the network.

The key is that it's a soft fork. Old nodes continue to work as always,whether the soft fork deploys or not.

User activated soft forks, or perhaps more accurately called 'economicallyforced soft forks' are a tool to use if the miners are in clear oppositionto the broader economy. They only work if the broader economy actuallyfully supports the soft fork, which is much more difficult to measure thanminer support. And miners with deeper pockets may be able to resist forsome time, effectively performing a rewardless 51% attack and maintaining asplit network for some time. The miners would lose lots of money, but oldnodes would feel all the burn of a hard fork, followed by a sudden deepreorg when the network finally 'heals'.

I guess in some sense you'd be playing chicken with the miners. If thesplit is not instantly successful there would be a lot of damage to oldnodes, even if the majority of new nodes had upgraded. (but there wouldalso be a lot of damage to the miners).

the UASF has the higher coin price, the other chain will be annihilated. Ifthe UASF has a lower coin price, the user activated chain can still exist(though their coins can be trivially stolen on the majority chain).

I don't think that's true. Say there are two forks of Blahcoin. Alicethinks there's a 55% chance that Fork A will succeed. Bob thinks there's a55% chance that Fork B will succeed. Alice trades all of her Fork B coinsfor all of Bob's Fork A coins. Now, Bob and Alice both have a stake in onefork or the other succeeding. Alice starts spending more time around Fork Ausers; Bob starts spending his time with Fork B users.

This is not relevant to a UASF. The existing nodes on the network have asingle formal definition for longest chain. If the UASF is successful, theold nodes will follow the new soft fork and there will be only one chain.Spirit of Bitcoin or not, the UASF is successful and there is no coin splitor network fork.

Post by David Vorick via bitcoin-devUser activated soft forks, or perhaps more accurately called 'economicallyforced soft forks' are a tool to use if the miners are in clear oppositionto the broader economy.

I don't think they work for that, at least not for new features,because miners will presumably just head the whole thing off byorphaning the whole class of non-standard transactions that are thesubject of the fork. In the SegWit case, they'd just orphan anythingthat looks like a SegWit transaction, valid or not. That way theydon't need to worry about ending up on the wrong side of the upgrade,because no transaction affected by the proposed rule change will everget into the longest chain. Rational node operators (particularlyexchanges) will likely also adopt their stricter rule change, sincethey know any chain that breaks it will end up being orphaned, so youdon't want to act on a payment that you see confirmed in it. So thenyou're back where you started, except that your soft-fork is now ade-facto hard-fork, because you have to undo the new, stricter rulethat the miners introduced to head off your shenannigans.

Where they're interesting is where you can do something meaningful byforcing some transactions through on a once-off basis. For example, ifthe Chinese government identified an address belonging to Uighurseparatists and leaned on Chinese miners to prevent anything from thataddress confirming, it might be interesting for users to say, "Ifthese utxos are not spent by block X, your block is invalid".

They might also be interesting for feature upgrades in a world wheremining is radically decentralized and upgrades are fighting againstinertia rather than opposition, but sadly that's not the world wecurrently live in.----Edmund EdgarFounder, Social Minds Inc (KK)Twitter: @edmundedgarLinked In: edmundedgarSkype: edmundedgarhttp://www.socialminds.jp

I don't think they work for that, at least not for new features,because miners will presumably just head the whole thing off byorphaning the whole class of non-standard transactions that are thesubject of the fork. In the SegWit case, they'd just orphan anythingthat looks like a SegWit transaction, valid or not. That way theydon't need to worry about ending up on the wrong side of the upgrade,because no transaction affected by the proposed rule change will everget into the longest chain. Rational node operators (particularlyexchanges) will likely also adopt their stricter rule change, sincethey know any chain that breaks it will end up being orphaned, so youdon't want to act on a payment that you see confirmed in it. So thenyou're back where you started, except that your soft-fork is now ade-facto hard-fork, because you have to undo the new, stricter rulethat the miners introduced to head off your shenannigans.Where they're interesting is where you can do something meaningful byforcing some transactions through on a once-off basis. For example, ifthe Chinese government identified an address belonging to Uighurseparatists and leaned on Chinese miners to prevent anything from thataddress confirming, it might be interesting for users to say, "Ifthese utxos are not spent by block X, your block is invalid".They might also be interesting for feature upgrades in a world wheremining is radically decentralized and upgrades are fighting againstinertia rather than opposition, but sadly that's not the world wecurrently live in.

Post by Gareth Williams via bitcoin-devWhat you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with.

Well, they'd be censoring transactions to prevent the thing fromactivating in the first place. (As opposed to censoring a subset ofthose transactions to enforce the new rule, which is the behaviourthat the people promoting the change want.) There would be no point atwhich people reasonably expected that something useful would happen ifthey sent funds to an address protected by the new scripting rule.

This is true. But what we're talking about here is hostility to *aparticular proposal to change the network rules* which is (in thishypothetical case) supported by the economic majority of users. Thisdoesn't, in itself, break Bitcoin, although the economic majority areof course always free to hard-fork to something new if they'reunhappy.

transactions, in response to a user activated soft fork that themajority of hashpower disagrees with.

This definition of censorship would apply to all validation.

A miner is free to select whatever transactions he wants, for whateverreasons he wants. Bitcoin's defense against censorship (and disruption)is in the broad distribution of over 50% (anecdotally) of the hash poweramong a large number of people.

Post by Edmund Edgar via bitcoin-devWell, they'd be censoring transactions to prevent the thing fromactivating in the first place. (As opposed to censoring a subset ofthose transactions to enforce the new rule, which is the behaviourthat the people promoting the change want.)

Exactly, a soft fork expects that people start rejecting a previouslyvalid style of transaction, or that they ignore it. It's perfectlyreasonable to conclude that some miners may continue to accept thesoft-fork-invalidated transactions and instead reject the new style oftransactions as invalid. Reliance on their acceptance of the soft forkis based on the weak assumption that they won't change their software orthat they live in fear of a retaliatory POW change.

Honesty in this context refers to double spending. Selecting a differentrule set effectively moves one to another coin, which is not dishonest(hostile to anyone). Miners have zero technical or ethical obligationto follow any particular set of rules. Bitcoin has one golden rule, runwhatever code you want. Security is based on decentralization, notwell-behaved people (or well-behaved software).

Post by Edmund Edgar via bitcoin-devThis is true. But what we're talking about here is hostility to *aparticular proposal to change the network rules* which is (in thishypothetical case) supported by the economic majority of users. Thisdoesn't, in itself, break Bitcoin, although the economic majority areof course always free to hard-fork to something new if they'reunhappy.

Again spot on. Users of the money purchase security from miners. Minersare under no obligation to provide that service nor are users under anyobligation to purchase it.

One thing to consider is how different the landscape would look if everyperson on the planet was a miner, and the economy was similarlydistributed. Would it be easier to get 51% hash power on board with asoft fork, or some much higher percentage on board with a hard fork? Itseems likely that any proposed material change would fail. Regardless ofhow one feels about that, it is the nature of a sound money that itdoesn't change.

Post by Gareth Williams via bitcoin-devWhat you're describing is a hashpower activated soft fork to censortransactions, in response to a user activated soft fork that the majorityof hashpower disagrees with.

It is incorrect to say that censoring of transactions is what Edmundsuggested. It's purely about the form they take, you can re-send thetransaction in a different form with the same content and they go through.Hence, not transaction censoring.

I do believe the point that Edmund brought up is a very good one, the ideathat a set of users can force the miners to do something is rather silly andthe setup that a minority miner fraction can force the majority to dosomething is equally silly. This is because the majority mining hashpowercan fight back against this attack upon them.

Don’t be mistaken; a hash-minority attacking the hash-majority is in actualfact an attack upon Bitcoin as a whole.If this were possible then next year we’d see governments try to pushthrough changes in the same UASF way. I’m very happy that UASFs can’t workbecause that would be the end of Bitcoin's freedom and decentralized nature.

Post by Gareth Williams via bitcoin-devIt is always possible for a majority of hashpower to censor transactionsthey disagree with. Users may view that as an attack, and can alwaysrespond with a POW hard fork.

I definitely welcome that approach.

The result would be that you have two chains, but also you ensure that thechain that the miners didn’t like will no longer be something they can mine.Not even the minority set of miners that like the softfork can mine on it.This is a win-win and then the market will decide which one will "win".

This goes both ways, miners both generate value (in the form of security)and they take value (in the form of inflation).If the majority of the users are hostile and reject blocks that the minerscreate, or change the POW, then what the miners bring to the table is alsoremoved.Bitcoin would lose the security and in the short term even the ability tomine blocks every 10 minutes.

So, lets correct your statement a little;«Bitcoin only works when the majority of the hashpower and the (economic)majority of the users are balanced in power and have their goals aligned.»

Presumably a POW hard fork would be accompanied by a difficulty reset, so that the deployment didn't have *both* of these problems from the outset. There's really little difference between 10 minutes at little/no security and zero conf. See testnet. But people might feel better about still seeing blocks.

But in any case it's not clear to me why you assume a loss of security in the "short term" is something that can be overcome. The short term can presumably prevent the long term from ever becoming.

Post by Gareth Williams via bitcoin-devWhat you're describing is a hashpower activated soft fork to censortransactions, in response to a user activated soft fork that the majorityof hashpower disagrees with.

It is incorrect to say that censoring of transactions is what Edmundsuggested. It's purely about the form they take, you can re-send thetransaction in a different form with the same content and they go through.Hence, not transaction censoring.I do believe the point that Edmund brought up is a very good one, the ideathat a set of users can force the miners to do something is rather silly andthe setup that a minority miner fraction can force the majority to dosomething is equally silly. This is because the majority mining hashpowercan fight back against this attack upon them.Don’t be mistaken; a hash-minority attacking the hash-majority is in actualfact an attack upon Bitcoin as a whole.If this were possible then next year we’d see governments try to pushthrough changes in the same UASF way. I’m very happy that UASFs can’t workbecause that would be the end of Bitcoin's freedom and decentralized nature.

Post by Gareth Williams via bitcoin-devIt is always possible for a majority of hashpower to censor transactionsthey disagree with. Users may view that as an attack, and can alwaysrespond with a POW hard fork.

I definitely welcome that approach.The result would be that you have two chains, but also you ensure that thechain that the miners didn’t like will no longer be something they can mine.Not even the minority set of miners that like the softfork can mine on it.This is a win-win and then the market will decide which one will "win".

This goes both ways, miners both generate value (in the form of security)and they take value (in the form of inflation).If the majority of the users are hostile and reject blocks that the minerscreate, or change the POW, then what the miners bring to the table is alsoremoved.Bitcoin would lose the security and in the short term even the ability tomine blocks every 10 minutes.So, lets correct your statement a little;«Bitcoin only works when the majority of the hashpower and the (economic)majority of the users are balanced in power and have their goals aligned.»--Tom ZanderBlog: https://zander.github.ioVlog: https://vimeo.com/channels/tomscryptochannel_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I fail to see how any non-mining user can attack a miner. The worst theycan do is refuse to buy their coinbase transaction. Do you believe thatusers are obligated to buy coins from miners? If not, then all miners arevoluntarily choosing a set of rules to enforce and a set of policy to mine.

Donât be mistaken; a hash-minority attacking the hash-majority is in actual

fact an attack upon Bitcoin as a whole.

Can you outline how a minority of hash rate can attack a majority? Usersare free to follow tighter rules than before, or they may reject it. Themajority of hash rate can continue the old rules or not. Where is theattack? I see a disagreement being resolved peacefully through unilateralseparation.

If this were possible then next year weâd see governments try to push

through changes in the same UASF way. Iâm very happy that UASFs canât workbecause that would be the end of Bitcoin's freedom and decentralized nature.

Governments would be much more equipped to simply go directly to the minersto enforce this for them - why even bother with millions of distributedminers when you can knock on a few doors and get your policy?

If the majority of the users are hostile and reject blocks that the miners

create, or change the POW, then what the miners bring to the table is alsoremoved.

I don't understand how users can be hostile to Bitcoin. Users areBitcoin. Everyone else serves the users. All participants are voluntaryand can choose to participate or not. Where is the attack or hostility?

-Alphonse

On Tue, Mar 7, 2017 at 3:17 AM, Tom Zander via bitcoin-dev <

Post by Gareth Williams via bitcoin-devWhat you're describing is a hashpower activated soft fork to censortransactions, in response to a user activated soft fork that the majorityof hashpower disagrees with.

It is incorrect to say that censoring of transactions is what Edmundsuggested. It's purely about the form they take, you can re-send thetransaction in a different form with the same content and they go through.Hence, not transaction censoring.I do believe the point that Edmund brought up is a very good one, the ideathat a set of users can force the miners to do something is rather silly andthe setup that a minority miner fraction can force the majority to dosomething is equally silly. This is because the majority mining hashpowercan fight back against this attack upon them.Donât be mistaken; a hash-minority attacking the hash-majority is in actualfact an attack upon Bitcoin as a whole.If this were possible then next year weâd see governments try to pushthrough changes in the same UASF way. Iâm very happy that UASFs canât workbecause that would be the end of Bitcoin's freedom and decentralized nature.

Post by Gareth Williams via bitcoin-devIt is always possible for a majority of hashpower to censor transactionsthey disagree with. Users may view that as an attack, and can alwaysrespond with a POW hard fork.

I definitely welcome that approach.The result would be that you have two chains, but also you ensure that thechain that the miners didnât like will no longer be something they canmine.Not even the minority set of miners that like the softfork can mine on it.This is a win-win and then the market will decide which one will "win".

This goes both ways, miners both generate value (in the form of security)and they take value (in the form of inflation).If the majority of the users are hostile and reject blocks that the minerscreate, or change the POW, then what the miners bring to the table is alsoremoved.Bitcoin would lose the security and in the short term even the ability tomine blocks every 10 minutes.So, lets correct your statement a little;Â«Bitcoin only works when the majority of the hashpower and the (economic)majority of the users are balanced in power and have their goalsaligned.Â»--Tom ZanderBlog: https://zander.github.ioVlog: https://vimeo.com/channels/tomscryptochannel_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Thank you all for the insightful feedback, on list, in private and on various social media platforms. I have extended the generalized proposal which extends BIP9. This basically introduces an extra workflow state if activationtime > starttime and < timeout - 1 month. It allows extra business logic to be added, such as requiring mandatory signalling.

Please find the draft here:

https://gist.github.com/shaolinfry/70d0582db7de958b7d5b6422cfef4e22

<pre> BIP: bip-uaversionbits-strong Title: Version bits extension with mandatory activation Author: Shaolin Fry <***@protonmail.ch> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-???? Status: Draft Type: Informational Created: 2017-03-09 License: BSD-3-Clause CC0-1.0 </pre> ==Abstract== This document specifies an extension to BIP9 that introduces an additional activation parameter to deploy backward-compatible changes (further called "soft forks") to be activated by a deadline. ==Motivation== BIP9 introduced a mechanism for doing parallel soft forking deployments based on repurposing the block nVersion field. Activation is dependent on near unanimous hashrate signalling which may be impractical and is also subject to veto by a small minority of non-signalling hashrate. This specification provides an way for full nodes to coordinate syncronized activation based on a median past time using the BIP9 state machine. Hashrate may optionally trigger activation before the user defined activation sequence triggers. ==Specification== This specification adds a new per-chain deployment parameter to the existing BIP9 specification as follows: # The '''activationtime''' specifies a minimum median time past of a block at which the deployment should transition to the locked-in state. This specification adds a new workflow state, '''PRE_LOCK_IN''' to the BIP9 state machine if the deployment '''activationtime''' is greater than zero when the workflow will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' -> '''LOCKED_IN''' -> '''ACTIVE'''. The '''PRE_LOCK_IN''' phase allows optional per deployment processing, e.g. mandatory signalling. ===Selection guidelines=== The following guidelines are suggested for selecting these parameters for a soft fork: # '''activationtime''' should be set to some date in the future and must be less than the BIP9 '''timeout'''. It is recommended to have an activation time of 1 year minus 30 days (28944000 seconds). The '''activationtime''' cannot be less than 30 days before the '''timeout'''. ===State transitions=== The state transition workflow is exactly the same as in BIP9 except when '''activationtime''' is greater than zero. Then the workflow will be '''DEFINED''' -> '''STARTED''' -> '''PRE_LOCK_IN''' -> '''LOCKED_IN''' -> '''ACTIVE'''. When in the STARTED state if the median time past is greater than or equal to the '''activationtime''' then the state will transition to PRE_LOCK_IN on the next retarget after '''activationtime'''. case STARTED: // Transition to THRESHOLD_PRE_LOCK_IN if mandatory activation is set if ((nActivationTime != 0) && pindexPrev->GetMedianTimePast() >= nActivationTime) { stateNext = THRESHOLD_PRE_LOCK_IN; break; } // BIP9 specification follows if (GetMedianTimePast(block.parent) >= timeout) { return FAILED; } int count = 0; walk = block; for (i = 0; i < 2016; i++) { walk = walk.parent; if (walk.nVersion & 0xE0000000 == 0x20000000 && (walk.nVersion >> bit) & 1 == 1) { count++; } } if (count >= threshold) { return LOCKED_IN; } return STARTED; === Reference implementation === https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:bip-uaversionbits-strong ==== Optional mandatory signalling ==== <pre> /** * Return true if nVersion BIP9 deployment is signalling during * mandatory periods. */ bool IsMandatorySignalling(int32_t nVersion, Consensus::DeploymentPos pos, const CBlockIndex* pindexPrev, const Consensus::Params& params) { // Check the deployment is in the correct state for this check to apply. if (!((VersionBitsState(pindexPrev, params, pos, versionbitscache) == THRESHOLD_PRE_LOCK_IN) || (VersionBitsState(pindexPrev, params, pos, versionbitscache) == THRESHOLD_LOCKED_IN))) return true; // return signalling state return (((nVersion & VERSIONBITS_TOP_MASK) == VERSIONBITS_TOP_BITS) && (nVersion & VersionBitsMask(params, pos)) != 0); } // segwit signalling is mandatory during PRE_LOCK_IN and LOCKED_IN phase if (!IsMandatorySignalling(block.nVersion, Consensus::DEPLOYMENT_EXAMPLE, pindexPrev, consensusParams)) return state.Invalid(false, REJECT_OBSOLETE, strprintf("bad-version(0x%08x)", block.nVersion), strprintf("rejected nVersion=0x%08x block, must upgrade", block.nVersion)); </pre> ==Deployments== A living list of deployment proposals can be found [[bip-0009/assignments.mediawiki|here]]. ==Copyright== This document is placed in the public domain.