--- Day changed Wed Oct 30 2019 01:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds] 01:22 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 250 seconds] 01:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 02:08 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews 02:23 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds] 02:24 -!- jonatack [~jon@213.152.161.219] has joined #bitcoin-core-pr-reviews 02:30 -!- jonatack_ [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews 02:30 -!- jonatack [~jon@213.152.161.219] has quit [Ping timeout: 276 seconds] 02:33 -!- jonatack_ [~jon@54.76.13.109.rev.sfr.net] has quit [Client Quit] 02:34 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews 02:36 -!- ironbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has quit [Quit: Leaving] 02:38 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 252 seconds] 03:27 -!- devops99 [~textual@vpn.ki-performance.com] has joined #bitcoin-core-pr-reviews 03:42 -!- awesome-doge [lplplpmatr@gateway/shell/matrix.org/x-fhnpiotpucahmwmd] has quit [Read error: Connection reset by peer] 03:44 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Ping timeout: 240 seconds] 03:46 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-pr-reviews 04:06 -!- awesome-doge [lplplpmatr@gateway/shell/matrix.org/x-jjdwklahpetblzye] has joined #bitcoin-core-pr-reviews 04:14 -!- devops99 [~textual@vpn.ki-performance.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 04:44 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews 04:53 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 05:10 -!- devops99 [~textual@vpn.ki-performance.com] has joined #bitcoin-core-pr-reviews 05:27 -!- devops99 [~textual@vpn.ki-performance.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:28 -!- devops99 [~textual@vpn.ki-performance.com] has joined #bitcoin-core-pr-reviews 05:30 -!- sosthene [~sosthene@88.191.20.124] has quit [Ping timeout: 244 seconds] 05:34 -!- devops99 [~textual@vpn.ki-performance.com] has quit [Quit: Textual IRC Client: www.textualapp.com] 06:17 -!- emilengler_ [~emilengle@unaffiliated/emilengler] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in] 06:19 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 07:05 <@jnewbery> Hi folks. If you're joining us from europe note that the time of the meeting may have changed for you due to daylight savings. We start at 17:00 UTC (3 hours from now) 07:46 -!- lightlike [~lightlike@2001:16b8:5728:f700:60f7:e4ab:9b1b:7bbf] has joined #bitcoin-core-pr-reviews 07:49 <@jnewbery> remember: reviewing doesn't stop when a PR gets merged :D 07:50 -!- diogosergio [~diogoserg@212.36.34.126] has joined #bitcoin-core-pr-reviews 07:57 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 268 seconds] 07:59 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 08:01 <@jnewbery> wow tercets in this week's merge rhyme. Very nice! 08:13 <@jnewbery> oops wrong window for that one 08:14 < pinheadmz> yeah.. what? lol. whats a merge rhyme ?! 08:15 <@jnewbery> bitschmidty treats us to a merge rhyme for every optech newsletter: https://github.com/bitcoinops/bitcoinops.github.io/pull/248 08:15 < pinheadmz> omg :-) 08:16 < pinheadmz> also thats cool i didnt realize the newsletter when through review on GH 08:27 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Ping timeout: 252 seconds] 08:30 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 08:34 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Ping timeout: 268 seconds] 08:34 -!- diogoser1io [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 08:41 -!- davterra [~none@195.242.213.120] has quit [Ping timeout: 246 seconds] 08:43 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews 09:43 -!- mango [cdd118e3@205.209.24.227] has joined #bitcoin-core-pr-reviews 09:46 -!- mango [cdd118e3@205.209.24.227] has quit [Remote host closed the connection] 09:47 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 09:47 -!- Moller40 [~mr@82.103.128.151] has joined #bitcoin-core-pr-reviews 09:55 -!- ajonas [uid385278@gateway/web/irccloud.com/x-xnlguzztavtmbbma] has joined #bitcoin-core-pr-reviews 09:58 <@jnewbery> we'll get started in a couple of minutes 09:58 <@jnewbery> notes and questions: https://bitcoincore.reviews/15921.html 09:59 -!- mango [cdd118e3@205.209.24.227] has joined #bitcoin-core-pr-reviews 10:00 <@jnewbery> hi! 10:00 < kanzure> hi 10:00 < diogoser1io> hello! 10:00 < amiti> hi 10:00 < fjahr> hi 10:00 < lightlike> hi 10:01 <@jnewbery> Today's PR is 15921. Notes and questions are in the usual place: https://bitcoincore.reviews/15921.html 10:01 <@jnewbery> Thanks to everyone who reviewed/tested/left comments! 10:01 -!- diogoser1io is now known as diogosergio 10:01 <@jnewbery> the PR was merged today, but that doesn't mean you shouldn't review it 10:01 < schmidty> hola 10:02 <@jnewbery> In my mind, there are (at least) three reasons to review PRs: 10:02 <@jnewbery> 1. Make suggestions to the PR author on how to improve the PR 10:02 <@jnewbery> 2. Leave your ACK if you think the code should be merged or your NACK if you think it shouldn't be 10:02 <@jnewbery> 3. Learn about the code 10:03 <@jnewbery> All three are still valuable after the PR has been merged 10:03 <@jnewbery> (1) can lead to follow-up PRs that can improve the code further, for (2) you might still find a bug that other reviewers have missed, and we should all be doing (3) all the time! 10:04 <@jnewbery> ok, any initial thoughts about the PR? 10:04 -!- Moller40_ [~mr@82.103.130.25] has joined #bitcoin-core-pr-reviews 10:04 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:e5f7:5b8e:caec:35a0] has joined #bitcoin-core-pr-reviews 10:04 <@jnewbery> (as always, question 1 is Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK? (Don’t forget to put your PR review on GitHub.) 10:05 < amiti> I thought it was interesting to review. Since it touched all the sites that care about block / txn validation, it exposed me to new parts of the codebase 10:06 < fjahr> Yeah, I acked since it makes a lot of sense to me to separate Tx and Block validation 10:06 -!- Moller40 [~mr@82.103.128.151] has quit [Ping timeout: 268 seconds] 10:06 <@jnewbery> amiti: good! The PR title says this is a tidy-up, but I thought it might be interesting because it touches the net_processing-validation interface, which I think are the two most interesting components in Bitcoin Core 10:07 <@jnewbery> fjahr: good 10:07 <@jnewbery> ok, for those that reviewed: what steps did you take to review/test? 10:08 < ajonas> Going through each commit was a must on this one. And ryanofsky's suggestion was very helpful on the first commit. 10:09 < amiti> I mostly just read the code one commit at a time & tried to understand the changes, and poke around the larger codebase to get context for them 10:10 < lightlike> just looked at each line of code that was changed and tried to understand it (saw the hint by ryanofski too late) 10:10 <@jnewbery> yeah, ryanofsky's reviewer tip was very helpful 10:10 < michaelfolkson> Agreed I'd like more of those reviewer tips 10:10 <@jnewbery> lightlike: perhaps I should have added the tip to the commit log? 10:11 <@jnewbery> next question: Does this PR change any behaviour, or is it a pure refactor? 10:11 < lightlike> jnewbery: no, it was clear enough in the first post of the PR, just my fault... 10:13 < michaelfolkson> #15141 changed behavior but this one (#15921) didn't right? 10:13 < fjahr> I did not see any behaviour change. It was consensus code after all :) 10:13 <@jnewbery> Did anyone here review the previous PR (15141)? If not, did any of you go back and look at it? 10:14 < lightlike> it does change an error message of sendtransaction rpc call in case of missing inputs, other than that I didn't see anything. 10:14 <@jnewbery> lightlike: good catch! 10:14 < michaelfolkson> I looked at #15141. I didn't "review" as already merged 10:14 < amiti> I def took a look at 15141 in the context of this PR, but didnt dig very deep 10:14 <@jnewbery> yes, some minor logging/error message change 10:15 <@jnewbery> michaelfolkson: yes, 15141 has some minor behaviour changes in the way we ban/disconnect peers 10:17 < michaelfolkson> That punishment logic was interesting 10:17 < michaelfolkson> But leave that to later, let's stay on #15921 for now ;) 10:18 <@jnewbery> michaelfolkson: yeah, the disconnect logic is very interesting 10:18 <@jnewbery> which leads us into the next question: Why do you think we have different validation results for RECENT_CONSENSUS_CHANGE and CONSENSUS? 10:19 < michaelfolkson> I initially thought it was SegWit related but it actually wasn't 10:19 <@jnewbery> well segwit was the last consensus change 10:19 < michaelfolkson> For a future soft fork/consensus change right? 10:19 < fjahr> I found that RECENT_CONSENSUS_CHANGE relates to everything after segwit 10:19 < fjahr> so it has not been used yet 10:20 < amiti> I didn't understand why thats already been introduced if its not used yet 10:20 < fjahr> but it would be used to prevent a potential network split 10:20 < amiti> fjahr: how so? 10:21 < lightlike> amiti: i had the same question, if it is never used I don't understand how introducing it now can help us in the future. 10:21 <@jnewbery> What do we do to peers that send us txs/blocks that are invalid because of CONSENSUS? What do we do if they're invalid for RECENT_CONSENSUS_CHANGE? 10:22 <@jnewbery> amiti: lightlike: right, it's not currently used, but I think the reasoning behind having it as a validation reason is interesting 10:22 < fjahr> I guess a new change would be flagged with this and then this would be used for a conditional to manage behaviour differently. So we don't ban peers who have not upgraded to segwit yet. 10:22 <@jnewbery> There's a clue here: https://github.com/bitcoin/bitcoin/blob/a6abc94e9307ea05972ef69732bb148acbfa870a/src/validation.cpp#L1544-L1548 10:23 <@jnewbery> fjahr: yes, that's right (if you replace the word 'segwit' with 'current consensus rules') 10:24 <@jnewbery> Does that make sense to everyone? 10:24 <@jnewbery> does anyone have the answer to this: 10:24 <@jnewbery> > What do we do to peers that send us txs/blocks that are invalid because of CONSENSUS? What do we do if they're invalid for RECENT_CONSENSUS_CHANGE? 10:25 < amiti> https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L1004 10:25 < fjahr> ah, got it, so segwit is just the point after which this was introduced but there was nothing about segwit that made this necessary in particular. 10:25 <@jnewbery> amiti: you've found the right line. What's it doing? 10:25 < amiti> RECENT_CONSENSUS_CHANGE we just break, but CONSENSUS we invoke misbehaving 10:25 < fjahr> 1. ban 2. nothing 10:26 <@jnewbery> and what does that mean we do the peer? 10:26 <@jnewbery> fjahr: more or less. I think we just disconnect not ban for (1) 10:26 < amiti> do we necessarily ban? or do we just increase the score? 10:27 < amiti> oh, the threshold is 100 10:27 < amiti> and we increase score by 100 10:27 <@jnewbery> no, you're right it's a ban 10:27 <@jnewbery> amiti: right. It's instaban 10:27 < amiti> haha. instaban. 10:28 <@jnewbery> the DOS scores are weird and were somewhar arbitrary until 15141 10:28 < lightlike> i understand it only in parts: Couldn't it be introduced just as well together with the next consensus change instead of now? Has it been implemented now so that future consensus changes don't forget about the idea? 10:29 <@jnewbery> lightlike: Yes, the code isn't exercised now so it could just be added with the next consensus change 10:29 <@jnewbery> I think the best reason for having the code in place now is so future consensus changes don't forget the idea 10:30 <@jnewbery> I think in segwit this was almost forgotten (but that was before i was active in Bitcoin Core so I'm certain about that) 10:30 < michaelfolkson> That would not have been ideal for network stability 10:30 <@jnewbery> the risk is that some portion of the network upgrades, the softfork is activated, and then someone sends a transaction that is invalid under the new rules to nodes that haven't upgraded yet 10:31 <@jnewbery> those old nodes relay the transaction, but if they relay it to an upgraded node then that upgraded node will reject it 10:31 <@jnewbery> we don't want the upgraded nodes to disconnect/ban the unupgraded nodes. That would cause a network split 10:31 -!- Moller40 [~mr@82.103.128.151] has joined #bitcoin-core-pr-reviews 10:32 <@jnewbery> so we want to treat txs/blocks that fail validation for RECENT_CONSENSUS_CHANGE differently than those that fail for long-standing CONSENSUS rules 10:32 -!- Moller40_ [~mr@82.103.130.25] has quit [Ping timeout: 240 seconds] 10:32 <@jnewbery> (nothing about that changed in this PR, but I thought it was a fun sidetrack) 10:32 < amiti> ok so thats the reason for having the distinction between recent & existing, but the reason that code is _already_ introduced is so its not forgotten about during implementation? 10:32 <@jnewbery> amiti: yes 10:33 < amiti> gotcha. thanks 10:33 < michaelfolkson> I'm wondering if there are better approaches than putting these "placeholders" in 10:33 <@jnewbery> My final question was for all of you to either prepare a question or share an observation you made while reviewing the PR. Anyone have anything? 10:34 < fjahr> What did you think of my idea to move the punishment logic out? 10:34 <@jnewbery> oh, here's some discussion of RECENT_CONSENSUS_CHANGE: https://github.com/bitcoin/bitcoin/pull/15141#discussion_r247736063 10:35 < fjahr> I saw from other PRs that it is not necessarily a goal to reduce net_processing size but I am still interested 10:35 <@jnewbery> fjahr: I'm not sure it achieves much. peer punishment logic is so tied to net processing logic that separating them into separate translation units doesn't seem like an improvement 10:36 < amiti> jnewbery: I have a question about your git workflow- I noticed you pushed fixup commits in response to reviewer comments, and then squashed & force pushed afterwards. I was wondering if there was a specific reason you did that (vs squash and force push initially)... potentially to make it easier for reviewers to see the recent changes? 10:36 < fjahr> jnewbery: ok, thanks 10:36 <@jnewbery> peer punishment logic wouldn't be required by any other component, which is one reason you'd want to separate them 10:38 <@jnewbery> amiti: yeah, that's it. Just so those reviewers could very quickly see what changes I'd made in response to their comments. Lightlike suggested a much better way to do what he'd asked for, so I was able to throw away my commit and use his suggested method 10:38 <@jnewbery> as soon as those reviewers were happy I just squashed the changes into the relevant commits and force pushed. Verifying that a force-push doesn't change the final code is very quick 10:38 -!- Moller40 [~mr@82.103.128.151] has quit [Quit: -a- IRC for Android 2.1.55] 10:40 <@jnewbery> if I'd squashed and force-pushed initially and then lightlike had made his suggestion, I'd have wasted a bunch of time changing the initial commit and then changing it back and potentially having to resolve merge conflicts 10:40 <@jnewbery> any other comments/questions? 10:40 < amiti> ah I see. ok thanks 10:40 < michaelfolkson> If nobody else has anything I wouldn't mind chatting more about the punishment logic 10:41 <@jnewbery> michaelfolkson: just ask. No need to ask to ask :) 10:41 < michaelfolkson> So I'm assuming there is no way to trick a honest peer into forwarding a consensus invalid transaction 10:41 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Read error: Connection reset by peer] 10:42 < michaelfolkson> I'm wondering if this scoring system is optimal and whether it can be gamed 10:42 <@jnewbery> michaelfolkson: not if the tx fails validation on your node 10:42 < michaelfolkson> Instaban seems pretty confident the peer is dishonest 10:43 <@jnewbery> of course if your node is old or isn't validating the same consensus rules as everyone else and an adversary knows that, then they can send you a tx that isn't valid according to the rest of the network and is valid for you. You'd try to relay that one 10:43 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews 10:44 < michaelfolkson> What about the weaker punishments? Discussed in https://github.com/bitcoin/bitcoin/pull/15141 10:44 <@jnewbery> what do you mean by weaker punishments? 10:45 < lightlike> i think if you send two version messages, you just a get score of 10 10:45 < lightlike> for examlpe 10:45 < michaelfolkson> Oh a lot of them have moved to max punishment (100) 10:46 <@jnewbery> lightlike: it's actually 1 10:46 <@jnewbery> https://github.com/bitcoin/bitcoin/blob/a6abc94e9307ea05972ef69732bb148acbfa870a/src/net_processing.cpp#L1912 10:46 < sdaftuar> an important idea relating to tricking a peer into forwarding a consensus invalid transaction happens with softfork deployment 10:46 < michaelfolkson> Some of them were previously 10/50 points 10:46 < michaelfolkson> But now full ban 10:47 <@jnewbery> which is incredibly arbitrary. We'll tolerate a peer sending us 99 duplicate VERSION messages, but ban them on the 100th 10:47 < sdaftuar> this is why we strive to ensure that features that transactions which will obey new consensus rules are policy-invalid (though obviously not consensus invalid) to old peers 10:47 < sdaftuar> s/that features// 10:48 < michaelfolkson> Interesting 10:48 <@jnewbery> right. We want consensus changes to be policy-invalid for some length of time before they become consensus-invalid 10:49 < michaelfolkson> And we can overwrite the ban if it is a peer that we trust? 10:49 <@jnewbery> note that we don't ban peers for sending us policy-invalid txs: https://github.com/bitcoin/bitcoin/blob/a6abc94e9307ea05972ef69732bb148acbfa870a/src/net_processing.cpp#L1073-L1079 10:49 <@jnewbery> michaelfolkson: take a look at whitelisting. We'll never bad/disconnect a whitelisted peer 10:49 < sdaftuar> jnewbery: this gets to the heart of the CONSENSUS_CHANGE vs RECENT_CONSENSUS_CHANGE debate 10:49 < michaelfolkson> : Yup thanks 10:50 <@jnewbery> Last 10 minutes. Any more questions/observations? 10:51 < michaelfolkson> Just to clarify on 's question. Really long files are ok as long as they don't contain parts that multiple components use? 10:52 < michaelfolkson> Length isn't a variable to consider? 10:53 <@jnewbery> michaelfolkson: it'd be nicer to have shorter source files, where code can be logically split up 10:54 < michaelfolkson> But low on the priority list right? 10:54 <@jnewbery> but in this case, the only places that call MaybeDisconnectPeerForX() are in net_processing, so it doesn't make sense to split it out 10:55 < michaelfolkson> Yeah it would only be for readability I suppose 10:55 < michaelfolkson> Ok thanks 10:55 <@jnewbery> any more questions? 10:57 <@jnewbery> ok, let's wrap it up there. Thanks everyone! And thanks sdaftuar for dropping in 10:57 < lightlike> thanks all! 10:57 <@jnewbery> I'll post next week's PR before this weekend 10:57 < michaelfolkson> Indeed, thanks everyone 10:57 < fjahr> thanks john! and all :) 10:57 < amiti> thanks ! 10:58 < diogosergio> Thanks, it was good to follow this up! 10:58 < michaelfolkson> Kept too quiet ;) 11:00 < diogosergio> Not that technical, but good to see how things work and what goes behing the pr reviews. :) 11:00 -!- sebastianvstaa [~sebastian@212.32.225.229] has joined #bitcoin-core-pr-reviews 11:16 -!- mango [cdd118e3@205.209.24.227] has quit [Remote host closed the connection] 11:33 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:e5f7:5b8e:caec:35a0] has quit [Quit: Sleep mode] 11:34 <@jnewbery> meeting logs are up: https://bitcoincore.reviews/15921.html 11:42 -!- sebastianvstaa [~sebastian@212.32.225.229] has quit [Ping timeout: 240 seconds] 11:43 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 11:43 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Ping timeout: 265 seconds] 12:04 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 12:07 -!- sebastianvstaa [~sebastian@212.32.225.229] has joined #bitcoin-core-pr-reviews 12:08 < jonatack> Just realised I was disconnected from irc and thinking in the wrong timezone :/ ... looking forward to reading the meeting log! 12:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack] 12:11 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 12:14 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection] 12:15 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews 12:16 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection] 12:35 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:37 -!- davterra [~none@195.242.213.120] has joined #bitcoin-core-pr-reviews 12:38 -!- davterra [~none@195.242.213.120] has quit [Remote host closed the connection] 12:41 -!- sebastianvstaa [~sebastian@212.32.225.229] has quit [Ping timeout: 268 seconds] 12:43 -!- diogosergio [~diogoserg@176.24.23.243] has joined #bitcoin-core-pr-reviews 12:51 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Quit: leaving] 12:53 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 13:00 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Quit: leaving] 13:02 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 13:05 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Client Quit] 13:06 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 13:09 -!- ajonas [uid385278@gateway/web/irccloud.com/x-xnlguzztavtmbbma] has quit [Quit: Connection closed for inactivity] 13:14 -!- sebastianvstaa [~sebastian@212.32.225.229] has joined #bitcoin-core-pr-reviews 13:16 -!- ajonas [uid385278@gateway/web/irccloud.com/x-tajqitbeahtbcgrd] has joined #bitcoin-core-pr-reviews 13:31 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Quit: leaving] 13:32 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 13:40 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.4 - https://znc.in] 13:40 -!- sebastianvstaa [~sebastian@212.32.225.229] has quit [Quit: Leaving] 13:44 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 14:35 -!- davterra [~none@89.187.165.157] has joined #bitcoin-core-pr-reviews 16:08 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Quit: leaving] 16:09 -!- diogosergio [~diogoserg@195.206.183.104] has joined #bitcoin-core-pr-reviews 16:48 -!- diogosergio [~diogoserg@195.206.183.104] has quit [Ping timeout: 265 seconds] 18:02 -!- davterra [~none@89.187.165.157] has quit [Quit: Leaving] 18:49 -!- lightlike [~lightlike@2001:16b8:5728:f700:60f7:e4ab:9b1b:7bbf] has quit [Quit: Leaving] 19:09 -!- ajonas [uid385278@gateway/web/irccloud.com/x-tajqitbeahtbcgrd] has quit [Quit: Connection closed for inactivity] 19:11 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has quit [Read error: Connection reset by peer] 19:43 -!- seven_ [~seven@193.77.101.62] has joined #bitcoin-core-pr-reviews 20:09 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Ping timeout: 240 seconds] 20:09 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 20:19 -!- felixfoertsch [~felixfoer@i6DFA6414.versanet.de] has joined #bitcoin-core-pr-reviews 20:20 -!- felixfoertsch23 [~felixfoer@i6DFA67F9.versanet.de] has quit [Ping timeout: 240 seconds] 22:09 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection] 22:17 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined #bitcoin-core-pr-reviews