< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cce151317909...dde104963b3b
< bitcoin-git> bitcoin/master 1885ad3 Fabian Jahr: RPC: remove duplicate line in getblock help
< bitcoin-git> bitcoin/master dde1049 fanquake: Merge #20064: RPC: remove duplicate line in getblock help
< bitcoin-git> [bitcoin] fanquake merged pull request #20064: RPC: remove duplicate line in getblock help (master...getblock_help) https://github.com/bitcoin/bitcoin/pull/20064
< bitcoin-git> [bitcoin] EthanHeilman opened pull request #20082: refactor: Minor refactor of RandAddSeedPerfmon + comments (master...perfmon) https://github.com/bitcoin/bitcoin/pull/20082
< fanquake> luke-jr: looks like your DNS seed is down?
< * luke-jr> checks
< luke-jr> yep, should be back up when it's done loading the data file
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/dde104963b3b...875e1ccc9fe0
< bitcoin-git> bitcoin/master 64bc5ef Oliver Gugger: test: Assert PSBT change type
< bitcoin-git> bitcoin/master a56e9f5 Oliver Gugger: test: Assert exclusive PSBT funding options
< bitcoin-git> bitcoin/master 875e1cc MarcoFalke: Merge #19947: Test: Cover "change_type" option of "walletcreatefundedpsbt"...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19947: Test: Cover "change_type" option of "walletcreatefundedpsbt" RPC (master...psbt-test) https://github.com/bitcoin/bitcoin/pull/19947
< aj> sipa: is your txrequest corpus uploaded anywhere?
< hebasto> doing final testing of #19954; please connect to my node at d6jwdcoo2l3gbjps6asgg4nhp2gn5oao3wj333o43ssqnjaliehytfad.onion:8333
< gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: complete the TORv3 implementation by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
< * hebasto> +1 inbound connection. Thanks!
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20083: p2p: Disconnect, not discourage, misbehaving NODE_BLOOM peers (master...2010-p2pBloomPeer) https://github.com/bitcoin/bitcoin/pull/20083
< jonatack> hebasto: connected
< hebasto> jonatack: ty
< bitcoin-git> [bitcoin] Rav3nPL opened pull request #20086: Update CONTRIBUTING.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/20086
< sipa> should we disable appveyor?
< sipa> aj: no, i can
< wumpus> well, if we can't fix it...
< wumpus> I think disabling it temporarily makes sense
< bitcoin-git> [bitcoin] promag closed pull request #19476: rpc: Add mempoolchanges (master...2020-07-rpc-mempoolchanges) https://github.com/bitcoin/bitcoin/pull/19476
< aj> sipa: re: #20005 would just adding an autoconf snippet and failing before even trying to build if the bug is present be simpler than trying to get a reliable workaround?
< gribble> https://github.com/bitcoin/bitcoin/issues/20005 | memcmp with constants that contain zero bytes are broken in GCC · Issue #20005 · bitcoin/bitcoin · GitHub
< sipa> aj: unfortunately i fear that that may mean that people either stop building their own bitcoind, or get accustomed to a --ignore-compiler-bugs flag
< sipa> because a large number of current distributions ship a broken gcc
< aj> sipa: debian stable's gcc is 8.3 which is too old i think?? have fedora/rhel/ubuntu not done emergency patches?
< sipa> aj: there are _no_ GCC releases with the fix
< aj> sipa: the bug's only in gcc 9 and 10, isn't it?
< sipa> yes
< sipa> but all most recent 9.x and 10.x are vulnerable
< sipa> wumpus: i've disabled the appveyor webhook; it's useless currently
< aj> https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1879481 is the tracking bug for updating ubuntu focal, i think. i'm not seeing a specific bug for the issue on launchpad; likely worth filing one
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #20067: refactor: remove use of boost::algorithm::replace_first (master...20201003-get-rid-of-boost-replace_first) https://github.com/bitcoin/bitcoin/pull/20067
< bitcoin-git> [bitcoin] MarcoFalke reopened pull request #20067: refactor: remove use of boost::algorithm::replace_first (master...20201003-get-rid-of-boost-replace_first) https://github.com/bitcoin/bitcoin/pull/20067
< wumpus> sipa: thanks!
< wumpus> sipa: that's great, didn't know it could be done without a change to the repository
< sipa> wumpus: i hope it works
< wumpus> I'm honestly not sure anymore whether we should do anything at all, in regard to the gcc bug
< sipa> wumpus: agree... it's a lot less scary than we first thought, though the concern about introducing new something that is affected by it remains
< wumpus> testing has shown it doesn't affect our consensus code, that was a potential reason to panic
< sipa> it doesn't affect anything, actually
< wumpus> right
< sipa> (in the 0.20.1 codebase)
< wumpus> we probably should keep paying attention, or even have an automated test for code that is affected, but it's not enough reason to refuse to build outright or such I mean
< sipa> agree, i think refusing to build is too big a stick
< wumpus> (I initially wanted that, but it seems to be much less bad than initially thought)
< aj> (i dunno, if distros haven't patched already, someone needs to get a bigger stick...)
< wumpus> they definitely won't patch because of anything we do
< wumpus> I mwan, for example, last time I tried to get a miniupnp remote code exploit fixed in ubuntu it took a direct example of an exploit to get them to fix it quickly... "it doesn't build bitcoin anymore" is not likely to convince anyone
< wumpus> I wish someone found an example of the bug actually causing an exploitable security somewhere (and published it ofc)
< luke-jr> wumpus: it seems very unlikely
< luke-jr> wumpus: roconnor rebuilt his entire system and nothing stood out like that iirc
< wumpus> luke-jr: yes I think too that it's unlikely (but also unlikely roconner had every possible remote service installed :-) )
< luke-jr> heh
< aj> doesn't seem like anyone's filed a bug for rhel/fedora, debian or ubuntu
< wumpus> that's very much worth doing if not
< luke-jr> lol
< luke-jr> I don't see one on Gentoo's either
< luke-jr> could they be security-hidden?
< aj> seems unlikely given the gcc bug's been public for months?
< wumpus> it's almost like we're the only ones worrying about this, or yeah, that the bugs are hidden, but that would most probably mean someone did find a serious exploit making use of it
< wumpus> it's sometimes hard to distinguish "no one cares" from "everyone is panicking in secret"
< wumpus> ... though you'd kind of expect swifter action in that case
< sipa> i don't have the impression anyone is panicking in secret
< sipa> or panicking at all... if people were, there would be distro packages with gcc patched
< luke-jr> and a GCC 9 backport :P
< wumpus> sipa: I agree
< sipa> the fix is known, it's in the master branch, and it applies cleanly to GCC 9 and 10 releases, IIRC
< bitcoin-git> [bitcoin] laanwj closed pull request #20086: Fix MD linting in CONTRIBUTING.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/20086
< roconnor> Someone contacted me and is attempting to rebuild "all of" the packages in Nix with the gcc bug detection patch.
< luke-jr> sipa: it doesn't even come close to cleanly applying to GCC 9 - I couldn't rebase it without doubt
< sipa> luke-jr: oh, i'm misinformed then
< sipa> roconnor: nice
< luke-jr> sipa: my solution was to neuter the builtin memcmp entirely
< wumpus> roconnor: now that's an interesting experiment
< bitcoin-git> [bitcoin] practicalswift opened pull request #20089: validation: Increase robustness when loading malformed mempool.dat files (LoadMempool) (master...load-mempool-robustness) https://github.com/bitcoin/bitcoin/pull/20089
< aj> sipa: doesn't InsecureRandBits(n) give a value in [ 0, 1<<(n+1) ) ? or was i talking max, while you were talking average?
< sipa> aj: no, in range [0...(1<<n)-1]
< bitcoin-git> [bitcoin] amitiuttarwar opened pull request #20090: [doc] Tiny followups to new getpeerinfo connection type field (master...2020-09-getpeerinfo-conn-type-release-notes) https://github.com/bitcoin/bitcoin/pull/20090
< aj> sipa: oh, i can't add up! neat!
< sipa> (InsecureRandBits(n) >> n) should always be 0
< sipa> aj: the random interface is modeled after python's fwiw, see https://docs.python.org/3/library/random.html#random.getrandbits e.g.
< aj> sipa: my stumbling block was not realising 1<<n wasn't n for n in 0,1,2 i think
< sipa> ah
< sipa> exponents are hard
< roconnor> sipa: I didn't get any memcmp warning when compiling 875e1ccc9fe01e026e564dfd39a64d9a4b332a89.
< sipa> roconnor: awesome, thank you
< sipa> aj: a much longer term solution to the "time going backwards" thing... we really shouldn't using a system clock for these things
< sipa> all of the GetTime*() functions deal with the same clock currently, but there are two distinct use cases for them, and C++(11) conveniently has a clock for each
< sipa> most clock uses (except those used in block or wallet transaction timestamps) should really be using std::chrono::steady_clock, which can't be converted to real-world clock values, but is sufficient for "X time in the future" decisions
< sipa> and the other ones should be using std::chrono::system_clock
< aj> sipa: yeah. i tried switching a bunch of net.h to time_point's once, but got stymied by it not working with atomic.
< sipa> oh it doesn't
< sipa> that's annoying
< aj> sipa: might be fixed with c++14 or 17, i don't remember the details
< aj> sipa: it was something that needed a noexcept but didn't have one or something
< aj> sipa: i believe my thought was that we could have a mockable_clock, and then have typechecking for which times were mockable and which ones weren't
< sipa> aj: i think we should have no non-mockable times :)
< aj> sipa: hmm, i think the select() delays are better off non-mockable
< sipa> aj: hmm, right
< sipa> those should be rare though,i think
< aj> sipa: yeah, hopefully
< sipa> i guess we'd want 3 clocks:
< sipa> * nonmockable, a steady clock for select() & co
< sipa> * adjusted, a system clock with network-data based corrections
< sipa> * timings, a steady but mockable clock
< sipa> do we need a system clock that's non-adjusted anywhere?
< aj> when we have mocked time, the logs include the system time without adjusting it?
< sipa> it logs both
< sipa> [$real_time] (mocked: $mocked_time) ...
< aj> right, non-adjusted system time and mocktime
< aj> is adjusted system time okay there?
< sipa> ah, i see
< sipa> right, logs may wan5 to report real real non-adjusted system time... but those are also not things stored in variables or so
< aj> yep
< sipa> also creating an atomic_time_point should be easy
< sipa> just store an atomic duration, and convert from_to time_point at store/load time
< aj> yeah, looks like i tried pretty much that
< sipa> aj: right
< sipa> probably best to first clean up as much as we can with just durations first
< aj> sipa: yep