< kallewoof> Signet PR https://github.com/bitcoin/bitcoin/pull/18267 latest commit now has 1 approach ACK, 1 utACK, 2 test ACKs; more if you count older commits. Feels like more is needed for a merge, but good progress. Please review!
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/8d6224fefe01...92735e45badf
< bitcoin-git> bitcoin/master fa96574 MarcoFalke: test: Move doxygen comment to header
< bitcoin-git> bitcoin/master fa11ff2 MarcoFalke: test: Pass empty tx pool to block assembler
< bitcoin-git> bitcoin/master fad84b7 MarcoFalke: test: Activate segwit in TestChain100Setup
< bitcoin-git> [bitcoin] fanquake merged pull request #19775: test: Activate segwit in TestChain100Setup (master...2008-testSegwit) https://github.com/bitcoin/bitcoin/pull/19775
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/92735e45badf...6a2ba626852b
< bitcoin-git> bitcoin/master fa40017 MarcoFalke: init: Pass reference to ArgsManager around instead of relying on global
< bitcoin-git> bitcoin/master fa33bc2 MarcoFalke: init: Capture copy of blocknotify setting for BlockNotifyCallback
< bitcoin-git> bitcoin/master fa9d590 MarcoFalke: scripted-diff: gArgs -> args
< bitcoin-git> [bitcoin] fanquake merged pull request #19779: Remove gArgs global from init (master...2008-gArgs) https://github.com/bitcoin/bitcoin/pull/19779
< bitcoin-git> [bitcoin] fanquake pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/6a2ba626852b...e80e5b3e4f00
< bitcoin-git> bitcoin/master 9e2897d John Newbery: scripted-diff: Rename mininode_lock to p2p_lock
< bitcoin-git> bitcoin/master 85165d4 John Newbery: scripted-diff: Rename mininode to p2p
< bitcoin-git> bitcoin/master 5e8df33 John Newbery: test: resort imports
< bitcoin-git> [bitcoin] fanquake merged pull request #19760: test: Remove confusing mininode terminology (master...2020-08-no-mininode) https://github.com/bitcoin/bitcoin/pull/19760
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e80e5b3e4f00...a12d9e5fd24a
< bitcoin-git> bitcoin/master 2bc2071 Sebastian Falbesoner: util: make EncodeBase32 consume Spans
< bitcoin-git> bitcoin/master e2aa1a5 Sebastian Falbesoner: util: make EncodeBase64 consume Spans
< bitcoin-git> bitcoin/master a12d9e5 MarcoFalke: Merge #19687: refactor: make EncodeBase{32,64} consume Spans
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19687: refactor: make EncodeBase{32,64} consume Spans (master...20200807-util-make-encode-base3264-consume-spans) https://github.com/bitcoin/bitcoin/pull/19687
< vasild> What would be the best approach to use SHA3-256 in Bitcoin Core?
< MarcoFalke> vasild: Why?
< vasild> MarcoFalke: it is used in constructing TORv3 addresses
< MarcoFalke> I'd say it should be a module in our own source code (like src/crypto/sha1.h)
< vasild> MarcoFalke: so, copy-paste (steal) some of the implementations and put it in src/crypto/sha3-256.{h,cpp}?
< MarcoFalke> Yes. Though, I am not sure where to steal from. You might want to ask the libsecp ppl ;)
< vasild> Preferred over linking to an external library? I guess its source will rarely change, if ever.
< vasild> libsecp ppl: ^ ;-)
< fanquake> I can't see a reason why we'd need to link an external library for something like that
< vasild_> fanquake: a reason could be to avoid copy-pasting a pile of obscure code into src/ (that will be like a black box) and if upstream applies changes - we will likely forget to pick them. But I guess that will not be often.
< fanquake> I'm happy for it to join all the other *obscure* code in https://github.com/bitcoin/bitcoin/tree/master/src/crypto
< vasild_> for now I will go with copy-pasting in src/ and will see what reviewers have to say
< vasild_> :)
< MarcoFalke> see also commit a5bc9c09177420bd1c6a1f9ece9ecfbe80c453fe which replaces ripemd with an in-tree version
< vasild> ok
< wumpus> why would we need to construct our own TORv3 addresses?
< wumpus> we only need to store them, right?
< wumpus> from our point of view they're simply opaque network addresses
< bitcoin-git> [bitcoin] hebasto opened pull request #19813: util, ci: Hard code previous release tarball checksums (master...200826-gpg) https://github.com/bitcoin/bitcoin/pull/19813
< vasild> wumpus: because we only (plan to) send the 32 byte public key, getting the address from that requires calculating a checksum
< vasild> "H" is "SHA3-256"
< jamesob> argh. so I'm curious about how people want to handle circular deps. The latest assumeutxo PR (#19806) has introduced one (coinstats -> validation -> coinstats).
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/a12d9e5fd24a...93ab136a33e4
< bitcoin-git> bitcoin/master e133631 Russell Yanofsky: gui: Partially revert #10244 gArgs and Params changes
< gribble> https://github.com/bitcoin/bitcoin/issues/19806 | validation: UTXO snapshot activation by jamesob · Pull Request #19806 · bitcoin/bitcoin · GitHub
< bitcoin-git> bitcoin/master 91aced7 Russell Yanofsky: gui: Remove unused interfaces::Node references
< bitcoin-git> bitcoin/master 102abff Russell Yanofsky: gui: Replace interface::Node references with pointers
< jamesob> wow, timing
< jamesob> anyway the two options I see are (i) call it what it is and just fold coinstats into validation, or (ii) mangle the coinstats interface so that the validation dependencies are injected via function parameters (which in this case requires the introduction of a single new parameter)
< jamesob> the circular dep is due to this block: https://github.com/jamesob/bitcoin/blob/82ad09bd205dfc4d8f21f17f6515ef73729c4a0d/src/node/coinstats.cpp#L67-L70 - so conceivably we could just pass in a `hash_to_height` function param. But this seems contorted. I think I'm more sympathetic to just folding the code into validation, since it'll be security critical under assumeutxo anyway.
< luke-jr> jamesob: or just add the circular dep and call it okay? :p
< luke-jr> LookupBlockIndex seems like something that shouldn't need to be in validation
< luke-jr> long-term it looks like moving that to BlockManager, and BlockManager outside validation, might be the right approach
< jamesob> luke-jr: our linter now prevents that
< luke-jr> jamesob: it has a list of exceptions
< luke-jr> just be sure the .h files don't include each other
< jamesob> luke-jr: oh great, thanks
< wumpus> vasild: you're right, my bad
< * luke-jr> grumbles at getting a slow Qt mirror
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/93ab136a33e4...30568d3f1e23
< bitcoin-git> bitcoin/master fa347b2 MarcoFalke: test: Select at least the fee in wallet_bumpfee to avoid negative amounts
< bitcoin-git> bitcoin/master fafc9d5 MarcoFalke: test: Fix intermittent issue in wallet_bumpfee
< bitcoin-git> bitcoin/master 30568d3 MarcoFalke: Merge #19778: test: Fix intermittent issue in wallet_bumpfee
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #19778: test: Fix intermittent issue in wallet_bumpfee (master...2008-testFix) https://github.com/bitcoin/bitcoin/pull/19778
< luke-jr> any determinism experts on?
< luke-jr> did a gitian windows build with a ppc64le host/VM; it's *almost* identical, but all the addresses are different :/
< luke-jr> (identical to the x86_64 build, that is)
< bitcoin-git> [bitcoin] practicalswift closed pull request #19074: tests: Use BasicTestingSetup to initialise fuzzing environment (master...fuzzers-2020-05-26) https://github.com/bitcoin/bitcoin/pull/19074
< bitcoin-git> [bitcoin] hebasto closed pull request #19471: util: Make default arg values more specific (master...200708-hint) https://github.com/bitcoin/bitcoin/pull/19471
< bitcoin-git> [bitcoin] hebasto reopened pull request #19471: util: Make default arg values more specific (master...200708-hint) https://github.com/bitcoin/bitcoin/pull/19471