--- Log opened Wed Mar 06 00:00:21 2024
00:35 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
00:36 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
02:40 -!- no-world [~no-world@2601:644:800:66d0:5d9a:9fb9:7e12:92b0] has quit [Quit: Client closed]
02:57 -!- Guest10 [~Guest85@197.245.148.21] has joined #bitcoin-core-pr-reviews
02:58 -!- Guest10 [~Guest85@197.245.148.21] has quit [Client Quit]
03:22 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
05:51 -!- cbergqvist [~chris@84-216-185-21.customers.ownit.se] has joined #bitcoin-core-pr-reviews
06:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Remote host closed the connection]
06:15 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
06:16 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
06:19 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 264 seconds]
07:52 -!- jon_atack [~jonatack@user/jonatack] has quit [Ping timeout: 256 seconds]
08:11 -!- ghost43_ [~ghost43@gateway/tor-sasl/ghost43] has joined #bitcoin-core-pr-reviews
08:12 -!- ghost43 [~ghost43@gateway/tor-sasl/ghost43] has quit [Ping timeout: 260 seconds]
08:23 -!- jess [meow@libera/staff/cat/jess] has joined #bitcoin-core-pr-reviews
08:31 -!- rot13maxi [~rot13maxi@45.134.142.205] has joined #bitcoin-core-pr-reviews
08:49 -!- vmammal [~vmammal@107.181.222.132] has joined #bitcoin-core-pr-reviews
08:49 -!- Ethan [~Ethan@2601:189:8180:6320:c54a:433:256f:4a0f] has joined #bitcoin-core-pr-reviews
08:50 -!- Ethan [~Ethan@2601:189:8180:6320:c54a:433:256f:4a0f] has quit [Client Quit]
08:52 -!- Ayelen [~ayelen@181.29.131.163] has joined #bitcoin-core-pr-reviews
08:52 -!- EthanHeilman [~EthanHeil@2601:189:8180:6320:8a2:3df0:39e4:566a] has joined #bitcoin-core-pr-reviews
08:56 -!- arminsdev [~arminsdev@199.94.1.207] has joined #bitcoin-core-pr-reviews
08:56 -!- alfonsoromanz [~alfonsoro@181.29.131.163] has joined #bitcoin-core-pr-reviews
08:59 -!- Al79 [~Al79@41.85.177.98] has joined #bitcoin-core-pr-reviews
08:59 -!- kevkevin [~kevkevin@2601:241:8703:7b30:c18d:86a5:6374:50f3] has joined #bitcoin-core-pr-reviews
09:00 -!- Guest42 [~Guest42@212.129.78.57] has joined #bitcoin-core-pr-reviews
09:00 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
09:00 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:01 < glozow> hi
09:01 < maxedw> hi
09:01 -!- Guest21 [~Guest21@99.255.159.147] has joined #bitcoin-core-pr-reviews
09:01 < EthanHeilman> #startmeeting
09:01 < EthanHeilman> Hi
09:01 < stickies-v> hi
09:01 -!- kouloumos__ is now known as kouloumos
09:01 < arminsdev> Hi
09:01 < maxedw> hi
09:01 < reardencode> hi!
09:01 < kouloumos> hi
09:01 < Guest21> hello
09:01 < kevkevin> hi
09:01 < dergoegge> hi
09:01 < Al79> hI
09:01 < monlovesmango> hello
09:01 < effexzi> Hi every1 
09:01 < cbergqvist> hi
09:02 < EthanHeilman> Feel free to post any questions you might have about the PR https://github.com/bitcoin-inquisition/bitcoin/pull/39 to reenable OP_CAT.
09:03 < EthanHeilman> Did everyone get a chance to read the PR?
09:03 < LarryRuane> hi
09:03 -!- marcofleon [~marcofleo@wsip-174-73-86-98.ph.ph.cox.net] has joined #bitcoin-core-pr-reviews
09:03 < glozow> Spent some time, but I'm new to script interpreter code
09:03 < stickies-v> same here!
09:04 < instagibbs> ignored the activation code, mostly, but read the script interpreter stuff which im more familiar with
09:04 < reardencode> My one question so far is why in the test_framework/script.py the separate block for marking CAT not-success vs. changing the 2nd-to-last character in line 938 to `d`?
09:04 < kevkevin> have not but I will be mostly lurking today
09:04 < hernanmarino> Hi  !
09:04 < alfonsoromanz> hi
09:04 -!- Mccalabrese [~Mccalabre@189.178.60.103] has joined #bitcoin-core-pr-reviews
09:04 < maxedw> skimmed through PR and BIP
09:05 < reardencode> BTW, not specific to the PR, but to the BIP and PR club notes, but CAT cannot emulate CSFS - that was a common misconception based on many of us too quickly reading Poelstra's old blog post.
09:05 < kouloumos> a quick look at the PR, read the BIP and mostly context-gathering around OP_CAT
09:05 < EthanHeilman> If you reviewed the PR Concept ACK, approach ACK, tested ACK, or NACK?
09:06 < arminsdev> @reardencode  Thanks for pointing that out! I need to revert that change. In general the changes in this PR should not affect OP_SUCCESS checks
09:06 < hernanmarino> approach ACK here. I'll test it later , i really like this :)
09:06 < instagibbs> approach ACK, would have to dive more into the activation logic to think clearly about how OP_SUCCESSX stuff is handled
09:08 < EthanHeilman> Let's get it started, it sounds like arminsdev addressed reardencode's question
09:08 < LarryRuane> i have a very basic question, what's the difference between the various OP_NOPs and OP_SUCCESS?
09:08 < LarryRuane> do they both just do nothing (successfully)?
09:09 < instagibbs> LarryRuane all NOPs are same, all OP_SUCCESSX are same, but the two classes are different
09:09 < reardencode> presence of SUCCESS skips script execution entirely and makes the tx success.
09:09 -!- EthanHeilman [~EthanHeil@2601:189:8180:6320:8a2:3df0:39e4:566a] has quit [Quit: Client closed]
09:09 < reardencode> er the _input_ success, not the tx
09:09 -!- approvedraccoon [~approvedr@186.70.85.162] has joined #bitcoin-core-pr-reviews
09:09 -!- EthanHeilman [~EthanHeil@2601:189:8180:6320:8a2:3df0:39e4:566a] has joined #bitcoin-core-pr-reviews
09:09 -!- jd19 [~jd@75.162.68.46] has joined #bitcoin-core-pr-reviews
09:10 < LarryRuane> i see thanks
09:10 < instagibbs> interpreter steps over all opcodes, if it sees an op_successx, it immediately succeeds
09:10 < instagibbs> before running the actual script
09:10 -!- jd19 [~jd@75.162.68.46] has quit [Client Quit]
09:10 < glozow> do repurposed nops have restrictions on what they can do to the stack?
09:10 < EthanHeilman> I'm going to go down the list of questions, but throw any additional questions in
09:10 -!- jdnewby [~jdnewby@75.162.68.46] has joined #bitcoin-core-pr-reviews
09:11 < instagibbs> glozow and how does that effect re-enabling of something like OP_CAT 🧐
09:11 < LarryRuane> glozow: i would think they must leave the stack unchanged (like a NOP does)
09:11 < glozow> it doesn't, i'm just trying to answer LarryRuane's question
09:12 < EthanHeilman> 2. What are the various conditions under which the execution of OP_CAT may result in failure?
09:12 < reardencode> it means we can only reenable OP_CAT as a SUCCESS replacement in tapscript, but not in legacy/witnessv0 script.
09:12 < glozow> fewer than 2 items, resulting size too big, or usage not allowed?
09:12 < LarryRuane> I could only see 2, not enough items on the stack, or the resulting element too large
09:12 < instagibbs> reardencode without some ... interesting engineering :)
09:13 < arminsdev> So far so good! Fewer than 2 items on the stack, resulting item is too large and script verify flags
09:13 < arminsdev> There is one more
09:14 -!- twhittle [~twhittle@c-73-70-223-137.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews
09:14 < Ayelen> OP_CAT fails if there are less than two values on the stack or if the size of the result is more than size of 520 bytes.
09:14 < Guest21> is MAX_SCRIPT_ELEMENT_SIZE = 520 a consensus rule or policy rule ?
09:15 < arminsdev> Hint that we re-enable CAT by replacing OP_SUCCESS126
09:15 < reardencode> Guest21: consensus (but prior to CAT we didn't have an example of it needing to be enforced on an element pushed back to the stack IIUC)
09:16 < reardencode> arminsdev: when it's executed in witnessv0/legacy script?
09:16 < arminsdev> reardencode correct!
09:17 < Guest21> so its not consensus rule for tapscript?
09:17 < rot13maxi> I saw that there is a new `SCRIPT_VERIFY_DISCOURAGE_OP_CAT` flag being added. Why is there also `SCRIPT_VERIFY_OP_CAT`? Is that to have something to toggle on when it gets activated
09:17 < EthanHeilman> OP_FALSE IF OP_SUCCESS126 END_IF OP_FALSE OP_VERIFY --> success
09:17 < EthanHeilman> vs
09:17 < EthanHeilman> OP_FALSE IF OP_CAT END_IF OP_FALSE OP_VERIFY --> failure
09:17 -!- jdnewby19 [~jdnewby19@75.162.68.46] has joined #bitcoin-core-pr-reviews
09:17 -!- approvedraccoon [~approvedr@186.70.85.162] has quit [Quit: Client closed]
09:17 < arminsdev> rot13maxi thats one of the questions we're going to cover
09:17 < EthanHeilman> rot13maxi thats question 4, lets jump to that: In deploymentinfo.cpp, there are both an OP_CAT flag and a DISCOURAGE_OP_CAT flag. What is the rationale behind having both of these?
09:17 < reardencode> Guest21: it is a consensus rule for all incoming stack elements in witnessv0 and tapscript, and with the addition of CAT also for elements pushed back to the stack by script.
09:18 -!- vmammal [~vmammal@107.181.222.132] has quit [Quit: Client closed]
09:18 -!- vmammal [~vmammal@107.181.222.132] has joined #bitcoin-core-pr-reviews
09:18 < rot13maxi> arminsdev cool
09:19 < arminsdev> I suppose we can jump into that question now. Any ideas?
09:19 -!- Guest21 [~Guest21@99.255.159.147] has quit [Quit: Client closed]
09:20 < EthanHeilman> reardencode "with the addition of CAT also for elements pushed back to the stack by script" how does OP_CAT add this rule? Is there something different about the OP_PUSHDATA logic?
09:20 < LarryRuane> rot13maxi: I believe the discourage flags are in case later we want to deactivate the softfork (I notice that the early SFs like P2SH don't have discourage flags because we know they'll never be undone)
09:21 < reardencode> EthanHeilman: because CAT directly manipulates the stack it has to separately implement the length restriction, vs. PUSHDATA already has the restriction is what I meant
09:21 < EthanHeilman> reardencode Oh, I get what you are saying
09:22 < instagibbs> OP_CAT didn't have the restriction, hence part of th reason it was disabled 
09:22 < hernanmarino> +1 to LarryRuane but i thinks it is only related to bitcoin inquisition  because forks are activated differently, and can be desactivated 
09:22 < EthanHeilman> IIRC OP_CAT did have the restriction
09:22 -!- Guest21 [~Guest21@99.255.159.147] has joined #bitcoin-core-pr-reviews
09:23 -!- jdnewby19 [~jdnewby19@75.162.68.46] has quit [Remote host closed the connection]
09:23 < instagibbs> only for like... a day, one sec
09:23 < rot13maxi> there is also a policy limit on taproot witness stack item size of 80 bytes (https://github.com/bitcoin/bitcoin/blob/ab5dfdbec1143f673f4d83acd4e335bb2c51034e/src/policy/policy.h#L45) which I ran into when playing with CAT on regtest. Doesn't directly affect this PR, but is another limit that comes into play for using cat in practice
09:24 < EthanHeilman> OP_CAT was restricted to 5000 bytes before it was disabled, but interestingly in the commit that disabled it, Satoshi also changed OP_CAT to restrict it to 520 Bytes
09:24 < EthanHeilman> https://github.com/bitcoin/bitcoin/commit/4bd188c4383d6e614e18f79dc337fbabe8464c82#diff-27496895958ca30c47bbb873299a2ad7a7ea1003a9faa96b317250e3b7aa1fefL390
09:24 < instagibbs> 757f0769d8360ea043f469f3a35f6ec204740446 satoshi adds a result restiction
09:25 < kouloumos>  Regarding the MAX_SCRIPT_ELEMENT_SIZE, Steven Roose [propose yesterday](https://github.com/bitcoin/bips/pull/1525#issuecomment-1979297869) a total stack size limit instead of per-item size limit. Any thoughts on that? Does it allow for any other use-cases?
09:25 < instagibbs> 4bd188c4383d6e614e18f79dc337fbabe8464c82 satoshi changes it to 520, but also disabled
09:26 < instagibbs> (end digression!)
09:28 < EthanHeilman> What happens in soft fork when half of the network has adapted it but half the network has not and someone publishes a transaction on the p2p network that uses the softforked behavior? (related to the question)
09:28 < arminsdev> SCRIPT_VERIFY_OP_CAT essentially decouples OP_SUCCESS verify flags from OP_CAT usage. Take a look at how this is being used here: https://github.com/0xBEEFCAF3/bitcoin/blob/armin/re-enable-op-cat/src/script/interpreter.cpp#L1985
09:28 < arminsdev> By introducing the discouragement flag, mempool policy can inform developers to not use CAT during a activation period.
09:28 < arminsdev> Take a look https://github.com/0xBEEFCAF3/bitcoin/blob/armin/re-enable-op-cat/src/validation.cpp#L1021
09:29 < glozow> so DISCOURAGE_OP_CAT is for granularity vs DISCOURAGE_OP_SUCCESS?
09:29 < rot13maxi> I get the rational of having a flag to specifically target OP_CAT for "allow" or "disallow". I'm curious about the rationale for having both
09:30 < Guest42> hi
09:32 < EthanHeilman> It is like a two phase commit, OP_CAT = true,  DISCOURAGE_OP_CAT = true. Until the network has fully moved to OP_CAT = true. Then you can set DISCOURAGE_OP_CAT =false. I believe this approach was taken with segwit as well right, right?
09:32 -!- Guest42 [~Guest42@212.129.78.57] has quit [Quit: Client closed]
09:33 -!- Guest42 [~Guest42@212.129.78.57] has joined #bitcoin-core-pr-reviews
09:33 < EthanHeilman> 6. What is the expected behavior when neither flag is set?
09:35 < glozow> It's just an op success?
09:37 < arminsdev> glozow correct!
09:37 < EthanHeilman> and op success is discouraged
09:37 < glozow> so, rejected in policy and accepted in consensus
09:38 < EthanHeilman> 7. Why is it important to verify if OP_CAT is being executed in a non-segwitv0 or base-script context at L474:interpreter.cpp rather than inside the opcode definition
09:38 < EthanHeilman> https://github.com/0xBEEFCAF3/bitcoin/blob/armin/re-enable-op-cat/src/script/interpreter.cpp#L475
09:38 < EthanHeilman> this question is a fun one!
09:38 < hernanmarino> glozow: thanks for clarifying that, i was wondering about the meaning of discouraged in this context 
09:39 < instagibbs> "pretty please don't use this, this an upgrade hook"
09:40 < arminsdev> For those that want to dig a bit deeper into the different flags and their responsibilities take a look at this gh thread
09:40 < arminsdev> https://github.com/bitcoin-inquisition/bitcoin/pull/39#discussion_r1480760257
09:41 < reardencode> EthanHeilman: otherwise it would fail before getting to the opcode execution even for Tapscript?
09:41 < Ayelen> 7- to avoid exponential memory usage?. Tapscript enforces a maximum stack element size of 520 bytes
09:42 < kouloumos> I can't find when/if the discourage flag was used with previous softforks, links appreciated
09:42 < EthanHeilman> almost! What would be the behavior for non-tapscript transactions if we enabled OP_CAT and put the check IS OPCAT ENABLED in the script definiition
09:43 < glozow> by opcode definition, do you mean L543?
09:44 < EthanHeilman> yes
09:45 < hernanmarino> i have a question related to the discourage flag... this is only related to how bitcoin inquisition works right ? Activation in the real Bitcoin mainnet will not work this way, will it ?
09:45 < EthanHeilman> If implemented it like:
09:45 < EthanHeilman>  L543: case OP_CAT: {
09:45 < EthanHeilman>  L544:     if not tapscript ... return set_error(serror, SCRIPT_ERR_DISABLED_OPCODE); // Disabled opcodes (CVE-2010-5137).
09:49 < reardencode> not seeing a difference :-\
09:49 < Mccalabrese> all nontapscript transactions would fail?
09:49 < arminsdev> hernanmarino thats a good question. It certainly could operate the same way in mainnet. It depends on what the bitcoin core policy is for consensus changes
09:49 < EthanHeilman> I took me a half a day to figure this out.
09:49 < EthanHeilman> Consider the following non-tapscript script
09:49 < EthanHeilman> OP_FALSE IF OP_CAT END_IF OP_TRUE
09:49 < EthanHeilman> Currently this script will fail because the check for if OP_CAT is a disabled op code happens before we reach the logic that checks conditionals
09:50 < reardencode> oh, but the if check there hiding on the line right above the switch(opcode). would be a consensus change for legacy scripts.
09:50 < reardencode> nice one.
09:51 < EthanHeilman> Whereas if we move that check into the op code definition (L543) then
09:51 < EthanHeilman> OP_FALSE IF OP_CAT END_IF OP_TRUE
09:51 < EthanHeilman> will succeed for non-tapscript transactions. Such a change will result in a hardfork.
09:51 < EthanHeilman> reardencode exactly!
09:51 < Ayelen> EthanHeilman: thanks
09:51 < instagibbs> feel like we should have a term for things that fail if interpreter hits it unconditionally
09:52 < dergoegge> EthanHeilman: would any of our tests catch this?
09:52 < dergoegge> (i don't think so)
09:53 < EthanHeilman> Yes, in fact I first noticed this because an existing script test caught it. For more details see:
09:53 < EthanHeilman> https://github.com/bitcoin-inquisition/bitcoin/pull/39#discussion_r1465110469
09:54 < EthanHeilman> I believe the script test that caught it was this one:
09:54 < EthanHeilman> ["'a' 'b' 0", "IF CAT ELSE 1 ENDIF", "P2SH,STRICTENC", "DISABLED_OPCODE", "CAT disabled"],
09:55 < EthanHeilman> so good work to whoever wrote that
09:55 < dergoegge> that's great!
09:55 < EthanHeilman> 8. This PR introduces new semantics for taproot-related script tests in script_tests.json. For example, this test. What issues or inefficiencies existed with the previous testing strategy?
09:56 < glozow> very cool, totally doesn't make this code look scary at all
09:56 < glozow> (the interpreter code in general i mean)
09:56 < arminsdev> test example = https://github.com/0xBEEFCAF3/bitcoin/blob/armin/re-enable-op-cat/src/test/data/script_tests.json#L2530
09:58 < BlueMatt[m]> do we have fuzz tests which can test an old script interpreter and a new one and check that its not a hard fork?
09:58 < instagibbs> differential script fuzzing sounds like a dergoegge question
09:58 < dergoegge> not that i'm aware but i've been meaning to work on it
09:58 < monlovesmango> needing to check/validate multiple previous items on the stack?
09:59 < EthanHeilman> I would love to see that. I did a bit of fuzzing on OP_CAT and I want to do more.
10:00 < hernanmarino> dergoegge: that would something nice to have, I'm not an expert in fuzz testing but I'm willing to help if you or someone takes the lead
10:00 < EthanHeilman> For reference, this is that a tapscript script test looked like before we added these new test semantics
10:00 < EthanHeilman> [
10:00 < EthanHeilman>     [
10:00 < EthanHeilman>         "c24f2c1e363e09a5dd56f0",
10:00 < EthanHeilman>         "89a0385490a11b6dc6740f3513",
10:00 < EthanHeilman>         "7e4c18c24f2c1e363e09a5dd56f089a0385490a11b6dc6740f351387",
10:00 < EthanHeilman>         "c0d6889cb081036e0faefa3a35157ad71086b123b2b144b649798b494c300a961d",
10:00 < EthanHeilman>         0.00000001
10:00 < EthanHeilman>     ],
10:00 < EthanHeilman>     "",
10:00 < EthanHeilman>     "0x51 0x20 0x25b1769ec1939759dd5a97f5f02186e986280ae2bd0588ad13f28c8ce5044fa6",
10:00 < EthanHeilman>     "P2SH,WITNESS,TAPROOT",
10:00 < EthanHeilman>     "OK",
10:00 < EthanHeilman>     "TAPSCRIPT (OP_CAT) tests CAT on different sized random stack elements. Script is CAT PUSHDATA1 0x18 c24f2c1e363e09a5dd56f089a0385490a11b6dc6740f3513 EQUAL"
10:00 < EthanHeilman> ],
10:02 < EthanHeilman> This is what that a very similar tapscript script test looks like now
10:02 < EthanHeilman> [
10:02 < EthanHeilman>     [
10:02 < EthanHeilman>         "c24f2c1e363e09a5dd56f0",
10:02 < EthanHeilman>         "89a0385490a11b6dc6740f3513",
10:02 < EthanHeilman>         "CAT 0x4c 0x18 0xc24f2c1e363e09a5dd56f089a0385490a11b6dc6740f3513 EQUAL",
10:02 < EthanHeilman>         "<AUTOGEN:CONTROLBLOCK>",
10:02 < EthanHeilman>         0.00000001
10:02 < EthanHeilman>     ],
10:02 < EthanHeilman>     "",
10:02 < EthanHeilman>     "0x51 0x20 <AUTOGEN:TAPROOTOUTPUT>",
10:02 < EthanHeilman>     "P2SH,WITNESS,TAPROOT,OP_CAT",
10:02 < EthanHeilman>     "OK",
10:02 < EthanHeilman>     "TAPSCRIPT Tests CAT on different sized random stack elements and compares the result."
10:02 < EthanHeilman> ],
10:03 < hernanmarino> new semantic is more human readable and less error prone 
10:04 < EthanHeilman> Yes! And you can edit it by hand without writing code to generate a valid control block so it makes it easy to add new tapscript tests to script_tests.json
10:05 < EthanHeilman> We are five minutes past the hour, I'm happy to lurk and discuss this more, I'm going to bring the meeting to a end
10:05 < EthanHeilman> Please add any comments or questions to the PR
10:06 < rot13maxi> EthanHeilman was there other feedback you were hoping to get but didn't?
10:06 < Guest42> Is there another meeting tomorrow?
10:07 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews
10:08 < EthanHeilman> #endmeeting
10:08 < glozow> thanks EthanHeilman and arminsdev! :)
10:09 -!- vmammal [~vmammal@107.181.222.132] has quit [Quit: Client closed]
10:09 -!- Ayelen [~ayelen@181.29.131.163] has quit []
10:10 < hernanmarino> thanks !
10:10 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit []
10:10 < EthanHeilman> Meeting is over, only question we didn't get to but I really wanted to was
10:10 < EthanHeilman> 9. Are there any additional test cases you would like to see implemented that are not covered by the functional tests or the script tests in script_tests.json?
10:10 < EthanHeilman> comment on the PR for any additional test ideas
10:10 -!- Naiyoma [~Naiyoma@41.80.113.237] has joined #bitcoin-core-pr-reviews
10:11 -!- Mccalabrese [~Mccalabre@189.178.60.103] has quit [Quit: Client closed]
10:11 -!- alfonsoromanz [~alfonsoro@181.29.131.163] has quit []
10:11 -!- twhittle [~twhittle@c-73-70-223-137.hsd1.ca.comcast.net] has quit [Quit: Client closed]
10:12 < reardencode> thanks all!
10:12 < EthanHeilman> thanks everyone
10:13 -!- EthanHeilman [~EthanHeil@2601:189:8180:6320:8a2:3df0:39e4:566a] has quit [Quit: Client closed]
10:13 -!- Guest21 [~Guest21@99.255.159.147] has quit [Quit: Client closed]
10:22 -!- Guest42 [~Guest42@212.129.78.57] has quit [Ping timeout: 250 seconds]
10:22 -!- Naiyoma [~Naiyoma@41.80.113.237] has quit [Quit: Client closed]
10:27 -!- rot13maxi [~rot13maxi@45.134.142.205] has quit [Quit: Client closed]
10:32 -!- Al79 [~Al79@41.85.177.98] has quit [Quit: Client closed]
10:37 -!- arminsdev [~arminsdev@199.94.1.207] has quit [Quit: Client closed]
10:38 -!- marcofleon [~marcofleo@wsip-174-73-86-98.ph.ph.cox.net] has quit [Quit: Connection closed]
10:59 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
10:59 -!- Al79 [~Al79@41.85.177.98] has joined #bitcoin-core-pr-reviews
11:00 -!- Al79 [~Al79@41.85.177.98] has quit [Client Quit]
11:03 -!- Talkless [~Talkless@mail.dargis.net] has quit [Ping timeout: 264 seconds]
11:05 -!- jdnewby [~jdnewby@75.162.68.46] has quit [Quit: Client closed]
13:40 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
14:07 -!- maflcko [~none@107.172.8.183] has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
14:08 -!- maflcko [~none@107.172.8.183] has joined #bitcoin-core-pr-reviews
14:13 -!- mehounme [~mehounme@41.85.177.98] has joined #bitcoin-core-pr-reviews
14:15 < mehounme> Hi
14:21 -!- mehounme [~mehounme@41.85.177.98] has quit [Remote host closed the connection]
14:24 -!- mehounme [~mehounme@41.85.177.98] has joined #bitcoin-core-pr-reviews
14:24 -!- mehounme [~mehounme@41.85.177.98] has quit [Client Quit]
14:25 -!- mehounme [~mehounme@41.85.177.98] has joined #bitcoin-core-pr-reviews
14:25 -!- mehounme [~mehounme@41.85.177.98] has quit [Remote host closed the connection]
15:00 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:59 -!- cbergqvist [~chris@84-216-185-21.customers.ownit.se] has quit [Ping timeout: 252 seconds]
16:30 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-pr-reviews
16:30 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
18:39 -!- tdb3 [~tdb3@158.101.115.10] has quit [Ping timeout: 240 seconds]
18:57 -!- furszy [~furszy@user/furszy] has quit [Quit: ZNC - https://znc.in]
18:59 -!- furszy [~furszy@104.128.239.93] has joined #bitcoin-core-pr-reviews
18:59 -!- furszy [~furszy@user/furszy] has changed host
22:23 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has quit [Remote host closed the connection]
22:52 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
23:38 -!- PaperSword [~Thunderbi@securemail.qrsnap.io] has joined #bitcoin-core-pr-reviews
--- Log closed Thu Mar 07 00:00:20 2024