+Return-Path: <laanwj@gmail.com>

+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org

+ [172.17.192.35])

+ by mail.linuxfoundation.org (Postfix) with ESMTPS id CF089486

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Mon, 16 Nov 2015 07:49:02 +0000 (UTC)

+X-Greylist: whitelisted by SQLgrey-1.7.6

+Received: from mail-wm0-f41.google.com (mail-wm0-f41.google.com [74.125.82.41])

+ by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE00C90

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Mon, 16 Nov 2015 07:49:00 +0000 (UTC)

+Received: by wmvv187 with SMTP id v187so162183241wmv.1

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Sun, 15 Nov 2015 23:48:59 -0800 (PST)

+DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;

+ h=date:from:to:cc:subject:message-id:references:mime-version

+ :content-type:content-disposition:content-transfer-encoding

+ :in-reply-to; bh=YUSWxHDeB19dz5z1T3Jk8mpejusK9rqYbeJZFPPKL88=;

+ b=BhihmOrpStVI80b5dtbNujq4XKZa6vYeN3aBmG/fcIkApFgOZS+kJJ+QCjp+qfxwwN

+ L+WbZbgAU0pOBoFJTZfeJNWye23S6rh3bZXzWAh3N1Hpl7J7g4gwZflskJvgEQNQyHnC

+ PrPw0nIBFdBa4LDz2FBdNKm+Fank2Q3W4OE9wI9sDGS/JAwqakgOAvXaCF1Kw8DecEi0

+ m+oLUzODCwQBUatHmz0Oq5vOISCSJ4AqfcZ+DWHumNFchG61y/POrO25tiw3MB0+YBvC

+ YddEwK8y5UnuUaP2ZCfQRARTPIG9K2/DlS+qZ6knw9GdtEpd7yI49cED2RHIerLO7fH1

+ GKlA==

+X-Received: by 10.28.212.84 with SMTP id l81mr7701152wmg.50.1447660139416;

+ Sun, 15 Nov 2015 23:48:59 -0800 (PST)

+Received: from amethyst.visucore.com (dhcp-089-098-228-253.chello.nl.

+ [89.98.228.253]) by smtp.gmail.com with ESMTPSA id

+ c13sm17126674wmd.14.2015.11.15.23.48.58

+ (version=TLS1_2 cipher=AES128-SHA bits=128/128);

+ Sun, 15 Nov 2015 23:48:58 -0800 (PST)

+Date: Mon, 16 Nov 2015 08:49:15 +0100

+From: "Wladimir J. van der Laan" <laanwj@gmail.com>

+To: Dave Scotese <dscotese@litmocracy.com>

+Message-ID: <20151116074914.GA10127@amethyst.visucore.com>

+References: <20151113131353.GA26622@amethyst.visucore.com>

+ <CAGLBAhcMMLnze8N=OLK0EypatRKEhFkHTJDo_KJyc_A1h1d-uA@mail.gmail.com>

+MIME-Version: 1.0

+Content-Type: text/plain; charset=utf-8

+Content-Disposition: inline

+Content-Transfer-Encoding: 8bit

+In-Reply-To: <CAGLBAhcMMLnze8N=OLK0EypatRKEhFkHTJDo_KJyc_A1h1d-uA@mail.gmail.com>

+X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,

+ DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,URIBL_BLACK

+ autolearn=no version=3.3.1

+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on

+ smtp1.linux-foundation.org

+Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>

+Subject: Re: [bitcoin-dev] Bitcoin Core 0.11.2 released

+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org

+X-Mailman-Version: 2.1.12

+Precedence: list

+List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>

+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>

+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>

+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>

+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>

+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,

+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>

+X-List-Received-Date: Mon, 16 Nov 2015 07:49:02 -0000

+

+

+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

+

+