--- Day changed Wed Feb 12 2020 01:33 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 03:05 -!- Dandre48Bayer [~Dandre48B@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews 03:10 -!- Dandre48Bayer [~Dandre48B@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 260 seconds] 03:17 -!- pkr [~pkr@158.140.254.215] has quit [Read error: Connection reset by peer] 03:28 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 04:02 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 04:05 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 04:35 -!- provoostenator_ [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews 04:36 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection] 04:38 -!- provoostenator_ [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection] 04:39 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews 04:41 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 04:42 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 05:00 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 05:00 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 05:00 -!- TheRec_ [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 05:00 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 240 seconds] 05:15 -!- felixfoertsch [~felixfoer@i6DFA6AD0.versanet.de] has joined #bitcoin-core-pr-reviews 06:02 -!- molz_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 06:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 06:31 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 06:33 -!- seven_ [~seven@2a00:ee2:410c:1300:7908:6885:9ac7:51bb] has joined #bitcoin-core-pr-reviews 06:37 -!- seven__ [~seven@2a00:ee2:410c:1300:61a0:fa52:2231:266b] has quit [Ping timeout: 245 seconds] 06:42 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 06:43 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 06:47 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 07:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 07:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 07:40 -!- rjected [~rjected@natp-128-119-202-137.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 07:55 -!- rjected [~rjected@natp-128-119-202-137.wireless.umass.edu] has quit [Ping timeout: 260 seconds] 07:55 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 07:57 -!- rjected [~rjected@natp-128-119-202-137.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 08:04 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 08:10 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 08:11 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Client Quit] 08:11 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 08:12 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 08:37 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 09:05 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 09:05 -!- fodediop [~fodediop@41.83.23.178] has joined #bitcoin-core-pr-reviews 09:05 -!- fodediop is now known as fode 09:16 -!- SirRichard [~MaxSikors@cpe-98-28-69-149.columbus.res.rr.com] has joined #bitcoin-core-pr-reviews 09:17 -!- SirRichard [~MaxSikors@cpe-98-28-69-149.columbus.res.rr.com] has quit [Client Quit] 09:35 -!- rjected [~rjected@natp-128-119-202-137.wireless.umass.edu] has quit [Ping timeout: 265 seconds] 09:45 < jnewbery> Hi folks. We'll get started in about 15 minutes 09:50 -!- lightlike [~lightlike@p200300C7EF140400E57B0BA00317E093.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:54 -!- michaelfolkson [~textual@85.255.237.148] has joined #bitcoin-core-pr-reviews 09:54 -!- SirRichard [~MaxSikors@cpe-98-28-69-149.columbus.res.rr.com] has joined #bitcoin-core-pr-reviews 09:56 -!- michel_foucault [~michel_fo@185.104.185.249] has joined #bitcoin-core-pr-reviews 10:00 -!- rjected [~rjected@natp-128-119-202-173.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 10:00 < fode> hi 10:00 < jnewbery> #startmeeting 10:00 < ajonas> Hi 10:00 < pinheadmz> hi 10:00 < fode> hello 10:00 < fjahr> hi 10:00 < jonatack> hi 10:00 < michaelfolkson> hi 10:00 < lightlike> hi 10:00 < jnewbery> Hi folks. Welcome to this week's review club meeting! 10:00 < kanzure> hi 10:01 < jnewbery> Feel free to say hi to let everyone know you're here. 10:01 < jnewbery> Before we start, I'm always looking for volunteer hosts for these meetings. I'll help you choose a PR, and help you prepare notes and questions. Just let me know if you're interested and we'll slot you in. 10:01 < emzy> Hi 10:01 < michaelfolkson> DM you jnewbery? 10:02 < jnewbery> yes! 10:02 < fanquake> hi 10:02 < jnewbery> Hosting a review club meeting forces you to really understand a PR, so I think it's a really worthwhile learning experience. You can ask any of the previous hosts if you don't believe me 10:02 < jnewbery> Normal reminder: everyone is here to learn, and no questions are stupid. Feel free to jump in and ask questions at any point. 10:02 < jnewbery> I heard this nice quote from Steven Strogatz the other day: 10:02 -!- hanhua [68850952@104.133.9.82] has joined #bitcoin-core-pr-reviews 10:02 < jnewbery> We're all confused; confusion is the normal state of affairs when you're trying something really hard, and when you're exploring the unknown, [...] you can trust us that we're all on the same team trying the figure this out together and don't worry about looking stupid, I'm confused over here too. 10:03 < jnewbery> I hope that's how people see review club. We're all just trying to be a little less confused 10:03 < michaelfolkson> Haha nice 10:03 < jnewbery> ok, first up: who managed to review the PR? (y/n) 10:03 < fode> n 10:03 < fjahr> y 10:03 < lightlike> y 10:03 < pinheadmz> cramming rn :-) But i have read through sipa taproot branch 10:03 < michaelfolkson> y 10:03 < jonatack> y 10:04 -!- ColloquyUser [~colloquyu@072-186-173-059.biz.spectrum.com] has joined #bitcoin-core-pr-reviews 10:04 < nehan_> hi 10:04 < jnewbery> hi nehan_ 10:04 < nehan_> y 10:05 < jnewbery> For the folks that looked at the PRs, any high-level thoughts? Concept ACK/NACKs? 10:05 < jonatack> acked both 10:05 < jnewbery> or any general questions about the script interpreter in Bitcoin Core? 10:06 < emzy> n 10:06 < lightlike> concept ack 10:06 < andrewtoth> hi 10:06 < michaelfolkson> Concept ACK. I like the PR being broken down into smaller PRs as Nicolas said. My only concern is that this approach kind of assumes Taproot is inevitable (which we really shouldn't do) 10:06 < SirRichard> hi 10:06 < fjahr> code review ack for the refactor one, the op_if one I have not found anything yet but want to put a little more time into it 10:07 < jnewbery> michaelfolkson: I don't think that's true. These PRs don't leave the code in a worse place, even if taproot doesn't happen 10:07 < michaelfolkson> That's fair. sipa said the motivation for touching consensus wouldn't be there without Taproot 10:07 < jnewbery> I'd agree if the intermediate state made the code less clear or performant, but these changes are both improvements 10:07 < lightlike> actually I was meaning to ask what the relation of #16902 to taproot/schnorr is? 10:08 < pinheadmz> i agree with jnewbery the fact that witness versions are extensible up to 31 makes it reasonable to abstract out executeWitnessProgram 10:08 < michaelfolkson> Just a thought. I really like splitting it (makes it much more understandable for me) so I'm not arguing against this approach 10:08 < jnewbery> right - the calculus of whether to spend time on this changes if we think taproot will happen, but the changes are all good I think 10:09 < jnewbery> lightlike: good question! Anyone know why the OP_IF change is relevant for taproot? 10:10 < jonatack> the 201 opcode limit 10:10 < pinheadmz> hm is it because you only "pay" for sigops that you execute? 10:10 < michaelfolkson> Because Taproot no longer has limits on script size, number of op codes 10:10 < pinheadmz> (in taproot) 10:10 < jnewbery> michaelfolkson: yes! exactly 10:10 < jonatack> from the BIP "The maximum non-push opcodes limit of 201 per script does not apply." 10:11 < jonatack> and footnote 10: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#cite_note-10 10:11 < jnewbery> exactly - in tapscript, there can be more than 201 opcodes in a script, so any quadratic performance behaviour could be much worse 10:12 < michaelfolkson> That was a great blog post of Sergio's. I should check some of his other blogs out 10:12 < michaelfolkson> https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/ 10:12 < jnewbery> ok, let's get into some of the more low-level questions 10:12 < jnewbery> The fuctions in ConditionStack() contain asserts. What happens if these asserts are hit? 10:13 < michaelfolkson> Asserts generally terminate the program if false. Is that what you mean? 10:13 < jonatack> assertion failed -> Aborted 10:14 < jonatack> (right?) 10:14 < jonatack> https://en.cppreference.com/w/cpp/error/assert 10:15 < jnewbery> hmmm, don't they get caught? 10:15 < jnewbery> or is that just throws? 10:16 < jonatack> can reverse one to find out :p 10:17 < jnewbery> ok, I'm wrong. asserts don't get caught in C++ 10:17 < jnewbery> (I told you I'm also confused) 10:17 < jnewbery> why do we expect these asserts never to be hit? 10:18 < lightlike> afaik the asserts are removed by the compiler if NDEBUG is not defined, so they should not be relied upon. 10:18 < jonatack> when i'm testing PRs I often add compile (static assert) or run time (assert) to check my assumptions and so far when they failed, it aborts 10:18 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [] 10:18 -!- ColloquyUser [~colloquyu@072-186-173-059.biz.spectrum.com] has quit [Quit: Colloquy for iPhone - http://colloquy.mobi] 10:19 < jnewbery> lightlike: yes, I think you're right 10:19 < jonatack> lightlike: i'm not sure if that's a c++17 feature 10:20 < jonatack> (i mean, if it's c++17 and up or also with c++11) 10:20 < lightlike> jonatack: pretty sure that is a very old feature 10:20 < jnewbery> the asserts appear in `pop_back()` and `toggle_top()`, which are only called in one place each, where we've already checked the stack is non-empty 10:20 < jnewbery> https://github.com/bitcoin/bitcoin/pull/16902/files#diff-be2905e2f5218ecdbe4e55637dac75f3R561 10:20 < jnewbery> https://github.com/bitcoin/bitcoin/pull/16902/files#diff-be2905e2f5218ecdbe4e55637dac75f3R569 10:21 -!- B [~B@072-186-173-059.biz.spectrum.com] has joined #bitcoin-core-pr-reviews 10:21 < jonatack> lightlike: agreed, i was thinking of this: "NDEBUG is defined at the point where assert is last defined or redefined (i.e., where the header or was last included); (since c++17)" 10:21 -!- B is now known as Guest13226 10:21 < jnewbery> next question. This PR swaps out a vector of booleans for a pair of integers. How are we able to express a vector of booleans as a pair of integers? What observation about the use of the vector makes this possible? 10:21 < emzy> why using an assert insted of an error log entry? 10:22 < nehan_> why assert() instead of static_assert()? 10:23 < nehan_> as suggested in the developer docs 10:23 < jb55> lightlike: NDEBUG functionality is disabled in core. asserts happens with or without it enabled 10:23 < jonatack> jb55: ah 10:23 < lightlike> jb55: ok, thanks 10:24 < jonatack> nehan_: i think static asserts require a bool constexpr 10:24 < michaelfolkson> The two integers are size of implied stack (m_stack_size) and position of the first false value on the implied stack (m_first_false_pos) 10:24 < jnewbery> nehan_: I don't think it's possible to do a static_assert here because it's asserting on runtime behaviour 10:24 < jonatack> so they can't be dynamic values determined at run time... thought i could very well be confused, recently forgot that in a pr review i made 10:25 < jnewbery> emzy: I think this is a good description of what asserts are for: https://stackoverflow.com/a/28974029/933705 10:25 < nehan_> jnewbery: jonatack: ah thanks 10:25 < jnewbery> "The purpose of assert is the guarantee that the programmer doesn't make mistakes." 10:26 < lightlike> there was some trouble with misplaced asserts a some years ago with the Bitcoin Unlimited fork, see e.g. https://blog.erratasec.com/2017/03/assert-in-hands-of-bad-coders.html (with a comment of gmaxwell) 10:26 < jnewbery> michaelfolkson: yep, that's what they're being used for, but we're losing some information there. We don't know the state of all booleans on the stack. Why is that ok? 10:26 -!- rjected [~rjected@natp-128-119-202-173.wireless.umass.edu] has quit [Ping timeout: 240 seconds] 10:26 < michaelfolkson> So you'd use an assert over a test when it is critically important? 10:27 < nehan_> might be good to discuss bitcoin-core policy on when to assert vs. log or bump up failure. is that documented anywhere? 10:27 -!- docallag [~textual@cpc103056-sgyl39-2-0-cust1444.18-2.cable.virginm.net] has joined #bitcoin-core-pr-reviews 10:27 < jnewbery> asserts are a check on the programing logic. throws are for runtime error conditions that can be recovered from. 10:28 < jnewbery> the expectation is that asserts are *never* hit when running the code in the wild 10:28 < lightlike> so asserts, if they can somehow be triggered by our peers, have the potential to bring down large parts of the network. 10:28 < emzy> as I understand it is a assert is triggert it is not anymore save to execute the program and better to exit. 10:29 < fjahr> see also use of assert in the second pr where sipa explicitly comments that this code should never be hit 10:29 < jnewbery> nehan_: I'm not sure it is documented anywhere. It's a good question 10:29 < jnewbery> fjahr: I think that's slightly different, and is to quiet a build warning 10:30 < jnewbery> here: https://github.com/bitcoin/bitcoin/pull/18002/files#diff-be2905e2f5218ecdbe4e55637dac75f3R1464 10:30 < jonatack> agree, i see asserts as sanity checks that should never be hit under expected circumstances 10:30 < nehan_> jnewbery: to answer your question about why you don't need all booleans on the stack, it's because once you hit a false you will not execute anything after that 10:31 -!- rjected [~rjected@natp-128-119-202-173.wireless.umass.edu] has joined #bitcoin-core-pr-reviews 10:31 < MarcoFalke> It is documented a bit in ./src/util/check.h, I think 10:31 < jnewbery> nehan_: yes, exactly. The calling code can only do one of the following: 10:32 < jnewbery> - push/pop from the top of the stack 10:32 < jnewbery> - toggle the top of the stack 10:32 < jnewbery> - check if all values are true 10:33 < jnewbery> because of that limited interface to the stack, internally the stack doesn't need to track more information than stack depth and first false entry 10:33 < MarcoFalke> util/check.h defines a CHECK_NONFATAL, which actually throws, instead of terminating (like an assert) 10:33 < jonatack> MarcoFalke: NonFatalCheckError/CHECK_NONFATAL? 10:33 < jonatack> right 10:34 < MarcoFalke> Obviously we don't want to use that in consensus or validation code 10:34 < jnewbery> And to add a bit more confusion, we also have an 'AbortNode' function in logs and attempts to shutdown cleanly 10:35 < jnewbery> *in validation which logs and attempts to shutdown cleanly 10:35 < fjahr> jnewbery: I saw that but I understood it as the warning would be there "if the logic got messed up in future". I removed it now and did not see any new compiler warnings. 10:36 -!- Guest13226 [~B@072-186-173-059.biz.spectrum.com] has quit [Ping timeout: 265 seconds] 10:36 < jnewbery> fjahr: oh, I think you're right 10:37 < jnewbery> everyone happy with the optimized 'stack' implementation? 10:38 < jnewbery> here: https://github.com/bitcoin/bitcoin/pull/16902/files#diff-be2905e2f5218ecdbe4e55637dac75f3R297 10:39 < jnewbery> ok, next question: In the notes, I’ve written “If fExec is false, then we’re in a branch that shouldn’t be executed and we continue to the next iteration of the while loop.” That’s not quite the full story. When do we not continue to the next iteration while fExec is false? 10:39 < jonatack> We don't continue if fExec is false, when we are inside an OP_IF...OP_ENDIF conditional? 10:40 < jonatack> e.g. ... if (fExec || (OP_IF <= opcode && opcode <= OP_ENDIF)) 10:40 -!- fode [~fodediop@41.83.23.178] has quit [Quit: WeeChat 2.7] 10:41 -!- B [~B@072-186-173-059.biz.spectrum.com] has joined #bitcoin-core-pr-reviews 10:41 < jnewbery> jonatack: right. If there's we're in a non-executing branch and the next opcode is OP_IF, OP_NOTIF, OP_ELSE or OP_ENDIF, we drop into the switch statement 10:41 -!- B is now known as Guest55579 10:42 < jnewbery> https://github.com/bitcoin/bitcoin/blob/2bdc476d4d23256d8396bb9051a511f540d87392/src/script/interpreter.cpp#L348-L349 10:42 < jonatack> oof good, i can leave the ack :p 10:43 < jnewbery> we also execute everything above that, even if we're in the unexecuted branch: https://github.com/bitcoin/bitcoin/blob/2bdc476d4d23256d8396bb9051a511f540d87392/src/script/interpreter.cpp#L310-L347 10:44 < jnewbery> so if there's a non-existent opcode in the script, the script always fails (even if that non-existent opcode is in an unexecuted branch) 10:44 -!- unbend [~unbend@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:45 < jnewbery> ok, final question: Did you run the verify_script() benchmark? Does this PR make a difference to performance? 10:47 -!- Guest55579 [~B@072-186-173-059.biz.spectrum.com] has quit [Ping timeout: 260 seconds] 10:47 < jnewbery> Alright, anyone have any other questions? Thoughts? 10:47 < michaelfolkson> Sorry I didn't get that far to do that 10:48 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 260 seconds] 10:48 < unbend> got here late is there a bouncer / log to check? ':0 10:48 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 10:48 < nehan_> PRs like this are terrifying because they touch consensus code 10:48 -!- rjected [~rjected@natp-128-119-202-173.wireless.umass.edu] has quit [Ping timeout: 240 seconds] 10:48 < jnewbery> nehan_: yeah, we don't touch this stuff much 10:49 < jnewbery> hopefully these two are small and contained enough that they're ok to review 10:49 < jnewbery> what would make it less terrifying? 10:49 < michaelfolkson> Any chance of any more PRs being rolled out of sipa's Taproot PR? 10:49 < lightlike> script seems to be even more terrifying than other consensus code like in validation 10:50 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 10:50 < jnewbery> michaelfolkson: I expect so. I plan to discuss them here if more PRs are opened 10:50 < jnewbery> lightlike: interesting. How so? 10:50 < michaelfolkson> The Taproot PR would be a monstrous PR review club in its current form haha 10:50 -!- michaelfolkson [~textual@85.255.237.148] has quit [Quit: Sleep mode] 10:51 < lightlike> just my impression. there are quite some PRs changing validation code, while script is touched almost never. Possibly, the quality/accessibility of code is better in validation.cpp? 10:52 < fjahr> did not run the benchmarks yet but will do so before finishing the review 10:52 < jonatack> Sorry, the internet connection fitzed. I wanted to mention that I found the study notes really helpful. 10:53 < fjahr> we could also review specific commits of taproot in the club 10:53 < jnewbery> lightlike: maybe. There are ongoing projects that we want to do in validation.cpp (eg splitting net_processing/validation onto different threads). That stuff makes slow progression. 10:53 < jonatack> And kudos to MarcoFalke for the related fuzzing test to check today's PR. 10:53 < jnewbery> but we very rarely touch script except fo a softfork 10:53 < MarcoFalke> lol, that fuzz test is really simple 10:54 < MarcoFalke> The fuzzer should exhaust it in less than a minute. I was too lazy to write a unit test 10:54 < jnewbery> I had a quick look for unit tests for the script interpreter and didn't find anything that tested the if/else opcodes 10:54 < nehan_> question: suppose some nodes upgrade to use this new, faster code. is there any way the existence of the old nodes could cause a consensus failure, or upheaval on the network? they would take a longer time to validate a block that stressed this. 10:55 < jnewbery> nehan_: great question! 10:55 < jnewbery> does anyone have thoughts about that? 10:56 < jnewbery> we have 4 minutes left. Now's your chance if you've been shy so far 10:56 < fjahr> nehan_: you mean after taproot is activated? 10:57 < jonatack> nehan_: Older software running non-tapscript? The limit is in place and should be backward compatible, no? 10:57 -!- michel_foucault [~michel_fo@185.104.185.249] has quit [Quit: michel_foucault] 10:57 < nehan_> I imagine old nodes won't understand taproot and so won't execute that script anyway, right? And perhaps the current opcode limit bounds the difference between the slowest un-upgraded node and the fastest upgraded node. 10:58 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving] 10:58 -!- SirRichard [~MaxSikors@cpe-98-28-69-149.columbus.res.rr.com] has quit [Quit: SirRichard] 10:58 < jonatack> It's a soft fork, not a hard fork, so a narrowing with backward compat preserved unless i'm confused 10:58 < nehan_> old nodes won't execute taproot scripts which stressed that code, that is. 10:59 < nehan_> yes, i'm not suggesting there would be a fork because of rules. but imagine if a performance improvement made new nodes many many times faster than old nodes, and the old nodes couldn't keep up. 10:59 < jnewbery> nehan_: I think that's right. Pieter estimates in the PR notes that a block that fully exploits this slow behaviour can take up to 0.25 seconds to validate. That's not enough to cause any network partition concerns 10:59 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 11:00 < jnewbery> ok, that's time folks. Thanks for coming. See y'all next week 11:00 < jnewbery> #endmeeting 11:00 < nehan_> has anyone thought about the impact of different verification times across the network? maybe it's not important? 11:00 < nehan_> thanks! 11:00 < emzy> thanks jnewbery and all others! 11:01 < lightlike> thanks! 11:02 < jonatack> yes, my thinking as well 11:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 11:02 < fjahr> yeah, i think your right but it's interesting. the biggest difference in validation time would probably be between the fastest (hardware) non-taproot node and the slowest taproot node. but given that we have nodes with all kinds of different hardware on the network now and these have different validation times I think there is no real impact. 11:02 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 11:03 < nehan_> fjahr: i think you're right 11:04 < jonatack> Lost the connection again. Curious to catch up with the discussion. It seems to me though that these changes are strictly better. 11:05 < jonatack> Great question though! 11:05 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has quit [Read error: Connection reset by peer] 11:05 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 11:05 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 11:06 < unbend> How easy is it that a block to exploit this validation slow down? 250 ms / block won't affect block relay much but would increase initial sync by +14 hours / 210e3 blocks 11:07 < unbend> .25*210e3/3600 = 14.6 hrs 11:08 -!- rjected [~rjected@eduroamgw.cs.umass.edu] has joined #bitcoin-core-pr-reviews 11:09 < lightlike> unbend: i think the 0.25s is just an upper bound, because it requires unrealistic transactions with multiple nested IFs that don't usually occur in the actual chain because they make no sense. 11:10 < unbend> ah i see, I'm mainly talking blind because I got here late ':] 11:12 < unbend> I figured it was something tailored like the 4mb segwit blocks 11:12 < unbend> I'll review the notes/logs, thanks for hosting 11:14 < jnewbery> Meeting Log is posted: https://bitcoincore.reviews/16902.html 11:24 -!- rjected [~rjected@eduroamgw.cs.umass.edu] has quit [Quit: WeeChat 2.7] 11:28 < aj> "witness versions are extensible up to 31" ? you mean 16? 11:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 11:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 11:45 < jonatack> pinheadmz: ^ 11:48 < pinheadmz> ha yes thanks :-) 11:51 < aj> pinheadmz: (where'd 31 come from?) 11:52 < pinheadmz> aj: oh man, i hate to say it but I am working on another blockchain project that is 100% segwit only and it allows for up to 32 witness program versions 11:52 < aj> ah, fair enough then! 12:09 -!- docallag [~textual@cpc103056-sgyl39-2-0-cust1444.18-2.cable.virginm.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 12:16 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:34 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 12:38 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has quit [Read error: Connection reset by peer] 12:39 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 12:45 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving] 12:46 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 12:46 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Client Quit] 13:44 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 14:06 -!- michel_foucault [~michel_fo@185.104.185.249] has joined #bitcoin-core-pr-reviews 14:12 -!- michel_foucault [~michel_fo@185.104.185.249] has quit [Quit: michel_foucault] 14:27 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 14:28 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 14:33 -!- hanhua [68850952@104.133.9.82] has quit [Remote host closed the connection] 14:33 -!- rjected [~rjected@2600:380:bd33:9604:ed6a:2199:c245:f6b9] has joined #bitcoin-core-pr-reviews 14:38 -!- jungly [~jungly@host243-191-dynamic.1-87-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 14:50 -!- rjected [~rjected@2600:380:bd33:9604:ed6a:2199:c245:f6b9] has quit [Ping timeout: 240 seconds] 14:52 -!- rjected [~rjected@2607:fb90:6023:a28d:e783:c53d:14fd:657e] has joined #bitcoin-core-pr-reviews 15:12 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 15:23 -!- rjected [~rjected@2607:fb90:6023:a28d:e783:c53d:14fd:657e] has quit [Ping timeout: 240 seconds] 15:33 -!- lightlike [~lightlike@p200300C7EF140400E57B0BA00317E093.dip0.t-ipconnect.de] has quit [Quit: Leaving] 16:00 -!- seven_ [~seven@2a00:ee2:410c:1300:7908:6885:9ac7:51bb] has quit [Ping timeout: 246 seconds] 16:02 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 16:05 -!- fox2p [~fox2p@cpe-66-108-32-173.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 16:17 -!- seven_ [~seven@2a00:ee2:410c:1300:bd4f:8f0c:252f:f360] has joined #bitcoin-core-pr-reviews 16:32 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Remote host closed the connection] 17:06 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 17:06 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 17:06 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 17:07 -!- TheRec_ [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer] 19:53 -!- felixfoertsch23 [~felixfoer@i6DFA6CEB.versanet.de] has joined #bitcoin-core-pr-reviews 19:54 -!- felixfoertsch [~felixfoer@i6DFA6AD0.versanet.de] has quit [Ping timeout: 260 seconds] 20:46 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Ping timeout: 240 seconds] 21:03 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 21:23 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 21:24 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 21:30 -!- vindard [~vindard@190.83.165.233] has quit [Remote host closed the connection] 21:31 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 21:44 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 21:45 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 22:04 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 22:06 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 22:19 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 22:23 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 22:25 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 22:26 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 22:46 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 22:46 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 22:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 22:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 23:06 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 23:06 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 23:21 -!- jungly [~jungly@79.8.200.97] has joined #bitcoin-core-pr-reviews 23:27 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 23:27 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 23:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 23:45 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 23:47 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has quit [Read error: Connection reset by peer] 23:48 -!- harrigan [~harrigan@ptr-93-89-242-149.ip.airwire.ie] has joined #bitcoin-core-pr-reviews