--- Day changed Thu May 21 2020 00:09 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds] 00:10 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 00:10 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: ZNC 1.7.5 - https://znc.in] 00:12 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-pr-reviews 00:15 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 00:20 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 258 seconds] 00:47 -!- hebasto [~hebasto@95.164.65.194] has quit [Ping timeout: 246 seconds] 00:50 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-pr-reviews 00:58 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 00:59 -!- jonatack [~jon@37.170.253.61] has joined #bitcoin-core-pr-reviews 01:53 -!- jonatack_ [~jon@37.167.18.204] has joined #bitcoin-core-pr-reviews 01:56 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Read error: Connection reset by peer] 01:57 -!- jonatack [~jon@37.170.253.61] has quit [Ping timeout: 256 seconds] 01:57 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 02:02 -!- jonatack_ [~jon@37.167.18.204] has quit [Quit: jonatack_] 02:02 -!- jonatack [~jon@37.167.18.204] has joined #bitcoin-core-pr-reviews 02:16 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 02:17 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 02:21 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 264 seconds] 02:32 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Read error: Connection reset by peer] 02:33 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 03:03 -!- Adam34Kreiger [~Adam34Kre@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:04 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 03:04 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 03:17 -!- yojoots [~justin@2600:1700:19e0:4b10:5047:d6fb:a52a:fe7f] has joined #bitcoin-core-pr-reviews 03:18 -!- Adam34Kreiger [~Adam34Kre@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds] 03:51 -!- gio98 [~gmx98@88.147.10.97] has joined #bitcoin-core-pr-reviews 04:09 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Read error: Connection reset by peer] 04:10 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 04:35 -!- gio98 [~gmx98@88.147.10.97] has quit [Ping timeout: 246 seconds] 04:53 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 04:58 -!- gio98 [~gmx98@88.147.10.97] has joined #bitcoin-core-pr-reviews 05:12 -!- gio98 [~gmx98@88.147.10.97] has quit [Remote host closed the connection] 05:42 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 06:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 06:17 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 06:17 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 06:21 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 240 seconds] 07:20 < MarcoFalke> I also have a lot of projects to work on. They are of varying difficulty, so not just for new contributors. 07:20 < MarcoFalke> One easy one by fanquake is here: https://github.com/bitcoin/bitcoin/issues/19017 07:38 < MarcoFalke> A slightly harder one: https://github.com/bitcoin/bitcoin/issues/19037 07:39 < MarcoFalke> I am happy to come up with more projects, but I don't want to spam the repo either, so let me know if the existing issues are too few or too hard or too easy. :) 07:39 < jnewbery> thanks MarcoFalke fanquake and nehan. There's plenty of work to go round for people who want to get involved! 08:05 < jnewbery> We'll get started on 19010 in just under two hours 08:06 < pinheadmz> ooh extra meetings this week for bip 157 ? 08:07 < jnewbery> That's right. The BIP 157 show must go on! 08:18 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 08:23 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 08:23 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 08:42 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews 08:58 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 09:02 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 09:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 09:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 09:23 -!- vasild_ is now known as vasild 09:38 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 264 seconds] 09:45 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews 09:52 < ryanofsky> raj_149, on your gdb questions earlier, my hacky solution for that is to set BITCOIND environment variable to path to one line script containing: 09:52 < ryanofsky> screen -S "bitcoind_${PPID}_$$" -D -m gdb "${OPT[@]}" -ex run --args "$BITCOIN_NODE" "$@" 09:53 < ryanofsky> actually that should say: 09:53 < ryanofsky> screen -S "bitcoind_${PPID}_$$" -D -m gdb -ex run --args /path/to/bitcoind "$@" 09:53 < ryanofsky> than i can attach to the screen sessions in other terminals with "screen -d -r" 09:55 < fjahr> jnewbery: FYI #19010 is not linked in #18876 yet 09:57 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 10:00 < jnewbery> #startmeeting 10:00 < jnewbery> hi! 10:00 < theStack> hi! 10:00 < jkczyz> hi 10:00 < troygiorshev> hi 10:00 < jnewbery> fjahr: Thanks! I've updated #18876 10:00 < fjahr> hi 10:00 < michaelfolkson> hi 10:01 < jnewbery> Notes/questions: https://bitcoincore.reviews/19010.html 10:01 < jnewbery> who had a chance to review the PR? (y/n) 10:01 < troygiorshev> n 10:01 < jkczyz> y 10:01 < fjahr> n 10:01 < theStack> y 10:02 < michaelfolkson> 0.5y 10:02 < jnewbery> Let's get into the questions. What happens if the getcfheaders message is malformed and we’re not able to deserialize it? 10:03 < theStack> concluding from my log, CDataStream::read() seems to throw an exception 10:04 < michaelfolkson> I didn't do this. But what was the best approach here to malform it? Randomly tweak it or deliberately construct a message that didn't follow the definition? 10:04 < theStack> [msghand] ProcessMessages(getcfheaders, 11 bytes): Exception 'CDataStream::read(): end of data: iostream error' (NSt8ios_base7failureB5cxx11E) caught 10:04 < jnewbery> theStack: exactly right. The deserialization is here: https://github.com/jnewbery/bitcoin/blob/befc63d5b0937ca24fd48ed2580349740b87b0ec/src/net_processing.cpp#L2061 10:05 < theStack> michaelfolkson: i just modified the method msg_getcfheaders.serialize() in test_framework/messages.py to create some garbage data 10:05 < michaelfolkson> theStack: Ah nice, makes sense 10:05 < jnewbery> but just like all messages being deserialized, error handling is done in the ProcessMessages() try-except catch: https://github.com/jnewbery/bitcoin/blob/befc63d5b0937ca24fd48ed2580349740b87b0ec/src/net_processing.cpp#L3611 10:06 < jnewbery> We don't need to add custom deserialization error handling for new message types 10:07 < jnewbery> Next question: What changes do we need to make to the ProcessGetCFCheckPt() function in this PR? Why? 10:09 < theStack> were there ever any discussions among bitcoin core devs about whether to use exceptions in general? there seem to be very divided views about that in general... same say they are evil because they basically behave like goto/longjmp, and some languages like golang don't even include them (sorry for slight off-topic :)) 10:10 < jkczyz> Adding stop_hash and max_height_dif params to the PrepareBlockFilterRequest call 10:10 < jnewbery> theStack: not off-topic. It's a good question! 10:10 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 10:11 < theStack> PrepareBlockFilterRequst was extended to test the preconditions more detailled, by also checking the allowed block range 10:12 < jnewbery> My opinion: using try-except for control flow is to be discouraged (since like you say, it's basically a goto). I'd argue that the code here is doing that: https://github.com/bitcoin/bitcoin/blob/fed1a9043fdf802c7cf7eab1c8aab25ca1c90e8d/src/bitcoin-cli.cpp#L503-L531 10:12 < jnewbery> if it's to handle errors from input that you don't control (as is the case in ProcessMessage()), then it makes sense 10:13 < theStack> jnewbery: sounds reasonable. in this case it's definitely a good thing that a deserialization return code doesn't need to be checked every time 10:14 < jnewbery> jkczyz: correct, although I see you have a suggestion for how to improve that here: https://github.com/bitcoin/bitcoin/pull/19010#discussion_r428737628 10:15 < jnewbery> Next question: What data is the LookupFilterHashRange() function returning? Why don’t we just return the block headers to the peer? 10:16 < theStack> jnewbery: i think this is supposed to be "filter headers" in the second question? (i submitted a PR shortly before the start of the meeting) 10:17 < theStack> the idea is that only the one filter header is part of the cfheaders response, the rest are filter _hashes_, and the headers can be computed on the client-side from that information 10:18 < jnewbery> theStack: you're right. I mean filter headers. 10:18 < jkczyz> which allows them to verify they are linked correctly 10:18 < theStack> jkczyz: +1 10:19 < jnewbery> jkczyz: exactly 10:19 < jnewbery> meaning you can fetch the headers trustlessly if you have the checkpts 10:20 < jnewbery> jkzyz: I don't know if you had anything to say about error handling based on your comment here: https://github.com/bitcoin/bitcoin/pull/16202#issuecomment-535152710 10:21 < jnewbery> ok, final question. How is the new functionality tested? Should any other tests be added? 10:22 < jkczyz> jnewbery: ah, error handling in relation to PrepareBlockFilterRequest? Or the exception handling discussion? 10:23 < jnewbery> the exception handling discussion (or any other wisdom you want to share with us) 10:24 < fjahr> basically the test does what the client should do as described above, it asks for cfheaders and then validates the hashes it receives by computing that it ends up at the right header 10:25 < jkczyz> I came from a world where C++ exception handling was discourage / outright banned. I tend to agree with the reasons behind that. I've come to like variant types where the return value is either the result or an error. Then you never have uninitialized or partially initialized objects around 10:25 < jkczyz> Rust has a Result enum type for this. I believe newer version of C++ have something similar 10:26 < jnewbery> yeah, that comment struck me as quite rust-ish 10:26 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 10:26 < michaelfolkson> There's no test that the node doesn't respond to getcfheaders with an unsupported filter type 10:26 < theStack> some languages go the way of returning two values, one for the actual result and one for an error code (i think golang also does this) 10:27 < michaelfolkson> That was outlined in the BIP 10:28 < fjahr> theStack: I think that's more of a style pattern? I mean you can write code this way in any language. 10:29 < jkczyz> jnewbery: Wrote the comment before I learned Rust but happy to see the idiom is prevalent in that world :) 10:29 < michaelfolkson> There is only one filter type currently though right? 10:31 < jnewbery> michaelfolkson: there's already a test that requesting a getcfcheckpt with an invalid filter type fails: https://github.com/bitcoin/bitcoin/pull/19010/files#diff-7cb56395a1bd1037534080986f33bd9dR158 10:31 < theStack> fjahr: yes, you are right. let's say then some languages propose this style pattern in their guidelines _and_ also provide the syntactic sugar for it (to not need an out-parameter, for example), more than others :) 10:31 < jnewbery> jkczyz commented that our behaviour regarding invalid requests is different from the BIP: https://github.com/bitcoin/bitcoin/pull/19010#pullrequestreview-416266764 10:32 < theStack> i think one of the most ugliest methods of error handling is global variables, like errno in the C standard library 10:33 < fjahr> I guess there could be a test that the client is disconnected if it requests invalid or too many filter headers 10:33 < jnewbery> michaelfolkson: yes, currently only one filter type. BIP 158 initially defined two filter types, but that was reduced to just basic filter types 10:33 < jnewbery> fjahr: seems reasonable 10:34 < michaelfolkson> Thanks jnewbery. What was the motivation for the second (now ditched) filter type? 10:35 < jkczyz> theStack: I soured on out params once I saw the result type idiom. Out params seem to encourage uninitialized objects and null ptrs 10:35 < jnewbery> michaelfolkson: I'm not sure. I didn't follow early discussion of BIP 158 very closely 10:35 < michaelfolkson> I know Pieter said something about needing a soft fork to make this more trust minimized. Maybe it was related to that 10:36 < jnewbery> jkczyz: when you say newer C++ has a Result enum type, do you know where I could find out more? 10:37 < jnewbery> jkczyz: maybe this: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4015.pdf ? 10:38 < sipa> michaelfolkson: i argued against the other filter because i thought it was useless 10:39 < michaelfolkson> Ok thanks sipa 10:40 < fjahr> michaelfolkson: https://github.com/bitcoin/bips/commit/4a85759f0229450f4a63b9404dfe8e8c10bdc92e#diff-367f1ff45d7efb5c6774e4112cd17489 10:40 < jkczyz> jnewbery: Looks like it from a brief glance though I was thinking of std::variant 10:40 < jkczyz> https://en.cppreference.com/w/cpp/utility/variant 10:40 < theStack> jnewbery: i also couldn't find much about this idiom, at least there seems to be a wiki article: https://en.m.wikipedia.org/wiki/Result_type 10:40 < sipa> haskell has an (actual data or error string) type 10:40 < sipa> iirc 10:41 < sipa> variant looks like a crazy hammer to achieve that 10:41 < michaelfolkson> Re the cfheaders cache size being big enough until 2047. I'm assuming this is a direct trade-off with OOM concerns. Could make it a bit bigger but then you are also raising OOM concerns 10:42 < jnewbery> unfortunately discussion about basic and extended filters was before the optech newsletter, so you'll just need to go back to the primary source material! 10:42 < michaelfolkson> Where are the Optech minus versions?! 10:43 < jnewbery> the paper I linked to talks about Haskell monads 10:43 < theStack> michaelfolkson: i think the OOM concerns were primarily about it being unlimited 10:43 < sipa> the extended filter was including all data elements pushed in scriptSigs i believe, which i think was a huge mistake in bip37 10:43 < sipa> or sPKs, i don't remember 10:44 < michaelfolkson> So could bump it theStack? Not a big deal but might as well push it out as far as possible if no downsides? 10:44 < jnewbery> This might be an interesting talk if anyone's interested in error handling: https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C 10:44 < fjahr> The extended filter contains extra data that is meant to enable applications 10:44 < fjahr> with more advanced smart contracts. An extended filter MUST contain exactly the 10:44 < fjahr> following items for each transaction in a block ''except the coinbase'': 10:44 < fjahr> * Each item within the witness stack of each input (if the input has a witness) 10:44 < fjahr> * Each data push in the scriptSig of each input 10:44 < jnewbery> (I haven't watched it, but it looks interesting) 10:45 < fjahr> (the removed part of BIP158 on extended filter type) 10:45 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 10:45 < theStack> sipa: putting all scriptSigs in a filter sounds crazy... would there ever be any use to match signatures? 10:46 < theStack> michaelfolkson: in my opinion it could be bumped, the memory usage is neglictible, whether it is 2000 or e.g. 4000... 10:46 < jkczyz> sipa: Not sure if you were around when something like this became widespread: https://github.com/protocolbuffers/protobuf/blob/master/src/google/protobuf/stubs/statusor.h 10:47 < sipa> jkczyz: i can't remember seeing that 10:47 < sipa> theStack: the idea was presumably that it allows matching for the full pubkey 10:48 < jnewbery> we've covered all the questions from https://bitcoincore.reviews/19010.html. Any final thoughts/questions before we wrap up? 10:50 < michaelfolkson> One final one. I know we are going through these PRs pretty quickly week by week. Do they need longer time to be reviewed? Or are they pretty much ready to all be merged? 10:50 < theStack> sipa: yes matching only the public key part of scriptSig data sounds reasonable... the signatures themselves not i think (don't know though how easy it is to distinguish) 10:51 < michaelfolkson> There should be a few weeks on the first one, a few weeks on the second one etc etc? 10:51 < jnewbery> michaelfolkson: they're ready to be merged once they've been reviewed and the maintainers consider them safe to merge. 10:51 < sipa> theStack: imho the only thing you should ever care about is the entire sPK as a whole 10:53 < jnewbery> This code has been PR'ed since July: https://github.com/bitcoin/bitcoin/pull/16442 so leaving the PR open for additional weeks doesn't seem to give any benefit 10:53 < jnewbery> (and just means that there may be conflicts that require rebase and rereview) 10:54 < jnewbery> The next PR in the sequence is "Serve cfilters requests", which is pretty much more of the same, so I suggest we don't do a review club on that and reconvene when "Signal NODE_COMPACT_FILTERS support" is open. 10:55 < theStack> michaelfolkson: concerns about too quick merging on the first BIP 157 PR were expressed, see last two comments on #18877 10:55 < michaelfolkson> Makes sense. Doesn't seem applicable here but generally there is a trade-off of waiting for more reviews versus getting the merging over with. 10:56 < jnewbery> michaelfolkson: it's down to the maintainer's judgement. If they think it's received enough reviews, then they'll merge it 10:56 < fjahr> I also found it a bit unusual that there were merge target date. On the other hand I agree, the code has been out there for a long time, just in different commits 10:56 < jnewbery> There's also nothing to stop people from reviewing a PR after it's been merged. 10:57 < michaelfolkson> Not asking because I'm critical, just asking to understand the thought process better ;) 10:57 < michaelfolkson> But thanks 10:57 < sipa> i also find it strange to have a merge target date 10:58 < jnewbery> I put a target date to hold myself accountable to make progress. I'm trying to turn around all review comments on these PRs in less than 24 hours. 10:59 < michaelfolkson> I suppose this set of PRs has a unique history of being held up for years due to a couple of Concept NACKs too. If the code has been sitting there for all that time... 11:00 < jnewbery> It seems like a monumental waste of effort to have a PR open for 9 months where review happens, there's some delay before the author responds, the reviewer gets bored, the PR needs to be rebased, etc 11:00 < michaelfolkson> Yup 11:01 < theStack> sipa: hmm if you only put sPK data in a block filter you couldn't detect if a block spent an utxo of your interest, or did you mean something different? 11:01 < jnewbery> I hope it's obvious that I'm not proposing that these things get merged on those dates if there hasn't been enough review 11:02 < sipa> theStack: BIP158 includes the sPK of UTXOs when they're created *and* when they're spent 11:02 < fjahr> jnewbery, Bitcoin Scrum Master :p 11:02 < michaelfolkson> Yeah that was clear to me jnewbery 11:03 < theStack> sipa: ah, that makes sense then 11:03 < jnewbery> jfahr: haha. I'll pass on that title if you don't mind 11:03 < fjahr> ok :D 11:04 < jnewbery> alright that's time. Thanks everyone! 11:05 < jnewbery> #endmeeting 11:05 < fjahr> Thanks! 11:05 < theStack> so far i didn't have the impression that something got merged without a good amount of ACKs -- but i guess it's always a good thing if people stay watchful 11:05 < theStack> thanks! 11:05 < michaelfolkson> Thanks. Great work on progressing these jnewbery 11:05 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 11:05 < jkczyz> thanks jnewbery 11:08 < jnewbery> michaelfolkson: I don't think it's true that this was 'held up for years by a couple of concept NACKs'. There were no concept NACKs on the original PR: https://github.com/bitcoin/bitcoin/pull/16442 11:08 < jnewbery> (until a couple of weeks ago when I rebased it) 11:10 < michaelfolkson> Or general understanding that there was some limited opposition at a conceptual level? 11:10 < michaelfolkson> PRs languish due to lack of interest or opposition right? It didn't seem like the former to me but I could be wrong 11:13 < jnewbery> Certainly there's been disagreement, but the opposition to it has changed over time. Luke originally seemed to be fine with adding BIP 157 support behind a flag: https://github.com/bitcoin/bitcoin/pull/16442#issuecomment-522805991 11:17 < michaelfolkson> Yeah interesting. I don't envy the maintainers. We had a Socratic with Jeremy Rubin on CTV and it seems like the design for that proposal has benefitted from the perceived opposition over time 11:18 < michaelfolkson> Seems like a much stronger proposal now than if it had been rushed through years ago. But knowing when to delay or oppose versus supporting it being merged seems like a fiendish responsibility 11:19 < michaelfolkson> Above my pay grade :) 11:19 < theStack> my assumption is that the potential for opposition or controversy would be way larger if it was enabled by default 11:22 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 240 seconds] 11:43 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:59 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 12:01 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 12:15 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:17 -!- jonatack_ [~jon@184.75.221.203] has joined #bitcoin-core-pr-reviews 12:18 -!- jonatack [~jon@37.167.18.204] has quit [Ping timeout: 256 seconds] 12:20 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 265 seconds] 12:23 -!- jonatack_ [~jon@184.75.221.203] has quit [Quit: jonatack_] 12:23 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 12:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 12:36 -!- seven_ [~seven@2a00:ee2:410c:1300:715b:e62c:17fb:7fec] has joined #bitcoin-core-pr-reviews 12:38 -!- seven_ [~seven@2a00:ee2:410c:1300:715b:e62c:17fb:7fec] has quit [Remote host closed the connection] 12:38 -!- seven_ [~seven@2a00:ee2:410c:1300:715b:e62c:17fb:7fec] has joined #bitcoin-core-pr-reviews 13:46 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 13:52 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 14:09 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 14:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 14:12 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds] 14:35 -!- slivera [~slivera@116.206.228.204] has joined #bitcoin-core-pr-reviews 14:40 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds] 14:43 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 15:05 -!- waxwing [~waxwing@unaffiliated/waxwing] has quit [Ping timeout: 246 seconds] 15:11 -!- waxwing [~waxwing@193.29.57.116] has joined #bitcoin-core-pr-reviews 15:16 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 15:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 15:17 -!- waxwing [~waxwing@193.29.57.116] has quit [Changing host] 15:17 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-pr-reviews 15:31 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: Lost terminal] 15:33 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 16:02 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Read error: Connection reset by peer] 16:46 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 19:01 -!- seven_ [~seven@2a00:ee2:410c:1300:715b:e62c:17fb:7fec] has quit [Remote host closed the connection] 19:01 -!- seven_ [~seven@2a00:ee2:410c:1300:715b:e62c:17fb:7fec] has joined #bitcoin-core-pr-reviews 20:50 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 264 seconds] 21:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 21:24 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 21:24 -!- vasild_ is now known as vasild 21:30 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 21:33 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds] 22:00 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Ping timeout: 258 seconds] 22:00 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 22:06 -!- soju [uid403160@gateway/web/irccloud.com/x-hevkxsdewzznqpza] has joined #bitcoin-core-pr-reviews 22:50 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 22:54 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 256 seconds] 23:23 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 23:24 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 23:24 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 23:45 -!- seven_ [~seven@2a00:ee2:410c:1300:715b:e62c:17fb:7fec] has quit [Read error: Connection reset by peer] 23:46 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews