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