< 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
< 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
< 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
< 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