path: root/c7/a63b36dd90043530b5291099aa571bf814ec2a

Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id D115B8EF
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 04:11:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DBE0140
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 14 Nov 2015 04:11:05 +0000 (UTC)
Received: from [172.17.0.1] (gw.vpn.bluematt.me [162.243.132.6])
	by mail.bluematt.me (Postfix) with ESMTPSA id 63A005819A;
	Sat, 14 Nov 2015 04:11:03 +0000 (UTC)
References: <20151113131353.GA26622@amethyst.visucore.com>
	<CAGLBAhcMMLnze8N=OLK0EypatRKEhFkHTJDo_KJyc_A1h1d-uA@mail.gmail.com>
	<5646B367.2090305@mattcorallo.com>
To: Dave Scotese <dscotese@litmocracy.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
Message-ID: <5646B455.1090900@mattcorallo.com>
Date: Sat, 14 Nov 2015 04:11:01 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5646B367.2090305@mattcorallo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,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: Sat, 14 Nov 2015 04:11:06 -0000

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
>>