--- Log opened Wed Jun 08 00:00:46 2022 00:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 00:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 248 seconds] 00:08 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 00:13 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds] 00:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 00:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 260 seconds] 00:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 00:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 240 seconds] 00:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 00:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 248 seconds] 00:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 00:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 272 seconds] 00:53 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 00:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 244 seconds] 01:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 01:09 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 258 seconds] 01:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 01:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 255 seconds] 01:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 01:28 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 01:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 260 seconds] 01:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 01:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 272 seconds] 01:49 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 01:53 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 248 seconds] 02:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 02:04 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 244 seconds] 02:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 02:06 -!- Common_ [~Common@096-033-221-075.res.spectrum.com] has joined #bitcoin-core-pr-reviews 02:09 -!- Common [~Common@096-033-221-075.res.spectrum.com] has quit [Ping timeout: 258 seconds] 02:10 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 258 seconds] 02:17 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 02:21 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds] 02:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 02:32 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 240 seconds] 02:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 02:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 260 seconds] 02:52 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 244 seconds] 02:57 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 03:01 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 244 seconds] 03:03 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 03:08 -!- __nick__ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 03:08 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 246 seconds] 03:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 03:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Ping timeout: 240 seconds] 03:56 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 05:39 -!- brunoerg_ [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has joined #bitcoin-core-pr-reviews 05:41 -!- brunoerg_ [~brunoerg@2804:14d:5281:8ae2:d56e:4da1:5ebd:d43] has quit [Client Quit] 05:42 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 276 seconds] 05:50 -!- real_or_- is now known as real_or_random 06:31 -!- theStack [~theStack@95.179.145.232] has joined #bitcoin-core-pr-reviews 07:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 08:20 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 08:49 -!- newbie [~newbie@ipbcc11383.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews 08:51 -!- newbie [~newbie@ipbcc11383.dynamic.kabel-deutschland.de] has quit [Client Quit] 08:55 -!- newbiexra [~newbiexra@ipbcc11383.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews 09:00 -!- newbiexra [~newbiexra@ipbcc11383.dynamic.kabel-deutschland.de] has quit [Client Quit] 09:00 -!- newbiexra [~newbiexra@ipbcc11383.dynamic.kabel-deutschland.de] has joined #bitcoin-core-pr-reviews 09:06 -!- newbiexra [~newbiexra@ipbcc11383.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed] 09:23 -!- OliverOff [~OliverOff@189.16.122.204] has joined #bitcoin-core-pr-reviews 09:32 < OliverOff> Hi all, we're going to be reviewing a PR that's already been merged, right? 09:45 < larryruane> yes that's correct ... (it wasn't merged yet when we decided to review it) 09:50 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews 09:58 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has joined #bitcoin-core-pr-reviews 10:00 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews 10:00 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews 10:01 < larryruane> #startmeeting 10:01 < svav> Hi 10:01 < larryruane> Welcome to PR Review Club! This meeting is intended for beginners to learn about the Bitcoin Core codebase and how to review PRs. 10:01 < brunoerg> hi 10:01 < larryruane> Today we're looking at PR #22778 "net processing: Reduce resource usage for inbound block-relay-only connections" 10:02 < larryruane> Notes are here https://bitcoincore.reviews/22778 10:02 -!- Azor [~Azor@181.208.38.141] has joined #bitcoin-core-pr-reviews 10:02 < yashraj> hi 10:02 < larryruane> Please feel free to ask questions whenever you want, and don't worry about interrupting - this meeting is for learning! 10:02 < BlueMoon> Good afternoon everyone, greetings from Mexico. 10:02 < larryruane> Who had a chance to review the PR and/or look at the notes? How about a y/n from people who are here 10:02 < OliverOff> y 10:03 < svav> Looked at notes 10:03 < BlueMoon> I checked it a bit 10:03 < yashraj> y, mostly notes 10:03 < larryruane> If there are any first-time people here, please say let us know and say Hi if you'd like! 10:03 -!- b_1o1 [~b_1o1@187.202.211.10] has joined #bitcoin-core-pr-reviews 10:04 < larryruane> As you can see, this PR was merged last week, but that's okay, we can still a lot from it 10:04 < theStack> hi 10:04 < larryruane> (we decided to review this PR before it was merged) 10:05 < svav> Welcome to any newcomers. How did you hear about this meeting? 10:06 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-pr-reviews 10:06 < effexzi> Hi every1 10:07 < b_1o1> hi all 10:07 < larryruane> Hi to all! I guess we can start in, we always like to know, if you've reviewed the PR, how did you go about it? 10:08 < larryruane> Or in general, for any PR, what are your favorite tips for reviewing? 10:08 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Ping timeout: 240 seconds] 10:08 < BlueMoon> I did some reading on incoming and outgoing connections. 10:09 < larryruane> Mine personally is to checkout the branch locally, start up vscode (or just "code" on linux), which has a nice git integration, and look at the commits separately... then I also sometimes run the debugger on both one of the python tests and the node (bitcoind) 10:10 < larryruane> BlueMoon: that's good, can you tell us at a high level what's the difference between those kinds of connections? 10:10 -!- observer52 [~observer@160.sub-174-251-168.myvzw.com] has joined #bitcoin-core-pr-reviews 10:11 < yashraj> basically tried to read meeting logs and github conversations for this and related PRs. Everything's just a rabbithole for noobs 10:11 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 10:11 < BlueMoon> It seems to me that if our peer initiates the connection it is an incoming peer, if we initiate the connection the peer is an outgoing peer. 10:11 < larryruane> BlueMoon: yes exactly! 10:12 < BlueMoon> Thanks! 10:12 < larryruane> when we initiate the connection (an outgoing connection), there are multiple types, two main ones that are most important for today's PR, can anyone say what they are and what's the difference between them? 10:14 < OliverOff> one kind transmits both block data and mempool data (unconfirmed txs), the other kind transmits only block data and it's called block-relay-only connections 10:14 < svav> Types are outbound-full-relay connection and block-relay-only connection 10:15 < svav> outbound-full-relay will gossip address and transaction information, block-relay-only will not 10:15 < larryruane> yes, good, here's the full list: https://github.com/bitcoin/bitcoin/blob/master/src/net.h#L131 10:17 < larryruane> why is there such a thing as block-relay-only connections? 10:18 < svav> It is for improved security, to help prevent partition attacks 10:18 < larryruane> why was that connection type added to the software? 10:18 < larryruane> svav: yes, exactly 10:18 < svav> For network security. By not relaying transactions or addresses, these connections are harder to detect by a third party, thus helping obfuscate the network topology. 10:19 < BlueMoon> The importance of propagation speed is crucial for network decentralisation. 10:19 -!- observer52 [~observer@160.sub-174-251-168.myvzw.com] has quit [Quit: Connection closed] 10:19 < OliverOff> to make it more difficult to identify the networks topology, which could lead to privacy loss (identifying the IP that originated a transaction) and facilitate GBP attacks 10:20 < larryruane> yes, the block-relay-only connection type was added by PR 15759 (2019) https://github.com/bitcoin/bitcoin/pull/15759 10:20 < larryruane> you can see some good explanation there about why it was added 10:21 < larryruane> notice that block-relay-only applies only to outbound connections, not inbound 10:21 < theStack> an interesting fact is that there is also a "blocksonly" mode for reducing traffic by turning off transaction relay completely (option -blocksonly); this can be confusing due to the similar naming to "block-relay-only"... at least it was for me :) 10:22 < OliverOff> s/GBP/BGP (Border Gateway Protocoßl) 10:23 < larryruane> theStack: yes excellent, i was just going to mention that next! setting up a block-relay-only peer affects only how we interact with that peer, whereas `blocksonly=` (configuration option) affects our behavior with all our peers 10:23 < larryruane> do we still have a mempool if we are `blocksonly`? 10:25 < theStack> i would guess yes for submitting transactions via wallet or RPC calls? of course it would be pretty empty most of the time 10:25 < OliverOff> thought so too but what's the point of submitting if you're not transmitting this tx to the rest of the network? 10:25 < OliverOff> only if you're mining yourself 10:26 < larryruane> yes I think that's right, maybe the node can use fewer resources (less memory etc.) 10:27 < larryruane> you can still initiate a transaction and relay it out to the network, but it's bad for privacy because everyone will know that you initiated it 10:28 < larryruane> Okay feel free to continue on that topic, but question 2, what's a bloom filter (very basically)? 10:29 < theStack> (for those interested, this is a thread in the bitcointalk board where gmaxwell gives a bit background and bandwidth savings results for the back then newly introduced -blocksonly mode: https://bitcointalk.org/index.php?topic=1377345.0) 10:29 < larryruane> theStack: that's great, thanks! 10:29 < yashraj> theStack: thanks 10:30 < BlueMoon> Thanks, this is very interesting :) 10:30 < svav> A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. 10:30 < OliverOff> this interactive learning material was personally helpful in (re)learning about bloom filters: https://llimllib.github.io/bloomfilter-tutorial/ 10:30 < svav> Bloom filters can have false positives but not false negatives. 10:30 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed] 10:31 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has joined #bitcoin-core-pr-reviews 10:31 < yashraj> OliverOff: thanks! 10:31 < larryruane> svav: OliverOff: thanks, very helpful explanation and link 10:31 < BlueMoon> Thanks for the link, very nice. 10:33 < larryruane> so it's a way of compactly storing a set of values, but you can only test if a value is present (you can't iterate a bloom filter like a map or a vector), and you can get false positives (the filter can say an item is there when it actually isn't) 10:33 < b_1o1> OliverOff: thanks! 10:33 < larryruane> Ok so briefly, how are bloom filters used in the bitcoin P2P protocol? (just briefly) 10:34 < OliverOff> nodes tell you a filter and ask you to only relay transactions that pass that bloom filter 10:35 < sipa> Only when BIP37 is enabled, which isn't the case for most nodes. 10:35 < BlueMoon> <3 10:35 < sipa> There are probably more than 3 nodes with it enabled 10:35 < sipa> ;) 10:36 < larryruane> OliverOff: good! sipa: yes, that's question 6, why do most nodes not support this bloom filtering service (that is they don't set the `NODE_BLOOM` service bit in the version message they send to their peers)? 10:37 < sipa> Apologies for skipping ahead! 10:37 < larryruane> oh no that's fine we've already been doing that! 10:40 < larryruane> bloom filtering (offering that service) used to be enabled by default (you always had the option of disabling it), but it was changed to default-disabled here: https://github.com/bitcoin/bitcoin/pull/16152 10:41 < larryruane> that PR's description indicates the reason .. but it still wasn't entirely clear to me, until I found this: https://blog.lopp.net/could-spv-support-a-billion-bitcoin-users-sizing-up-a-scaling-claim/ 10:42 < sipa> We use bloom filters for a lot of things in the p2p code and validation. BIP37 is the only place where it's specifically part of the protocol, in order to perform server-side filtering. 10:42 < larryruane> search on the page for "SPV server scaling" 10:43 < yashraj> looks like bloom filters are used in a bunch of places based on PR 15759 meeting log? 10:43 < BlueMoon> Thank you very much, I am learning a lot. 10:43 < sipa> But "disabling Bloom filters" is maybe a bit confusing, as it's just about disabling server-side filtering, not all other places where Bloom filters are used. 10:43 < sipa> LevelDB (which we use for the utxo database) uses Bloom filters internally, for example. 10:43 < larryruane> sipa: thanks, isn't there a newer data structure that's similar to but an improvement on bloom filters? I can't recall its name (if there is one) 10:43 < larryruane> sipa: oh I see, thanks 10:44 < sipa> Cuckoo filters! 10:44 < larryruane> oh that's right, thanks 10:45 < sipa> BIP158 (client-side filtering) uses yet another datastructure (golomb filters), which are smaller than Bloom filters and cuckoo filters, but don't support efficient updating after creation. 10:46 < larryruane> Thanks, I've learned a lot. Okay so finally we're ready to consider question 4, this PR reduces resource usage, which resource and roughly how much? 10:46 < OliverOff> is BIP158 going to supersede BIP37 with regards to SPV? 10:46 < theStack> it seems that the "pure" bloom filter CBloomFilter is only used for BIP37, whereas the rolling bloom filter CRollingBloomFilter is used at more places (if i interpreted my "git grep" results correctly :)) 10:47 < sipa> OliverOff: Yes and no - they're very different designs. BIP157/BIP158 can be used for some things BIP37 was, but not all, and the other way around. 10:47 < BlueMoon> I found this https://blog.trezor.io/bip158-compact-block-filters-9b813b07a878 10:47 < larryruane> and what is CRollingBloomFilter? Is it one that supports removing items? (that's just a guess) 10:48 -!- observer77 [~observer@160.sub-174-251-168.myvzw.com] has joined #bitcoin-core-pr-reviews 10:48 < sipa> No, it's a Bloom filter from which elements expire. 10:48 < OliverOff> and what was the DoS problem with BIP37 that warranted it to be disabled by default? was it sending an avalanche of `filterload` and `filterclear` messages? 10:48 < sipa> You can't explicitly delete anything from it, but they only guarantee that inserted elements remain in it for a number of insertions that follow. 10:49 < larryruane> OliverOff: No, the best explanation I've seen is the article by Lopp that I linked to above 10:49 < sipa> OliverOff: The problem with BIP37 is that it causes disk and CPU load that is not proportional to the bandwidth. 10:49 < OliverOff> sipa: @larr 10:49 < sipa> BIP37 is also a privacy nightmare. 10:49 < OliverOff> thanks 10:50 < sipa> OliverOff: You can send a filter that matches nothing, and then ask for all blocks in the chain. Now the attacker gets only tiny messages (empty filtered blocks), while the victim is reading through the entire blockchain and processing every tx in it. 10:50 < sipa> Ideally, we want some cost to the attacker (such as bandwidth) that is proportional to how much work they're causing the victim to perform. 10:51 < theStack> BIP37 is, if at all, used mostly in local networks nowadays i would guess, e.g. if you want to connect a wallet to your own node? 10:51 < sipa> BIP37 was made optional in BIP111. 10:52 < larryruane> To maybe help answer question 4, let's look at question 5, what is the `TxRelay` object (struct), and why is it separate from the `Peer` object (also a struct)? 10:52 < yashraj> About Q4: we save on resource usage by not initialising TxRelay if invound peer has indicated they will never request transaction relay. 10:53 < svav> Re Q4 we are saving memory 10:53 < larryruane> yashraj: svav: yes exactly, and why is it helpful to not create an instance of `TxRelay`? 10:53 < larryruane> (if we don't need to, obviously :) ) 10:54 < BlueMoon> <3 10:54 < svav> TxRelay is held in memory 10:54 < sipa> Peer is also held in memory. 10:55 < svav> It is a case of not creating a TxRelay resource for a particular incoming node, when we know it will never be required 10:57 -!- observer77 [~observer@160.sub-174-251-168.myvzw.com] has quit [Ping timeout: 256 seconds] 10:57 < yashraj> do we have to create a TxRelay for every inbound peer separately and if so why? sorry if this is completely wrong I'm (very) new. 10:58 < svav> if we have not offered NODE_BLOOM to the peer and it has set fRelay to 0, then we know that it will never request transaction announcements, and that we can save resources by not initializing the TxRelay data structure for that incoming node 10:58 < larryruane> svav: yes, `TxRelay` contains only state that's needed for relaying transactions (outward) to a particular peer ... so if we never need to send transactions to this peer, then there's no reason to allocate one of these for this peer 10:59 < svav> yashraj the reason for this PR is that there are some circumstances that we know a TXRelay will never be needed for a particular incoming node, and therefore we save memory resources in our node by not creating it - I think! 10:59 < larryruane> yashraj: yes, the `TxRelay` is per-peer (whether inbound or outbound), because it contains stuff like: which transactions does this peer already know about? 11:00 -!- mdr0id [~mdr0id@c-76-115-176-197.hsd1.or.comcast.net] has joined #bitcoin-core-pr-reviews 11:00 < larryruane> we're at time, feel free to continue the discussion! Thanks to all for attending!! 11:00 < larryruane> #endmeeting 11:00 < svav> I should say a TXRelay data structure 11:01 < yashraj> larryruane: thanks for hosting, learnt a lot. 11:01 < OliverOff> me too! thank you larryruane and sipa 11:02 < svav> Just a comment that I saw Michael Saylor complaining about the 2x Bitcoin giveaway scam videos on Twitter today 11:02 -!- OliverOff [~OliverOff@189.16.122.204] has quit [Quit: Connection closed] 11:02 < BlueMoon> Thank you for everything, I learned a lot. <3 11:02 < svav> I continue to think this is a very big problem affecting Bitcoin's image 11:02 < svav> Thanks all 11:03 < b_1o1> thanks all 11:03 < svav> Mainly because YouTube does not seems very good at tackling the scam videos 11:04 < svav> despite constant reporting by people 11:05 -!- BlueMoon [~BlueMoon@dgb3.dgbiblio.unam.mx] has quit [Quit: Connection closed] 11:08 < effexzi> Thanks every1 11:10 -!- Azor [~Azor@181.208.38.141] has quit [Quit: Connection closed] 11:22 -!- b_1o1 [~b_1o1@187.202.211.10] has quit [Quit: Connection closed] 11:26 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed] 11:34 -!- yashraj [yashraj@gateway/vpn/protonvpn/yashraj] has quit [] 12:21 -!- __nick__ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.] 12:23 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 12:23 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit] 12:25 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews 12:26 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 13:04 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 240 seconds] 13:19 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity] 15:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Remote host closed the connection] 15:32 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 15:36 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 255 seconds] 15:44 -!- mdr0id [~mdr0id@c-76-115-176-197.hsd1.or.comcast.net] has quit [Quit: Connection closed] 15:46 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity] 16:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 16:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 260 seconds] 16:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 16:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 272 seconds] 17:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 17:38 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 255 seconds] 18:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 18:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 260 seconds] 18:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 18:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 258 seconds] 19:02 -!- jtrag [~jtrag@user/jtrag] has quit [Quit: Peace out <3] 19:37 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 19:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 260 seconds] 20:18 -!- Ozzie [~Ozzie@120.244.220.25] has joined #bitcoin-core-pr-reviews 20:26 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 20:29 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 20:33 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 244 seconds] 20:54 -!- jtrag [~jtrag@user/jtrag] has joined #bitcoin-core-pr-reviews 21:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 21:22 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 260 seconds] 21:24 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has quit [Remote host closed the connection] 21:25 -!- evanlinjin_ [~evanlinji@gateway/tor-sasl/evanlinjin] has joined #bitcoin-core-pr-reviews 21:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has joined #bitcoin-core-pr-reviews 21:55 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:c477:ce89:7499:43e0] has quit [Ping timeout: 240 seconds] 22:42 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 22:46 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 246 seconds] 23:36 -!- brunoerg [~brunoerg@187.183.43.40] has joined #bitcoin-core-pr-reviews 23:41 -!- brunoerg [~brunoerg@187.183.43.40] has quit [Ping timeout: 255 seconds] --- Log closed Thu Jun 09 00:00:48 2022