From e10c044c78f1f4de679936b18480f1b0e1352124 Mon Sep 17 00:00:00 2001 From: BtcDrak Date: Sun, 3 Apr 2016 17:48:38 +0100 Subject: [PATCH] [0.12] Update release notes --- doc/release-notes.md | 103 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 102 insertions(+), 1 deletion(-) diff --git a/doc/release-notes.md b/doc/release-notes.md index 177bf333bb..070be08d01 100644 --- a/doc/release-notes.md +++ b/doc/release-notes.md @@ -35,7 +35,108 @@ earlier. Notable changes =============== -The p2p alert system is off by default. To turn on, use `-alert` with startup configuration. +First version bits BIP9 softfork deployment +------------------------------------------- + +This release includes a soft fork deployment to enforce [BIP68][], +[BIP112][] and [BIP113][] using the [BIP9][] deployment mechanism. + +The deployment sets the block version number to 0x20000001 between +midnight 1st May 2016 and midnight 1st May 2017 to signal readiness for +deployment. The version number consists of 0x20000000 to indicate version +bits together with setting bit 0 to indicate support for this combined +deployment, shown as "csv" in the `getblockchaininfo` RPC call. + +For more information about the soft forking change, please see + + +This specific backport pull-request can be viewed at + + +[BIP9]: https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki +[BIP68]: https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki +[BIP112]: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki + +BIP68 soft fork to enforce sequence locks for relative locktime +--------------------------------------------------------------- + +[BIP68][] introduces relative lock-time consensus-enforced semantics of +the sequence number field to enable a signed transaction input to remain +invalid for a defined period of time after confirmation of its corresponding +outpoint. + +For more information about the implementation, see + + +BIP112 soft fork to enforce OP_CHECKSEQUENCEVERIFY +-------------------------------------------------- + +[BIP112][] redefines the existing OP_NOP3 as OP_CHECKSEQUENCEVERIFY (CSV) +for a new opcode in the Bitcoin scripting system that in combination with +[BIP68][] allows execution pathways of a script to be restricted based +on the age of the output being spent. + +For more information about the implementation, see + + +BIP113 locktime enforcement soft fork +------------------------------------- + +Bitcoin Core 0.11.2 previously introduced mempool-only locktime +enforcement using GetMedianTimePast(). This release seeks to +consensus enforce the rule. + +Bitcoin transactions currently may specify a locktime indicating when +they may be added to a valid block. Current consensus rules require +that blocks have a block header time greater than the locktime specified +in any transaction in that block. + +Miners get to choose what time they use for their header time, with the +consensus rule being that no node will accept a block whose time is more +than two hours in the future. This creates a incentive for miners to +set their header times to future values in order to include locktimed +transactions which weren't supposed to be included for up to two more +hours. + +The consensus rules also specify that valid blocks may have a header +time greater than that of the median of the 11 previous blocks. This +GetMedianTimePast() time has a key feature we generally associate with +time: it can't go backwards. + +[BIP113][] specifies a soft fork enforced in this release that +weakens this perverse incentive for individual miners to use a future +time by requiring that valid blocks have a computed GetMedianTimePast() +greater than the locktime specified in any transaction in that block. + +Mempool inclusion rules currently require transactions to be valid for +immediate inclusion in a block in order to be accepted into the mempool. +This release begins applying the BIP113 rule to received transactions, +so transaction whose time is greater than the GetMedianTimePast() will +no longer be accepted into the mempool. + +**Implication for miners:** you will begin rejecting transactions that +would not be valid under BIP113, which will prevent you from producing +invalid blocks when BIP113 is enforced on the network. Any +transactions which are valid under the current rules but not yet valid +under the BIP113 rules will either be mined by other miners or delayed +until they are valid under BIP113. Note, however, that time-based +locktime transactions are more or less unseen on the network currently. + +**Implication for users:** GetMedianTimePast() always trails behind the +current time, so a transaction locktime set to the present time will be +rejected by nodes running this release until the median time moves +forward. To compensate, subtract one hour (3,600 seconds) from your +locktimes to allow those transactions to be included in mempools at +approximately the expected time. + +For more information about the implementation, see + + +Miscellaneous +------------- + +The p2p alert system is off by default. To turn on, use `-alert` with +startup configuration. 0.12.1 Change log =================