< bitcoin-git> [bitcoin] theStack opened pull request #21867: test: use MiniWallet for p2p_blocksonly.py (master...20210505-test-convert_p2pblocksonly_miniwallet) https://github.com/bitcoin/bitcoin/pull/21867
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21869: depends: Add missing -D_LIBCPP_DEBUG=1 to debug flags (master...2105-dependsDebug) https://github.com/bitcoin/bitcoin/pull/21869
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f8575bce3118...9c05da4a5c57
< bitcoin-git> bitcoin/master fa3bbcf MarcoFalke: ci: Properly pass msan cflags
< bitcoin-git> bitcoin/master 9c05da4 fanquake: Merge bitcoin/bitcoin#21865: ci: Properly pass msan cflags
< bitcoin-git> [bitcoin] fanquake merged pull request #21865: ci: Properly pass msan cflags (master...2105-ciMsan) https://github.com/bitcoin/bitcoin/pull/21865
< bitcoin-git> [gui] RandyMcMillan opened pull request #320: qt: mempool stats chart (master...mempool_graph_rebase) https://github.com/bitcoin-core/gui/pull/320
< bitcoin-git> [gui] prayank23 opened pull request #321: Remove `gui_issue` from issue templates (master...issue-templates) https://github.com/bitcoin-core/gui/pull/321
< bitcoin-git> [bitcoin] prayank23 opened pull request #21870: Add `config.yml` (master...issue-templates) https://github.com/bitcoin/bitcoin/pull/21870
< bitcoin-git> [gui] MarcoFalke closed pull request #321: Remove `gui_issue` from issue templates (master...issue-templates) https://github.com/bitcoin-core/gui/pull/321
< bitcoin-git> [bitcoin] fanquake opened pull request #21871: scripts: add checks for minimum required OS versions (master...new_tests_on_lief) https://github.com/bitcoin/bitcoin/pull/21871
< michaelfolkson> #proposedmeetingtopic Plan for future Core fuzzing using OSS-Fuzz
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/9c05da4a5c57...1fcf66af6826
< bitcoin-git> bitcoin/master fae2c8b MarcoFalke: fuzz: Allow to pass min/max to ConsumeTime
< bitcoin-git> bitcoin/master fab646b MarcoFalke: fuzz: Use correct variant of ConsumeRandomLengthString instead of hardcodi...
< bitcoin-git> bitcoin/master fa61ce5 MarcoFalke: fuzz: Limit mocktime to MTP in tx_pool targets
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21798: fuzz: Create a block template in tx_pool targets (master...2104-fuzzMempool) https://github.com/bitcoin/bitcoin/pull/21798
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1fcf66af6826...06d573f053c6
< bitcoin-git> bitcoin/master 9f767e8 Sebastian Falbesoner: test: use MiniWallet for p2p_blocksonly.py
< bitcoin-git> bitcoin/master 06d573f MarcoFalke: Merge bitcoin/bitcoin#21867: test: use MiniWallet for p2p_blocksonly.py
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21867: test: use MiniWallet for p2p_blocksonly.py (master...20210505-test-convert_p2pblocksonly_miniwallet) https://github.com/bitcoin/bitcoin/pull/21867
< bitcoin-git> [bitcoin] laanwj opened pull request #21872: net: Sanitize message type for logging (master...2021-05-sanitize-messagetype) https://github.com/bitcoin/bitcoin/pull/21872
< yanmaani> What's the mempool policy for locktime?
< yanmaani> If a transaction is valid after block X, will it be accepted in the mempool in the block before that?
< sipa> it is accepted if it could be mined in the block following the current tip
< yanmaani> When will it be accepted? Transactions with locktime 10 years in the future won't, right
< yanmaani> so what's the cutoff?
< sipa> they have to be legally minable in the block following the current tip
< yanmaani> thanks!
< wumpus> #startmeeting
< core-meetingbot> Meeting started Thu May 6 19:00:26 2021 UTC. The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< meshcollider> hi
< jonatack> hi
< murch> hi
< jb55> hi
< jnewbery> hi
< michaelfolkson> hi
< fjahr> hi
< ariard> hi
< wumpus> welcome to the weekly bitcoin-core-dev meeting, there is one proposed meeting topic from http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt: Plan for future Core fuzzing using OSS-Fuzz (michaelfolkson)
< sipa> hi
< wumpus> any last minute topic proposals?
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< wumpus> 10 current blockers on review in https://github.com/bitcoin/bitcoin/projects/8
< wumpus> anything to add/remove or this is ready for merge?
< achow101> hi
< murch> #17331 has five concept ACKs and one tACK
< gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 · Pull Request #17331 · bitcoin/bitcoin · GitHub
< murch> Might be good if a couple more people took a look
< sipa> i will
< wumpus> right, needs more code review ACKs i guess
< gleb> hi
< wumpus> nothing else?
< achow101> I will be making a few changes to #17331, so it is not rtm
< gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 · Pull Request #17331 · bitcoin/bitcoin · GitHub
< wumpus> achow101: thanks for letting us know
< wumpus> no other discussion of high prio PRs? moving to next topic
< wumpus> #topic Plan for future Core fuzzing using OSS-Fuzz (michaelfolkson)
< core-meetingbot> topic: Plan for future Core fuzzing using OSS-Fuzz (michaelfolkson)
< michaelfolkson> Ok cool, so I don't know if the regular fuzzers are here but Core has signed up to use Google's OSS-Fuzz from what I understand
< michaelfolkson> I heard about it through this https://github.com/bitcoin/bitcoin/pull/21856
< michaelfolkson> In the past there were some discussions on whether it would be wise to sign up to it. The biggest concern being the 90 day disclosure.
< michaelfolkson> But it sounds like these concerns were resolved and there was some misunderstanding that there could always be some exceptions (for Core or any other project)
< luke-jr> presumably by the time it gets to Google, 90 day disclosure is better than not knowing at all?
< michaelfolkson> luke-jr: I think this more if Google finds out about it they plan to release details of it after 90 days
< michaelfolkson> luke-jr: If there is no exception
< luke-jr> michaelfolkson: right, but if we had already know, Google wouldn't have found out anyway
< sipa> we have an exception
< michaelfolkson> sipa: Ok I wasn't clear on the details of that. But that's good
< michaelfolkson> So assuming there are no problems with the disclosure part (which it sounds like there isn't) I wondered what the plan was to take advantage of using OSS-Fuzz
< michaelfolkson> Or have we not thought this far ahead yet?
< michaelfolkson> It looks like this was signed up for the last week
< sipa> michaelfolkson: MarcoFalke knows more details
< michaelfolkson> The main benefit it appears to give is access to vast amount of CPU cores but I wondered what particular fuzzing would be done on those cores and whether that would be managed by an individual, the fuzzing team etc
< sipa> but i don't think there is that much to say; it's up and running our fuzzers fron what i understand, in a number of configurations
< michaelfolkson> So no plan to allocate certain fuzzing exercises, targeted fuzzing to those particular cores?
< sipa> not sure what the advantage of that would be
< sipa> if we think our fuzzers are good, more cpu power running them is good
< sipa> if we don't think they're useful, they should be removed
< michaelfolkson> Ok so just running existing fuzzers but with more CPU power
< michaelfolkson> Do we get anything else from signing up to OSS-Fuzz other than CPU cores? Do you know?
< sipa> in what sense?
< michaelfolkson> I'm not sure. Just clarifying if that is the only benefit
< sipa> i mean... that's what fuzzing is
< sipa> they help us eun our fuzzers
< sipa> for free
< michaelfolkson> They have a few fuzzing experts over at Google. Maybe they will engage with it
< * michaelfolkson> shrugs
< wumpus> tbh, i'm not sure this is a meeting discussion topic or simply some questions that could be handled outside the meeting, but i guess it's okay as we have no other topics for today
< michaelfolkson> Ok that's all. Just interested in what had happened and what the plan was
< wumpus> okay
< michaelfolkson> I hadn't seen it discussed anywhere on IRC until that PR popped up
< wumpus> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu May 6 19:20:35 2021 UTC.
< luke-jr> on the topic of fuzzing, I'm curious if conditionals acting on ConsumeBool run ~50% in each alternative?
< luke-jr> or if fuzzing is smarter than that
< sipa> luke-jr: it is smarter
< sipa> it is biased towards choices that increase coversge
< luke-jr> sipa: ah, does it count Consume<other> as more coverage?
< luke-jr> eg, I noticed the versionbits fuzzer uses a ConsumeBool to choose between all real params, and the always/never active special cases
< luke-jr> I would expect the former to make more sense to run much more often
< sipa> luke-jr: eh, it's a bit long to explain here, but that's not how fuzzing works really
< sipa> it keeps a set of "good inputs" (ones that together maximize coverage), and then tries to construct new ones by mutating existing inputs and combining thrm
< sipa> those mutations are uniformly random, but only the ones that increase coverage (according to a number of metrics) are kept
< luke-jr> I see
< sipa> if you read bytes as input and memcmp them with a long string, fuzzing will generally discover that string fairly quickyl
< sipa> because every byte correct increases coverage by some metric
< michaelfolkson> You can direct the fuzzing to run 50% on each alternative if that's what you want
< michaelfolkson> I don't know if that would be deemed targeted fuzzing or structured fuzzing
< michaelfolkson> I read the definitions months ago, I've forgotten
< sipa> that may be the case in theory
< sipa> i don't think any of the frameworks we use actually let you
< michaelfolkson> Interesting
< luke-jr> I'm not sure there would be a reason to either
< michaelfolkson> If you were more concerned with a code path from one alternative of the bool you might want to run say 90 percent on that alternative
< luke-jr> I see what you mean; I just meant a 50/50 split didn't seem particularly useful in this case
< sipa> the cool thing about coverage-directed fuzzing is that you don't need to care about this
< sipa> if making that bool true results in 90% of the inputs that together maximize coverage, 90% of the time will be spent on it
< sipa> well, not exactly - but there is a strong correlation
< michaelfolkson> If coverage is the only metric you are concerned with. But there might be parts of the code already with coverage that you are more concerned with re bugs that might be found?
< michaelfolkson> I guess coverage directed fuzzing is only concerned with coverage :)
< sipa> then you can write a separate fuzzer for that
< jeremyrubin> responding to https://github.com/bitcoin/bitcoin/pull/21702#discussion_r616863828 shedcolor comment, does anyone have any feelings on renaming "StandardTemplateHash" to "BIP119Hash" and renaming "BasicStandardTemplate" to "StandardBareBIP119Output"?
< luke-jr> jeremyrubin: using BIP numbers in names seems non-ideal
< jeremyrubin> bip341 did this in caches?
< jeremyrubin> pyskell suggested s/bip119/ctv
< luke-jr> jeremyrubin: I think there's at least 2 cases where we regretted it
< jeremyrubin> hmm
< luke-jr> (tx replacability, versionbits)
< jeremyrubin> for the caching I don't want to rename it because i did it to match the bip341 style
< jeremyrubin> personally I like the BIP naming since I know where to go to find it
< luke-jr> use a comment/doc?
< jeremyrubin> in the case of these specific vars, it is nice because they are defined in the BIP somewhat permanently
< jeremyrubin> but I don't have a strong preference on names
< jeremyrubin> I mildly prefer leaving the names the same, but I agree it's confusing that StandardTemplateHash is a consensus definition
< luke-jr> BIP doesn't imply consensus either *shrug*
< jeremyrubin> it at least doesn't anti-imply consensus
< jeremyrubin> which "standard" kinda does
< jeremyrubin> i dunno -- do you think the names should be changed? It's kinda a PITA to change since it has to touch the BIP and the code, and there are resources floating around using those names already
< jeremyrubin> I don't really care tho overall; happy for the names to just be assigned by someone who cares
< jeremyrubin> jnewbery: ^ you want to pick for me :p