--- Day changed Wed Sep 25 2019 00:52 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 246 seconds] 01:30 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #bitcoin-core-pr-reviews 02:52 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 02:56 -!- designwish [~designwis@51.ip-51-68-136.eu] has quit [Quit: ZNC - http://znc.in] 03:02 -!- designwish [~designwis@51.ip-51-68-136.eu] has joined #bitcoin-core-pr-reviews 03:04 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-pr-reviews 03:07 -!- icota [d5953d2c@213.149.61.44] has joined #bitcoin-core-pr-reviews 03:14 -!- icota [d5953d2c@213.149.61.44] has quit [Remote host closed the connection] 03:31 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #bitcoin-core-pr-reviews 04:41 -!- shesek`` [~shesek@5.22.135.66] has quit [Read error: Connection reset by peer] 05:22 -!- gorazdko [59d42ea3@89-212-46-163.dynamic.t-2.net] has joined #bitcoin-core-pr-reviews 06:16 -!- emilengler_ is now known as emilengler 06:55 < sosthene> Hi folks, I'm experiencing issues with the vagrant VM that I've been using to test PR, I opened an issue https://github.com/jnewbery/btc-dev/issues/15 06:55 < sosthene> I already spent some hours trying to figure it out, any help would be appreciated :) 07:44 < jonatack> sosthene: Wish I could be of help but I just compile directly from source as per this summary I wrote: https://github.com/jonatack/bitcoin-development/blob/master/how-to-compile-bitcoin-core-from-source-on-linux-and-macOS.md 07:49 < jonatack> which I just realised should be clarified for the simpler case of re-building for testing PR branches, where you can go straight to make and make check with an occasional make clean. 07:54 < pinheadmz> I already have bitcoin built from source locally. When I pull this branch and `make` again -- it looks like it is recompiling the entire code base. Is that right? Is there a flag to just recompile the elements that have changed? 08:09 -!- lightlike [~lightlike@2001:16b8:57bd:700:5994:5f4e:65db:c1d4] has joined #bitcoin-core-pr-reviews 08:09 < sosthene> jonatack: you're not using a VM? 08:10 < sosthene> thanks for your tuto, I'm using it to try another way to make it work 08:12 < jonatack> pinheadmz: do you have ccache installed? you can also specify which parts to compile if you don't need the other ones. Check out doc/developer-notes.md and doc/productivity.md. 08:14 < jonatack> sosthene: I'm a horrible, lazy person who has not yet used a VM to build bitcoind yet :p 08:15 < jonatack> sosthene: though for testing different platforms other than Debian and macOS I should probably do so 08:18 < sosthene> hahaha it's reassuring to see technical people that are not like "what you're not running it all on Docker/Vagrant/Qubes/whatever?!" :D 08:24 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has joined #bitcoin-core-pr-reviews 08:37 < jonatack> heh 09:17 -!- diogosergio [~diogoserg@185.5.172.150] has joined #bitcoin-core-pr-reviews 09:22 < diogosergio> /quit 09:22 -!- diogosergio [~diogoserg@185.5.172.150] has quit [Quit: Lost terminal] 09:30 < sosthene> Well, I used your tuto and it kind of work, but it fails on compile. I dumped the whole log here https://gist.github.com/BobleChinois/893a5d00e10d5ec7195100f50afa5a6b 09:31 < sosthene> `Makefile:10392: recipe for target 'bench/bench_bench_bitcoin-data.o' failed` I'm checking it out now 09:33 < jonatack> sosthene: maybe try make clean before make, or configure with --disable-bench 09:33 < sosthene> yeah fount it :) https://github.com/bitcoin/bitcoin/issues/16479 09:33 < sosthene> I'm trying again 09:34 < jonatack> sosthene: great :) 09:34 < jonatack> This week I'm counting on you all to not be shy 09:35 < jonatack> I might be slow to respond because my CPUs are running near 100% from making a big wallet for the past few days 09:35 < jonatack> am close to the end of running an achow101 script called make-big-wallet.py... 09:35 < jonatack> to test the wallet memory PR with flame graphs 09:36 < sosthene> wow is it that big a wallet? 09:40 < jonatack> 160MB ATM 09:40 < jonatack> so not that big, but biggish 09:49 -!- sebastiavstaa [~sebastian@37.58.59.184] has joined #bitcoin-core-pr-reviews 09:50 -!- michaelfolkson [~textual@82.132.187.166] has joined #bitcoin-core-pr-reviews 09:53 < jonatack> We'll get started in about 7 minutes. 09:54 < zenogais> Sounds good! 09:57 -!- watcher [253a3bb8@37.58.59.184] has joined #bitcoin-core-pr-reviews 09:58 -!- rwang [uid386281@gateway/web/irccloud.com/x-wdipbxkbbsertqdj] has joined #bitcoin-core-pr-reviews 10:00 -!- watcher [253a3bb8@37.58.59.184] has left #bitcoin-core-pr-reviews [] 10:00 < jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club. 10:00 < fjahr> hi 10:00 < pinheadmz> hi 10:00 < gorazdko> hi 10:00 < sebastiavstaa> hi 10:00 < jonatack> (We usually start Bitcoin Core IRC meetings with a 'hi' so it's clear who's at keyboard. Feel free to say hi here!) 10:01 < jonatack> Feel free to jump in at any point with thoughts and questions, don't be shy :) 10:01 < michaelfolkson> Holla 10:01 < jonatack> This week, we're talking about PR16202 - "Refactor network message deserialization" by jonasschnelli 10:01 < jonatack> The PR is part of on-going work by jonasschnelli on BIP 324: Version 2 Peer-to-Peer Message Transport Protocol. 10:01 < lightlike> hi 10:01 < zenogais> hi all 10:02 < jonatack> jonasschnelli: By any chance, are you here? Would you like to say anything about this PR, or the next steps for BIP 324? Feel free to jump in anytime. 10:02 < sosthene> hi 10:03 < jonatack> Let's get started. Did you review the PR? What are your thoughts... Concept ACK, approach ACK, tested ACK, or NACK? 10:03 < fjahr> tested ACK although I did not have much time to look at the code 10:04 < jonatack> etscrivner: jkczyz: Great to see your reviews of the PR on GitHub! 10:04 < zenogais> Tested ACK. I was able to review the whole PR as well as test it. 10:04 < jonatack> fjahr: Excellent. 10:04 * zenogais is etscrivner btw 10:04 < jonatack> zenogais: got it :) 10:04 < jonatack> How did you test? 10:04 < lightlike> concept ack, haven't understood the code yet completely. 10:04 < sosthene> I do have a question that is more about the whole BIP than this PR. I remember some time ago evoskuil criticizing the BIP on Twitter I think, but I couldn't find the thread again. So what could be controversial about it? 10:05 < zenogais> I ran the unit and functional tests. Also used my own P2P library in C to run some manual tests and make sure things worked as I expected. 10:05 < sebastiavstaa> built and ran the tests. 10:05 < sosthene> (if anyone knows what I'm talking about and can link to evoskuil arguments I would be very grateful) 10:05 < jonatack> Did anyone add any tests, assertions, or custom logging to test the PR? 10:06 < pinheadmz> built and tested, broke the test and tested the test :-) 10:06 < pinheadmz> just the one test that was altered, the error message is changed 10:06 < pinheadmz> I assume because its a refactor, the existing tests cover and protect against regresison 10:06 < jonatack> I added some basic logging for sanity checks https://gist.github.com/jonatack/d6a228878e6ef5f582ff75c974f2d6c3 10:07 < jonatack> and would like to run the changes through gdb tomorrow for my review, since p2p is a risky area. 10:07 < jonatack> sosthene: I wasn't aware of controversy WRT BIP 324. 10:08 < zenogais> Might be useful to have some sort of P2P fuzzing also (if it doesn't already exist). 10:08 < pinheadmz> jonatack: that's cool - these properties i.e. msg.m_command are new to this PR right? 10:08 < sosthene> jonatack: I guess that's evoskuil vs the rest of the world then 10:09 < jonatack> pinheadmz: yeah, I want to see the values as a sanity check 10:09 < jonatack> pinheadmz: it's only a start 10:09 < jonatack> sosthene: if you have a link please share! 10:09 < michaelfolkson> Nor me, sorry . Perhaps contact him? 10:10 < jonatack> zenogais: Fuzzing is one area the maintainers would be very happy to see additional tests or data for. 10:10 < jonatack> MarcoFalke is the primary contact for that. 10:10 < michaelfolkson> I didn't stumble on any conceptual downsides to this BIP 10:10 < jonatack> See also doc/fuzzing.md 10:10 -!- next-defection [~next-defe@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:11 < zenogais> jonatack: Thanks, will give it a look. Have been thinking about P2P fuzzing specifically for a couple of weeks now. 10:11 -!- michaelf_ [~textual@82-132-231-86.dab.02.net] has joined #bitcoin-core-pr-reviews 10:11 -!- michaelf_ [~textual@82-132-231-86.dab.02.net] has quit [Client Quit] 10:11 -!- michaelf_ [~textual@82-132-231-86.dab.02.net] has joined #bitcoin-core-pr-reviews 10:12 < jonatack> zenogais: Any contribution to the fuzz testing would probably be very welcome! 10:12 < jonasschnelli> hi 10:12 < jkczyz> hi 10:12 * zenogais waves 10:12 < jonatack> jonasschnelli: hi thanks for coming by 10:13 < jonasschnelli> Sorry for being late 10:13 < jonatack> jkczyz: thanks for reviewing the PR 10:13 * jonasschnelli is reading back 10:13 * next-defection thumbs up to fuzzing 10:13 < jonasschnelli> Should I explain why I did this PR (PR16202) 10:13 < jonatack> jonasschnelli: Would you like to say anything about this PR, or the next steps for BIP 324? 10:13 < lightlike> here is a link to the points by evoskuil: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016810.html 10:13 < jonatack> jonasschnelli: yes please! 10:14 < sosthene> I found it https://twitter.com/evoskuil/status/825089930221064192 10:14 < jonasschnelli> PR16202 is just about adding flexibility for allowing multiple transport protocol 10:14 < jonatack> jkczyz: (we were discussing how people tested the PR, if you would like to share what you did to test it) 10:14 -!- michaelfolkson [~textual@82.132.187.166] has quit [Ping timeout: 240 seconds] 10:15 < sosthene> and this wrt BIP151 https://github.com/bitcoin/bips/wiki/Comments:BIP-0151 10:15 < jonasschnelli> It is necessary for any forms of protocol upgrades and also a nice refctor if nothing gets added (which we don't hope) 10:15 < jonasschnelli> evoskuil's points are valid,... not sure if the overall desire (or dislike) of encryption is something we should discuss here. 10:15 < jonasschnelli> But we can... 10:15 < jonatack> jonasschnelli: What are the next BIP324 PRs we should review after this one is hopefully in 10:16 < jonatack> jonasschnelli: and PR #16562: Refactor message transport packaging https://github.com/bitcoin/bitcoin/pull/16562 10:16 < jonasschnelli> Yes... that one is in align with the deserialization 10:16 < jonasschnelli> I have a branch I'd like to open after those two PRs have been merged 10:17 < jonasschnelli> Both PRs are pretty much straight forward with little to no impact 10:18 < michaelf_> What was thinking behind separating the serialization and deserialization into two PRs? Safety or just cleaner? 10:18 < pinheadmz> jonasschnelli: how often would a node generate a new key for DH? every new peer conncetion? every restart? just once? 10:18 < jonasschnelli> michaelf_: I always try to make PRs small as possible if they allow to be splitted 10:18 < jkczyz> jonatack: Wasn't able to test, only reviewied this morning. Busy last week on the job. :) 10:19 < jonatack> michaelf_: Not to speak for jonasschnelli but it's usually easier for smaller changes to get review and merged quickly 10:19 < jonasschnelli> pinheadmz: it's described in the BIP. The DH key is generated once during the encryption handshake. 10:19 < jonasschnelli> But we do rekey every <1GB 10:19 < jonatack> michaelf_: it's good to keep PRs focused 10:20 < michaelf_> Makes sense. The deserialization PR isn't much use without the serialization PR though is it? 10:20 < jonasschnelli> large PRs in risky areas (like the p2p field) tends to loop forever in rebase limbo. :) 10:20 < jonatack> jkczyz: I understand :) 10:20 < jonasschnelli> michaelf_: The are independent. 10:20 < jonasschnelli> But for BIP324, we need both at the end 10:20 < jonasschnelli> But they are both refactors that are valid on their own 10:20 < michaelf_> Ok thanks 10:21 < jonatack> jonasschnelli: Is this PR still a prerequisite for https://github.com/bitcoin/bitcoin/pull/14032 10:22 < zenogais> One comment: Separating serialization from message data structure is I thinking cleaner overall, even if this wasn't in order to add V2 serialization I still think it's a good refactor. 10:22 < jonatack> Add p2p layer encryption with ECDH/ChaCha20Poly1305 #14032 ... on the road to implementing BIP324. 10:22 < jonasschnelli> jonatack: yes. Somehow. But they need refactor once 16202 lands 10:22 < jonatack> jonasschnelli: right. 10:23 < jonatack> As the review club improves over time, it would be great to see us tackle the high priority PRs more often. 10:23 < jonasschnelli> in general, the criticism about no need for encryption (voskuli) since it's all public anyways looks valid at first sight,... but 10:24 < jonasschnelli> BIP324 eliminates passive observing and add detectability of a MITM 10:24 < jonasschnelli> *adds 10:24 < jonasschnelli> its opportunistic encryption and therefor a building block 10:25 < zenogais> jonasschnelli: It sounds like MITM detection is optional and must be done manually by peers though via side-channel? 10:25 < sosthene> It seems Eric is arguing that MITM detection would hard in practice, since node would need to exchange session ID over safe channel 10:26 < jonasschnelli> zenogais: yes. BIP324 has no MITM detectability next to manual comparison of session IDs... 10:26 < jonasschnelli> but.... 10:26 < jonasschnelli> An attacked needs to take the risk of being detected... which is a big difference to the current status quo 10:26 < zenogais> Protection against passive observability is still probably a pretty big win for most users. 10:26 < jonasschnelli> he cannot know if an authentication happens after he has mitm-led the encryption 10:27 < jonasschnelli> usually detectable observing and tampering is much less valuable for an attacker 10:27 < next-defection> I disagree with the critiques brought up by evoskuli, P2P encryption increase observation costs (undeniable) 10:27 < zenogais> Yeah, and optional MITM detection is still better than V1. 10:28 < jonasschnelli> right now,... everyone on the network between two peers can delay a block... peers can not detect that and the attacker can be sure of that 10:28 < next-defection> even if "but MITM is still possible" "better is the enemy of good" situations are present 10:29 < jonasschnelli> Yes. And there are schemes (Pieter Wuillies for example) building on top of BIP324, that would broad scale detect MITMs 10:29 < next-defection> the blockchain stores a limited set of information, it doesn't store the transport information which is highly valuable to well-funded attackers 10:30 < jonasschnelli> Yes. The p2p traffic is in general not considered public. 10:30 < jonasschnelli> But chain analysis will still be possible with BIP324 10:30 < sosthene> Does it still make sense to use Tor with this "native" encryption? 10:31 < jonasschnelli> (since this is very likely active listening) 10:31 < sosthene> I mean, does it bring any extra security or is it negligible? 10:31 < jonatack> The best way each of us can help jonasschnelli move BIP 324 forward, is to review these PRs. 10:31 < jonasschnelli> Tor is an alternative,.. though a slightly different threat model (mostly censorship) 10:31 < jonasschnelli> But... the great thing is, we can run BIP324 through tor 10:31 < jonasschnelli> at no cost 10:31 < jonasschnelli> (faster, less bandwith) 10:32 < jonatack> sosthene: IIRC, BIP 324 makes targeting more difficult for SPV nodes and those not using a VPN or Tor, but Tor is still valid with it. 10:32 < jonasschnelli> bandwidth 10:32 < jonasschnelli> BIP324 is our own encryption with no dependencies. Simple and effective. 10:33 < jonasschnelli> Additionally, you can circumvent censorship or connectivity issues with tor 10:34 < jonasschnelli> Right now,... there are a bunch of people connecting their mobile wallets (Green, BRD, Schildbach) to their nodes with a IPv4 10:34 < jonasschnelli> Which is _absolutely_ not secure 10:34 < sosthene> jonatack: (I just finished running all the tests, finally! all passed :) 10:34 < jonasschnelli> (and those users assume to preserve privacy) 10:35 < jonasschnelli> however, to solve that non-tor connection, we need BIP150 10:35 < jonasschnelli> (which may follow after BIP324) 10:36 < jonatack> https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki 10:36 < jonatack> "This BIP describes a way for peers to authenticate to other peers to guarantee node ownership and/or allow peers to access additional or limited node services, without the possibility of fingerprinting." 10:37 < jonasschnelli> But one thing after another. :) PR16202 is a baby step forwards 10:38 < jonatack> It seems the first question has been well-covered! "Why was this PR written and considered high-priority?" 10:38 < michaelf_> Re the new message structure. Variable size message is big win. You also got rid of the magic bytes? 10:38 < jonasschnelli> Yes 10:39 < michaelf_> Why? Not needed? 10:40 < michaelf_> I suppose not 10:40 < jonatack> jonasschnelli: When working on changes to the p2p network, are there any particular ways you test that the changes are working as intended? 10:40 < jonasschnelli> I don't think it's needed. We have port for specific network. And it would fail anyways quickly. 10:41 < jonatack> We don't really have a framework yet for p2p simulation. 10:41 < zenogais> So net magic isn't needed to avoid peering with wrong network peers? 10:41 < jonasschnelli> jonatack: I think the test framework covers a lot. Though, running such PRs for a while (couple of days) on a node may reveal more details. 10:41 < jonasschnelli> zenogais: yes... I think that was the intention 10:42 < jonasschnelli> But the cost of 4 bytes per every message (and ~50% are less then 64 bytes) is quite high 10:42 < zenogais> Right, I suppose it could just be part of the handshake 10:43 < jonasschnelli> Yes. Maybe this is not a bad idea. 10:44 < jonatack> Shorter INVs are a win since they make up so much of the messages. 10:44 < jonasschnelli> yes. 10:44 < zenogais> Without seeing the network magic bytes at least once, I could see scenarios where nodes incorrectly peer - especially if they're sync from scratch 10:44 < jonasschnelli> The network magic could maybe be added to the HKDF 10:44 < jonasschnelli> https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#symmetric-encryption-cipher-keys 10:44 < jonasschnelli> instead of PRK = HKDF_EXTRACT(hash=SHA256, salt="BitcoinSharedSecret||INITIATOR_32BYTES_PUBKEY||RESPONDER_32BYTES_PUBKEY", ikm=ECDH_KEY) 10:44 < jonasschnelli> make PRK = HKDF_EXTRACT(hash=SHA256, salt="NETWORK_MAGIC||BitcoinSharedSecret||INITIATOR_32BYTES_PUBKEY||RESPONDER_32BYTES_PUBKEY", ikm=ECDH_KEY) 10:45 < jonasschnelli> A handshake on the wrong network would just fail 10:45 < zenogais> Ah nice, yeah that would work perfectly 10:45 < jonasschnelli> Good point zenogais. I'll add others for feedback on that idea 10:45 < jkczyz> jonatack: High priority because it allows two separate transport implementations would be my educated guess. 10:46 < jonasschnelli> High priority is a per-developer thing. I consider it high-prio/blocker for my work. 10:46 < jonasschnelli> Since we have no central planing, every active developer can add stuff to the high-prio list 10:46 < jonasschnelli> (to avoid central planing) 10:46 < michaelf_> It is a blocker to other PRs yeah 10:47 < michaelf_> And for a direction that seems to have broad consensus bar Eric 10:48 < jonasschnelli> I think most people agree that it is a useful thing 10:48 < jonasschnelli> We have also already merged the cryptographic primitives (chacha20, poly1305, hkdf) as well as the AEAD 10:48 < jonasschnelli> (which are less risky since they are only used in tests) 10:50 < jonatack> Improving privacy is so essential. A thousand thank you's, Jonas, for your work on this. 10:50 < jonasschnelli> Thanks for reviewing guys! 10:50 < zenogais> Yeah, this is great work, really looking forward to the V2 transport stuff. 10:50 < jonatack> Let's all get our review in tomorrow for those who haven't yet. 10:51 < sosthene> jonasschnelli: Thanks, it was great to have you here 10:51 < jonatack> Ten minutes left, and I'm glad we've been able to discuss the most important issues. 10:51 < jonatack> Any other comments, feedback, or questions? 10:51 < michaelf_> In terms of future work. you referred to 64 byte public keys and randomizing ports. Can you elaborate? 10:52 -!- baroobob [a75807a2@167.88.7.162] has joined #bitcoin-core-pr-reviews 10:52 < michaelf_> Also found it interesting that there could be different authentication schemes 10:52 < lightlike> do you think that v2 will take over completely, or do you think both v1 and v2 will coexist for a long time? 10:52 < jonasschnelli> I think so 10:52 < jonatack> michaelf_: you mean in my slides? Those were only a quick summary of jonasschnelli's complete slides. 10:53 < michaelf_> Ah ok. I'll look back at Jonas' slides 10:53 < jonasschnelli> I think randomising ports would go into the direction of censorship resistance which is very complicated and I think this should be done on other layers like tor 10:54 < jonasschnelli> even with randomised ports, by looking at the package size and burst-characteristics, identifying bitcoin traffic is trivial. 10:55 < jonatack> michaelf_: Great question. 10:55 < jonasschnelli> lightlike: back to the v1/v2 question. I think, when there are enough peers supporting v2, people may disable v1 10:55 < jonasschnelli> but sadly its a slow transition 10:55 -!- clarkmoody [~clarkmood@167.71.122.99] has joined #bitcoin-core-pr-reviews 10:56 < jonasschnelli> (unless v1 gets exploited which is unlikely) 10:57 < jonatack> jonasschnelli: would you see v2 on by default in future releases? or only after a certain level of v2 adoption? 10:57 < jonasschnelli> I hope... I guess this is the plan. Though time will show and it needs enought people willing to run v2 10:58 < jonatack> Privacy may turn out to be a good motivation * crosses fingers 10:58 < michaelf_> Less systemic risk if half the network is running v1 and half is running v2 rather than everyone running v2 :) 10:58 < jonatack> If anyone wants to continue with the other questions after we wrap up, I'll hang around. 10:59 < jkczyz> jonasschnelli: I have a suggestion regarding TransportDeserializer's interface but will leave a new comment on the PR. 10:59 < jonasschnelli> thanks jkczyz 10:59 < jonasschnelli> I'll try to tackle the comments by tommorw 11:00 < jonatack> Thanks, everyone, for participating this week! 11:00 < jonatack> Thanks jonasschnelli for coming by! 11:00 < michaelf_> Thanks both 11:00 < lightlike> thanks jonatack, jonasschnelli! 11:00 < jonasschnelli> thanks all 11:00 < zenogais> Thanks all, appreciate you fielding our questions jonasschnelli 11:00 < sebastiavstaa> thanks all 11:01 < jonatack> Thanks to zenogais and jkczyz for reviewing the PR, good job. 11:03 -!- michaelf_ [~textual@82-132-231-86.dab.02.net] has quit [Quit: Sleep mode] 11:06 < jonatack> sosthene: Good news on all the tests passing. 11:08 < next-defection> WRT BGP-based sigint: https://arstechnica.com/information-technology/2018/11/strange-snafu-misroutes-domestic-us-internet-traffic-through-china-telecom/ https://twitter.com/matthew_d_green/status/1151965634370199552/ 11:09 < jonatack> zenogais: will be interesting to see what sipa and real or random think of your idea (see #bitcoin-core-dev channel) 11:19 -!- next-defection [~next-defe@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews [] 11:49 < zenogais> jonatack: Oh nice, yeah very interested to hear thoughts. 12:16 -!- sebastiavstaa [~sebastian@37.58.59.184] has quit [Ping timeout: 240 seconds] 12:23 -!- diogosergio [~diogoserg@195.206.183.218] has joined #bitcoin-core-pr-reviews 12:29 -!- diogosergio [~diogoserg@195.206.183.218] has quit [Quit: Lost terminal] 12:38 -!- sebastiavstaa [~sebastian@37.58.59.184] has joined #bitcoin-core-pr-reviews 13:19 -!- fox2p [fox2p@gateway/vpn/mullvad/fox2p] has joined #bitcoin-core-pr-reviews 13:22 -!- fox2p_ [fox2p@gateway/vpn/mullvad/fox2p] has quit [Ping timeout: 265 seconds] 13:27 -!- gorazdko [59d42ea3@89-212-46-163.dynamic.t-2.net] has quit [Remote host closed the connection] 13:35 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has quit [Read error: Connection reset by peer] 13:36 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 13:36 -!- jnewbery [~john@rrcs-184-74-240-156.nyc.biz.rr.com] has joined #bitcoin-core-pr-reviews 13:36 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 13:56 -!- diogosergio [~diogoserg@195.206.183.218] has joined #bitcoin-core-pr-reviews 13:58 -!- hebasto [~hebasto@95.164.65.194] has quit [Ping timeout: 265 seconds] 13:59 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 14:00 < diogosergio> clear 14:00 < diogosergio> oops :) 14:24 -!- diogosergio [~diogoserg@195.206.183.218] has quit [Ping timeout: 245 seconds] 14:29 -!- diogosergio [~diogoserg@195.206.183.218] has joined #bitcoin-core-pr-reviews 15:11 -!- baroobob [a75807a2@167.88.7.162] has quit [Remote host closed the connection] 15:28 -!- seven__ [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews 15:30 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has quit [Ping timeout: 245 seconds] 15:36 -!- clarkmoody [~clarkmood@167.71.122.99] has quit [Remote host closed the connection] 15:36 -!- clarkmoody [~clarkmood@167.71.122.99] has joined #bitcoin-core-pr-reviews 15:37 -!- clarkmoody [~clarkmood@167.71.122.99] has quit [Remote host closed the connection] 15:37 -!- clarkmoody [~clarkmood@167.71.122.99] has joined #bitcoin-core-pr-reviews 15:47 -!- clarkmoody [~clarkmood@167.71.122.99] has quit [Ping timeout: 276 seconds] 15:48 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Remote host closed the connection] 16:00 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 16:11 -!- diogosergio [~diogoserg@195.206.183.218] has quit [Quit: Lost terminal] 16:13 -!- diogosergio [~diogoserg@195.206.183.218] has joined #bitcoin-core-pr-reviews 16:40 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-pr-reviews 16:40 -!- diogosergio [~diogoserg@195.206.183.218] has quit [Read error: Connection reset by peer] 16:44 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Ping timeout: 265 seconds] 17:03 -!- diogosergio [~diogoserg@195.206.183.218] has joined #bitcoin-core-pr-reviews 17:07 -!- diogosergio [~diogoserg@195.206.183.218] has quit [Ping timeout: 240 seconds] 17:20 -!- lightlike [~lightlike@2001:16b8:57bd:700:5994:5f4e:65db:c1d4] has quit [Quit: Leaving] 17:35 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-pr-reviews 17:44 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Ping timeout: 268 seconds] 17:50 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 17:50 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 19:06 -!- emilengler_ [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-pr-reviews 19:09 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Ping timeout: 265 seconds] 19:21 -!- harrigan [~harrigan@149.5.35.1] has quit [Quit: ZNC 1.7.4 - https://znc.in] 19:27 -!- harrigan [~harrigan@149.5.35.1] has joined #bitcoin-core-pr-reviews 19:38 -!- clarkmoo_ [~clarkmood@167.71.122.99] has joined #bitcoin-core-pr-reviews 19:39 -!- clarkmoo_ [~clarkmood@167.71.122.99] has quit [Client Quit] 20:04 -!- zenogais [~user@cpe-76-175-74-114.socal.res.rr.com] has quit [Ping timeout: 240 seconds] 20:31 -!- harrigan_ [~harrigan@149.5.35.1] has joined #bitcoin-core-pr-reviews 20:33 -!- harrigan [~harrigan@149.5.35.1] has quit [Ping timeout: 245 seconds] 20:56 -!- harrigan_ [~harrigan@149.5.35.1] has quit [Quit: ZNC 1.7.4 - https://znc.in] 20:56 -!- harrigan [~harrigan@149.5.35.1] has joined #bitcoin-core-pr-reviews 21:36 -!- harrigan [~harrigan@149.5.35.1] has quit [Quit: ZNC 1.7.4 - https://znc.in] 21:36 -!- harrigan [~harrigan@149.5.35.1] has joined #bitcoin-core-pr-reviews 23:15 -!- seven__ [~seven@BSN-77-101-62.static.siol.net] has quit [Read error: Connection reset by peer] 23:47 -!- seven_ [~seven@BSN-77-101-62.static.siol.net] has joined #bitcoin-core-pr-reviews