--- Day changed Wed Nov 18 2020 00:04 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 00:07 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 00:12 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews 00:19 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 00:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net] 00:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 01:07 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th] has quit [Ping timeout: 272 seconds] 01:31 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 01:34 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Ping timeout: 240 seconds] 01:46 -!- da39a3ee5e6b4b0d [~da39a3ee5@ppp-27-55-83-106.revip3.asianet.co.th] has joined #bitcoin-core-pr-reviews 02:03 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 272 seconds] 02:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 02:11 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 02:11 -!- vasild_ is now known as vasild 02:17 -!- da39a3ee5e6b4b0d [~da39a3ee5@ppp-27-55-83-106.revip3.asianet.co.th] has quit [Ping timeout: 256 seconds] 02:26 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews 02:42 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds] 02:46 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews 03:18 -!- Cydney36Schaden [~Cydney36S@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:18 -!- da39a3ee5e6b4b0d [~da39a3ee5@ppp-223-24-153-25.revip6.asianet.co.th] has joined #bitcoin-core-pr-reviews 03:23 -!- Cydney36Schaden [~Cydney36S@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 03:48 -!- belcher_ is now known as belcher 03:53 -!- da39a3ee5e6b4b0d [~da39a3ee5@ppp-223-24-153-25.revip6.asianet.co.th] has quit [Ping timeout: 240 seconds] 04:17 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews 04:32 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds] 04:34 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews 04:51 -!- ccdle12 [~ccdle12@gateway/tor-sasl/ccdle12] has joined #bitcoin-core-pr-reviews 04:52 -!- mol_ [~mol@unaffiliated/molly] has quit [Quit: Leaving] 05:02 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th] has quit [Ping timeout: 256 seconds] 05:25 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th] has joined #bitcoin-core-pr-reviews 05:37 -!- shesek` is now known as shesek 05:37 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 05:37 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 06:08 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 06:09 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 06:34 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection] 06:34 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-pr-reviews 06:34 -!- shesek [~shesek@164.90.217.137] has quit [Changing host] 06:34 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-pr-reviews 07:00 -!- da39a3ee5e6b4b0d [~da39a3ee5@cm-171-98-78-149.revip7.asianet.co.th] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 07:00 -!- hmrawal [~hmrawal@2401:4900:2343:7a51:44e0:77fa:74d:b0a8] has joined #bitcoin-core-pr-reviews 07:10 -!- hmrawal [~hmrawal@2401:4900:2343:7a51:44e0:77fa:74d:b0a8] has quit [Quit: Leaving] 07:28 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 07:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews 07:31 < MarcoFalke> reminder that we'll get started in about 1.5 hours 07:32 < jnewbery> I was just about to type that! 07:41 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 07:53 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews 07:58 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 272 seconds] 08:23 -!- dappdever [~dappdever@pool-100-8-184-107.nwrknj.fios.verizon.net] has joined #bitcoin-core-pr-reviews 08:49 -!- tonyfabeen [3e9d4f68@p3e9d4f68.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 08:51 -!- thomasb06 [863be68d@leat141.unice.fr] has joined #bitcoin-core-pr-reviews 08:53 -!- elle [~ellemouto@155.93.252.70] has joined #bitcoin-core-pr-reviews 08:53 -!- dhruvm [~noreply@c-73-158-59-66.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 08:58 -!- drainable [~wireless@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 08:59 -!- carlakc [uid471474@gateway/web/irccloud.com/x-wvwqarqgagwcykkp] has joined #bitcoin-core-pr-reviews 09:00 < MarcoFalke> #startmeeting 09:00 < jnewbery> hi! 09:00 < emzy> hi 09:00 < carlakc> hello! 09:00 < willcl_ark> hi 09:00 < tonyfabeen> hi 09:00 < pinheadmz> hi 09:00 < stacie> hi 09:00 < elle> hi! 09:00 < felixweis> hi 09:00 < dappdever> hi 09:00 < dhruvm> hi 09:00 -!- sergei-t [~sergei@2001:a18:0:b23::6] has joined #bitcoin-core-pr-reviews 09:00 < michaelfolkson> hi 09:00 < sergei-t> hi 09:01 -!- hmrawal [~hmrawal@2401:4900:2343:7a51:44e0:77fa:74d:b0a8] has joined #bitcoin-core-pr-reviews 09:01 < jonatack> hi 09:01 < nehan> hi 09:01 < hmrawal> hi 09:02 < MarcoFalke> Today we'll chat about peer handshake, and peer misbehavior. Reminder: Don't ask to ask, just ask your question :) 09:02 < MarcoFalke> Anyones first review club today? 09:02 < drainable> hi 09:03 < amiti> hi 09:03 < MarcoFalke> Ok, lets get started. Did you review the PRs (y/n)? 09:03 < elle> y 09:03 < dhruvm> y 09:03 < sergei-t> y 09:03 < nehan> y 09:03 < amiti> y 09:03 < felixweis> y 09:03 < carlakc> y 09:03 < stacie> y 09:03 < dappdever> y 09:03 < jnewbery> y 09:03 < MarcoFalke> nice. A lot of yes 09:03 < emzy> n 09:03 < pinheadmz> y 09:03 < jonatack> y, would like to propose peers wear a mask and avoid handshakes 09:04 < MarcoFalke> heh 09:04 < MarcoFalke> What message types can be sent/received during a handshake? Which are optional? In what order can they be sent? 09:04 < pinheadmz> 🤝 😷 09:04 < hmrawal> jonatack: :-D good one 09:04 -!- iamoperand [~iamoperan@182.64.58.201] has joined #bitcoin-core-pr-reviews 09:04 < pinheadmz> MarcoFalke VERSION and VERACK; WTXIDRELAY is optional 09:04 -!- lightlike [~lightlike@p200300c7ef15c6002880e36288c53c60.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 09:05 < sergei-t> version - (verack+version) - verack. Not sure about the order in (version + verack)... 09:05 < dhruvm> Both peers in the connection must send a VERSION and receive a VERACK before other messages are accepted. 09:05 < MarcoFalke> The handshake is done by several functions, but here is a good start to begin your search: https://github.com/bitcoin/bitcoin/blob/50e019a97a5b49caee867ec7d630fca908caed9d/src/net_processing.cpp#L2274 09:05 < sergei-t> What is wtxidrelay? 09:05 < pinheadmz> sergei-t it's new! 09:05 < carlakc> and WTXIDRELAY needs to come before verack iiuc 09:05 < hmrawal> does verack mean version acknowledged ? 09:06 < felixweis> its a new feature where nodes relay tx via wtxid instead of txid 09:06 < pinheadmz> sergei-t peers can relay transactions by their witness txid 09:06 < pinheadmz> a tx hash that includes witness data 09:06 < pinheadmz> hmrawal yup 09:06 < felixweis> the hash over the full transaction not just the base version without the segwit stuff 09:06 < MarcoFalke> Indeed, wtxidrelay is a newly introduced protocol feature 09:06 -!- iamoperand [~iamoperan@182.64.58.201] has quit [Client Quit] 09:06 < sergei-t> may be off topic, but why is wtxidrelay useful / better than regular txid relay? 09:07 < sipa> sergei-t: BIP 339 09:07 < pinheadmz> MarcoFalke pretty funny "start your search here"... link to 3,000 line function :-) 09:07 < felixweis> wtxidrelay is a marker to annouce to your peer, to negociate this ability for the connection 09:07 < MarcoFalke> pinheadmz: I wish we still had main.cpp. You could find everything in one file ;) 09:08 < felixweis> lolz 09:08 < pinheadmz> ha "yeah just check out the code here" ....main.cpp answers all your questions 09:08 < felixweis> no need to figure out how to exit vim all the time 09:08 < dhruvm> Why is wtxisrelay a message and not a service bit? 09:08 < dhruvm> wtxidrelay* 09:09 < carlakc> do SENDHEADERS and SENDCMPCT count as part of the handshake? they're optionally sent once we receive VERACK 09:09 -!- webtricks [679c329a@103.156.50.154] has joined #bitcoin-core-pr-reviews 09:09 < sipa> dhruvm: service bits are useful for feature discovery; he it's just a negotiation 09:09 < jnewbery> sergei-t dhruvm : it's probably a bit offtopic for this meeting. There's lots more information and context about wtxid relay in https://github.com/bitcoin/bitcoin/pull/18044 09:09 < dhruvm> jnewbery: thanks 09:09 < MarcoFalke> dhruvm: Good question. service bits are used when peering behavior is changed. wtxidrelay is just a toggle for tx relay and shouldn't influence peering 09:10 < jnewbery> and the issues that it solves are documented in https://github.com/bitcoin/bitcoin/issues/8279 09:10 < elle> carlakc: those are send only once handshake is complete i think. ie: after VERACK as you said 09:10 < elle> *sent 09:10 < dhruvm> MarcoFalke: i see. thanks. 09:10 < pinheadmz> also stuff like GETADDR and SENDCMPT kinda stuff 09:10 < pinheadmz> comes after handshake but is kinda part of the initial connection 09:11 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 09:11 < felixweis> you can't "wtxidrelay" it to older nodes too because you risk get disconnected (Misbehaving) 09:11 < carlakc> elle: got it, thanks! 09:11 < jonatack> dhruvm: there's even a review club for that https://bitcoincore.reviews/18044 09:11 < hmrawal> what's the order ? first Version followed by VERACK ? 09:11 < pinheadmz> hmrawal yeah VERSION-> VERACK<- VERSION<- VERACK-> I think 09:11 < sergei-t> If I receive a Version, do I first send my Version and then Verack or vice versa? Or t doesn't matter? 09:12 -!- tonyfabeen [3e9d4f68@p3e9d4f68.dip0.t-ipconnect.de] has quit [Ping timeout: 245 seconds] 09:12 < hmrawal> and that's multiple VERSION/VERACK for multiples nodes I guess 09:12 < MarcoFalke> version must be the first message sent/received 09:12 < felixweis> the connecting node sends the first message 09:13 < sipa> for a lot of behavior around initiao connection (and the p2p protocol in general, especially parts that are old), there is no clear distinction between "what is part of the protocol" and "what bitcoin core does" 09:13 < sergei-t> MarcoFalke: so it's strictly Version1 - Version2 - Verack2 - Verack1? 09:13 < sipa> as the initial protocol was simply defined by how the reference client behaved 09:13 < sipa> and what it accepted 09:13 < MarcoFalke> So who wants to answer the full question? Hint: There are more message types than version/verack 09:14 -!- anir [40bba0b7@64.187.160.183] has joined #bitcoin-core-pr-reviews 09:14 < elle> sergei-t: i dont think the connection needs to happen both ways. that is optional. a peer may decide to connect to me but then i dont make an outgoing connection to them. i think 09:14 < dappdever> MarcoFalke: how do you define exactly what is part of the handshake? 09:14 < stacie> Do the rest of the message types handled in ProcessMessage() count as part of the handshake? Because there is a long list 😅 09:15 < michaelfolkson> Not formally defined in code dappdever. I would say any data sent once connection is formalized isn't part of handshake 09:15 < nehan> There is also SENDADDRV2 09:16 < pinheadmz> stacie hint: search for erros that throw a message with "...before version handshake" 09:16 < jonatack> nehan: yes, BIP155 09:17 < MarcoFalke> the handshake includes anything that involves feature negotiation 09:17 < dappdever> michaelfolkson: and a connection is formalized when fSuccessfullyConnected becomes true? 09:17 < MarcoFalke> so inv or tx wouldn't be part of the handshake (even if they might be sent out during one) 09:17 < sipa> MarcoFalke: also sendheaders and sendcmpct which carlakc mentiomed earlier in that case 09:18 < elle> Surely the only other optional message is wtxidrelay? 09:18 < MarcoFalke> sipa: I'd count those as features negotiation, so part of the handshake 09:19 < jnewbery> elle: the initial handshake does require a version message in both directions and a verack message in both directions. You may be getting confused with how the functional tests open multiple connections between nodes 09:19 < elle> ok cool, my bad. Sorry sergei-t and carlakc! im spreading false info here 09:20 < MarcoFalke> Ok, I think we covered all message types during the handshake 09:20 < sipa> MarcoFalke: yeah; i think people here earlier suggested that it wasn't because those are after verack 09:20 < sipa> just a semantics issue 09:20 < sergei-t> So what's the correct answer? to question 2 09:20 < carlakc> are sendheaders and sendcmpct also optional? because we only send them if the peer version supports them 09:20 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 09:20 < nehan> carlakc: yes 09:20 < MarcoFalke> Let me try to summarise: version (must be first message sent/received, required), wtxidrelay (sent/received after version, before verack, optional), verack (sent/received after version,required), sendaddrv2/sendheaders/sendcmpct (sent/received after verack,optional) 09:20 < pinheadmz> cant SENDCMPCT be sent at any time ? 09:21 < MarcoFalke> pinheadmz: Right 09:21 < pinheadmz> so its an early message but to me the "handshake" is just the two required messages 09:21 < MarcoFalke> though, must be after verack 09:21 -!- manojncs [~manojncs@27.5.151.193] has joined #bitcoin-core-pr-reviews 09:21 < pinheadmz> er, and then wtxidrelay yeah 09:22 < nehan> MarcoFalke: so are you defining the "handshake" as first VERSION to last VERACK, or first VERSION to complete feature negotiation? 09:22 < MarcoFalke> ok, I think this question wasn't well defined because handshake is unclear 09:22 < MarcoFalke> nehan: I'd say until feature negotiation is complete 09:22 < nehan> ok, I think that was the confusion. 09:22 < MarcoFalke> It is a long and awkward handshake 09:22 < elle> my assumption was that once pfrom.fSuccessfullyConnected is true, then the handshake is complete? 09:23 < anir> that's what I understood^ 09:23 < felixweis> thats expected, the nodes are just starting to get to know each other 09:23 < michaelfolkson> You can define handshake however you want. It is a word. It isn't code :) 09:23 < MarcoFalke> Ok, so my understanding of handshake is wrong ;). Moving on ... 09:23 < MarcoFalke> What happens if the peer doesn’t complete the handshake? 09:23 < sipa> maybe we can call the steps until verack "handshake" and the colection of all messages that determine features "feature negotiation", and these two only partially overlap (wtxidrelay) 09:24 < MarcoFalke> Oh, I see. This question only makes sense when the handshake is done after the verack msg 09:24 < willcl_ark> It looks like, after the PR, we just fall back to timing out after `DEFAULT_PEER_CONNECT_TIMEOUT = 60` seconds? 09:24 < pinheadmz> we ignore any other messages / bump misbehave score befoer this PR, and eventually the peer probably times out 09:24 < stacie> Per comments in PR #19723 they are disconnected after 60 seconds/99 unsupported/non-handshake messages (the messages part of the previous question). Can someone help direct me to where this is in the code? 09:24 < hmrawal> they are disconnected 09:24 < MarcoFalke> can anyone link to the code? 09:25 < willcl_ark> src/net.cpp#CConnman::InactivityCheck 09:26 < nehan> pre-PR, if nVersion hasn't been set, add to the misbehaving score. if the nVersion was set but fSuccessfullyConnected wasn't true yet, it looks like it just logs. 09:26 < MarcoFalke> willcl_ark: There are several inactivity checks. Which one would be hit? 09:26 < pinheadmz> stacie i thikn the old 99 value comes from the misbehavior score getting +1'ed and then we ban at 100 09:27 < willcl_ark> I think `else if (!pnode->fSuccessfullyConnected)` 09:27 < dhruvm> https://github.com/bitcoin/bitcoin/blob/5bcae7967f73353aff5e6d2f696bbf47ec6fdbb3/src/net.cpp#L1257 09:27 < stacie> pinheadmz oh! that makes sense. Especially since incrementing misbehaving score is what was removed from this PR 09:28 < MarcoFalke> willcl_ark: dhruvm: right 09:28 < pinheadmz> and theres a few other Misbehaving() calls, e.g. "non-connecting headers" is a score of 20 etc 09:28 < MarcoFalke> How are incorrect message from peers dealt with during the handshake? How does the pull request change that? 09:29 < dhruvm> prior to PR incorrect messages would contribute to themisbehavior score, now they won't 09:29 < hmrawal> earlier it used to add to the misbehaving score after PR it will jus tlog 09:29 < emzy> How can tor nodes be baned? As I understand they have no source address. 09:29 < nehan> i think my answer above addresses the first part. the PR changes it by no longer adding to the misbehaving score. I don't see how timeouts are involved though... 09:29 < dhruvm> however, since the 60 seconds timeout will disconnect the peer anyway, it seems unnecessary to punish them 09:30 < felixweis> emzy: you can still get disconnected if your score reaches 100 09:30 < dappdever> it is more likely that the peer would timeout before having a score reach 100 09:30 < sipa> emzy: they're just disconnected 09:31 < jnewbery> Does everyone see that? In the InactivityCheck() function: https://github.com/bitcoin/bitcoin/blob/50e019a97a5b49caee867ec7d630fca908caed9d/src/net.cpp#L1235-L1257 09:31 < jnewbery> That top if statement with nTimeConnected means we don't do any of these checks until we've been connected to the peer for 60 seconds. The final else if statement with fSuccessfullyConnected means that if the handshake hasn't completed in that time then we'll disconnect. 09:31 < michaelfolkson> emzy sipa: Tor nodes aren't subject to the these misbehaving scores? Just disconnected at first sign of misbehaving? 09:32 < nehan> jnewbery: thanks! 09:32 < MarcoFalke> The InactivityCheck is called by Connman for every node in a loop 09:32 < MarcoFalke> jnewbery: thanks for clarifying 09:32 < sergei-t> How often in the inactivity check performed? 09:33 < sipa> michaelfolkson: they're subject to misbehavior and disconnection, not discouraging 09:33 < MarcoFalke> m_peer_connect_timeout is 60 seconds by default 09:33 < jnewbery> sergei-t: every loop of the socket handler thread 09:33 < sipa> (discouraging is the new name of the auto-banning mechanism) 09:33 < MarcoFalke> every loop for every peer 09:33 < carlakc> jnewbery: this one https://github.com/bitcoin/bitcoin/blob/50e019a97a5b49caee867ec7d630fca908caed9d/src/net.cpp#L1544? 09:33 < jnewbery> look for where InactivityCheck() is called 09:34 < emzy> sipa: so only option would be a tarpit. To slow them down. 09:34 < felixweis> https://github.com/bitcoin/bitcoin/blob/50e019a97a5b49caee867ec7d630fca908caed9d/src/net.cpp#L1544 09:34 < sergei-t> I mean, how often is a loop in seconds? Does this question make sense? 09:34 < felixweis> everytime there is some activity on the socket. can be multiple times in a second 09:35 < jnewbery> carlakc: exactly! 09:35 < pinheadmz> sergei-t yeah because the check starts with GetSystemTimeInSeconds() so that loop can run infintiely, it just checks against the clock 09:35 < pinheadmz> ultimately there is a while(true) loop that iterates through all peers as long as bitcoind is alive 09:36 < dhruvm> sergei-t: If I am reading this right, it is called whenever anything is received on the socket? 09:36 < sergei-t> if there is no activity in the socket, the inactivity check must still run, right? Otherwise it fails to detect inactivity :) 09:37 < dhruvm> sergei-t: Sorry read the indentation wrong: It's run just cycling through the peers. 09:37 < dhruvm> https://github.com/bitcoin/bitcoin/blob/5bcae7967f73353aff5e6d2f696bbf47ec6fdbb3/src/net.cpp#L1544 09:37 < felixweis> at some point there will be a new incomming connection or another peer sends us an inv or something 09:37 < sergei-t> felixweis: aa, and this would trigger inactivity checks for _all_ peers, not only the one that sent us something? 09:38 < jnewbery> sergei-t: the inactivity check will happen for all peers in every loop, not just ones that are active 09:38 < felixweis> thats how I currently understand CConnman::SocketHandler, pls correct me 09:38 < sergei-t> jnewbery: that makes it much clearer, thanks! and what if all peers are inactive? 09:39 < willcl_ark> Looks like CConnman::ThreadSocketHandler just loops continuously running SocketHandler with no interval time? 09:39 < pinheadmz> yup 09:39 < dhruvm> willcl_ark: that's how i understand it now as well 09:39 < pinheadmz> checks each peer one at a time for incoming messages, or if we need to send an outgoing message back 09:39 < sergei-t> willcl_ark: loops continiously means _many_ times per second? isn't it a bit... wasteful? 09:40 < felixweis> if all the peers are inactive and there is no attempt for a new peer to connect (very unlikly), there is no cpu wasted so no need to disco 09:40 < jnewbery> willcl_ark: yes, I can't see any sleeps in the socket handler loop 09:40 < pinheadmz> sergei-t pretty sure it gets slowed down by all the things it does for each peer 09:40 < sipa> there is a 10ms delay somewhere iirc 09:40 < pinheadmz> sipa oh! 09:40 < MarcoFalke> I can't see any sleeps either 09:40 < sipa> maybe not anymore? that would be strange 09:40 < MarcoFalke> Ideed. I presumed there was one 09:40 < pinheadmz> i just figured a lot of the networking stuff is blocking, getting chain data etc 09:40 < pinheadmz> slows down the loop 09:41 < felixweis> doesnt it work on kqueue / epoll 09:41 < felixweis> ? 09:41 < sipa> the select() call has a timeout 09:41 < jnewbery> oh, maybe it's in SocketEvents() 09:41 < sipa> so SocketHandler runs whenever there is socket activity on any socket, or that timeoit pazssz 09:41 < sipa> yeah, in SocketEvents() 09:41 < sipa> sorry, phome typing 09:42 < MarcoFalke> https://github.com/bitcoin/bitcoin/blob/50e019a97a5b49caee867ec7d630fca908caed9d/src/net.cpp#L1316 09:42 < jnewbery> SELECT_TIMEOUT_MILLISECONDS which is 50ms 09:42 < MarcoFalke> phew, glad we found that 09:42 < willcl_ark> :D 09:42 < sipa> we'd notice 09:42 < sipa> bitcoind would be >100% cpu usage all the time otherwise 09:42 < willcl_ark> the thread would max out at 100% cpu otherwise 09:43 < MarcoFalke> ok, any other questions before we move on? 09:43 < willcl_ark> probably what sipa said 09:43 < michaelfolkson> But handshakes/serving data to peers can be done concurrently right. You don't need to complete a handshake with one peer before starting a handshake with another etc? 09:43 < michaelfolkson> I don't know what pinheadmz meant exactly by "blocking" 09:43 < jnewbery> and if you're interested, our other main loop is in the message handler thread, which sleeps here between loops: https://github.com/bitcoin/bitcoin/blob/50e019a97a5b49caee867ec7d630fca908caed9d/src/net.cpp#L2249 09:43 < MarcoFalke> michaelfolkson: Yes concurrently logically, but there is only one thread handling the bytes on the wire 09:44 < michaelfolkson> Ok thanks 09:44 < amiti> something I want to clarify about the previous convo with the timeout: prior to this PR, if a peer sends a non-version message before completing their handshake, this would bump their misbehaving score by 1 & disconnect if they sent 100 non-version messages. so, this case would probably hit the timeout (by the time they send over 100s of messages). there might be a slight difference though, in the case 09:44 < amiti> where they just send over a couple non-version messages and then finish connecting. prior to PR this could have incremented the score that reached the 100 number with other behavior too. (but if I remember correctly, many of the misbehaviors increment +100, so a couple extra points would be irrelevant) 09:44 < amiti> so what I'm saying is pre-pr incrementing misbehavior wouldnt *always* hit the timeout. but pre-pr disconnection would almost certainly disconnect via timeout. right? 09:45 < sipa> one message handler thread (which processes incoming messages and decides what to send), and one network thread (which actually receives/sends data over the wire) 09:46 < sipa> amiti: in theory that sounds right, but i think hitting score 100 through 100 score-1 faults isn't ever going to happen accept with very weird broken peers 09:46 < willcl_ark> amiti: do scores persist between disconnects? 09:46 < pinheadmz> michaelfolkson ^ yeah the single threadedness is what i meant by blocking -- while we are processing a peer the other peers are "waiting" 09:46 < MarcoFalke> amiti: Depends on how many non-version messages the peer can send in 60 seconds 09:46 < sipa> willcl_ark: no 09:46 < sipa> *except 09:46 < amiti> sipa: haha yeah, would be weird. 09:46 < michaelfolkson> So the network thread could be dealing with one peer and the message thread could be dealing with a different peer 09:46 < sipa> also we should just remove misbehavior scores 09:46 < amiti> +1 09:46 < willcl_ark> well if scores persisted, then the cumulateive behaviour in amiti's example might be different 09:47 < sipa> michaelfolkson: indeed 09:47 < MarcoFalke> sipa: Why not remove them? *hides* 09:48 < michaelfolkson> What's stopping us from having multiple message handler threads and multiple network threads? :) 09:48 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-pr-reviews 09:48 < jonatack> I'm curious to hear people's thoughts on the last two questions. 09:48 < MarcoFalke> michaelfolkson: cs_main 09:48 < michaelfolkson> Ah 09:48 < nehan> cs_main doesn't _prevent_ it, it just limits the benefit 09:49 < pinheadmz> cs_main you mean - the lock ? 09:49 < nehan> and might actually make things slower if many threads are contending for one lock 09:49 < pinheadmz> side Q: is `cs` a hungarian-notation abbreviation for something ? 09:49 < sipa> critical section 09:49 < pinheadmz> of course!!!!!!! /runs to google 09:49 < MarcoFalke> To elaborate a bit more: Most traffic is from tx messages. Each tx message (assuming it is a previously unseen tx) will call ATMP (AcceptToMemoryPool), which takes the cs_main lock 09:50 < jnewbery> pinheadmz: mutexes that have been added more recently are more often named thing_mutex 09:50 < MarcoFalke> cs_main is the validation lock. It needs to be taken in addition to the mempool lock when adding txs to the mempoll 09:50 < MarcoFalke> *mempool 09:50 < sipa> michaelfolkson: it's also inherently limited in many ways; a lot of messages require processing that affects many other peers (e.g. incoming, put in queue for all other peers to announce) 09:51 < MarcoFalke> Ok, let's move on with the next questions. Only 10 minutes left 09:51 < MarcoFalke> What are the risks or benefits of disconecting a peer? 09:51 < sipa> so net_processing (at peast parts of it) are about interaction between peers, and not just "handle message for one peer, move on to the next" 09:51 < pinheadmz> i think disconnecting peers, like selecitng peers, is sensistive because of eclipse attacks 09:51 < nehan> risks: potential for eclipse attacks 09:51 < willcl_ark> well surely one risk is in someway eclipsing yourself 09:52 < felixweis> benefit would be keeping our connection slots open for non-misbehaving nodes 09:52 < amiti> a benefit is you don't want your slots to be taken up by broken or malicious peers 09:52 < sergei-t> Risk: wrongly disconnect an honest peer that did a weird thing on accident 09:52 < nehan> benefit: open up connections for useful peers 09:52 < sergei-t> Benefit: prevent potential attacks (?) 09:52 < amiti> a risk is that over-eager disconnection logic in bitcoin core could lead to a network partition 09:52 < michaelfolkson> Yeah depends on whether if the disconnecting was rational or not. 09:53 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 09:53 < michaelfolkson> If rational great, cleared a slot. If not rational you might replace honest peer with a malicious peer 09:53 < pinheadmz> also its very impolite. not everyone speaks the same dialect *cough* bcoin 09:53 < MarcoFalke> all good answers 09:53 < carlakc> even rationally connecting could be a problem if we have different logic across versions? 09:53 < MarcoFalke> pinheadmz: I think in some cases it is polite to disconnect 09:53 < sipa> i'd say disconnecting is very polite 09:54 < felixweis> pinheadmz: what are some examples of bcoin dialect? 09:54 < sipa> it can prevwnt the peer from wasting bandwidth on you 09:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 09:54 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has joined #bitcoin-core-pr-reviews 09:54 < pinheadmz> felixweis still uses getblocks and doesnt headers-first yet, although PR is in review to update 09:54 < pinheadmz> not really bannable offenses, i was joking 09:54 < felixweis> thanks, good to know 09:54 < jnewbery> pinheadmz: no headers-first?! :-O 09:55 < michaelfolkson> Yeah I wanted to ask about this carlakc. What happens when a connected peer changes their version? They just send you new version and you understand that they've upgraded? 09:55 < MarcoFalke> Say there is a light client connecting to you, asking for data you can't provide. You could keep and waste the connection or just disconnect 09:55 < sipa> michaelfolkson: you can't upgrade a connectiom from one version to another 09:55 < felixweis> yeah people tend to overlook the importance of "p2p consensus" when reimplementing bitcoin 09:55 < pinheadmz> jnewbery we worked on it all last year, it led to the chain-width-expansion attack paper Braydon released, but never merged the fix, still wanted to figure out a way to mitigate timewarp attacks in conjunciton 09:55 < michaelfolkson> Oh so you disconnect sipa? 09:55 < jnewbery> michaelfolkson: there's no way to re-version a connection 09:55 < sipa> michaelfolkson: how do you upgrade your software without disconnecting....? 09:56 < sipa> you need to stop the running version and start the new one 09:56 < michaelfolkson> Good point 09:56 < nehan> michaelfolkson: there's no mechanism for nodes to update their version without restarting... 09:56 < michaelfolkson> Haha 09:56 < MarcoFalke> double version messages are also ignored 09:56 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 09:56 < MarcoFalke> Last question: What are your thoughts on balancing the risks and benefits of disconnecting peers? What should be used as criteria to disconnect a peer? 09:57 < MarcoFalke> This one doesn't have a textbook answer 09:57 < sergei-t> Would it be a good idea to introduce some kind of config setting so that peer can set how strict it wants to be in its disconnection policy? 09:57 < felixweis> cue erlang bitcoin implementation hot version upgrade 09:57 < sipa> sergei-t: what advice would you give to people on what to set it to? 09:58 < willcl_ark> I guess you might want to be more liberal in disconnecting if your slots are full, but if you have many empty ones then less so 09:58 < pinheadmz> hard question, we want to mitigate DoS but keep the network healthy 09:58 < nehan> felixweis: if the kernel can do it... https://ksplice.oracle.com/ 09:58 < pinheadmz> i think it takes research to determine what is meaningful attack vector based on message size and procesing requirement 09:58 < sergei-t> sipa: e.g., if you run a professional node that hodls lots of coins (exchange), you'd better be stringent 09:58 < willcl_ark> also if you are bandwidth-constrained then you don't want peers wasting your bandwidth 09:58 < sipa> (this is my test: if you introduce a configuration knob, you must know when it's useful to change ot) 09:58 < felixweis> nehan: exactly!!1 09:58 < MarcoFalke> willcl_ark: Good point making it dependend on how many slots are used 09:58 < sipa> sergei-t: how does being more stringent imply being more safe? 09:59 -!- webtricks [679c329a@103.156.50.154] has left #bitcoin-core-pr-reviews [] 09:59 < sergei-t> sipa: it does though I can't prove it's true :) otoh, what are the benefits of _not_ being stringent?.. what do I gain by being more liberal? 09:59 < hmrawal> willcl_ark peers hardly take a few KBs right ? so if at all the bandwith is wasted it's not so much a peer can't afford 10:00 < MarcoFalke> sergei-t: If the connection can offer you value (eg. valid txs or blocks), you might be better off keeping it 10:00 < sipa> sergei-t: the problem is that the protocol is not exactly specified, and changing, and not all software behaves exactly the same 10:00 < felixweis> sergei-t: more implementations, more different bitcoin versions, easier to introduce new features without the risk of network partitioning, ... 10:00 < willcl_ark> hmrawal: I was doing some work previously on mesh networks where message size was 210 bytes... 10:00 < sipa> being more stringent may mean disallowing some (honest but weird) peers 10:00 < sipa> or in the worst case, promoting partitioning attacks 10:01 < nehan> also upgraded nodes with new features might look "weird" to un-upgraded nodes which is bad 10:01 < MarcoFalke> And accidents do happen. Banilla Bitcoin Core itself might accidentally misbehave 10:01 < MarcoFalke> *Vanilla 10:01 < MarcoFalke> #endmeeting 10:01 < MarcoFalke> time :) 10:01 < carlakc> tangent, but has there ever been an attempt to write out the current P2P protocol as implemented in core? 10:01 < felixweis> thanks MarcoFalke! :) 10:01 < jonatack> MarcoFalke: I think you've just named the new release 10:01 < nehan> thanks! 10:01 < willcl_ark> thanks MarcoFalke 10:01 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews 10:01 < carlakc> thanks MarkoFalke! 10:01 < theStack> hi 10:01 < dhruvm> thank you MarcoFalke 10:01 < anir> thanks MarcoFalke! 10:01 < MarcoFalke> thanks everyone. Today I learned the difference between version handshake and feature negotiation 10:01 < willcl_ark> Bitcoin Core 22.0 "Banilla" 10:01 < pinheadmz> good jam ya'll! 10:01 < emzy> Thank you MarcoFalke and jnewbery! 10:02 < amiti> thanks MarcoFalke! thanks everyone :) 10:02 < michaelfolkson> Missed it theStack 10:02 < sergei-t> thank you everyone and welcome to people who confused the time zones! 10:02 < elle> thanks everyone! 10:02 < felixweis> theStack: yeah, DST sucks 10:02 -!- elle [~ellemouto@155.93.252.70] has quit [Quit: leaving] 10:02 -!- anir [40bba0b7@64.187.160.183] has quit [Remote host closed the connection] 10:02 < stacie> Thanks all! 10:02 < michaelfolkson> carlakc: You mean docs? 10:02 < theStack> michaelfolkson: ohnoez... guess i have to read the logs tomorrow :p 10:02 < jonatack> thanks MarcoFalke and everyone! 10:02 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has quit [] 10:02 < jnewbery> sergei-t: A bit more background on removing the -banscore option, which did something similar to what you suggested: https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652684340 https://github.com/bitcoin/bitcoin/pull/19219#issuecomment-652699592 10:03 < carlakc> michaelfolkson: I mean formal specification of the protocol, message formats, exchange order etc 10:03 -!- hmrawal [~hmrawal@2401:4900:2343:7a51:44e0:77fa:74d:b0a8] has quit [Quit: Leaving] 10:03 < jnewbery> thanks MarcoFalke. That was a great meeting :) 10:03 < MarcoFalke> carlakc: there is https://btcinformation.org/en/developer-reference#p2p-network 10:03 -!- manojncs [~manojncs@27.5.151.193] has left #bitcoin-core-pr-reviews ["Leaving"] 10:03 < thomasb06> Nothing to do with the review today but to break things up, Q[X]/(X^3-3X-1) in a field of dimension 9 over rationals and is non-commutative. It's considered a simple one: https://math.stackexchange.com/questions/133790/an-example-of-noncommutative-division-algebra-over-q-other-than-quaternion-alg 10:03 < willcl_ark> It's pretty much "the code is the spec" these days, right? 10:04 < carlakc> MarkoFalke: awesome, never seen that before 10:04 < michaelfolkson> Always has been. Always will be willcl_ark 10:04 < willcl_ark> I guess P2P could perhaps be codified though :S 10:04 < MarcoFalke> carlakc: Might be outdated by now. It was mainly written by harding some years ago 10:04 < sergei-t> jnewbery: thanks, will have a look! just seemed weird to me that misbehaving score is currently "one size fits all"... 10:04 < sipa> also like consensus changes... the changes to P2P are documented in BIPs 10:04 < MarcoFalke> Though, new p2p messages are covered in BIPs 10:05 < sipa> sergei-t: it's a terrible idea and we shouldn't ever had it 10:05 < sipa> ;) 10:05 < michaelfolkson> Suhas said he'd withdrawn a BIP. Which BIP was that? 10:05 < pinheadmz> MarcoFalke how is https://en.bitcoin.it/wiki/Protocol_documentation ? 10:05 < MarcoFalke> pinheadmz: Works too. Should cover the same stuff 10:06 < michaelfolkson> https://github.com/bitcoin/bitcoin/pull/19723#issuecomment-679137633 10:06 < MarcoFalke> michaelfolkson: The feature negotiation BIP? 10:06 < felixweis> michaelfolkson: not the bip, the big amendment 10:06 < sipa> michaelfolkson: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018084.html 10:06 < michaelfolkson> Ta 10:07 < sipa> sergei-t: maybe a counterpoint... you *can* change the misbehavior threshold from 100 to another value using a cmdline option 10:07 < sipa> but imho, it's pointless to do so 10:08 -!- foxp2 [~foxp2@ec2-52-73-85-113.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews 10:08 < MarcoFalke> sipa: Not anymore 10:08 < MarcoFalke> That setting was finally removed 10:08 < sipa> oh, good. 10:09 -!- thomasb06 [863be68d@leat141.unice.fr] has quit [Remote host closed the connection] 10:10 -!- sergei-t [~sergei@2001:a18:0:b23::6] has left #bitcoin-core-pr-reviews [] 10:13 < jonatack> #19464 net: remove -banscore configuration option 10:16 < sipa> dank. 10:17 < pinheadmz> haha spoken like a true bay area kid 10:17 < jnewbery> *flemish person 10:25 -!- foxp2 [~foxp2@ec2-52-73-85-113.compute-1.amazonaws.com] has quit [Quit: \/\/] 10:33 -!- drainable [~wireless@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews [] 10:34 < michaelfolkson> How do Bcoin nodes connect to Core nodes pinheadmz? Core nodes don't recognize Bcoin versions right? 10:34 < pinheadmz> on the internet, no one knows youre a firdge... 10:34 < sipa> why would they care about version numbers? 10:34 < pinheadmz> bcoin speaks all the same messages and message tpyes 10:34 < sipa> clients don't even tell each other their client version, apart from a free-form user agent string 10:35 < pinheadmz> protocol version numbers are still in sync, as they must be to send and receive certain messages like compact blocks 10:35 < pinheadmz> same as btcd and other fullnode implementations 10:36 < pinheadmz> however, if bitcoin core deprecates getblocks we'll need to merge our headers first branch with more urgency ;-) 10:36 < sipa> that'd break a lot of things, i think 10:36 < pinheadmz> how old is headers first? any nodes out there predate that ? 10:36 < pinheadmz> (bitcoin core nodes out there) 10:37 < sipa> 0.10, 2015 10:39 < michaelfolkson> I rather dumbly thought Bcoin nodes would exchange Bcoin version messages 10:40 < michaelfolkson> So Bcoin versions map to particular Core versions 10:40 < sipa> the VERSION message doesn't send the client version; it sends the protocol version 10:40 < pinheadmz> two versions: software version like releases and protocl version :-) 10:41 < sipa> protocol versions have been disentangled from client versions since 0.6 or so 10:41 < pinheadmz> https://github.com/bcoin-org/bcoin/blob/master/lib/net/common.js#L23 10:42 < michaelfolkson> Ha TIL 10:42 < michaelfolkson> Just assumed they were the same 10:43 < michaelfolkson> Protocol versions only updated when they are changed? 10:43 < sipa> yes 10:43 < sipa> current protocol version is 70002 10:44 < sipa> eh 10:44 < sipa> 70016 10:45 < michaelfolkson> The reason for disentangling to not confuse versions with other implementations? 10:46 < michaelfolkson> I can't think of another reason. No harm in just using Core versions otherwise 10:46 < sipa> core doesn't define the protocol 10:46 < pinheadmz> michaelfolkson yeah and like, compact blocks was added in 70014, comcpact blocks +swegwit in 70015, etc 10:46 < sipa> it's an implementation of it 10:46 < pinheadmz> so your node knows what words the peer understnads 10:47 < MarcoFalke> there is also a wallet version ;) 10:47 < pinheadmz> heh and bcoin wallet is totally different from bitcoind 10:48 < sipa> the wallet version isn't a protocol thing 10:48 < sipa> it's just stored in wallet.dat, which is obviously core-only 10:50 < michaelfolkson> "Core doesn't define the protocol" is surely a can of worms. Without a spec a so called reference implementation is all we have 10:52 < michaelfolkson> But disentangling P2P protocol from consensus protocol makes sense 10:52 < sipa> i think that's the wrong way to think about it 10:52 < sipa> bitcoin core never sends GETBLOCKS messages since 0.10, but they're clearly still part of the protocol as removing it would break other software 10:53 < sipa> ultimately the protocol is defined by what actually deployed software expects 10:53 < sipa> and that's a very fuzzy thing, but it's not the same thing as "defined by a reference implementation" 10:56 < michaelfolkson> I guess if Core is the "reference implementation" then the next question is which version of Core is the "reference implementation". And which P2P protocol version is the reference P2P protocol implementation. Can't be answered 10:56 < michaelfolkson> The limitations of words.... 10:58 < jnewbery> The getblocks/hashContinue IBD method should be deprecated. We don't even have any tests for it. 10:59 < sipa> jnewbery: perhaps we should add tests for it :) 10:59 < jnewbery> perhaps, or perhaps we should just remove it :) 11:00 < sipa> i don't think it's reasonable to require all peer software to switch to headers-first based IBD 11:00 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 11:00 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 11:01 < pinheadmz> actualy bcoin *does sync headers first for IBD only, once it hits the last checkpoint though its getblocks 11:01 < pinheadmz> and even then it doesn't download blocks out of order or from >1 peer 11:02 < pinheadmz> i think this is how btcd does as well 11:03 < jnewbery> pinheadmz: does it use the hashContinue method? ie does it need to be retriggered to request blocks by a BLOCK message for the tip after receiving 2000 blocks? 11:04 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie] 11:04 < pinheadmz> yeah 11:04 < pinheadmz> https://github.com/bcoin-org/bcoin/blob/master/lib/net/pool.js#L1652 11:04 < pinheadmz> with some tweaks 11:05 < jnewbery> yuck 11:05 < pinheadmz> ha tell me about it 11:06 < pinheadmz> the headers first PR is here: https://github.com/bcoin-org/bcoin/pull/875 and was accompanied by the chain-expansion attack paper 11:06 < jnewbery> I dislike any method where you're using state on a remote peer for your book-keeping 11:06 < pinheadmz> but after discussing on the ML braydon realized time warp attacks werent really accounted for and so like a perfectionist, he clsoed the branch 11:06 < pinheadmz> then we all got laid off 11:06 < pinheadmz> so. 11:06 < pinheadmz> yeah great point 11:13 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has joined #bitcoin-core-pr-reviews 11:23 -!- stacie [~stacie@c-24-60-139-217.hsd1.ma.comcast.net] has quit [Quit: stacie] 11:27 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Remote host closed the connection] 11:27 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 11:29 -!- ccdle12 [~ccdle12@gateway/tor-sasl/ccdle12] has quit [Remote host closed the connection] 12:01 -!- dappdever [~dappdever@pool-100-8-184-107.nwrknj.fios.verizon.net] has quit [] 12:07 -!- carlakc [uid471474@gateway/web/irccloud.com/x-wvwqarqgagwcykkp] has quit [Quit: Connection closed for inactivity] 12:11 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:22 -!- nothingmuch_ is now known as nothingmuch 12:48 -!- lightlike [~lightlike@p200300c7ef15c6002880e36288c53c60.dip0.t-ipconnect.de] has quit [Quit: Leaving] 13:41 -!- effexzi [uid474242@gateway/web/irccloud.com/x-sfrzhrhccjrtpvef] has joined #bitcoin-core-pr-reviews 13:41 -!- effexzi_ [uid474242@gateway/web/irccloud.com/x-rzcbsldwxwpmrwrr] has joined #bitcoin-core-pr-reviews 13:42 -!- effexzi_ [uid474242@gateway/web/irccloud.com/x-rzcbsldwxwpmrwrr] has left #bitcoin-core-pr-reviews [] 14:08 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 14:09 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 14:10 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-pr-reviews 14:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 14:12 -!- vasild_ is now known as vasild 14:26 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-mxowwcwnuzktweyq] has quit [Ping timeout: 260 seconds] 14:26 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-lecmkndyxyxbgylp] has joined #bitcoin-core-pr-reviews 14:27 -!- digi_james [sid281632@gateway/web/irccloud.com/x-luadapapmlcwedbg] has quit [Ping timeout: 260 seconds] 14:27 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-mbwcgsqcljczdygs] has quit [Ping timeout: 260 seconds] 14:28 -!- digi_james [sid281632@gateway/web/irccloud.com/x-cgclkowkiyrokwek] has joined #bitcoin-core-pr-reviews 14:29 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-kmxptbegweexrioe] has joined #bitcoin-core-pr-reviews 15:11 -!- wumpus2 [~ircclient@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-pr-reviews 15:13 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 15:13 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-tztxjaghihphabaq] has quit [Ping timeout: 240 seconds] 15:13 -!- wumpus [~ircclient@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 240 seconds] 15:26 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-ospaiomdpjpxqqnk] has joined #bitcoin-core-pr-reviews 15:26 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 15:34 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 15:35 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 15:41 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 15:44 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 15:44 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 16:32 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has quit [Quit: leaving] 16:41 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 272 seconds] 17:00 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds] 18:29 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews 18:49 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Quit: Leaving] 19:54 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 19:56 -!- davterra [~davterra@94.198.43.53] has quit [Quit: Leaving] 19:57 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds] 20:09 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 20:09 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-pr-reviews 20:55 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds] 21:04 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 21:21 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection] 21:22 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews 21:23 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds] 22:06 -!- effexzi [uid474242@gateway/web/irccloud.com/x-sfrzhrhccjrtpvef] has left #bitcoin-core-pr-reviews [] 23:47 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has quit [Quit: ZNC 1.7.4 - https://znc.in] 23:47 -!- MarcoFalke [~none@198.12.116.246] has quit [Quit: ZNC 1.7.1 - https://znc.in] 23:49 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews 23:49 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-pr-reviews