--- Day changed Wed Jan 06 2021 00:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 00:14 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Quit: Ping timeout (120 seconds)] 00:17 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #bitcoin-core-pr-reviews 00:46 -!- musdom [~Thunderbi@113.210.56.124] has quit [Read error: Connection reset by peer] 00:50 -!- DuncanDean[m] [duncandean@gateway/shell/matrix.org/x-wqtxrjxevyhtthik] has joined #bitcoin-core-pr-reviews 00:52 -!- sunon [~sunon@105-213-12-49.access.mtnbusiness.co.za] has joined #bitcoin-core-pr-reviews 00:53 -!- DuncanDean[m] is now known as sunon[m] 00:53 -!- sunon [~sunon@105-213-12-49.access.mtnbusiness.co.za] has quit [Remote host closed the connection] 00:54 -!- sunon [~sunon@105-213-12-49.access.mtnbusiness.co.za] has joined #bitcoin-core-pr-reviews 00:55 -!- sunon [~sunon@105-213-12-49.access.mtnbusiness.co.za] has left #bitcoin-core-pr-reviews [] 00:56 -!- sunon[m] is now known as sunon 01:27 -!- musdom [~Thunderbi@113.210.56.124] has joined #bitcoin-core-pr-reviews 01:46 -!- musdom [~Thunderbi@113.210.56.124] has quit [Read error: Connection reset by peer] 01:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 01:59 -!- jadijadi [~jadi@80.71.124.72] has joined #bitcoin-core-pr-reviews 02:03 -!- jadi [~jadi@80.71.124.72] has quit [Ping timeout: 264 seconds] 02:08 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has joined #bitcoin-core-pr-reviews 03:14 -!- norisgOG [~norisgOG@dslb-094-216-007-055.094.216.pools.vodafone-ip.de] has joined #bitcoin-core-pr-reviews 03:14 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews 03:18 -!- Savion72Bins [~Savion72B@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews 03:18 -!- norisgOG [~norisgOG@dslb-094-216-007-055.094.216.pools.vodafone-ip.de] has quit [Remote host closed the connection] 03:20 -!- astrolince [astrolince@gateway/shell/matrix.org/x-pefoseecitekmcnv] has quit [Quit: Bridge terminating on SIGTERM] 03:20 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-jptjnyqphtosrcjy] has quit [Quit: Bridge terminating on SIGTERM] 03:20 -!- sunon [duncandean@gateway/shell/matrix.org/x-wqtxrjxevyhtthik] has quit [Quit: Bridge terminating on SIGTERM] 03:23 -!- Savion72Bins [~Savion72B@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds] 03:24 -!- norisgOG_ [~norisgOG@89.45.7.199] has joined #bitcoin-core-pr-reviews 03:26 -!- norisgOG_ is now known as norisg 03:28 -!- sunon [duncandean@gateway/shell/matrix.org/x-daqewdhpuqdpzfos] has joined #bitcoin-core-pr-reviews 03:41 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-cnxucyerlehmvlgp] has joined #bitcoin-core-pr-reviews 03:41 -!- astrolince [astrolince@gateway/shell/matrix.org/x-epshixvunsdsuvjp] has joined #bitcoin-core-pr-reviews 04:36 -!- parah [c5d247f3@197.210.71.243] has joined #bitcoin-core-pr-reviews 04:54 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 04:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 04:57 -!- parah [c5d247f3@197.210.71.243] has quit [Remote host closed the connection] 05:36 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 05:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services] 05:36 -!- vasild_ is now known as vasild 05:48 -!- norisg [~norisgOG@89.45.7.199] has quit [Ping timeout: 246 seconds] 06:00 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 06:10 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has joined #bitcoin-core-pr-reviews 06:44 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews 06:47 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection] 06:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds] 06:57 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews 07:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Ping timeout: 240 seconds] 07:02 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds] 07:05 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews 07:05 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 240 seconds] 07:05 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-pr-reviews 07:17 -!- martinus [~martinus@212095005068.public.telering.at] has joined #bitcoin-core-pr-reviews 07:29 -!- norisg_ [~norisgOG@89.45.7.199] has joined #bitcoin-core-pr-reviews 07:29 -!- norisg_ is now known as norisg 07:34 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews 07:44 -!- martinus [~martinus@212095005068.public.telering.at] has quit [Remote host closed the connection] 07:44 -!- martinus [~martinus@212095005068.public.telering.at] has joined #bitcoin-core-pr-reviews 07:51 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection] 07:51 -!- sdaftuar_ [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 08:06 -!- lightlike [~lightlike@p200300c7ef13d600f1c214ee95d46c5a.dip0.t-ipconnect.de] has joined #bitcoin-core-pr-reviews 08:20 -!- martinus [~martinus@212095005068.public.telering.at] has quit [Ping timeout: 272 seconds] 08:31 -!- martinus [~martinus@212095005068.public.telering.at] has joined #bitcoin-core-pr-reviews 08:32 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 08:36 -!- elle [~ellemouto@155.93.252.70] has joined #bitcoin-core-pr-reviews 08:37 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 08:37 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has quit [Ping timeout: 265 seconds] 08:38 -!- theStack [~honeybadg@vps1648322.vs.webtropia-customer.com] has joined #bitcoin-core-pr-reviews 08:42 < jnewbery> Hi folks. We'll get started in 18 minutes. Notes and questions are on the website: https://bitcoincore.reviews/20799 08:44 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews 08:45 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds] 08:50 -!- jadijadi [~jadi@80.71.124.72] has quit [Remote host closed the connection] 08:50 -!- jadi [~jadi@80.71.124.72] has joined #bitcoin-core-pr-reviews 08:50 -!- joelklabo [~textual@108-196-216-127.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-pr-reviews 08:51 -!- Legousk [~Henkie@178-84-68-9.dynamic.upc.nl] has joined #bitcoin-core-pr-reviews 08:53 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has joined #bitcoin-core-pr-reviews 08:53 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews 08:54 -!- jadi [~jadi@80.71.124.72] has quit [Ping timeout: 240 seconds] 08:55 -!- keyboardwarrior [6d88c481@109.136.196.129] has joined #bitcoin-core-pr-reviews 08:57 -!- AnthonyRonning [3480306a@52.128.48.106] has joined #bitcoin-core-pr-reviews 08:57 -!- Caralie [185a59be@cpe-24-90-89-190.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews 08:59 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-umalafzpqpnjwfty] has joined #bitcoin-core-pr-reviews 08:59 -!- andozw [ae1f1aca@174.31.26.202] has joined #bitcoin-core-pr-reviews 09:00 < jnewbery> #startmeeting 09:00 -!- anir [40bba0b7@64.187.160.183] has joined #bitcoin-core-pr-reviews 09:00 < emzy> hi 09:00 < jnewbery> Hi folks. Welcome to the first Bitcoin Core PR Review Club of 2021 🎉 09:00 < jarolrod> hi 09:00 < schmidty> Hi! 09:00 < troygior1hev> hi 09:00 < ccdle12> hi 09:00 < Legousk> Hello! 09:00 < lightlike> hi 09:00 < theStack> hi 09:00 < andozw> hiiii 09:00 < elle> hi! 09:00 < joelklabo> good morning 👋 09:00 < anir> hey everyone! 09:00 < AnthonyRonning> Hi all! 09:00 < amiti> hello! 09:00 < felixweis> hi! 09:00 < larryruane_> hi! 09:00 < jnewbery> I hope you all had a good break, and are feeling ready to learn even more about Bitcoin Core this year :) 09:00 < jnewbery> feel free to say hi to let everyone know you're here 09:00 < sunon> Hey!! Elle yay! 09:00 -!- fodediop [~fode@41.214.91.32] has joined #bitcoin-core-pr-reviews 09:01 < norisg> Hi ! 09:01 < fodediop> hi 09:01 < willcl_ark> hi 09:01 < jnewbery> Notes and questions are in the normal place: https://bitcoincore.reviews/20799 09:01 < elle> hey sunon! :) 09:01 < glozow> hi! 09:01 < michaelfolkson> hi 09:01 -!- olympics [~olympics@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews 09:01 < jnewbery> Is anyone here for the first time? 09:01 < olympics> hi 09:01 < AnthonyRonning> first time here 09:01 < pinheadmz> hi 09:01 < jnewbery> Welcome AnthonyRonning! Thanks for joining us 09:01 < keyboardwarrior> hi :) 09:01 < sunon> Trying via a matrix.org proxy for the first time. Let’s see how this goes 09:01 < fodediop> Welcome Anthony! 🎉 09:01 < olympics> welcome AnthonyRonning 09:02 < AnthonyRonning> 🙌 09:02 < Caralie> hi :) Welcome Anthony! 09:02 < thomasb06> hi 09:02 < jnewbery> A couple of reminders on the format: i have some prepared questions to guide the conversation, but feel free to jump in at any time. Don't worry if you have a question about something that we covered earlier or whatever. 09:03 < jnewbery> also, don't ask to ask. Just jump right in. 09:03 < jnewbery> we're all here to learn and all questions are welcome 09:03 < jnewbery> ok, onto the PR. Who had a chance to review it? (y/n) 09:03 < sunon> n 09:03 < joelklabo> y 09:03 < Legousk> n 09:03 < AnthonyRonning> y 09:03 < ccdle12> y 09:03 < troygior1hev> n 09:03 < fodediop> y 09:03 < norisg> n 09:03 < felixweis> n 09:03 < thomasb06> y 09:03 < willcl_ark> n 09:03 < pinheadmz> 1/2 09:03 < theStack> 0.5 y (did just skim over the commits w/o detailled code review) 09:04 < emzy> y/n 09:04 < Legousk> Where can I see beforehand which one will be reviewed? 09:04 < jnewbery> nice. No problem if you didn't have time this week 09:04 < elle> 0.5 y (spent most time on context) 09:04 < glozow> y-ish 09:04 < jarolrod> .5y 09:04 < lightlike> 1/2 09:04 < jnewbery> Legousk: they're announced on the website, usually the Friday before. 09:04 < olympics> Legousk https://bitcoincore.reviews/ 09:04 < jnewbery> any initial thoughts about the PR? Concept ACK/NACKs? 09:04 < anir> 1.2 09:04 < anir> 1/2* 09:05 < AnthonyRonning> concept ack, love removing code 09:05 < nehan> hi 09:05 < sunon> Concept ACK 09:05 < jnewbery> YES! Removing code is the best! 09:05 < emzy> concept ack, not needed anymore. 09:05 < pinheadmz> ack yes 09:05 < jarolrod> concept ack makes sense 09:05 < thomasb06> not acquainted with the code enough 09:05 < Legousk> Thanks 09:05 < joelklabo> ack 👍 09:05 < theStack> concept ack! 09:05 < michaelfolkson> Concept ACK but remind me how many old versions it is Core policy to support? 09:05 < anir> Concept ack, streamlines the codebase 09:06 < jonatack> hi 09:06 -!- sishir [465dca45@cpe-70-93-202-69.natsow.res.rr.com] has joined #bitcoin-core-pr-reviews 09:06 < fodediop> Concept but still trying to digest the codebase 09:06 < fodediop> Ack 09:06 < michaelfolkson> 0.13 is pretty old 09:06 < jnewbery> michaelfolkson: that's a very broad question. There are lots of different versionings (eg p2p protocol, wallet, file format, ...) 09:06 < jnewbery> First question. How does using compact blocks save bandwidth? What data is not downloaded when relaying blocks using compact blocks? 09:07 < ccdle12> the transactions aren't downloaded? it 09:07 < jarolrod> Compact Blocks only includes a short transaction id for each transaction contained within it. The node on the receiving end of a compact block must match a transaction id with a transaction in its mempool and reconstruct the full block. Since we are not sending all of the transaction data, we can reduce block relay bandwidth around ~90% 09:07 < sunon> Most of the actual transactions 09:07 < pinheadmz> full transaction data is not downloaded, just short IDs 09:07 < jnewbery> The BIP is here: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki 09:07 < pinheadmz> in hopes the recipient has the tx data already 09:07 < joelklabo> transactions are assumed to be in the mempool already 09:07 < jonatack> Legousk: if you're on twitter, you can get updates by following https://twitter.com/BitcoinCorePRs 09:07 < michaelfolkson> jnewbery: For this type of p2p change how many old versions should be supported? 09:07 < thomasb06> only the transactions missing are transmitted 09:07 < thomasb06> the block isn't 09:07 < emzy> We only send the block header and short IDs of the transactions. If the peer has all the transactions in the mempool it can reconstruct the block without additional data. 09:07 -!- sdaftuar_ is now known as sdaftuar 09:08 < sunon> Some transaction predicted to not be known to receiver are transmitted too 09:08 < glozow> PrefilledTransactions for txns we expect the peer to be missing, e.g. the coinbase tx 09:08 < pinheadmz> michaelfolkson i think an important point is that no one will ever need version 1 compact blocks because the last non witness block was so long ago, and compacts only work for recent blocks 09:08 < Legousk> jonatack: I'm not on twitter, but will follow it tho 09:08 < emzy> pinheadmz: exactly. 09:08 < pinheadmz> even non upgraded nodes (non segwit) it wont affect them, they arent getting v1 compacts any more anyway 09:08 < jnewbery> Lots of great answers there. Yes, when the node sends a CMPCTBLOCK it'll include shortids for the transactions, and some prefilled transactions, including the coinbase 09:08 < michaelfolkson> pinheadmz: If you are running 0.13 and want to use compact blocks? 09:08 < pinheadmz> i still wont send them to you 09:08 < pinheadmz> the last non witness block was SO LONG ago, you definitely dont have those txs in your mempool :-) 09:09 < pinheadmz> and having tx in the mempool is required for compact blocks to be useful 09:09 < jnewbery> michaelfolkson: if you're running 0.13.0, then you're not enforcing all consensus rules 09:09 < sdaftuar> pinheadmz: that's not exactly right 09:09 < sipa> michaelfolkson: if you're running 0.13.0, yes; not 0.12.x (because it has no compact blocks), and not 0.13.1+ (because it has segwit activated) 09:10 < sdaftuar> pinheadmz: currently an 0.13.0 node could attempt to use compact block relay, and it would get short-ids based on txid rather than wtxid 09:10 < sunon> So it’s really only very specifically 0.13.0 that’s the weird case? 09:10 < olympics> so it only affects node IFF they run 0.13.0 09:10 < olympics> ? 09:10 < sipa> olympics: i believe so 09:10 < sdaftuar> pinheadmz: but you are right that reconstruction would always require a roundtrip because those witness transactions would be nonstadnard to an 0.13.0 node 09:10 < sdaftuar> however, the protocol would work 09:10 < sipa> (or any other codebase that behaves similarly) 09:10 < pinheadmz> sdaftuar i see ok thanks 09:10 < jnewbery> or theoretically some other implementation that implemented BIP 152 but not segwit 09:10 < jnewbery> maybe some old version of an alternative implementation 09:11 < sunon> Oh yes of course 09:11 < norisg> did the block structure also change with segwit, you are talking about "non witness blocks", non witness blocks have no segwit transactions in it? 09:11 < pinheadmz> sdaftuar non standard TXs require a roundtrip? even if the tx is in the mempool (by txid, not wtxid) ? 09:11 < sdaftuar> michaelfolkson: importantly, this doesn't fundamentally break blockrelay to 0.13.0 nodes -- just won't use compact blocks for it 09:11 < sdaftuar> so to your question about "supporting" older nodes, this change wouldn't cause 0.13.0 nodes to fall out of consensus 09:11 < jnewbery> norisg: yes, the serialization of blocks changed with segwit. See BIP 144 for details 09:11 -!- Murch [murch@2a01:4f8:141:1272::2] has joined #bitcoin-core-pr-reviews 09:12 < larryruane_> so a segwit block could happen to have no segwit transactions? 09:12 < olympics> sdaftuar the worst effect would be, marginally longer txn propagation to nodes on 0.13.0? 09:12 < sdaftuar> pinheadmz: well non-standard transactions are (by definition) not in the mempool -- so reconstruction would fail 09:12 < sdaftuar> olympics: yep 09:12 < olympics> ty 09:12 < sdaftuar> block propagation 09:12 < sipa> larryruane_: then by definition it is not a segwit block :) 09:12 < pinheadmz> sdaftuar ah yes yes ty 09:13 < sdaftuar> pinheadmz: (well we also have the extra pool, too -- but that is relatively small) 09:13 -!- nR2Cncdm [~nR2Cncdm@2600:8807:c109:6700:b5ea:4643:bdde:4db0] has joined #bitcoin-core-pr-reviews 09:13 < olympics> sdaftuar should I have said block propagation not txn propagation ? 09:13 < sdaftuar> olympics: yes 09:14 < olympics> bc the shortID expedites relaying the txns in the block rather than shipping out txns the peer may already have 09:14 < jnewbery> Next question: What is BIP152 high-bandwidth mode? How many of our peers can we choose to be high-bandwidth peers? 09:14 < ccdle12> 3 peers as high bandwith, high-bandwith means the nodes send compacted blocks by default 09:15 < emzy> We send the compact block without the peer asking for it, also before we validated it ourself. Max is 3 peers. 09:15 < thomasb06> 2 max 09:15 < anir> peers send new block announcements with the short transaction IDs already via a cmpctblock message, and it’s enabled by setting the first boolean to 1 in a sendcmpct message 09:15 < AnthonyRonning> High bandwidth mode is available so that peers can receive blocks automatically and asap (`1.5 * RTT`), even before full block validation takes place. 09:15 < sunon> High bandwidth mode allows peers to send compact blocks without sending inv msg / asking permission 09:15 < willcl_ark> look like 3 peers 09:15 < jnewbery> olympics: tx relay (for unconfirmed transactions) is unaffected by this. compact blocks makes block propogation faster based on the observation that the receiver probably has most of the transactions in their mempool already 09:15 < pinheadmz> high bandwidth sends unannounced compcat block 09:15 < willcl_ark> from `MaybeSetPeerAsAnnouncingHeaderAndIDs` 09:15 < jarolrod> high bandwidth mode is when you send cmpct blocks without asking for permission, can lead to higher bandwidth because you can receive the same block more than once, but reduced latency because potentially less round trips 09:15 < norisg> we are removing code, but no functionality ? 09:16 < pinheadmz> i was confused by this at first bc if oyu look at bip152 graphic "low bandwiwdth" appears to have more messages 09:16 < glozow> I got 3 from this line in MaybeSetPeerAsAnnouncingHeaderAndIDs: https://github.com/bitcoin/bitcoin/blob/417f95fa453d97087a33d4176523ab278bef21a1/src/net_processing.cpp#L553 09:16 < thomasb06> high bandwidth mode means the nodes will only get the missing transactions 09:16 < lightlike> when it was introduced, why wasn't it decided to schedule compact blocks after segwit? Seems like a lot of effort for just one version 0.13.0 09:16 < sipa> norisg: wouldn't that be great? no, we are removing functionality: dropping support for the non-segwit version of compact blocks 09:16 < sunon> Also yeah only header needs to be validated before they’re sent in high bandwidth mode right? 09:16 < AnthonyRonning> one thing I was unsure of, bip152 says "Nodes MUST NOT send such sendcmpct messages to more than three peers" but sendcmpct can be for low bandwitdth too, so is the three limit total or high bandwidth? 09:16 < sipa> lightlike: things get merged when they're ready, and compact blocks did not require a softfork or anything 09:16 -!- effexzi [uid474242@gateway/web/irccloud.com/x-cxqbwrlditmqpgpy] has joined #bitcoin-core-pr-reviews 09:16 < sdaftuar> lightlike: segwit was also a big change, and it was unclear when it would be finally ready 09:16 < anir> upto 3 peers recommended I believe 09:17 < norisg> sipa because the probability of the block without segwit tx is aganist 0? 09:17 < lightlike> ah ok, thanks! 09:17 < theStack> it should not only affect 0.13.0 but also other higher versions that don't have activated segwit yet, right? (afair segwit came with v0.17, so there must be some versions v0.14.x and v0.15.x etc. with non-latest minor number that are affected) 09:17 < sipa> lightlike: so at the time it was included, it worked immediately on the network, and would keep doing so regardless of whether segwit activated or not (which turned out to be... uncertain for a while) 09:17 < sunon> I also believe I saw 3 peers max 09:17 < thomasb06> it's >= indeed 09:17 < sipa> norisg: no no 09:17 < sipa> norisg: the new protocol works even with non-segwit blocks 09:17 < jnewbery> ... or indeed if it would ever be activated. Segwit and compact blocks are indepedently good things, so it doesn't make sense to gate one on the other 09:17 < michaelfolkson> You just need one SegWit transaction for it to be a SegWit block 09:18 < sdaftuar> theStack: no, everything from 0.13.1 on is segwit aware/activated 09:18 < sipa> norisg: it should be less ambigious and say "segwit-supporting compact block version" and "non-segwit-supporting compact block version" perhaps 09:18 < theStack> sdaftuar: how so? in 0.14.0 there was no segwit 09:18 < sipa> theStack: there absolutely was 09:18 < sdaftuar> theStack: that is not true! 09:19 < theStack> ah, right 09:19 < sipa> theStack: wallet support for segwit came in 0.16 iirc, but that's unrelated 09:19 < ccdle12> i was curious what was the specific reason for a max of 3 high bandwith nodes? 09:19 < michaelfolkson> As pinheadmz said it must have been a long time since a mined block didn't have a single SegWit transaction 09:19 < norisg> sipa ok you you are saying that the "segwit-supporting compact block version" can also propagate non-segwit blocks? 09:19 < sunon> Is it not for DoS mitigation? 09:19 < jnewbery> theStack: the code for segwit was merged in bitcoin 0.13.1. Activation was later, but any node on 0.13.1 or higher can understand/validate/relay segwit blocks/txs 09:20 < theStack> for some reason i thought it was with 0.17, sorry :x 09:20 < sipa> norisg: correct 09:20 < jonatack> was afk, catching up, we can select up to 3, not 2, peers to be bip152 high-bandwidth 09:20 < norisg> and this pull request we are talking about implements "segwit-supporting compact block version" 09:20 < willcl_ark> ccdle12: as per BIP152: "Nodes MUST NOT send such sendcmpct messages to more than three peers, as it encourages wasting outbound bandwidth across the network." 09:21 < jnewbery> norisg: no. It removes support for non-segwit-supporting compact block version 09:21 < ccdle12> willcl_ark: thanks 09:21 < sipa> norisg: no; the current codebase supports both; what we're discussing is removing support for the "non-segwit-supporting compact block version" 09:21 < nR2Cncdm> Hello, my first time. Just lurking today. Hope to make an impact before I die! 09:21 < AnthonyRonning> that's what I'm confused about willcl_ark, doesn't low bandwidth send sendcmpct too? 09:21 < glozow> we can't tell if a node has more than 3, can we? 09:21 < nR2Cncdm> (i'm not expecting death btw) 09:21 < sipa> AnthonyRonning: yes, but with an extra roundtrip 09:21 < thomasb06> jonatack: yep, misread the code 09:21 < sipa> AnthonyRonning: the extra roundtrip means that the receiver only asks for the actual compact block once 09:22 < jnewbery> to everyone who answered "3 peers". You're right! Bonus point to Gloria for pointing out the line of code: https://github.com/bitcoin/bitcoin/blob/417f95fa453d97087a33d4176523ab278bef21a1/src/net_processing.cpp#L553 09:22 < AnthonyRonning> sipa: so the three limit applies to low too? not just high? 09:22 < jonatack> if you'd like to see your bip152 high-bandwidth peers in real time, they can be visualized with https://github.com/bitcoin/bitcoin/pull/20764 09:22 < emzy> nR2Cncdm: good to hear. You will make an impect with the right mindset. 09:22 < sipa> AnthonyRonning: all the ones that are not hb are lb 09:22 < michaelfolkson> The message comparison is here AnthonyRonning: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#intended-protocol-flow 09:22 < jnewbery> The BIP RECOMMENDS that a node chooses up to 3 peers to request HB mode from: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#implementation-notes 09:23 < jnewbery> and that's exactly what Bitcoin Core implements 09:23 < troygior1hev> jonatack: nice! 09:23 < sipa> AnthonyRonning: the hb peers will just send the compact block without being asked for it; the lb peers will announce "hey i have a compact block for you, want it?" - and then the receiver gets to pick which of the lb peers to ask it from 09:23 < jonatack> or via getpeerinfo in master now that theStack's PR exposing these two fields was merged 09:23 < jnewbery> Next question (should be easy given the link above): How do we choose which peers should be high-bandwidth peers? In which function does that logic exist? 09:23 < AnthonyRonning> sipa: thanks! 09:23 < jonatack> troygior1hev: ty :) 09:23 < AnthonyRonning> High bandwidth mode is for peers that have a past performance in providing blocks quickly. I believe it exists in `MaybeSetPeerAsAnnouncingHeaderAndIDs` 09:23 < norisg> sipa: what was the reason why we had to implement it in the first place, but did't remove it immediatly when introducing "segwit-supporting compact block version" 09:24 < pinheadmz> jnewbery in the updated code, if i send you SENDCMPCT with version 1, the function just returns. So you will not send me compact blocks - is my node "ok with this"? Or do we disconnect from peers that dont send compact blocks after we ask them to ? 09:24 < sipa> norisg: because it was necessary at the time; segwit wasn't active on the network 09:24 < norisg> thx sipa 09:24 < jnewbery> norisg: because there's no rush, and potentially there could have been peers on 0.13.0 who still wanted to use compact blocks 09:25 < michaelfolkson> norisg: Why remove functionality for 0.13.0 nodes if Core current version is 0.14? 09:25 < jnewbery> norisg: You may want to look at the motivation in the PR again. It answers a lot of your questions: https://github.com/bitcoin/bitcoin/pull/20799 09:25 < thomasb06> the function is "connman.ForNode(.,.)" 09:25 < anir> I think peers be selected based on their past performance in providing blocks quickly 09:26 < willcl_ark> jnewbery: this is in src/net_processing.cpp#MaybeSetPeerAsAnnouncingHeaderAndIDs called by PeerManager::BlockChecked 09:26 < pinheadmz> MaybeSetPeerAsAnnouncingHeaderAndIDs sets `pfrom->m_bip152_highbandwidth_to = true;` 09:26 < jonatack> anir: right 09:27 < jonatack> for the peers our node chooses 09:27 < pinheadmz> high bandwidth peers are chosen if they are the first peer to inform us of a new block 09:27 < jnewbery> pinheadmz: Very good question. I think Bitcoin Core would be "ok with this", but it's maybe worth a quick check in the Bitcoin Core 0.13.0 code. If it's not ok with it, then maybe a polite disconnect would be better. 09:28 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 09:28 < AnthonyRonning> if I forked core to connect to all my peers with high bandwith mode, is that allowed? can the network see I have connected to more than 3? 09:29 < michaelfolkson> AnthonyRonning: No feel free! 09:29 < jnewbery> To those that answered BlockChecked -> MaybeSetPeerAsAnnouncingHeaderAndIDs : you're right! 09:29 < sdaftuar> AnthonyRonning: no one is in charge... 09:29 < willcl_ark> AnthonyRonning: I don't think anyone except you would know, it's just bad practice 09:29 < sipa> AnthonyRonning: yes, you'll primarily be wasting your own bandwidth 09:29 < sunon> I don’t think that would be any issue 09:29 < thomasb06> arg... 09:29 < emzy> AnthonyRonning: I think there is no way. But what will you gain. Execpt of more bandwith incomming? 09:29 < jnewbery> AnthonyRonning: no-one can stop you, but the BIP says you shouldn't: Nodes MUST NOT send such sendcmpct messages to more than three peers, as it encourages wasting outbound bandwidth across the network. 09:30 < AnthonyRonning> 👍 09:30 < glozow> AnthonyRonning: If your question is whether nodes detect/punish this behavior I don't think they do 09:30 * emzy has unlimited bandwith on his node. Be my guest :) 09:30 < glozow> how would they 🤔 09:30 < AnthonyRonning> glozow: yeah! 09:30 < norisg> does the network equally distribute the high bath width connection, lets say we have 5 nodes on the network and each one of them is connected to the same other 3 in high band with, how do we get the other one in 09:30 < jnewbery> Any questions about BlockChecked() or MaybeSetPeerAsAnnouncingHeaderAndIDs()? 09:30 < sunon> I mean it’s ok to play a little haha 09:31 < jnewbery> How about this question: "Where does BlockChecked() get called from? On which thread?" 09:31 < ccdle12> ThreadMessageHandler 09:32 < ccdle12> ProcessNewBlock I think 09:33 < jnewbery> ccdle12: yes, it can be called from ProcessNewBlock 09:33 < jnewbery> it can also be called from ConnectTip, if we tried to connect the block, but it failed at that point (e.g. if it spent coins that didn't exist) 09:34 < larryruane_> thread b-loadblk? (validation) 09:34 < jnewbery> And yes, those functions will almost always be called on ThreadMessageHandler 09:34 < jnewbery> larryruane_: I think you might be right that it could also be on that thread 09:34 < norisg> ccdle12 which codefile and line ? 09:35 < jnewbery> the interesting thing to note here is that CheckBlock is one of the two validation interface callbacks that are called synchronously. Does anyone know the other one? 09:35 < glozow> where can I find all the threads? grep for std::thread ? 09:35 < ccdle12> norisg: net.cpp::CConnman::ThreadMessageHandler() and net_processing.cpp:ProcessMessage() 09:35 < norisg> thx ccdle12 09:36 < troygior1hev> This is useful for anyone wanting to explore the different threads: 09:36 < ccdle12> norisg: ProcessMessage() is hugh fyi lol 09:36 < troygior1hev> https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#threads 09:36 < glozow> big thank 🙏 09:36 < larryruane_> glozow I think a good way to do it actually is to run the debugger, set a bp, then see which thread you're on (info threads helps) 09:37 < jnewbery> troygior1hev: good tip! 09:37 < glozow> larryruane_ oo nice! 09:37 < jnewbery> Also, try running with -logthreadnames and look at your debug log 09:37 < jonatack> doc/developer-notes.md has a section on the threads 09:38 < pinheadmz> jnewbery tracing through net_processing I think the requesting node doesnt care if it gets a block instead of a compact block. Even if the inv has type MSG_CMPCT_BLOCK, the remote node just tests for IsGenBlkMsg which includes all block tpe messages, and then decides later to send compact or not 09:38 < jnewbery> especially with the validation category enabled, because then you can see the validation interface callbacks being set and fired 09:38 < jonatack> troygior1hev: what you wrote ^ 09:38 < jnewbery> pinheadmz: thanks! Quick work 09:39 < jnewbery> ok, we can come back to the validation interface in a bit. Let's move on to the next question. If a peer chooses us to be its high-bandwidth peer, how does it signal that to us? 09:39 < emzy> Sending sendcmpct with first byte set to1 (true). 09:39 < theStack> by sending the SENDCMPCT message with its payload byte set to 1 09:39 < AnthonyRonning> sending a 1 in the `sendcmpct` command 09:39 < norisg> how do we test this compact block feature, there should already be test files I guess 09:40 < jnewbery> yes. exactly right. The first byte of sendcmpct is for high bandwidth mode. 09:40 < ccdle12> norisg: test/functional/p2p_compactblocks.py 09:40 < michaelfolkson> norisg: There is already a functional test which is changed in the PR 09:40 < jnewbery> norisg: good question. Take a look at the commits in the PR and see which functional test is being updated 09:40 < theStack> norisg: see test/functional/p2p_compatblocks.py 09:40 < theStack> *p2p_compactblocks.py 09:40 -!- jadi [~jadi@62.102.130.15] has joined #bitcoin-core-pr-reviews 09:41 < jnewbery> Next question. BIP152 states: “high-bandwidth mode permits relaying of CMPCTBLOCK messages prior to full validation (requiring only that the block header is valid before relay).” In which PeerManager function do we relay compact blocks to peers that have chosen us to be a high-bandwidth peer? 09:41 < AnthonyRonning> I think `NewPoWValidBlock` , determined by the `m_sendcmpct_hb` flag 09:41 < jarolrod> PeerManager::NewPOWValidBlock line 1250 of src/net_processing.cpp 09:42 < jnewbery> AnthonyRonning jarolrod: exactly right. It's in NewPOWValidBlock(). Can anyone tell me more about NewPOWValidBlock? Where is it called from? 09:43 < ccdle12> AcceptBlock()? 09:43 < AnthonyRonning> yeah that was my guess as well https://github.com/bitcoin/bitcoin/blob/c37600777eea9fc248ad0cffcc1a90df9af2410c/src/validation.cpp#L3741 09:44 < AnthonyRonning> not sure the thread info though, haven't reviewed the threads doc yet 09:44 < jnewbery> yeah, AcceptBlock() has this call: `GetMainSignals().NewPoWValidBlock(pindex, pblock)`. What does that mean? 09:44 < norisg> why is propagation more important than verification 09:45 -!- jadi [~jadi@62.102.130.15] has quit [Ping timeout: 240 seconds] 09:45 < larryruane_> Is it because that function is going to run in a different thread? 09:45 < ccdle12> actually that's something I was studying earlier, GetMainSignals() gets called in init.cpp, so is it like a main thread in a way? 09:45 < jnewbery> larryruane_: good guess. You're almost there 09:45 < larryruane_> (I meant the GetMainSignals) 09:45 < jarolrod> norisg: block propagation is important to prevent network splits 09:46 < sipa> norisg: it's not; but verification takes time, and latency on the network is important, so we want blocks to be able to propagate without suffering a delay from validation at every hop 09:46 < sipa> ccdle12: validation.cpp and net_processing.cpp together used to be main.cpp; i think that's where the name comes from 09:47 < ccdle12> sipa: aahh interesting, thanks 09:47 < larryruane_> also we don't want to give anyone an incentive to run a modified client 09:47 < jnewbery> ok, GetMainSignals is the way that validation fires a validation interface notification 09:47 < glozow> at this point though we've already verified the PoW, which would be very hard to fake, so it's not as risky right? 09:48 < larryruane_> john could you elaborate a bit? 09:48 < emzy> I think a valid Block header is enough to be relayed. It is enough work to come up with one. 09:48 < norisg> sipa: how long do we allow peers to send us false blocks until we close the connection 09:48 < jnewbery> other components subscribe to those notifications. Look for any class that inherits the CValidationInterface interface to see examples 09:48 < norisg> in high band with mode 09:48 < sdaftuar> glozow: yep the PoW prevents DoS. however it's worth looking at what happens if a block is invalid 09:48 < sipa> norisg: it is very expensive for them to do so, due to PoW 09:49 < sipa> (even unvalidated blocks must pass PoW) 09:49 < norisg> sipa perfect thanks 09:49 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews 09:49 < jnewbery> many of those notifications are asynchronous (i.e. validation sends them, and then the subscibers get notified by a background thread), but there are a couple that are synchronous (i.e. the subscribers are called directly by the thread in validation) 09:49 < jnewbery> BlockChecked was one synchronous callback. What's the other? 09:50 < jnewbery> They're defined in https://github.com/bitcoin/bitcoin/blob/68196a891056f98c1df0debacf09fb2ea4682a43/src/validationinterface.h 09:51 < jonatack> jnewbery: i'd gladly review a commit adding that info in a GetMainSignals() doxygen doc in validationinterface.h 09:51 < pinheadmz> sdaftuar glozow related: i dont see in net_processing how we deal with unsolicited BLOCK messages? is that not a DoS risk? 09:52 < jnewbery> look for "called on a background thread" 09:52 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews 09:52 < AnthonyRonning> ah so NewPoWValidBlock is sync too then? 09:52 < jnewbery> YES! 09:53 < jnewbery> AnthonyRonning: correct 09:53 < jnewbery> why do you think that is? 09:53 < larryruane_> ChainStateFlushed() also 09:53 < glozow> pinheadmz: I suppose we check blocks in an order that prioritizes failing early 09:53 < jnewbery> ChainStateFlushed is asynchronous 09:53 -!- sanket1729_ [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Client Quit] 09:53 -!- sanketcell_ [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined #bitcoin-core-pr-reviews 09:54 < glozow> i.e. first non-contextual and look at PoW before doing any expensive verification 09:54 < AnthonyRonning> does BlockChecked not call NewPoWValidBlock? So they'd both be sync? 09:54 < pinheadmz> glozow ah yeah i thikn i see in CChainState::AcceptBlock() if we didnt request the block we check chainwork in the header before anything 09:54 < jnewbery> AnthonyRonning: No. NewPOWValidBlock is called by AcceptBlock() 09:55 < glozow> i think we do that for blocks we did request too, right? 09:55 < jnewbery> The reason it's important is that we want to send out the high-bandwidth compact blocks as quickly as possible 09:55 -!- sanketcell_ is now known as sanketcell 09:55 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 09:55 < larryruane_> Why is there such a thing as synchronous notifications? How is that different from just a normal function call? 09:55 < pinheadmz> glozow sorry we just check against nMinimumChainWork 09:55 < jnewbery> so we immediately (synchronously) call the NewPoWValidBlock() callback in net_processing, which sends the cmpctblock message out immediately 09:56 < jnewbery> larryruane_: validation doesn't hold a reference/pointer to peermanager. Everything that peermanager gets from validation is through the validation interface 09:56 < AnthonyRonning> interesting, so do async notifications go through a queue of some sort? And calling it syncronously skips that? 09:57 < jnewbery> AnthonyRonning: basically yes, async notifications are all serviced on the background scheduler thread 09:57 < nehan> jnewbery: so the documentation that NewPoWValidBlock is synchronous vs asynchronous is the fact that it does *not* have "Called in a background thread" in its defn comments in validationinterface.h? 09:57 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds] 09:57 < nehan> how else might one confirm that? 09:57 < jnewbery> whereas synchronous notifications are just regular function calls by the thread that's doing the validation 09:58 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews 09:58 < AnthonyRonning> gotcha, very cool, thanks 09:58 < nehan> just that its function doesn't call ENQUEUE_AND_LOG_EVENT? 09:58 < jnewbery> nehan: that's the documentation, yes! You could look in validationinterface.cpp to see how those notifications are invoked, or you could run a node with thread debug logs enabled and validation category debug logs enabled and see which threads are servicing the validation interface callbacks 09:59 < jnewbery> We've covered the last question already (How is that PeerManager function invoked? In which thread is it called?) 09:59 < jnewbery> And that's about time. 09:59 -!- sishir [465dca45@cpe-70-93-202-69.natsow.res.rr.com] has quit [Remote host closed the connection] 10:00 < jnewbery> Next week, dhruv is hosting on PR 19825. We'll have notes up by Friday. 10:00 < jnewbery> Thanks everyone! 10:00 < jnewbery> #endmeeting 10:00 < pinheadmz> thanks jnewbery ! 10:00 < theStack> thanks for hosting jnewbery 10:00 < AnthonyRonning> thank you! 10:00 < troygior1hev> thanks jnewbery! 10:00 < olympics> thanks jnewbery 10:00 < norisg> thank you ! 10:00 < ccdle12> thanks jnewbery 10:00 < thomasb06> thanks jnewbery 10:00 < emzy> Thank you jnewbery and all others. Happy, healthy and productive 2021 to you all. 10:00 < lightlike> thanks jnewbery 10:00 < glozow> thanks jnewbery! 10:00 < fodediop> Thanks jnewbery! 10:00 < larryruane_> thank you all, this was great! 10:00 < anir> Thanks jnewbery and everyone else! 10:01 < jarolrod> thanks 10:03 -!- elle [~ellemouto@155.93.252.70] has quit [Quit: leaving] 10:04 -!- FreeCake [~FreeCake@86.106.90.94] has joined #bitcoin-core-pr-reviews 10:04 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews 10:04 -!- fodediop [~fode@41.214.91.32] has quit [Quit: WeeChat 3.0] 10:07 -!- belcher_ is now known as belcher 10:08 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has quit [Ping timeout: 240 seconds] 10:09 -!- AnthonyRonning [3480306a@52.128.48.106] has quit [Remote host closed the connection] 10:10 < jonatack> The meeting log is now posted at https://bitcoincore.reviews/20799 10:13 -!- norisg [~norisgOG@89.45.7.199] has quit [Ping timeout: 256 seconds] 10:14 < jnewbery> Thanks jonatack! 10:16 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has joined #bitcoin-core-pr-reviews 10:16 < jonatack> 🍰 10:16 < olympics> thanks jonatack 10:17 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 240 seconds] 10:17 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-pr-reviews 10:21 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 10:25 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 10:34 -!- Legousk [~Henkie@178-84-68-9.dynamic.upc.nl] has quit [Quit: Leaving] 10:37 -!- andozw [ae1f1aca@174.31.26.202] has quit [Remote host closed the connection] 10:41 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: ccdle12] 10:43 -!- olympics [~olympics@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews [] 10:54 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 256 seconds] 10:57 -!- martinus [~martinus@212095005068.public.telering.at] has quit [Ping timeout: 265 seconds] 10:57 -!- Caralie [185a59be@cpe-24-90-89-190.nyc.res.rr.com] has quit [Remote host closed the connection] 11:12 -!- jadi [~jadi@62.102.130.15] has joined #bitcoin-core-pr-reviews 11:16 -!- jadi [~jadi@62.102.130.15] has quit [Ping timeout: 260 seconds] 11:20 -!- nR2Cncdm [~nR2Cncdm@2600:8807:c109:6700:b5ea:4643:bdde:4db0] has quit [Quit: Textual IRC Client: www.textualapp.com] 11:26 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 264 seconds] 12:05 -!- anir [40bba0b7@64.187.160.183] has quit [Remote host closed the connection] 12:10 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!] 12:15 -!- effexzi [uid474242@gateway/web/irccloud.com/x-cxqbwrlditmqpgpy] has quit [Quit: Connection closed for inactivity] 12:26 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has quit [Ping timeout: 264 seconds] 12:37 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has joined #bitcoin-core-pr-reviews 13:37 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection] 14:00 -!- troygior1hev [~troygiors@bras-base-barion1858w-grc-01-216-209-164-24.dsl.bell.ca] has quit [Ping timeout: 256 seconds] 14:11 -!- martinus [~martinus@212095005068.public.telering.at] has joined #bitcoin-core-pr-reviews 14:21 -!- keyboardwarrior [6d88c481@109.136.196.129] has quit [Remote host closed the connection] 14:45 -!- martinus [~martinus@212095005068.public.telering.at] has quit [Ping timeout: 264 seconds] 15:13 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer] 15:13 -!- FreeCake [~FreeCake@86.106.90.94] has quit [Quit: For Sale: Parachute. Only used once, never opened, small stain.] 15:15 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews 15:18 -!- lightlike [~lightlike@p200300c7ef13d600f1c214ee95d46c5a.dip0.t-ipconnect.de] has quit [Quit: Leaving] 16:27 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has joined #bitcoin-core-pr-reviews 17:36 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 17:36 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services] 17:36 -!- vasild_ is now known as vasild 18:54 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews 19:08 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds] 19:09 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews 19:12 -!- jadi [~jadi@62.102.130.15] has joined #bitcoin-core-pr-reviews 19:17 -!- jadi [~jadi@62.102.130.15] has quit [Ping timeout: 246 seconds] 21:03 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews 21:05 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds] 21:08 -!- glozow [uid453516@gateway/web/irccloud.com/x-fnpkgibmglqpjsad] has quit [Quit: Connection closed for inactivity] 21:14 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 21:27 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 21:42 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has joined #bitcoin-core-pr-reviews 22:00 -!- jadi [~jadi@62.102.130.15] has joined #bitcoin-core-pr-reviews 22:11 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:12e2:ad75:1255:fdff:5733] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 22:31 -!- da39a3ee5e6b4b0d [~da39a3ee5@183.88.107.112] has joined #bitcoin-core-pr-reviews 22:31 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds] 22:39 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews 23:35 -!- da39a3ee5e6b4b0d [~da39a3ee5@183.88.107.112] has quit [Ping timeout: 264 seconds]