< bitcoin-git> [bitcoin] ryanofsky opened pull request #17473: refactor: Settings code cleanups (master...pr/cleanset) https://github.com/bitcoin/bitcoin/pull/17473
< bitcoin-git> [bitcoin] luke-jr opened pull request #17474: Bugfix: GUI: Recognise NETWORK_LIMITED in formatServicesStr (master...bugfix_gui_netlimited_svcbit+refactor) https://github.com/bitcoin/bitcoin/pull/17474
< bitcoin-git> [bitcoin] practicalswift closed pull request #17129: tests: Add fuzzing harness for miniscript::FromScript(...) (master...fuzzers-miniscript-fromscript) https://github.com/bitcoin/bitcoin/pull/17129
< bitcoin-git> [bitcoin] practicalswift closed pull request #16915: doc: Document MemPoolAccept::Finalize(...) precondition (master...clarify-mempoolaccept-finalize-assumptions) https://github.com/bitcoin/bitcoin/pull/16915
< bitcoin-git> [bitcoin] domob1812 closed pull request #14144: Refactoring: Clarify code using encrypted_batch in CWallet (master...encrypted-batch) https://github.com/bitcoin/bitcoin/pull/14144
< bitcoin-git> [bitcoin] jnewbery opened pull request #17477: Remove the mempool's NotifyEntryAdded and NotifyEntryRemoved signals (master...2019-11-remove-mempool-signals2) https://github.com/bitcoin/bitcoin/pull/17477
< bitcoin-git> [bitcoin] jnewbery opened pull request #17479: Return BlockValidationState from ProcessNewBlock if CheckBlock/AcceptBlock fails (master...2019-11-processnewblock-early-return) https://github.com/bitcoin/bitcoin/pull/17479
< bitcoin-git> [bitcoin] theStack opened pull request #17480: test: add unit test for non-standard txs with too large scriptSig (master...20191114-test-check-for-non-standard-txs-with-too-large-scriptsig) https://github.com/bitcoin/bitcoin/pull/17480
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cd6cb9745e13...21ee676dd6a7
< bitcoin-git> bitcoin/master edb6b76 NullFunctor: fix uninitialized variable nMinerConfirmationWindow
< bitcoin-git> bitcoin/master 21ee676 fanquake: Merge #17449: fix uninitialized variable nMinerConfirmationWindow
< bitcoin-git> [bitcoin] fanquake merged pull request #17449: fix uninitialized variable nMinerConfirmationWindow (master...master) https://github.com/bitcoin/bitcoin/pull/17449
< wumpus> meeting time?
< jnewbery> hi
< moneyball> Yup
< fjahr> hi
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Nov 14 19:00:28 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< ariard> hi
< moneyball> Is it possible for me to speak to my topic first? Should be short and I only have 10 minutes
< digi_james> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james amiti fjahr
< wumpus> jeremyrubin lightlike
< lightlike> hi
< wumpus> moneyball: sure!
< moneyball> Ty
< wumpus> #topic next CoreDev
< jamesob> oh man it's thursday already hi
< achow101> hi
< meshcollider> hi
< moneyball> So I'm proposing next Core dev to be in March in SF. The 3 days prior to Bitcoin 2020 conference
< BlueMatt> gogo moneyball
< BlueMatt> sgtm
< moneyball> Let me know if there are major concerns with this
< achow101> we've already had one in sf
< moneyball> The conference is willing to find and pay for venue and breakfast and lunch
< moneyball> achow101 e we haven't had west coast the past 3
< jnewbery> last three have been Europe, Asia, US east coast. Seems reasonable to have the next one on the west coast
< BlueMatt> achow101: ehh, its been quite a while though....
< moneyball> Europe, Asia, nyc past 3
< moneyball> And we are likely to do Europe in the fall 2020
< jnewbery> moneyball: do you have somewhere planned for fall 2020?
< wumpus> seems fine to me
< moneyball> A candidate is London
< wumpus> oh cool
< moneyball> Scaling bitcoin
< jnewbery> +1 :)
< moneyball> Thought you'd like
< jamesob> I'm amazed moneyball is voluntarily signing up to plan more than one future conference
< wumpus> heh
< jonatack> hi
< wumpus> it seems there's no one with major concerns
< moneyball> Ok great
< wumpus> #topic High priority for review
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 7 blockers, 7 chasing concept ACK again
< wumpus> anything to be added/removed? or ready for merge?
< jamesob> can I add #16945? I think it's pretty close
< gribble> https://github.com/bitcoin/bitcoin/issues/16945 | refactor: introduce CChainState::GetCoinsCacheSizeState by jamesob . Pull Request #16945 . bitcoin/bitcoin . GitHub
< wumpus> looks like #16323 is closed, let's remove it
< gribble> https://github.com/bitcoin/bitcoin/issues/16323 | Call ProcessNewBlock() asynchronously by TheBlueMatt . Pull Request #16323 . bitcoin/bitcoin . GitHub
< jamesob> the assumeutxo PRs are probably gonna start to get more... substantial
< BlueMatt> indeed, got no review, scary changes are scary, so not worth rebasing.
< wumpus> BlueMatt: yeah...
< wumpus> added 16945
< jamesob> ty!
< wumpus> (to blockers, I guess, not chasing concept)
< jamesob> wumpus: right
< wumpus> #topic version 0.19.0.1
< wumpus> so, we were about to do the final release preparation for 0.19.0, then #17449 came up
< gribble> https://github.com/bitcoin/bitcoin/issues/17449 | fix uninitialized variable nMinerConfirmationWindow by bitcoinVBR . Pull Request #17449 . bitcoin/bitcoin . GitHub
< wumpus> and field of the CChainParams structure is used uninitialized in a computation, and this can have effect on GUI warnings
< wumpus> so I guess it's serious enough to forego 0.19.0 and do 0.19.0.1 immediately
< MarcoFalke> I'd say so too
< achow101> ack
< jnewbery> I agree :(
< wumpus> this does give some logistical issues, I don't think we've ever skipped a major release, but doing 0.19.0.1 with the 0.19.0 release notes and releasing it as if it is 0.19.0 should work, I guess
< MarcoFalke> Even though it seems the compiler might have compiled it correctly with -O2, not worth to rely on that
< MarcoFalke> It includes the -cli fix as well
< wumpus> it might have cuased #16697
< gribble> https://github.com/bitcoin/bitcoin/issues/16697 | Unknown version bit fork activated warning . Issue #16697 . bitcoin/bitcoin . GitHub
< MarcoFalke> So a short release notes would make sense?
< wumpus> just add them to the 0.19.0 release notes
< MarcoFalke> Oh right
< wumpus> ok, seems there's agreement on how to go forward, any other topics?
< MarcoFalke> no
< wumpus> I guess no new rc cycle is needed?
< wumpus> I don't think that is necessary with just the #17417 and #17449
< gribble> https://github.com/bitcoin/bitcoin/issues/17417 | [0.19] cli: fix -getinfo output when compiled with no wallet by fanquake . Pull Request #17417 . bitcoin/bitcoin . GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17449 | fix uninitialized variable nMinerConfirmationWindow by bitcoinVBR . Pull Request #17449 . bitcoin/bitcoin . GitHub
< jnewbery> topic suggestion: Maybe I could give people a quick update on review club?
< wumpus> otherwise there will be even more delay
< wumpus> ok
< wumpus> #topic Review club update
< jnewbery> we've had ~ 30 review club meetings so far. I'm very happy with the quality of questions that we've had
< wumpus> 30 already? wow
< jnewbery> there are a group of very regular attendees who you might recognize from PR comments: lightlike, jkczyz, zenogais, fjahr, pinheadmz, amiti, ariard, ...
< jnewbery> and we've had a few guest hosts as well: harding, MarcoFalke, ...
< jnewbery> I still think it's a great way to help new contributors. If you're interested in guest hosting some time, please message me
< jnewbery> Also tell your friends who want to start contributing that reviewing/testing is a great way to help, and review club could be a fun way for them to start
< wumpus> yes I think it's a great initative to get people involved inreview!
< jnewbery> (to clarify: I'm talking about PR review club, not taproot review club, which is another great initiative!)
< jnewbery> that's all I had
< wumpus> thank you
< wumpus> I'm trying to be involved once in a while too! but usually miss the meetings :(
< wumpus> any other topics?
< jonatack> i discussed it a fair amount in the latest stephan livera podcast too
< jonatack> including links to the club website and twitter account
< wumpus> great!
< jnewbery> thanks jonatack. I should have included you in the regular attendees list!
< jonatack> jnewbery: np!
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Nov 14 19:24:50 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< fanquake> Sounds good
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.19: https://github.com/bitcoin/bitcoin/compare/c7c8e3e072a7...6ec0dc195dc6
< bitcoin-git> bitcoin/0.19 1e9816d Wladimir J. van der Laan: build: bump version to 0.19.0.1
< bitcoin-git> bitcoin/0.19 6ec0dc1 NullFunctor: fix uninitialized variable nMinerConfirmationWindow
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.19: https://github.com/bitcoin/bitcoin/compare/6ec0dc195dc6...890dc0a7cccd
< bitcoin-git> bitcoin/0.19 890dc0a Wladimir J. van der Laan: doc: Re-add release notes of 0.19.0
< bitcoin-git> [bitcoin] ryanofsky opened pull request #17482: util: Disallow network-qualified command line options (master...pr/wdqual) https://github.com/bitcoin/bitcoin/pull/17482
< jonasschnelli> Sorry for missing the meeting again.
< jonasschnelli> I just saw that the Bitcoin Core Code Signing Association Apple developer programm expires in 15 days
< jeremyrubin> is ~everyone post DST now? does it make sense to move the meeting an hour up (or is this a settled matter of sticking to non-adjusted time)
< instagibbs> sticking to iceland time seems to be the solution
< * jeremyrubin> misses every meeting till spring
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #17483: scripted-diff: Set gitian arch back to amd64 (master...1911-gitianRevertToAmd64) https://github.com/bitcoin/bitcoin/pull/17483
< bitcoin-git> [bitcoin] ariard opened pull request #17484: CWallet: add cached m_is_ibd to remove isInitialBlockDownload (master...2019-11-wallet-remove-isibd) https://github.com/bitcoin/bitcoin/pull/17484
< bitcoin-git> [bitcoin] jnewbery opened pull request #17485: net processing: Don't reach into CBlockIndex to check for block mutation (master...2019-11-processnewblock-early-return2) https://github.com/bitcoin/bitcoin/pull/17485
< bitcoin-git> [bitcoin] jamesob closed pull request #16718: Improve speed, memory efficiency with alternate hashmap (master...2019-08-robinhood) https://github.com/bitcoin/bitcoin/pull/16718
< luke-jr> wumpus: I'd do 0.19.1 ;)
< darosior> sipa (or anyone who knows): why in https://github.com/bitcoin/bitcoin/commit/2b1f6f9ccf36f1e0a2c9d99154e1642f796d7c2b#diff-d22bc3e058f8982972e2eb381a1df668R154 is GetVirtualTransactionSize as (weight + 3) / 4 while virtual tx size is defined as weight / 4 here
< sipa> darosior: for compatibility
< sipa> weight is the consensus level thing that needs to be exact, and we only want integer arithmetic for
< sipa> vsize is the more familiar not as exact thing but that doesn't risk blowing up people's fees by 4, because they're doing estimation per size and then applying it to weight
< sipa> as for non-segwit transactions, vsize == size
< darosior> sipa: Thank you for your answer. I don't understand the trailing `3` though. For more context I've been working in making core using weight units for every feerate computation (mempool, fee estimation, coin selection, ....) and had two last broken functional test I could not get rid of (0.001% fee approximation wrong). Turned out they were using
< darosior> decoderawtransaction which uses this same formula but hardcoded. Using the BIP formula makes the fee estimation match.
< sipa> darosior: for fee estimarion purposes rounding up is less harmful than rounding down
< darosior> Ok, thanks
< darosior> Then getting rid of that if we don't round up anymore for fee estimation seems ok ? :)