< BlueMatt> wtf github just lost my comments
< gmaxwell> they probably weren't that important anyways...
< BlueMatt> no, i hit "finish review" on the wrong pr (and apparently you cant delete that kind of comment?)
< gmaxwell> the whole review thing is kinda crap. I've been trying to use it but ... ugh.
< BlueMatt> i treat it as just a batch-comment system
< BlueMatt> as such its not bad
< BlueMatt> (lack of back-comments, or, really, cache comments that you can delete before posting, was always one of my bigger complaints)
< roasbeef> adiabat: might be a good idea to use testing/quick (https://golang.org/pkg/testing/quick/, basically a fuzztester/quickcheck) against the current ref implementations, then add as test vectors divergences that the fuzzer catches
< sipa> roasbeef: that sounds cool, indeed
< warren> 2017-03-11 02:25:53 Loaded 169 blocks from external file in 2224m 2017-03-11 02:25:53 Reindexing block file blk00658.dat... when did -reindex change to no longer display progress in debug.log? I have no idea how far along it is.
< warren> oh, it shows the block progress quite a bit later now
< sipa> warren: reindexing is split into 2 phases
< sipa> one which is the real reindexing: go through the block files, and record them in the block index
< sipa> the second phase is activating the main chain, after the chain is fully known
< warren> sipa: why does it not do the first part in cases where there is no block index yet but blk*.dat files already exist?
< sipa> it only does the first part when you pass -reindex
< sipa> it does the second part if you pass -reindex-chainstate, or there are unconnected blocks in the index
< warren> Would there be any drawback to it doing the first part if blk*.dat already exists and there is no block index yet?
< sipa> probably not, but only if there is no index at all
< sipa> (i.e., not for cases where the index is out of date)
< warren> yeah, that's desirable for the use case where you want to place read-only blk*.dat files into the blocks/ dir
< jonasschnelli> BlueMatt: seems to be the right key: CA1A2908DCE2F13074C62CDE1EB776BB03C7922D
< jonasschnelli> But I had a gpg binary mix on my system due to a shitty app that had it's own gpg binary included and messed up PATH
< jonasschnelli> How do I get gpg list the used Digest (or just the full gpg signature) when using --show-signature?
< jonasschnelli> s/gpg/git
< sipa> jonasschnelli: not sure if you can
< sipa> jonasschnelli: though you can make it reject signatures made with certain hash types
< jonasschnelli> sipa: okay.. I'll check that.
< jonasschnelli> sipa: BTW. Is the assumption correct that DER encoded privkeys second byte is always 0x81 for compressed keys and 0x82 for uncompressed?
< sipa> DER encoded privkeys? why are you using those?
< jonasschnelli> sipa: there is a bug in our source code.
< jonasschnelli> I mean in key.cpp
< jonasschnelli> I'd like to fix it.
< sipa> what bug?
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #10043: 2017/03/fix der comp (master...2017/03/fix_der_comp) https://github.com/bitcoin/bitcoin/pull/10043
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/3192e5278abc...919aaf650855
< bitcoin-git> bitcoin/master d5046e7 Russell Yanofsky: Avoid scoped_connection compile error with boost 1.55.0...
< bitcoin-git> bitcoin/master b5bec4e Russell Yanofsky: Avoid QTimer::singleShot compile error with Qt 5.3.2...
< bitcoin-git> bitcoin/master 919aaf6 Wladimir J. van der Laan: Merge #10039: Fix compile errors with Qt 5.3.2 and Boost 1.55.0...
< bitcoin-git> [bitcoin] laanwj closed pull request #10039: Fix compile errors with Qt 5.3.2 and Boost 1.55.0 (master...pr/jessie) https://github.com/bitcoin/bitcoin/pull/10039
< NicolasDorier> wumpus: since you merged https://github.com/bitcoin-core/leveldb/pull/16#event-1008318088 when will it be added to core ?
< wumpus> when the secp256k1 tree is updated
< wumpus> that will happen at least once before 0.15.0
< NicolasDorier> should I close https://github.com/bitcoin/bitcoin/pull/10000 ?
< wumpus> I don't know - I don't think there's anytning left to be done there, at least
< bitcoin-git> [bitcoin] NicolasDorier closed pull request #10000: [DO NOT MERGE][LevelDB] Do no crash if filesystem can't fsync (master...fsync) https://github.com/bitcoin/bitcoin/pull/10000
< bitcoin-git> [bitcoin] jnewbery opened pull request #10044: [WIP] Run functional tests in `make check` (master...reorg_makefiles) https://github.com/bitcoin/bitcoin/pull/10044
< bitcoin-git> [bitcoin] practicalswift opened pull request #10045: [trivial] Fix typos in comments (master...typos-201703) https://github.com/bitcoin/bitcoin/pull/10045
< Chris_Stewart_5> Not sure if people have seen this, but apparently github is trying to protect against SHA1 collision attacks
< BlueMatt> sdaftuar: was reading the paper behind that...it didnt seem to indicate that it was a foolproof solution, but more like "well, these are the test vectors we know about today....might not be it, though"
< bitcoin-git> [bitcoin] pi opened pull request #10046: LevelDB: Fix Win32Env::GetFileSize(), Win32SequentialFile::_Init() and Win32RandomAccessFile::_Init() (master...master) https://github.com/bitcoin/bitcoin/pull/10046
< bitcoin-git> [bitcoin] pi closed pull request #10046: LevelDB: Fix Win32Env::GetFileSize(), Win32SequentialFile::_Init() and Win32RandomAccessFile::_Init() (master...master) https://github.com/bitcoin/bitcoin/pull/10046