--- Day changed Wed Jul 31 2019
00:18 -!- petezz4 [uid2429@gateway/web/irccloud.com/x-yteiglaopptrqjxf] has joined #bitcoin-core-pr-reviews     
00:25 -!- petezz4 [uid2429@gateway/web/irccloud.com/x-yteiglaopptrqjxf] has quit [Quit: Updating details, brb]     
00:25 -!- petezz4 [uid2429@gateway/web/irccloud.com/x-khtvbfwezanbrpzm] has joined #bitcoin-core-pr-reviews     
00:37 -!- octomatic [~octomatic@c-73-189-22-4.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]     
01:10 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds]     
01:24 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews     
01:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
01:58 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews     
03:37 -!- jonatack [d598a155@213.152.161.85] has quit [Remote host closed the connection]     
04:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
04:19 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
04:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
04:23 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
05:00 -!- jonatack [d598a155@213.152.161.85] has joined #bitcoin-core-pr-reviews     
05:56 -!- davterra [~none@209.58.190.248] has quit [Quit: Leaving]     
06:11 -!- octomatic [~octomatic@c-73-189-22-4.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
06:40 -!- davterra [~none@64.120.89.22] has joined #bitcoin-core-pr-reviews     
07:01 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-isjyuaalbhbfdvbq] has joined #bitcoin-core-pr-reviews     
07:32 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
08:12 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
09:17 -!- lightlike [~lightlike@2001:16b8:57bf:800:a5cf:5b01:180a:96c] has joined #bitcoin-core-pr-reviews     
09:19 -!- zeptin [a9010dd8@reoelladol.net.afrihost.co.za] has joined #bitcoin-core-pr-reviews     
09:34 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Ping timeout: 272 seconds]     
09:44 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-pr-reviews     
09:44 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-pr-reviews     
09:45 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews     
09:48 -!- phuvp [41d13c92@65.209.60.146] has joined #bitcoin-core-pr-reviews     
09:53 -!- michaelfolkson [~textual@82-132-221-138.dab.02.net] has joined #bitcoin-core-pr-reviews     
10:00 < jnewbery_> hi     
10:00 < lightlike> hello
10:00 < jkczyz> hi     
10:00 < michaelfolkson> Hey     
10:01 < davterra> hi     
10:01 < jnewbery_> lightlike is going to host today. He also prepared the notes and questions at https://bitcoin-core-review-club.github.io/15505.html . Thanks lightlike!
10:01 < fjahr> hi     
10:01 -!- i2 [~i2@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
10:01 < hugohn> hello
10:01 < i2> hallo
10:01 < jonatack> hi++
10:01 < jnewbery_> before I hand over, my periodic reminder that the point of PR review club is to help you review PRs! Please do review the PRs on github (an if you have any questions about how to do that, feel free to ask them here)
10:02 < jnewbery_> ok, let's get started. Over to you, lightlike
10:02 < michaelfolkson> Thanks for the reminder John :)
10:02 < lightlike> Thanks! I found this PR interesting because it deals with some of the very basic P2P functionality (ThreadMessageHandler)
10:02 < lightlike> to optimize how we deal with NOTFOND message.
10:03 < ariard> hi     
10:03 < lightlike> Even though it got closed by the author recently
10:03 -!- fjsldakfjalskjdf [68840050@104.132.0.80] has joined #bitcoin-core-pr-reviews     
10:03 < lightlike> I think it is good for learning about  P2P aspects of bitcoin - definitely helped my understand some new things.
10:04 < lightlike> First question (some overlap with the old session on #15834):
10:04 < lightlike> What is the most typical situation when running a node in which NOTFOUND messages are encountered?
10:04 < jkczyz> When the peer no longer has the transaction in the relay set
10:04 < michaelfolkson> Unpruned node requesting historic transaction?
10:05 < michaelfolkson> *Pruned
10:06 < lightlike> In my experience of running a node with logging, it is dealing with orphan transactions:
10:06 < jnewbery_> michaelfolkson: pruning is only relevant for old blocks in the chain. This PR deals with tx relay
10:06 < jnewbery_> (unconfirmed txs)
10:07 < lightlike> when we receive an tx from a peer for which we dont have the parent, we will ask him for the parent too
10:07 < lightlike> sending GETDATA without him having sent an INV before.
10:07 < lightlike> *received
10:08 < michaelfolkson> But a pruned node might request a tx it no longer has?
10:08 < lightlike> in this case, the other node often doesn't have the parent tx (or won't send it to us) and answers with NOTFOUND.
10:09 < jnewbery_> michaelfolkson: pruning is only for the blockchain. tx relay is for unconfirmed txs not in the blockchain yet
10:09 < michaelfolkson> Ok thanks
10:09 < hugohn> how likely is it to receive a txn for which we don't know the parent? is that related to CPFP or no?
10:10 < i2> answer to typical situation for NOTFOUND: maybe: a.) blocks-only Lite client? b.) full-node that's in process of syncing to tip, c.) adversarial peer? d.) full node drops tx if tx is included in block but a reorg happens to your peer?
10:10 < lightlike> when firing up a node, it happens a lot (we weren't there when the parent was relayed)
10:13 < lightlike> i2: i dont think an adversarial peer would send a NOTFOUND currently. He could just INV a tx and never follow up with the TX if we request it.
10:13 < jnewbery_> i2: a) blocks-only clients will advertise that they're not relaying txs with the relay flag in the VERSION message: https://btcinformation.org/en/developer-reference#version
10:14 < jnewbery_> i2: d) in the case of a reorg, the disconnected txs are added back into the mempool
10:14 < hugohn> lightlike: I see, so when a node comes back online after a while, the INVs typically arrive out-of-order? i.e., receiving INVs for children first before receiving INVs for parent
10:14 < lightlike> im not entirely sure if this is typical, but in a short test-run on mainnet all of the NOTFOUNDs i got were for parents of orphan transactions.
10:15 < jnewbery_> lightlike: I think that's fairly typical, but I haven't actually tested it myself
10:15 < i2> jnewbery_ re d) so the steps are 1.) new block 2.) shed txns in block from mempool 3) reorg 4) put txn from reorg'ed blocks back into mempool?
10:16 < lightlike> ok, maybe move on to the next q:
10:16 < lightlike> Why was the solution with the sequence counter chosen, instead of simpler alternatives like a random draw?
10:16 < jonatack> lightlike: my testing of the NOTFOUND PR showed the same as you
10:16 < i2> lightlike: maybe a.) Decrease p2p churn?  b.) Equalize load requested from peers (no peer wins the INV-request lottery)
10:17 < jkczyz> Is it to ensure a uniform distribution of peer selection? I left a comment on the review regarding the sequence number but wasn't sure if this was the reason.
10:17 < hugohn> I guess for robustness: we want to retry fetching the txn from all eligible outbound peers, not just one
10:17 < jnewbery_> i2: not quite. It's 1) get new block and see that it's got more work than tip 2) run ActivateBestChain, which tries to move to the best chain, which will 2a) rewind blocks, adding txs to mempool 2b) connect new blocks, removing txs from mempool that in the new block
10:19 < lightlike> yes, i think that's correct, it's to not ask more transansaction from peers earlier in the loop.
10:20 < michaelfolkson> How many peers is a node on average connected to? I'm assuming most would run the default config settings
10:20 < jnewbery_> hugohn: no, we only want to request from one peer at a time. That tripped me up too. The logic to make sure we're not requesting from more than one peer is in TryRequestTx(): https://github.com/bitcoin/bitcoin/pull/15505/files#diff-eff7adeaec73a769788bb78858815c91R773
10:21 < lightlike> i think it is important here that there is an "early" and "late" in the loop, even though ThreadMessageHandler loops continuously through all our peer.
10:21 < jnewbery_> michaelfolkson: up to 8 outbound and (for listening nodes) up to 125 total (so 117 inbound)
10:21 < hugohn> jnewbery_: yes I saw that, the retrying is actually one peer at a time. but the queuing up for retries happen for all outbound peers, right? to ensure that if one outbound peer fails to give us the txn, the next one still could
10:22 < lightlike> because the order of our peers is not random (usually there are first our outbound peers to which we connect at startup, and after that the inbound peers)
10:22 < jnewbery_> hugohn: right, the txid will be added to m_tx_not_found for all outbound peers that have announced the tx
10:22 < jonatack> perhaps a random draw would not ensure the taking of turns e.g. the same peer could be picked twice in a row
10:23 < michaelfolkson> Yeah especially if only 8 outbound
10:23 -!- davterra [~none@64.120.89.22] has quit [Remote host closed the connection]     
10:24 < lightlike> jonatack: i think with the random draw, the node in our current position in the loop would get more action: it has now an 1/N chance, and in case there is an entire cycle without anohter node getting the INV, it gets a second chance first
10:24 -!- davterra [~none@64.120.89.22] has joined #bitcoin-core-pr-reviews     
10:24 < i2> jonatack "peer could be picked twice in a row" = INV 'lottery' winner ;]
10:24 < hugohn> jonatack: yeah I think so, so if we randomly choose only one outbound peer to retry, it's less robust if that peer _also_ fails to SENDDATA . but the advantage of random draw is no extra sequence_number, which is somewhat awkward to introduce in the main processing loop...
10:24 < jonatack> lightlike: right, in that case random would have more bias
10:24 < jnewbery_> one thing we could do is shuffle the order we visit peers in the ThreadMessageHandler here: https://github.com/bitcoin/bitcoin/blob/7821821a23b68cc9ec49d69829ad4c939cb762e8/src/net.cpp#L1939
10:25 < lightlike> jnewbery_: yes, I thought about that too, that could be randomized
10:26 < jkczyz> jnewbery_: how important is maintaining determinism for sake of testing?
10:26 < lightlike> i actually like the proposal of jkczyz  https://github.com/bitcoin/bitcoin/pull/15505#issuecomment-516636613 - on first thought I think that might work
10:26 < jnewbery_> jkczyz: I don't think it's important. My guess is that no tests will break.
10:26 < hugohn> but one consequence of queuing up the txns in all outbound peers is there could potentially be duplicate entries in each m_tx_not_found queue? I don't see any logic checking against with duplicates
10:27 < hugohn> do you guys think it's necessary? to check against duplicates in m_tx_not_found?
10:28 < jnewbery_> hugohn: I think you may be right about duplicates in m_tx_not_found
10:29 -!- davterra [~none@64.120.89.22] has quit [Ping timeout: 248 seconds]     
10:30 -!- davterra [~none@64.120.89.22] has joined #bitcoin-core-pr-reviews     
10:30 < lightlike> ok, next question: Why are only outbound peers considered for requesting transactions after receiving NOTFOUND?
10:31 < lightlike> hugohn: I think so too, not sure thought how bad duplicates would be.
10:32 < i2> clarify my ignorance: outbound peers = non-listen-only peers. yes?
10:32 < hugohn> jnewbery_ lightlike: yeah so looks like we indiscriminately queue up the txn any time we get a NOTFOUND. there's no guarantee we can't get multiple NOTFOUNDs for the same txns.
10:32 < hugohn> or back-to-back
10:32 < hugohn> retry failure
10:32 < lightlike> i2: no, outbound peers are when we initiate the connection, vs inbound peers that connect to us
10:32 < michaelfolkson> https://bitcoin.stackexchange.com/questions/42286/what-is-the-difference-between-inbound-and-outbound-connections
10:33 < michaelfolkson> I made same mistake
10:34 < michaelfolkson> Because you would rather cycle through nodes you have personally selected rather than random nodes that you haven't selected?
10:35 < lightlike> michaelfolkson: yes, that's true, but why not just treat everyone the same?
10:35 < hugohn> we generally trust the outbound peers more than inbound ones, to guard against Sybil attacks?
10:36 < michaelfolkson> Because nodes aren't the same. Some will go offline and won't make timely responses?
10:36 < lightlike> hugohn: yes. I think if we also requested from inbounds, attackers could try to withhold a tx from us by establishing many connections to us
10:37 < lightlike> the normal logic if a GETDATA times out also treats outbounds nodes preferentially
10:37 < jonatack> yes, idea is attackers could use inbound conns to prevent us from seeing a txn
10:38 < jonatack> thus the delay placed on inbounds giving preferance to outbounds
10:38 < lightlike> so an attacker could circumvent that by sending us NOTFOUND right before the GETDATA times out, and then we would be likely to ask the tx from another inbound node, that is also controlled by the attacker.
10:38 < jonatack> nNow + 2 sec
10:39 < lightlike> and so on
10:40 < i2> so rational for txn requests to outbound peers before inbound is to prevent an eclipse attack on a node for txn awareness (say lighnting force close)?
10:40 -!- michaelfolkson [~textual@82-132-221-138.dab.02.net] has quit [Quit: Sleep mode]     
10:41 < lightlike> i2: yes, I think so. it's much harder for an attacker to control our outbound peers that we chose carefully.
10:41 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 246 seconds]     
10:42 < hugohn> the time delay attack was the motivation for the fix https://github.com/bitcoin/bitcoin/pull/14897 wasn't it? which introduced a few bugs & motivated more robustness handling of NOTFOUND
10:43 < jonatack> hugohn: yes, iirc
10:43 < hugohn> retry logic is hard :-)
10:44 < hugohn> so many edge cases
10:44 < lightlike> ok, final question:
10:44 < lightlike> What kind of options exist in the functional testing framework for P2P functionality? Why is it so hard to test PRs like this one with the existing framework?
10:45 < jonatack> Good read on this at https://github.com/bitcoin/bitcoin/issues/14210
10:46 < jonatack> (current limitations and goal of an instantiable CConnman, then a MockNetworkRouter)
10:46 -!- octomatic [~octomatic@c-73-189-22-4.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]     
10:48 < lightlike> jonatack: yes, seems like it is not possible at the moment to fully mock inbound/outbound behavior in functional tests.
10:48 < ariard> We currently dissociate the node added from cli and from addrman
10:49 < jonatack> and the testing can do manual conns but not spontanous ones
10:49 < jnewbery_> IIRC there's also special logic for peers on the same subnet or IP address, which all our test nodes are for functional tests
10:50 < jnewbery_> yeah, I think it's the IsLocal() test
10:50 < hugohn> is the bucketing mechanism (putting nodes in new vs. tried tables) one of the main challenges? do you have to stub out the bucketing logic somehow, or create fake IP addresses?
10:51 < jnewbery_> there are a few things that would need to change. I think they're all documented in 14210
10:51 < ariard> I think we should create fake IP addresses for our nodes thanks to namespaces
10:52 < jnewbery_> ariard: I don't know anything about that, but it sounds like a good idea!
10:52 < jonatack> Ethan Deilman proposed that here https://github.com/bitcoin/bitcoin/issues/14210#issuecomment-469318300
10:53 < jonatack> * Heilman
10:53 < ariard> jnewbery: how IIRC that's why we conclude with dongcarl in 14210
10:54 < jonatack> ariard: right, namespaces as you proposed https://github.com/bitcoin/bitcoin/issues/14210#issuecomment-473361633
10:55 < ariard> not sure about all this stuff, it need more thought but first cconman encapsulation!
10:55 < ariard> *needs
10:55 < lightlike> do you know if the work towards an instantiable CConnman is still in an early stage, or close to being finished?
10:55 < jonatack> before we run out of time... is anyone working on this atm?
10:55 < hugohn> all roads point to more modular components :-)
10:55 < ariard> I do what I can https://github.com/bitcoin/bitcoin/pull/16503 ;)
10:56 < ariard> jonatack: dongcarl, theuni, ryanofksy
10:56 < hugohn> ariard: yes moar pls ! :D
10:56 < ariard> but it split between different parts of the codebase
10:57 < jonatack> ariard: currently?
10:57 < ariard> we'll try to remove more cconnman usages in RPC interface, don't remember what need to be done in net.cpp
10:57 < ariard> *will
10:57 < hugohn> also a basic q before we run out: does anyone know why g_outbound_peers_with_protect_from_disconnect is defined within net_processing.cpp’s namespace, but g_outbound_peers is defined outside of it?
10:58 < ariard> jonatack: dunno rn, ask on core dev
10:58 < lightlike> there is #14856, where there was not so much action recently
10:58 < lightlike> https://github.com/bitcoin/bitcoin/pull/14856
10:59 < ariard> lightlike: ping carl on it, he may need help
10:59 < jnewbery_> hugohn: no idea!
10:59 < hugohn> ha     
10:59 < jonatack> thanks, interesting. we need to be reviewing these PRs to encourage people
10:59 < jnewbery_> Shall we wrap up there?
11:00 < lightlike> yes, thanks everybody!
11:00 < i2> thanks lightlike!
11:00 < jnewbery_> that was great. Thanks so much for hosting and preparing notes lightlike!
11:00 < jonatack> great jon, lightlike :100: would attend again
11:00 < hugohn> thanks lightlike! learned a lot!
11:00 < ariard> thanks lightlike!
11:00 < jkczyz> yeah, thank you!
11:01 < jonatack> * job :-)
11:01 < jnewbery_> Before we go: next week PR review is looking at *two* competing PRs! https://bitcoin-core-review-club.github.io/16345.html
11:01 < jnewbery_> notes are already up
11:02 < jonatack> nice
11:04 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]     
11:23 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-pr-reviews     
11:24 -!- booyah [~bb@193.25.1.157] has quit [Read error: Connection reset by peer]     
11:26 -!- booyah [~bb@193.25.1.157] has joined #bitcoin-core-pr-reviews     
11:31 -!- zeptin [a9010dd8@reoelladol.net.afrihost.co.za] has quit [Remote host closed the connection]     
11:44 -!- fjsldakfjalskjdf [68840050@104.132.0.80] has quit [Remote host closed the connection]     
11:46 -!- i2 [~i2@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 244 seconds]     
11:55 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: harrigan]     
12:20 -!- davterra [~none@64.120.89.22] has quit [Ping timeout: 246 seconds]     
12:22 -!- jonatack [d598a155@213.152.161.85] has quit [Remote host closed the connection]     
12:34 < jnewbery_> meeting log: https://bitcoin-core-review-club.github.io/15505.html
12:39 -!- davterra [~none@c-73-221-225-225.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
12:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
12:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
12:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
12:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
12:58 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
13:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
13:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
13:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
13:16 -!- phuvp [41d13c92@65.209.60.146] has quit [Remote host closed the connection]     
13:17 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
13:18 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
13:21 -!- octomatic [~octomatic@24.5.180.154] has joined #bitcoin-core-pr-reviews     
13:21 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
13:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
13:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
13:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
13:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 244 seconds]     
13:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
13:56 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]     
15:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
15:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
15:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 268 seconds]     
15:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
15:44 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews     
15:56 -!- jnewbery_ [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Ping timeout: 268 seconds]     
15:56 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]     
15:58 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews     
15:58 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews     
16:15 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Ping timeout: 258 seconds]     
16:19 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-pr-reviews     
16:58 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:e8e3:af4f:841e:206a] has joined #bitcoin-core-pr-reviews     
17:08 -!- davterra [~none@c-73-221-225-225.hsd1.wa.comcast.net] has quit [Quit: Leaving]     
17:20 -!- lightlike [~lightlike@2001:16b8:57bf:800:a5cf:5b01:180a:96c] has quit [Quit: Leaving]     
17:37 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:e8e3:af4f:841e:206a] has quit [Quit: Sleep mode]     
17:51 -!- octomatic [~octomatic@24.5.180.154] has quit [Ping timeout: 245 seconds]     
18:00 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 248 seconds]     
18:55 -!- davterra [~none@c-73-221-225-225.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
18:56 -!- davterra [~none@c-73-221-225-225.hsd1.wa.comcast.net] has quit [Remote host closed the connection]     
19:00 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-isjyuaalbhbfdvbq] has quit [Quit: Connection closed for inactivity]     
20:18 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews     
20:18 -!- octomatic [~octomatic@c-73-189-22-4.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
21:07 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]     
21:08 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dmyodtygbfxbndfz] has joined #bitcoin-core-pr-reviews     
21:41 -!- octomatic [~octomatic@c-73-189-22-4.hsd1.ca.comcast.net] has quit [Ping timeout: 268 seconds]     
21:47 -!- octomatic [~octomatic@c-73-189-22-4.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
22:52 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Ping timeout: 246 seconds]     
23:20 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dmyodtygbfxbndfz] has quit [Quit: Connection closed for inactivity]