--- Day changed Wed Aug 05 2020 00:03 -!- jeremyrubin [~jr@2601:645:c200:f539:bd98:3c2c:9403:b8b3] has quit [Ping timeout: 240 seconds] 00:44 -!- slivera__ [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews 00:47 -!- slivera_ [~slivera@14-201-44-251.tpgi.com.au] has quit [Ping timeout: 264 seconds] 00:54 -!- dr-orlovsky [~dr-orlovs@194.230.155.142] has joined #bitcoin-core-pr-reviews 01:11 -!- Tralfaz [~Davterra@2601:603:4f00:63d0::1] has joined #bitcoin-core-pr-reviews 01:13 -!- Davterra [~Davterra@2601:603:4f00:63d0::1] has quit [Ping timeout: 260 seconds] 01:24 -!- dr-orlovsky [~dr-orlovs@194.230.155.142] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 01:32 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 01:32 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 02:46 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 02:47 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 03:05 -!- Kyle25Crona [~Kyle25Cro@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:14 -!- Kyle25Crona [~Kyle25Cro@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds] 03:44 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 03:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 03:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 03:59 -!- vasild_ is now known as vasild 04:55 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds] 05:19 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 05:30 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 05:35 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 05:41 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 06:11 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:39 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving] 06:40 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 07:25 -!- Tralfaz [~Davterra@2601:603:4f00:63d0::1] has quit [Remote host closed the connection] 07:25 -!- Tralfaz [~Davterra@2601:603:4f00:63d0::1] has joined #bitcoin-core-pr-reviews 07:28 -!- slivera__ [~slivera@103.231.88.10] has quit [Remote host closed the connection] 08:20 < michaelfolkson> For those who need to look up how IPC and RPC differ :) https://stackoverflow.com/questions/2161674/is-there-a-difference-between-rpc-and-ipc 08:22 < jonatack> michaelfolkson: yes, i proposed to add a link to the notes: https://github.com/bitcoin-core-review-club/website/pull/235#discussion_r463933690 08:23 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 08:30 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 09:09 -!- jeremyrubin [~jr@2601:645:c200:f539:bd98:3c2c:9403:b8b3] has joined #bitcoin-core-pr-reviews 09:16 -!- narcelio [~nf@189.59.193.142] has joined #bitcoin-core-pr-reviews 09:18 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 09:19 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 09:19 -!- narcelio [~nf@189.59.193.142] has left #bitcoin-core-pr-reviews [] 09:28 -!- narcelio [~nf@189.59.193.142] has joined #bitcoin-core-pr-reviews 09:48 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews 09:50 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection] 09:56 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:57 -!- lightlike [~lightlike@p200300c7ef16f20014e75e8ff300e012.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:59 -!- runcrypto [50bdcf8f@143.207.189.80.dyn.plus.net] has joined #bitcoin-core-pr-reviews 10:00 < ryanofsky> #startmeeting 10:00 < ryanofsky> (hope I did that right) 10:00 < michaelfolkson> hi 10:00 < troygiorshev> hi 10:00 < ryanofsky> Hi, welcome one and all to the weekly PR review club! 10:01 < fjahr> hi 10:01 < lightlike> hi 10:01 < jkczyz> hi 10:01 < jonatack> hi 10:02 < ryanofsky> PR this week is https://bitcoincore.reviews/19160.html 10:02 < ryanofsky> You can say y/n if you've looked or haven't had a chance to look at it 10:02 < nehan> hi 10:02 < emzy> Hi 10:02 < fjahr> y 10:02 < emzy> n 10:02 < troygiorshev> y 10:02 < jkczyz> n 10:02 < lightlike> y 10:02 < nehan> y 10:02 < jonatack> (hi also for ariard who is here) 10:02 < jonatack> y/n 10:03 -!- LarryRuane [62f5cc94@c-98-245-204-148.hsd1.co.comcast.net] has joined #bitcoin-core-pr-reviews 10:03 < ryanofsky> Thanks, this is a big PR that and notes and questions there are about a portion of it, mostly meant to be a prompt 10:03 < michaelfolkson> I've looked at it but I feel as if I haven't :) 10:03 < ariard> y 10:04 -!- stroller_ [~stroller@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:04 < ryanofsky> Yeah we can start off with any questions you might have. No stupid questions and we can really talk about anything 10:04 < ryanofsky> Even "how does a pipe work?" general stuff not specific to bitcoin 10:05 < ryanofsky> Or just general difficulties or feedback 10:05 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has joined #bitcoin-core-pr-reviews 10:06 < ariard> okay wrt to the threading model, it's handle lower by libmultiprocess? 10:06 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews 10:06 < ryanofsky> Threading is just supposed to be transparent 10:07 < ryanofsky> So if GUI calls a wallet method to find out the wallet balance, and the wallet is running in a different process 10:07 < ariard> the wallet process spwans a thread to serve ? 10:07 < ryanofsky> On the GUI process side, the getbalance method sends a requests, blocks, waits for a response, and then returns 10:08 < ryanofsky> Yes, and the wallet process sees that a call has come in from gui thread #234 10:08 < fjahr> I haven't studied capnp before. I remember seeing some discussion on it in the core dev irc. Is it worth re-reading any of that to get more of the context about it's use in core? 10:08 < ryanofsky> If it already has a thread to handle requests for #234, it runs calls the wallet getbalance method on that thread, otherwise it makes a new thread to handle that request and future ones 10:09 < ariard> and this service thread die with the connection? 10:10 < ryanofsky> ariard, yes, the service thread dies if the connection is closed 10:10 < lightlike> a very general q: what is the main goal for introducing multiprocesssing to core: Mostly architectural, i.e. is better separation of wallet/node/gui? or would it also affect performance? 10:10 < ryanofsky> it also dies if the thread #234 is joined before the connection is closed 10:11 < nehan> why are the threads short lived instead of long lived? presumably the wallet, gui, etc are going to run for a long time 10:12 < michaelfolkson> fjahr: I don't think capnp understanding is key to this https://github.com/bitcoin/bitcoin/pull/10102#issuecomment-289999980 10:12 < ryanofsky> lightlike, there are different goals and tradeoffs. generally good for security, bad for performance, good for flexibility, like being able to have node run in backgground and attach/detach wallets and guis 10:12 < michaelfolkson> But yeah I haven't studied it either 10:12 < fjahr> michaelfolkson: but I want to understand it :) 10:13 < ryanofsky> what kinds of things do you want to know about capnp? 10:13 < ariard> memory separation, if your bitcoin-node gets corrupted, it won't be able to swallow your keys 10:13 < ryanofsky> it is basically a code generator, io frameowork, file format, and protocol 10:13 < ariard> also exposing interfaces means you can build tool against them 10:14 < michaelfolkson> lightlike: See the comments on this Slide 5 https://docs.google.com/presentation/d/1AeJ-7gD-dItUgs5yH-HoEzLvXaEWe_2ZiGUUxYIXcws/edit#slide=id.g255500ac67_0_21 10:14 < ryanofsky> you could write a custom protocol, the advantage of using capnp is that when you want to add a new method or class or parameter, you just add it in a schema instead of having to write manual code 10:14 < fjahr> ryanofsky: no specific things about it, just if there is something worth reading on why it was chosen (i guess you chose it?) for this job 10:15 < lightlike> great thanks! 10:16 < ryanofsky> It was chosen just because I played with it an liked it. A similar alternative would be gRPC 10:16 < ariard> and also you can now move wallet/gui code in different repo, you don't have wallet utxo tracking meddle with validation 10:16 < fjahr> ryanofsky: that's good enough for me, thanks! 10:16 < ryanofsky> gRPC is lower lever, though, it doesn't track objects so requires more work to support bidirectional callbacks 10:17 < ryanofsky> in capnp each object has an identity, and you call a method on a specific object. while in gRPC you just define request and response formats and have to look up the objects yourself from the request 10:18 < michaelfolkson> Adding spawn support seems like it would be one of the final steps after untangling all the code between the different components. Is that all done now and ready to be merged? 10:19 < michaelfolkson> I can see the various open PRs 10:19 < ryanofsky> michaelfolkson, yes basically all that code is already merged 10:20 < michaelfolkson> Oh wow. This is further along than I thought it was then 10:20 < ryanofsky> all the code in the src/interfaces/ directory was introduce to define the interfaces between node, wallet, and gui components 10:21 < michaelfolkson> We can go through the questions you posed ryanofsky https://bitcoincore.reviews/19160.html 10:22 < ryanofsky> So this PR adds support for spawning, and then the next pr 10102 calls it to actually make bitcoin-node, bitcoin-gui, bitcoin-wallet processes specialize and talk to each other with the spawn support here 10:22 < jkczyz> Ah, so by "bidirectional", it doesn't simply mean returning data back from child to parent process but rather supporting callbacks from child to parent more generally 10:23 < ryanofsky> michaelfolkson, sure, one pre-question. The notes focused on IpcProcess, IpcProtocol, and Init classes introduced in this PR. We it clear what these classes do, and anyone want to summarize? 10:24 < ryanofsky> jkczyz, exactly yes, lots of interface methods take std::function arguments, or objects arguments 10:24 < ryanofsky> when a client passes a server a std::function or an object, the server can call back to that function or call an object method at any time, and the framework handles it 10:24 < nehan> ryanofsky: IpcProcess sets things up, IpcProtocol is used for the parent and child to actually talk to each other 10:25 < michaelfolkson> IpcProcess spawns new child processes 10:26 < ryanofsky> nehan, right, and one reason IpcProtocol is separate from IpcProcess, is so different protocols other than capnp could be supported in the future 10:26 < michaelfolkson> Child being a process that the parent process needs to complete a task right 10:26 < ryanofsky> michaelfolkson, right, it handles all the details of spawning and being spawned 10:26 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 265 seconds] 10:27 < troygiorshev> ryanofsky: and init actually, er, holds everything? 10:27 < ryanofsky> michaelfolkson, right in 10102, bitcoin-gui spawns a bitcoin-node, and bitcoin-node spawns a bitcoin-wallet, so these are long running tasks 10:27 < nehan> is there some kind of architecture/picture diagram of the processes? 10:28 < troygiorshev> ^ +1 10:28 < michaelfolkson> So the child processes could be running continuously. The "parent" would be the process which is was running first 10:28 < troygiorshev> Something like the steps in init.h but for those of us who like pictures :) 10:28 < ryanofsky> troygiorshev, yes. Init does a few things but the main reason it exists is because the only way the framework allows processes to communicate by calling object methods, and Init is the object a spawned process provides to start off with 10:29 < ariard> nehan: https://docs.google.com/presentation/d/1AeJ-7gD-dItUgs5yH-HoEzLvXaEWe_2ZiGUUxYIXcws/edit#slide=id.p 10:29 < ryanofsky> No diagram exists, but a sequence diagram would be a good thing to have summarizing the init.h comment I agree 10:30 < michaelfolkson> I get why you want to be able to start/stop processes. But generally the processes would be running continuously and concurrently. They aren't going to be regularly stop/started? 10:31 < ryanofsky> michaelfolkson, maybe could be. Use cases I'm thinking of is you leave node running, but start and stop wallets, and start and stop gui 10:31 < michaelfolkson> Maybe they would... you only really need the node process running all the time 10:32 < nehan> ariard: saw that. doesn't have a diagram. 10:32 < ryanofsky> It's just an interesting thing you could do, though 10:32 < ryanofsky> So question 1 was just about the entry point line 180 in main(): https://github.com/ryanofsky/bitcoin/blob/pr/ipc-echo.7/src/bitcoind.cpp#L180-L185 10:32 < nehan> in addition to what's described in init.h, it would be nice to see a diagram which shows the steps for the node, gui, and wallet. it's not obvious to me why the gui spawns a node and the node spawns the wallet? 10:34 < troygiorshev> related is, if the gui spawns a node, then does that mean we can't nicely shut down the gui without shutting down the node? Or is the distinction between parent and child sortof flexible? 10:34 < ryanofsky> nehan, that's a good question. gui spawning node and node spawning wallet are just artifacts of the way the code works currently and are just supported so no user changes are required 10:34 < michaelfolkson> You mean the ordering doesn't make sense? What is the parent and the child in this context nehan? 10:34 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 10:34 < nehan> michaelfolkson: gui is parent to node, node is parent to wallet 10:35 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 10:35 < ryanofsky> yes. Should note that the parent/child relationships talked about with respect to spawning aren't some permanent part of the connections. Connections are fully bidirectional 10:35 < michaelfolkson> But the roles can be reversed right? The node can be the parent to the wallet. Just what happens in the general case 10:36 < ryanofsky> So if the node spawns a few wallets on startup, and some separate wallet processes are started which connect back to the node, all the wallets are equivalent 10:36 < nehan> ryanofsky: ah, thanks for clarifying 10:36 < thomasb06> https://capnproto.org/ 10:37 < ryanofsky> I guess the first question was: How do the child processes provide useful functionality to the parent processes if they never run the code after the IpcProcess::serve() calls in main()? 10:39 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-pr-reviews 10:39 < michaelfolkson> I didn't get this question :) I don't know why they would need to run the code *after* to be useful 10:39 < ryanofsky> michaelfolkson, good point 10:40 < troygiorshev> the communication is done, ultimately, through the fd used in serve. Is that what this question is going for? 10:40 < ryanofsky> They definitely don't need to run code after. The question was assuming if you saw code in main that said if (condition) exit, you would might be suspicious 10:41 < ryanofsky> troygiorshev, yes. Answer is just that the serve method blocks and handles requests, so there is nothing to do when it exits 10:41 < ryanofsky> Probably bad question :) I definitely baked an assumption into it 10:42 < ryanofsky> Next question goes into the serve() implementation: https://github.com/ryanofsky/bitcoin/blob/pr/ipc-echo.7/src/interfaces/ipc.cpp#L35-L61 10:42 < nehan> ryanofsky: i had trouble tracing through the code to answer this question. where is the block? 10:42 < michaelfolkson> Practise definitely makes perfect in all things (including PR review club hosting ;) ) 10:42 < ryanofsky> yep getting close to perfection soon I think :) 10:43 < ryanofsky> nehan, yes, that's basically the question! the "if (init->m_process && init->m_process->serve(exit_status))" serve() call blocks 10:44 < nehan> here? https://github.com/ryanofsky/bitcoin/blob/pr/ipc-echo.7/src/interfaces/capnp/ipc.cpp#L79 10:44 < lightlike> i thought that the protocol implementation (capnp) has a loop in its serve() method, so everything useful would happen during the IpcProcess::serve() call. 10:44 < troygiorshev> nehan: I was thinking Line 62 of that file 10:45 < ryanofsky> that line is saying "if I am a child process spawned to handle requests from a parent, and I am done handling requests, then exit without executing the rest of main()" 10:45 < ryanofsky> yes in this case it is line 62 10:46 < ryanofsky> line 79 is the equivalent place, but in the parent process, not the child process 10:46 -!- jimpo [~jimpo@ec2-13-57-39-52.us-west-1.compute.amazonaws.com] has left #bitcoin-core-pr-reviews ["Leaving"] 10:46 < troygiorshev> ryanofsky: ah thanks 10:47 < troygiorshev> i think these questions link nicely into your question 4 10:48 -!- LarryRuane [62f5cc94@c-98-245-204-148.hsd1.co.comcast.net] has quit [Remote host closed the connection] 10:48 < michaelfolkson> line 79 is the equivalent place, but in the parent process? Why is the parent exiting? 10:49 < nehan> where is m_loop initialized? 10:49 < ryanofsky> michaelfolkson, oh I just meant it is the equivalent place in terms of blocking, lines 62 and 79 both block the thread and wait for and respond to incoming requests 10:49 < michaelfolkson> Oh ok gotcha 10:50 < ryanofsky> nehan, it's initialized in the m_loop.emplace() calls 10:50 < nehan> ryanofsky: ah, ok thanks 10:51 < michaelfolkson> I think troygiorshev wants to answer question 4 10:51 < ryanofsky> as you can see and as troygiorshev question 4 reference gets to, IpcProtocol is kind of a messy glue code class 10:51 < ryanofsky> it has connect() and serve() methods that take file descriptors 10:52 < ryanofsky> in a future PR it also gets a listen() method to be able to accept incoming connections 10:53 < ryanofsky> but question 4 first asks if you wanted to get rid of capnproto, and use a different protocol like gRPC or JSONRPC or something custom, would the method definitions hve to change? 10:54 < ryanofsky> and then if you wanted to use a different type of channel other than pipes/file descriptors, how would it have to change? 10:55 < michaelfolkson> I'm guessing the first part of that question is no 10:55 < troygiorshev> without looking deeply into any IPC protocols, I want to guess no to both questions 10:56 < ryanofsky> michaelfolkson, yes, that's basically design goal to make protocol swappable 10:56 < nehan> i guess if you wanted to use something other than file descriptors you'd have to tell the processes how to talk to each other 10:56 < troygiorshev> i can't picture a useful connectionless IPC protocol (though I'm sure there's something out there) 10:57 < ryanofsky> troygiorshev, could be yes/no in different cases, like this is just passing int file descriptors 10:57 < nehan> like spawn() would have to pass in something else 10:57 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 10:57 < ryanofsky> but on windows file descriptors aren't weird HANDLE types instead of ints, so maybe you'd pass handles 10:58 < ryanofsky> or if you wanted to use openssl, maybe you'd pass objects with read and write methods, or callbacks or something else 10:58 < troygiorshev> right, unless those can be represented by an int 10:58 < troygiorshev> (but that's very antithetical to the whole "everything is an object" approach of windows) 10:58 < ryanofsky> I think it works in practice if your int is big enough, but yeah 10:59 < ryanofsky> THese questions were mostly intended to be prompts to look at the code, so glad we did a little bit of that :) 11:00 < ryanofsky> Can wrap up, and happy to answer try to clarify anything else later 11:00 < troygiorshev> thanks ryanofsky and thanks for the amazing notes! 11:00 < nehan> ryanofsky: why did you choose file descriptors as the interface instead of something more general? what would it take to run processes on different machines? 11:00 < nehan> thanks! 11:01 < lightlike> thanks! 11:01 < ryanofsky> nehan, just for convenience because I never did the windows port yet. When I do I'll probably just make a typedef 11:02 < ryanofsky> Even using file descriptors though, you could pass connections to different machines since TCP sockets give you file descriptors too 11:02 < michaelfolkson> So this process separation marathon is almost over? Just the four remaining PRs to get merged?! https://github.com/bitcoin/bitcoin/projects/10 11:04 < michaelfolkson> It is really hard to catch up on all these years of work in an afternoon haha. I think we covered a previous PR on interfaces at a previous PR review club 11:04 < ryanofsky> michaelfolkson, Basically yes with exception that starting bitcoin-wallet tool and connecting to node isn't greately useful even with those 4 prs 11:04 < michaelfolkson> This in February https://bitcoincore.reviews/17954.html 11:05 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Ping timeout: 256 seconds] 11:05 < ryanofsky> followup PR would add a "serve" wallet tool subcommand or something similar so the wallet tool could connect to the node and then actually do useful operations 11:05 < ryanofsky> Yeah, there's a lot here. Appreciate you guys taking interest and digging in. 11:06 < michaelfolkson> Nice. Well thanks for doing this and your patience! It is certainly a really important project 11:06 < jonatack> thanks ryanofsky, owe you a review on this -- 11:07 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection] 11:07 < jonatack> concept ack ofc and would like to see it move forward 11:08 < ryanofsky> Anything I can do to help (s/guys/all/ above by the way too :) 11:13 -!- stroller_ [~stroller@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 240 seconds] 11:13 -!- hanhua [63687d99@99-104-125-153.lightspeed.sntcca.sbcglobal.net] has quit [Remote host closed the connection] 12:09 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:23 -!- runcrypto [50bdcf8f@143.207.189.80.dyn.plus.net] has quit [Remote host closed the connection] 12:27 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 264 seconds] 12:28 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 13:14 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 13:14 -!- Tralfaz is now known as davterra 13:15 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-pr-reviews 13:28 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has joined #bitcoin-core-pr-reviews 13:29 -!- narcelio [~nf@189.59.193.142] has quit [Ping timeout: 256 seconds] 13:38 -!- lightlike [~lightlike@p200300c7ef16f20014e75e8ff300e012.dip0.t-ipconnect.de] has quit [Quit: Leaving] 13:54 < michaelfolkson> https://bitcoin.stackexchange.com/questions/98398/what-is-the-motivation-behind-russell-yanofskys-work-to-separate-bitcoin-core-i 14:07 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 14:11 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 14:46 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 14:49 -!- fox2p [~fox2p@cpe-66-108-40-125.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 14:53 -!- rafalcpp [~racalcppp@ip-178-214.ists.pl] has quit [Read error: Connection reset by peer] 15:44 < ryanofsky> Wow, nice writeup! Thanks for that! 15:46 < ryanofsky> This may be first the time I can reliably know my motivation for doing something :) 15:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 15:56 -!- davterra [~Davterra@2601:603:4f00:63d0::1] has quit [Ping timeout: 244 seconds] 15:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 15:58 -!- vasild_ is now known as vasild 16:44 -!- tryphe_ is now known as tryphe 17:01 -!- slivera [~slivera@103.231.88.10] has joined #bitcoin-core-pr-reviews 17:06 -!- slivera_ [~slivera@14-201-44-251.tpgi.com.au] has joined #bitcoin-core-pr-reviews 17:09 -!- slivera [~slivera@103.231.88.10] has quit [Ping timeout: 264 seconds] 17:57 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 18:23 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #bitcoin-core-pr-reviews 18:23 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 18:24 -!- Davterra [~Davterra@2601:603:4f00:63d0::1] has joined #bitcoin-core-pr-reviews 18:27 -!- Tralfaz [~Davterra@37.120.215.173] has joined #bitcoin-core-pr-reviews 18:29 -!- Davterra [~Davterra@2601:603:4f00:63d0::1] has quit [Ping timeout: 244 seconds] 18:31 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 246 seconds] 18:32 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 18:39 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 19:47 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: leaving] 19:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 19:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 20:26 -!- gzhao408 [~textual@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:33 -!- adaminsky [499e3e4f@c-73-158-62-79.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 21:34 -!- adaminsky [499e3e4f@c-73-158-62-79.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 22:52 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 22:52 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 22:52 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 23:03 -!- slivera__ [~slivera@217.138.204.138] has joined #bitcoin-core-pr-reviews 23:06 -!- slivera_ [~slivera@14-201-44-251.tpgi.com.au] has quit [Ping timeout: 240 seconds] 23:17 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 240 seconds]