[bitcoin-dev] Bitcoin Core 0.11.2 released

[bitcoin-dev] Bitcoin Core 0.11.2 released

[Wladimir J. van der Laan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Bitcoin Core version 0.11.2 is now available from:

  <https://bitcoin.org/bin/bitcoin-core-0.11.2/>

Alternatively, through bittorrent:

    magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b&dn=bitcoin-core-0.11.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F 

This is a new minor version release, bringing bug fixes, the BIP65
(CLTV) consensus change, and relay policy preparation for BIP113. It is
recommended to upgrade to this version as soon as possible.

Please report bugs using the issue tracker at github:

  <https://github.com/bitcoin/bitcoin/issues>

Upgrading and downgrading
=========================

How to Upgrade
- --------------

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the
installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or
bitcoind/bitcoin-qt (on Linux).

Downgrade warning
- ------------------

Because release 0.10.0 and later makes use of headers-first synchronization and
parallel block download (see further), the block files and databases are not
backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

* Blocks will be stored on disk out of order (in the order they are
received, really), which makes it incompatible with some tools or
other programs. Reindexing using earlier versions will also not work
anymore as a result of this.

* The block index database will now hold headers for which no block is
stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data
directory. Without this your node will need start syncing (or importing from
bootstrap.dat) anew afterwards. It is possible that the data from a completely
synchronised 0.10 node may be usable in older versions as-is, but this is not
supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility. There are no
known problems when downgrading from 0.11.x to 0.10.x.

Notable changes since 0.11.1
============================

BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
- --------------------------------------------------------

This release includes several changes related to the [BIP65][] soft fork
which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY
(CLTV) so that a transaction output can be made unspendable until a
specified point in the future.

1. This release will only relay and mine transactions spending a CLTV
   output if they comply with the BIP65 rules as provided in code.

2. This release will produce version 4 blocks by default. Please see the
   *notice to miners* below.

3. Once 951 out of a sequence of 1,001 blocks on the local node's best block
   chain contain version 4 (or higher) blocks, this release will no
   longer accept new version 3 blocks and it will only accept version 4
   blocks if they comply with the BIP65 rules for CLTV.

For more information about the soft-forking change, please see
<https://github.com/bitcoin/bitcoin/pull/6351>

Graphs showing the progress towards block version 4 adoption may be
found at the URLs below:

- - Block versions over the last 50,000 blocks as progress towards BIP65
  consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>

- - Block versions over the last 2,000 blocks showing the days to the
  earliest possible BIP65 consensus-enforced block: <http://bitcoin.sipa.be/ver-2k.png>

**Notice to miners:** Bitcoin Core’s block templates are now for
version 4 blocks only, and any mining software relying on its
getblocktemplate must be updated in parallel to use libblkmaker either
version 0.4.3 or any version from 0.5.2 onward.

- - If you are solo mining, this will affect you the moment you upgrade
  Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
  status.

- - If you are mining with the stratum mining protocol: this does not
  affect you.

- - If you are mining with the getblocktemplate protocol to a pool: this
  will affect you at the pool operator’s discretion, which must be no
  later than BIP65 achieving its 951/1001 status.

[BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

BIP113 mempool-only locktime enforcement using GetMedianTimePast()
- ----------------------------------------------------------------

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 (**not 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 if/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.

[BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki

Windows bug fix for corrupted UTXO database on unclean shutdowns
- ----------------------------------------------------------------

Several Windows users reported that they often need to reindex the
entire blockchain after an unclean shutdown of Bitcoin Core on Windows
(or an unclean shutdown of Windows itself). Although unclean shutdowns
remain unsafe, this release no longer relies on memory-mapped files for
the UTXO database, which significantly reduced the frequency of unclean
shutdowns leading to required reindexes during testing.

For more information, see: <https://github.com/bitcoin/bitcoin/pull/6917>

Other fixes for database corruption on Windows are expected in the
next major release.

0.11.2 Change log
=================

Detailed release notes follow. This overview includes changes that affect
behavior, not code moves, refactors and string updates. For convenience in locating
the code changes and accompanying discussion, both the pull request and
git merge commit are mentioned.

- - #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument
- - #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
- - #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify flag
- - #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
- - #6353 `ba1da90` Show softfork status in getblockchaininfo
- - #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list
- - #6688 `01878c9` Fix locking in GetTransaction
- - #6653 `b3eaa30` [Qt] Raise debug window when requested
- - #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary
- - #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package
- - #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for testnet
- - #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack
- - #6846 `af6edac` alias `-h` for `--help`
- - #6867 `95a5039` Set TCP_NODELAY on P2P sockets.
- - #6856 `dfe55bd` Do not allow blockfile pruning during reindex.
- - #6566 `a1d3c6f` Add rules--presently disabled--for using GetMedianTimePast as end point for lock-time calculations
- - #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end point of lock-time constraints
- - #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping
- - #6948 `4e895b0` Always flush block and undo when switching to new file

Credits
=======

Thanks to everyone who directly contributed to this release:

- - Alex Morcos
- - ฿tcDrak
- - Chris Kleeschulte
- - Daniel Cousens
- - Diego Viola
- - Eric Lombrozo
- - Esteban Ordano
- - Gregory Maxwell
- - Luke Dashjr
- - Marco Falke
- - Mark Friedenbach
- - Matt Corallo
- - Micha
- - Mitchell Cash
- - Peter Todd
- - Pieter Wuille
- - Wladimir J. van der Laan
- - Zak Wilcox

And those who contributed additional code review and/or security research.

As well as everyone that helped translating on [Transifex](https://www.transifex.com/projects/p/bitcoin/).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJWReHOAAoJEHSBCwEjRsmmTAAH/iZQGklLHLIM6a2tTOj4d/O6
xHg5bJhXGjtzO284Uy3phTzvk+e4mqBTjI8BrSr4D+Vw7mJrfWihdTLlgZYCwso3
AyAk8ud1H42QanAfUvciY5uXd7cyzr8tCnCIBkvwJT5O8tI3FFhSMM5Fs86WnsP1
Y10+93sxaVJUave2xm1bmgiwApFZKQ2MNU1IVgFaW8agB59fuqtPRnBdKiK/j+AO
Jn1LKsObsINYhjtkAFiC66mUOBZ2N3rdhbN3LFl+u7EriTLoYk1OtZZhlC+rOueo
nxl1H5SHStjrD27vE9Hv2qD5Ckrwo3zib8hZNIVs6MJjFnWUCwNtNg0nqDEvpn4=
=xXdY
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Bitcoin Core 0.11.2 released

[Dave Scotese]

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

I decided to try to certify Wladimir's PGP keys (the old one (2346C9A6)
first, and then the new one (36C2E964), since it was signed with the old
one).

I visited
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
to see that the new key was referenced in a message signed by the old one.
I figure it's safe to assume that if the old key actually signed that
message, then the core dev using <laanwj at gmail.com
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> is an
actual core dev (that's all I'd be worried about).  So I copied the text
from ------BEGIN PGP SIGNED MESSAGE----- to -----END PGP SIGNATURE----- to
my clipboard and asked Kleopatra (on Windows) to verify it.  It says the
signature is bad.  If I alter the text of the email (so the signature would
be have to be different to be valid), it says exactly the same thing.  So
maybe something is wrong with Kleopatra on Windows.

However, the SHA256SUMS.asc file I got from the magnet link posted in the
email (below)  verifies just fine using the new key (36C2E964).  So I
figure Kleopatra is not broken.  It recognizes that the old key was used to
create the signature in that old email, but it says it's invalid.  Has
Wladimir been secretly replaced by someone who doesn't have access to the
private key for 2346C9A6?  Can you make a (bad) signature look like it was
made using a key you don't have? The whole reason for signing is so that we
will know if something like that happened.  So did I do something wrong?
(I mean, besides using Windows).

I believe this is the expected result if someone took something Wladimir
signed and ripped off the signature and pasted it below this new message to
make everyone think the new message was genuine.  Maybe Wladimir made an
edit after the signature was attached.  Or maybe it got changed when it
went through the email system.  It would be nice to know.  Anyway, I fell
back on Windows security and ran the install because it said it verified
that the publisher was "The Bitcoin Foundation".


On Fri, Nov 13, 2015 at 5:13 AM, Wladimir J. van der Laan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Bitcoin Core version 0.11.2 is now available from:
>
>   <https://bitcoin.org/bin/bitcoin-core-0.11.2/>
>
> Alternatively, through bittorrent:
>
>
> magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b&dn=bitcoin-core-0.11.2&tr=udp%3A%2F%
> 2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%
> 2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de
> %3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk
> %3A6969&tr=udp%3A%2F%2Fopen.demonii.com
> %3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
>
> This is a new minor version release, bringing bug fixes, the BIP65
> (CLTV) consensus change, and relay policy preparation for BIP113. It is
> recommended to upgrade to this version as soon as possible.
>
> Please report bugs using the issue tracker at github:
>
>   <https://github.com/bitcoin/bitcoin/issues>
>
> Upgrading and downgrading
> =========================
>
> How to Upgrade
> - --------------
>
> If you are running an older version, shut it down. Wait until it has
> completely
> shut down (which might take a few minutes for older versions), then run the
> installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
> or
> bitcoind/bitcoin-qt (on Linux).
>
> Downgrade warning
> - ------------------
>
> Because release 0.10.0 and later makes use of headers-first
> synchronization and
> parallel block download (see further), the block files and databases are
> not
> backwards-compatible with pre-0.10 versions of Bitcoin Core or other
> software:
>
> * Blocks will be stored on disk out of order (in the order they are
> received, really), which makes it incompatible with some tools or
> other programs. Reindexing using earlier versions will also not work
> anymore as a result of this.
>
> * The block index database will now hold headers for which no block is
> stored on disk, which earlier versions won't support.
>
> If you want to be able to downgrade smoothly, make a backup of your entire
> data
> directory. Without this your node will need start syncing (or importing
> from
> bootstrap.dat) anew afterwards. It is possible that the data from a
> completely
> synchronised 0.10 node may be usable in older versions as-is, but this is
> not
> supported and may break as soon as the older version attempts to reindex.
>
> This does not affect wallet forward or backward compatibility. There are no
> known problems when downgrading from 0.11.x to 0.10.x.
>
> Notable changes since 0.11.1
> ============================
>
> BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
> - --------------------------------------------------------
>
> This release includes several changes related to the [BIP65][] soft fork
> which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY
> (CLTV) so that a transaction output can be made unspendable until a
> specified point in the future.
>
> 1. This release will only relay and mine transactions spending a CLTV
>    output if they comply with the BIP65 rules as provided in code.
>
> 2. This release will produce version 4 blocks by default. Please see the
>    *notice to miners* below.
>
> 3. Once 951 out of a sequence of 1,001 blocks on the local node's best
> block
>    chain contain version 4 (or higher) blocks, this release will no
>    longer accept new version 3 blocks and it will only accept version 4
>    blocks if they comply with the BIP65 rules for CLTV.
>
> For more information about the soft-forking change, please see
> <https://github.com/bitcoin/bitcoin/pull/6351>
>
> Graphs showing the progress towards block version 4 adoption may be
> found at the URLs below:
>
> - - Block versions over the last 50,000 blocks as progress towards BIP65
>   consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>
>
> - - Block versions over the last 2,000 blocks showing the days to the
>   earliest possible BIP65 consensus-enforced block: <
> http://bitcoin.sipa.be/ver-2k.png>
>
> **Notice to miners:** Bitcoin Core’s block templates are now for
> version 4 blocks only, and any mining software relying on its
> getblocktemplate must be updated in parallel to use libblkmaker either
> version 0.4.3 or any version from 0.5.2 onward.
>
> - - If you are solo mining, this will affect you the moment you upgrade
>   Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
>   status.
>
> - - If you are mining with the stratum mining protocol: this does not
>   affect you.
>
> - - If you are mining with the getblocktemplate protocol to a pool: this
>   will affect you at the pool operator’s discretion, which must be no
>   later than BIP65 achieving its 951/1001 status.
>
> [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
>
> BIP113 mempool-only locktime enforcement using GetMedianTimePast()
> - ----------------------------------------------------------------
>
> 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 (**not 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 if/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.
>
> [BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
>
> Windows bug fix for corrupted UTXO database on unclean shutdowns
> - ----------------------------------------------------------------
>
> Several Windows users reported that they often need to reindex the
> entire blockchain after an unclean shutdown of Bitcoin Core on Windows
> (or an unclean shutdown of Windows itself). Although unclean shutdowns
> remain unsafe, this release no longer relies on memory-mapped files for
> the UTXO database, which significantly reduced the frequency of unclean
> shutdowns leading to required reindexes during testing.
>
> For more information, see: <https://github.com/bitcoin/bitcoin/pull/6917>
>
> Other fixes for database corruption on Windows are expected in the
> next major release.
>
> 0.11.2 Change log
> =================
>
> Detailed release notes follow. This overview includes changes that affect
> behavior, not code moves, refactors and string updates. For convenience in
> locating
> the code changes and accompanying discussion, both the pull request and
> git merge commit are mentioned.
>
> - - #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument
> - - #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
> - - #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify
> flag
> - - #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
> - - #6353 `ba1da90` Show softfork status in getblockchaininfo
> - - #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list
> - - #6688 `01878c9` Fix locking in GetTransaction
> - - #6653 `b3eaa30` [Qt] Raise debug window when requested
> - - #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary
> - - #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package
> - - #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for
> testnet
> - - #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack
> - - #6846 `af6edac` alias `-h` for `--help`
> - - #6867 `95a5039` Set TCP_NODELAY on P2P sockets.
> - - #6856 `dfe55bd` Do not allow blockfile pruning during reindex.
> - - #6566 `a1d3c6f` Add rules--presently disabled--for using
> GetMedianTimePast as end point for lock-time calculations
> - - #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end
> point of lock-time constraints
> - - #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping
> - - #6948 `4e895b0` Always flush block and undo when switching to new file
>
> Credits
> =======
>
> Thanks to everyone who directly contributed to this release:
>
> - - Alex Morcos
> - - ฿tcDrak
> - - Chris Kleeschulte
> - - Daniel Cousens
> - - Diego Viola
> - - Eric Lombrozo
> - - Esteban Ordano
> - - Gregory Maxwell
> - - Luke Dashjr
> - - Marco Falke
> - - Mark Friedenbach
> - - Matt Corallo
> - - Micha
> - - Mitchell Cash
> - - Peter Todd
> - - Pieter Wuille
> - - Wladimir J. van der Laan
> - - Zak Wilcox
>
> And those who contributed additional code review and/or security research.
>
> As well as everyone that helped translating on [Transifex](
> https://www.transifex.com/projects/p/bitcoin/).
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJWReHOAAoJEHSBCwEjRsmmTAAH/iZQGklLHLIM6a2tTOj4d/O6
> xHg5bJhXGjtzO284Uy3phTzvk+e4mqBTjI8BrSr4D+Vw7mJrfWihdTLlgZYCwso3
> AyAk8ud1H42QanAfUvciY5uXd7cyzr8tCnCIBkvwJT5O8tI3FFhSMM5Fs86WnsP1
> Y10+93sxaVJUave2xm1bmgiwApFZKQ2MNU1IVgFaW8agB59fuqtPRnBdKiK/j+AO
> Jn1LKsObsINYhjtkAFiC66mUOBZ2N3rdhbN3LFl+u7EriTLoYk1OtZZhlC+rOueo
> nxl1H5SHStjrD27vE9Hv2qD5Ckrwo3zib8hZNIVs6MJjFnWUCwNtNg0nqDEvpn4=
> =xXdY
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

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

Re: [bitcoin-dev] Bitcoin Core 0.11.2 released

[Matt Corallo]

Heh, though mine doesnt since I mangled the line breaks...that should
have been...

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Strange, the signature validates for me. If I copy the entire mail
(including the signature and PGP armor, but not the ads) I see the hash
of the mail as
b3bbd0fcfcea5f4eb5b49e9c2d7ed7514259f004fbdb5930c92084d6de561238.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWRrNYAAoJEGOJ097IOJ+hTg0P/2H5DRaG1Gd8k72VPT/DiNHP
e8Al19f3FXIaGSiiJ2CC6Tx3d/13U8SOnbqC28vWDpCn6TR+aw7QMoLy2huyivSp
kTuboqtTVgyt2JbwmXQHrxHIHiW70Xa/dP0sfZlQKjI47RO/gBG8ccRuIyEPgVAi
ag7bT74hL7/C1BuEB+wA9E+b8lnCjr/rFjVKp0mSzp1/5qOCnoddUatQU4zNnE6E
WNKj+qGekqDLPzzfMH/VrE9XX0GVaQcFG2cSBSqVOL6WQHj6cqh2z7MXl1aWMkEt
X+GYVIYJw3UUikKKsHPdNqoVRHYAmrg7OVmrYXuL4JDOneJYnihTKj7O2bFy8tBz
eDIBuqjyG8RTvNvouKCYMN89ePt1P53B0zDK9o6aQDUIkT/2a6RAdUUUencrN812
Bc5E2EEbfdEn4wFeAgLAXLZ5KFFGMlEXC8ceswQHzONnXzy6UkK0D9MexvxEZnMm
6s3N1XBbB2Xqw04JfQ6k5r0ywV3yu1JmG0AoPuluA3xZkID2izMuSGQU2Vji/xdH
ByeeRBYMFLeTbVIIi8I5v19ThQ+j7MR7VK8A8tt3GIjNSL3grNABOlRPb7mDDIyB
oMnc48XBaRn3Rsdn3wwbmhvRGF2A5fDZ+APldVy89TNgtUXPMTlholCzY9ekiniA
lVAHrXea2CpzbH6In7GK
=dQCp
-----END PGP SIGNATURE-----



On 11/14/15 04:07, Matt Corallo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Strange, the signature validates for me. If I copy the entire mail
> (including the signature and PGP armor, but not the ads) I see the hash
> of the mail as
> b3bbd0fcfcea5f4eb5b49e9c2d7ed7514259f004fbdb5930c92084d6de561238.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBCAAGBQJWRrNYAAoJEGOJ097IOJ+hTg0P/2H5DRaG1Gd8k72VPT/DiNHP
> e8Al19f3FXIaGSiiJ2CC6Tx3d/13U8SOnbqC28vWDpCn6TR+aw7QMoLy2huyivSp
> kTuboqtTVgyt2JbwmXQHrxHIHiW70Xa/dP0sfZlQKjI47RO/gBG8ccRuIyEPgVAi
> ag7bT74hL7/C1BuEB+wA9E+b8lnCjr/rFjVKp0mSzp1/5qOCnoddUatQU4zNnE6E
> WNKj+qGekqDLPzzfMH/VrE9XX0GVaQcFG2cSBSqVOL6WQHj6cqh2z7MXl1aWMkEt
> X+GYVIYJw3UUikKKsHPdNqoVRHYAmrg7OVmrYXuL4JDOneJYnihTKj7O2bFy8tBz
> eDIBuqjyG8RTvNvouKCYMN89ePt1P53B0zDK9o6aQDUIkT/2a6RAdUUUencrN812
> Bc5E2EEbfdEn4wFeAgLAXLZ5KFFGMlEXC8ceswQHzONnXzy6UkK0D9MexvxEZnMm
> 6s3N1XBbB2Xqw04JfQ6k5r0ywV3yu1JmG0AoPuluA3xZkID2izMuSGQU2Vji/xdH
> ByeeRBYMFLeTbVIIi8I5v19ThQ+j7MR7VK8A8tt3GIjNSL3grNABOlRPb7mDDIyB
> oMnc48XBaRn3Rsdn3wwbmhvRGF2A5fDZ+APldVy89TNgtUXPMTlholCzY9ekiniA
> lVAHrXea2CpzbH6In7GK
> =dQCp
> -----END PGP SIGNATURE-----
> 
> 
> On 11/14/15 02:10, Dave Scotese via bitcoin-dev wrote:
>> I decided to try to certify Wladimir's PGP keys (the old one (2346C9A6)
>> first, and then the new one (36C2E964), since it was signed with the old
>> one).
>>
>> I visited
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
>> to see that the new key was referenced in a message signed by the old
>> one.  I figure it's safe to assume that if the old key actually signed
>> that message, then the core dev using <laanwj at gmail.com
>> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> is an
>> actual core dev (that's all I'd be worried about).  So I copied the text
>> from ------BEGIN PGP SIGNED MESSAGE----- to -----END PGP SIGNATURE-----
>> to my clipboard and asked Kleopatra (on Windows) to verify it.  It says
>> the signature is bad.  If I alter the text of the email (so the
>> signature would be have to be different to be valid), it says exactly
>> the same thing.  So maybe something is wrong with Kleopatra on Windows.
>>
>> However, the SHA256SUMS.asc file I got from the magnet link posted in
>> the email (below)  verifies just fine using the new key (36C2E964).  So
>> I figure Kleopatra is not broken.  It recognizes that the old key was
>> used to create the signature in that old email, but it says it's
>> invalid.  Has Wladimir been secretly replaced by someone who doesn't
>> have access to the private key for 2346C9A6?  Can you make a (bad)
>> signature look like it was made using a key you don't have? The whole
>> reason for signing is so that we will know if something like that
>> happened.  So did I do something wrong?  (I mean, besides using Windows).
>>
>> I believe this is the expected result if someone took something Wladimir
>> signed and ripped off the signature and pasted it below this new message
>> to make everyone think the new message was genuine.  Maybe Wladimir made
>> an edit after the signature was attached.  Or maybe it got changed when
>> it went through the email system.  It would be nice to know.  Anyway, I
>> fell back on Windows security and ran the install because it said it
>> verified that the publisher was "The Bitcoin Foundation".
>>
>>
>> On Fri, Nov 13, 2015 at 5:13 AM, Wladimir J. van der Laan via
>> bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org
>> <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>
>>     -----BEGIN PGP SIGNED MESSAGE-----
>>     Hash: SHA512
>>
>>     Bitcoin Core version 0.11.2 is now available from:
>>
>>       <https://bitcoin.org/bin/bitcoin-core-0.11.2/>
>>
>>     Alternatively, through bittorrent:
>>
>>        
>>     magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b&dn=bitcoin-core-0.11.2&tr=udp%3A%2F%2Ftracker.openbittorrent.com
>>     <http://2Ftracker.openbittorrent.com>%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com
>>     <http://2Ftracker.publicbt.com>%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de
>>     <http://2Ftracker.ccc.de>%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk
>>     <http://2Ftracker.coppersurfer.tk>%3A6969&tr=udp%3A%2F%2Fopen.demonii.com
>>     <http://2Fopen.demonii.com>%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
>>
>>     This is a new minor version release, bringing bug fixes, the BIP65
>>     (CLTV) consensus change, and relay policy preparation for BIP113. It is
>>     recommended to upgrade to this version as soon as possible.
>>
>>     Please report bugs using the issue tracker at github:
>>
>>       <https://github.com/bitcoin/bitcoin/issues>
>>
>>     Upgrading and downgrading
>>     =========================
>>
>>     How to Upgrade
>>     - --------------
>>
>>     If you are running an older version, shut it down. Wait until it has
>>     completely
>>     shut down (which might take a few minutes for older versions), then
>>     run the
>>     installer (on Windows) or just copy over /Applications/Bitcoin-Qt
>>     (on Mac) or
>>     bitcoind/bitcoin-qt (on Linux).
>>
>>     Downgrade warning
>>     - ------------------
>>
>>     Because release 0.10.0 and later makes use of headers-first
>>     synchronization and
>>     parallel block download (see further), the block files and databases
>>     are not
>>     backwards-compatible with pre-0.10 versions of Bitcoin Core or other
>>     software:
>>
>>     * Blocks will be stored on disk out of order (in the order they are
>>     received, really), which makes it incompatible with some tools or
>>     other programs. Reindexing using earlier versions will also not work
>>     anymore as a result of this.
>>
>>     * The block index database will now hold headers for which no block is
>>     stored on disk, which earlier versions won't support.
>>
>>     If you want to be able to downgrade smoothly, make a backup of your
>>     entire data
>>     directory. Without this your node will need start syncing (or
>>     importing from
>>     bootstrap.dat) anew afterwards. It is possible that the data from a
>>     completely
>>     synchronised 0.10 node may be usable in older versions as-is, but
>>     this is not
>>     supported and may break as soon as the older version attempts to
>>     reindex.
>>
>>     This does not affect wallet forward or backward compatibility. There
>>     are no
>>     known problems when downgrading from 0.11.x to 0.10.x.
>>
>>     Notable changes since 0.11.1
>>     ============================
>>
>>     BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
>>     - --------------------------------------------------------
>>
>>     This release includes several changes related to the [BIP65][] soft fork
>>     which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY
>>     (CLTV) so that a transaction output can be made unspendable until a
>>     specified point in the future.
>>
>>     1. This release will only relay and mine transactions spending a CLTV
>>        output if they comply with the BIP65 rules as provided in code.
>>
>>     2. This release will produce version 4 blocks by default. Please see the
>>        *notice to miners* below.
>>
>>     3. Once 951 out of a sequence of 1,001 blocks on the local node's
>>     best block
>>        chain contain version 4 (or higher) blocks, this release will no
>>        longer accept new version 3 blocks and it will only accept version 4
>>        blocks if they comply with the BIP65 rules for CLTV.
>>
>>     For more information about the soft-forking change, please see
>>     <https://github.com/bitcoin/bitcoin/pull/6351>
>>
>>     Graphs showing the progress towards block version 4 adoption may be
>>     found at the URLs below:
>>
>>     - - Block versions over the last 50,000 blocks as progress towards BIP65
>>       consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>
>>
>>     - - Block versions over the last 2,000 blocks showing the days to the
>>       earliest possible BIP65 consensus-enforced block:
>>     <http://bitcoin.sipa.be/ver-2k.png>
>>
>>     **Notice to miners:** Bitcoin Core’s block templates are now for
>>     version 4 blocks only, and any mining software relying on its
>>     getblocktemplate must be updated in parallel to use libblkmaker either
>>     version 0.4.3 or any version from 0.5.2 onward.
>>
>>     - - If you are solo mining, this will affect you the moment you upgrade
>>       Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
>>       status.
>>
>>     - - If you are mining with the stratum mining protocol: this does not
>>       affect you.
>>
>>     - - If you are mining with the getblocktemplate protocol to a pool: this
>>       will affect you at the pool operator’s discretion, which must be no
>>       later than BIP65 achieving its 951/1001 status.
>>
>>     [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
>>
>>     BIP113 mempool-only locktime enforcement using GetMedianTimePast()
>>     - ----------------------------------------------------------------
>>
>>     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 (**not 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 if/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.
>>
>>     [BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
>>
>>     Windows bug fix for corrupted UTXO database on unclean shutdowns
>>     - ----------------------------------------------------------------
>>
>>     Several Windows users reported that they often need to reindex the
>>     entire blockchain after an unclean shutdown of Bitcoin Core on Windows
>>     (or an unclean shutdown of Windows itself). Although unclean shutdowns
>>     remain unsafe, this release no longer relies on memory-mapped files for
>>     the UTXO database, which significantly reduced the frequency of unclean
>>     shutdowns leading to required reindexes during testing.
>>
>>     For more information, see:
>>     <https://github.com/bitcoin/bitcoin/pull/6917>
>>
>>     Other fixes for database corruption on Windows are expected in the
>>     next major release.
>>
>>     0.11.2 Change log
>>     =================
>>
>>     Detailed release notes follow. This overview includes changes that
>>     affect
>>     behavior, not code moves, refactors and string updates. For
>>     convenience in locating
>>     the code changes and accompanying discussion, both the pull request and
>>     git merge commit are mentioned.
>>
>>     - - #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument
>>     - - #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
>>     - - #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script
>>     verify flag
>>     - - #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
>>     - - #6353 `ba1da90` Show softfork status in getblockchaininfo
>>     - - #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list
>>     - - #6688 `01878c9` Fix locking in GetTransaction
>>     - - #6653 `b3eaa30` [Qt] Raise debug window when requested
>>     - - #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary
>>     - - #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package
>>     - - #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks
>>     for testnet
>>     - - #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack
>>     - - #6846 `af6edac` alias `-h` for `--help`
>>     - - #6867 `95a5039` Set TCP_NODELAY on P2P sockets.
>>     - - #6856 `dfe55bd` Do not allow blockfile pruning during reindex.
>>     - - #6566 `a1d3c6f` Add rules--presently disabled--for using
>>     GetMedianTimePast as end point for lock-time calculations
>>     - - #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the
>>     end point of lock-time constraints
>>     - - #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping
>>     - - #6948 `4e895b0` Always flush block and undo when switching to
>>     new file
>>
>>     Credits
>>     =======
>>
>>     Thanks to everyone who directly contributed to this release:
>>
>>     - - Alex Morcos
>>     - - ฿tcDrak
>>     - - Chris Kleeschulte
>>     - - Daniel Cousens
>>     - - Diego Viola
>>     - - Eric Lombrozo
>>     - - Esteban Ordano
>>     - - Gregory Maxwell
>>     - - Luke Dashjr
>>     - - Marco Falke
>>     - - Mark Friedenbach
>>     - - Matt Corallo
>>     - - Micha
>>     - - Mitchell Cash
>>     - - Peter Todd
>>     - - Pieter Wuille
>>     - - Wladimir J. van der Laan
>>     - - Zak Wilcox
>>
>>     And those who contributed additional code review and/or security
>>     research.
>>
>>     As well as everyone that helped translating on
>>     [Transifex](https://www.transifex.com/projects/p/bitcoin/).
>>
>>     -----BEGIN PGP SIGNATURE-----
>>     Version: GnuPG v1
>>
>>     iQEcBAEBCgAGBQJWReHOAAoJEHSBCwEjRsmmTAAH/iZQGklLHLIM6a2tTOj4d/O6
>>     xHg5bJhXGjtzO284Uy3phTzvk+e4mqBTjI8BrSr4D+Vw7mJrfWihdTLlgZYCwso3
>>     AyAk8ud1H42QanAfUvciY5uXd7cyzr8tCnCIBkvwJT5O8tI3FFhSMM5Fs86WnsP1
>>     Y10+93sxaVJUave2xm1bmgiwApFZKQ2MNU1IVgFaW8agB59fuqtPRnBdKiK/j+AO
>>     Jn1LKsObsINYhjtkAFiC66mUOBZ2N3rdhbN3LFl+u7EriTLoYk1OtZZhlC+rOueo
>>     nxl1H5SHStjrD27vE9Hv2qD5Ckrwo3zib8hZNIVs6MJjFnWUCwNtNg0nqDEvpn4=
>>     =xXdY
>>     -----END PGP SIGNATURE-----
>>     _______________________________________________
>>     bitcoin-dev mailing list
>>     bitcoin-dev@lists.linuxfoundation.org
>>     <mailto:bitcoin-dev@lists.linuxfoundation.org>
>>     https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> -- 
>> I like to provide some work at no charge to prove my value. Do you need
>> a techie? 
>> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
>> <http://www.memeracing.net> (in alpha).
>> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com>
>> which now accepts Bitcoin.
>> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
>> "He ought to find it more profitable to play by the rules" - Satoshi
>> Nakamoto
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>

Re: [bitcoin-dev] Bitcoin Core 0.11.2 released

[Wladimir J. van der Laan]

I'm not sure that's the right way to go about verifing gpg keys.
Copy/pasting from webpages is going to run into padding/character set conversion issues, resulting in potential false negatives. If you want to verify mails, you have to verify the original mail, which archives don't make easy (or even possible).

So I'd do this:

The binary release signing key is signed by my normal key:

$ gpg --list-sigs 36C2E964

    pub   4096R/36C2E964 2015-06-24 [expires: 2017-02-13]
    uid                  Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>
    sig 3        36C2E964 2015-06-24  Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>
    sig          2346C9A6 2015-06-24  Wladimir J. van der Laan <laanwj@visucore.com>

My normal key in turn is signed by a lot of different people.

$ gpg --list-sigs 2346C9A6

...

Also, both keys can be found on bitcoin.org in the list of developers, as well
as linked on the download page:

https://bitcoin.org/en/download

Wladimir

On Fri, Nov 13, 2015 at 06:10:29PM -0800, Dave Scotese via bitcoin-dev wrote:
> I decided to try to certify Wladimir's PGP keys (the old one (2346C9A6)
> first, and then the new one (36C2E964), since it was signed with the old
> one).
> 
> I visited
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
> to see that the new key was referenced in a message signed by the old one.
> I figure it's safe to assume that if the old key actually signed that
> message, then the core dev using <laanwj at gmail.com
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>> is an
> actual core dev (that's all I'd be worried about).  So I copied the text
> from ------BEGIN PGP SIGNED MESSAGE----- to -----END PGP SIGNATURE----- to
> my clipboard and asked Kleopatra (on Windows) to verify it.  It says the
> signature is bad.  If I alter the text of the email (so the signature would
> be have to be different to be valid), it says exactly the same thing.  So
> maybe something is wrong with Kleopatra on Windows.
> 
> However, the SHA256SUMS.asc file I got from the magnet link posted in the
> email (below)  verifies just fine using the new key (36C2E964).  So I
> figure Kleopatra is not broken.  It recognizes that the old key was used to
> create the signature in that old email, but it says it's invalid.  Has
> Wladimir been secretly replaced by someone who doesn't have access to the
> private key for 2346C9A6?  Can you make a (bad) signature look like it was
> made using a key you don't have? The whole reason for signing is so that we
> will know if something like that happened.  So did I do something wrong?
> (I mean, besides using Windows).
> 
> I believe this is the expected result if someone took something Wladimir
> signed and ripped off the signature and pasted it below this new message to
> make everyone think the new message was genuine.  Maybe Wladimir made an
> edit after the signature was attached.  Or maybe it got changed when it
> went through the email system.  It would be nice to know.  Anyway, I fell
> back on Windows security and ran the install because it said it verified
> that the publisher was "The Bitcoin Foundation".
> 
> 
> On Fri, Nov 13, 2015 at 5:13 AM, Wladimir J. van der Laan via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > Bitcoin Core version 0.11.2 is now available from:
> >
> >   <https://bitcoin.org/bin/bitcoin-core-0.11.2/>
> >
> > Alternatively, through bittorrent:
> >
> >
> > magnet:?xt=urn:btih:d6d3387160f7e14f6f27dc40ae84cf566ebf631b&dn=bitcoin-core-0.11.2&tr=udp%3A%2F%
> > 2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%
> > 2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de
> > %3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk
> > %3A6969&tr=udp%3A%2F%2Fopen.demonii.com
> > %3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
> >
> > This is a new minor version release, bringing bug fixes, the BIP65
> > (CLTV) consensus change, and relay policy preparation for BIP113. It is
> > recommended to upgrade to this version as soon as possible.
> >
> > Please report bugs using the issue tracker at github:
> >
> >   <https://github.com/bitcoin/bitcoin/issues>
> >
> > Upgrading and downgrading
> > =========================
> >
> > How to Upgrade
> > - --------------
> >
> > If you are running an older version, shut it down. Wait until it has
> > completely
> > shut down (which might take a few minutes for older versions), then run the
> > installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac)
> > or
> > bitcoind/bitcoin-qt (on Linux).
> >
> > Downgrade warning
> > - ------------------
> >
> > Because release 0.10.0 and later makes use of headers-first
> > synchronization and
> > parallel block download (see further), the block files and databases are
> > not
> > backwards-compatible with pre-0.10 versions of Bitcoin Core or other
> > software:
> >
> > * Blocks will be stored on disk out of order (in the order they are
> > received, really), which makes it incompatible with some tools or
> > other programs. Reindexing using earlier versions will also not work
> > anymore as a result of this.
> >
> > * The block index database will now hold headers for which no block is
> > stored on disk, which earlier versions won't support.
> >
> > If you want to be able to downgrade smoothly, make a backup of your entire
> > data
> > directory. Without this your node will need start syncing (or importing
> > from
> > bootstrap.dat) anew afterwards. It is possible that the data from a
> > completely
> > synchronised 0.10 node may be usable in older versions as-is, but this is
> > not
> > supported and may break as soon as the older version attempts to reindex.
> >
> > This does not affect wallet forward or backward compatibility. There are no
> > known problems when downgrading from 0.11.x to 0.10.x.
> >
> > Notable changes since 0.11.1
> > ============================
> >
> > BIP65 soft fork to enforce OP_CHECKLOCKTIMEVERIFY opcode
> > - --------------------------------------------------------
> >
> > This release includes several changes related to the [BIP65][] soft fork
> > which redefines the existing OP_NOP2 opcode as OP_CHECKLOCKTIMEVERIFY
> > (CLTV) so that a transaction output can be made unspendable until a
> > specified point in the future.
> >
> > 1. This release will only relay and mine transactions spending a CLTV
> >    output if they comply with the BIP65 rules as provided in code.
> >
> > 2. This release will produce version 4 blocks by default. Please see the
> >    *notice to miners* below.
> >
> > 3. Once 951 out of a sequence of 1,001 blocks on the local node's best
> > block
> >    chain contain version 4 (or higher) blocks, this release will no
> >    longer accept new version 3 blocks and it will only accept version 4
> >    blocks if they comply with the BIP65 rules for CLTV.
> >
> > For more information about the soft-forking change, please see
> > <https://github.com/bitcoin/bitcoin/pull/6351>
> >
> > Graphs showing the progress towards block version 4 adoption may be
> > found at the URLs below:
> >
> > - - Block versions over the last 50,000 blocks as progress towards BIP65
> >   consensus enforcement: <http://bitcoin.sipa.be/ver-50k.png>
> >
> > - - Block versions over the last 2,000 blocks showing the days to the
> >   earliest possible BIP65 consensus-enforced block: <
> > http://bitcoin.sipa.be/ver-2k.png>
> >
> > **Notice to miners:** Bitcoin Core’s block templates are now for
> > version 4 blocks only, and any mining software relying on its
> > getblocktemplate must be updated in parallel to use libblkmaker either
> > version 0.4.3 or any version from 0.5.2 onward.
> >
> > - - If you are solo mining, this will affect you the moment you upgrade
> >   Bitcoin Core, which must be done prior to BIP65 achieving its 951/1001
> >   status.
> >
> > - - If you are mining with the stratum mining protocol: this does not
> >   affect you.
> >
> > - - If you are mining with the getblocktemplate protocol to a pool: this
> >   will affect you at the pool operator’s discretion, which must be no
> >   later than BIP65 achieving its 951/1001 status.
> >
> > [BIP65]: https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
> >
> > BIP113 mempool-only locktime enforcement using GetMedianTimePast()
> > - ----------------------------------------------------------------
> >
> > 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 (**not 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 if/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.
> >
> > [BIP113]: https://github.com/bitcoin/bips/blob/master/bip-0113.mediawiki
> >
> > Windows bug fix for corrupted UTXO database on unclean shutdowns
> > - ----------------------------------------------------------------
> >
> > Several Windows users reported that they often need to reindex the
> > entire blockchain after an unclean shutdown of Bitcoin Core on Windows
> > (or an unclean shutdown of Windows itself). Although unclean shutdowns
> > remain unsafe, this release no longer relies on memory-mapped files for
> > the UTXO database, which significantly reduced the frequency of unclean
> > shutdowns leading to required reindexes during testing.
> >
> > For more information, see: <https://github.com/bitcoin/bitcoin/pull/6917>
> >
> > Other fixes for database corruption on Windows are expected in the
> > next major release.
> >
> > 0.11.2 Change log
> > =================
> >
> > Detailed release notes follow. This overview includes changes that affect
> > behavior, not code moves, refactors and string updates. For convenience in
> > locating
> > the code changes and accompanying discussion, both the pull request and
> > git merge commit are mentioned.
> >
> > - - #6124 `684636b` Make CScriptNum() take nMaxNumSize as an argument
> > - - #6124 `4fa7a04` Replace NOP2 with CHECKLOCKTIMEVERIFY (BIP65)
> > - - #6124 `6ea5ca4` Enable CHECKLOCKTIMEVERIFY as a standard script verify
> > flag
> > - - #6351 `5e82e1c` Add CHECKLOCKTIMEVERIFY (BIP65) soft-fork logic
> > - - #6353 `ba1da90` Show softfork status in getblockchaininfo
> > - - #6351 `6af25b0` Add BIP65 to getblockchaininfo softforks list
> > - - #6688 `01878c9` Fix locking in GetTransaction
> > - - #6653 `b3eaa30` [Qt] Raise debug window when requested
> > - - #6600 `1e672ae` Debian/Ubuntu: Include bitcoin-tx binary
> > - - #6600 `2394f4d` Debian/Ubuntu: Split bitcoin-tx into its own package
> > - - #5987 `33d6825` Bugfix: Allow mining on top of old tip blocks for
> > testnet
> > - - #6852 `21e58b8` build: make sure OpenSSL heeds noexecstack
> > - - #6846 `af6edac` alias `-h` for `--help`
> > - - #6867 `95a5039` Set TCP_NODELAY on P2P sockets.
> > - - #6856 `dfe55bd` Do not allow blockfile pruning during reindex.
> > - - #6566 `a1d3c6f` Add rules--presently disabled--for using
> > GetMedianTimePast as end point for lock-time calculations
> > - - #6566 `f720c5f` Enable policy enforcing GetMedianTimePast as the end
> > point of lock-time constraints
> > - - #6917 `0af5b8e` leveldb: Win32WritableFile without memory mapping
> > - - #6948 `4e895b0` Always flush block and undo when switching to new file
> >
> > Credits
> > =======
> >
> > Thanks to everyone who directly contributed to this release:
> >
> > - - Alex Morcos
> > - - ฿tcDrak
> > - - Chris Kleeschulte
> > - - Daniel Cousens
> > - - Diego Viola
> > - - Eric Lombrozo
> > - - Esteban Ordano
> > - - Gregory Maxwell
> > - - Luke Dashjr
> > - - Marco Falke
> > - - Mark Friedenbach
> > - - Matt Corallo
> > - - Micha
> > - - Mitchell Cash
> > - - Peter Todd
> > - - Pieter Wuille
> > - - Wladimir J. van der Laan
> > - - Zak Wilcox
> >
> > And those who contributed additional code review and/or security research.
> >
> > As well as everyone that helped translating on [Transifex](
> > https://www.transifex.com/projects/p/bitcoin/).
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBCgAGBQJWReHOAAoJEHSBCwEjRsmmTAAH/iZQGklLHLIM6a2tTOj4d/O6
> > xHg5bJhXGjtzO284Uy3phTzvk+e4mqBTjI8BrSr4D+Vw7mJrfWihdTLlgZYCwso3
> > AyAk8ud1H42QanAfUvciY5uXd7cyzr8tCnCIBkvwJT5O8tI3FFhSMM5Fs86WnsP1
> > Y10+93sxaVJUave2xm1bmgiwApFZKQ2MNU1IVgFaW8agB59fuqtPRnBdKiK/j+AO
> > Jn1LKsObsINYhjtkAFiC66mUOBZ2N3rdhbN3LFl+u7EriTLoYk1OtZZhlC+rOueo
> > nxl1H5SHStjrD27vE9Hv2qD5Ckrwo3zib8hZNIVs6MJjFnWUCwNtNg0nqDEvpn4=
> > =xXdY
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> 
> 
> 
> -- 
> I like to provide some work at no charge to prove my value. Do you need a
> techie?
> I own Litmocracy <http://www.litmocracy.com> and Meme Racing
> <http://www.memeracing.net> (in alpha).
> I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
> now accepts Bitcoin.
> I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
> "He ought to find it more profitable to play by the rules" - Satoshi
> Nakamoto

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev