< sipa>
it's also potentially creating new entries in the parent cache
< sipa>
so to compensate for that memory usage, it also erases on the fly from the other one
< gmaxwell>
sipa: now that you've done intrensics you should be able to specialize the 64byte double sha2
< gmaxwell>
pretty easily?
< phantomcircuit>
sipa, right i see the pr, it's trying to avoid peak memory usage effectively being doubled by caching things twice
< gmaxwell>
(at least the 32-byte specialized version should get heavy use... because of all the places we use double sha2...)
< sipa>
gmaxwell: yup, one thing at a time
< phantomcircuit>
does std::unordered_map::clear() even do anything on an empty map?
< sipa>
no
< phantomcircuit>
ok so that call in Flush() is effectively a noop but makes it clear that it's empty i guess
< cfields>
sipa: hmm, come to think about it, the slowdown occured on AMD when Round() was done on SIMD instructions. Maybe it doesn't pay the same price on integers?
< bitcoin-git>
[bitcoin] murrayn opened pull request #13446: Build: remove non-distribution files/directories during make distclean. (master...distclean) https://github.com/bitcoin/bitcoin/pull/13446
< rafalcpp>
wumpus: hm, why are symlinks prohibited from being in Tree-SHA512? they seem to normally work, they are shown as blobs, their git-sha1 is identical for symlinks with same symlink target, and so is sha512 that we get from them
< rafalcpp>
BlueMatt: why we disallow symlinks? (it's your commit be908a69 - Fail merge if there are any symlinks)
< rafalcpp>
it was decided in #9871 to disable them because bitcoin doesn't need them so no need to wonder if we handle them correctly
< wumpus>
rafalcpp: basic security precaution, we could go into detail analysing the consequences of symlinks (relative, absolute, inside tree, outside tree, etc) or just blanket disallow them. As we don't require them, just disallowing is safer.
< wumpus>
jonasschnelli: could be!
< wumpus>
we don't really *want* symlinks ending up in the repository
< wumpus>
`(they're also not compatible with some OSes)
< rafalcpp>
wumpus: perhaps support for them could exist with --allow-symlinks defaulting to false? Other projects besides bitcoin could benefit from tree sha512
< wumpus>
yes- it could be a git setting that defaults to false. But I don't think it's urgent.
< wumpus>
fanquake: so the only thing affected by the OpenSSL version in depends is pretty much qt nowadays, right?
< wumpus>
I tend to agree with you that it is unnecessary
< wumpus>
(assuming that there has been no security issue that necessitates it)
< fanquake>
wumpus Looking at the release notes, basically every major change in the 1.0.2 series is a CVE
< wumpus>
seems like a nightmare to keep track of
< wumpus>
maybe "update to most recent version" isn't that bad an idea, periodically, I don't know...
< fanquake>
tbh I prefer the "drop the requirement for OpenSSL entirely" idea :p
< fanquake>
There have been a few shots at that in the past, but never merged for various reasons.
< wumpus>
for the core it's doable, but dropping the requirement from the GUI doesn't seem feasible to me, besides replacing it with some alternative SSL library (qt supports some) but I'm not sure that's better...
< wumpus>
e.g. on windows, qt can use the native SSL support, so wouldn't strictly need OpenSSL - but that doesn't sound too great to me either...
< fanquake>
Especially given the seeming lack of people we have testing anything on Windows
< wumpus>
that, too
< wumpus>
also the GUI code does some juggling with certificates that doesn't go through the Qt crypto API, so is OpenSSL specific
< wumpus>
it doesn't feel really worth working on
< wumpus>
in a bizarre twist of fate, I was working on a deprecation plan for payment requests, which would have solved this problem once and for all, but then bitpay announced they will *only* support it from then on.
< fanquake>
However seems like that doesn't need to hold up a 0.16.1
< jnewbery>
Review beg for #13066. We haven't run successfully run the extended tests or verify-commits in Travis for over two months and that would fix it
< wumpus>
yes, it's always good to have more review, also of code already merged
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #13447: travis: Increase travis_wait time while verifying commits (master...patch-1) https://github.com/bitcoin/bitcoin/pull/13447
< bitcoin-git>
[bitcoin] practicalswift opened pull request #13448: Add linter: Make sure we explicitly open all text files using UTF-8 encoding in Python (master...lint-python-utf8-encoding) https://github.com/bitcoin/bitcoin/pull/13448
< bitcoin-git>
bitcoin/master 57ba401 Pieter Wuille: Enable double-SHA256-for-64-byte code on 32-bit x86
< bitcoin-git>
bitcoin/master a607d23 Wladimir J. van der Laan: Merge #13393: Enable double-SHA256-for-64-byte code on 32-bit x86...
< bitcoin-git>
[bitcoin] laanwj closed pull request #13393: Enable double-SHA256-for-64-byte code on 32-bit x86 (master...201806_dsha256_i386) https://github.com/bitcoin/bitcoin/pull/13393
< promag>
MarcoFalke: how about a "dormant" label, automatically added for something not updated for X days (either github or git)?
< bitcoin-git>
[bitcoin] instagibbs opened pull request #13449: [WIP] support new multisig template in wallet for Solver, signing, and sign… (master...largemultisig) https://github.com/bitcoin/bitcoin/pull/13449
< luke-jr>
seems like Ubuntu doesn't have Qt 5.10 yet, but Debian testing does
< luke-jr>
dunno how to check Fedora
< luke-jr>
Arch has 5.11
< bitcoin-git>
[bitcoin] practicalswift opened pull request #13450: Add linter: Enforce the source code file naming convention described in the developer notes (master...lint-filenames) https://github.com/bitcoin/bitcoin/pull/13450
< bitcoin-git>
[bitcoin] instagibbs opened pull request #13452: have verifytxoutproof check the number of txns in proof structure (master...actuallyverifytxoutproof) https://github.com/bitcoin/bitcoin/pull/13452