--- Day changed Wed Aug 07 2019 01:28 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 01:36 -!- jonatack [6dca6b93@109.202.107.147] has joined #bitcoin-core-pr-reviews 02:39 -!- setpill [~setpill@unaffiliated/setpill] has quit [Read error: Connection reset by peer] 02:41 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 03:08 -!- jonatack [6dca6b93@109.202.107.147] has quit [Remote host closed the connection] 04:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 04:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 04:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 04:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 04:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 04:39 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 05:23 -!- jonatack [6dca6b93@109.202.107.147] has joined #bitcoin-core-pr-reviews 05:23 -!- jonatack [6dca6b93@109.202.107.147] has quit [Remote host closed the connection] 05:54 -!- Eyal4all [uid344073@gateway/web/irccloud.com/x-nomzeoykpcqwippu] has joined #bitcoin-core-pr-reviews 07:30 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 08:03 -!- Eyal4all [uid344073@gateway/web/irccloud.com/x-nomzeoykpcqwippu] has quit [Quit: Connection closed for inactivity] 08:18 -!- lightlike [~lightlike@2001:16b8:5797:1d00:a4ab:d863:44bc:ec79] has joined #bitcoin-core-pr-reviews 08:18 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 08:30 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 09:00 < jnewbery> we'll get started in an hour 09:06 -!- usil [~nicko@32.111.198.104.bc.googleusercontent.com] has joined #bitcoin-core-pr-reviews 09:34 -!- PaulTroon [~paultroon@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 09:36 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 09:40 -!- han1 [68850941@104.133.9.65] has joined #bitcoin-core-pr-reviews 09:40 -!- han1 [68850941@104.133.9.65] has quit [Remote host closed the connection] 09:40 -!- hanh [68850941@104.133.9.65] has joined #bitcoin-core-pr-reviews 09:50 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 09:51 -!- afigs [642bef32@100-43-239-50.static-ip.telepacific.net] has joined #bitcoin-core-pr-reviews 09:56 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews 09:59 -!- ajonas [~ajonas@192.241.238.29] has joined #bitcoin-core-pr-reviews 10:00 < jnewbery> hi 10:00 < kanzure> hi 10:00 < emilengler> Hi 10:00 < emilengler> Does it start now :) 10:00 < lightlike> hello 10:00 < ajonas> hi 10:00 < Emzy> Hi 10:01 < jnewbery> notes/questions for today's meeting: https://bitcoin-core-review-club.github.io/16345.html 10:01 < digi_james> Hello .. 10:01 < emilengler> Oh that is my pull request 10:01 < ccdle12> hello 10:01 < jnewbery> Welcome everyone! I'll start with my normal reminder: The point of the review club is to give participants the tools and knowledge they need to take part in the Bitcoin Core review process on github. 10:02 < jnewbery> This meeting is for you to ask any questions you want about the review process, so you can test/review/leave comments on github. 10:03 < jnewbery> one other announcement before we begin. I recently became aware of this repo from fanquake: https://github.com/fanquake/core-review 10:03 < jnewbery> it's got a bunch of tools for helping with Bitcoin Core review. Might be worth taking a look at. 10:03 < jnewbery> ok, let's get started 10:04 < jnewbery> from the notes: "Users often want to get the block details for a block at a specific height, and so need to run getblockhash and then getblock with the hash returned." 10:04 < jnewbery> First question: What other solutions have been proposed to this user request? 10:04 < emilengler> Two PRs 10:04 < emilengler> And others which overload arguments at the getblock method 10:04 < Emzy> To use a prefix for the hight 10:04 < jkczyz> Use parameter type; string for hash and integer for height 10:05 < emilengler> Like getblock 42 to get block 42 or getblock HASHOFBLOCK42 10:05 < fjahr> 1. plain overloading 2. overloading with prefix 3. new rpc call 10:05 < jnewbery> any others? 10:05 < emilengler> jnewbery: iirc no 10:05 < jkczyz> JSON RPC promiose pipelinig 10:06 < jnewbery> jkczyz: yes, that was proposed by wumpus I think 10:06 < jnewbery> the comment here: https://github.com/bitcoin/bitcoin/pull/16439#issuecomment-514038924 gives a good summary of different approaches 10:06 < lightlike> also leave as is and leave it up to the users to create aliases etc. locally 10:06 < jkczyz> yep, to avoid the round trip but still define the interface in terms of primitives 10:07 < jnewbery> ok, next question: What are the problems with overloading RPC arguments to be interpreted as different types? 10:07 < emilengler> It might be interpreted wrong 10:07 < jkczyz> Might be ambiguous as to whether the user intended a height or hash 10:08 < Emzy> Introducing parsing bugs. 10:08 < emilengler> especially in plain overloading 10:08 < jnewbery> jkczyz: right. The block hash is in hex, so it's possible (although unlikely) that every hex character is a digit, and the RPC would interpret it as a height 10:08 < jnewbery> Emzy: yes, it makes parsing logic more complex 10:08 < PaulTroon> script could fail in a way that gives bad input and then call returns wrong value instead of error 10:08 < emilengler> This wouldn't happen with a prefix character 10:09 < hanh> Changing a widely-used interface may break software depending on it. 10:09 < jkczyz> parameter names could be confusing if named as hash but given a height 10:09 < emilengler> +1 10:10 < jnewbery> There is already one RPC that overloads an argument in this way. Does anyone know which one? 10:10 < jnewbery> actually more than one 10:11 < jnewbery> getblockstats has a hash_or_height argument that can take a blockhash or height: https://github.com/bitcoin/bitcoin/blob/e5fdda68c6d2313edb74443f0d1e6d2ce2d97f5e/src/rpc/blockchain.cpp#L1770 10:12 < jnewbery> and getblock has a 'verbosity' argument that can take a number or bool: https://github.com/bitcoin/bitcoin/blob/e5fdda68c6d2313edb74443f0d1e6d2ce2d97f5e/src/rpc/blockchain.cpp#L877 10:12 < emilengler> Is a hash a num? 10:12 < jnewbery> one issue with these is that it makes type-checking a bit messier 10:12 < jnewbery> emilengler: hash is always a string in RPC methods 10:12 < digi_james> How is parsing ambuity solved with getblockstats? 10:12 < emilengler> But why is it RPCARG::Type::NUM then 10:13 < jnewbery> you can see here: https://github.com/bitcoin/bitcoin/blob/e5fdda68c6d2313edb74443f0d1e6d2ce2d97f5e/src/rpc/blockchain.cpp#L1826 if isNum() {} else {} 10:14 < jnewbery> emilengler: To allow the case where a block height is passed 10:14 < achow101> range in importmulti can also be multiple types 10:14 < achow101> as can timestamp 10:14 < emilengler> jnewbery: But why is it a num then? 10:14 < emilengler> This is also a problem of overloading 10:14 < emilengler> Could be problematic at autocomplete 10:15 < emilengler> And how do you transmit the hash? It is just weird if params:["hash"] 10:15 < jnewbery> yeah - overloading can make client code more complex 10:16 < emilengler> And why is getblockstats using a NUM and not a STR 10:16 < emilengler> A string can contain ASCII numbers which can be converted to real numbers then 10:16 < emilengler> But vice versa it is a bit more complicated 10:16 < emilengler> So a STR would be probably a better choice then 10:17 < emilengler> And there we have the problems of overloading... 10:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:17 < jnewbery> The proposal in https://github.com/bitcoin/bitcoin/pull/16439 allows a string argument to represent either a hash or a height (when prefixed with @). What are people's thoughts about that? 10:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:18 < Emzy> Better because no dublicated code. 10:18 < jkczyz> I'd prefer it to be done at the client side rather than server side 10:19 < PaulTroon> would prevent accidental entry interpreted as height 10:19 < lightlike> it is nice that is solves the problem for many RPCs, not just for getblock 10:19 < jnewbery> Emzy: yeah, I think the duplicate code is a problem in 16345. It could be re-implemented with less duplicate code though 10:19 < emilengler> Worser because overloading which I don't think is agood approach 10:19 < jkczyz> While the extra round trip is not desirable, once you get a block you can get the next and previous hash easily 10:20 < emilengler> Maybe it is also causing backwards comptabitlity issues 10:20 < jnewbery> jkczyz: what do you think about ryanofsky's comment "Can someone be specific about an actual advantage that would come from moving logic from server to client, or be clear about what types of logic should be moved?" ... 10:20 < Emzy> I think it would be harder to optimize it. You would simply do it in sequence. 10:20 < emilengler> I general don't like to change existing RPC calls except new parameters are being added 10:20 < jnewbery> "If I'm writing a rust client or any other type of client, it would seem like the more logic there is in bitcoin-cli, the more work I have to do in rust to get access to the same functionality, and the greater chance I have of introducing bugs or inconsistencies." 10:21 < jnewbery> lightlike: yeah, I agree. It's nice that a small amount of code can add this functionality for many RPC methods 10:22 < jnewbery> emilengler: I can't see how this would be an issue. This is making the RPC method more permissive. It shouldn't impact any clients that are already using those methods 10:22 < PaulTroon> old code can't accidentally trigger new behavior, but new code can use it with out adding a new set of RPC calls to support 10:22 < jnewbery> PaulTroon: exactly 10:22 < emilengler> jnewbery: Are you sure? It is changing a parameter type 10:22 < jnewbery> the parameter type is a string in all cases 10:23 < jnewbery> either the hex string for the block hash or a string "@" for a block height 10:23 < PaulTroon> changing the behavior of getblockstats would be problematic though, so it would probably have to continue to use a different system 10:24 < jnewbery> the only (slight) change in behaviour is for the height_or_hash parameter in getblockstats 10:24 < emilengler> jnewbery: Yeah but is now using RPCArg::Type::BLOCK_REF 10:24 < emilengler> And not RPCArg::Type::STR_HEX 10:24 < PaulTroon> perhaps could continue to use the deprecated form with out @ 10:24 < jnewbery> you can see that aj has maintained that parameter, but placed it behind a deprecation flag: https://github.com/bitcoin/bitcoin/pull/16439/commits/792c2a5dbca346e1b693446accd68b6a5448292f 10:24 < emilengler> Maybe this causing issues but I'm not 100% sure 10:24 < jkczyz> jnewbery: Generally, I'm in favor if keeping the interface here simple given the hash at given block height can change near head. Otherwise, I would lean more towards hiding the complexity from the client. 10:25 < jnewbery> we talked about RPC deprecation in some detail a few weeks ago: https://bitcoin-core-review-club.github.io/15996.html 10:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:26 < jnewbery> jkczyz: that's a good point. One response on twitter to this PR review club topic was "Ugh, I see this causing people to do a lot of stupid things that don't handle forks and orphans correctly." 10:26 < jnewbery> can anyone give more detail or examples of how that could cause issues? 10:27 < emilengler> The overloading? 10:27 < lightlike> getblock will stay the same during a reorg, while getblock will change 10:27 < jnewbery> lightlike: exactly 10:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:27 < digi_james> lightlike: +1 10:28 < jnewbery> you could imagine someone doing `getblock<@height>` followed by `getblockstats<@height>` or similar during a re-org 10:28 < Emzy> this sould be expected if you are at the tip of the chain. 10:28 < jnewbery> and expecting the results to be for the same block 10:29 -!- martinus [d4c5a2e1@212-197-162-225.adsl.highway.telekom.at] has joined #bitcoin-core-pr-reviews 10:29 < Emzy> ok. that a good example, for using the hash instead. 10:29 -!- martinus [d4c5a2e1@212-197-162-225.adsl.highway.telekom.at] has quit [Remote host closed the connection] 10:30 < jkczyz> Also, traversing the chain should ideally follow next/prev links rather than incrementing the height 10:30 < jnewbery> but often, I use `get block $(getblockhash())`. That would also change if I ran it across a re-org 10:30 < emilengler> jnewbery: Why 10:31 < emilengler> It would still work 10:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:31 < jnewbery> because the inner call to getblockhash would return a different hash 10:31 -!- Emzy is now known as emzy 10:32 < jnewbery> if I'm not inspecting or storing the hash returned and just using it immediately in a call, then it's basically equivalent to just calling the method with a height 10:32 < emilengler> jnewbery: Is getblockhash also being changed? 10:32 < jnewbery> yes, getblockhash() will return the hash of the block at that height in the main chain 10:32 < jnewbery> which can change during a re-org 10:32 < emilengler> Yeah I know 10:32 < emilengler> Oh know I got what you mean 10:32 < emilengler> now* 10:33 < emilengler> But then using heights as identifiers is general a bad approach 10:33 < emilengler> No matter which implementation 10:34 < jnewbery> right, near the tip, height shouldn't be used as a unique identifier for blocks 10:34 < jnewbery> Next question: What test cases have been added to these two PRs? What additional test cases could be added? 10:34 < jkczyz> getblock(getblockhash()) == getblock(@) 10:35 < aj> (hmm, what if we made "@589082" give an error "height is too near the tip" ?) 10:35 < jnewbery> jkczyz: yeah, I think that's the test case added in 16439 10:35 < jkczyz> Could add tests for exceptional cases (height is out of bounds) 10:35 < jnewbery> a wild aj appears! 10:35 < jnewbery> aj: I think I like that 10:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:36 < jnewbery> jkczyz: I agree. The tests are only testing the happy case. I don't think any of the failure modes are tested 10:36 < jnewbery> ie giving a too-high height or a -ve height 10:36 < emzy> woul'd be a warning better? 10:37 < hanh> Could add parsing exceptional cases, something like "@xyz" 10:37 < jnewbery> warnings are often ignored. I tend to think of them as mostly useless 10:37 < jnewbery> hanh: +1 10:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 10:37 < emilengler> hanh: +1 10:38 < emilengler> Yeah good question what happens when you enter something invalid to getblock @height 10:38 < emilengler> Like a string 10:38 < emilengler> Even if its a string technically already 10:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 10:38 < jnewbery> emilengler: it should always be a string 10:39 < lightlike> aj, jnewbery: wouldn't it be necessary to be able get the block of a near-tip height, even if you know that it might change in a reorg? or do you suggest to refer to the old getblockhash(height) in this case? 10:39 < PaulTroon> parsing strings is always a rich source of errors 10:40 < emilengler> PaulTroon: +1, I think tests should be done dynamically 10:40 < jnewbery> 16439 actually contains two proposals for the price of one: using '@height' and parsing on the server; or using '%height' and parsing on the client. The last two commits implement the '%height' in the client approach 10:40 < aj> lightlike: if you want the tip, you don't know the exact height and will expect change 10:40 < aj> lightlike: if you want the tip, you don't know the exact height and will expect changing results -- i mean 10:41 < digi_james> Near the tip: If a client makes multiple (different) rpc calls using height, and would like to ensure that the return relates to the same chain, it would have to check tip/branch before, and after these rpc calls, to ensure they relate to the same chain. Actually reorgs can happen anytime, this doesn' t help. 10:41 < jnewbery> lightlike: I'd suggest making the error text descriptive: "height given is close to the tip. Call getblockhash(height) to get the current blockhash at heigh , but be aware that it could change with a shallow reorg." or something similar 10:42 < aj> lightlike: i think if you want stuff near the tip you probably want to walk backwards from the tip manually, so heights are irrelevant? the times i'd want to say "tell me about block at height X" is for things well in the past where i just don't want to copy-and-paste a full hash... 10:42 < digi_james> * correlating calls only works with blockhash nvrmind. 10:43 < jnewbery> ok, final question: Which approach do you like best? 10:43 < emilengler> I like mine (adding a new RPC call) because I'm skeptical about overloading parameters 10:44 < jkczyz> Neither :) Actaully, @height in client (e.g., bitcoin-cli) I'd prefer 10:44 < aj> jkczyz: (that's the %height one jnewbery mentioned) 10:44 < jkczyz> yep 10:44 < emzy> The one with the rpc-client change. 10:45 < emzy> %height in short. 10:45 < fjahr> It has been said that this was requested multiple times but do we know anything more about this? Who would use this frequently but not frequently enough to use a script/alias? 10:45 < lightlike> I'm undecided between leave-as-is and the on by aj. 10:46 < PaulTroon> I like the @height change if consistently used by rest of the RPC, otherwise emilengler's is cleaner 10:46 < jnewbery> fjahr: good question. I think it's just convenience. People don't like those extra few keystrokes. 10:47 < emilengler> Also thought about this to be honest :P 10:47 < jnewbery> did anyone have any other questions about this PR or review in general in the last few minutes? 10:47 < lightlike> fjahr: also, this is one of the first things many new users will do with bitcoind. at least it was for me. 10:47 < PaulTroon> any sort of standards document around RPC interface? 10:47 < emilengler> lightlike: Yeah 10:48 < emilengler> PaulTroon: standards? This is a Bitcoin Core only thing 10:48 < hanh> fjahr my experience with this RPC is it's heavily used in blockchain extraction software. 10:48 < PaulTroon> emilengler: I mean convention within Bitcoin Core, like there is for coding 10:48 < emilengler> hanh: Like blockexplorers? 10:49 < emilengler> PaulTroon: I think the manpages are fine for this :) 10:49 < hanh> That's one example. 10:49 < hanh> Anywhere you need to extract blokchain data into an external storage 10:49 < jnewbery> PaulTroon: we've been trying to rationalize the RPC methods. Take a look at RPCHelpMan and RPCArg::Type for example 10:49 < jkczyz> hanh: yes, but once a block is retrieved the next/prev links could be followed 10:50 < jnewbery> those are new, and impose some structure on the methods and arguments 10:50 < PaulTroon> jnewbery: +1 10:50 < hanh> jkczyz Yes. 10:50 < emilengler> jkczyz: For this we have the prevHash field and the getblockcount 10:51 < jkczyz> emilengler: yeah, I think we're on the same page 10:52 < hanh> emilengler The problem is if you have a pipeline continuously extracting blockchain, you will keep pinging the tip of the chain. Of course, once you get the block, you can use prevHash. 10:52 < emilengler> Do you going from the top to the bottom 10:53 < emilengler> mean* 10:53 < jnewbery> ok, let's wrap it up there. Thanks everyone. Next week is #16115 "On bitcoind startup, write config args to debug.log (config)" 10:53 < emilengler> Ok, see you next week. Was funny today :) 10:54 < PaulTroon> +1 10:54 < digi_james> Thanks! 10:54 * jkczyz waves 10:54 < emzy> Thanks jnewbery and all others! 10:54 < jnewbery> if anyone has suggestions for future PRs to cover or if you want to host a future meeting, please messge me or comment on https://github.com/bitcoin-core-review-club/bitcoin-core-review-club.github.io/issues/14 10:54 < jnewbery> thanks all! 10:54 -!- PaulTroon [~paultroon@rrcs-184-74-240-156.nyc.biz.rr.com] has left #bitcoin-core-pr-reviews [] 10:54 < hanh> Thanks jnewbery 10:55 -!- remyers [~paultroon@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 10:55 < lightlike> thanks! 10:55 -!- ajonas [~ajonas@192.241.238.29] has quit [Quit: leaving] 10:56 < emilengler> Yes thank you all especially you jnewbery 10:57 -!- remyers [~paultroon@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [] 11:10 -!- afigs [642bef32@100-43-239-50.static-ip.telepacific.net] has quit [Remote host closed the connection] 11:11 < provoostenator> If you want to watch achow101 live refactor the wallet box PR: https://www.twitch.tv/achow101/ 11:27 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 11:35 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 11:40 -!- hanh [68850941@104.133.9.65] has quit [Remote host closed the connection] 11:57 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 12:18 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [] 12:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds] 12:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 12:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 12:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 12:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 12:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 12:36 -!- MasterdonX [~masterdon@185.193.36.226] has quit [Ping timeout: 245 seconds] 12:45 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has quit [Quit: pinheadmz] 12:49 -!- pinheadmz [~matthewzi@172.255.125.150] has joined #bitcoin-core-pr-reviews 13:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 13:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 13:32 -!- pinheadmz [~matthewzi@172.255.125.150] has quit [Quit: pinheadmz] 14:05 -!- MasterdonX [~masterdon@5.226.137.122] has joined #bitcoin-core-pr-reviews 14:05 -!- diverger [~div@89.238.130.200] has joined #bitcoin-core-pr-reviews 14:11 -!- pinheadmz [~matthewzi@208.69.41.101] has joined #bitcoin-core-pr-reviews 14:55 -!- booyah_ [~bb@193.25.1.157] has quit [Read error: Connection reset by peer] 15:23 -!- booyah_ [~bb@193.25.1.157] has joined #bitcoin-core-pr-reviews 15:27 -!- booyah_ [~bb@193.25.1.157] has quit [Remote host closed the connection] 16:06 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-bsihzsmbdqhsuctf] has quit [Quit: Connection closed for inactivity] 16:11 -!- lightlike [~lightlike@2001:16b8:5797:1d00:a4ab:d863:44bc:ec79] has left #bitcoin-core-pr-reviews ["Leaving"] 17:13 -!- pinheadmz [~matthewzi@208.69.41.101] has quit [Quit: pinheadmz] 18:04 -!- pinheadmz [~matthewzi@c-73-92-181-51.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 18:05 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Quit: Leaving] 19:32 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 248 seconds] 19:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:31 -!- davterra [~none@209.58.185.33] has quit [Quit: Leaving] 20:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:40 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 20:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds] 20:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 20:46 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 20:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 22:52 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews