< luke-jr>
would be nice if it let us set labels as well, but apparently not
< gmaxwell>
or sort orders.
< GitHub73>
[bitcoin] kazcw closed pull request #7991: Save 7% total memory usage by using pointers as keys in mapNextTx (master...memusage) https://github.com/bitcoin/bitcoin/pull/7991
< gmaxwell>
I wonder why that was just closed?
< cfields>
sdaftuar: coverage data updated, much more accurate now
< cfields>
i'm actually really impressed by our coverage
< cfields>
NicolasDorier: oh haha. I didn't improve the test coverage, that was all you guys :)
< cfields>
i just made a report :)
< NicolasDorier>
btw how did you made the report ? can I do it easily as well with some guru command line ?
< cfields>
NicolasDorier: it was pretty manual this time around. I had to fix up a good bit of stuff
< cfields>
NicolasDorier: goal is to get it automated and upstreamed so that Travis can generate them for each pull
< NicolasDorier>
this would be awesome
< NicolasDorier>
would help quite a lot
< cfields>
it currently won't compile without patches, that was interesting. We rely on undefined-ish compiler optimizations in CCoinsViewCache, need to figure out the cleanest way to fix that.
< cfields>
*compile for accurate coverage reporting
< Chris_Stewart_5>
Where can test coverage be viewed?
< Chris_Stewart_5>
sipa: I'm trying to add OP_CSV tests to script_tests, do I need to adjust a some sort of flag to have our script_test framework parse CHECKSEQUENCEVERIFY correctly?
< Chris_Stewart_5>
Currently getting a script parse error
< instagibbs>
Chris_Stewart_5, link to code? Worst case it's an noop
< GitHub199>
[bitcoin] laanwj opened pull request #7995: main: Make version bits GUI warning clearer to translators (master...2016_05_minor_message_change) https://github.com/bitcoin/bitcoin/pull/7995
< wallet42>
if i want to wipe my hard drive for instance
< wallet42>
talking about a _faster_ PRNG
< gmaxwell>
The openssl output has a header, so it will not be totally random.
< sipa>
i'd just write /dev/urandom
< sipa>
if you're paranoid
< sipa>
overwrite it 2 times
< wallet42>
i use /dev/urandom as initializer but my SSD can write 900 MB/s, why settle for 12 MB/s
< wallet42>
is there a crypto reason this is a bad PRNG?
< gmaxwell>
wallet42: note that on modern disks (esp for SSD), there really is no safe way to overwrite the whole disk.
< sipa>
i think there is typical advice not to use aes-ctr for very large messages without rekeying
< gmaxwell>
there is a 'secure erase' available from hdparm which is specified to erase more than you can normally access, but it's anyone's guess at how effective it actually is.
< gmaxwell>
sipa: I think any single disk that exists is small enough where that issue doesn't matter.
< sipa>
aes-ctr is by definition a bad prng, as it produces a permutation, not a random function
< sipa>
also, the argument is unlikely to matter here
< gmaxwell>
But if your goal is to not have it clear you overwrote it with openssl that command won't work due to the header.
< sipa>
you don't need a perfectly random function, just something unoredictable is enough
< gmaxwell>
doing that then overwriting with zeros would.
< wallet42>
would a sha256(password+nonce) be better than aes-ctr?
< gmaxwell>
it would be much slower.
< sipa>
it would be a random function, though
< sipa>
or at least, indistinguishable from one
< wallet42>
ok so sha256's randomness is better than aes-ctr
< sipa>
in theory
< sipa>
i don't think the distuishability matters here at all
< wallet42>
how can i bench libsecp256k1
< sipa>
it has a bench binary
< wallet42>
ah --enable-benchmark
< wallet42>
sorry
< sipa>
oh right, it's not standard anymore
< wallet42>
80us = 12,500 op/s ?
< wallet42>
shit :D
< sipa>
per thread
< wallet42>
<3 sipa, (no homo)
< wallet42>
boringssl does only 2,800 op/s for Ed25519 verify
< sipa>
there are some non-merged optimizations that are make it a few % faster stoll