--- Day changed Wed May 20 2020 00:17 < raj_149> Is there any special meaning of "cs" is mutex locks? like cs_main, eyc. Or its just a convention? 00:17 < raj_149> *in, *etc 00:18 < sipa> critical section 00:19 < sipa> and it's just a convention to name mutexes that way 00:19 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Read error: Connection reset by peer] 00:19 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 00:49 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 00:54 < raj_149> thanks. 01:47 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 01:49 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 02:41 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 02:45 -!- gleb [~gleb@cpe-67-244-100-77.nyc.res.rr.com] has quit [Ping timeout: 260 seconds] 03:05 -!- Terrell71Bernhar [~Terrell71@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 03:10 -!- Terrell71Bernhar [~Terrell71@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 260 seconds] 04:17 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 04:19 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 04:20 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 04:30 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 04:30 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 04:35 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 04:38 < raj_149> I was reviewing pull/15206 scheduled for review club today. The test makes node[0] send a bogus message to P2PDtatStrore() and waits to see if it gets disconnected. I want to look inside the disconnection process in details and want to catch a node in action doing disconnection with gdb. but how can i do this with P2PDataStore(), its not a seperate node right? Any hint or clues? 04:53 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 05:03 < jonatack> if i understand your question, perhaps with a break point where you want to stop: import pdb; pdb.set_trace() 05:03 < jonatack> or, to launch the Python debugger on failure of a functional test, pass 05:04 < jonatack> --pdbonfailure (see the test runner help) 05:07 < jonatack> iirc, don't use --pbbonfailurenot with the test runner, but directly with the test, e.g. test/functional/wallet_basic.py --pdbonfailure 05:37 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 05:38 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 05:39 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 05:45 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 05:59 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Quit: Lost terminal] 06:20 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 06:22 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 06:27 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving] 06:28 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection] 06:28 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 06:35 -!- davterra [~dulyNoded@172.98.86.80] has joined #bitcoin-core-pr-reviews 06:59 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 07:08 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 07:26 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 08:05 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 08:17 < raj_149> Thanks jonatack . But i wanna stop inside net.cpp. Exactly like the gdb attatchment process. Where the test node will send the message and i can then step through the cpp code. Problem is, here theres no process to attach to. The test only spawns node[0], which as far as i can read, is the one sending the msg. So gdb isn't catching readData() in node[0]. 08:19 < jonatack> P2PDataStore is in test/functional/test_framework/mininode.py 08:20 < jonatack> which is why I replied about stepping through it in the functional tests 08:21 < raj_149> Okay. And all the networkhandling logic are inside mininode itself?? 08:22 < raj_149> Ok let me try this. 08:23 < jonatack> It's bedtime for me :) signing off. Have a great review club session! 08:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack] 08:24 < pinheadmz> one thing im curious to discuss about todays PR is why it was 'tabled' for over a year / why is it being looked at again now? 08:29 < raj_149> pinheadmz: -1 08:29 < raj_149> *+1. Sorry.. 08:29 < pinheadmz> haha 08:29 < pinheadmz> im back to 0 08:30 < raj_149> +2 . lets add some buffer. :D 08:34 < raj_149> Also my src dir is getting huge. 5 gigs now. Whats going on?? Is that normal? 08:34 < pinheadmz> do you download a lot of git branches and remotes? 08:36 < raj_149> I have 2. One for bitcoin/bitcoin and one for my fork. 08:37 < pinheadmz> git branch -v 08:37 < pinheadmz> huge list? 08:39 -!- davterra [~dulyNoded@172.98.86.80] has quit [Ping timeout: 260 seconds] 08:40 -!- davterra [~dulyNoded@172.98.86.80] has joined #bitcoin-core-pr-reviews 08:41 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 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:24 < jnewbery> raj_149: gdb is a pretty big hammer to be reaching for if you just want to see control flow. I'd recommend setting -`-debug=1` and looking at debug.log files (and adding additional logging if necessary) 09:25 < jnewbery> if you really do need to set breakpoints in bitcoind, https://github.com/bitcoin/bitcoin/blob/master/test/README.md#attaching-a-debugger should have all the info you need 09:26 < jnewbery> you might want to do a git garbage collection on your local repo if it's getting too big. Check https://git-scm.com/docs/git-gc 09:33 < vasild> raj_149: 5GB source directory is not normal. Mine is ~800MB and the build, in another directory is also ~800MB. 09:34 < vasild> Even if you download all PRs like described in https://github.com/bitcoin/bitcoin/blob/master/doc/productivity.md#reference-prs-easily-with-refspecs that will bloat the source directory from ~800MB to ~1.4GB. 09:36 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has joined #bitcoin-core-pr-reviews 09:37 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 09:38 < raj_149> jnewbery: i am following the gdb attatchment doc. I got the logistic sorted, but what do i attatch into when the call is going to a P2PDataStore()?? I cant log because i am not sure where to log from. Thats why i thought of gdb attatchment. 09:39 < sipa> raj_149: maybe on a more high level, what are you trying to do or figure out? 09:40 -!- lightlike [~lightlike@p200300c7ef1d8b00308ef29b5ea87d51.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:40 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 09:41 < raj_149> @sipa, ok i wanna see who is calling the readData() or how the disconnection is happening when readData() is returning -1? 09:41 < raj_149> I am not being able to trace the path from readData() return to node being disconnected. 09:41 -!- davterra [~dulyNoded@172.98.86.80] has quit [Remote host closed the connection] 09:42 -!- davterra [~dulyNoded@172.98.86.80] has joined #bitcoin-core-pr-reviews 09:44 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 09:46 < sipa> you can add LogPrintf(...) statements, if that helps 09:46 < sipa> they'll end up in the debug.log 09:47 < raj_149> Ok i will try that. On a high level can you help me see how returning -1 is resulting into node disconnection? 09:48 < troygiorshev> raj_149, readData is called by V1TransportDeserializer::Read 09:48 < troygiorshev> It's hiding in net.h 09:50 < lightlike> the rest of the path is explained in https://github.com/bitcoin/bitcoin/pull/15206#discussion_r250250631 09:51 < jnewbery> Time to put the kettle on, folks. Meeting starts in 10 minutes. 09:51 * pinheadmz cracks open a beer 09:51 < pinheadmz> "quaren-tea" 09:52 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 09:52 < andrewtoth> the meeting's at 5 o'clock somewhere 09:53 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Remote host closed the connection] 09:57 < jnewbery> 🍻 09:58 < jnewbery> The meeting is at 5pm universal time, so it's 5 o'clock _everywhere_ 09:59 < emzy> On earth... ;) 09:59 < MarcoFalke> *univers*al time 09:59 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews 10:00 < MarcoFalke> hi 10:00 < jnewbery> #startmeeing 10:00 < troygiorshev> hi 10:00 < ariard> hi 10:00 < nehan> hi 10:00 < kanzure> hi 10:00 < theStack> hi 10:00 < thomasb06> hi 10:00 < jnewbery> greetings earthlings (and other universe dwellers) 10:00 < raj_149> Hi.. 10:00 < jnewbery> Notes and questions: https://bitcoincore.reviews/15206.html 10:00 < michaelfolkson> hi 10:00 < emzy> Hi 10:00 < felixweis> hi 10:00 < jkczyz> hi 10:00 < sipa> hi 10:00 < lightlike> hi 10:01 < pinheadmz> hi 10:01 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection] 10:01 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 10:01 < jnewbery> Normal reminders: all questions are welcome! If you're confused about something, other people probably are too, so ask! No need to ask to ask, just ask! 10:01 < andrewtoth> hi 10:01 < jnewbery> who had a chance to review this week? (y/n) 10:01 -!- jake [426c61f6@cpe-66-108-97-246.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 10:01 < pinheadmz> y 10:01 < ariard> y 10:01 < raj_149> y 10:01 < felixweis> n 10:01 < MarcoFalke> y 10:01 < theStack> n 10:01 < lightlike> y 10:01 < troygiorshev> y 10:01 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has joined #bitcoin-core-pr-reviews 10:02 < vasild> Hi, n 10:02 < gimballock> Hi 10:02 < nehan> y 10:02 < andrewtoth> y 10:02 < jkczyz> y 10:02 < jnewbery> Great, anyone want to summarize the PR? Are you concept ACKs/NACKs? 10:02 < emzy> n 10:03 < pinheadmz> it moves the p2p message checksum check up earlier in the message processing prrocess 10:04 < troygiorshev> Concept ACK. Two parts: 1) Move checksum check to net layer, 2) change behavior upon check failure to disconnecting the peer, from ignoring the message 10:04 < pinheadmz> and the reviewers are trying to decide if it should ban a peer that sends a malformed message 10:04 < jonasschnelli> Hi (only partially here) 10:04 < jnewbery> troygiorshev pinheadmz: exactly. This isn't a pure refactor, it does change behaviour 10:04 < raj_149> Move hashing op into network layer. Move it from message processing to socket Handler. . 10:04 < jonasschnelli> The current behavior of the PR is not a ban 10:05 < jnewbery> we'll go into that in the next questions 10:05 < jnewbery> hi jonasschnelli! Thanks for joining us 10:05 < nehan> also changes which thread does the Finalize, I think? 10:05 < sipa> only the finalization moves 10:06 < sipa> hashing for bulk of messages was already in net 10:06 < jonasschnelli> Only the finalize operation changes... 10:06 < jonasschnelli> Though we have a lot of small messages 10:06 < jnewbery> I don't think this PR actually moves which thread does the finalize 10:06 -!- desolate [~desolate@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 10:06 < pinheadmz> yeah looked to me like originally the checksum was checked and stored in a bool but not /acted/ upon until way later 10:06 < jonasschnelli> I think it does... but can’t say for sure. It been a while 10:07 < jnewbery> When the PR was opened it did, but since then, PR16202 was merged, which moves the finalize operation into the socket handler thread 10:07 < sipa> oh, ok! 10:07 < pinheadmz> oh interesting. yeah i had a pre-game quesiton about the timing of this one 10:07 < pinheadmz> has there been a recent flood of malformed messages or something? 10:07 < pinheadmz> what rises this PR from its year of sleep? 10:07 < jonasschnelli> Oh. Thanks for that info jnewbery 10:08 < michaelfolkson> I think some of the review comments touched upon this but what are the likely reasons for sending an incorrect checksum (other than maliciousness)? 10:08 < jonasschnelli> Some BIp324 discussion 10:08 < nehan> jnewbery: oh right, that's the first sentence of the review notes 10:08 < jnewbery> pinheadmz: I just saw it was rebased recently and started receiving some review attention and thought net/net_processing separation would be interesting to talk about at review club 10:09 < jnewbery> ok, so first question. What are the benefits of handling bad checksums in the net layer instead of in net processing? 10:09 < vasild> michaelfolkson: implementation bug, memory corruption, also memory corruption at the receiving end. 10:09 < sipa> just broken network infrastructure 10:10 < vasild> we can rely on TCP to not corrupt the data? 10:10 < nehan> jnewbery: get to it sooner, use fewer resources processing bad messages 10:10 < jnewbery> (I'll be a bit loose with language and use "net layer" == "socket handler thread" and "net processing layer" == "message handler thread") 10:10 < michaelfolkson> vasild: Which could all be honest failures right? We're disconnecting for our own benefit as a node rather than because we think the incorrect checksum was sent due to maliciousness 10:11 < emzy> For network problems there is l a TCP checksum. Ok could be manipulatet bei firewall stuff. 10:11 < jnewbery> vasild: great question. TCP should take care of errors for us. So how else could header checksum be wrong? 10:11 < theStack> jnewbery: i'd say it makes generally sense to detect failures at the lowest layer possible 10:11 < vasild> I mean we can rely that TCP will detect and re-transmit corrupted data. So there is no way to get corrupted data due to a malfuctioning router in between? 10:11 < vasild> michaelfolkson: yes 10:12 < ariard> vasild: TCP does integrity check ? 10:12 < emzy> vasild: yes, normaly. 10:12 < jonasschnelli> Would firewall randomly manipulate a single message? Or constant? 10:12 < sipa> jonasschnelli: intentionally it wouldn't change anything at all 10:12 < jonasschnelli> (Sry phone typing) 10:12 < lightlike> While reviewing I wondered if the changed disconnect behavior is a consequence of a change done mostly for architectural reasons (not so easy to imitate the old behavior after moving from net_processing to net) or something desirable in itself. 10:12 < vasild> ariard: yes 10:13 < jonasschnelli> Is the firewall a hypothetical issue or did someone report / monitor that? 10:13 < emzy> jonasschnelli: you never know. there is deep packet inspection. 10:13 < sipa> but routers can reassemble TCP packets 10:13 < jnewbery> nehan theStack: in the original version of this PR, I'd agree with you. I expect there was a performance benefit from moving the finalize operation to the socket handler thread, since the message handler thread is our bottleneck. Since 16202 was merged, there isn't a performance benefit ... 10:13 < felixweis> tcp has a 16 bit checksum 10:13 < sipa> so the TCP checksum is only an point-to-point checksum, not end-to-end 10:13 < jonasschnelli> Which is relatively weak 10:13 < jnewbery> ... but I think from a architecture/layering perspective, this makes sense 10:13 < MarcoFalke> lightlike: I posted a patch that keeps the check in net_processing, so no 10:13 < ariard> right but your NAT firewall may recompute the checksum after modification IIRC 10:13 < sipa> ariard: yes 10:13 < sipa> it will 10:14 < troygiorshev> jnewbery: agreement on the architecture/layering reason 10:14 < nehan> jnewbery: what is the architecture/layering reason? 10:15 < jnewbery> anyone want to answer nehan's question about layering? 10:15 < sipa> it's ugly that the checksum checking is in net_processing, because it's a network protocol level thing 10:15 * MarcoFalke move the checksum check to the wallet. *hides 10:16 < troygiorshev> nehan: The header wraps around some data. (Just like how, say, an ethernet header wraps around some data). Ideally you do the checksums, check the header, and then hand the data to the layer above you. Then that layer doesn't have to worry about anythign 10:16 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 10:16 < sipa> in particular when facing BIP324, where the checksum because dependent on the transport used... it's strange that the network processing layer would even know which transport is used 10:16 < nehan> maybe you could share a bit about how you see hte split between net/net_processing 10:16 < nehan> net is network protocol; net_processing is more application (node) semantics? 10:17 < felixweis> stream vs message handling? 10:17 < nehan> and you consider the "header" part of the network protocol? that's application-specific, right? it's not the packet header 10:17 < troygiorshev> nehan: yes exactly 10:17 < jnewbery> nehan: exactly 10:17 < sipa> net is interaction with socket layer, and P2P transport layer 10:17 < lightlike> the PR description gives another reason: It would be desirable to implement alternative transport layer protocols such as BIP155 in net, without having to change anything in net_processing 10:17 < sipa> the P2P transport layer transports messages, which are handled by net_processing 10:18 < jnewbery> The distinction on our software is not perfect. Take a look a CNode in net.h and CNodeState in net_processing.cpp. Ideally, CNode would just be about the connection to another node and CNodeState would just be about application-level stuff (ie inventory of transactions and blocks, address gossip, etc) 10:19 < jnewbery> Greg's point here: https://github.com/bitcoin/bitcoin/pull/15206#issuecomment-460082894 is about firewalls trying to be application aware, and messing around with IP addresses inside application messages. That sometimes happens when firewalls are trying to deal with things like NAT traversal. 10:19 < sipa> nehan: i guess you'd have to see the bitcoin p2p protocol as consisting of two layers itself 10:19 < jnewbery> In a previous life I worked in telecoms, and we used to have lots of similar issues, where firewalls would mess around with IP addresses inside SIP and SDP messages and things would stop working. 10:19 < gzhao408> jnewbery When you say that "message handler thread is our bottleneck" it seems like we want to protect that thread from DoS/wasted resources. Is this a concern here/in general? 10:20 < jnewbery> gzhao408: that's a concern everywhere! 10:20 < sipa> it depends whether you're talking about honest overload or DoS attack 10:20 < gzhao408> jnewbery er sorry, I mean is it something we care /especially/ about e.g. because it's a common dos vector? 10:20 < jnewbery> but yes, here is a good example. In general, like nehan and theStack said earlier, it's best to deal with failures and bad messages as early and as low in the stack as possible. 10:21 < ariard> sipa: do we have a way to dissociate both right now ? 10:21 < lightlike> if these corruption issues can happen spuriously to otherwise good peers in some cases, I would prefer not to disconnect. 10:21 < ariard> like when downloading too much blocks become a DoS ? 10:21 < theStack> would a proper analogy for net vs. net_processing be be ethernet (layer 2) vs ip (layer 3)? the ethernet frame has a checksum, which is also checked on layer 2, and layer3 never gets to see it 10:21 < sipa> ariard: sure it can, but we have no protection against that 10:22 < jnewbery> gzhao408: probably not. This isn't a big dos concern. We always have to do the checksum calculations, so a node trying to waste our resources gains no advantage by sending a message with a bad checksum. 10:22 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 10:22 < ariard> I think there is another point by moving this from net_processing to net, it's happen in 2 different threads right now 10:22 < emzy> What about Erlay BIP 330? Will it also bettter to move the checksum out to net for that? 10:22 < felixweis> could ASMAP be used to limit upload rates per network? 10:22 < ariard> and lets say you have a single-threaded system, you may have some buffer growing quickly before switch 10:22 < troygiorshev> theStack: I think so. An interesting parellel is that just as the ethernet header contains a section saying "IP", the bitcoin header contains a sections specifying the command name 10:22 < jnewbery> theStack: I'm not sure that analogy is useful. You can point out some similarities, but I don't think it's particularly illuminating 10:22 < sipa> emzy: completely orthogonal; erlay is entirely net_processing 10:23 < ariard> felixweis: I would fear someone in your ASN wasting resources for you, like some kind of impersonation 10:24 < sipa> felixweis: the general solution to resource wasting attack is just keep track of how much resources every peer is using; if things get tight, slow down processing of the worst one 10:24 < sipa> felixweis: that's the first, and hard, step 10:24 < jnewbery> lightlike: To understand whether this is actually a concern, it'd be useful to look at real-world data. 10:24 < sipa> doing it per asmap seems like a nice optimization on top of that 10:24 < jnewbery> Has anyone grepped their debug log for "CHECKSUM ERROR"? 10:24 < sipa> felixweis: sorry, how many resources you're consuming on behalf of every peer 10:24 < sipa> jnewbery: yes 10:25 < MarcoFalke> net_processing is similar to the rpc server I guess. They both can send data structures to validation, and they both read raw bytes from a socket or so 10:25 < troygiorshev> sipa: What did you generally find? 10:25 < felixweis> ariad, sipa: interesting points! 10:25 < MarcoFalke> I found one error 10:25 < sipa> troygiorshev: only one completely broken peer, which sends bogus messages with checksum all 0 10:25 < MarcoFalke> 2020-03-03T23:14:54Z ProcessMessages(inv, 397 bytes): CHECKSUM ERROR peer=1849951 10:25 < troygiorshev> sipa: bogus message with SMBr as the type? 10:25 < sipa> indeed 10:25 < MarcoFalke> 2020-03-03T22:49:52Z receive version message: /Satoshi:0.18.0/: version 70015, blocks=620054, us=35.247.102.9:8333, peer=1849951 10:25 < sipa> or 0-byte or -1 messages 10:26 < troygiorshev> Looks like that's spam from some group advertizing their coin 10:26 < jnewbery> I found none (although I only had a couple of weeks' worth of debug logs) 10:26 < MarcoFalke> So according to the user agent, it is a Bitcoin Core node 10:26 < jonasschnelli> MarcoFalke: what does that peer does during its session... can you grep? 10:26 < MarcoFalke> Normal relay, it was an inv message 10:26 < jnewbery> sipa: how long does your debug log go back? 10:27 < sipa> only 15 days 10:27 < sipa> i have an older one though 10:28 < sipa> i don't think this means much though - people on broken network infrastructure will see checksum errors and others won't 10:28 < jnewbery> So it seems that checksum errors are very rare. 10:28 < jnewbery> Did people see Nicolas Dorier's comment here: https://github.com/bitcoin/bitcoin/pull/15206#issuecomment-460024940. Any thoughts about that? 10:29 < sipa> jnewbery: i don't think we can conclude that (i agree it's likely the case, but it's hard to know) 10:29 < emzy> can't find a "CHECKSUM ERROR" on like 5 nodes/ 10:30 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 10:30 < jnewbery> sipa: right, there's at least one cow in scotland, and one side of it appears to be brown 10:30 < sipa> ... 10:30 < nehan> jnewbery: gmaxwell's response seemed reasonable 10:30 < sipa> jnewbery: my point is that you wouldn't see problems if you're on a non-broken network 10:30 < jnewbery> (https://mathworld.wolfram.com/AtLeastOne.html) 10:30 < sipa> that doesn't mean it's not a problem for others 10:31 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 10:31 < sipa> it may be fairly common even, for users we care about, but we wouldn't know as long as we are using good networks 10:31 < sipa> (especially old home routers...) 10:31 < lightlike> emzy: all nodes with debug=net enabled? 10:31 < ariard> and there is no way to measure which nodes are on good-vs-bad network 10:31 < troygiorshev> should we try and ensure that bitcoin can be used over an unreliable transport layer? 10:32 < raj_149> I didn't find any in my node.. 10:32 < emzy> lightlike: no. 10:32 < sipa> troygiorshev: that is a better question, i think 10:32 < vasild> If I am sitting on a broken network infrastructure, checksum errors will be common for me. 10:32 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 10:32 < sipa> to what extent can be guarantee reliable operation in such cases 10:32 < lightlike> emzy: then it wouldn't appear in the logs even if it happened 10:32 < MarcoFalke> Wouldn't a bad router cause disconnects anyway because the network magic is corrupted? I mean it is less likely because the magic is short compared to the message, but still 10:32 < sipa> BIP324 would break these nodes anyway 10:32 < troygiorshev> it certainly seems, uh, romantic at least... 10:32 < ariard> troygiorshev: shilling this https://github.com/bitcoin/bitcoin/pull/18988 ;) 10:33 < emzy> lightlike: I see. I will enable it on one of my nodes. 10:33 < jnewbery> If the network infrastructure is breaking the version message, then those nodes won't be able to connect to peers 10:33 < sipa> jnewbery: agree 10:33 < troygiorshev> sipa: good point bringing up BIP324. Maybe it overrides this discussion 10:33 < sipa> further, the protocol is stateful 10:34 -!- r251d [~r251d@162-196-59-192.lightspeed.irvnca.sbcglobal.net] has joined #bitcoin-core-pr-reviews 10:34 < sipa> if something happens in the middle of say a tx response, the peer may keep waiting, and time out 10:34 < jnewbery> so there seems to be no downside to disconnecting peers that have a bad checksum in a version message (since the alternative is that they'll timeout their connection) 10:34 < troygiorshev> ariard: i love it :D 10:34 < sipa> jnewbery: why would they time out? 10:34 < jnewbery> And if the version message is the one most likely to be corrupted by the firewall (which seems likely since it contains IP addresses), then if it's uncorrupted, then there are unlikely to be problems with subsequent messages 10:35 < jonasschnelli> Good point 10:35 < jnewbery> Do we not drop a connection if we don't receive a version within a time limit? 10:35 < sipa> jnewbery: sure 10:35 < sipa> but there are cases where a checksum failure would not result in any problems at all 10:35 < jonasschnelli> MarcoFalke: is that checksum error you witnessed in a version message? 10:35 < ariard> jnewbery: can you still have a bad checksum for version message, i.e switch IP address but this IP address being valid 10:35 < ariard> for receiver 10:35 < MarcoFalke> no 10:35 < sipa> the message would just be ignored and skipped, and that'd be it 10:35 < jonasschnelli> (Or did you say in a inv) 10:35 < MarcoFalke> It was in an inv message 10:36 < jnewbery> so the peer would send us a version with a bad checksum, we'd drop it, and then we'd eventually time out the connection because we never saw a version 10:36 < troygiorshev> sipa: (Other than a single bit flip in the checksum field I assume?) 10:36 < ariard> if it's a NATed address it's routable 10:36 < sipa> jnewbery: if it's in the version message, sure 10:36 < MarcoFalke> I was connected to the node for days 10:36 < troygiorshev> jonasschnelli: that's a good point 10:37 < MarcoFalke> No, only 15 minutes :sweat-smile: 10:37 < jnewbery> sipa: right that was my point. If the version message is corrupted, then there's no downside to disconnecting 10:37 < sipa> jnewbery: agree! 10:37 < jnewbery> right, next question. Are there any other checks that should be moved from net processing into net? 10:38 < jnewbery> (feel free to continue discussing/asking questions about disconnect. I just want to make sure we have a chance to discuss all the questions before the end of the hour) 10:38 < troygiorshev> jnewbery: MarcoFalke brought up a great point in the PR that the checksum should be treated the same as the header check and netmagic. Maybe all of them should be moved to net? 10:39 < jnewbery> troygiorshev: I agree! 10:40 < MarcoFalke> I think both should live in the same place (whether that is net_processing due to historic reasons or net because we decided that is the better place) 10:41 < MarcoFalke> But splitting them up felt a bit weird 10:41 < jnewbery> MarcoFalke: I don't think it's all-or-nothing. There are plenty of examples where things live in the wrong layer because they haven't moved yet 10:42 < ariard> its far better in net IMO, its really confusing while reviewing bip324 where these values are changed by deserializer and you have to go in net_processing to understand semantic 10:42 < jonasschnelli> jnewbery: we might want to disconnect nodes on invalid netmagic (v1 only). 10:42 < pinheadmz> jnewbery how about m_valid_netmagic ? 10:42 < pinheadmz> ha 10:42 < jonasschnelli> (in the socket thread) 10:42 < pinheadmz> i was looking for something like message size etc 10:42 < troygiorshev> pinheadmz: look at m_valid_header too 10:42 < jonasschnelli> Isn't #15197 doing that? (netmagic) 10:43 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/15197 10:43 < pinheadmz> troygiorshev ah good call for some reason i saw that and thought block header, but ofc that was wrong contet 10:44 < jnewbery> jonasschnelli: ah, I hadn't seen 15197. Thanks 10:45 < MarcoFalke> Is there software that uses the net magic to seek to the next message in the stream? 10:45 < jonasschnelli> MarcoFalke: that would be super weak 10:46 < MarcoFalke> (Asking because btcinformation claimed so) 10:46 < jonasschnelli> what if those 4 bytes match a hash of something sent over the wire? 10:46 < MarcoFalke> jonasschnelli: Agree 10:46 < jonasschnelli> we can't help someone doing that 10:47 < MarcoFalke> I am asking because the meeting notes linked to btcinformation, which suggest this is good practice 10:47 < MarcoFalke> Someone should probably edit that 10:47 < troygiorshev> Is it maybe historical? 10:48 < vasild> The decision whether to disconnect from a peer from whom we receive a bad checksum maybe should be based on how many other checksum errors am I seeing from other peers. For example if I get bad checksums from 1 peer but have plenty of other healthy peers from which I never get a bad checksum, then I would disconnect from the "bad" peer. But if I am getting checksum errors every few minutes 10:48 < vasild> from e.g 80% of my peers then maybe I wouldn't be so eager to disconnect (from everybody). 10:48 < jnewbery> MarcoFalke: you've missed out a part of the sentence "used to seek to next message _when stream state is unknown._" 10:49 < jnewbery> I'm still not sure whether that's true, but it makes a bit more sense 10:49 < jonasschnelli> vasild: that would be an option. But is it worth the effort? 10:49 < vasild> dunno :) 10:49 < MarcoFalke> But why would the stream state be unknown? (We disconnect when the header can't be deserialized) 10:50 < vasild> jonasschnelli: I think definitely out of the scope of that PR, maybe not worth the effort at all. 10:50 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 10:50 < michaelfolkson> Agree vasild. The danger here is that majority of your peers are sending you bad checksums and you rotate through iterations of new peers? 10:50 < felixweis> is it known how much CPU time is spent in SHA256 in a typical bitcoin node during normal operation (not IBD)? 10:51 < nehan> vasild: hmm this makes me wonder if this changes threatmodels at all. now an attacker could corrupt all incoming headers and force me to disconnect from all nodes 10:51 < troygiorshev> nehan: this is discussed in the PR 10:51 < vasild> michaelfolkson: yes, needlessly disconnecting from good peers due to bricked network router, but you also use the same router to connect to new peers... 10:51 < nehan> but could an attacker with network control essentially do that anyway? 10:51 < sipa> nehan: that kind of attacker can already just disconnect you 10:51 < troygiorshev> nehan: yup that's it :) 10:51 < nehan> troygiorshe: ah, must have missed it. thanks! 10:51 < MarcoFalke> felixweis: Depends whether you use hardware hashing or do it in software, I guess 10:51 < jnewbery> felixweis: I'm also curious about this. Does anyone know? 10:52 < troygiorshev> felixweis: Do you mean in this checksum or SHA256 in general? 10:52 < sipa> none of the changes in this PR change anything about attack models, as far as i can tell 10:52 < emzy> There is also an attack vector. If you can insert one TCP packet into the stram with wrong checksum. Then you can disconnect all peers. Seeing from a network level attacker. 10:52 < sipa> the only question is whether disconnecting honest but broken peers is preferable 10:52 < jonasschnelli> well... there is a CVE. 10:52 < felixweis> well all i know is there's a lot of sh256 hashing going, only 2 of them are used to verify the next block header. 10:53 < michaelfolkson> The scenario where honest peers are sending you bad checksums. A dishonest node identifies this, sends you good checksums and controls all your connections 10:53 < michaelfolkson> Unlikely but possible? 10:53 < jnewbery> is the concern about bad firewalls about my local firewall or the remote peer's firewall? 10:53 < ariard> emzy: network level attacker with such capabilities can just feed invalid blocks and get ban all your peers 10:54 < ariard> jnewbery: good question, I think both 10:54 < ariard> like can you know which one is faultive ? 10:54 < sipa> felixweis: txid and merkle root computation are probably the majority 10:54 < jnewbery> if it's about the remote's firewall, then I'd expect to see CHECKSUM ERROR messages in all node's debug logs 10:54 < sipa> and p2p checksums... 10:54 < pinheadmz> jonasschnelli CVE for what ? 10:55 < jnewbery> because we'd probably connect to at least one peer with a bad firewall 10:55 < sipa> jnewbery: it could be rare 10:55 < emzy> ariard: You only have to hit the right TCP SEQ. number. That's not sp hard anymore. 10:55 < jonasschnelli> There is a publicly revealed CVE that the PR fixes... but I don't think that CVE has reasonable weight 10:55 < jnewbery> 5 minutes left! 10:55 < MarcoFalke> jonasschnelli: Pretty sure anyone can come up with a DOS vector that is more severe and does not depend on the checksum disconnect logic 10:55 < jonasschnelli> The PR focuses on layering issues and it "also fixes that CVE" 10:55 < jnewbery> If you've been shy so far, now's your chance to ask your question 10:56 < ariard> emzy: what do you mean by sp hard ? IIRC there is ban on mutated consensus data, you don't need hashrate for this 10:56 -!- davterra [~dulyNoded@172.98.86.80] has quit [Quit: Leaving] 10:57 < pinheadmz> jonasschnelli if possible id love to see the cve 10:57 < lightlike> emzy, ariard: maybe there are types of attackers who could manage to flip a bit every now and then, but cannot carefully replace whole msgs with constructed ones? Or does that make no sense? 10:57 < nehan> well, now i want to know about the CVE 10:57 < troygiorshev> +! 10:57 < troygiorshev> +1 10:57 < jonasschnelli> MarcoFalke: probably... I guess the difference on attacking the checksum is, that the attacker doesn't have to calculate a valid SHA256 hash where the victim needs to do for the validation 10:57 < ariard> jnewbery: it's a private node it may not have that much connections and not being seen that much 10:57 < emzy> ariard: sorry typo. It's not so hard to hit the right TCP sequence number. 10:57 < jonasschnelli> pinheadmz: the CVE has been publicly announced by the Bitcoin SV people... 10:57 < pinheadmz> ha! 10:57 < jonasschnelli> I'm only revealing it because its already public available on the web 10:58 < nehan> ah. it's a pretty obvious one 10:58 < pinheadmz> https://bitcoinsv.io/2019/03/01/denial-of-service-vulnerabilities-repaired-in-bitcoin-sv-version-0-1-1/ 10:59 < jonasschnelli> It is public since a year and it seems that no-one could explot it 10:59 < sipa> heh, they can just send valid double spending transactions too 10:59 < nehan> jonasschnelli: why not? 10:59 < emzy> lightlike: yes, It would make an attack more easy, if you only have to get in the TCP stream and send someting random. Insted of getting the hash right. 11:00 < jnewbery> That's time. Thanks everyone! Special thanks to jonasschnelli for dropping in. 11:00 < jonasschnelli> nehan: don't know... because its probably an inefficient attack? 11:00 < ariard> lightlike: I can't think about real-world infrastructure with this kind of capabilites, see Erebus paper for discussion on infrastructure attacker model 11:00 < jnewbery> I have a call now so I have to run. 11:00 < nehan> thanks! 11:00 < jnewbery> Reminder that we have a BIP 157 special meeting at the same time tomorrow. I'll push the notes and questions for https://github.com/bitcoin/bitcoin/pull/19010 this afternoon. 11:00 < troygiorshev> thanks jnewbery! 11:00 < jnewbery> #endmeeting 11:00 < sipa> jonasschnelli: there are dozens of ways to achieve the same outcome 11:00 < jonasschnelli> thanks, Thanks for calling me in jnewbery! 11:00 < pinheadmz> ty all! 11:00 < jonasschnelli> sipa: Yes. I think so. 11:00 < emzy> tnx everyone! 11:00 < lightlike> thanks! 11:00 < theStack> thanks! 11:00 < vasild> Thanks everyone! 11:00 < sipa> jonasschnelli: sending N bytes to cause the victim to waste N bytes of network + N bytes of hashing... 11:01 < felixweis> thanks everyone! 11:01 < pinheadmz> sipa jonasschnelli you mean just sending any type of invalid mesasge 11:01 < jonasschnelli> indeed... yeah 11:01 < thomasb06> thanks! 11:01 < thomasb06> 11:01 < pinheadmz> is as severe as bad checksum 11:01 < sipa> pinheadmz: right 11:01 < sipa> that too 11:01 < pinheadmz> i.e. a ddos where entire 4MB block is valid.... except the last tx 11:01 < nehan> pinheadz: that requires a bunch of pow 11:01 < pinheadmz> ah good point 11:01 < jonasschnelli> but for an invalid message (to pass the checksum test), the attacker needs a valid sha256 hash? 11:01 < pinheadmz> well then a TX max-size where the last sig is invalid 11:02 < MarcoFalke> jonasschnelli: Only needs to calculate once 11:02 < jonasschnelli> But I guess you can send invalid blocks to make the victim hash-check that 11:02 < nehan> don't nodes drop peers that send a lot of invalid messages/ 11:02 < jonasschnelli> MarcoFalke: yeah. We don't ignore dups 11:02 < jonasschnelli> I guess that CVE is total bullshit 11:02 < MarcoFalke> right 11:02 < pinheadmz> even if its not severe, I do appreciate that altcoins look at the code from a different perspective and have an opportunity to contribute back to bitcoin 11:03 < jonasschnelli> However, the optimization in layering (checksum belong to message transport and not to message processing) is real 11:03 < jonasschnelli> I guess the SV people where happy they could create some CVE at all. :) 11:03 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 11:04 < raj_149> Curious on estimate of performance optimization by this layering. 11:05 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 11:05 < jonasschnelli> raj_149: near to zero probably 11:06 < emzy> Again. I think the checksum prevents that an attacker could inject just one packet into the TCP stream to ban a node. I'ts far to easy to spoof the IP address of a peer and flood with TCP packets (random SEQ. number) the target node. 11:07 < emzy> Would be better to just dissconnet the node not ban it. 11:08 < sipa> who says anything about banning? 11:08 < raj_149> Are we also banning the node along with disconnection? 11:08 < sipa> no 11:08 < raj_149> Ya. Right. 11:08 < emzy> I think I got it wrong. It is only disconnect. 11:08 < emzy> Sorry, that's fine then. 11:10 < raj_149> Also is it possible to apply some kind of heuristics to assertain resource draining intention from a node? May be that way we can safeguard against disconecting honest nodes just because of bad transport? 11:11 < sipa> raj_149: that's hard, as it's probably a cat and mouse game 11:11 < sipa> there are certainly some behaviours that are easily detectable, but if someone really wants to exploit things, there are dozens of ways 11:12 < sipa> i believe the real solution is just keeping track of resources used on behalf of every peer, and slow down/disconnect the worst offenders if you run low 11:12 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has left #bitcoin-core-pr-reviews ["ERC Version 5.3 (IRC client for Emacs)"] 11:12 < desolate> raj_149 does the heuristic determine how much resources the attack is draining on the heuristic function? :P 11:12 < sipa> with perhaps exceptions like giving you a valid block 11:13 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 11:16 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] 11:18 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 11:20 < desolate> I second sipa's KISS approach when receiving incompatible data: "turtle" strategy rather than attempting to build a highly optimized, hopefully omnipotent strategy 11:21 -!- gzhao408 [49fcfb03@c-73-252-251-3.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 11:23 -!- jake [426c61f6@cpe-66-108-97-246.nyc.res.rr.com] has quit [Ping timeout: 245 seconds] 11:24 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 11:24 -!- gimballock [b8a4b1b9@d-184-164-177-185.fl.cpe.atlanticbb.net] has quit [Remote host closed the connection] 11:33 -!- desolate [~desolate@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: desolate] 11:38 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 11:45 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 272 seconds] 11:46 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 11:51 < raj_149> It seems in socketHandler() any kind of read failure will result into peer disconnection. Is that correct understanding? 11:54 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 11:56 < sipa> a read failure means the socket is closed 11:56 < sipa> or otherwise failed anyway 11:57 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 11:58 -!- mango [~mango@158.170.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews 11:59 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 260 seconds] 12:02 < jnewbery> logs for today's meeting and notes for tomorrow's on PR 19010 have been pushed to the website: https://bitcoincore.reviews/ 12:06 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: Lost terminal] 12:12 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 12:14 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 12:17 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!] 12:17 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 12:20 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 265 seconds] 12:26 -!- r251d [~r251d@162-196-59-192.lightspeed.irvnca.sbcglobal.net] has quit [Quit: r251d] 12:27 -!- mango [~mango@158.170.24.136.in-addr.arpa] has quit [Quit: Textual IRC Client: www.textualapp.com] 12:44 < jb55> experimenting with linux userspace tracepoints for core. nice thing about this is that you can hook into kernel level traces at the same time for low level perf debugging. and you can share awk-like bpftrace scripts instead of making invasive changes to core: https://jb55.com/s/bitcoin-lock-contention.mp4 12:53 -!- jnewbery [~john@cpe-74-72-241-241.nyc.res.rr.com] has quit [Ping timeout: 260 seconds] 12:55 -!- jnewbery [~john@cpe-74-72-241-241.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 13:13 -!- lightlike [~lightlike@p200300c7ef1d8b00308ef29b5ea87d51.dip0.t-ipconnect.de] has quit [Quit: Leaving] 13:22 -!- vindard [~vindard@190.83.165.233] has quit [Read error: Connection reset by peer] 13:24 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews 14:11 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 14:16 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 256 seconds] 14:26 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 260 seconds] 14:29 < jb55> another example, ibd bench script: https://jb55.com/s/e4a85724324329a1.txt 14:42 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 272 seconds] 14:43 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 14:43 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 14:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 14:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Client Quit] 14:49 -!- shesek [~shesek@185.3.145.28] has joined #bitcoin-core-pr-reviews 14:49 -!- shesek [~shesek@185.3.145.28] has quit [Changing host] 14:49 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 15:36 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Quit: Leaving] 15:47 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 15:48 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Client Quit] 16:00 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has joined #bitcoin-core-pr-reviews 16:05 -!- troygiorshev [~troygiors@CPEdcef09a0ed55-CM0c473d74be00.cpe.net.cable.rogers.com] has quit [Ping timeout: 256 seconds] 16:08 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has joined #bitcoin-core-pr-reviews 16:17 -!- dfmb_ [~dfmb_@unaffiliated/dfmb/x-4009105] has quit [Read error: Connection reset by peer] 16:21 < nehan> if someone in here is looking for a project, i think fanquake is looking for someone to performance test these gcc flags: https://github.com/bitcoin/bitcoin/pull/18921 18:25 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 18:26 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews 18:58 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 20:13 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has joined #bitcoin-core-pr-reviews 20:19 -!- PaulTroon [~paultroon@h-5-150-248-150.NA.cust.bahnhof.se] has quit [Ping timeout: 256 seconds] 20:31 < fanquake> Feel free to ping me if you have any Qs 21:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 21:23 -!- vasild_ is now known as vasild 21:46 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews 22:34 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews 22:52 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 22:57 -!- jonatack [~jon@213.152.162.79] has joined #bitcoin-core-pr-reviews 23:14 -!- jonatack [~jon@213.152.162.79] has quit [Ping timeout: 264 seconds] 23:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews