public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Moving towards user activated soft fork activation
@ 2017-02-25 23:55 shaolinfry
  2017-02-26 17:34 ` Jameson Lopp
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: shaolinfry @ 2017-02-25 23:55 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 7501 bytes --]

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

References:

[1]: https://bitcoin.org/en/alert/2015-07-04-spv-mining
[2]: http://p2sh.info/dashboard/db/p2sh-statistics?from=1472043312917&to=1488030912918

[-- Attachment #2: Type: text/html, Size: 8319 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread

• * Re: [bitcoin-dev] Moving towards user activated soft fork activation
    2017-02-25 23:55 [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry
  @ 2017-02-26 17:34 ` Jameson Lopp
    2017-02-27 16:02   ` shaolinfry
    2017-02-28 21:20 ` Luke Dashjr
    2017-03-12 15:47 ` shaolinfry
    2 siblings, 1 reply; 18+ messages in thread
  From: Jameson Lopp @ 2017-02-26 17:34 UTC (permalink / raw)
    To: shaolinfry, Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 9967 bytes --]
  
  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.
  
  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...
  
  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?
  
  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.
  
  - Jameson
  
  On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <
  bitcoin-dev@lists•linuxfoundation.org> wrote:
  
  > 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
  >
  > References:
  >
  > [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 list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  >
  >
  
  [-- Attachment #2: Type: text/html, Size: 11385 bytes --]
  
  ^ permalink raw reply	[flat|nested] 18+ messages in thread

• • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
      2017-02-26 17:34 ` Jameson Lopp
    @ 2017-02-27 16:02   ` shaolinfry
      2017-02-27 16:50     ` Eric Voskuil
      0 siblings, 1 reply; 18+ messages in thread
    From: shaolinfry @ 2017-02-27 16:02 UTC (permalink / raw)
      To: Jameson Lopp; +Cc: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 13591 bytes --]
    
    Dear Jameson,
    
    Thank you for your questions. Answers inline below:
    
    Jameson Lopp via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    
    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.
    
    
    
    - Jameson
    
    
    
    On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    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
    
    References:
    
    [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 list
    bitcoin-dev@lists•linuxfoundation.org
    https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    
    [-- Attachment #2: Type: text/html, Size: 16148 bytes --]
    
    ^ permalink raw reply	[flat|nested] 18+ messages in thread

  • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
        2017-02-27 16:02   ` shaolinfry
      @ 2017-02-27 16:50     ` Eric Voskuil
        0 siblings, 0 replies; 18+ messages in thread
      From: Eric Voskuil @ 2017-02-27 16:50 UTC (permalink / raw)
        To: shaolinfry, Bitcoin Protocol Discussion
      
      On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      >> 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.
      
      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.
      
      e
      
      ^ permalink raw reply	[flat|nested] 18+ messages in thread

• * Re: [bitcoin-dev] Moving towards user activated soft fork activation
    2017-02-25 23:55 [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry
    2017-02-26 17:34 ` Jameson Lopp
  @ 2017-02-28 21:20 ` Luke Dashjr
    2017-03-12 15:47 ` shaolinfry
    2 siblings, 0 replies; 18+ messages in thread
  From: Luke Dashjr @ 2017-02-28 21:20 UTC (permalink / raw)
    To: shaolinfry, Bitcoin Protocol Discussion
  
  Without at least a majority hashrate validating blocks, it is possible just a 
  single invalid block could split the chain such that the majority continue 
  building 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 be 
  to follow the chain with the most-work that was valid under the pre-softfork 
  rules. 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 had 
  been a hardfork, IF someone ever mines a single malicious block.
  
  For this reason, I think a minority-hashrate softfork requires a much higher 
  degree of social support than merely the widespread agreement typical of 
  softforks. It might perhaps require less than the full ~100% consensus 
  hardforks require, but it likely comes somewhat close.
  
  Once it gets over 50% hashrate enforcement, however, the situation improves a 
  lot more: a malicious block may split obsolete miners off the valid chain, but 
  it will eventually resolve on its own given enough time. Due to natural 
  fluctuations in block finding, however, automatic measurement may need to look 
  for >75%.
  
  So I would suggest that instead of a simple flag day activation, this proposal 
  would be improved by changing the flag day to merely reduce the hashrate 
  requirement from 95% to 75%.
  
  (In addition to the above concerns, if >50% of miners are hostile to the 
  network, we likely have other problems.)
  
  Luke
  
  
  ^ permalink raw reply	[flat|nested] 18+ messages in thread

• * Re: [bitcoin-dev] Moving towards user activated soft fork activation
    2017-02-25 23:55 [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry
    2017-02-26 17:34 ` Jameson Lopp
    2017-02-28 21:20 ` Luke Dashjr
  @ 2017-03-12 15:47 ` shaolinfry
    2 siblings, 0 replies; 18+ messages in thread
  From: shaolinfry @ 2017-03-12 15:47 UTC (permalink / raw)
    To: Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 4889 bytes --]
  
  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 <shaolinfry@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.
  
  [-- Attachment #2: Type: text/html, Size: 9716 bytes --]
  
  ^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [bitcoin-dev] Moving towards user activated soft fork activation
@ 2017-03-05 14:33 Chris Belcher
  2017-03-05 18:10 ` David Vorick
  0 siblings, 1 reply; 18+ messages in thread
From: Chris Belcher @ 2017-03-05 14:33 UTC (permalink / raw)
  To: bitcoin-dev, shaolinfry

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

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

In a fork between segwit-invalid and segwit-valid after a UASF, if the
segwit-valid chain ever ends up with more work then the segwit-invalid
chain will be annihilated in a big re-organization as
non-segwit-enforcing nodes move to the segwit-valid chain. The less-work
chain 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 by
default.

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


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

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

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

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

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

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

Of course as the old saying goes markets can stay irrational longer than
we can stay solvent, which is why I think UASF should only go ahead if
we'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 very
low and make the annihilating re-organization happen faster.
User-activated means it _must_ be done by the users of bitcoin.



^ permalink raw reply	[flat|nested] 18+ messages in thread

• * Re: [bitcoin-dev] Moving towards user activated soft fork activation
    2017-03-05 14:33 Chris Belcher
  @ 2017-03-05 18:10 ` David Vorick
    2017-03-05 18:48   ` Eric Voskuil
    2017-03-05 21:31   ` Nick ODell
    0 siblings, 2 replies; 18+ messages in thread
  From: David Vorick @ 2017-03-05 18:10 UTC (permalink / raw)
    To: Bitcoin Dev, Chris Belcher
  
  [-- Attachment #1: Type: text/plain, Size: 2149 bytes --]
  
  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.
  
  [-- Attachment #2: Type: text/html, Size: 3323 bytes --]
  
  ^ permalink raw reply	[flat|nested] 18+ messages in thread

• • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
      2017-03-05 18:10 ` David Vorick
    @ 2017-03-05 18:48   ` Eric Voskuil
      2017-03-05 21:31   ` Nick ODell
      1 sibling, 0 replies; 18+ messages in thread
    From: Eric Voskuil @ 2017-03-05 18:48 UTC (permalink / raw)
      To: David Vorick, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 3623 bytes --]
    
    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
    
    > On Mar 5, 2017, at 10:10 AM, David Vorick via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
    > 
    > 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 list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    
    [-- Attachment #2: Type: text/html, Size: 5355 bytes --]
    
    ^ permalink raw reply	[flat|nested] 18+ messages in thread

  • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
      2017-03-05 18:10 ` David Vorick
      2017-03-05 18:48   ` Eric Voskuil
    @ 2017-03-05 21:31   ` Nick ODell
      2017-03-06  9:18     ` David Vorick
      1 sibling, 1 reply; 18+ messages in thread
    From: Nick ODell @ 2017-03-05 21:31 UTC (permalink / raw)
      To: David Vorick, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 5212 bytes --]
    
    >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).
    
    I don't think that's true. Say there are two forks of Blahcoin. Alice
    thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
    55% chance that Fork B will succeed. Alice trades all of her Fork B coins
    for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
    fork or the other succeeding. Alice starts spending more time around Fork A
    users; Bob starts spending his time with Fork B users.
    
    A year passes, and Alice and Bob meet again. Bob tells Alice that Fork B
    has been doing much better than Fork A, and is trading at ten times the
    price. Alice replies that it doesn't matter, since Fork B will soon split
    into B1 and B2. After all, if Fork B surrendered its principles once, it
    can do so again. Bob replies that Fork B represents the true spirit of
    Blahcoin. Alice replies that all of the people whose opinion she respects
    believe that Fork B violates principles set down by the Founder (peace be
    upon 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 Fork
    happens, 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 is
    committing the bandwagon fallacy; even if a thousand people believe that
    red is green, that does not make it true. Also, the collection takes
    several of the Founder's comments out of context. If one looks at comments
    made prior to the release of Blahcoin, they lay out a framework that
    envisions Fork A. Bob replies that Alice can't use statements made prior to
    the release of Blahcoin to establish original intent; the system hadn't
    been designed yet.
    
    Bob points out that Fork B has a higher total chainwork. Alice scoffs. She
    posits a Fork C, which is exactly like Fork A, except that chainwork is
    defined to be the previous definition plus a quadrillion. Bob finds that
    ridiculous. 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 sincerely
    believes in the rightness of their position. Is there some objective
    measure, that both Alice and Bob can agree on, that resolves this? I don't
    think there is. Bob and Alice will sneer at each other for being idiots
    forever. The schism will never resolve.
    
    Satoshi Bless,
    --Nick
    
    On Sun, Mar 5, 2017 at 11:10 AM, David Vorick via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > 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 list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    >
    
    [-- Attachment #2: Type: text/html, Size: 7060 bytes --]
    
    ^ permalink raw reply	[flat|nested] 18+ messages in thread

  • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
        2017-03-05 21:31   ` Nick ODell
      @ 2017-03-06  9:18     ` David Vorick
        2017-03-06 10:29       ` Edmund Edgar
        0 siblings, 1 reply; 18+ messages in thread
      From: David Vorick @ 2017-03-06  9:18 UTC (permalink / raw)
        To: Nick ODell; +Cc: Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 2860 bytes --]
      
      On Mar 5, 2017 6:48 PM, "Eric Voskuil" <eric@voskuil•org> wrote:
      
      
      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
      
      
      There is no doubt that politics play a big role in all of this. Also no
      doubt that broader decentralization would be superior. But miner activated
      soft forks and user activated soft forks do not need discussions with
      centralized parties to move forward. It is merely two different methods for
      pushing 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 'economically
      forced soft forks' are a tool to use if the miners are in clear opposition
      to the broader economy. They only work if the broader economy actually
      fully supports the soft fork, which is much more difficult to measure than
      miner support. And miners with deeper pockets may be able to resist for
      some time, effectively performing a rewardless 51% attack and maintaining a
      split network for some time. The miners would lose lots of money, but old
      nodes would feel all the burn of a hard fork, followed by a sudden deep
      reorg when the network finally 'heals'.
      
      I guess in some sense you'd be playing chicken with the miners. If the
      split is not instantly successful there would be a lot of damage to old
      nodes, even if the majority of new nodes had upgraded. (but there would
      also be a lot of damage to the miners).
      
      On Mar 5, 2017 9:31 PM, "Nick ODell" <nickodell@gmail•com> wrote:
      
      >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).
      
      I don't think that's true. Say there are two forks of Blahcoin. Alice
      thinks there's a 55% chance that Fork A will succeed. Bob thinks there's a
      55% chance that Fork B will succeed. Alice trades all of her Fork B coins
      for all of Bob's Fork A coins. Now, Bob and Alice both have a stake in one
      fork or the other succeeding. Alice starts spending more time around Fork A
      users; Bob starts spending his time with Fork B users.
      
      
      This is not relevant to a UASF. The existing nodes on the network have a
      single formal definition for longest chain. If the UASF is successful, the
      old 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 split
      or network fork.
      
      [-- Attachment #2: Type: text/html, Size: 4099 bytes --]
      
      ^ permalink raw reply	[flat|nested] 18+ messages in thread

    • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
          2017-03-06  9:18     ` David Vorick
        @ 2017-03-06 10:29       ` Edmund Edgar
          2017-03-06 23:23         ` Gareth Williams
          0 siblings, 1 reply; 18+ messages in thread
        From: Edmund Edgar @ 2017-03-06 10:29 UTC (permalink / raw)
          To: Bitcoin Protocol Discussion
        
        On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
        <bitcoin-dev@lists•linuxfoundation.org> wrote:
        > User activated soft forks, or perhaps more accurately called 'economically
        > forced soft forks' are a tool to use if the miners are in clear opposition
        > to 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 by
        orphaning the whole class of non-standard transactions that are the
        subject of the fork. In the SegWit case, they'd just orphan anything
        that looks like a SegWit transaction, valid or not. That way they
        don't need to worry about ending up on the wrong side of the upgrade,
        because no transaction affected by the proposed rule change will ever
        get into the longest chain. Rational node operators (particularly
        exchanges) will likely also adopt their stricter rule change, since
        they know any chain that breaks it will end up being orphaned, so you
        don't want to act on a payment that you see confirmed in it. So then
        you're back where you started, except that your soft-fork is now a
        de-facto hard-fork, because you have to undo the new, stricter rule
        that the miners introduced to head off your shenannigans.
        
        Where they're interesting is where you can do something meaningful by
        forcing some transactions through on a once-off basis. For example, if
        the Chinese government identified an address belonging to Uighur
        separatists and leaned on Chinese miners to prevent anything from that
        address confirming, it might be interesting for users to say, "If
        these utxos are not spent by block X, your block is invalid".
        
        They might also be interesting for feature upgrades in a world where
        mining is radically decentralized and upgrades are fighting against
        inertia rather than opposition, but sadly that's not the world we
        currently live in.
        
        -- 
        -- 
        Edmund Edgar
        Founder, Social Minds Inc (KK)
        Twitter: @edmundedgar
        Linked In: edmundedgar
        Skype: edmundedgar
        http://www.socialminds.jp
        
        Reality Keys
        @realitykeys
        support@realitykeys•com
        https://www.realitykeys.com
        
        
        ^ permalink raw reply	[flat|nested] 18+ messages in thread

      • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
            2017-03-06 10:29       ` Edmund Edgar
          @ 2017-03-06 23:23         ` Gareth Williams
            2017-03-07  1:07           ` Edmund Edgar
            2017-03-07  9:17           ` Tom Zander
            0 siblings, 2 replies; 18+ messages in thread
          From: Gareth Williams @ 2017-03-06 23:23 UTC (permalink / raw)
            To: Edmund Edgar, Bitcoin Protocol Discussion
          
          What 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.
          
          It is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an attack, and can always respond with a POW hard fork. 
          
          Bitcoin only works if the majority of hashpower is not hostile to the users.
          
          
          On 6 March 2017 9:29:35 PM AEDT, Edmund Edgar via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
          >On 6 March 2017 at 18:18, David Vorick via bitcoin-dev
          ><bitcoin-dev@lists•linuxfoundation.org> wrote:
          >> User activated soft forks, or perhaps more accurately called
          >'economically
          >> forced soft forks' are a tool to use if the miners are in clear
          >opposition
          >> to 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 by
          >orphaning the whole class of non-standard transactions that are the
          >subject of the fork. In the SegWit case, they'd just orphan anything
          >that looks like a SegWit transaction, valid or not. That way they
          >don't need to worry about ending up on the wrong side of the upgrade,
          >because no transaction affected by the proposed rule change will ever
          >get into the longest chain. Rational node operators (particularly
          >exchanges) will likely also adopt their stricter rule change, since
          >they know any chain that breaks it will end up being orphaned, so you
          >don't want to act on a payment that you see confirmed in it. So then
          >you're back where you started, except that your soft-fork is now a
          >de-facto hard-fork, because you have to undo the new, stricter rule
          >that the miners introduced to head off your shenannigans.
          >
          >Where they're interesting is where you can do something meaningful by
          >forcing some transactions through on a once-off basis. For example, if
          >the Chinese government identified an address belonging to Uighur
          >separatists and leaned on Chinese miners to prevent anything from that
          >address confirming, it might be interesting for users to say, "If
          >these utxos are not spent by block X, your block is invalid".
          >
          >They might also be interesting for feature upgrades in a world where
          >mining is radically decentralized and upgrades are fighting against
          >inertia rather than opposition, but sadly that's not the world we
          >currently live in.
          
          
          
          ^ permalink raw reply	[flat|nested] 18+ messages in thread

        • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
              2017-03-06 23:23         ` Gareth Williams
            @ 2017-03-07  1:07           ` Edmund Edgar
              2017-03-07 17:37             ` Eric Voskuil
              2017-03-07  9:17           ` Tom Zander
              1 sibling, 1 reply; 18+ messages in thread
            From: Edmund Edgar @ 2017-03-07  1:07 UTC (permalink / raw)
              To: Bitcoin Protocol Discussion
            
            On 7 March 2017 at 08:23, Gareth Williams <gjw@posteo•net> wrote:
            > What 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 from
            activating in the first place. (As opposed to censoring a subset of
            those transactions to enforce the new rule, which is the behaviour
            that the people promoting the change want.) There would be no point at
            which people reasonably expected that something useful would happen if
            they sent funds to an address protected by the new scripting rule.
            
            > Bitcoin only works if the majority of hashpower is not hostile to the users.
            
            This is true. But what we're talking about here is hostility to *a
            particular proposal to change the network rules* which is (in this
            hypothetical case) supported by the economic majority of users. This
            doesn't, in itself, break Bitcoin, although the economic majority are
            of course always free to hard-fork to something new if they're
            unhappy.
            
            Edmund
            
            -- 
            -- 
            Edmund Edgar
            Founder, Social Minds Inc (KK)
            Twitter: @edmundedgar
            Linked In: edmundedgar
            Skype: edmundedgar
            http://www.socialminds.jp
            
            Reality Keys
            @realitykeys
            ed@realitykeys•com
            https://www.realitykeys.com
            
            
            ^ permalink raw reply	[flat|nested] 18+ messages in thread

          • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
                2017-03-07  1:07           ` Edmund Edgar
              @ 2017-03-07 17:37             ` Eric Voskuil
                0 siblings, 0 replies; 18+ messages in thread
              From: Eric Voskuil @ 2017-03-07 17:37 UTC (permalink / raw)
                To: bitcoin-dev, Libbitcoin Development
              
              [-- Attachment #1: Type: text/plain, Size: 2850 bytes --]
              
              On 03/06/2017 05:07 PM, Edmund Edgar via bitcoin-dev wrote:
              > On 7 March 2017 at 08:23, Gareth Williams <gjw@posteo•net> wrote:
              >> What 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.
              
              This definition of censorship would apply to all validation.
              
              A miner is free to select whatever transactions he wants, for whatever
              reasons he wants. Bitcoin's defense against censorship (and disruption)
              is in the broad distribution of over 50% (anecdotally) of the hash power
              among a large number of people.
              
              > Well, they'd be censoring transactions to prevent the thing from
              > activating in the first place. (As opposed to censoring a subset of
              > those transactions to enforce the new rule, which is the behaviour
              > that the people promoting the change want.)
              
              Exactly, a soft fork expects that people start rejecting a previously
              valid style of transaction, or that they ignore it. It's perfectly
              reasonable to conclude that some miners may continue to accept the
              soft-fork-invalidated transactions and instead reject the new style of
              transactions as invalid. Reliance on their acceptance of the soft fork
              is based on the weak assumption that they won't change their software or
              that they live in fear of a retaliatory POW change.
              
              >> Bitcoin only works if the majority of hashpower is not hostile to the
              users.
              
              Honesty in this context refers to double spending. Selecting a different
              rule set effectively moves one to another coin, which is not dishonest
              (hostile to anyone).  Miners have zero technical or ethical obligation
              to follow any particular set of rules. Bitcoin has one golden rule, run
              whatever code you want. Security is based on decentralization, not
              well-behaved people (or well-behaved software).
              
              > This is true. But what we're talking about here is hostility to *a
              > particular proposal to change the network rules* which is (in this
              > hypothetical case) supported by the economic majority of users. This
              > doesn't, in itself, break Bitcoin, although the economic majority are
              > of course always free to hard-fork to something new if they're
              > unhappy.
              
              Again spot on. Users of the money purchase security from miners. Miners
              are under no obligation to provide that service nor are users under any
              obligation to purchase it.
              
              One thing to consider is how different the landscape would look if every
              person on the planet was a miner, and the economy was similarly
              distributed. Would it be easier to get 51% hash power on board with a
              soft fork, or some much higher percentage on board with a hard fork? It
              seems likely that any proposed material change would fail. Regardless of
              how one feels about that, it is the nature of a sound money that it
              doesn't change.
              
              e
              
              
              [-- Attachment #2: OpenPGP digital signature --]
              [-- Type: application/pgp-signature, Size: 490 bytes --]
              
              ^ permalink raw reply	[flat|nested] 18+ messages in thread

          • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
              2017-03-06 23:23         ` Gareth Williams
              2017-03-07  1:07           ` Edmund Edgar
            @ 2017-03-07  9:17           ` Tom Zander
              2017-03-07 18:13             ` Eric Voskuil
              2017-03-07 19:13             ` Alphonse Pace
              1 sibling, 2 replies; 18+ messages in thread
            From: Tom Zander @ 2017-03-07  9:17 UTC (permalink / raw)
              To: bitcoin-dev, Gareth Williams
            
            On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
            > What 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.
            
            It is incorrect to say that censoring of transactions is what Edmund 
            suggested. It's purely about the form they take, you can re-send the 
            transaction 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 idea 
            that a set of users can force the miners to do something is rather silly and 
            the setup that a minority miner fraction can force the majority to do 
            something is equally silly. This is because the majority mining hashpower 
            can fight back against this attack upon them.
            
            Don’t be mistaken; a hash-minority attacking the hash-majority is in actual 
            fact an attack upon Bitcoin as a whole.
            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 work 
            because that would be the end of Bitcoin's freedom and decentralized nature.
            
            > It is always possible for a majority of hashpower to censor transactions
            > they disagree with. Users may view that as an attack, and can always
            > respond with a POW hard fork.
            
            I definitely welcome that approach.
            
            The result would be that you have two chains, but also you ensure that the 
            chain 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".
             
            > Bitcoin only works if the majority of hashpower is not hostile to the
            > users.
            
            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 miners 
            create, or change the POW, then what the miners bring to the table is also 
            removed.
            Bitcoin would lose the security and in the short term even the ability to 
            mine 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 Zander
            Blog: https://zander.github.io
            Vlog: https://vimeo.com/channels/tomscryptochannel
            
            
            ^ permalink raw reply	[flat|nested] 18+ messages in thread

          • • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
                2017-03-07  9:17           ` Tom Zander
              @ 2017-03-07 18:13             ` Eric Voskuil
                2017-03-07 19:13             ` Alphonse Pace
                1 sibling, 0 replies; 18+ messages in thread
              From: Eric Voskuil @ 2017-03-07 18:13 UTC (permalink / raw)
                To: Tom Zander, Bitcoin Protocol Discussion
              
              > Bitcoin would lose the security and in the short term even the ability to 
              mine blocks every 10 minutes.
              
              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.
              
              e
              
              > On Mar 7, 2017, at 1:17 AM, Tom Zander via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
              > 
              >> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote:
              >> What 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.
              > 
              > It is incorrect to say that censoring of transactions is what Edmund 
              > suggested. It's purely about the form they take, you can re-send the 
              > transaction 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 idea 
              > that a set of users can force the miners to do something is rather silly and 
              > the setup that a minority miner fraction can force the majority to do 
              > something is equally silly. This is because the majority mining hashpower 
              > can fight back against this attack upon them.
              > 
              > Don’t be mistaken; a hash-minority attacking the hash-majority is in actual 
              > fact an attack upon Bitcoin as a whole.
              > 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 work 
              > because that would be the end of Bitcoin's freedom and decentralized nature.
              > 
              >> It is always possible for a majority of hashpower to censor transactions
              >> they disagree with. Users may view that as an attack, and can always
              >> respond with a POW hard fork.
              > 
              > I definitely welcome that approach.
              > 
              > The result would be that you have two chains, but also you ensure that the 
              > chain 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".
              > 
              >> Bitcoin only works if the majority of hashpower is not hostile to the
              >> users.
              > 
              > 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 miners 
              > create, or change the POW, then what the miners bring to the table is also 
              > removed.
              > Bitcoin would lose the security and in the short term even the ability to 
              > mine 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 Zander
              > Blog: https://zander.github.io
              > Vlog: https://vimeo.com/channels/tomscryptochannel
              > _______________________________________________
              > bitcoin-dev mailing list
              > bitcoin-dev@lists•linuxfoundation.org
              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              
              
              ^ permalink raw reply	[flat|nested] 18+ messages in thread

            • * Re: [bitcoin-dev] Moving towards user activated soft fork activation
                2017-03-07  9:17           ` Tom Zander
                2017-03-07 18:13             ` Eric Voskuil
              @ 2017-03-07 19:13             ` Alphonse Pace
                1 sibling, 0 replies; 18+ messages in thread
              From: Alphonse Pace @ 2017-03-07 19:13 UTC (permalink / raw)
                To: Tom Zander, Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 4517 bytes --]
              
              I fail to see how any non-mining user can attack a miner.  The worst they
              can do is refuse to buy their coinbase transaction.  Do you believe that
              users are obligated to buy coins from miners?  If not, then all miners are
              voluntarily 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? Users
              are free to follow tighter rules than before, or they may reject it.  The
              majority of hash rate can continue the old rules or not.  Where is the
              attack?  I see a disagreement being resolved peacefully through unilateral
              separation.
              
              >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 work
              because that would be the end of Bitcoin's freedom and decentralized nature.
              
              Governments would be much more equipped to simply go directly to the miners
              to enforce this for them - why even bother with millions of distributed
              miners 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 also
              removed.
              
              I don't understand how users can be hostile to Bitcoin.  Users are
              Bitcoin.  Everyone else serves the users.  All participants are voluntary
              and 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 <
              bitcoin-dev@lists•linuxfoundation.org> wrote:
              
              > On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev
              > wrote:
              > > What 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.
              >
              > It is incorrect to say that censoring of transactions is what Edmund
              > suggested. It's purely about the form they take, you can re-send the
              > transaction 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 idea
              > that a set of users can force the miners to do something is rather silly
              > and
              > the setup that a minority miner fraction can force the majority to do
              > something is equally silly. This is because the majority mining hashpower
              > can fight back against this attack upon them.
              >
              > Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
              > fact an attack upon Bitcoin as a whole.
              > 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 work
              > because that would be the end of Bitcoin's freedom and decentralized
              > nature.
              >
              > > It is always possible for a majority of hashpower to censor transactions
              > > they disagree with. Users may view that as an attack, and can always
              > > respond with a POW hard fork.
              >
              > I definitely welcome that approach.
              >
              > The result would be that you have two chains, but also you ensure that the
              > chain 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".
              >
              > > Bitcoin only works if the majority of hashpower is not hostile to the
              > > users.
              >
              > 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 miners
              > create, or change the POW, then what the miners bring to the table is also
              > removed.
              > Bitcoin would lose the security and in the short term even the ability to
              > mine 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 Zander
              > Blog: https://zander.github.io
              > Vlog: https://vimeo.com/channels/tomscryptochannel
              > _______________________________________________
              > bitcoin-dev mailing list
              > bitcoin-dev@lists•linuxfoundation.org
              > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
              >
              
              [-- Attachment #2: Type: text/html, Size: 6475 bytes --]
              
              ^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2017-03-12 15:47 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-02-25 23:55 [bitcoin-dev] Moving towards user activated soft fork activation shaolinfry
2017-02-26 17:34 ` Jameson Lopp
2017-02-27 16:02   ` shaolinfry
2017-02-27 16:50     ` Eric Voskuil
2017-02-28 21:20 ` Luke Dashjr
2017-03-12 15:47 ` shaolinfry
2017-03-05 14:33 Chris Belcher
2017-03-05 18:10 ` David Vorick
2017-03-05 18:48   ` Eric Voskuil
2017-03-05 21:31   ` Nick ODell
2017-03-06  9:18     ` David Vorick
2017-03-06 10:29       ` Edmund Edgar
2017-03-06 23:23         ` Gareth Williams
2017-03-07  1:07           ` Edmund Edgar
2017-03-07 17:37             ` Eric Voskuil
2017-03-07  9:17           ` Tom Zander
2017-03-07 18:13             ` Eric Voskuil
2017-03-07 19:13             ` Alphonse Pace

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox