[bitcoin-dev] [Bitcoin-development] [BIP draft] Motivation and deployment of consensus rules changes ([soft/hard]forks)

Jorge Timón jtimon at jtimon.cc
Fri Jul 31 20:37:43 UTC 2015


On Fri, Jul 31, 2015 at 7:40 PM, Thomas Kerin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I really think there should be a document before a BIP number is assigned.

There was a document from the start, but after I got the BIP number, I
was renaming the file, moving from org-mode to mediawiki and getting
the code ready.
I'm sorry, I broke the old link to the document, here's the new one:
https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki

Maybe I should create a PR already to have a permanent link, I don't know.
As said in the document, the code is now here:
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11

Also, I should mention that one particular discussion related to this
BIP (whether we should use Block.nTime, median time or block.nHeight
for the activation thresholds) is being discussed in:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

The BIP is currently assuming that the preferred choice for all
non-emergency uncontroversial hardforks is defining a starting
block.nHeight after which miners start confirming their upgrade. Once
the 95% threshold is reached the hardfork takes effect.
Long after that, after that first block enforcing the new rules is
deeply buried, that check can simply replaced by re-defining the
threshold height not with the height when miners started voting, but
simply with the height in which the rules started being enforced for
the first time (see https://github.com/bitcoin/bitcoin/pull/5966/files
).


More information about the bitcoin-dev mailing list