--- Day changed Wed Feb 19 2020 00:34 -!- fanquake [sid369002@gateway/web/irccloud.com/x-kjjicniivqzkqzxu] has quit [Ping timeout: 248 seconds] 00:34 -!- felixweis [sid154231@gateway/web/irccloud.com/x-vqmefdkkwyinjdil] has quit [Ping timeout: 248 seconds] 00:34 -!- fanquake [sid369002@gateway/web/irccloud.com/x-pqxjugmmgotzfczm] has joined #bitcoin-core-pr-reviews 00:35 -!- surja795 [uid422261@gateway/web/irccloud.com/x-vafewsphpbmjllbg] has quit [Ping timeout: 248 seconds] 00:35 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-poaqqqpfoopjpogd] has quit [Ping timeout: 248 seconds] 00:35 -!- surja795 [uid422261@gateway/web/irccloud.com/x-lvahpiaoigdfxpgk] has joined #bitcoin-core-pr-reviews 00:35 -!- felixweis [sid154231@gateway/web/irccloud.com/x-waynunhvumbjtoqa] has joined #bitcoin-core-pr-reviews 00:35 -!- digi_james [sid281632@gateway/web/irccloud.com/x-dfjtnwutsesastim] has quit [Ping timeout: 248 seconds] 00:36 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 248 seconds] 00:37 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-fliqnewyacvxaztl] has joined #bitcoin-core-pr-reviews 00:37 -!- digi_james [sid281632@gateway/web/irccloud.com/x-fmymzdzbsvpjkemv] has joined #bitcoin-core-pr-reviews 00:42 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 00:44 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews 02:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 02:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 03:05 -!- Matilde14Lowe [~Matilde14@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews 03:11 -!- slivera [~slivera@217.138.204.69] has quit [Remote host closed the connection] 03:11 -!- Matilde14Lowe [~Matilde14@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 272 seconds] 03:53 -!- jungly [~jungly@79.8.200.97] has quit [Remote host closed the connection] 05:12 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 05:40 -!- emilengler [~emilengle@stratum0/entity/emilengler] has joined #bitcoin-core-pr-reviews 05:47 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 05:48 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 05:54 -!- jungly [~jungly@a-si4-24.tin.it] has joined #bitcoin-core-pr-reviews 06:11 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-1-200.adslplus.ch] has joined #bitcoin-core-pr-reviews 06:20 -!- molly [~molly@unaffiliated/molly] has quit [Quit: Leaving] 06:22 -!- dr-orlovsky [~dr-orlovs@xdsl-188-155-1-200.adslplus.ch] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 06:38 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 07:53 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 07:55 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds] 08:17 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has joined #bitcoin-core-pr-reviews 08:18 < rockzombie2> Hello, are the bitcoin pr reviews all done via irc, or is there a voip channel as well? 08:20 < rockzombie2> Looks like it's just irc 08:23 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 08:30 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 08:38 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews 08:40 -!- pinheadmz_ [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 08:41 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 268 seconds] 08:41 -!- pinheadmz_ is now known as pinheadmz 08:48 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has quit [Remote host closed the connection] 09:00 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has joined #bitcoin-core-pr-reviews 09:09 -!- jungly [~jungly@a-si4-24.tin.it] has quit [Ping timeout: 240 seconds] 09:12 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 09:17 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has quit [Remote host closed the connection] 09:29 < jnewbery> Hi folks. We'll get started in about 30 minutes. Russ Yanofsky is hosting his PR 17954: https://bitcoincore.reviews/17954.html 09:30 < jnewbery> rockzombie2: Bitcoin Core PR reviews are done on github. This channel is for contributors who want to learn about the review process by discussing a different PR each week. Details here: https://bitcoincore.reviews/ 09:33 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 260 seconds] 09:38 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews 09:40 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:43 -!- lightlike [~lightlike@p200300C7EF117900604FFB0EFD89D946.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:43 -!- SirRichard [~MaxSikors@cblmdm72-240-113-19.buckeyecom.net] has joined #bitcoin-core-pr-reviews 09:45 < ryanofsky> Hi all, meeting will start in about 15 minutes. First "hi" at UTC 18:00 wins the meeting 09:46 -!- ryanofsky [russ@jumpy.yanofsky.org] has left #bitcoin-core-pr-reviews [] 09:46 -!- lightlike [~lightlike@p200300C7EF117900604FFB0EFD89D946.dip0.t-ipconnect.de] has quit [Client Quit] 09:47 -!- ryanofsky [russ@jumpy.yanofsky.org] has joined #bitcoin-core-pr-reviews 09:50 < emilengler> ryanofsky: Challenge accepted 09:56 -!- pbleam [268ebb82@38.142.187.130] has joined #bitcoin-core-pr-reviews 09:59 < luke-jr> hi 10:00 < emilengler> hi 10:00 < SirRichard> hi 10:00 < jnewbery> hi 10:00 < emzy> hi 10:00 < pbleam> hi 10:00 < nehan_> hi 10:00 < ariard_> hi 10:00 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has joined #bitcoin-core-pr-reviews 10:00 < ajonas> hi 10:00 < ryanofsky> #startmeeting 10:00 < ryanofsky> hi 10:01 < rockzombie2> hi 10:01 < ryanofsky> Welcome to the review meeting! 10:01 < felixweis> Hi 10:01 < ryanofsky> Link to notes and PR is https://bitcoincore.reviews/17954.html 10:01 -!- van [18bf0fb0@ool-18bf0fb0.dyn.optonline.net] has joined #bitcoin-core-pr-reviews 10:01 < ryanofsky> Everyone can say hi (who didn't already) to let people know you're here 10:02 < ryanofsky> Reminder that everyone is here to learn, and all types of questions are encouraged. Anything that seems confusing is probably confusing to other people, and good to spend time figuring out together 10:02 < emilengler> Yeah then I have a question! 10:02 < ryanofsky> I have some prompt questions at the link above, but it is fine not to get through them if there are other things people want to talk about 10:02 < ryanofsky> No need to ask to ask, just ask! 10:02 < jonatack> hi 10:03 < andrewtoth> hi 10:03 < emilengler> I'm still a bit confused and not really that much into thread safe programming therefore reviewing this PR is hard 10:03 < emilengler> Can someone give a brief introduction to this? 10:03 < ryanofsky> Anyone want to jump in with a short summary? 10:05 < ryanofsky> I can say that the motivation for this is to be able to get rid of the Chain::Lock interface. Because that interface is low level and lets wallets slow down and potentially lock the node 10:06 < andrewtoth> It seems to be taking a piece of #16426 which we reviewed here previously, and splitting it out into its own PR no? 10:06 < luke-jr> I guess the important thing for reviewers to check, is that the code doesn't touch anything it actually needs the lock for 10:06 < rockzombie2> My limited understanding (not specifically related to bitcoin): Sharing resources among threads can cause confilcts in state. One solution is to "lock" a resource. There are many ways to be "thread-safe". Some more topics for further research that might help in understanding: Dining Philosophers problem, Spin-locks, Software Transactional Memory. 10:06 < ryanofsky> absolutely yes, yes, and yes 10:07 < luke-jr> I suggest looking at each commit individually 10:07 < luke-jr> (there's 11) 10:07 < nehan_> is it an invariant that wallet tip is always behind or at chain tip? 10:07 < ariard_> nehan_: no it can be also forked of chain tip 10:08 < luke-jr> or even ahead, if reindexing or such 10:08 < ariard_> that where you may have trouble and the initial reason of Russ working on #17954 10:08 < ryanofsky> yes, this gets to the question: What’s the difference between calling interfaces::Chain::getHeight() and CWallet::GetLastBlockHeight()? When will the values be the same, and when will they be different? 10:09 < ryanofsky> the next question looks into a specific example: In commit “wallet: Avoid use of Chain::Lock in listsinceblock” the call to locked_chain->getHeight() is replaced with pwallet->GetLastBlockHeight(). If listsinceblock is called with a non-null block hash, how does this change prevent transactions that are older than the specified block from being mistakenly printed? 10:09 < ryanofsky> commit: https://github.com/bitcoin/bitcoin/pull/17954/commits/e276b6821430ec2c18aba55137daf98bae770054 10:11 < ryanofsky> the changes to listsinceblock are small, but the existing code is dense, people may have questions just about that 10:14 < ryanofsky> the key to which transactions are printed is the abs(tx.GetDepthInMainChain()) < depth check on line 1616 10:16 < ryanofsky> the depth value is computed differently now with wallet tip: pwallet->GetLastBlockHeight(), instead of node tip: locked_chain->getHeight() 10:18 < ryanofsky> if a new block is connected, and the wallet didn't catch up yet. the height variable will be bigger or smaller? and the depth value? 10:19 < ariard_> ryanofsky: there is also a behavior change I think by returning lastblock=findAncestorByHeight? 10:20 < ryanofsky> yes, there are two behavior changes in the function 10:20 < ryanofsky> the lastblock behavior change is more complicated to think about since it involves multiple listsinceblock calls 10:21 < nehan_> if the wallet is behind chain tip, depth will be smaller? 10:21 < ryanofsky> the transaction listing height/depth change is simpler, because it can be understood looking at a single listsinceblock call 10:22 < ryanofsky> nehan_: yes depth is smaller, so older transactions that weren't requested won't be printed 10:23 < ryanofsky> This is a corner case race condition. Goal of PR is not to change behavior, but to clean up the API and fix some of these little races 10:23 < rockzombie2> Sorry, I'm still very new to this review process, but I'm hoping I can ramp up quickly by attending these reviews because I want to be helpful. As for testing your behavior changes, what are the cases I should try to test (and how exactly can I cover that test case in a multi-threaded environment?) 10:23 -!- frenchNoob [52fc80ea@lns-bzn-59-82-252-128-234.adsl.proxad.net] has joined #bitcoin-core-pr-reviews 10:24 < nehan_> ryanofsky: what do you mean by "older transactions that weren't requested won't be printed"? 10:25 < nehan_> you mean in the new behavior, it will print less? 10:25 < nehan_> but i'm not sure how those "weren't requested" 10:25 < ryanofsky> rockzombie2: great question, anybody have any suggestions for testing? i will say bitcoin core doesn't currently have great for testing infrastrucuture to force code to run in order and simulate races 10:25 < ryanofsky> but we are always adding new testing features 10:26 < ryanofsky> nehan_: listsinceblock is typically called with a specific block hash, so you only want to return transactions after that block 10:26 < luke-jr> or if that block isn't in the main chain, transactions reorg'd out 10:27 < nehan_> ryanofsky: yes. and in the new behavior, in the case where the wallet is behind chain, it will print fewer transactions. but it's not clear to me why those "weren't requested" 10:27 < ryanofsky> nehan_: yes I actually left something out 10:28 < ryanofsky> in order for there to be a race condition, the "auto locked_chain = pwallet->chain().lock();" line above has to be removed, which is removed in a later PR 10:28 < ryanofsky> the problem is in the comparison tx.GetDepthInMainChain() < depth 10:29 < ryanofsky> you don't want to compute the depth on the left side and the depth on the right side with two different tips 10:29 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 10:30 < nehan_> ryanofsky: ah ok, thanks. but isn't this fixed in the new code because both of things will be under cs_wallet? 10:30 < nehan_> ryanofsky: are you saying there *was* a race condition? 10:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 10:31 < ryanofsky> i should check on what the later PRs are doing, but it is saying there would be a race condition 10:31 -!- van [18bf0fb0@ool-18bf0fb0.dyn.optonline.net] has quit [Remote host closed the connection] 10:32 < ryanofsky> this might be a bad example, because it is talking about a theoretical race condition 10:32 < ryanofsky> but hopefully it at least suggests what the problem is, because this example is simpler than other cases like the one ariard was talking about that involves separate RPC calls 10:33 < jonatack> rockzombie2: WRT what cases to try to test, one thing you can try is look at the cases ryanofsky describes in the commit message, then look at the relevant unit and functional tests to see if the case is tested, and how (and if not, try adding it) 10:34 < ariard_> you shouldn't have a race condition even after chain lock removal because now you're relying on same tip for both computation 10:34 < ariard_> like finding the common ancestor and the comparison tx.GetDepthInMainChain() < depth 10:35 < ryanofsky> ariard_: yes you'd have to remove the wallet lock too, which i can't rememeber if we do 10:35 < nehan_> ariard_: this was my interpretation as well 10:35 < jonatack> for instance, in commit e276b682, look at the tests that are added in that commit, and at the those in test/functional/wallet_listsinceblock.py 10:36 < ariard_> ryanofsky: both are under cs_wallet lock so you can't get a block connected/disconnected in between 10:36 < rockzombie2> Thanks jonatack, I'll look into that 10:37 < ryanofsky> yes, this race condition will only happen we stop holding cs_wallet throughout the call 10:37 < jonatack> rockzombie2: fwiw, wallet_listsinceblock.py has some *really* interesting tests imo 10:37 < nehan_> how important is it to preserve all the little behavioral quirks in the wallet as you make these changes to pull out cs_main? do you know who relies on listsinceblock? 10:38 < ryanofsky> probably not too important, there was an interesting issue opened about listsinceblock and how it's intended to be used, trying to find it 10:39 < ryanofsky> the changes within listsinceblock are just meant to be minimal, if it would be simpler to change behavior in some way, that's be reasonable to do 10:40 < jonatack> fwiw i tried to add test coverage for block heights to listsinceblock.py https://github.com/bitcoin/bitcoin/pull/17535 10:40 < jonatack> but the PR went nowhere. it seems difficult nowadays to add functional test coverage. 10:40 < ryanofsky> i think this was the interesting listsinceblock issue I remembered: https://github.com/bitcoin/bitcoin/pull/9622 10:42 < ryanofsky> maybe someone wants to reason through the next question about listsinceblock: In the same commit, the call to locked_chain->getBlockHash(last_height) is replaced with pwallet->GetLastBlockHash(). How does this change result in a more accurate lastblock value that won’t result in missing transactions when passed to a subsequent listsinceblock call? 10:43 -!- r8921039 [~r8921039@2601:644:303:18c0:317f:b7a5:ff5:2e3] has joined #bitcoin-core-pr-reviews 10:43 < ariard_> rockzombie2: you should test this on the cli, by doing reorg and calling RPC in a while loop, at least I remember doing this while working on some refactoring 10:45 < ryanofsky> i guess this question is also assuming that cs_main isn't locked throughout the call as is the case now 10:46 < ariard_> if wallet tip has been reorg out that avoid hitting the assert 10:46 < ryanofsky> or actually, no even with cs_main held, the node tip could be ahead of the wallet last block processed at the moment lock was acquired 10:48 < ariard_> but int that case you would find the last_height inside ChainActive so not a issue? 10:48 < ryanofsky> ariard yes, that is one case, but in the case of a reorg locked_chain->getBlockHash(last_height) could return a completely unrelated block 10:50 < ryanofsky> ariard_, yes i think you're right, there can only be missing transactions if there's a reorg. the other case would result in hitting an assert 10:51 < ryanofsky> IMO, code is easier to reason about if you only have to think about the wallet last block processed, and return information relative to that 10:51 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 10:51 < ryanofsky> not caring about the node tip or active chain 10:51 < ariard_> yes I agree on this, caring about both node tip and wallet tip is headache guarantee 10:53 < ryanofsky> ~10 minutes left, any questions about wallet/node in general, or maybe other parts of the PR? 10:55 < jonatack> ryanofsky: when you wrote "In the same commit, the call to locked_chain->getBlockHash(last_height) is replaced with pwallet->GetLastBlockHash()"... 10:55 < rockzombie2> I have a general question about the github Bitcoin group. Who exactly are all of those contributors? Like, how did they qualify and become the main body that accepts PRs to bitcoin core? 10:56 < jonatack> are you referring to the code in UniValue listsinceblock in rpcwallet.cpp, or? 10:57 < ryanofsky> jonatack: just the commit with that title https://github.com/bitcoin/bitcoin/pull/17954/commits/e276b6821430ec2c18aba55137daf98bae770054 10:57 < luke-jr> rockzombie2: in theory, it's just a matter of anyone doing the reviews needed 10:57 < ryanofsky> line 1641: ... pwallet->chain().findAncestorByHeight(pwallet->GetLastBlockHash() ... 10:58 < ryanofsky> rockzombie2: yes, there's no qualification process, decisions to merge are based on merits of the individual PR 10:58 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 10:58 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 10:59 < rockzombie2> I see 10:59 < jonatack> ryanofsky: ok, i thought you were describing a diff, and i wasn't finding it 10:59 < jonatack> rockzombie2: see the Peer Review section of CONTRIBUTING.md 11:00 -!- emilengler [~emilengle@stratum0/entity/emilengler] has quit [Quit: Leaving] 11:00 < ryanofsky> jonattack: ok hopefully clearer now, but let me know if it's not. there is one new line replacing two deleted lines there, and I was asking about that change 11:01 < ryanofsky> Looks like time is up, thanks everybody for participating! 11:01 < ryanofsky> #endmeeting 11:01 < nehan_> thanks 11:01 < rockzombie2> Thank you! 11:01 < jonatack> ryanofsky: there are two instances in that commit of one line replacing two others :p 11:01 < ryanofsky> Thanks for finding mistakes in my questions, too. Those were definitely on purpose 11:02 < jonatack> i suppose you mean the first instance 11:03 < emzy> thanks ryanofsky 11:03 -!- rockzombie2 [6cbd6b9a@108.189.107.154] has quit [Remote host closed the connection] 11:03 < jonatack> thanks for hosting ryanofsky, will try to finish review of that PR 11:03 < jnewbery> Thanks for hosting, ryanofksy! I'll publish the meeting log to the website soon 11:03 < ryanofsky> jonattack: just the place where "locked_chain->getBlockHash(last_height)..." is replaced 11:04 < jonatack> ryanofsky: thanks, was convinced we were discussing the other one :) 11:05 < jonatack> somehow misread and misunderstood, all good 11:06 < ryanofsky> Ah well, soon enough github will have an integrated IRC and we will avoid these problem 11:06 < jonatack> more reliance on github? goodness, i certainly hope not 11:07 < frenchNoob> Thanks 11:07 -!- pbleam [268ebb82@38.142.187.130] has quit [Remote host closed the connection] 11:11 -!- frenchNoob [52fc80ea@lns-bzn-59-82-252-128-234.adsl.proxad.net] has quit [Remote host closed the connection] 11:43 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 11:47 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 11:52 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Ping timeout: 260 seconds] 12:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 12:10 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:21 -!- slivera [~slivera@217.138.204.84] has joined #bitcoin-core-pr-reviews 12:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 12:56 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 12:59 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 13:01 -!- Marcos2Reichert [~Marcos2Re@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-pr-reviews 13:06 -!- Marcos2Reichert [~Marcos2Re@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 258 seconds] 14:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds] 14:31 -!- SirRichard [~MaxSikors@cblmdm72-240-113-19.buckeyecom.net] has quit [Quit: SirRichard] 14:33 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 14:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 14:53 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has joined #bitcoin-core-pr-reviews 14:55 < midnight> pfft. Wonder who that was. 15:09 -!- jungly [~jungly@host237-31-dynamic.249-95-r.retail.telecomitalia.it] has quit [Remote host closed the connection] 15:11 < jnewbery> Meeting log is up: https://bitcoincore.reviews/17954.html 15:46 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Read error: Connection reset by peer] 15:48 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 15:48 -!- TheRec [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 15:48 -!- TheRec [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 16:07 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 16:49 -!- slivera [~slivera@217.138.204.84] has quit [Ping timeout: 265 seconds] 16:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 17:02 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 17:32 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 19:46 -!- felixfoertsch23 [~felixfoer@i6DFA6266.versanet.de] has joined #bitcoin-core-pr-reviews 19:49 -!- felixfoertsch [~felixfoer@92.117.50.63] has quit [Ping timeout: 265 seconds] 20:17 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 20:20 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 20:21 -!- slivera [~slivera@217.138.204.100] has joined #bitcoin-core-pr-reviews 20:39 -!- r8921039 [~r8921039@2601:644:303:18c0:317f:b7a5:ff5:2e3] has quit [Remote host closed the connection] 20:48 -!- r8921039 [~r8921039@2601:644:303:18c0:74d1:df46:71d9:a613] has joined #bitcoin-core-pr-reviews 20:48 -!- r8921039 [~r8921039@2601:644:303:18c0:74d1:df46:71d9:a613] has quit [Read error: Connection reset by peer] 20:59 -!- pinheadmz [~matthewzi@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 21:15 -!- pinheadmz [~matthewzi@23.226.131.230] has joined #bitcoin-core-pr-reviews 21:47 -!- pinheadmz [~matthewzi@23.226.131.230] has quit [Quit: pinheadmz] 23:30 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 23:30 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 23:37 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 23:39 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 23:40 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 23:41 -!- jungly [~jungly@79.8.200.97] has joined #bitcoin-core-pr-reviews 23:44 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]