--- Log opened Wed May 25 00:00:33 2022
00:02 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
00:06 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
00:08 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
00:25 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
01:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 240 seconds]
01:11 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews
01:12 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
01:24 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
01:29 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
01:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
01:41 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
01:42 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
01:46 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 246 seconds]
01:59 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
02:30 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
02:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 260 seconds]
03:03 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 246 seconds]
03:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
03:10 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
03:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 258 seconds]
03:17 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
03:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
04:22 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 258 seconds]
04:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 240 seconds]
04:30 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
04:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
04:46 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
04:52 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 276 seconds]
04:56 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
05:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 255 seconds]
05:03 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
05:08 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
05:08 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
05:19 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
06:24 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
06:37 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
06:42 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 246 seconds]
06:55 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
07:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Remote host closed the connection]
07:55 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
07:59 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 246 seconds]
07:59 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 260 seconds]
08:12 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
08:17 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
08:28 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
08:29 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
08:33 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 255 seconds]
08:34 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
08:40 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
08:46 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
08:51 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
08:58 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
09:00 -!- sr_gi[m] [~srgimatri@2001:470:69fc:105::1:c14c] has quit [Quit: You have been kicked for being idle]
09:00 -!- Zenton [~user@user/zenton] has quit [Ping timeout: 260 seconds]
09:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
09:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 255 seconds]
09:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
09:31 < michaelfolkson> Just reading the conversation log from last week's. Why does a sane Miniscript need to not mix timelock units (block/time)? Why does the timelock unit have to be consistent across the entire Miniscript for it to be considered sane?
09:32 < michaelfolkson> I get it is better for consistency. Does it introduce a malleability vector?
09:33 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:34 < sipa> Because the spending transaction can only have one of the two.
09:34 < sipa> If you're required to have both a timelock and a heightlock on the spending tx, that means it's just unspendable.
09:34 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
09:36 < michaelfolkson> If it was a script summarized by X OR Y. X had a timelock with block. Y had a timelock with time. Not sane?
09:36 < sipa> That's perfectly fine, and would be considered sane.
09:37 < sipa> It's only when you have a branch in the script that requires both timelock and heightlock that's a problem.
09:38 < michaelfolkson> Ok thanks. So not a strict requirement ("must not in any circumstances" kinda thing)
09:38 < sipa> (timelock) AND (heightlock) is unspendable
09:38 < sipa> so e.g. (A signs) OR ((B signs) AND (timelock) AND (heightlock)) would be considered not sane.
09:39 < sipa> Even though it can be spent by A, its apparently policy doesn't match the actual script (whose actual policy is just "A signs", because the other branch is unusable).
09:42 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has quit [Quit: Connection closed]
09:45 < michaelfolkson> Ok and on duplicate keys it is a similar deal right? You can repeat a key across branches? But not sane if key is repeated on a single branch?
09:45 < sipa> That's kind of the opposite.
09:46 < sipa> With duplicate keys it may be possible to construct new spending paths by observing existing ones.
09:46 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
09:46 < sipa> So that's just a malleability issue.
09:47 < sipa> @michaelfolkson I really would appreciate it if you'd stop talking my answers from IRC and put them on stackexchange.
09:47 < sipa> If you want an answer on SE, I can write one myself, that's appropriate for the medium.
09:48 < michaelfolkson> So it could be a malleability issue. But there are example sane Miniscripts with repeated key on a single branch and example sane Miniscripts with repeated key across branches?
09:48 < michaelfolkson> [17:47:54]  <sipa> If you want an answer on SE, I can write one myself, that's appropriate for the medium.
09:48 < michaelfolkson> Just trying to save you time. This is useful for me (and I'm assuming for others given this channel isn't logged)
09:49 < michaelfolkson> But sure, feel free to post an answer and I won't include it in my attempted answer
09:49 < sipa> Then ask the question on SE directly, and perhaps point me to it.
09:50 < michaelfolkson> Ok here is the link: https://bitcoin.stackexchange.com/questions/113878/what-is-a-sane-miniscript-how-does-it-differ-to-a-valid-miniscript
09:50 -!- paul_c [~paul_c@pool-72-66-70-127.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
09:50 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:51 < sipa> I'm trying to be helpful here, explaining things to you. If your goal isn't to learn yourself, but to turn it nearly literal transliterations on another medium, there are better ways.
09:51 < sipa> I don't mind you writing your own answer in your own words, if you understood it.
09:51 < sipa> But this way, I just get the impression you want to you my answer from brownie points.
09:51 < sipa> *use
09:52 < michaelfolkson> Well I refer back to the SE answers (and I assume others do too) at a later point. I get you are trying to be helpful (as always) and it is appreciated
09:52 < sipa> I obviously can't stop you from quoting me or using my answers in whatever way you see fit, but if this continues I'm just going to stop answering you on IRC.
09:53 < michaelfolkson> Would you rather I just not accredit you at all? Or post a question and then ask you to answer it directly on StackExchange? I've always struggled with this
09:53 < michaelfolkson> If you explain it better than I could I'd like to refer back to it in future
09:54 < michaelfolkson> I'm trying to be helpful too (even if it doesn't seem like it)
09:54 < sipa> If you want an answer on SE, ask it there, and see if someone answers it. If you don't get an answer, you can ping people for it.
09:56 -!- Franko [~Franko@186.84.21.160] has joined #bitcoin-core-pr-reviews
09:56 < michaelfolkson> It often doesn't get answered (people are busy) but ok.
09:57 < sipa> If you want an answer on IRC, ask it here. I'm happy to explain things to you or others, and I'm sure others are too. But this approach you're using gives me the impression you don't care about understanding it yourself (if you did, you could write something yourself instead of translitering my explaination directly), and just want to turn it into an SE answer.
09:57 < sipa> If it doesn't get answered, you can point to it.
09:57 < michaelfolkson> As I said I refer back to it. And your explanations are better than your explanations being reworded by me
09:57  * michaelfolkson shrugs
09:58 -!- OliverOff [~OliverOff@187.85.172.39] has joined #bitcoin-core-pr-reviews
09:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
10:00 < stickies-v> #startmeeting
10:00 -!- d65 [~d@208.127.227.161] has joined #bitcoin-core-pr-reviews
10:00 < larryruane> hi
10:00 < kevkevin> Hey guys new here, will be mostly lurking today
10:00 < theStack> hi
10:00 < schmidty> hi
10:01 < svav> Hi
10:01 < stickies-v> welcome everyone! We'll be continuing our review of #24148 (https://bitcoincore.reviews/24148-2). Last week we covered some of the Miniscript fundamentals, this week we'll dive deeper into the new MiniscriptDescriptor output descriptor implementation.
10:01 -!- __gotcha [~Thunderbi@79.132.248.217] has joined #bitcoin-core-pr-reviews
10:01 < stickies-v> hey kevkevin, that's great! don't hesitate to ask any questions though, we're always happy to explain
10:01 < stickies-v> do we have any other first timers around? even if you're just lurking, feel free to say hi!
10:01 < paul_c> Hey guys
10:02 < OliverOff> hi
10:02 < svav> I'd be interested to hear from the newcomers how they found out about this meeting, if they don't mind sharing.
10:03 < stickies-v> today's session will be more code heavy than last week, but feel free to ask about general concepts too (please check if we didn't cover it last week already to avoid repetition: https://bitcoincore.reviews/24148-2 )
10:03 < paul_c> was shilled this group from onstage at BTC 2022
10:03 < b10c> hi
10:03 < kevkevin> svav I found this irc after reading Amiti Uttarwar's Onboarding to bitcoin core
10:03 < svav> OK thanks paul_c
10:03 < stickies-v> who got the chance to review the PR or read the notes?
10:04 < svav> OK thanks kevkevin and welcome to the newcomers
10:04 < OliverOff> reviewed the code
10:04 < __gotcha> read parts of the notes
10:05 < paul_c> yes, reviewed before meeting
10:05  * __gotcha still need to not forget to prepare the meeting better
10:05 < svav> I had a quick read of the notes
10:06 < stickies-v> nice to see some code review this time, it's quite a bit to go through I'm aware! but kudos for reading the notes too
10:06 < stickies-v> for those of you who were able to review, would you give it a Concept ACK, Approach ACK, Tested ACK, or NACK?
10:06 < stickies-v> __gotcha: that's alright, as long as it's interesting, you're having fun and you're learning, do keep coming back!
10:07 < __gotcha> stickies-v: I will, thanks
10:08 < stickies-v> alright feel free to post your (N)ACK later on but let's dive into the questions, we've got a lot to cover
10:08 < stickies-v> first up: which function is responsible for parsing the output descriptor strings? How does it determine whether the string represents a `MiniscriptDescriptor`, instead of any other type (including a `WSHDescriptor`)?
10:08 < OliverOff> Approach ACK (caveat: I'm still a n00b)
10:09 < theStack> there is a function `ParseScript` in script/descriptor.cpp, which in turn calls `miniscript::FromString`
10:10 < stickies-v> theStack: yes exactly! to anyone interested, this `ParseScript` function is here: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/descriptor.cpp#L1228
10:11 < stickies-v> so then for the follow up question... how does ParseScript distinguish between all the different descriptors functions that we support?
10:12 < theStack> seems like it tries to parse descriptor functions first and miniscript quite at the end
10:12 < sipa> Actually something I wonder about, related to this, which I don't remember despite writing it: if you have a wsh(pk(...)) descriptor, how does it get parsed? Miniscript, or pk?
10:12 < sipa> And does it matter that both would be possible?
10:13 < stickies-v> theStack: exactly, it tries all the other descriptor functions first, and if all fail then we move on to MiniscriptDescriptor
10:13 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
10:13 < sipa> I guess my question is answered.
10:13 < stickies-v> sipa: I believe it would get parsed as pk
10:14 < stickies-v> bonus question: what's the behaviour of `Func("func_name", expr)` that is used quite frequently in `ParseScript`? are there side effects?
10:16 -!- Azor [~Azor@200.109.50.144] has joined #bitcoin-core-pr-reviews
10:17 < __gotcha> I do not find the definition of that `Func` function.
10:17 < stickies-v> sipa just to confirm, first we would remove the "wsh()" wrapper here: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/descriptor.cpp#L1353; and then since the very first check we do in `ParseScript` is for "pk()" (https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/descriptor.cpp#L1233), I'm quite confident that as said before 
10:17 < stickies-v> it would be parsed as pk and not as Miniscript
10:17 -!- otech [~otech@80.251.179.171] has joined #bitcoin-core-pr-reviews
10:17 -!- darosior [~darosior@194.36.189.246] has quit [Read error: Connection reset by peer]
10:17 < sipa> That sounds correct.
10:18 < theStack> i think it extracts the arguments of a function call expression... e.g. Func("foo", "foo(bar,xyz)") would result in "bar,xyz"
10:18 < sipa> @__gotcha It's in spanparsing
10:18 < stickies-v> __gotcha: it's here: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/util/spanparsing.cpp#L23, or the header here: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/util/spanparsing.h#L28
10:19 -!- darosior [~darosior@194.36.189.246] has joined #bitcoin-core-pr-reviews
10:19 < theStack> though the result is not returned directly, but the passed expression span is modified
10:19 < __gotcha> for the newbie, is grep your only friend to help to find code ?
10:19 < stickies-v> yes exactly! if the "func_name" and a parenthesis wrapper is found, they get removed from expr and Func returns true. if it is not found, Func returns false and expr remains unchanged
10:20 < sipa> @__gotcha `git grep` works pretty well.
10:20 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has quit [Ping timeout: 246 seconds]
10:20 < stickies-v> __gotcha: I know it's not OG but personally I rely quite a bit on vscode's intellisense, it allows you to jump through the code very quickly once you know the hotkeys
10:21 < stickies-v> alright, moving on, but as always feel free to continue the discussion on previous questions - we can manage async!
10:21 < stickies-v> does `MiniscriptDescriptor` accept Miniscript policy or Miniscript or both?
10:21 < OliverOff> Is there a reason for naming it "Func" instead of something like "ExtractArgs"?
10:21  * __gotcha will remember to check how to setup C++ LSP for neovim
10:22 < stickies-v> OliverOff: I would guess that's because it was specifically designed to parse function calls, but I wasn't there...
10:22 < theStack> __gotcha: some people have made good experiences with using vim + ctags (i guess with neovim that also works)
10:23 < __gotcha> stickies-v: are there tests for Func function ?
10:23 < OliverOff> __gotcha: src/test/util_tests.cpp
10:23 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:23 < __gotcha> well, the Func function does not return args
10:24 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 246 seconds]
10:24 < theStack> __gotcha: yes, there are unit tests, see ./test/util_tests.cpp
10:24 < stickies-v> __gotcha: in other parts of the code there are quite a few functions called "Extract..." or "Parse..." that don't return whatever is parsed, but rather use an out argument
10:25 < theStack> OliverOff: ah didn't see, you were faster :D
10:26 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:26 < stickies-v> anyone got an idea for the second question? "does `MiniscriptDescriptor` accept Miniscript policy or Miniscript or both?"
10:26 < __gotcha> not sure what you call an out argument, but afaics, here the args are removed from expr
10:27 < theStack> i wrote down that there is only miniscript supported (no miniscript policy), but don't remember how i came to that conclusion
10:28 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 258 seconds]
10:28 < sipa> That's correct.
10:28 < stickies-v> __gotcha: only the function wrapper is removed from expr, so essentially expr becomes the arguments. Like theStack gave as an example: Func("foo", "foo(bar,xyz)") would change expr to become "bar,xyz"
10:28 < sipa> The PR just doesn't include a policy compiler.
10:29 < __gotcha> Oops, misunderstood
10:29 < stickies-v> alright that was a short one, moving on
10:29 < stickies-v> `Node<Key>::ContainsDuplicateKey` returns a bool. What is the return type of `TreeEvalMaybe<std::set<Key>>(upfn)`, and how does it get cast to a `bool`? What does `Key` represent, and why is it templated?
10:30 < stickies-v> hmm let's break that up in a first part to not get too confusing
10:30 < stickies-v> `Node<Key>::ContainsDuplicateKey` returns a bool. What is the return type of `TreeEvalMaybe<std::set<Key>>(upfn)`, and how does it get cast to a `bool`?
10:30 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 276 seconds]
10:30 < OliverOff> Hm sorry I can't find "ContainsDuplicateKey" anywhere in the codebase/PR
10:31 < stickies-v> link: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/miniscript.h#L781
10:31 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:31 < stickies-v> (note: I always include links in the notes as well: https://bitcoincore.reviews/24148-2, the formatting there is a bit easier)
10:33 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-pr-reviews
10:34 < __gotcha> Is considered bad etiquette to complain about naming ?
10:34 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:35 < __gotcha> iow, is review a chance to hint where code is hard to read ?
10:35 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 258 seconds]
10:36 < stickies-v> __gotcha: personally I find that quite important. It's such a waste of time to have to go read the docs when a better func/arg name would have explained it right away. Obviously it's personal preference and not everyone may agree with your suggestion, but if you have a better alternative you should definitely suggest that in a review
10:37 < stickies-v> I've got a couple of those lined up in my review too, FYI. Note that sometimes "bad" names are chosen for consistency, which is also important. Trade-offs...
10:37 < larryruane> I think that an expression of type std::optional can be coerced to a boolean, and it will be true if the expression yields a value, or else false if std::nullopt
10:37 < larryruane> (all that is from memory)
10:37 < otech> __gotcha maybe bad etiquette if you do not include suggestions for alternative names and leave it up to the author to fix if they like. I use `NIT` for "nit-picking" for that kind of thing
10:38 < stickies-v> larryruane: yes exactly! so TreeEvalMaybe returns an std::optional<Result>, where `Result` is a templated typename
10:38 < stickies-v> and as per https://en.cppreference.com/w/cpp/utility/optional: when cast to a bool, `std::optional` becomes true if the object contains a value and false if it does not contain a value
10:40 < stickies-v> this is actually a question for later on, but maybe now is a better time to cover it. We use `TreeEvalMaybe()` (and `TreeEval()`) quite a lot throughout this part of the codebase. Could anyone explain how that works? Or are there specific parts that are unclear and we can cover here?
10:40 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
10:40 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:40 < larryruane> in a way it's consistent with what std::optional is often replacing, a pointer that can be NULL (nullptr) ... lots of old code would say !p (where p is a pointer) to test if p is not valid
10:41 < stickies-v> (link: https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/miniscript.h#L338)
10:41 < stickies-v> larryruane: yeah, I like that with new code we're using std::optional though, much clearer and helpful interface with value_or() etc
10:42 < OliverOff> For me, the interesting thing about `TreeEvalMaybe` is that the way it was implemented allows for a recursive walk of the three without actual recursive function calls. When you think of it, it's just parsing left-to-right and accumulating values. Not much different than when I'm writing LISP and need to count the parentheses ;)
10:42 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:44 < stickies-v> yep, that is a nice feature. The abstraction and templating does make it a bit harder to wrap your head around exactly how it works, but it is nice how flexibly it can be used
10:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 240 seconds]
10:44 < theStack> first a "state" is computed from root down the leaves, then a "result" is computed up back from the leaves to the root... for that one needs to pass a down- and an up-function
10:44 -!- Kaizen___ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:45 < theStack> or not pass, but rather specify in the template instantiation
10:45 < stickies-v> the lambda functions are actually passed, it's just that their signature is templated
10:45 < theStack> ah, yes that makes sense
10:46 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:46 < sipa> @larryruane Note that std::optional only has an *explicit* operator bool, so it won't get automatically converted to bool or int, only in places where only a bool makes sense (such as in an if condition).
10:47 < OliverOff> is TreeEval ever called with a "custom" `downfn`?
10:47 < larryruane> sipa: +1 thanks
10:47 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 258 seconds]
10:47 < sipa> @OliverOff I don't know what you mean by "custom"; a downfn just has to be provided.
10:48 < sipa> (in the overload that provides the ability to specify one; if you don't have state, you don't need one)
10:48 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
10:49 < stickies-v> OliverOff: see e.g. https://github.com/darosior/bitcoin/blob/ec72f351134bed229baaefc8ffaa1f72688c5435/src/script/miniscript.h#L483 for an example of how downfn and upfn are constructed and passed to TreeEval (which calls TreeEvalMaybe)
10:49 -!- Kaizen___ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
10:49 < OliverOff> Thank you
10:50 -!- Azor [~Azor@200.109.50.144] has quit [Quit: Connection closed]
10:50 < stickies-v> next up: when choosing between two available satisfactions, why should the one that involves less or no signatures be preferred?
10:50 < stickies-v> for example, consider the policy `or(and(older(21), pk(B)), thresh(2, pk(A), pk(B)))` which can always be spent when both A and B sign, and can be spent after 21 blocks when just B signs. After 21 blocks, both satisfactions are available, but why would the satisfaction that involves just B’s signature be preferable?
10:50 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 255 seconds]
10:50 < sipa> @OliverOff See miniscript::Node::ToScript for an example.
10:51 < stickies-v> sipa: yup that's the one I linked a few lines earlier
10:51 < sipa> Oops, I was being slow.
10:51 < theStack> less signatures -> less witness data -> smaller tx -> less fees to pay
10:52 < sipa> @theStack What if somehow the smaller one involved no signatures?
10:52 < stickies-v> theStack: yes, probably the most important one to most users! but, there is another less obvious reason
10:52 < __gotcha> less specific ?
10:52 < sipa> (You can construct pathological cases for which this is case)
10:53 < stickies-v> hint: it's got to do with malleability
10:54 < sipa> More hint: 3rd parties on the network can remove signatures, but not add them.
10:54 < OliverOff> I'd guess it's because in order to prevent malleability we need satisfaction to be deterministic
10:54 -!- Azor [~Azor@200.109.50.144] has joined #bitcoin-core-pr-reviews
10:54 < __gotcha> sipa: remove signatures from transaction data ?
10:55 < stickies-v> OliverOff: what do you mean with being deterministic?
10:55 < svav> Can someone remind me what malleability is?
10:55 < sipa> Imagine in @[stickies-v]'s example that the 21 blocks have passed, so B can sign alone, but instead the path that involves a signature from both A and B is used.
10:55 < OliverOff> stickies-v: mean that all nodes should agree on what the preferable satisfaction is
10:56 < theStack> sipa: not sure if i understand your question. did you mean "if the _larger_ one involved no signatures?" if the smaller one involved no signatures, that's what i would expect
10:56 < stickies-v> __gotcha: witness data is not covered by signatures, so third parties (e.g. when relaying a tx) can change this at will. In most cases, this will make the tx invalid because the witness doesn't satisfy the scriptPubKey anymore, but there are cases where the witness remains valid even after it is modified
10:57 < sipa> @theStack Imagine a situation where you have the choice between two satisfaction paths. One involves no signatures, but is bigger. One involves signature but is smaller. You should *still* prefer the bigger, no signatures one. Why?
10:57 < OliverOff> sipa:  that scenario, a 3rd party could drop A and force the script to go through the first path. However, the other way around is not possible. If you only announce A, the 3rd party couldn't possibly drop B.
10:57 < sipa> @OliverOff Not really; it has to do with third parties not being able to change which satisfaction path was used.
10:58 < sipa> @OliverOff Exactly.
10:58 < stickies-v> svav: we mean third-party malleability here, which is, as explained in my previous example to __gotcha, the ability for someone not participating in the tx (not holding the required keys to sign) to modify the witness of a transaction
10:58 < theStack> sipa: ah, now i understand the question at least (still don't know the answer though xD)
10:58 < stickies-v> as we're getting close to time:
10:58 < stickies-v> if the second branch is satisfied, a third party can malleate the satisfaction by removing the signature for A, since having the signature for B is enough
10:59 < stickies-v> (the second branch is `thresh(2, pk(A), pk(B))`)
10:59 < sipa> @theStack A third party can't add signatures but can drop them. So if the honest signers use a construction with a "redundant" signature, even if it is smaller, third parties can mutate it into the bigger no-sig variant.
11:00 < stickies-v> #endmeeting
11:00 < __gotcha> iiuc you want to use as few signatures as possible to fulfill the script
11:00 < stickies-v> that's all for today, folks. I really enjoy hosting these meetings but would love to hear your feedback on how you found it and especially how it could be better
11:00 < stickies-v> if you found the questions too easy or too difficult, we went too fast or too quick, the notes didn't provide enough context, ... I'd love to hear how I could have prepared better, either here or via DM.
11:00 < __gotcha> stickies-v: Thanks for preparing and animating
11:01 < paul_c> thanks, have a good one
11:01 -!- Franko [~Franko@186.84.21.160] has quit [Ping timeout: 240 seconds]
11:01 < svav> Thanks stickies-v and all
11:01 < theStack> sipa: okay, so by choosing the bigger no-sig variant we ensure that no mutation by a third party can happen at all and no surprises happen?
11:02 < OliverOff> thanks stickies-v!! great host as per ushe and thanks all for your help
11:02 < stickies-v> thank you everyone for coming along, I really appreciate your participation! thanks darosior and sipa for the awesome work on the PR and for helping me with these review clubs
11:03 < sipa> theStack: Indeed.
11:03 < sipa> It's a bit inaccurate to say that you should always prefer the fewest signatures satisfaction though.
11:03 < theStack> one could still try for the smaller version though and hope to save fees? as spender i wouldn't be terribly interested how exactly the spending path is satisfied, as long as the spending was successful, isn't it?
11:04 < sipa> The exact rule is that within any "choice" between two branches, if one of them involves *no* signatures, you have to choose that branch, and not the other, even if the other one is smaller.
11:05 < sipa> (at any level, so recursively for every subexpression)
11:05 < theStack> thanks for hosting stickies-v!
11:05 < sipa> theStack: Well, this assumes you care about malleability of course. But miniscript is mostly designed to assume you do (because it's kind of bad for transaction relay globally if transactions are malleable).
11:05 -!- OliverOff [~OliverOff@187.85.172.39] has quit [Quit: Connection closed]
11:06 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:06 < sipa> Thankfully, in most non-pathological cases, the smaller satisfaction will be the one with the fewest signatures.
11:06 < stickies-v> sipa: ah, so the nuance is that you don't minimize the overall number of signatures, but rather in isolation every time you need to choose between branches?
11:06 < sipa> Indeed.
11:07 < stickies-v> but then wouldn't the exact rule that you pick the branch with the *least* signatures, instead of the one with *no* signatures?
11:07 < sipa> If both branch have at least one signature, you pick the smallest one.
11:07 < stickies-v> (just to make it more general, *no* signatures is obviously a case of that)
11:07 < sipa> Given the assumption of no duplicate keys, there is no way an attacker can modify one branch to the other.
11:08 < stickies-v> ah yes
11:08 < sipa> See the section "Non-malleable satisfaction algorithm" on https://bitcoin.sipa.be/miniscript/
11:10 < paul_c> thanks
11:11 -!- Azor [~Azor@200.109.50.144] has left #bitcoin-core-pr-reviews []
11:18 -!- Kaizen_K_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
11:18 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
11:19 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has quit [Ping timeout: 240 seconds]
11:24 -!- otech [~otech@80.251.179.171] has quit [Quit: Connection closed]
11:37 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-pr-reviews
11:43 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
11:43 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
11:46 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Read error: Connection reset by peer]
11:49 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
11:52 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 244 seconds]
11:59 -!- d65 [~d@208.127.227.161] has quit [Quit: Connection closed]
12:00 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:09 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-pr-reviews
12:13 -!- __gotcha1 [~Thunderbi@cust-232-232-109-94.dyn.as47377.net] has joined #bitcoin-core-pr-reviews
12:14 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Remote host closed the connection]
12:17 -!- __gotcha [~Thunderbi@79.132.248.217] has quit [Ping timeout: 246 seconds]
12:17 -!- __gotcha1 is now known as __gotcha
12:20 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:24 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has joined #bitcoin-core-pr-reviews
12:30 -!- __gotcha1 [~Thunderbi@79.132.248.217] has joined #bitcoin-core-pr-reviews
12:33 -!- __gotcha [~Thunderbi@cust-232-232-109-94.dyn.as47377.net] has quit [Ping timeout: 255 seconds]
12:33 -!- __gotcha [~Thunderbi@cust-13-62-109-94.dyn.as47377.net] has joined #bitcoin-core-pr-reviews
12:35 -!- __gotcha1 [~Thunderbi@79.132.248.217] has quit [Ping timeout: 246 seconds]
12:41 -!- Kaizen_K_ [~Kaizen_Ki@2607:fb90:22d2:5d08:d977:4580:f53b:c691] has joined #bitcoin-core-pr-reviews
12:44 -!- Kaizen_Kintsugi_ [Kaizen_Kin@gateway/vpn/protonvpn/kaizenkintsugi/x-74018745] has quit [Ping timeout: 258 seconds]
12:46 -!- Precioso [~Precioso@191.7.107.250] has joined #bitcoin-core-pr-reviews
12:49 -!- Precioso [~Precioso@191.7.107.250] has quit [Client Quit]
12:50 -!- Precioso [~Precioso@191.7.107.250] has joined #bitcoin-core-pr-reviews
12:50 -!- Precioso [~Precioso@191.7.107.250] has quit [Client Quit]
12:57 -!- paul_c [~paul_c@pool-72-66-70-127.washdc.fios.verizon.net] has left #bitcoin-core-pr-reviews []
13:32 -!- __gotcha [~Thunderbi@cust-13-62-109-94.dyn.as47377.net] has quit [Ping timeout: 246 seconds]
13:33 -!- kevkevin [~kevkevin@68-75-9-3.lightspeed.cicril.sbcglobal.net] has quit [Ping timeout: 246 seconds]
13:57 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has joined #bitcoin-core-pr-reviews
14:00 -!- Kaizen_K_ [~Kaizen_Ki@2607:fb90:22d2:5d08:d977:4580:f53b:c691] has quit [Ping timeout: 240 seconds]
14:26 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has quit [Remote host closed the connection]
14:39 < david-bakin> So, having achieved 3 concept ACKs to a little PR - how do I take the next step?  https://github.com/bitcoin/bitcoin/pull/25132 - or do I _need_ to take a next step or not?  (i.e., just wait for more activity)
15:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Remote host closed the connection]
15:51 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
15:56 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 255 seconds]
15:58 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
16:01 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 246 seconds]
16:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
16:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 244 seconds]
16:47 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has joined #bitcoin-core-pr-reviews
16:58 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has quit [Remote host closed the connection]
17:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
17:05 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 240 seconds]
17:14 -!- jesseposner [~jesse@user/jesseposner] has quit [Quit: Textual IRC Client: www.textualapp.com]
17:17 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
17:25 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Remote host closed the connection]
17:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
17:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 260 seconds]
18:12 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
18:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
18:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 255 seconds]
18:27 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews
18:31 -!- evanlinjin [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
18:43 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds]
18:51 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
18:55 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds]
18:58 -!- jesseposner [~jesse@user/jesseposner] has joined #bitcoin-core-pr-reviews
19:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
19:54 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has joined #bitcoin-core-pr-reviews
19:59 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has quit [Remote host closed the connection]
20:14 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has joined #bitcoin-core-pr-reviews
20:16 -!- z9z0b3t1_ [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has joined #bitcoin-core-pr-reviews
20:18 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has quit [Ping timeout: 255 seconds]
20:20 -!- z9z0b3t1c [z9z0b3t1c@gateway/vpn/protonvpn/z9z0b3t1c] has quit [Ping timeout: 256 seconds]
20:29 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has joined #bitcoin-core-pr-reviews
20:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 260 seconds]
20:58 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews
21:02 -!- jtraub91 [~Jason@098-147-176-043.res.spectrum.com] has joined #bitcoin-core-pr-reviews
21:02 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 258 seconds]
21:35 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has quit [Ping timeout: 244 seconds]
21:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
21:50 -!- Kaizen_Kintsugi_ [~Kaizen_Ki@2600:8802:3806:c200:c45d:c9ef:f1c8:c769] has joined #bitcoin-core-pr-reviews
22:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has quit [Ping timeout: 260 seconds]
23:14 -!- cryptoquick [~cryptoqui@8.46.89.33] has joined #bitcoin-core-pr-reviews
23:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:8dad:ff4:acd:af20] has joined #bitcoin-core-pr-reviews
--- Log closed Thu May 26 00:00:35 2022