--- Day changed Wed Dec 02 2020 00:58 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 02:09 < fanquake> Review beg: #20422. It's basically just deleting a bunch of Python code, consolidating our macOS DMG building and dropping some macOS specific hacks while we're at it. 02:44 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has joined #bitcoin-core-pr-reviews 03:15 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 03:16 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Quit: No Ping reply in 180 seconds.] 03:16 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 240 seconds] 03:16 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 03:16 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews 03:20 -!- Ora61Paucek [~Ora61Pauc@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:27 -!- Ora61Paucek [~Ora61Pauc@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 04:00 -!- reallll is now known as belcher 04:53 -!- MasterdonX [~masterdon@45.9.249.246] has quit [Ping timeout: 265 seconds] 05:22 < jnewbery> hi folks. We'll get started in around 3.5 hours. 05:27 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:35 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 05:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services] 05:36 -!- vasild_ is now known as vasild 05:51 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has joined #bitcoin-core-pr-reviews 06:11 -!- tralfaz is now known as davterra 06:30 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-pr-reviews 06:39 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 06:46 < michaelfolkson> If someone wants to get started answering StackExchange questions :) https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c 07:10 -!- ottosch [~l@2804:7f7:a6a9:72ef:9c29:8b2c:580f:40ad] has joined #bitcoin-core-pr-reviews 07:11 -!- cangr [4d036b59@dynamic-077-003-107-089.77.3.pool.telefonica.de] has joined #bitcoin-core-pr-reviews 07:17 < michaelfolkson> fanquake: For someone not particularly familiar with the deployment code is building the PR branch and checking it builds fine on MacOS of value? 07:18 < michaelfolkson> It looks like the UX is slightly different e.g. disk image window no longer popping up briefly during deployment process like it used to 07:19 -!- jonatack [~jon@109.232.227.138] has quit [Quit: jonatack] 07:20 < michaelfolkson> Lots of error messages that are being deleted. Presumably these errors will no longer encountered 07:21 < michaelfolkson> "It also gets rid of the annoying "popping up" behaviour during DMG generation" That answers my first question 07:22 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 07:43 -!- schulzemic [b9d1c4a5@185.209.196.165] has joined #bitcoin-core-pr-reviews 07:55 -!- zelluz [~zelluz@178.164.32.56] has joined #bitcoin-core-pr-reviews 07:57 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-pr-reviews 07:59 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews 08:01 -!- schulzemic [b9d1c4a5@185.209.196.165] has quit [Remote host closed the connection] 08:02 -!- cangr [4d036b59@dynamic-077-003-107-089.77.3.pool.telefonica.de] has quit [Remote host closed the connection] 08:05 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 272 seconds] 08:05 -!- jonatack [~jon@109.202.107.20] has joined #bitcoin-core-pr-reviews 08:16 -!- cangr [4d036b59@dynamic-077-003-107-089.77.3.pool.telefonica.de] has joined #bitcoin-core-pr-reviews 08:16 -!- schulzemic [ada@gateway/vpn/mullvad/schulzemic] has joined #bitcoin-core-pr-reviews 08:33 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 08:34 -!- schulzemic [ada@gateway/vpn/mullvad/schulzemic] has quit [Quit: Konversation terminated!] 08:41 -!- elle [~ellemouto@155.93.227.251] has joined #bitcoin-core-pr-reviews 08:47 -!- effexzi [uid474242@gateway/web/irccloud.com/x-epravqsodrzemcov] has joined #bitcoin-core-pr-reviews 08:48 -!- elle [~ellemouto@155.93.227.251] has quit [Ping timeout: 260 seconds] 08:52 -!- sequel [~sequel@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 08:54 -!- jonatack [~jon@109.202.107.20] has quit [Ping timeout: 272 seconds] 08:54 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-pr-reviews 08:57 -!- schulzemic [ada@gateway/vpn/mullvad/schulzemic] has joined #bitcoin-core-pr-reviews 08:57 < glozow> ____ ____ ____ ____ _____ 08:57 < glozow> / __"| u U /"___| U | _"\ u ___ U| _"\ u |_ " _| 🏴‍☠️ 08:57 < glozow> <\___ \/ \| | \| |_) |/ |_"_| \| |_) |/ | |__/ 08:58 < glozow> u___) | | |___ | _ < | | | __/ /| | 08:58 < glozow> |____/>> \____| |_| \_\ U/| |\U |_| u |_| 08:58 < glozow> )) (__) // \\ // \\_ .-,_|___|_,-. ||>>_ _// \\_ 08:58 < glozow> (__) (__)(__) (__) (__) \_)-' '-(_/ (__)__) (__) (__) 08:58 < glozow> (in 2 minutes) 08:58 < jnewbery> \o/ 08:59 < MarcoFalke> I think I am using the wrong IRC client to see ascii art 08:59 < willcl_ark> very nifty 09:00 < jnewbery> #startmeeting 09:00 < sequel> fixed width font helps 09:00 -!- elle [~ellemouto@155.93.227.251] has joined #bitcoin-core-pr-reviews 09:00 < MarcoFalke> copy-paste in vim helped :) 09:00 < glozow> hi everyone! 09:00 < willcl_ark> hi 09:00 -!- mango [~mango@c-73-71-224-94.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:00 < sequel> hi 09:00 < robot-dreams> hi 09:00 < MarcoFalke> hi 09:00 < elle> hi! 09:00 < mango> hi 09:00 < thomasb06> hi 09:00 < dhruvm> hi 09:00 < michaelfolkson> hi 09:00 < schulzemic> hi 09:00 < emzy> hi 09:00 < jnewbery> hi all. Welcome to review club! Feel free to say hi to let everyone know you're here 09:00 -!- rage-proof [5f5af573@ip5f5af573.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews 09:00 < cangr> hi 09:00 < jnewbery> anyone here for the first time? 09:01 < schulzemic> yes 09:01 < glozow> Welcome schulzemic! ☜(ﾟヮﾟ☜) 09:01 < emzy> MarcoFalke: hehe, that was what I also did. 09:01 < sequel> welcome schulzemic 09:01 < murch> hi 09:01 < cangr> yes 09:01 < jnewbery> welcome schulzemic :) 09:01 < schulzemic> Thanks! 09:01 < jnewbery> glozow is hosting today, but I just wanted to mention something first 09:01 < jnewbery> I'm currently looking for hosts for future review club meetings. 09:02 < jnewbery> I've got a lot of commitments right now, so anyone volunteering to host would be really helping me! 09:02 < jnewbery> I can help you prepare/review notes and questions, and help you get ready for the meeting. 09:02 < jnewbery> If you've been coming to the meetings for a few weeks/months, then you're ready to host! Take a look at all the people who've hosted before you here: https://bitcoincore.reviews/meetings-hosts/. 09:02 < jnewbery> I find that teaching something is one of the best ways of learning. Hosting a review club will force you to understand the PR that week. So if you're serious about improving your understanding of Bitcoin Core, then I'd highly recommend hosting a review club. 09:02 < jnewbery> Feel free to message me after the meeting in this channel or privately. 09:02 -!- anir [40bba0b7@64.187.160.183] has joined #bitcoin-core-pr-reviews 09:02 -!- slam45 [3feee5ba@63-238-229-186.dia.static.qwest.net] has joined #bitcoin-core-pr-reviews 09:03 < jnewbery> ok, over to glozow for the fun part.. 09:03 < glozow> woo thanks jnewbery! Today we’re talking about PR #19698 https://github.com/bitcoin/bitcoin/pull/19698 09:03 < robot-dreams> Welcome cangr and thanks jnewbery! 09:03 < glozow> Did anyone get the chance to review the PR? (y/n) 09:03 < anir> y 09:03 < jnewbery> y 09:03 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 09:03 < willcl_ark> y 09:03 < elle> y 09:03 < thomasb06> y 09:03 < glozow> (☞ﾟヮﾟ)☞ cangr welcome! 09:03 < robot-dreams> y-ish but want to take a closer look after the meeting 09:04 < murch> y 09:04 < cangr> thanks 09:04 < emzy> y (reading it and running make check) 09:04 < glozow> I just hope that everyone learns something, so feel free to ask any questions :) a lot of the questions today are also more conceptual than implementation 09:04 < glozow> Let’s get this party started! First warm-up question: What is the difference between `PolicyScriptChecks` and `ConsensusScriptChecks`? 09:05 -!- pratapashutosh [67699876@103.105.152.118] has joined #bitcoin-core-pr-reviews 09:05 < willcl_ark> As I understand it, policies are soft local rules regarding what our node will create and accept. Consensus rules by contrast are hard limits which define what we accept as valid transactions and blocks on the network. 09:05 < glozow> link to code btw: https://github.com/bitcoin/bitcoin/blob/a35b948836db20fab9b48d3b77cf9f23ffee109a/src/validation.cpp#L924 09:05 < pinheadmz> policy is the ruleset that validates entry into the mempool, consensus is the ruleset that validates entry into blocks -- confusing but mempool rules are always *more* restrictive! 09:05 < thomasb06> PolicyScriptChecks is executed first, and ConsensusScriptChecks only checks if the script doesn't pass because of flags 09:06 < dhruvm> Policy is the prerogative of the node, Consensus is what the network expects and considers honest. 09:06 < willcl_ark> and we use policy checks as a "cheap" DOS prevention before running expensive? consensus checks 09:06 -!- darius27 [516cb8be@cpc159747-finc22-2-0-cust189.4-2.cable.virginm.net] has joined #bitcoin-core-pr-reviews 09:06 < glozow> willcl_ark pinheadmz dhruvm correct about policy vs consensus! can anyone tell me what the differences are in the code? 09:06 < sequel> policy screens on the node level, consensus on the network level (should never make it into the chain) 09:07 < michaelfolkson> If a transaction doesn't follow consensus rules then it would fork the chain if included a block 09:07 < glozow> willcl_ark not really, they are both script checks and aren't that different in terms of computational complexity 09:07 < sipa> sdaftuar just wrote a great answer on this question: https://bitcoin.stackexchange.com/questions/100317/what-is-the-difference-between-policy-and-consensus-when-it-comes-to-a-bitcoin-c 09:08 < glozow> sipa: that's an awesome post 09:08 < michaelfolkson> That was amazing. Thanks for that sdaftuar 09:08 < pinheadmz> in the code, there are bitfields like this one https://github.com/bitcoin/bitcoin/blob/a35b948836db20fab9b48d3b77cf9f23ffee109a/src/policy/policy.h#L60 that define a set of rules to check 09:08 < sipa> glozow: it depends, i think 09:08 < willcl_ark> sipa: oh wow that is a nice answer 09:09 < sipa> some policy checks (specifically resource limit related ones, size of scripts, ...) let us avoid doing signature checks before it's needed 09:09 < sipa> policy is really a whole bunch of unrelated things 09:09 < glozow> ah that's true 09:09 < glozow> most of those are in PreChecks though, I believe 09:10 < murch> Policy checks only apply to unconfirmed transactinos, though, right? 09:10 < MarcoFalke> (mempool) policy even includes non-script reject reasons like tx dependencies 09:10 < michaelfolkson> And so we try to do checks from cheapest to most expensive in that order? 09:10 < pinheadmz> and IIRC sipa, for soft forks the rules apply to the mempool (policy) before the actual soft fork activation. Does that hold true for taproot? For example with the next release of bitcoind, taproot rules will actually apply in the mempool even though they are not enforced in blocks yet? 09:10 < sipa> glozow: oh, this is just about the script validation flags for policy? in that case you're right 09:10 < glozow> what I wanted to get to was `PolicyScriptChecks` and `ConsensusScriptChecks` both call `CheckInputScripts`, but with different script verification flags :) 09:10 < MarcoFalke> murch: yes 09:10 < robot-dreams> One question about the the code difference, why does Consensus use CheckInputsFromMempoolAndCache? 09:11 < pinheadmz> actually answer my own question: https://github.com/bitcoin/bitcoin/blob/a35b948836db20fab9b48d3b77cf9f23ffee109a/src/policy/policy.h#L76 09:11 < sipa> pinheadmz: actually, no: https://github.com/bitcoin/bitcoin/pull/20165 09:13 < murch> Hehe, is everyone busy reading Suhas's post or why did we stop? :D 09:13 < glozow> robot-dreams: I think it's to use cached coins or signature verification result, I'd have to check more closely 09:13 < glozow> ok yes, next question: Since the code for taproot is already in interpreter.cpp, why aren’t taproot rules being enforced yet (what condition in the code would it exit on)? How would we invoke `VerifyWitnessProgram` to make it apply taproot spending rules? 09:13 < glozow> Code we’re looking at: https://github.com/bitcoin/bitcoin/blob/2ee954daaee5758d04935492139808cb6fd95233/src/script/interpreter.cpp#L1885-L1926 09:14 < thomasb06> (ko) 09:15 < pinheadmz> well this is interesting, because if you look at SCRIPT_VERIFY_TAPROOT -- it is included in the standard verify flags in the code i posted, but then those txs are actually not relayed because of the code sipa posted -- right? 09:15 < willcl_ark> Looks like a Taproot tx would currently fail at src/validation.cpp#MemPoolAccept::PreChecks#L696 09:15 < jnewbery> robot-dreams: that's an excellent question. There's a comment here: https://github.com/bitcoin/bitcoin/blob/a35b948836db20fab9b48d3b77cf9f23ffee109a/src/validation.cpp#L959-L975 that explains why that function is being called 09:16 < willcl_ark> We should call VerifyWitnessProgram with `witversion=1` to make it apply taproot rules 09:17 < robot-dreams> I'm guessing a taproot transaction would not make it into the mempool due to the policy flag `SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_TAPROOT_VERSION` 09:18 < sipa> no, that's for unknown leaf versions 09:18 < sipa> the only defined leaf version is 0xc0 for tapscript currently 09:19 < glozow> is there a condition within that control block that would exit early if we... say... didn't have a script verification flag set? :P 09:19 < elle> im assuming that the SCRIPT_VERIFY_TAPROOT bit is not yet added to the flags variable. Meaning that this line is false: if (VersionBitsState(pindex->pprev, consensusparams, Consensus::DEPLOYMENT_TAPROOT, versionbitscache) == ThresholdState::ACTIVE) { 09:20 < elle> (https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1861) 09:20 < glozow> elle: ding ding ding!!! winner winner 09:20 < glozow> today is all about script verification flags, in case y'all haven't noticed :) 09:20 < pinheadmz> well but isnt it included in standard flags? https://github.com/bitcoin/bitcoin/blob/a35b948836db20fab9b48d3b77cf9f23ffee109a/src/policy/policy.h#L76 09:21 < glozow> not consensus 09:21 < pinheadmz> aha, missed the context :-P 09:22 < glozow> and as elle pointed out, whenever we validate blocks, we get our consensus rules in the form of flags in `GetBlockScriptFlags`: https://github.com/bitcoin/bitcoin/blob/04670ef81ea2300fcba4e1a492c4c6b0e0752848/src/validation.cpp#L1822 09:22 < glozow> okie dokie 09:22 < sipa> in the mempool, taproot script validation currently happens in 0.21... except that as long as it isn't active on the network, a pre-script policy check will reject it before the script interpreter even runs 09:22 < glozow> Let’s dive into the test JSON files :D This PR edits some of the CTV and CSV tests by removing the `1` (push a 1 to the stack) at the end of the scripts. However, it doesn’t do this for all of them. Why? 09:22 < sipa> CLTV? 09:22 < glozow> CLTV OOPS 09:22 < glozow> no CTV yet 09:22 < michaelfolkson> I missed the CTV soft fork happened ;) 09:23 < jnewbery> glozow: is it something to do with the V part of CLTV? 09:23 -!- novio [56d5b49e@lfbn-bor-1-476-158.w86-213.abo.wanadoo.fr] has joined #bitcoin-core-pr-reviews 09:24 -!- jesseposner [~jp@2601:643:8980:bfd2:f040:ed44:8391:19d3] has quit [Quit: My Mac Mini has gone to sleep. ZZZzzz…] 09:24 < robot-dreams> Wild guess, is it because you now want maximal flags and are enforcing `CLEANSTACK`? 09:24 < murch> robot-dreams: That would explain why they are removed, but not why some were left in 09:25 < glozow> btw here's an example of a test that _isn't_ getting its 1 removed: https://github.com/bitcoin/bitcoin/pull/19698/files#diff-7e4229911841f1d419c71a0d0df95feb07b77f90c0ff39f09182eb8ca50779b9L199 09:25 < murch> Or maybe it does 09:26 < glozow> what does the script "0 CHECKLOCKTIMEVERIFY 1" do? 09:26 < glozow> vs a script "499999999 CHECKLOCKTIMEVERIFY 1" (which we're removing the 1 from)? 09:27 < sipa> the first leaves "0 1" on the stack if it succeeds; the second leaves "499999999 1" on the stack 09:27 < nehan> why are the policy script checks defined in STANDARD_SCRIPT_VERIFY_FLAGS in policy.h but the consensus script checks are enumerated separately in the function GetBlockScriptFlags? 09:27 < pinheadmz> sipa CLTV doesnt pop a number off the stack when it compares to the tx locktime ? 09:27 < willcl_ark> Well we need the script to end non-zero, which the first won't do without the final `1` 09:28 < sipa> pinheadmz: it cannot! it's a redefined NOP 09:28 < glozow> pinheadmz: nope! why :P 09:28 < glozow> AW MAN SIPA U GAVE IT AWAY 09:28 < jnewbery> if an opcode has verify in the name, then it leaves the stack unchanged 09:28 < sipa> sowwwy 09:28 < glozow> NOPs can't touch the stack! 09:28 < sipa> jnewbery: wrong 09:28 < jnewbery> oh really? 09:28 < sipa> CHECKSIGVERIFY definitely modifies the stack 09:28 < jnewbery> yes, totally wrong 09:28 < jnewbery> ignore me 09:28 < sipa> /ignore jnewbery 09:28 < michaelfolkson> That's generally right though 09:28 < michaelfolkson> Just some counterexamples 09:29 < glozow> ok we can still use our brains a little bit... WHY can't upgradeable NOPs touch the stack? 09:29 < pinheadmz> if the CLTV failed though, these examples would fail technically with n empty stack because the 1 at the end would never get pushed to the stack 09:29 < murch> Because that would be a hardfork 09:29 < willcl_ark> so that old clients don't fail the scripts 09:29 < pinheadmz> glozow bc they were soft forked in! i shouldve known 09:29 < robot-dreams> nehan: I think it's because consensus checks depends on which block you're on (so you can't just set hardcoded flags) 09:29 < glozow> yaaaaaaas 09:29 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:30 < pinheadmz> oops i mean they would fail without the 1 but still the first number bc of the NOPness 09:30 < glozow> and yes, sorry nehan, i forgot to get back to you on your question - block script flags change from block to block, so we re-calculate them every time 09:30 < sipa> robot-dreams: yeah, policy just always enables everything we know about; consensus flags depend on context 09:30 < glozow> thanks robot-dreams :) 09:30 < nehan> robot-dreams: thanks! 09:30 < glozow> alrighty, so why don't we take off the 1 at the end of "0 CHECKLOCKTIMEVERIFY 1" ? 09:31 < glozow> (this is a valid tx btw) 09:31 < willcl_ark> we need non-zero stack at the end 09:31 < glozow> willcl_ark: exactly! 09:31 < MarcoFalke> some consensus flags can be and have been backdated to the genesis block, though 09:32 < willcl_ark> but does `499999999 CHECKLOCKTIMEVERIFY` not leave us with nothing too? 09:32 < glozow> well, what does 499999999 evaluate to? 09:32 < sipa> pinheadmz: if the CLTV fails the script immediately aborts entirely with failure; no code after it is executed anymore, but that's not really relevant if we've already aborted 09:32 < willcl_ark> ah it just gives 499999999 I see now 09:32 < willcl_ark> was looking at the wrong opcode 09:32 < glozow> 👍 09:32 < glozow> NEXT! What does `TrimFlags` do? (Extra credit question: why does SCRIPT_VERIFY_CLEANSTACK need to be used with SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS?) 09:33 < pinheadmz> MarcoFalke example ? 09:33 < MarcoFalke> pinheadmz: the witness v0 script flags 09:33 < glozow> link to the TrimFlags code: https://github.com/bitcoin/bitcoin/blob/110239f2ff673eaea8f59c650792f3641855263d/src/test/transaction_tests.cpp#L138-L148 09:33 < robot-dreams> I'm a bit behind... I understand why we cannot take off the 1 at the end of "0 CLTV 1", but just to confirm, why DO we take off the 1 at the end of "499999999 CLTV 1"? 09:34 < MarcoFalke> pinheadmz: ok wait, they aren't enabled for the p2sh exception, so still depend on context 09:34 < sipa> robot-dreams: what would the script do if you left the "1" off? 09:34 < glozow> robot-dreams: we'd like a clean stack, and in that case we'd have 4999999 and 1 at the end 09:34 < sipa> robot-dreams: oh, i misread 09:34 < glozow> would anyone who's been quiet today like to tell us what CLEANSTACK means? :) 09:35 < murch> robot-dreams: I am also still wondering that. 09:35 < sipa> glozow: you could turn it into "0 CLTV DROP 1" if you wanted cleanstack for the first :) 09:35 < felixweis> it means that after all opcodes have executed on the stack, the stack must be empty or 1 (i forgot) 09:35 < willcl_ark> Single stack element remaining after execution 09:35 < robot-dreams> sipa: Yes, that was my confusion. I didn't understand why `0 1` would be considered a claen stack 09:36 < sipa> robot-dreams: it's not 09:36 < murch> Ah, thanks. 09:36 < pinheadmz> is the cleanstack rule just a malleability fix? 09:37 < willcl_ark> So am I right in reading CLEANSTACk is not consensus critical before taproot, but is for taproot? 09:37 < glozow> felixweis: yup! we don't want any extra items on the stack. I think 0 vs 1 depends on context too, sipa explains it here https://github.com/bitcoin/bitcoin/pull/20006#issuecomment-698487304 09:37 < sipa> willcl_ark: CLEANSTACK really means two different things 09:37 < felixweis> its required since segwit and p2sh 09:37 < murch> So previously the test was merely considering the tx valid because we didn't enforce the cleanstack rule, and now that we're defaulting to all flags, it would fail on the cleanstack rule 09:38 < willcl_ark> aha 09:38 < sipa> the script flag CLEANSTACK is only for top-level script evaluation 09:38 < willcl_ark> also: "Note: CLEANSTACK should never be used without P2SH or WITNESS." 09:38 < sipa> witv0/taproot have an implicit cleanstack-like behavior as part of their consensus rules 09:39 < willcl_ark> thanks sipa. 09:39 < sipa> but that isn't controlled by the CLEANSTACK flag 09:39 < glozow> right 09:39 < willcl_ark> Just to keep devs on their toes :P 09:39 < felixweis> so if the taproot stack after execution is empty and cleanstack is enabled the input still fails? 09:40 < glozow> ok everybody, I don't want to lose people so let's just go back to the first question :) what does TrimFlags do? 09:40 < robot-dreams> `TrimFlags` enforces constraints between flags (e.g. if CLEANSTACK is on, WITNESS must be on), and does so by turning off flags. 09:40 < glozow> robot-dreams: correct! 09:41 < glozow> what does `~` do in this context? 09:41 < michaelfolkson> bitwise NOT 09:41 < glozow> michaelfolkson: yup! 09:41 < robot-dreams> Do we expect many more such constraints in the future? 09:41 < murch> felixweis: Empty stack is also a problem, I think it should end on a single element. 09:41 < glozow> (not a flag destructor, in some countries that is illegal) 09:42 < felixweis> single element != 0 09:42 < glozow> Arriving at our main course today: What does it mean for script verify flags to be “minimal” and “maximal?” 09:42 < pinheadmz> ha 09:42 < glozow> robot-dreams: not sure. depends on sipa i guess 09:43 < sipa> help 09:43 < sipa> i sincerely hope not 09:43 < murch> glozow: Valid txes should pass with all flags that are not explicitly excluded in this specific transactino, and invalid txes should fail on exactly the specific flag that's tested 09:44 < glozow> murch: yes! we don't want transaction tests to be passing/failing because we omitted/added extra flags 09:44 < willcl_ark> yes, maximal should mean that adding any extra flag will make the transaction fail 09:44 < murch> felixweis: I'm not sure what you mean. Do you mean to express that "0" is empty stack? 09:45 < glozow> willcl_ark: yes! thanks for elaborating more concretely 09:45 < glozow> so how do we implement this? what does the PR do to test for maximal/minimal flags? 09:45 < murch> And minimal means that no flags can be removed without making the tx pass as valid 09:45 < glozow> Code at https://github.com/bitcoin/bitcoin/blob/110239f2ff673eaea8f59c650792f3641855263d/src/test/transaction_tests.cpp#L241-L246 09:45 < felixweis> murch: i thought it has to be a single element value. does the value have to be boolan true? 09:46 < sipa> felixweis: [] is an empty stack, [""] is not 09:46 < sipa> OP_0 pushes "" onto the stack 09:46 < robot-dreams> For a valid transaction, we try every unset flag and make sure adding it invalidates the transaction. 09:46 < felixweis> thanks 09:47 < glozow> robot-dream: correct 👌 09:47 < murch> sipa: But does a stack have to be empty or end on a positive single element in the end. I thought it was the latter for valid txes. 09:47 < robot-dreams> I had a question about that, would it be helpful to try every valid *combination* of unset flags, or would that blow up the test time way too much? 09:47 < glozow> robot-dreams: that's the next question :P 09:47 < sipa> murch: you have to have a stack with a single element in it, which has to be nonzero 09:47 < willcl_ark> stack has to terminate with any element not `0` 09:48 < murch> Thx 09:48 < sipa> murch: (for CLEANSTACK) 09:48 < felixweis> what about NaN? /s 09:48 < murch> Right 09:48 < glozow> ok and what about testing that invalid transaction tests are minimal? how's that implemented? 09:48 < sipa> without CLEANSTACK, a non-empty stack whose top element is nonzero is enough 09:48 < glozow> have minimal flags* i mean 09:48 < murch> glozow: Presumably by trying to remove every set flag in turn and checking that this makes the tx vaild 09:48 < glozow> murch: correct 09:49 < glozow> but hey, is it possible that we're removing a flag and getting an invalid combination? e.g. CLEANSTACK without P2SH? 09:49 < felixweis> isnt that what trimflags is for? 09:49 < murch> No, because if CLEANSTACK is set P2SH is turned back on by trimFlags() 09:49 < robot-dreams> Yeah, I think glozow addresses this with FillFlags / TrimFlags calls 09:50 < glozow> felixweis murch robot-dreams yah it's almost like last question feeds into this question 09:50 < michaelfolkson> Just to confirm sipa. For CLEANSTACK you have to have a stack with a single element in it which has to be nonzero. Without CLEANSTACK a non-empty stack with multiple elements is ok as long as the top element is nonzero? 09:50 < glozow> WOOT 09:50 < murch> glozow: You've set us up 09:50 -!- MasterdonX [~masterdon@45.9.249.248] has joined #bitcoin-core-pr-reviews 09:50 < glozow> last question! What does it mean for script verify flags to be “soft forks?” How do the tests check this? 09:50 < sipa> michaelfolkson: correct 09:51 < glozow> hint: https://github.com/bitcoin/bitcoin/pull/10699 09:51 < emzy> michaelfolkson: thx for the sum up. 09:52 < glozow> bigger hint: https://github.com/bitcoin/bitcoin/blob/3caee16946575e71e90ead9ac531f5a3a1259307/src/script/interpreter.h#L36-L40 09:52 < murch> glozow: I think it means that no flags should increase the set of acceptable txes when they're turned on 09:52 < felixweis> these flags only apply to mempool policy. so older nodes will not accept and forward new transaction features. 09:52 < robot-dreams> michaelfolkson: Thanks! Just to confirm, in this PR would it be necessary to change `0 CLTV 1` into `0 CLTV DROP 1` as sipa mentioned above? 09:53 < michaelfolkson> sipa: And so without CLEANSTACK you could have a horrible non-empty stack with TRUE FALSE 3 and it would pass. I don't think I understand this... 09:53 < felixweis> because we can't verify the new rules, people might be ddosing us with invalid transactions under new (yet to be definded) soft fork rules 09:53 -!- slam45 [3feee5ba@63-238-229-186.dia.static.qwest.net] has quit [Remote host closed the connection] 09:53 < murch> glozow: TBH, I'm only getting that from interpreting your commit message, though (^_^)/ 09:53 < glozow> robot-dreams: yes, this PR enforces that the tests do CLEANSTACK 09:53 < glozow> (when they can) 09:53 < sipa> michaelfolkson: yes; what's hard to understand about that? 09:54 < michaelfolkson> Why should it pass? It is a mess haha 09:54 < sipa> why wouldn't it? 09:54 < dhruvm> glozow: script verify flags are soft forks because each new flag can only be more restrictive. The tests check that here: https://github.com/bitcoin/bitcoin/pull/19698/files#diff-cc0c6a9039a1c9fe38b8a21fe28391fffbac9b8531dfda0f658919a9f74b46baR229 by making sure that the flags are maximal after `TrimFlags`? 09:54 < sipa> the computation succeeded 09:54 < felixweis> the final check just looks at the top element 09:54 < glozow> murch dhruvm: yup, adding a flag can never increase the space of valid scripts 09:55 < sipa> michaelfolkson: say the script is a boring " OP_CHECKSIG"; normally you'd pass it a [] as input, and it'd leave [1] on the stack 09:55 < sipa> if you pass it [,,], it'll leave [,,1] on the stack instead 09:55 < glozow> so we add/subtract individual flags to check this, but what about combinations of flags like robot-dreams mentioned earlier? 09:55 < felixweis> michaelfolkson: maybe some fancy script designers wanted to do multiple conditional execution paths and the shortest definition to do both didn't leave the stack clean 09:55 < sipa> whatever the script was enforcing worked just fine, but there is garbage left 09:56 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:56 < glozow> hint: https://github.com/bitcoin/bitcoin/pull/19698/files#diff-cc0c6a9039a1c9fe38b8a21fe28391fffbac9b8531dfda0f658919a9f74b46baR328 09:56 < sipa> michaelfolkson: i think you have to see bitcoin script as a programming language, and that language used to be defined without cleanstack... so you write scripts that do what you want given those semantics 09:57 < sipa> now the language does have cleanstack, and in theory that means you need slightly different scripts to do what you want 09:57 < sipa> in practice... not really 09:57 < dhruvm> glozow: since the flags have dependencies, you probably can't do all combinations? 09:57 < michaelfolkson> Ok I guess I'm surprised because I always thought a dirty stack (in the context of CLEANSTACK) would always fail. I misunderstood the other ways a script could still pass 09:57 < glozow> dhruvm: yes! so what do we do instead? 09:58 < dhruvm> glozow: TrimFlags? 09:58 < glozow> er i mean, we don't do all of them because that'd be 2^n 09:58 < michaelfolkson> But thanks sipa felixweis 09:58 < felixweis> was there ever a transaction using "p2sh" before p2sh activated? in other words would p2sh soft fork from genesis fork the chain? 09:58 < glozow> that's a lotta testing 09:58 < robot-dreams> glozow pulls out the RNG 09:58 < glozow> yeah! we just do random combinations :P 09:58 < sdaftuar> felixweis: one i think 09:58 < glozow> sorry, rushed the last question a little 09:58 < sipa> sdaftuar: oh, really? 09:59 < glozow> We've reached the end of our program. Thanks everyone! And now, a word from our sponsor, jnewbery 09:59 < jnewbery> it's the reason we can't apply P2SH/segwit back to genesis, right? 09:59 < dhruvm> glozow: Does that makes the test failures hard to reproduce? 09:59 < felixweis> sdaftuar: thanks, was it someone just experimenting with all the opcodes? 09:59 < MarcoFalke> (slightly off-topic) There is also a fuzz test that does random combinations: https://github.com/bitcoin/bitcoin/blob/3caee16946575e71e90ead9ac531f5a3a1259307/src/test/fuzz/script_flags.cpp#L54 09:59 < sdaftuar> jnewbery: yes, trying to find my notes on it 09:59 < jnewbery> thanks glozow. That was great. Really good dive into some pretty complex parts of the code. 09:59 < jnewbery> Hope everyone enjoyed! 09:59 < glozow> dhruvm: yeah i guess, but these are mostly sanity checks for making sure the test you wrote was correct. meta-testing 🤷 09:59 < willcl_ark> thanks glozow! 09:59 < jnewbery> I just wanted to repeat my request for hosts from the start. I have a slot open next week for anyone who's keen. 10:00 < felixweis> thanks glozow!! 10:00 < sipa> dhruvm: i expect that in practice this is not a problem; if there were an actual softforkability bug somewhere that these tests catch, you'll suddenly have tons of combinations fail 10:00 < cangr> thanks a lot 10:00 < robot-dreams> sdaftaur: Is this related to the comment at the start of `GetBlockScriptFlags` that says "one historical block violated the P2SH rules"? 10:00 < thomasb06> thanks glozow 10:00 < jnewbery> (and every week after that) 10:00 < elle> Thanks glozow! that was awesome. really enjoy learning about Script 10:00 < sipa> glozow: thanks! 10:00 < robot-dreams> Thanks glozow, great session! 10:00 < pinheadmz> good show glozow and jnewbery ! 10:00 < emzy> Thanks glozow and all. I lerned a lot! 10:00 < glozow> thanks everyone ^_^ tough review club today, thanks for sticking with me 10:00 -!- elle [~ellemouto@155.93.227.251] has quit [Quit: leaving] 10:00 < darius27> thanks glozow!! I learned a lot 10:00 < MarcoFalke> dhruvm: I think it makes it harder to reproduce, as the randomness seed is unknown 10:00 < dhruvm> sipa: that makes sense. 10:00 < jnewbery> just message me if you're interested in hosting and I can put you on the roster 10:00 < jnewbery> #endmeeting 10:01 < sdaftuar> felixweis: https://github.com/bitcoin/bitcoin/pull/11739#issue-153727297 10:01 < murch> This one was fun :D 10:01 < dhruvm> thank you, glozow 10:01 -!- cangr [4d036b59@dynamic-077-003-107-089.77.3.pool.telefonica.de] has quit [Remote host closed the connection] 10:01 < glozow> murch: glad u had fun, happy birthday present to you! 10:01 < pinheadmz> ps glozow +100 for ascii art! esp the 🏴‍☠️ 10:01 < michaelfolkson> Thanks glozow! 10:02 < sdaftuar> There was one block that violated P2SH. that was before my time so i don't know who did it, but i believe it lines up with the debate over bip16 vs bip17? so possibly a test relating to that 10:02 < murch> glozow: Hey, no doxxing please :p 10:02 < glozow> pinheadmz: inspired by you 🙏 10:02 < jonatack> Thanks glozow. (I nominate dhruvm to host.) 10:02 < michaelfolkson> murch uses his date of birth as his private key. Doh 10:03 < robot-dreams> +1 to the dhruvm host nomination 10:03 < felixweis> sdaftuar: facinating 10:03 < murch> michaelfolkson: I'm just worried that someone uses a zodiac sign powered weapon on me 10:04 < dhruvm> I'm definitely looking forward to hosting when I have a PR worthy of an hour long conversation. 10:04 < glozow> dhruvm we just talked for script verification flags for an hour 10:04 < michaelfolkson> murch: The famous zodiac side channel attack 10:05 -!- pratapashutosh [67699876@103.105.152.118] has left #bitcoin-core-pr-reviews [] 10:05 < MarcoFalke> There are 400 open pulls ;) 10:05 -!- rage-proof [5f5af573@ip5f5af573.dynamic.kabel-deutschland.de] has quit [Remote host closed the connection] 10:06 -!- schulzemic [ada@gateway/vpn/mullvad/schulzemic] has quit [Quit: Konversation terminated!] 10:06 < dhruvm> I will take a look at open pulls and reach out to you, jnewbery. Thanks, jonatack robot-dreams glozow. 10:07 < michaelfolkson> If you're short on time I'm happy to help with the preloaded notes dhruvm 10:08 < dhruvm> Thanks, michaelfolkson. I will dm you. 10:08 < jonatack> dhruvm: i usually picked an interesting PR (bip 324, bip 155, package relay, wtxid relay, asmap, etc), and used it as an excuse to learn about and discuss a larger topic 10:09 < jonatack> dhruvm: yes, we help with reviewing the notes, no worries there 10:09 < sequel> thanks all 10:09 < dhruvm> Is there an outstanding p2p PR that folks are already curious about? 10:11 < glozow> https://github.com/bitcoin/bitcoin/pull/18261 hoho 10:12 < dhruvm> Wow, I'll add that to the list and look for another one :D 10:12 < jonatack> dhruvm: https://github.com/bitcoin/bitcoin/pulls/naumenkogs 10:13 < jonatack> https://github.com/bitcoin/bitcoin/pulls/jnewbery 10:13 < glozow> https://github.com/bitcoin/bitcoin/pull/20197 looks fun too 10:13 < michaelfolkson> That is excellent suggestion glozow. I wanted to revisit the latest Erlay changes 10:13 < jonatack> https://github.com/bitcoin/bitcoin/pulls/vasild 10:14 < michaelfolkson> Does gleb want to host if we do the Erlay one? 10:15 < sipa> if gleb doesn't, i may be up for doing an Erlay one... i'm very familiar with the concept but not up to date with the code, so it'd be a good opportunity for me to review that too 10:15 < sipa> (but not next week) 10:15 < jonatack> unit testing of peer eviction logic seems interesting too: https://github.com/bitcoin/bitcoin/pull/20477 10:17 < sdaftuar> sipa: are you going to lead off with a course on minisketch? that might be a few meetings by itself :) 10:17 < sipa> happy to do one on minisketch too :) 10:17 < felixweis> sipa: i would be curious to hear more about the backstory of gleb misunderstaning greg and that leading to erlay 10:18 < felixweis> (at said review club) 10:18 < sipa> felixweis: greg's idea was mempool reconciliation (nodes would keep a sketch of their entire mempool, and occasionally reconcile those with each other); gleb misunderstood (iirc, correct me if i'm wrong) and worked out a concept where every node keeps a sketch of "transactions it would have relayed to peer X", for every peer, and then peers reconcile those sketches with eachother 10:19 < dhruvm> Oooh, all great suggestions. Thanks. 10:19 < sipa> felixweis: which has the advantage that if there is an irreconcilable difference (double-spend, policy difference, ...) it only "costs" the reconciliation once 10:19 < sipa> rather than every attempt 10:20 < felixweis> ah! 10:22 < sequel> sipa felixweis meaning gleb's design is more performant and robust/fault tolerant? 10:22 < sipa> well, who knows... we'd have run into this problem if we'd have worked on full-mempool reconciliation instead, and perhaps found a solution to it 10:23 < sipa> but this was a much simpler way to get something working 10:24 < sipa> if there is interest in minisketch... i'm not sure a review club of the code is the right approach, as there is a huge prerequisite of understanding the concept and algorithms first 10:25 < sdaftuar> sipa: how do you think about the review burden of the minisketch library itself? should bitcoin core contributors think of that as code that has sufficient outside review in the library it's maintained at? 10:25 < sipa> sdaftuar: that's a good question 10:26 < sdaftuar> every time i click on gleb's pr thinking i'm going to review it, i remember that issue, and resolve to set aside more time later :) 10:26 < sipa> i think it doesn't live up to the same standard of code review as we'd expect for some other things 10:27 < sdaftuar> certainly we can reason about the downsides to errors there well enough 10:27 < sipa> on the other hand, i think the concept and algorithms are well reviewed, and (famous last words) i believe it's the kind of thing that's unlikely to have implementation issues that aren't immediately obvious in testing 10:30 < sipa> sdaftuar: yeah, assuming it's not a stack overflow or crash, worst case it should mean less efficient tx relay 10:31 < sipa> minisketch can certainly use some love with tests and CI and so on 10:34 < sipa> i recently wrote an inefficient python reimplementation that could help with review and testing: https://github.com/sipa/minisketch/pull/26/files 10:34 < sdaftuar> oh neat, that might help me -- thanks 10:39 < jonatack> meeting log is up at https://bitcoincore.reviews/19698 10:40 < michaelfolkson> sipa: There was a series of PR review clubs on BIP 157 earlier in the year. We could do something similar for Minisketch/Erlay if there's interest 10:40 < michaelfolkson> I guess we did Taproot commits too but spread over many months 10:44 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 10:47 -!- sequel [~sequel@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 240 seconds] 10:54 < glozow> jonatack THANKS FOR INCLUDING MY ASCII ART HEHE 10:54 < jnewbery> thanks jonatack! 10:59 < michaelfolkson> Why is the "I" sitting down haha. Very cool 12:07 -!- darius27 [516cb8be@cpc159747-finc22-2-0-cust189.4-2.cable.virginm.net] has quit [Remote host closed the connection] 12:08 < pinheadmz> michaelfolkson because the letter "I" is only enforced by policy, not consensus 12:09 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:10 < sipa> but there is no I in consensus 12:40 < jnewbery> but there is an 'us' 12:41 < jnewbery> #cheesybitcoinmotivationalposters 12:42 < sipa> #there_is_icy_in_policy 12:46 < pinheadmz> BITCOIN: Put the "us" back in "consensus" 13:07 -!- effexzi [uid474242@gateway/web/irccloud.com/x-epravqsodrzemcov] has quit [Quit: Connection closed for inactivity] 13:08 -!- novio [56d5b49e@lfbn-bor-1-476-158.w86-213.abo.wanadoo.fr] has quit [Ping timeout: 245 seconds] 13:18 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer] 13:36 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 13:41 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 13:50 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 13:52 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Remote host closed the connection] 13:52 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 13:52 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 13:53 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 14:04 -!- jesseposner [~jp@2601:643:8980:bfd2:359b:3052:cb08:82ec] has joined #bitcoin-core-pr-reviews 14:12 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews 14:37 -!- Moller40 [~mr@45.135.187.15] has joined #bitcoin-core-pr-reviews 14:37 -!- Moller40 [~mr@45.135.187.15] has quit [Remote host closed the connection] 15:40 -!- provoostenator_ [~quassel@provoostenator.sprovoost.nl] has quit [Quit: No Ping reply in 180 seconds.] 15:41 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews 16:00 -!- TheRec_ [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 16:01 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 246 seconds] 16:17 -!- davterra [~davterra@68.235.43.158] has quit [Ping timeout: 240 seconds] 16:26 -!- anir [40bba0b7@64.187.160.183] has quit [Remote host closed the connection] 16:31 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has joined #bitcoin-core-pr-reviews 16:33 -!- da39a3ee5e6b4b0d [~da39a3ee5@171.5.161.165] has quit [Client Quit] 16:35 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 260 seconds] 16:39 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has joined #bitcoin-core-pr-reviews 17:23 -!- davterra [~davterra@static-198-54-131-92.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 17:27 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 17:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 17:35 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 17:35 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services] 17:46 -!- jesseposner [~jp@2601:643:8980:bfd2:359b:3052:cb08:82ec] has quit [Ping timeout: 260 seconds] 17:57 -!- tylerlevine6 [~hardforkt@li120-195.members.linode.com] has joined #bitcoin-core-pr-reviews 17:59 -!- tylerlevine6 [~hardforkt@li120-195.members.linode.com] has quit [Client Quit] 17:59 -!- tylerlevine [~hardforkt@li120-195.members.linode.com] has joined #bitcoin-core-pr-reviews 18:04 -!- tylerlevine [~hardforkt@li120-195.members.linode.com] has quit [Quit: The Lounge - https://thelounge.chat] 18:15 -!- tlev7 [~tlev@li120-195.members.linode.com] has joined #bitcoin-core-pr-reviews 18:15 -!- tlev7 [~tlev@li120-195.members.linode.com] has quit [Client Quit] 18:15 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 240 seconds] 18:15 -!- tlev [~tlev@li120-195.members.linode.com] has joined #bitcoin-core-pr-reviews 19:28 -!- gleb [~gleb@178.150.137.228] has quit [Ping timeout: 256 seconds] 19:31 -!- gleb [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews 19:37 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz] 19:44 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-pr-reviews 20:52 -!- asdf22 [ab42a113@171.66.161.19] has joined #bitcoin-core-pr-reviews 20:54 -!- Jeremy25Wolf [~Jeremy25W@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 20:59 -!- Jeremy25Wolf [~Jeremy25W@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 21:03 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz] 21:06 -!- pinheadmz [~pinheadmz@71.190.30.138] has joined #bitcoin-core-pr-reviews 21:28 -!- pinheadmz [~pinheadmz@71.190.30.138] has quit [Quit: pinheadmz] 21:50 -!- da39a3ee5e6b4b0d [~da39a3ee5@mx-ll-171.5.161-165.dynamic.3bb.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:58 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has quit [Quit: leaving] 22:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 22:10 -!- tralfaz [~davterra@static-198-54-131-92.cust.tzulo.com] has joined #bitcoin-core-pr-reviews 22:12 -!- davterra [~davterra@static-198-54-131-92.cust.tzulo.com] has quit [Read error: Connection reset by peer] 23:32 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 23:33 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 23:37 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 23:38 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection] 23:38 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews 23:38 -!- ctrlbreak_MAD [~ctrlbreak@159.2.182.106] has joined #bitcoin-core-pr-reviews 23:42 -!- ctrlbreak [~ctrlbreak@159.2.182.106] has quit [Ping timeout: 256 seconds] 23:45 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer] 23:47 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews