From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D115B8EF for ; 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 ; 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> <5646B367.2090305@mattcorallo.com> To: Dave Scotese From: Matt Corallo 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > > 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 > > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> Bitcoin Core version 0.11.2 is now available from: >> >> >> >> 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: >> >> >> >> 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 >> >> >> 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: >> >> - - Block versions over the last 2,000 blocks showing the days to the >> earliest possible BIP65 consensus-enforced block: >> >> >> **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: >> >> >> 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 and Meme Racing >> (in alpha). >> I'm the webmaster for The Voluntaryist >> which now accepts Bitcoin. >> I also code for The Dollar Vigilante . >> "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 >>