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