--- Day changed Thu Jun 04 2020 00:39 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 00:42 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 01:03 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 01:03 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 01:03 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 01:13 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection] 01:14 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews 02:34 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 02:56 -!- masterdonx2 [~masterdon@209.216.92.221] has joined #bitcoin-core-pr-reviews 02:56 -!- MasterdonX [~masterdon@209.216.92.221] has quit [Ping timeout: 265 seconds] 02:57 -!- wullon5 [~wullon@241.243.86.88.rdns.comcable.net] has quit [Ping timeout: 265 seconds] 02:57 -!- wullon5 [~wullon@241.243.86.88.rdns.comcable.net] has joined #bitcoin-core-pr-reviews 03:01 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 03:05 -!- Shirley88Reicher [~Shirley88@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:10 -!- Shirley88Reicher [~Shirley88@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 265 seconds] 03:37 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 04:45 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 05:33 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has joined #bitcoin-core-pr-reviews 05:33 -!- TheRec_ [~toto@84-75-225-47.dclient.hispeed.ch] has quit [Changing host] 05:33 -!- TheRec_ [~toto@drupal.org/user/146860/view] has joined #bitcoin-core-pr-reviews 05:36 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-jmtxdaapnvwvysok] has joined #bitcoin-core-pr-reviews 05:36 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [Ping timeout: 246 seconds] 05:36 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds] 05:36 -!- Henry151 [~bishop@ns3007530.ip-151-80-44.eu] has quit [Ping timeout: 264 seconds] 05:36 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-knrypoqzrmwzpbov] has quit [Ping timeout: 264 seconds] 05:36 -!- hebasto [~hebasto@95.164.65.194] has quit [Ping timeout: 264 seconds] 05:37 -!- Henry151 [~bishop@ns3007530.ip-151-80-44.eu] has joined #bitcoin-core-pr-reviews 05:37 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 05:48 -!- slivera [~slivera@103.231.88.28] has quit [Remote host closed the connection] 05:49 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 05:50 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 05:55 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 06:20 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 06:23 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:24 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 06:46 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving] 06:58 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:01 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:02 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:36 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:53 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 08:27 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:49 -!- tarboss [~tarboss@p54a03408.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 08:57 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 08:59 -!- tarboss [~tarboss@p54a03408.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 09:00 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 09:01 < jnewbery> reminder that we have a special session on PR 19070 in an hour: https://bitcoincore.reviews/19070.html 09:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 09:25 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 09:28 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 09:30 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:33 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 09:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 09:42 -!- riyasingh [~riyasingh@103.67.17.91] has joined #bitcoin-core-pr-reviews 10:00 < jnewbery> #startmeeting 10:00 < jnewbery> Hi! Welcome to the final special BIP 157 review club meeting. 10:00 < michaelfolkson> hi 10:00 < jnewbery> Notes and questions are here: https://bitcoincore.reviews/19070.html 10:01 < jkczyz> hi 10:01 < jnewbery> I think this might be the most interesting of the BIP 157 PRs, since it touches on some protocol design questions 10:02 < jnewbery> The code changes are small and simple, but the design decisions have important implications for BIP 157 clients 10:02 < jnewbery> is someone able to summarize the changes? 10:03 < jonatack> hi! 10:03 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 10:03 < jnewbery> hi jon! 10:03 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 10:03 < michaelfolkson> You mean the changes between jimpo's code and your code or this PR generally? 10:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 10:04 < jnewbery> ok, I'll summarize. It's adding signaling for BIP 157 support, using the NODE_COMPACT_FILTERS service bit in version and addr messages 10:05 < jnewbery> michaelfolkson: I meant generally in this PR, but if you want to summarize the differences from Jimpo's implementation, that'd be great 10:06 < michaelfolkson> Ok. One of the changes is that your code signals a node can provide filters for temporarily when it actually can't (as I understand) 10:07 < jnewbery> That's not exactly it 10:07 < jnewbery> it'll signal support for filters before it's fully built the cache. It's able to serve filters from blocks that it's processed 10:08 < michaelfolkson> Ah ok gotcha 10:09 < jnewbery> sorry, s/cache/index 10:09 < michaelfolkson> So it is not as simple saying willing to and unable to versus willing to and able to 10:09 < jnewbery> no 10:10 < jnewbery> with this PR, a node that signals NODE_COMPACT_FILTERS will always be able to serve the filters that it has built, it's just possible that it hasn't fully built the index yet 10:11 < michaelfolkson> I'm stuck in this IBD paradigm. Although there are some parallels they don't map perfectly 10:11 < jnewbery> There's one other change, which is that PrepareBlockFilterRequest() no longer calls BlockUntilSyncedToCurrentChain(). 10:11 < jnewbery> What are the implications of PrepareBlockFilterRequest() calling into BlockUntilSyncedToCurrentChain()? What are the implications of not calling BlockUntilSyncedToCurrentChain()? Which is preferable? Are there any alternative solutions? 10:12 < jnewbery> michaelfolkson: it's very similar to IBD. A node will signal NODE_NETWORK before it has completed IBD 10:12 < jkczyz> Calling it can prevent other messages from being processed. Not calling it may lead to requests not being served if the index does not contain the filter for the requested block 10:12 < jnewbery> that means "I can serve blocks". It doesn't mean "I'll be able to serve you any block that you request" 10:13 -!- riyasingh [~riyasingh@103.67.17.91] has quit [Remote host closed the connection] 10:13 < jnewbery> jkczyz: exactly. Calling that function blocks the message handling thread on the scheduler thread, which I think we should avoid unless absolutely necessary 10:13 -!- riyasingh [~riyasingh@103.67.17.91] has joined #bitcoin-core-pr-reviews 10:13 < jnewbery> the scheduler thread may be doing slow things like flushing the wallet to disk 10:14 < jkczyz> jnewbery: What if only some of the requested filters are available? Will we respond with a partial set? 10:15 < jkczyz> Haven't looked into this myself but it just came to mind 10:15 < jnewbery> And not blocking on the scheduler thread means that if we receive a request before the BlockConnected callback to the compact block index has been called, we won't be able to respond to that thread 10:16 < jnewbery> I think we'd reply with just a partial set. Let me check 10:17 < jnewbery> oh no, I'm wrong, we wouldn't respond with any of the filters 10:17 -!- riyasingh [~riyasingh@103.67.17.91] has quit [Client Quit] 10:18 < michaelfolkson> I'm going to keep hammering away at this IBD comparison. I know you discuss it here https://github.com/bitcoin/bitcoin/pull/19070#issuecomment-637056107 10:19 < jonatack> the original impl would have also entailed full node users having to stop and restart the node once the index finished building 10:19 < jnewbery> we return early here: https://github.com/bitcoin/bitcoin/blob/f5c003d3ead182335252558c5c6c9b9ca8968065/src/index/blockfilterindex.cpp#L426-L428 10:19 < jkczyz> michaelfolkson: I was trying to think if there is some analogy there. As in, if a node knows it shouldn't request a block from a peer, could there be a similar mechanism for filters 10:20 < jnewbery> jonatack: right. Well actually the original original implementation toggled the service bit dynamically. Some reviewers (including me) didn't like that, so jimpo changed it to be toggled manually 10:20 < michaelfolkson> But what is the reason for not responding with a partial set? Because filters are smaller than blocks and therefore you should expect to receive all of them in one go? 10:20 < jonatack> yeah, dynamic isn't better, for the reasons everyone stated 10:22 < jnewbery> the main difference with NODE_NETWORK is that in the initial version handshake, a node will tell its peer what its best block height is: https://btcinformation.org/en/developer-reference#version 10:22 < jnewbery> so the peer knows not to ask for higher blocks than that 10:22 < michaelfolkson> jkczyz: Yeah they do not map perfectly but I think they share enough characteristics such that there are a few questions like "Well IBD doesn't do what filter serving is doing. Why not?" 10:22 < MarcoFalke> with block filters the peer also knows not to ask for filters of block that the node hasn't announced, no? 10:24 < jnewbery> MarcoFalke: that's what the BIP says, but I think it's not a great design. I think it should be fine for a node to receive and relay a block before it's built the filter 10:24 < jnewbery> tying those two functions together seems like a bad idea 10:26 < jnewbery> it constrains implementers to couple together internal components that needn't be (eg here, blocking message handling on the scheduler thread so that the index gets built) 10:26 < jkczyz> jnewbery: ah, so doing so would also require re-introducing BlockUntilSyncedToCurrentChain? 10:26 < MarcoFalke> I see your point, but the validation interface queue needs to be processed either way at some point. Otherwise it will "overflow" 10:27 < jonatack> is it relatively common to see implementation development pushback and drive BIP updates? 10:27 < jnewbery> jkczyz: it requires some kind of sychronicity 10:27 < MarcoFalke> jonatack: Often issues with a BIP are only realized after it has been deployed. (E.g. bloomfilters, ouch) 10:28 < sipa> MarcoFalke: that's a fair example, but the issue there wasn't really discovered through implementation 10:28 < michaelfolkson> Steelmanning jimpo's argument. Changing the BIP is no big deal (imo). 10:28 < MarcoFalke> jup, not implementation, but more analysis 10:28 < michaelfolkson> "The BIP was designed to expose a consistent interface to clients, which is conceptually simpler, making it easier to implement client code correctly." 10:29 < michaelfolkson> You disagree with this jnewbery? 10:29 < jnewbery> one other way to achieve the same would be to have some kind of 'queue' of outstanding BIP157 requests, and if they can't be serviced, delay processing them (I put queue in quotes because I think we'd want to limit it to one request) 10:29 < sipa> jnewbery: i think you can also look at it the other way... why should an implementation detail in core affect the BIP? 10:29 < jonatack> MarcoFalke: thanks. that's not terribly surprising. 10:30 < sipa> for all kinds of network-servicable data peers can reasonable expect synchronicity... if you've processed a block, you can give it to others 10:30 < sipa> the bloom filter is weird in that it's started as an optional index, but now is becoming a network-servicable thing 10:30 < jnewbery> that'd be similar to the getdata queue, which can be processed out-of-order with other peers' requests: https://github.com/bitcoin/bitcoin/blob/365f1082e1e6ff1c2f53552c3871223e87a9d43f/src/net_processing.cpp#L3600-L3601 10:30 < jnewbery> (requests from a single peer are still treated serially) 10:31 < jnewbery> I don't think we should do this because it adds complexity, but there are potentially other ways to achieve what's wanted 10:32 < sipa> and if we want to say do block processing in a separate thread as well, like index building, we'll be faced with the same issues, and they need to be solved in a way that doesn't break the protocol synchronicity guarantees 10:32 < sipa> so it feels a bit strange to use a current implementation issue with filters specially 10:33 < jnewbery> sipa: I think my point is that we should avoid synchronicity between the core functionality of relaying blocks and the optional functionality of serving filters 10:33 < sipa> jnewbery: well we already have that, as long as it's an RPC interface 10:33 < sipa> if it's a P2P thing, it should behave P2P like 10:34 < jnewbery> I don't think the block example is the same. We wouldn't relay a block through headers if we hadn't yet processed it 10:35 < jkczyz> I've heard discussion around eventually committing the filter in the block (sorry if that terminology is no precise) -- at that point, does this problem simply go away (i.e., would the index be updated when the block is connected)? Or does the problem still exist for older blocks? 10:35 < sipa> jnewbery: i'm not sure i see the difference 10:37 < jnewbery> for compact blocks we do relay before processing, and I think that's the one place in net processing that we currently block on the scheduler thread: https://github.com/bitcoin/bitcoin/blob/365f1082e1e6ff1c2f53552c3871223e87a9d43f/src/net_processing.cpp#L1479-L1500 10:38 < jnewbery> sipa: if we send a header to a peer, we've already processed the block, so we can respond to a getdata request for it 10:38 < jnewbery> the header message itself is an indication that we can serve the block 10:38 < jnewbery> but why should it also be an indication that we have built the filter 10:39 < sipa> so perhaps we shouldn't send a header message to BIP157 peers before we've built the filter for it? 10:39 < jnewbery> we don't know which peers are BIP157 clients 10:39 < sipa> oh 10:39 < sipa> that's annoying 10:39 < jnewbery> the service bit is on the server side 10:41 < jnewbery> jkczyz: if the filter is committed, then presumably it's required for validation, and therefore a peer sending you a header for that block indicates that they have the filter 10:41 < MarcoFalke> We know they are clients when they send the first request, so what about disconnecting them instead of having them turn thumbs for 20 seconds (or whatever the timeout is) 10:41 < jnewbery> (again, it's slightly different for compact blocks where we relay a compact block before fully validating) 10:42 < sipa> yeah, compact blocks are explicitly asynchronously processed, as an exception to the usual protocol guarantees, with a good reason 10:42 < sipa> it seems BIP157 is written with an assumption of synchronous processing 10:43 < jnewbery> sipa: right, and with an assumption that servers will always be able to service any request 10:44 < sipa> and actually implementing that seems to require not announcing headers until the index has caught up? 10:44 < jnewbery> I'd prefer to not add this message-handler thread blocking, but I don't think it's the end of the world if we do. We're talking about very uncommon circumstances (usually I expect we'd be able to build the filter in the round-trip time between sending a header and receiving a getcfilters request) 10:45 < sipa> given that this functionality is opt-in, perhaps that's not too crazy? 10:45 < MarcoFalke> sipa: Yes, that's a different issue from the thread blocking. I'd say we should be nice to peers and disconnect them 10:46 < sipa> MarcoFalke: i agree 10:46 < jonatack> MarcoFalke: agree 10:46 < sipa> (independently of the thread blocking issue) 10:46 < MarcoFalke> (when the index itself is in "ibd" or syncing phase) 10:46 < MarcoFalke> which might happen when the node itself is already out of ibd 10:48 < jnewbery> sorry, to be clear about what you're all agreeing to: you think that if we've completed IBD but not yet finished building the index, we should disconnect and peers that request cfilters? 10:48 < MarcoFalke> jup, any blockfilter message that we can't service 10:48 < sipa> i think that whenever we would be not responding to a cfilters request, we should disconnect instead 10:50 < sipa> i also think it would be cleaner that whenever reasonable (post IBD?), we should wait for the index to sync and respond, instead of not responding/disconnecting 10:50 < jnewbery> I think that's reasonable, but would need to think about it 10:50 < MarcoFalke> if the peer asks for the filters from block [1000, 1500] and we can send them, sure. Though if we are out of ibd and at block 700k and they ask for the filter for block 700k -> disconnect 10:50 < jonatack> In general, when faced with a necessary reasonable tradeoff between user experience for full node users versus that of light clients, I'd favor the full node users. 10:50 < jnewbery> sipa: so add the BlockUntilSyncedToCurrentChain() back? 10:51 < MarcoFalke> jnewbery: That one can't be solved by a call to Sync() 10:52 < jnewbery> MarcoFalke: I understand. Trying to clarify sipa's "we should wait for the index to sync and respond" 10:52 < MarcoFalke> ah, missed that msg 10:52 < sipa> it feels to me that BIP157, as written, assumes synchronicity - so if we should either implement it that way, or change the BIP 10:52 < sipa> or not implement it 10:52 < sipa> but this is not a trivial change 10:53 < jnewbery> We only have 10 minutes left, but I did want to cover the second question 10:53 < jnewbery> What are the potential problems with a node signaling NODE_COMPACT_FILTERS before its compact block filters index is built? What are the potential issues if a node changes its service bits dynamically? 10:53 < sipa> and given that the protocol is an entirely opt-in extension, i think just adding syncs to make it act synchronously is not a big deal 10:53 < jnewbery> We've already talked quite a bit about some of the implications, but I was specifically interested in how the service bits are cached in various places 10:54 < jnewbery> like in other nodes' addrmans, and in the seed nodes 10:54 < sipa> they're overwritten on connection, so i don't think changing them on the fly is a big deal - as long as a reasonable degree of caching remains useful 10:54 < jnewbery> if the service bits change dynamically, is it possible that other nodes will be gossipping our old service bits for a long time? 10:55 < sipa> if you'd expect service bits to flip-flop constantly, there is a problem 10:56 < sipa> but i don't see much of a problem with changing them once a condition is fulfilled so that they won't change back 10:56 < MarcoFalke> It shouldn't matter much either way 10:56 < michaelfolkson> jnewbery: I don't know... It depends on how effective gossip floods the entire network? 10:56 < michaelfolkson> *effectively 10:57 < michaelfolkson> It is not flapping. It is old service bit -> new service bit right? 10:58 < michaelfolkson> It is one way. It doesn't return back to the old service bit ever 10:58 < jnewbery> Right. It's going from not present to present 10:58 < MarcoFalke> It latches to true (assuming no restart) 10:58 < sipa> i think (but i'm not sure) that the propagation of the gossip addr messages with the new flag is just as fast as the original announcement 10:59 < jnewbery> how does the new flag overwrite the old flag? 11:00 < sipa> the addr message with the new flag in is gossiped, which will overwrite the entry in addrman 11:00 < sipa> upon connection to the actual peer it's also overwritten 11:00 < MarcoFalke> sipa: But the light peer won't connect if the flag isn't set 11:00 < sipa> sure 11:01 < MarcoFalke> So it should be slightly slower 11:01 < jnewbery> I think I need to look more into how addrs are gossipped and how old data is refreshed 11:01 < sipa> i don't think there is a difference really 11:02 < sipa> if you initially gossip with flag "incorrectly" on, feature-needing peers will connect, and need to disconnect and retry a different peer 11:02 < MarcoFalke> sipa: Oh your point is that the propagation into addrmans does not slow down? 11:02 < MarcoFalke> I assumed "light clients will connect to you just as fast as if you were setting the flag a day in advance" 11:02 < sipa> yeah, my claim - but i'd need to look this up myself - is that the "updating" of the flag is not slower whether or not it has been broadcast already in the past 11:03 < jonatack> hmmmm 11:03 < sipa> so there is just the window during which peers think you're still on the old feature, but you're really already synced up to the new one, that matters 11:03 < jnewbery> ok, that's time! Thanks for input, everyone. 11:04 < sipa> thanks! 11:04 < michaelfolkson> Thanks jnewbery 11:04 * jnewbery goes to dig into addr gossip 11:04 < MarcoFalke> jnewbery: Thanks for hosting. And thanks for picking up this pull request. I don't think it would have made it this far by now if you hadn't put in the effort! 11:04 < jonatack> this ^ 11:05 < jkczyz> yeah, thanks jnewbery 11:05 < jonatack> thanks! very interesting 11:06 < jnewbery> MarcoFalke: thanks, and thanks for all your review :) 11:14 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:25 -!- seven_ [~seven@2a00:ee2:410c:1300:3162:6f2d:1df9:de8b] has joined #bitcoin-core-pr-reviews 11:31 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 11:35 -!- seven_ [~seven@2a00:ee2:410c:1300:3162:6f2d:1df9:de8b] has quit [Remote host closed the connection] 11:35 -!- seven_ [~seven@2a00:ee2:410c:1300:3162:6f2d:1df9:de8b] has joined #bitcoin-core-pr-reviews 11:51 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 12:10 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:17 -!- dfmbbtc [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 12:21 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Ping timeout: 260 seconds] 12:55 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 12:58 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 14:29 -!- dfmbbtc [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving] 15:02 -!- pinheadmz [~pinheadmz@96.47.229.196] has quit [Ping timeout: 256 seconds] 15:07 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 15:35 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-fwjjixdouqwfdrwz] has quit [Ping timeout: 260 seconds] 15:35 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-sinxepuyiurwjgdt] has quit [Ping timeout: 272 seconds] 15:35 -!- fjahr [sid374480@gateway/web/irccloud.com/x-ixfgxajkuakwodov] has quit [Ping timeout: 272 seconds] 15:35 -!- ethzero [sid396973@gateway/web/irccloud.com/x-saiosnxehgknnjrs] has quit [Ping timeout: 272 seconds] 15:35 -!- Aleru [sid403553@gateway/web/irccloud.com/x-osvqqxazaeheaotb] has quit [Ping timeout: 272 seconds] 15:36 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-wnrvylavwplwbmfq] has quit [Ping timeout: 260 seconds] 15:36 -!- digi_james [sid281632@gateway/web/irccloud.com/x-emzhhmbvslajbhfe] has quit [Ping timeout: 256 seconds] 15:36 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-dpnxedpcfnbrmdyd] has quit [Ping timeout: 256 seconds] 15:36 -!- fanquake [sid369002@gateway/web/irccloud.com/x-xwnmppxqhszbxoka] has quit [Ping timeout: 272 seconds] 15:36 -!- illlicit_ [uid109953@gateway/web/irccloud.com/x-kkzirplxskyqfltc] has quit [Ping timeout: 244 seconds] 15:36 -!- jamesob [sid180710@gateway/web/irccloud.com/x-ylcugpkygwylqefk] has quit [Ping timeout: 260 seconds] 15:36 -!- peltre [sid268329@gateway/web/irccloud.com/x-sgwkucoffsvdwkir] has quit [Ping timeout: 260 seconds] 15:37 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-kwpbiqhkwszaggdi] has quit [Ping timeout: 272 seconds] 15:37 -!- corollari [sid405633@gateway/web/irccloud.com/x-tvpoybnnltixhwyl] has quit [Ping timeout: 272 seconds] 15:37 -!- amiti [sid373138@gateway/web/irccloud.com/x-yvxynzqfiqknghgo] has quit [Ping timeout: 272 seconds] 15:37 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-wjxmksunuwrmguxl] has quit [Ping timeout: 260 seconds] 15:37 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-pzwftebipqviqiqo] has quit [Ping timeout: 260 seconds] 15:37 -!- moneyball [sid299869@gateway/web/irccloud.com/x-idfrgkxmsbhwxvay] has quit [Ping timeout: 256 seconds] 15:37 -!- hugohn [sid304114@gateway/web/irccloud.com/x-ujjrkpqnostiyppi] has quit [Ping timeout: 256 seconds] 15:37 -!- corollari [sid405633@gateway/web/irccloud.com/x-lurrerehxoczbibj] has joined #bitcoin-core-pr-reviews 15:37 -!- ajonas [sid385278@gateway/web/irccloud.com/x-ihkheqqexzsjdybe] has quit [Ping timeout: 272 seconds] 15:37 -!- schmidty [sid297174@gateway/web/irccloud.com/x-sxrueubhxjmfakcd] has quit [Ping timeout: 272 seconds] 15:37 -!- illlicit_ [uid109953@gateway/web/irccloud.com/x-trorwzkbxbpaczlp] has joined #bitcoin-core-pr-reviews 15:37 -!- moneyball [sid299869@gateway/web/irccloud.com/x-flptnlazuymwjekt] has joined #bitcoin-core-pr-reviews 15:38 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 15:38 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 15:38 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 15:38 -!- peltre [sid268329@gateway/web/irccloud.com/x-ovktzdniqlmsirdm] has joined #bitcoin-core-pr-reviews 15:38 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-ncldrsilsbytwleo] has joined #bitcoin-core-pr-reviews 15:38 -!- fanquake [sid369002@gateway/web/irccloud.com/x-fhmfssifughellja] has joined #bitcoin-core-pr-reviews 15:39 -!- digi_james [sid281632@gateway/web/irccloud.com/x-ixyargxtdibxiafd] has joined #bitcoin-core-pr-reviews 15:39 -!- ethzero [sid396973@gateway/web/irccloud.com/x-vitlyldkeacshzvi] has joined #bitcoin-core-pr-reviews 15:39 -!- amiti [sid373138@gateway/web/irccloud.com/x-ihxzbbxnsodekzrj] has joined #bitcoin-core-pr-reviews 15:39 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-npmrlfgjizlykrrf] has joined #bitcoin-core-pr-reviews 15:39 -!- petezz4 [sid2429@gateway/web/irccloud.com/x-etjpbbitvueppclq] has joined #bitcoin-core-pr-reviews 15:40 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-ozlyifiugrtfpnrc] has joined #bitcoin-core-pr-reviews 15:41 -!- pierre_rochard [sid299882@gateway/web/irccloud.com/x-spwrfouxaaawdzaz] has joined #bitcoin-core-pr-reviews 15:41 -!- Aleru [sid403553@gateway/web/irccloud.com/x-mdhadtakanjjzcvz] has joined #bitcoin-core-pr-reviews 15:41 -!- jkczyz [sid419941@gateway/web/irccloud.com/x-cmdidozedoxkrfli] has joined #bitcoin-core-pr-reviews 15:42 -!- jamesob [sid180710@gateway/web/irccloud.com/x-jggcdmnrhnqruafg] has joined #bitcoin-core-pr-reviews 15:42 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vvqiawmttlehinlw] has joined #bitcoin-core-pr-reviews 15:42 -!- schmidty [sid297174@gateway/web/irccloud.com/x-nngxwkzqbkdnzwpw] has joined #bitcoin-core-pr-reviews 15:43 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-hmwkqeliriuhvrvz] has joined #bitcoin-core-pr-reviews 15:43 -!- fjahr [sid374480@gateway/web/irccloud.com/x-nnnlcpasqlezucfe] has joined #bitcoin-core-pr-reviews 15:46 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 15:54 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 16:01 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 16:02 -!- hugohn [sid304114@gateway/web/irccloud.com/x-zuvdkgvfwlxxvniv] has joined #bitcoin-core-pr-reviews 16:42 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 16:42 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 16:43 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 16:50 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 16:52 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 16:59 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz] 17:03 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews 17:23 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 17:26 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 17:38 -!- slivera [~slivera@103.231.88.28] has joined #bitcoin-core-pr-reviews 18:25 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 18:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 19:21 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 19:22 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 21:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 21:23 -!- vasild_ is now known as vasild 21:43 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer] 21:43 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 23:24 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 23:25 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 23:29 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 23:36 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 256 seconds]