BIP99: Motivation and deployment of consensus rule changes

[jtimon]

This BIP attempts to classify all possible scenarios for consensus rule changes (soft/hard forks) as well as recommending a deployment path for each of them.

It also contains code proposing a first uncontroversial hardfork that conclusively fixes the timewarp attack: bitcoin/bitcoin@0.11...jtimon:hardfork-timewarp-0.11

The recommended activation conditions for uncontroversial hardforks are still being discussed in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

More general discussion about the BIP can still continue in http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html

[kanzure]

When there are two or more simultaneous hard-fork chains, transactions that are intended for only one chain may end up on both chains, especially if the transaction does not have inputs that are tainted by only-one-side coinbase transaction outputs. However, the effects of this may be mitigated if everyone was using some sort of opcode that could restrict the transaction to a blockchain where the history included some particular blockhash.... but then there's a payment coordination problem, you'd probably have to update BIP70 to include this feature, etc. What a mess.

[squidicuzz]

An potential attack vector scenario regarding Schism hardforks:

If a fork is contested when activated and both resulting chains continue; impassioned and nefarious users may utilize their funds on the chain they oppose to flood the network with spam transactions. Attackers could also use funds on both chains to double their attack power. Since both chains should see these transactions and user passions may be high, this has the possibly of resulting in a significant spam attack.

I am not sure how to handle something like this.

[jwilkins]

It would really help if BIPs related to the current blocksize debate were available in the repo, not just in pull requests. Any chance this and the others can get merged soon?

[jtimon]

Jonathan, I'm not sure why that's important: people can just PR to
https://github.com/jtimon/bips/tree/bip-forks in the meantime.

squidicuz sounds like a sensible thing to add to the text (I wonder
where you get that idea from...). an you directly propose changes to
the text by PRing to https://github.com/jtimon/bips/tree/bip-forks ?

On Sun, Aug 23, 2015 at 1:47 AM, Jonathan Wilkins
notifications@github.com wrote:

It would really help if BIPs related to the current blocksize debate were
available in the repo, not just in pull requests. Any chance this and the
others can get merged soon?

—
Reply to this email directly or view it on GitHub.

[kanzure]

nitpick: "soft-fork" not "softfork". Same comment for hard-fork vs hardfork.

[gmaxwell]

Is this waiting for something for a merge?

[luke-jr]

IMO this BIP should actually be Process type, since it defines rules for other BIPs to use?

[luke-jr]

@andychase BIP drafts are not rejected. Merging is a given with approval from the author.

[luke-jr]

Oh, and don't forget to update README.mediawiki!

[andychase]

@luke-jr I was referring to merging or rejecting/closing these specifically: jtimon#2 jtimon#1 edit: merged and good to go

[kanzure]

@jtimon, I was talking with Rusty and he mentioned that all soft-forks are actually hard-forks for miners. Perhaps wording to this effect should be included in the soft-fork/hard-fork distinctions.

[luke-jr]

@jtimon Please add a copyright section, and address @kanzure 's comments (or say you do not intend to make further changes, so I know to merge without them).

[gavinandresen]

I strongly disagree with "there will likely."

There are incredibly strong incentives for people to come to consensus; if they don't, they will lose money (via the mechanism I described on the bitcoin-dev mailing list here: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011291.html).

Jorge's response of "if there is demand then people will stick with the minority" is where I take issue: I claim that there will NOT be demand, because ~everybody has a limit to how economically irrational they will be.

We saw this with the "Lets stick with 50 BTC" people around the first bitcoin halving.

Did you run any of this by an economist who has studied markets that require consensus?

[jtimon]

@luke-jr added copyright section. I think this still needs more work, and some parts like the recommended deployment methods need more discussion. We can merge it and leave it as a draft and I open another PR with further changes. Or keep changing this one, whatever is preferred.

@reviewers I'm going to switch from block height (which apparently only a couple of persons ) to the block median time, which shares its main advantages height while not having its "hard to calculate dates" problem. But in addition to the minimum activation median time, I'm going to maintain the 95% versionbits miner upgrade confirmation for uncontroversial hardforks (because if it's truly uncontroversial and we're expecting 100% of the users to upgrade before the minimum time, I think we can safely expect that also 95% of the miners (who are also users) will upgrade at some point).

@kanzure I defined both softforks and hardforks and left the term "unintentional consensus fork" for unintentional consensus forks regardless of them being softforks or hardforks. I hopefully solved the rest of nits.

@gavinandresen

I strongly disagree with "there will likely."

Fine, I will s/there will likely be 2 chains/there will be 2 chains/ and, at the same time, be more strict defining the conditions when a schism hardfork happens. I agree that the schism hardfork section needs more work though.

Jorge's response of "if there is demand then people will stick with the minority" is where I take issue

I never claimed to be able to predict whether "people" would stick to some particular chain or not, I said that if people stick to a chain and there's demand for the block reward in that chain, there will likely be miners to mine, even if it's just to sell it right away. This has been proven with a myriad of altcoins (including some like Freicoin that people assured me "no body would ever mine"). If there's demand, offer will likely appear, this is not specific to this market.

We saw this with the "Lets stick with 50 BTC" people around the first bitcoin halving.

Thank you very much! I didn't remember this.
This is an excellent past example of a schism hardfork. If I remember correctly, the fork only lasted a few blocks that time. But from one observation, we cannot infer that all cases will last that long or even that they will have an end at all.

EDIT: if anybody has any links to the inflatacoin schism hardfork, they're more than welcomed!

[jtimon]

I could have at least squashed and add it to the readme...

[andychase]

Just noticed that this patch no longer includes the changes made by @instagibbs and I. @jtimon did you force push your repository at some point?

Also this still needs clarification on the type in the preamble.

[andychase]

@luke-jr Also what's the process to get this BIP approved? Is it just a simple majority vote among the core devs? BIP-0001 doesn't specify that process.

[jtimon]

@andychase I'll look into it, I merged your changes...
No voting: when I think it's ready I move it from draft (that doesn't mean that the code has to be deployed or that people are forced to use my decinitions or classification though).

[luke-jr]

@andychase BIP 1 provides an overview of BIP status. Core devs are not particularly relevant in any special/unique way. That being said, I don't know how the status would proceed on this particular BIP. Perhaps someone should bring it up at a Bitcoin development meeting after the draft has reached a more-or-less-final state.

[jtimon]

@luke-jr +1 "after the draft has reached a more-or-less-final state".

[jtimon]

@andychase you were right, I forgot to fetch the version with your changes incorporated and I kept working on a local older version. I've opened #237 with those changes and more improvements (specially in the "Schism hardforks" section).