--- Day changed Wed Mar 17 2021 00:19 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 246 seconds] 00:24 -!- prayank [~andr0irc@2401:4900:30df:4b1c:6d14:3f85:cf7d:24e9] has joined #bitcoin-core-pr-reviews 00:27 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 02:32 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 276 seconds] 02:40 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 02:46 -!- prayank [~andr0irc@2401:4900:30df:4b1c:6d14:3f85:cf7d:24e9] has quit [Remote host closed the connection] 02:55 -!- Netsplit *.net <-> *.split quits: belcher_ 03:02 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection] 03:03 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews 03:03 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 03:16 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 03:22 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 04:17 -!- jadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 04:20 -!- Lucinda42Hudson [~Lucinda42@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 04:25 -!- Lucinda42Hudson [~Lucinda42@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 04:40 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 05:00 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 246 seconds] 05:02 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 05:38 -!- belcher_ is now known as belcher 05:42 -!- jadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 05:45 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 05:46 -!- jadijadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 05:51 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 276 seconds] 06:04 -!- jonatack_ [~jon@37.169.45.97] has joined #bitcoin-core-pr-reviews 06:13 -!- MarcoFalke_2 [~none@198.12.116.246] has quit [Quit: ZNC 1.7.1 - https://znc.in] 06:15 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-pr-reviews 06:28 -!- jonatack_ [~jon@37.169.45.97] has quit [Quit: jonatack_] 06:28 -!- jonatack [~jon@37.169.45.97] has joined #bitcoin-core-pr-reviews 06:51 -!- jadijadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 07:00 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 07:11 -!- Keikun [cea6fb02@206.166.251.2] has joined #bitcoin-core-pr-reviews 07:14 -!- shesek`` [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 07:15 -!- shesek` [~shesek@164.90.217.137] has quit [Remote host closed the connection] 07:16 -!- musdom [~Thunderbi@202.186.69.84] has quit [Ping timeout: 245 seconds] 07:34 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews 07:36 -!- shesek` [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 07:37 -!- shesek`` [~shesek@164.90.217.137] has quit [Remote host closed the connection] 07:49 -!- Keikun [cea6fb02@206.166.251.2] has quit [Quit: Connection closed] 07:49 -!- Keikun [cea6fb02@206.166.251.2] has joined #bitcoin-core-pr-reviews 08:17 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 08:17 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 08:49 -!- comment [~comment@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 08:51 -!- AnthonyRonning [3480306a@52.128.48.106] has joined #bitcoin-core-pr-reviews 08:57 -!- nehan [~nehan@41.213.196.104.bc.googleusercontent.com] has quit [Ping timeout: 240 seconds] 08:57 -!- nehan [~nehan@41.213.196.104.bc.googleusercontent.com] has joined #bitcoin-core-pr-reviews 09:00 -!- rjected [~weechat-h@natp-128-119-202-29.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 09:22 -!- prayank [~andr0irc@2401:4900:30df:5e1e:ccd9:c8c0:52fc:3d02] has joined #bitcoin-core-pr-reviews 09:25 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Remote host closed the connection] 09:26 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews 09:26 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Client Quit] 09:30 < jnewbery> hi folks. We'll get started in about half an hour. Hope you're all ready for some fuzzing. 09:37 -!- prayank [~andr0irc@2401:4900:30df:5e1e:ccd9:c8c0:52fc:3d02] has quit [Ping timeout: 264 seconds] 09:44 -!- prayank [~andr0irc@2409:4053:2e1b:69dd:ccd9:c8c0:52fc:3d02] has joined #bitcoin-core-pr-reviews 09:45 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has joined #bitcoin-core-pr-reviews 09:45 -!- shafiunmiraz0 [~shafiunmi@103.220.205.190] has quit [Client Quit] 09:52 -!- test-23592 [93fb2f3b@eduroam47-59.fi.muni.cz] has joined #bitcoin-core-pr-reviews 09:59 -!- maqusat [59ee96ae@89.238.150.174] has joined #bitcoin-core-pr-reviews 10:00 < MarcoFalke> #startmeeting 10:00 < glozow> hi 10:00 < amiti> hi 10:00 -!- OliP [32f414b1@50-244-20-177-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews 10:00 < jnewbery> hi! 10:00 < maqusat> hi 10:00 < comment> hi 10:00 < emzy> hi 10:00 < OliP> Hi 10:00 < michaelfolkson> hi 10:00 < AnthonyRonning> hi 10:00 < Keikun> Hi 10:00 < cguida1> hi 10:00 < MarcoFalke> as always, don't ask to ask, just ask ;) 10:00 < MarcoFalke> any first time reviewers today? 10:00 < Keikun> yep! 10:01 < glozow> it's my first time reviewing a fuzz pr :3 10:01 < MarcoFalke> Keikun: Welcome! 10:01 < MarcoFalke> glozow: Welcome to fuzzing! :) 10:01 < jarolrod_> hi 10:01 < sipa> hi 10:01 < jonatack> hi (and hi Keikun!) 10:02 < MarcoFalke> ok, let's get started... 10:02 < MarcoFalke> Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach? 10:02 < AnthonyRonning> tACK - code looks good to me & ran fuzzer locally overnight 10:02 < felixweis> hi 10:02 < emzy> Tested ACK 10:02 < michaelfolkson> n Sad times :( 10:02 < glozow> y, got the fuzz running and did a code review 10:02 < amiti> easy to give it a concept ACK, seems to clearly increase coverage :) 10:03 < jarolrod_> concept ACK, got it running, but don't know much about fuzzing yet :) 10:03 < maqusat>  Concept ACK 10:03 < MarcoFalke> ok, before we jump into the fuzz target, let's cover another target really quick 10:03 < MarcoFalke> Why does the existing process_message_tx fuzz target perform so poorly when it comes to mempool acceptance? 10:03 < cguida1> didn't get to running it, still researching fuzzing 10:03 -!- effexzi [uid474242@gateway/web/irccloud.com/x-nxllnukpbokkgbha] has joined #bitcoin-core-pr-reviews 10:04 < MarcoFalke> cguida1: Did you have issues compiling? I'll be around after the meeting to troubleshoot a bit 10:04 < AnthonyRonning> mempool acceptance is pretty strict, it seems like the process_message fuzzing is random bytes of data in general. 10:05 < cguida1> MarcoFalke: unfortunately I was just busy with other stuff and didn't get to it :/ 10:05 < MarcoFalke> AnthonyRonning: Correct 10:05 < glozow> yeah i imagine it'd take a lot of random tries to get a valid tx 10:05 -!- OliP [32f414b1@50-244-20-177-static.hfc.comcastbusiness.net] has quit [Quit: Connection closed] 10:05 < michaelfolkson> I saw glozow did the fuzzing on Docker, I've also had problems in the past with fuzzing on Mac 10:06 < MarcoFalke> Depending on the fuzz engine, it might even be practically impossible to get a valid tx 10:06 < AnthonyRonning> both add value though, I like that process_message does test random data because any peer could send us all that 10:06 < MarcoFalke> michaelfolkson: Yeah, the easiest way to get this running is to install Ubuntu, but we can cover compile issues after the meeting 10:07 < emzy> michaelfolkson: I use a linux box (old thin client) for the fuzzing. Don't like to boil my notebook. 10:07 < MarcoFalke> AnthonyRonning: Indeed. I see them as testing different code paths. process_message* is more general at the cost of missing detail 10:08 < MarcoFalke> To wrap up the question. For example predicting a correct prevout hash in the input has a probability of approx. 0 10:09 < MarcoFalke> So all messages in process_message are invalid transactions (or not even transactions) 10:09 < MarcoFalke> Why does the newly added tx_pool fuzz target achieve higher coverage in MemPoolAccept than the process_message_tx target? 10:09 < AnthonyRonning> `tx_pool` creates transactions based on an existing mempool in order to make sure the tx data isn’t so random. 10:09 < glozow> for starters, you can get further than missing-inputs 10:11 < glozow> it also provides a valid script, right? `P2WSH_OP_TRUE`s? 10:11 -!- jadi [~jadi@188.75.94.246] has quit [Remote host closed the connection] 10:11 < MarcoFalke> For reference, the tx_pool target uses ConsumeTransaction: https://github.com/bitcoin/bitcoin/blob/e4e253d73007e0b680d2a473327c6fd66de4d86c/src/test/fuzz/util.cpp#L27 10:12 < AnthonyRonning> would it be benefitial to have an intentionally invalid script for the tx_pool tests? 10:13 -!- fewiofjdsklf [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:13 < glozow> we have a script fuzzer, I think 10:13 < MarcoFalke> glozow: the tx_pool target consumes any script the tx_pool_standard target picks P2WSH_OP_TRUE (a standard script) 10:13 < cguida1> AnthonyRunning: I don't see why not 10:13 < cguida1> Oh dear, everything is bold now… 10:14 < MarcoFalke> (sorry, insert separator between "script the") 10:15 < MarcoFalke> Any questions about the tx_pool target before we move on? 10:15 -!- fewiofjdsklf [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Client Quit] 10:16 < MarcoFalke> Is it expected to see more transactions rejected or accepted to the mempool in the tx_pool target? Why? You may collect evidence to support your answer by debugging the tx_pool target or by assuming all fields in the ConsumeTransaction helper are initialized by values picked to be uniformly random. Real fuzz engines do not pick values uniformly randomly, but this assumption is good enough for now. 10:16 < amiti> yes! at the end, why do we push_back txhash onto txids? 10:17 < MarcoFalke> amiti: txids keeps track of all txids to allow the fuzz engine to pick a valid prevout hash with propability larger than ~0 10:17 < MarcoFalke> https://github.com/bitcoin/bitcoin/blob/e4e253d73007e0b680d2a473327c6fd66de4d86c/src/test/fuzz/tx_pool.cpp#L223 10:17 < MarcoFalke> txids is also passed to the ConsumeTransaction helper 10:18 < MarcoFalke> https://github.com/bitcoin/bitcoin/blob/e4e253d73007e0b680d2a473327c6fd66de4d86c/src/test/fuzz/util.cpp#L38 10:18 < amiti> ah, I misread this and didn't realize its in the while loop. ok if it was a valid txn so use this as an option for the next round 10:18 < MarcoFalke> indeed 10:18 < amiti> clever :) 10:18 < AnthonyRonning> my guess was that tx_pool_standard would have more accepted transactions while tx_pool would have more rejected. 10:18 < AnthonyRonning> i wasn't sure how to debug to validate that idea 10:19 < MarcoFalke> Wild guesses are also allowed 10:19 < cguida1> I agree, I would guess more rejected, since tx_pool allows nonstandard txs? But just a guess. I imagine there are also ways to make sure most are accepted 10:20 < MarcoFalke> (The question is just about the ration of rejected/accepted within the tx_pool target) 10:21 -!- musdom [~Thunderbi@202.186.69.84] has joined #bitcoin-core-pr-reviews 10:23 < MarcoFalke> The answer to that question depends heavily on the fuzz engine. Modern fuzz engines can spend more time evolving fuzz inputs that cover rarely hit edges. 10:23 -!- musdom [~Thunderbi@202.186.69.84] has quit [Client Quit] 10:24 < MarcoFalke> One way to debug this would be to print out the mempool reject reason 10:24 < MarcoFalke> And then collect statistics which ones are the most common ones 10:25 < MarcoFalke> I found dust to be common and obviously an invalid sig 10:25 < glozow> ooo interesting 10:26 < emzy> More general question: How long should you run the fuzzing? What is a good sign to stop? 10:26 -!- genef [~user@198.167.192.33] has joined #bitcoin-core-pr-reviews 10:26 < glozow> any "mempool full"s ? 10:26 < glozow> i think that'd be the last possible failure 10:26 < MarcoFalke> glozow: Not yet, but I wasn't running very long 10:26 < AnthonyRonning> so just manually write a line in the code to log a message and that'll show up in the fuzz console output? or some other way with fuzzing libs? Not familar with fuzzing 10:27 < sipa> emzy: it's never ending 10:27 < MarcoFalke> emzy: That is still an open research question, but a good heuristic is to look whether the coverage metric increases 10:27 < sipa> for nontrivial tests there may be code paths that are only found after months or years of combined fuzzing time 10:28 < comment> emzy when one's tried every combination -- sun might go super nova before that though ;] 10:28 < emzy> MarcoFalke: so if it not increases anymore, better stop and change someting? 10:28 < MarcoFalke> emzy: The probability to find something decreases, but it won't be zero 10:29 < MarcoFalke> Unless the target is so trivial that all paths can be enumerated 10:29 < sipa> and presumably, the more interesting things are only found after long periods of time 10:29 < emzy> btw. I know it never stopps but there needs to be some practical messure to stop and move on. 10:29 < sipa> emzy: well, we in aggregate, won't stoo 10:30 < sipa> make sure you use the seeds in the qa repo, and contribute new ones back 10:30 < MarcoFalke> emzy: For a project that changes code every day, there is no "move on" 10:30 < AnthonyRonning> i wasn't exactly sure, but it seemed like the results from a `tx_pool_standard` actually changes the state of the mempool so consequtive runs even on the same input could produce different code paths? 10:30 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #bitcoin-core-pr-reviews 10:30 < MarcoFalke> With changing code, the paths change and some inputs are invalidated and need to be "re-evolved" 10:30 < comment> +1 10:30 < emzy> MarcoFalke: so maybe if the code changed you restart the fuzzing with the new code? ;) 10:31 < MarcoFalke> jup 10:31 < MarcoFalke> Moving on, How does the tx_pool_standard fuzz target improve upon the tx_pool fuzz target even further? 10:31 < glozow> how do we know when we've found a fuzz trophy? a crash? 10:31 < MarcoFalke> glozow: The fuzz engine will tell you 10:32 < MarcoFalke> afl++, and hongfuzz will tell you in their stats screen. libFuzzer will tell you by crashing 10:32 < AnthonyRonning> `tx_pool_standard` will create transactions that are standard & based on a simulated mempool. This leads to better acceptance than creating transactions with completely random amounts, scripts, etc. 10:33 < jonatack> FWIW I didn't see accepted = true yet in tx_pool after adding std::cout << "SUCCESS\n"; in the truthy case 10:33 < jonatack> (I suppose it may improve with run time) 10:34 < MarcoFalke> jonatack: How many CPU hours? 10:34 < jonatack> a few minutes :p 10:34 < MarcoFalke> leave a comment on the pr if you didn't find any within 2-8 hours or so 10:35 < MarcoFalke> Can transaction still be rejected in the tx_pool_standard target? 10:36 < MarcoFalke> (Question is made up just now, so don't look into your notes) 10:37 < glozow> hm, I thought it would still be possible... nLockTime is random right? 10:37 < AnthonyRonning> yeah I think so, things like locktime are still random 10:37 < MarcoFalke> For reference we are looking at this part of the code now: https://github.com/bitcoin/bitcoin/blob/e4e253d73007e0b680d2a473327c6fd66de4d86c/src/test/fuzz/tx_pool.cpp#L109 10:38 < glozow> I'm comparing `ConsumeTransaction` and the create transaction block in tx_pool_standard. It seems stricter but I don't think it necessarily results in a standard tx? 10:38 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 10:38 < MarcoFalke> glozow: Indeed, the tx is not guaranteed to be standard. (only the scripts) 10:39 < glozow> ah 💡 that's where the standard comes from 10:40 < MarcoFalke> Also, the amounts still might be dust 10:41 < MarcoFalke> So, to the last question in the script: Do you have other ideas for improvement? 10:42 < glozow> RBF? :) 10:42 < MarcoFalke> glozow: Good idea to test the rbf code paths 10:42 < MarcoFalke> Was working on this just now, but fighting c++17 auto-template deduction guidelines :) 10:42 -!- comment [~comment@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 265 seconds] 10:42 < glozow> could also pre-populate the mempool to test rejections based on mempool limits 10:43 < AnthonyRonning> is there a way to get a visual code coverage for the code paths that were tested? It may help me see what still isn't being reached. 10:43 < MarcoFalke> Now is also a good time to ask any questions. I understand that the fuzz code is daunting (especially for newcomers) 10:44 < MarcoFalke> AnthonyRonning: Jup, can be generated 10:44 < MarcoFalke> Will look like this: (master) https://marcofalke.github.io/btc_cov/fuzz.coverage/index.html 10:44 < glozow> I noticed the qa-assets repo is very very large 10:44 < MarcoFalke> hey, it is only 3 GB 10:44 < glozow> is it possible to condense the seeds or something? 10:44 < AnthonyRonning> MarcoFalke: thanks! that's really useful 10:44 < glozow> or some kind of more compact way? 10:45 < sipa> glozow: yes, though compact is based on some measure of "redundant" 10:45 < AnthonyRonning> have the seeds for `tx_pool` been added to qa-assets already? 10:45 < MarcoFalke> I think there is a lot of redundancy in the inputs and git will compress them (at least as long as they are in the git pack) 10:45 < glozow> AnthonyRonning: probably doesn't make sense until tx_pool is merged 10:46 < sipa> but redundant w.r.t. what? your compilation options will influence what is considered interesting 10:46 < AnthonyRonning> yeah good point. I wasn't sure how to see or check my seeds, thought it might had to been when passing in qa-assets data 10:46 < MarcoFalke> AnthonyRonning: The target might change a bit once I add support for RBF, so we wouldn't want to add stale inputs to the repo 10:46 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 10:46 -!- comment [~comment@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:46 < jnewbery> Is a git repo the best way to store the fuzz assets? Commit history don't seem very interesting/useful 10:47 < AnthonyRonning> the only thing i really see at the end of my fuzzing runs are some `slow-unit-*` files, are those anything to be concerned about? 10:47 < sipa> AnthonyRonning: how are you invoking it? 10:47 < MarcoFalke> jnewbery: Sometimes inputs are deleted because they are no longer relevant for the master branch. But keeping a copy for release branches could make sense 10:47 < AnthonyRonning> sipa: `FUZZ=tx_pool src/test/fuzz/fuzz -jobs=31` 10:48 < MarcoFalke> AnthonyRonning: How many cores do you have? 10:48 < sipa> AnthonyRonning: i think you need to specify a directory name where it'll save seeds 10:48 < AnthonyRonning> 64 10:48 < AnthonyRonning> sipa: ah okay cool! 10:48 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has joined #bitcoin-core-pr-reviews 10:48 < MarcoFalke> slow-* means that the particular input took a long time 10:48 < AnthonyRonning> still need to play with fuzzing more, very facinating 10:48 < sipa> just put a directory name after the commamd 10:48 < AnthonyRonning> sipa: thanks! 10:49 -!- test-23592 [93fb2f3b@eduroam47-59.fi.muni.cz] has quit [Ping timeout: 240 seconds] 10:49 < MarcoFalke> This could mean that the input takes a long time to parse and execute by the fuzz engine. Or it could mean there is a DoS vector 10:50 < AnthonyRonning> MarcoFalke: oh okay, so maybe false positive, maybe DoS? Is it worth saving those off to investigate further? 10:51 < glozow> ooh, how do we recover what the input was? I had a couple of those as well when i didn't specify directory 10:51 < MarcoFalke> crash- and slow- are stored in the pwd 10:51 < MarcoFalke> (also oom-*) 10:52 < jnewbery> MarcoFalke: my point is that unlike the code repo, where history is important, cloning the entire history of the fuzz assets doesn't seem very useful 10:52 < MarcoFalke> btw, this is how you generate the colored html output: https://github.com/MarcoFalke/btc_cov/blob/cd1b2a714aa99be3a9fd2bc68a2308c49f36fd76/.cirrus.yml#L43 10:53 < MarcoFalke> jnewbery: It isn't useful for CI, which is why CI specifies --depth=1 10:53 -!- jonatack [~jon@37.169.45.97] has quit [Ping timeout: 265 seconds] 10:53 < MarcoFalke> Though it might be useful for a dev 10:53 < jnewbery> ah, good tip! 10:53 -!- cguida_ [~cguida@185.81.136.21] has joined #bitcoin-core-pr-reviews 10:54 -!- genef [~user@198.167.192.33] has quit [Quit: genef] 10:54 -!- jonatack [~jon@37.169.45.97] has joined #bitcoin-core-pr-reviews 10:54 < MarcoFalke> Sorry, wrong line https://github.com/MarcoFalke/btc_cov/blob/cd1b2a714aa99be3a9fd2bc68a2308c49f36fd76/.cirrus.yml#L65 10:54 -!- genef [~genef@198.167.192.33] has joined #bitcoin-core-pr-reviews 10:55 < AnthonyRonning> MarcoFalke: thanks! 10:55 -!- cguida_ [~cguida@185.81.136.21] has quit [Read error: Connection reset by peer] 10:55 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has quit [Read error: Connection reset by peer] 10:55 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has joined #bitcoin-core-pr-reviews 10:55 < glozow> so adding `--enable-lcov --enable-lcov-branch-coverage` ? 10:56 < maqusat> likely a noob question but why do tests use COINBASE_MATURITY constant? 10:56 < MarcoFalke> jup 10:56 < jonatack> maqusat: The block reward of coinbaseoutput.nValue (50) BTC/block matures after COINBASE_MATURITY (100) blocks 10:57 < MarcoFalke> maqusat: Good question! Spending a coin before COINBASE_MATURITY confirmations is not allowed, so to add any transaction the the mempool the fuzz target needs to mine at least COINBASE_MATURITY+1 blocks 10:57 < MarcoFalke> I think this one mines 2*COINBASE_MATURITY 10:57 -!- cguida_ [~cguida@185.81.136.21] has joined #bitcoin-core-pr-reviews 10:58 < glozow> and it's still possible to pull an outpoint that's premature right? 10:58 < jonatack> this is why, in the functional test, you often see generate(101) in the test setup (COINBASE_MATURITY + 1) 10:58 < MarcoFalke> As the setup is expensive, it is done one time before any fuzzing starts: https://github.com/bitcoin/bitcoin/blob/e4e253d73007e0b680d2a473327c6fd66de4d86c/src/test/fuzz/tx_pool.cpp#L20 10:58 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has quit [Read error: Connection reset by peer] 10:58 < jonatack> tests* 10:58 < MarcoFalke> glozow: Only for the tx_pool target, IIRC 10:58 -!- cguida_ [~cguida@185.81.136.21] has quit [Read error: Connection reset by peer] 10:59 -!- cguida [~cguida@fixed-189-203-103-76.totalplay.net] has joined #bitcoin-core-pr-reviews 10:59 < maqusat> does coinbase mean a special type of transaction that can't be spent without 100 confirmations? 10:59 < glozow> ah right, `if (outpoints.size() >= COINBASE_MATURITY) break;` 11:00 < MarcoFalke> maqusat: The coinbase transaction is the first transaction in the block and can't be spent before 100 confirmations 11:00 < MarcoFalke> #endmeeting 11:01 < jnewbery> If I run `FUZZ=tx_pool src/test/fuzz/fuzz`, I don't get any output at all. Do I need to change something? 11:01 < glozow> thanks MarcoFalke!!!!!! 11:01 < emzy> Thank you MarcoFalke and all others! 11:01 < MarcoFalke> jnewbery: You'll need to compile with a fuzz engine (e.g. libFuzzer) 11:01 < comment> thanks MarcoFalke 11:01 < AnthonyRonning> thanks MarcoFalke and everyone else! 11:01 < maqusat> I see, thanks! 11:01 < cguida> thanks MarcoFalke! 11:01 < AnthonyRonning> Definitely want to keep playing with fuzzing, very cool stuff. 11:02 < MarcoFalke> Thanks everyone who made it through todays meeting! 11:02 < amiti> thanks MarcoFalke :) 11:02 < jonatack> Thanks MarcoFalke 11:02 < jnewbery> thanks MarcoFalke! 11:02 < genef> thanks MarcoFalke and all 11:02 < Keikun> Thanks MarcoFalke and everyone 11:02 < MarcoFalke> jnewbery: If you compile without a fuzz engine, you must play the fuzz engine yourself. I.e: `echo "foobar" | FUZZ=tx_pool src/test/fuzz/fuzz` 11:03 < amiti> maqusat: if you're interested, I drew a comic for the halving, and it mentions coinbase txns- https://github.com/amitiuttarwar/bitcoin-bytes/blob/master/halving.pdf. pages 6/7 =P 11:03 < MarcoFalke> jnewbery: or `cat /dev/random | FUZZ=tx_pool src/test/fuzz/fuzz` 11:04 < jnewbery> I followed the steps here: https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md#quickstart-guide 11:04 < maqusat> thanks amiti: will have a look 11:04 < sipa> MarcoFalke: lol 11:05 < sipa> jnewbery: did you perhaps forget a make clean? 11:05 < jnewbery> I did a make clean 11:05 < jnewbery> then `CC=clang CXX=clang++ ./configure --enable-fuzz --with-sanitizers=address,fuzzer,undefined && make` 11:05 < jonatack> would a kind soul please comment with the meeting log from minute 48 on at https://github.com/bitcoin-core-review-club/website/pull/321? i lost my internet at that point. 11:06 < jnewbery> I'll try again 11:06 < MarcoFalke> jnewbery: Does the process terminate if you provide a limited stdin? 11:06 < jonatack> (my connection returned during minute 54) 11:07 < jonatack> thanks jnewbery! 11:07 < jnewbery> MarcoFalke: rebuilding now. One minute 11:08 -!- Keikun [cea6fb02@206.166.251.2] has quit [Ping timeout: 240 seconds] 11:11 < MarcoFalke> Hmm. `cat /dev/urandom | FUZZ=tx_pool_standard ./src/test/fuzz/fuzz` doesn't terminate, but it should 11:13 < sipa> doesn't it read all of stdin? 11:14 < sipa> MarcoFalke: what do you think about making the fuzz binary in non-fuzzing mode take a directory as cmdline arg, and then run with all its files as input? 11:14 < sipa> basically acting like libfuzzer, except no actual fuzzing 11:14 < MarcoFalke> it shoul terminate after one: https://github.com/bitcoin/bitcoin/blob/63314b8211d795b2bf0814e244d801e74f50b152/src/test/fuzz/fuzz.cpp#L100 11:15 < MarcoFalke> sipa: No objection 11:15 < jnewbery> ok, it's working now. I obviously don't know how to compile code. Sorry! 11:15 < sipa> MarcoFalke: the read_stdin won't terminate denk ik 11:15 < sipa> oops, dutch 11:15 < sipa> "i think" 11:15 < MarcoFalke> achso 11:16 < jonatack> Meeting log is up at https://bitcoincore.reviews/21142#meeting-log 🍰 (in proper UTC as well courtesy of jnewbery) 11:17 < sipa> MarcoFalke: that'd also allow running phony fuzz on the qa assets in CI 11:17 < MarcoFalke> So we could remove one ci config? 11:18 < sipa> i think we still want an actual libfuzzer run 11:18 < sipa> i'm saying we could make the non-libfuzzer targets also test the qa assets 11:18 < MarcoFalke> why? 11:19 < MarcoFalke> Oh, to test compilation 11:19 < sipa> well, and to test 11:19 < sipa> libfuzzer isn't available for the windows appveyor build say 11:20 < sipa> but it can build and run a non-libfuzzer fuzz binary and run that on qa assets 11:21 < MarcoFalke> Sure, but if the `--with-sanitizers=address,integer,undefined` target runs over the fuzz inputs, we won't need to do it again for the libfuzzer run 11:21 < MarcoFalke> (and running it without the sanitizers won't add much value either, I think) 11:21 < MarcoFalke> Whereas running it on windows could add value 11:22 < MarcoFalke> libFuzzer is also available on Windows (in theory) 11:22 < sipa> depends, some fuzzers are just doing code coverage, and intend to trigger crashes/asserts/sanitizers 11:23 < sipa> but some fuzzers do significant amount of actual testing too 11:23 < MarcoFalke> you mean fuzz targets? 11:23 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 264 seconds] 11:24 -!- comment [~comment@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: comment] 11:24 < sipa> yes 11:24 < MarcoFalke> how would the testing be different if it is run once with a sanitizer and once without? 11:24 < sipa> yeah, fair point 11:25 < MarcoFalke> The fuzz targets are all compiled uniformly (there is no optional wallet, etc) 11:25 < sipa> i think fuzzing itself (generating more seeds) may be useful to do with both sanitizers enabled and disabled 11:25 < MarcoFalke> Maybe we could find a compiler bug, but that seems too unlikely and too expensive to do in CI 11:26 < sipa> but for just running the tests it likely makes little difference 11:26 < MarcoFalke> sipa: Yeah I think evan is generating without sanitizers and I am with 11:26 < sipa> or rather, running the tests with sanitizers is strictly better than without 11:26 < MarcoFalke> sipa: jup, that's what I think 11:27 < MarcoFalke> At least until there are significant compile options that influence the fuzz binary 11:27 < MarcoFalke> The largest one being right now probably windows vs non-windos 11:28 < sipa> right 11:40 -!- genef [~genef@198.167.192.33] has quit [Quit: genef] 11:46 -!- Netsplit *.net <-> *.split quits: Talkless 11:46 -!- Netsplit over, joins: Talkless 11:54 -!- tinova [~tinova@lemoncat.org] has quit [Ping timeout: 246 seconds] 12:01 -!- AnthonyRonning [3480306a@52.128.48.106] has quit [Quit: Connection closed] 12:04 -!- prayank [~andr0irc@2409:4053:2e1b:69dd:ccd9:c8c0:52fc:3d02] has quit [Ping timeout: 244 seconds] 12:33 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 12:52 -!- prayank [~andr0irc@2409:4053:2e1b:69dd:ccd9:c8c0:52fc:3d02] has joined #bitcoin-core-pr-reviews 12:52 -!- prayank [~andr0irc@2409:4053:2e1b:69dd:ccd9:c8c0:52fc:3d02] has quit [Read error: Connection reset by peer] 12:53 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews 12:55 -!- mol [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 264 seconds] 13:03 -!- effexzi [uid474242@gateway/web/irccloud.com/x-nxllnukpbokkgbha] has quit [Quit: Connection closed for inactivity] 13:04 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 13:06 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 246 seconds] 13:32 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 13:32 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 13:35 -!- maqusat [59ee96ae@89.238.150.174] has quit [Quit: Connection closed] 14:03 -!- jejune [~clara@193.36.225.159] has joined #bitcoin-core-pr-reviews 14:07 -!- jonatack [~jon@37.169.45.97] has quit [Read error: Connection reset by peer] 14:07 -!- jonatack [~jon@37.169.45.97] has joined #bitcoin-core-pr-reviews 14:24 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 14:30 -!- jadi [~jadi@188.75.94.246] has quit [Ping timeout: 265 seconds] 14:33 -!- cguida [~cguida@fixed-189-203-103-76.totalplay.net] has quit [Quit: -a- Connection Timed Out] 14:37 -!- cguida [~cguida@fixed-189-203-103-76.totalplay.net] has joined #bitcoin-core-pr-reviews 14:39 -!- cguida [~cguida@fixed-189-203-103-76.totalplay.net] has quit [Read error: Connection reset by peer] 14:41 -!- cguida_ [~cguida@fixed-189-203-103-76.totalplay.net] has joined #bitcoin-core-pr-reviews 14:49 -!- jonatack_ [~jon@37.164.14.9] has joined #bitcoin-core-pr-reviews 14:52 -!- jonatack [~jon@37.169.45.97] has quit [Ping timeout: 246 seconds] 14:59 -!- cguida [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:01 -!- cguida2 [~Adium@2806:2f0:51c1:5cee:c090:a5b7:3ef1:75c4] has joined #bitcoin-core-pr-reviews 15:01 -!- cguida [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:01 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has joined #bitcoin-core-pr-reviews 15:02 -!- cguida_ [~cguida@fixed-189-203-103-76.totalplay.net] has quit [Ping timeout: 245 seconds] 15:04 -!- cguida1 [~Adium@fixed-189-203-103-76.totalplay.net] has quit [Ping timeout: 264 seconds] 15:05 -!- prayank [~andr0irc@2409:4053:2e1b:69dd:ccd9:c8c0:52fc:3d02] has joined #bitcoin-core-pr-reviews 15:05 -!- cguida_ [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:06 -!- cguida_ [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:06 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has quit [Read error: Connection reset by peer] 15:06 -!- cguida [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:10 -!- cguida [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:10 -!- cguida [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:11 -!- cguida [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:11 -!- cguida [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:14 -!- cguida [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:14 -!- cguida [~cguida@fixed-189-203-100-22.totalplay.net] has joined #bitcoin-core-pr-reviews 15:21 -!- cguida_ [~cguida@fixed-189-203-100-22.totalplay.net] has joined #bitcoin-core-pr-reviews 15:21 -!- cguida [~cguida@fixed-189-203-100-22.totalplay.net] has quit [Read error: Connection reset by peer] 15:25 -!- cguida [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:29 -!- cguida_ [~cguida@fixed-189-203-100-22.totalplay.net] has quit [Ping timeout: 260 seconds] 15:41 -!- cguida [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:42 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has joined #bitcoin-core-pr-reviews 15:43 -!- cguida_ [~cguida@185.81.136.20] has joined #bitcoin-core-pr-reviews 15:46 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has quit [Ping timeout: 265 seconds] 15:47 -!- cguida_ [~cguida@185.81.136.20] has quit [Read error: Connection reset by peer] 15:47 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has joined #bitcoin-core-pr-reviews 15:54 -!- cguida [~cguida@2806:2f0:51c1:5cee:452d:444d:ea94:d4aa] has quit [Quit: -a- IRC for Android 2.1.59] 16:17 -!- jonatack_ [~jon@37.164.14.9] has quit [Ping timeout: 264 seconds] 16:22 -!- prayank [~andr0irc@2409:4053:2e1b:69dd:ccd9:c8c0:52fc:3d02] has quit [Read error: Connection reset by peer] 16:22 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has quit [Quit: Leaving] 16:33 -!- tinova [~tinova@lemoncat.org] has joined #bitcoin-core-pr-reviews 17:11 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 17:12 -!- ecola [~3cola@95.175.17.147] has quit [Ping timeout: 246 seconds] 19:27 -!- jejune [~clara@193.36.225.159] has quit [Quit: "What are you trying to say? That I can dodge bullets?" "No Neo, what I'm trying to say, is that when you are ready.....you won't have to"] 20:00 -!- mol [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews 20:12 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer] 20:14 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 21:01 -!- shesek` [~shesek@164.90.217.137] has quit [Remote host closed the connection] 21:06 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 21:06 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 21:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 21:19 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 21:22 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 21:28 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 21:29 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 22:11 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 22:12 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 23:02 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 23:02 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 23:02 -!- mol_ [mol@gateway/vpn/protonvpn/molly] has joined #bitcoin-core-pr-reviews 23:05 -!- mol [mol@gateway/vpn/protonvpn/molly] has quit [Ping timeout: 245 seconds] 23:12 -!- jadi [~jadi@188.75.94.246] has joined #bitcoin-core-pr-reviews 23:24 -!- serenity_721 [uid461749@gateway/web/irccloud.com/x-xdlhwurhfnvyuhel] has joined #bitcoin-core-pr-reviews 23:43 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 23:43 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 23:51 -!- rjected [~weechat-h@natp-128-119-202-29.wireless.umass.edu] has quit [Quit: WeeChat 3.0.1]