--- Log opened Wed Apr 05 00:00:23 2023
00:02 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 240 seconds]
00:25 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
00:30 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 265 seconds]
00:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
00:37 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 260 seconds]
00:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
00:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 265 seconds]
00:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
00:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 260 seconds]
01:09 -!- josie [~josibake@suhail.uberspace.de] has joined #bitcoin-core-pr-reviews
01:22 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
01:26 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 255 seconds]
01:54 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
01:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 260 seconds]
02:24 -!- NegativeOne [~NegativeO@bb121-6-126-184.singnet.com.sg] has quit [Quit: Connection closed]
02:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
02:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 248 seconds]
02:46 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
02:50 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 246 seconds]
03:21 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
03:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 260 seconds]
03:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
03:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 248 seconds]
04:02 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
04:07 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
04:36 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
04:40 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
05:13 -!- b_101_ [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
05:14 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
05:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
05:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 246 seconds]
05:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
06:55 -!- pablomartin [~pablomart@190.195.73.51] has joined #bitcoin-core-pr-reviews
07:13 -!- pablomartin4btc [~pablomart@185.183.180.93] has joined #bitcoin-core-pr-reviews
07:16 -!- pablomartin [~pablomart@190.195.73.51] has quit [Ping timeout: 265 seconds]
07:46 -!- pablomartin4btc [~pablomart@185.183.180.93] has quit [Remote host closed the connection]
07:46 -!- pablomartin4btc [~pablomart@185.183.180.93] has joined #bitcoin-core-pr-reviews
07:55 -!- pablomartin4btc [~pablomart@185.183.180.93] has quit [Remote host closed the connection]
07:55 -!- pablomartin4btc [~pablomart@185.183.180.93] has joined #bitcoin-core-pr-reviews
08:19 -!- pablomartin4btc [~pablomart@185.183.180.93] has quit [Ping timeout: 252 seconds]
08:37 -!- kevkevin [~kevkevin@104-182-134-253.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-pr-reviews
08:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Remote host closed the connection]
08:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
08:47 -!- grettke [~grettke@184.55.131.155] has joined #bitcoin-core-pr-reviews
08:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 260 seconds]
09:04 -!- Novo [~Novo@102.91.47.132] has joined #bitcoin-core-pr-reviews
09:17 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
09:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 264 seconds]
09:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
09:25 -!- Novo [~Novo@102.91.47.132] has quit [Quit: Connection closed]
09:39 -!- abubakar [~abubakars@197.210.71.218] has joined #bitcoin-core-pr-reviews
09:49 -!- DaveBeer [~DaveBeer@ip-62-245-124-60.bb.vodafone.cz] has joined #bitcoin-core-pr-reviews
09:51 -!- Tobses [~Tobses@41.217.96.52] has joined #bitcoin-core-pr-reviews
09:51 -!- kevkevin [~kevkevin@104-182-134-253.lightspeed.cicril.sbcglobal.net] has quit [Quit: Connection closed]
09:51 -!- kevkevin [~kevkevin@104-182-134-253.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-pr-reviews
09:59 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:59 -!- Alex66 [~Alex@5.151.70.133] has joined #bitcoin-core-pr-reviews
10:00 < josie> #startmeeting
10:00 < stickies-v> hi
10:00 < kevkevin> Hello
10:00 < josie> hi all, today we are reviewing https://bitcoincore.reviews/27255
10:00 < brunoerg> hi
10:00 < abubakar> hi
10:00 < effexzi> Hi every1
10:01 < josie> any first timers for the PR review club?
10:01 < DaveBeer> hi
10:01 < turkycat> yep, first timer here
10:01 < Alex66> hi, yap first time
10:02 < josie> turkycat, Alex66: welcome!
10:03 -!- Eppie [~Eppie@197.210.8.156] has joined #bitcoin-core-pr-reviews
10:04 < turkycat> ty
10:04 -!- anon [~anon@197.210.70.26] has joined #bitcoin-core-pr-reviews
10:05 < josie> just as a quick reminder: no need to ask about asking a question. if you have a question, jump in!
10:05 < josie> first question: did you get a chance to review the PR? give a y for yes or an n for no
10:05 -!- Tobses [~Tobses@41.217.96.52] has quit [Quit: Connection closed]
10:05 < kevkevin> y
10:06 < abubakar> y 
10:06 < Alex66> n
10:06 < Eppie> y
10:06 < josie> if you did get a chance to review the PR, what did was your approach? did you ACK/NACK?
10:06 < stickies-v> n, mostly looked at the notes/questions
10:07 -!- Munlite [~Munlite@102.89.32.118] has joined #bitcoin-core-pr-reviews
10:07 < kevkevin> I just visually read the code and got to understand miniscript.cpp and miniscript.h concept ACK
10:07 < LarryRuane> hi
10:07 < abubakar> I am running the test currently concept ACK
10:07 < josie> (or even if you didn't fully review, what do you think regarding the concept and the approach)
10:08 < LarryRuane> yes concept ACK also from me but this is an area I'm not familiar with at all
10:09 < stickies-v> taproot enables much more complex scripting, so big concept ack for adding miniscript compatibility
10:09 < brunoerg> concept ACK
10:09 -!- Tobses [~Tobses@41.217.96.52] has joined #bitcoin-core-pr-reviews
10:10 -!- NegativeOne [~NegativeO@bb121-6-126-184.singnet.com.sg] has joined #bitcoin-core-pr-reviews
10:10 < turkycat> I'm comfortable with the code changes and understand them- descriptors in general though not so much. some of the concepts of the descriptors are still fuzzy to me after reading the doc on them. hoping to pick up more today
10:11 < LarryRuane> I have a very basic question (sorry), but this https://bitcoin.sipa.be/miniscript/ already mentions Tapscript, so what is this PR for? I'm unclear on what is already done and what more is needed
10:11 < josie> cool! for the next question, I think it makes more sense to start with 3: what is tapscript?
10:11 < josie> turkycat: descriptors are a really big topic! 
10:12 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:12 < stickies-v> LarryRuane: the website was only updated very recently: https://github.com/sipa/miniscript/pull/134
10:12 < abubakar> tapscript is a modified version of bitcoin script which removes and adds some opcodes like checksigadd
10:12 < LarryRuane> stickies-v: thanks
10:13 < stickies-v> bitcoin core currently is not yet able to parse tapscript miniscript, so the website is just describing the spec already
10:13 < brunoerg> tapscript is a scripting language used in Bitcoin which can use Schnorr Signatures and other things
10:13 < kevkevin> tapscript is a scripting language that utilizes the upgrades from the taproot update
10:14 < josie> abubakar: correct! 
10:14 < LarryRuane> The interactive aspect of that website is really cool and amazing
10:15 < abubakar> only v1 scrippubkeys can use tapscript i think
10:16 < josie> yep, more specifically, tapscript is built of segwit v0 script
10:16 < turkycat> abubakar v1 as in segwit v1 (taproot) as apposed to segwit v0?
10:16 < josie> s/built of/built on/
10:17 -!- munjesi [~munjesi@197.232.61.235] has joined #bitcoin-core-pr-reviews
10:17 < josie> turkeycat: yep! more importantly, segwit v1 introduced the concept of a leaf version. tapscript is defined as leaf version 0
10:18 < abubakar> turkycat: yes segwit v0 uses the bitcoin script
10:18 < josie> a few of you have already mentioned some differences, but can you summarize in your own words some differences between Segwit v0 Script and Tapscript? 
10:18 < turkycat> yep just needed to clarify that there aren't two versions of something else in context
10:19 -!- b_101_ [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Ping timeout: 248 seconds]
10:19 < LarryRuane> ah so there can later be leaf versions 1, 2, ..., all within segwit v1
10:19 < josie> LarryRuane: the miniscript website is awesome! I reference it constantly
10:20 < turkycat> segwit v0 supports pubkeyhash and script hash operations via witness data. taproot allows for a merkle tree of different script leaves that can be revealed at spending time or satisfied with a composite signature of a single key
10:20 < josie> LarryRuane: that's right! in fact, you could create a TapTree where each leaf has it's own leaf version
10:21 < brunoerg> turkycat: MAST, right?
10:21 < stickies-v> josie: OP_(NOT)IF is now only allowed (consensus) to have 0 or 1 as its argument, whereas in v0 e.g. 4 would also evaluate as true (this is also referred to as MINIMALIF)
10:21 < abubakar> multisig is now different in tapscript because of the new checksigadd opcode
10:22 < josie> turkycat: close. I'd say it's more correct to say that segwit v1 introduces the merkle tree of scripts (with leaf versions) and tapscript is defined as leaf version 0
10:22 < turkycat> brunoerg - I had to google "MAST", but I think so. All I know is that with a single merkle root you can have an unbalanced trie of script leaves
10:23 < josie> stickies-v: yep, this is an important one! previously minimalif was only a policy rule, whereas in tapscript it is now a consensus rule
10:23 < turkycat> josie ACK. re-read your question and realized I didn't parse correctly on the first go
10:23 < turkycat> ty
10:24 < josie> abubakar: yep, tapscript adds a new op_code checksigadd. what about the old multisig opcodes from legacy and segwit v0?
10:24 < kevkevin> isnt the old multisig op code CHECKMULTISIG?
10:25 < abubakar> its removed i think, i might be wrong on this
10:25 < josie> kevkevin: yep! CHECKMULTISIG (and CHECKMULTISIGVERIFY)
10:25 < stickies-v> kevkevin: yes, OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY were used up until segwit v0 - what's the question?
10:26 < abubakar> kevkevin: yes
10:26 < stickies-v> oh I see, you were just listing them. sorry
10:26 < josie> abubakar: you are correct, CHECKMULTISIG and CHECKMULTISIGVERIFY are removed from tapscript
10:28 < josie> what about limits in segwit v0 vs tapscript? any changes here?
10:28 -!- Eppie [~Eppie@197.210.8.156] has quit [Quit: Connection closed]
10:28 < stickies-v> mmm I don't think they're removed? just made to behave like OP_RETURN, pretty much?
10:28 < stickies-v> as in - they fail script termination
10:28 < stickies-v> *script execution
10:29 < abubakar> stickies-v: +1
10:29 < abubakar> josie: thanks
10:29 < josie> stickies-v: that's a great point, actually! you are correct: they now behave like OP_RETURN 
10:30 < josie> so instead of saying removed, the more correct terminology would be "disabled"
10:31 < brunoerg> Sorry couldn't get it, what do you mean by "disabled"?
10:31 < turkycat> extending Script requires the redefining of the numbered NO_OP codes (like NO_OP1), where I could make a WAG that tapscript can be extensible without requiring to always be backwards compatible? by adding a new version I mean
10:33 < turkycat> segwit v0 still relies on 'legacy' Script, so now we could theoretically create all sorts of new capabilities with new versions?
10:33 < stickies-v> brunoerg: if during script execution one of those opcodes is encountered, script termination fails. if the opcodes are in a branch that's not executed, they're ignored
10:33 < brunoerg> ok, I think I got it, disabled means they are still present in the language but they're no longer executable
10:34 < brunoerg> stickies-v: cool, thanks
10:34 < stickies-v> (i don't know why i keep saying script termination instead of script execution, sorry)
10:35 < josie> brunoerg, stickies-v: that's my understanding as well. I'm not sure about this, but perhaps it also means those OP_CODE numbers are still reserved? meaning they cant be redefined to mean something else in the future
10:36 < brunoerg> yes, I think they're still reserved to keep backwards compatible
10:37 < josie> turkycat: actually, one of the key features of tapscript is that it allows adding new op_codes using OP_SUCCESS, instead of NO_OP
10:37 < brunoerg> so older scripts can still be decoded correctly
10:37 < abubakar> josie: is it limit to the size of the items in stack during execution of the script
10:38 < turkycat> @josie cool, added
10:38 < turkycat> tapscript walkthrough to reading list
10:39 < josie> abubakar: the stack element size, and the element count limit are the same, but the non-push opcodes limit of 201 per script was removed and the maximum script size limit of 10,000 bytes was removed 
10:39 -!- Munlite [~Munlite@102.89.32.118] has quit [Quit: Connection closed]
10:40 < josie> okay, moving on to question 4: the PR adds a `multi_a` fragment for Tapscript. how is this different than the existing `multi` fragment?
10:41 < josie> does `multi_a` have the same properties as `multi`? why/why not?
10:41 < kevkevin> is the difference multi_a uses checksigadd while multi uses checkmultisig
10:41 < kevkevin> they have the same properties tho?
10:42 < stickies-v> `multi` always consumes at least one stack element (because of the off-by-one bug, i think?), `multi_a` does not
10:43 < kevkevin> ooh ok didn't know that bit of info
10:44 < abubakar> kevkevin: +1 multi output has the checkmultisig opcode which was removed, the fragment output script differs
10:45 < josie> kevkevin, abubakar: tapscript definitely uses checksigadd, but I suppose we could have reused the same multi fragment and recognized that it was being used in a tapscript context. but this would only be possible if the multi fragment had the same properties under both p2wsh and tapscript 
10:46 < kevkevin> ohh is it because the tapscript inputs are 32 bytes and p2wsh 33 not too sure on this one
10:47 < josie> stickies-v: multi does have the n property, which means it must always consume at least one stack element. good point about the off-by-one tho, I'm not sure if this is the reason 
10:49 < josie> let me rephrase the question a bit: the `multi` fragment has the `n` type modifier, which means it must always consume at least one stack element. `multi_a` does not have the `n` type modifier, which means the top of the stack can be the empty vector. any ideas as to why?
10:50 -!- munjesi [~munjesi@197.232.61.235] has quit [Quit: Client closed]
10:51 < stickies-v> if we pass `0` as the first argument to `multi_a` it would be a 0-0 multisig, so nothing gets popped off the stack?
10:51 < abubakar> because of the 0 prefix
10:53 < josie> stickies-v: instead of a 0-0, think about how CHECKSIGADD would be used for a 2-3 multisig. how many parameters does CSA expect?
10:53 < turkycat> maybe because it still requires n items to satisfy the NUMEQUAL at the end, but if we're using, say 2-of-3 multisig then we only need 2 valid signatures? idk feels like a shaky guess but there doesn't appear to be a 'k' value on `multi_a`
10:54 < turkycat> oops, yes there is- at the end before NUMEQUAL
10:54 < josie> turkycat: bingo! CSA expects N sigs, but only k are needed for the NUMEQUAL. so n - k of the sigs will be the empty vector 
10:55 < turkycat> score 1 for the WAGs
10:56 < josie> CHECKMULTISIG had you pass both k and n, so it would be expecting exactly k sigs, non of which were empty 
10:57 < josie> we are pretty close to time, so instead of going into the next Q (which is a pretty big one), are there any questions about stuff we've talked about so far?
10:57 < josie> also, any interest in finishing the remaining questions in a follow-up review club? there's some pretty good stuff in the remaining questions :) 
10:58 < LarryRuane> I would say yes to follow-up, and I'll try to be better prepared!
10:58 < kevkevin> yup I'd say yes to a follow up aswell
10:59 < josie> cool, follow-up it is! probably should have started with less questions because this is a really big topic! what we are seeing in this PR is the tip of the iceberg
10:59 < brunoerg> yea, a follow-up would be great
10:59 < abubakar> +1 would like a part 2 :)
11:00 < turkycat> yea, I'll be able to read the new items on my list before then
11:00 < stickies-v> josie: contrary to OP_CHECKMULTISIG(VERIFY), CSA always operates on a single signature
11:00 < josie> stickies-v: yep! this is a big improvement over CMS(V)'s brute force approach 
11:01 < stickies-v> I still think that the only way for `multi_a` to not pop anything off the stack is for it to be `multi_a(0)`?
11:01 < josie> okay, thanks everyone for attending and keep your eyes out for a follow-up! 
11:01 < stickies-v> (i.e. k is 0 as per the first argument and n is 0 because we don't pass any further keys)
11:01 < josie> #endmeeting
11:02 < abubakar> thanks for hosting josie :)
11:02 < DaveBeer> thanks josie
11:02 < turkycat> assuming you've already satisfied k signatures, does this mean for each [ n - k ] you'll have [ OP_0, CHECKSIGADD ] ?
11:02 -!- Alex66 [~Alex@5.151.70.133] has quit [Quit: Connection closed]
11:02 < turkycat> thanks josie - super helpful
11:02 < turkycat> will be back
11:02 < stickies-v> thanks josie!
11:03 < kevkevin> Thanks josie!!!
11:03 < LarryRuane> thanks, @josie!
11:03 < brunoerg> thanks, josie!
11:04 < stickies-v> turkycat: no, for a k-n multisig `multi_a` would translate into a script with `k` `OP_CHECKSIGADD` codes
11:04 < stickies-v> oh
11:04 < stickies-v> no
11:04 < stickies-v> wait
11:04 < stickies-v> I'm confused ahh
11:04 < turkycat> I guess people were saying it still pops an item from the stack
11:05 < turkycat> usually, script notations leave out PUSH_DATA commands in favor of just listing the data being pushed
11:05 < josie> stickies-v: as I understood it, the problem was if we just used multi (which has the n property), you could use multi with a j fragment (j:multi, which requires that the top element of the stack is not the empty vector)
11:05 < turkycat> (implicit PUSH_DATA)
11:05 < josie> but CSA will have scenarios where the top element on the stack is the empty vector, at which point it moves on to the next op_code 
11:07 < josie> (I might be butchering the explanation here, I'm still kinda fuzzy on this part)
11:07 -!- abubakar [~abubakars@197.210.71.218] has quit [Quit: Lost terminal]
11:07 -!- anon [~anon@197.210.70.26] has quit [Quit: Connection closed]
11:09 -!- Tobses [~Tobses@41.217.96.52] has quit [Quit: Connection closed]
11:19 -!- DaveBeer [~DaveBeer@ip-62-245-124-60.bb.vodafone.cz] has quit [Quit: Connection closed]
11:37 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
11:42 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Ping timeout: 276 seconds]
12:13 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:59 -!- Eoin [~Eoin@212.129.76.231] has joined #bitcoin-core-pr-reviews
13:04 -!- Eoin [~Eoin@212.129.76.231] has quit [Ping timeout: 264 seconds]
13:14 -!- kevkevin [~kevkevin@104-182-134-253.lightspeed.cicril.sbcglobal.net] has quit [Quit: Connection closed]
13:14 -!- b10c_ [~quassel@static.33.106.217.95.clients.your-server.de] has quit [Changing host]
13:14 -!- b10c_ [~quassel@user/b10c] has joined #bitcoin-core-pr-reviews
13:14 -!- b10c_ is now known as b10c
14:26 -!- pablomartin4btc [~pablomart@185.183.180.96] has joined #bitcoin-core-pr-reviews
14:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Remote host closed the connection]
14:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
14:38 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 260 seconds]
14:47 -!- Eppie [~Eppie@197.210.8.156] has joined #bitcoin-core-pr-reviews
14:47 -!- Eppie [~Eppie@197.210.8.156] has quit [Client Quit]
14:50 -!- pablomartin [~pablomart@185.183.180.96] has joined #bitcoin-core-pr-reviews
14:50 -!- pablomartin4btc [~pablomart@185.183.180.96] has quit [Ping timeout: 255 seconds]
14:59 -!- pablomartin [~pablomart@185.183.180.96] has quit [Ping timeout: 276 seconds]
15:12 -!- __gotcha [~Thunderbi@ldd29-1-78-210-28-87.fbx.proxad.net] has quit [Ping timeout: 276 seconds]
15:19 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
15:29 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 248 seconds]
15:42 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
15:47 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 246 seconds]
16:20 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
16:24 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 260 seconds]
16:29 -!- NegativeOne [~NegativeO@bb121-6-126-184.singnet.com.sg] has quit [Quit: Connection closed]
17:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
17:14 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 250 seconds]
17:37 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
17:46 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:50 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 252 seconds]
17:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
17:57 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 248 seconds]
18:26 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
18:31 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 250 seconds]
18:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
18:40 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 248 seconds]
18:48 -!- Jamal [~Jamal@196.89.154.91] has joined #bitcoin-core-pr-reviews
18:48 -!- Jamal [~Jamal@196.89.154.91] has quit [Client Quit]
19:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
19:32 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 248 seconds]
20:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
20:07 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 265 seconds]
20:10 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Ping timeout: 252 seconds]
20:21 -!- grettke [~grettke@184.55.131.155] has quit [Quit: grettke]
20:28 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
20:33 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 268 seconds]
20:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
20:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 265 seconds]
21:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
21:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 265 seconds]
21:07 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
21:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 250 seconds]
21:17 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
21:18 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
21:22 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Ping timeout: 268 seconds]
21:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 252 seconds]
21:23 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
21:28 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 248 seconds]
22:03 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:08 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
22:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 264 seconds]
22:13 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
22:16 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Ping timeout: 260 seconds]
22:18 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 264 seconds]
22:19 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
22:22 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:24 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 264 seconds]
22:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
22:34 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 252 seconds]
22:36 -!- b_101_ [~robert@185.180.13.45.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews
22:36 -!- b_101 [~robert@185.180.13.45.adsl.inet-telecom.org] has quit [Read error: Connection reset by peer]
22:41 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
22:46 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 240 seconds]
22:52 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-pr-reviews
22:56 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 250 seconds]
23:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
23:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 264 seconds]
23:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
23:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 256 seconds]
23:36 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
23:44 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 265 seconds]
23:50 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
23:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has quit [Ping timeout: 264 seconds]
23:56 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c09e:9cff:94fc:2ae4] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Apr 06 00:00:24 2023