--- Day changed Wed Sep 16 2020
01:07 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 244 seconds]     
01:11 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #bitcoin-core-pr-reviews     
02:02 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
02:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
02:46 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
03:07 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
03:09 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
03:16 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
03:17 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has joined #bitcoin-core-pr-reviews     
03:18 -!- Milford1Lemke [~Milford1L@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:23 -!- Milford1Lemke [~Milford1L@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 246 seconds]     
03:23 -!- jonatack [~jon@37.166.247.142] has quit [Read error: Connection reset by peer]     
03:30 -!- worc3131 [~quassel@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786] has quit [Ping timeout: 260 seconds]     
03:38 < michaelfolkson> Thanks for the links jonatack. These instructions are for Linux. https://en.bitcoin.it/wiki/Setting_up_a_Tor_hidden_service
03:39 < michaelfolkson> Any reason not to do it on MacOS? Is it preferable to do this on Linux?
04:04 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
04:07 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
04:10 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
04:18 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
04:19 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
04:19 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
04:19 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
04:26 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
04:26 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
04:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
04:30 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
04:36 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
04:36 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
04:37 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
04:37 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
04:57 < michaelfolkson> "So far this is only used in tests to ensure the new code works as expected."
04:59 < michaelfolkson> I get the chopping up into more easily reviewable PRs part. So maybe it is more that than this. But does the PR author want reviewers to play around trying to break the tests with this code or is tests passing sufficient?
05:35 -!- worc3131 [~quassel@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786] has joined #bitcoin-core-pr-reviews     
05:42 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-pr-reviews     
05:43 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]     
06:07 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-pr-reviews     
06:22 < emzy> If someone needs a tor-v3 bitcoin node to connect to (only up for today): lw6hmfiyqkneb7biux5maaxztcizqnryjtrytwtsynj6szfwuo7dykyd.onion
06:33 < jonatack> there are at least 5 bitcoin torv3 nodes up and running right now
06:35 < jonatack> er, make that 6
06:40 < emzy> Cool
06:41 < emzy> jonatack: how do you know?
06:43 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
06:43 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
06:44 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
06:49 < jonatack> that's how many i see
06:50 < jonatack> the one you mentioned, one that sipa mentioned, two that wumpus mentioned, another one, and me...
06:53 -!- musdom [~Thunderbi@202.184.190.229] has joined #bitcoin-core-pr-reviews     
06:56 < pinheadmz> anyone ever played with I2P ?
06:56 < pinheadmz> Kinda curious how the network design compares to tor but having hard time finding tech details
06:58 < emzy> Like many years ago.
06:58 < michaelfolkson> jonatack has a secret network crawler that he doesn't want to disclose ;)
06:59 < jonatack> michaelfolkson: i don't open PRs for the good stuff :D
07:00 < emzy> hehe
07:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]     
07:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-pr-reviews     
07:15 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined #bitcoin-core-pr-reviews     
07:39 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has joined #bitcoin-core-pr-reviews     
07:53 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
07:53 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
07:56 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has joined #bitcoin-core-pr-reviews     
08:02 -!- wiz [~j@wiz.biz] has joined #bitcoin-core-pr-reviews     
08:03 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:05 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has joined #bitcoin-core-pr-reviews     
08:08 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has quit [Client Quit]     
08:26 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has joined #bitcoin-core-pr-reviews     
08:31 < pinheadmz> looks like the BIP needs to be updated? https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki#compatibility
08:31 < pinheadmz> 70016 is already WTXID_RELAY_VERSION
08:33 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:b0aa:ce46:f4e3:be1d] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:34 -!- epson121 [d5953d67@213.149.61.103] has joined #bitcoin-core-pr-reviews     
08:37 < jonatack> pinheadmz: https://github.com/bitcoin/bips/pull/907
08:38 < pinheadmz> bam!
08:41 -!- Elfrieda18Wolff [~Elfrieda1@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
08:43 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has quit [Remote host closed the connection]     
08:46 -!- Elfrieda18Wolff [~Elfrieda1@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]     
08:46 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
08:47 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
08:50 < jonatack> note: you can either build PR 19845 and then addnode to a torv3 peer, or build PR 19954 and gossip a torv3 service
08:51 < jonatack> and if you rebase the PR on master before building (git rebase origin/master), then you can observe the peer action with ./src/bitcoin-cli -netinfo 4
08:52 < jonatack> or you can use the GUI peers window
08:55 < pinheadmz> launching with src/bitcoind -proxy=127.0.0.1:9050  -onlynet=onion -debug=net
08:56 < pinheadmz> added the onionv3 address from emzy
08:56 < pinheadmz> bitcoin-cli getpeerinfo | jq '.[].addr' => mostly onionv2 and that one onionv3 address
08:59 < michaelfolkson> On Sjors comment "I did not check NET_I2P and NET_CJDNS stuff." There is nothing to check right? Just that NET_I2P and NET_CJDNS addresses can fit in ADDRv2 addresses
09:01 < michaelfolkson> https://github.com/bitcoin/bitcoin/pull/19845#pullrequestreview-489613987
09:02 < michaelfolkson> The test suggestions are good
09:03 < wiz> @jonatack running on wizbit5555bsslwv4ctronnsgk5vh2w2pdx7v7eyuivlyuoteejk7lid.onion can you peer with me
09:03 -!- vindard [~vindard@190.83.165.233] has quit [Ping timeout: 264 seconds]     
09:03 -!- vindard [~vindard@200.7.91.20] has joined #bitcoin-core-pr-reviews     
09:04 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
09:05 < jonatack> wiz: added
09:05 < wiz> <3     
09:06 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has joined #bitcoin-core-pr-reviews     
09:10 -!- epson121 [d5953d67@213.149.61.103] has quit [Remote host closed the connection]     
09:11 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has quit [Ping timeout: 272 seconds]     
09:21 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-pr-reviews     
09:22 < pinheadmz> actually after a restart i'm only reconnecting to onion v2 addrs. I'd've expected some of the onion v3 addrs I conencted to manually to be saved in peers.dat and restored on reboot ... no?
09:25 < pinheadmz> Before PR #19845 could we even addnode an onion v3 address ?
09:28 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has joined #bitcoin-core-pr-reviews     
09:29 < jonatack> i have them in bitcoin.conf. not sure if vAddedNodes is persisted. when you restart, run rpc getaddednodeinfo and see if it's populated.
09:30 < jonatack> yes, it seems to be persisted.
09:30 < pinheadmz> [ ] , nope! interesting
09:30 < pinheadmz> oh     
09:31 < jonatack> correction: no, it's not
09:31 < jonatack> snap :)
09:31 < pinheadmz> so as far as running the node with 19845, what can be tested?
09:32 < pinheadmz> is it novel just to be able to addnode onionv3 ?
09:32 < jonatack> yes     
09:32 < pinheadmz> 👍
09:45 < wiz> it's very useful for apps like bisq which need to connect to bitcoin nodes over v3 onions
09:45 < emzy> I connected to wiz. But I don't trust him ;)
09:51 < wiz> better verify all the blocks and transactions my node sends to you then
09:51 < emzy> wiz: nice to see you here.
09:51 < emzy> Will do :)
09:51 < michaelfolkson> Too late. He's a DNS seed now. We are all f***ed
09:51 < michaelfolkson> ;)     
09:52 < wiz> hey at least I have DNSSEC
09:52 -!- epson121 [d5953d67@213.149.61.103] has joined #bitcoin-core-pr-reviews     
09:52 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
09:53 < wiz> regarding the PR tho, it would be nice to support v2 and v3 simultaneously
09:53 < wiz> why not both.gif
09:53 < michaelfolkson> Added some jonatack guidance to the StackExchange answer on Tor https://bitcoin.stackexchange.com/a/99058/47827
09:54 < emzy> wiz: My dnssec test seed looks good.
09:54 < michaelfolkson> Hmm why not both..
09:55 < michaelfolkson> We are supporting both right
09:56 < michaelfolkson> Tor v2 and v3 both in the BIP https://github.com/bitcoin/bips/blob/9286b5254317d9e73fb25c5f0acd2b2d9937843e/bip-0155.mediawiki
09:58 < wiz> emzy cool then enable it on the production instance
09:58 -!- urethane [~urethane@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:59 < emzy> wiz: not yet. I will test it some more. No hurry.
09:59 < vasild> "But does the PR author want reviewers to play around
09:59 < vasild>                         trying to break the tests with this code"
09:59 < vasild> michaelfolkson: any breakage is welcome :)
09:59 < jonatack> pinging dongcarl and vasild :)
10:00 < jonatack> #startmeeting
10:00 <@jnewbery> hi     
10:00 < jonatack> Hi all! Welcome to this week's episode of the Bitcoin Core PR Review club!
10:00 < jonatack> #topic This week, we are looking at PR 19845 - "Net: CNetAddr: add support to (un)serialize as ADDRv2" (p2p)
10:00 < jonatack> Please refer to https://bitcoincore.reviews/19845 that contains notes and questions regarding today's meeting and PR.
10:00 < urethane> hi     
10:00 < michaelfolkson> hi     
10:00 < gzhao408> hai     
10:00 < brikk> hi     
10:00 < jonatack> Anyone here for the first time?
10:00 < shaunsun> hi     
10:01 < emzy> hi     
10:01 -!- dhruvm [~noreply@249.115.24.136.in-addr.arpa] has joined #bitcoin-core-pr-reviews     
10:01 < troygiorshev> hi     
10:01 < jonatack> Let's multithread this and dig in. Warm-up question #1: Visually, how can you tell the difference between a Tor v2 and v3 address?
10:01 < dongcarl> hi     
10:02 < vasild> hi     
10:02 < jonatack> Warm-up question #2: List all the network address types that Bitcoin Core can support after this PR. What is the size in bytes (address length) for each of them? hint: src/netaddress.h::95-114
10:02 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-pr-reviews     
10:02 < emzy> Lengh of the onion address.
10:02 < shaunsun> v3 is longer right?
10:02 < pinheadmz> hi!     
10:02 < sipa> hi.     
10:02 < urethane> v3 is much longer
10:02 < jonatack> emzy: shaunsun: urethane: yes
10:02 < michaelfolkson> 32 bytes vs 10 bytes
10:02 < jonatack> A tor v2 address is 15 characters in length, not counting the .onion suffix: 57qr3yd1nyntf5k.onion
10:02 < jonatack> A tor v3 address is 56 characters:  7zvj7a2imdgkdbg4f2dryd5rgtrn7upivr5eeij4cicjh65pooxeshid.onion
10:03 < jonatack> (visually)
10:03 < urethane> e.g. openpgp.org  v3: zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4
10:03 < emzy> ipv4, ipv6, torv2, torv3, I2P, CJDNS.
10:03 < urethane> .onion
10:03 -!- adolfosrs [bd06f87f@189.6.248.127] has joined #bitcoin-core-pr-reviews     
10:03 < sipa> it's that much longer because it's not just the payload going from 10 to 32 bytes, but also a version number and checksum are added
10:04 < jonatack> emzy: right, ipv4 4 bytes; ipv6 16 bytes; torv2 10 bytes; torv3 32 bytes; i2p 32 bytes; cjdns 16 bytes
10:04 < jonatack> Question 2 *BONUS*: describe any changes going from addrv1 to addrv2, in the size of addrv1-supported addresses, e.g. ipv4, ipv6, torv2?
10:04 < vasild> also "internal" is supported :)
10:05 < nehan> hi     
10:05 < sipa> cjdns could be 15 bytes, i think?
10:05 < vasild> ah, right!
10:05 < pinheadmz> the serialization of all adress types is different in addrv2
10:05 < michaelfolkson> Is it padded to make it 16?
10:06 < pinheadmz> UnserializeV1Stream() vs UnserializeV2Stream() in netaddress.h
10:06 < vasild> hmm, do we want to rely on the fact that they will never change the 1 byte prefix to something else?
10:06 < sipa> michaelfolkson: cjdns nominally uses IPv6 addresses in range fc00::/8
10:06 < sipa> since the first byte is always 0xfc, we could drop it from relay, as it's already explicitly tagged with the cjdns marker
10:06 < sipa> vasild: good question; perhaps not worth it
10:07 < jonatack> Anyone wish to describe changes going from addrv1 to addrv2, in the size of addrv1-supported addresses?
10:08 < pinheadmz> oh are we not using 16 bytes for ipv4 anymore?
10:08 < pinheadmz> because we have more speciifc types instead of trying to use 16 bytes for "everything"
10:08 < sipa> pinheadmz: indeed!
10:08 < jonatack> no, it's now much smaller
10:08 < jonatack> significantly
10:08  * pinheadmz fist bump booyah
10:09 < jonatack> ipv4: 16 -> 6 bytes
10:09 < jonatack> ipv6: 16 -> 18 bytes
10:09 < jonatack> oops, it's bigger, but...
10:09 < jonatack> torv2: 16 -> 12 bytes
10:09 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]     
10:09 < jonatack> estimate the bandwidth savings
10:10 -!- adolfosrs [bd06f87f@189.6.248.127] has quit [Remote host closed the connection]     
10:10  * urethane dreams of gigamegs
10:10 < urethane> lol     
10:10 < jonatack> iirc vasild estimated ~ half less bandwidth in a recent irc discussion
10:10 < vasild> http://www.erisian.com.au/bitcoin-core-dev/log-2020-09-11.html#l-478
10:11 < jonatack> Quick: What is the maximum address length Bitcoin Core will be able to support?
10:11 < vasild> hmm, is there a way to dump all addrman database in a human readable form?
10:11 < michaelfolkson> 512     
10:11 < wiz> hmm, I guess it's not possible to fit a v3 onion in a DNS Seed unless we implement TXT records or something eh
10:11 < emzy> 512 bytes
10:12 < jonatack> michaelfolkson: yes!
10:12 < vasild> wiz: right
10:12 < michaelfolkson> Which is....huge
10:12 < jonatack> wiz: right
10:12 < wumpus> that is true, though, DNS seeds are unusable through tor anyhow
10:12 < sipa> wiz: indeed, but on the other hand... if you're using tor you probably don't want to use DNS seeds (directly) in the first place (and bitcoin core doesn't)
10:13 < wumpus> that ^^
10:13 < sipa> instead we ask an exit node to do the resolving, connect to one of the seed's results, send it a getaddr, and disconnect when the response comes back
10:13 < sipa> which will transparently keep working for addrv2, and support torv3 just fine
10:13 < wumpus> (this is also, in general, the case for other overlay networks)
10:14 < jonatack> Question: did you review the PR? (y / n)
10:14 < jonatack> y     
10:14 < wiz> so what's the purpose of the onioncat encoded AAAA records that start with fd87:d87e:eb43::/48 then? totally unused?
10:14 < pinheadmz> y     
10:14 < emzy> sipa: so without clearnet nodes this will not work. But clearnet is not dead yet.
10:14 < urethane>  wumpus is it "DNS seeds are unusable through tor anyhow" or DNS seeds are ill-advised given user expectations of a node operator using tor?
10:14 < sipa> wiz: relay of onion addresses to non-tor nodes
10:14 < emzy> y (only tested)
10:15 < wiz> okay, so do we still want to support that for v3 onions in some new encoding or TXT records?
10:15 < wumpus> urethane: they are not usable through Tor. You can do DNS lookups through Tor (through a SOCKS5 extension), in principle, but not the kind of query that returns multiple results.
10:15 < sipa> wiz: that would be a ton of work, i'm afraid
10:15 < sipa> (as in: implement our own dns resolver that works over tor...)
10:16 < urethane> wumpus ty
10:16 < wumpus> urethane: they're also super-unreliable, because it's controlled by exit nodes
10:16 < wumpus> wiz: no, I think that's not necessary
10:16 < urethane> wumpus that's the security fallibility I thought you were referring to
10:16 < troygiorshev> n     
10:17 < wumpus> emzy: it works without clearnet nodes; in that case it would rely on the hardcoded onion seeds in the source code though
10:18 < wumpus> (which is okay, some are just as reliable as the DNS seeds)
10:18 < shaunsun> partial y (was able to connect to v3 addresses)
10:18 < jonatack> shaunsun: nice
10:19 < pinheadmz> doesn't tor work with some kind of directory nodes to help route?
10:19 < emzy> wumpus: I will make a mental note to set one up then.
10:19 < pinheadmz> like isnt there a tor version of DNS in that sense
10:20 < sipa> pinheadmz: yes, but for hidden services and relays (I think) - not DNS
10:20 < wumpus> correct, Tor doesn't use names (for anything besides routing through exit nodes), only public keys
10:20 < pinheadmz> sure bc theres no IPs in tor anyway really - but see what im getting at? could there be a bitcoin core tor directory that served bootstrapping nodes over tor?
10:21 < pinheadmz> er, i guess thats the same as just connecting to a seed node over tor and getting addr messages
10:21 < emzy> pinheadmz: I think you can see a hardcodes onion seed as a dnsseed for tor.
10:21 < wumpus> but why? any node can give you other peers, it's decentralized on purpose
10:21 < pinheadmz> yeah
10:22 < jonatack> pinheadmz: "directory" node... just to recap, irc there are 3 basic types of tor nodes: bridge/gate, relays and exit; often a tor node has more than one of those roles
10:22 < urethane> pinheadmz "some kind of directory nodes to help route?" I think you're referring to what's called HSDirs in tor
10:22 < michaelfolkson> Won't it take a while to find a node that gives you Bitcoin peers? Connect to loads of Tor nodes that aren't interested in Bitcoin
10:23 < sipa> pinheadmz: "could there be a bitcoin core tor directory that served bootstapping nodes over tor?" -> that's called a seed node
10:23 < sipa> and it needs literally zero modifications to work :)
10:23 < pinheadmz> yep I realize i just circled back to what we already ahve
10:23 < vasild> contrib/seeds/nodes_main.txt
10:23 < wumpus> michaelfolkson: it will only connect to (supposed) bitcoin peers which will give you other bitcoin peers
10:24 < urethane> tor v2 doesn't have privacy for onion addresses from an HSDirs observer, tor v3 does have onion service privacy from HSDirs
10:24 < wumpus> torv3 definitely improved things in that regard
10:25 < urethane> for that reason alone, users should stop using v2 :)
10:25 < vasild> they will be forced to stop using v2 very soon
10:25 < vasild> in less than a year
10:26 < jonatack> snooping of HSDir relays is improved by v3? TIL
10:26 < michaelfolkson> Ok yeah. But you need to find (supposed) Bitcoin peers in the first place. Lots of trial and error pinging?
10:26 < wumpus> michaelfolkson: that's what the hardcoded peers are for, which are updated every major version
10:27 < wumpus> michaelfolkson: it will never ping random addresses to find bitcoin peers, never :)
10:27 < michaelfolkson> Ok thanks
10:27 < sipa> and the DNS seeds
10:27 < jonatack> michaelfolkson: if you have some good addnode peers in your conf file, maybe seednode too, it makes a big difference afaict
10:28 < wumpus> you could potentially do that in 32 bit IPv4, even thn it'd likely take a long time, but it would be pointless with 32 byte addresses
10:28 < emzy> hehe
10:28 < urethane> list_of_every_ip_address.txt
10:29 < jonatack> I'm not sure there's much point in going through the "how did you review" questions
10:30 < jonatack> I did like the tests vasild added
10:30 < michaelfolkson> And Sjors' test suggestions
10:31 < vasild> I added two more (not pushed yet), guided by code coverage (seeing which line is not covered and writing test for it)
10:31 < wumpus> I only tested (have two running Torv3 nodes now) and did very light review FWIW
10:31 < michaelfolkson> What do you use for code coverage? Marco's site?
10:31 < jonatack> indeed, I think some addrv1 unit tests could be added to have equivalent coverage
10:32 < jonatack> michaelfolkson: i think vasild uses his own tool for that... vasild?
10:32 < wumpus> your code works on ARM Linux and FreeBSD x86_64
10:32 < michaelfolkson> https://marcofalke.github.io/btc_cov/
10:32 < vasild> michaelfolkson: no, I run clang's tools and then a script to hilight which lines in the coverage report have been modified by the patch
10:33 < vasild> https://github.com/vasild/filter_coverage
10:33 < michaelfolkson> Cool, thanks
10:33 < vasild> if some of travis or cirus can publish build products that can be integrated in CI
10:33 < jonatack> Q: When should the new sendaddrv2 message type, aka "send me addrv2", be sent?
10:34 < vasild> I mean - if during build we create coverage.html that can be browsed later
10:34 < pinheadmz> I modified a plugin for sublime text for better side-by-side diff'ing: https://github.com/CJTozer/SublimeDiffView/pull/73
10:34 < brikk> i looked at adding a test for the padding=false case
10:34 < pinheadmz> makes it more like github side-by-side with the benefit of being able to scroll up and down past blobs of diff
10:35 < vasild> pinheadmz: and runs locally (I guess)! :)
10:35 < pinheadmz> yeah i always pull the branch
10:35 < jonatack> pinheadmz: i'm afraid you lost me with "more like GitHub"
10:35 < pinheadmz> mmm, in github "files changed" view, in side-by-side mode
10:36 < vasild> jonatack: that is a good question :)
10:36 < jonatack> vasild: which one, sendaddrv2 message?
10:36 < pinheadmz> thats how i like to review. but on github it only shows you the blbos that are different, i prefer to be able to scroll up and down the file (witihout clickthe expansion buttons)
10:36 < vasild> as early as possible :)
10:36 < vasild> yes, sendaddr
10:36 < vasild> v2     
10:37 < jonatack> vasild: i thought troygiorshev wrote an interesting comment on that here https://github.com/bitcoin/bips/pull/907/files#r476667308
10:37 < jonatack> saying "sendaddrv2 SHOULD be sent after receiving the verack message from the peer" wasn't quite precise enough
10:38 < vasild> but we can't send it early enough to get the addrfrom in v2 format :(
10:38 < michaelfolkson> Yeah good comment
10:39 < jonatack> vasild: hmmmmm
10:39 < vasild> addrfrom which is part of the version message
10:39 < wumpus> jonatack: don't know why it's not precise enough; you can't quote say "before any other messages" because other BIPs might also introduce these kind of upgrade messages
10:40 < sipa> vasild: i think addrfrom is effectively unused?
10:40 < michaelfolkson> But Troy's point I think is to be clear on whether that means immediately after or at any point in time after
10:40 < wumpus> it's unused and always send as 127.0.0.1
10:40 < wumpus> only addrto is used
10:40 < wumpus> michaelfolkson: as I understood it, it can be any time after
10:41 < vasild> sipa: hm, right, it is just read from the stream and then discarded, even better!
10:41 < wumpus> michaelfolkson: there are no defined phases after VERACK
10:41 < michaelfolkson> Yup. So Troy wanted the comment to make that clear (that's my reading of it anyway)
10:42 < sipa> oh, but addrMe is used
10:42 < sipa> that's annoying
10:42 < sipa> it'     
10:42 < troygiorshev> michaelfolkson: yup that's it!
10:42 < sipa> it's used to classify our local addresses
10:42 < wumpus> yes, that one is used
10:43 < jonatack> michaelfolkson: right. i just sort of wonder, "should", as opposed to what
10:43 < sipa> so... should BIP155 define a replacement?
10:43 < troygiorshev> I'm more looking to clarify (or specify) that there are no phases after VERACK.
10:43 < wumpus> though many implementations just send it as 127.0.0.1 no matter what
10:44 < wumpus> sipa: I thought about it but really didn't want to change the version message
10:44 < sipa> wumpus: i mean, the sendaddrv2 message or whatever could contain "oh btw, the address i used to connect to you is X (in addrv2 serialization)"
10:44 < wumpus> (and I'm happy about that because even changing the network version was super controversial)
10:45 < sipa> and the addrMe field in version would become a dummy
10:45 < wumpus> sipa: that would be possible yes
10:47 < wumpus> it definitely couldn't hurt
10:47 < vasild> makes sense to me, that would need some adjustment to the BIP and the last commit in https://github.com/bitcoin/bitcoin/pull/19031/commits "net: advertise support for ADDRv2 via new message"
10:48 < vasild> there was some other proposal to add info to the sendaddrv2... what was it...
10:48 < wumpus> whether a node partakes in addr broadcasting at all
10:48 < sipa> heh the current BIP doesn't even include sendaddrv2?
10:48 < wumpus> gmaxwell's proposal
10:48 < vasild> right!
10:48 < wumpus> sipa: it's in vasild 's update PR
10:48 < jonatack> others: i think we are talking about PushNodeVersion() in net_processing.cpp
10:49 < wumpus> at some point we decided only the merge the updates to the BIP when the implementation was finalized
10:49 < vasild> sipa: that is in https://github.com/bitcoin/bips/pull/907
10:49 < jonatack> BIP update PR: https://github.com/bitcoin/bips/pull/907
10:50 < vasild> and another one: https://github.com/bitcoin/bips/pull/967 :)
10:50 < wumpus> why are there more than one?
10:51 < jonatack> thanks, i had not seen PR 967
10:51 < wumpus> I mean, I think it's easier to have the proposed version of the BIP in one place
10:51 < sipa> you should ask luke-jr to merge those
10:51 < sipa> future changes can always be new PRs
10:51 < wumpus> well some other people claimed it would be better to merge only when things were sure/decided in the implementation
10:51 < sipa> i have been commenting on #907, not realizing it was a PR with a lot of changes in it already
10:52 < wumpus> don't have a strong opinion about it
10:52 < sipa> oh, ok
10:52 < vasild> 907 started being a moving target, invalidating ACKs all the time, so I decided to not update it with the stuff from 967, also 907 contains mods which have been agreed on. While 967 has got zero discussion so far. I did not want to add some controversal stuff to the settled 907
10:52 < wumpus> but yes, having multiple PRs is really confusing here
10:52 < sipa> well, there is a BIP - it's confusing if there are multiple places where the currently-discussed version is held
10:52 < sipa> it has a number already; ideally that number means just one thing
10:52 < sipa> (or at least, one thing at any given point in time)
10:53 < wumpus> but having a lot fo small merges to the BIP wouldn't be great either
10:53 -!- vindard [~vindard@200.7.91.20] has quit [Ping timeout: 240 seconds]     
10:53 < michaelfolkson> Why does it matter?
10:53 < wumpus> it clutters the BIP repostiory
10:53 < wumpus> it's not meant for incremental development
10:54 < wumpus> you can have have the in-progress BIP somewhere else
10:54 -!- vindard [~vindard@190.83.165.233] has joined #bitcoin-core-pr-reviews     
10:54 < urethane> increases the mental cost of review and discussion
10:54 < sipa> vasild: fwiw, whether a BIP change gets merged is solely up to the author(s) and editor
10:54 < sipa> you don't need acks from anyone
10:54 < michaelfolkson> Hmm I'd have thought it was inevitable in cases such as this. Changes invalidate previous ACKs etc
10:54 < jonatack> ISTM the BIP has different versions as well: https://github.com/bitcoin/bips/blob/9286b5254317d9e73fb25c5f0acd2b2d9937843e/bip-0155.mediawiki vs https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki
10:54 < vasild> sipa: :-O
10:54 < jonatack> i've been reading the first one
10:55 < sipa> it's a proposal, you decide what the proposal is
10:55 < wumpus> it's nice to have ACKs from other people though
10:55 < sipa> wumpus: since you're the author, you should ack these changes ;)
10:55 < sipa> (or not)
10:56 < wumpus> I have (but not openly I guess)
10:56 < wumpus> I've always discussed with vasild about this
10:56 < sipa> of course
10:56 < michaelfolkson> Ok understood. So it is up to the author (vasild) to ask Luke to merge changes whenever vasild is happy with them
10:56 < sipa> michaelfolkson: wumpus, actually
10:56 < sipa> just saying - luke-jr's is probably just waiting for wumpus to ACK them
10:56 < vasild> I am the author of the PR, but not the BIP
10:56 < michaelfolkson> Ah yes sorry
10:57 < urethane> 3 minutes left :)
10:57 < wumpus> yes, I'll ACK them, np
10:58 < wumpus> as said, I had the impression that everything was in one PR, which tracked the new version of the BIP, which we'd merge when there was agreement on the implementation
10:58 < michaelfolkson> Did we cover all of Jon's questions?
10:58 < jonatack> PRs which also pick up work by dongcarl as well, and sipa for the crypto... it's a team effort
10:58 < wumpus> exactly because all kind of things come up during this
10:58 < vasild> sendaddrv2(your address is X, I promise to participate to gossip (but I may lie to you))
10:58 < jonatack> michaelfolkson: no, but the discussion was worth it
10:58 < michaelfolkson> Haha we did BAD
10:59 -!- epson121 [d5953d67@213.149.61.103] has quit [Remote host closed the connection]     
10:59 < jonatack> michaelfolkson: the variable-length question was a bit of a trick question
10:59 < jonatack> to check understanding
10:59 < jonatack> The addresses defined in BIP155 are of fixed size.
10:59 < jonatack> We don't actually handle any "variable-length" ones, just addresses of varying fixed lengths.
10:59 < jonatack> Why was the boolean pad parameter added to EncodeBase32()?
11:00 < jonatack> this seemed interesting
11:00 < jonatack> neither vasild nor i know
11:00 < jonatack> According to vasild: "that was ugly :/ but needed as some === signs appeared at the end of i2p addresses"
11:00 < brikk> thats how i see it too
11:00 < michaelfolkson> Hmm     
11:00 < sipa> i probably implemented some standard base32 format, which includes the requirement to pad with = symbols
11:00 < brikk> but will there be side effects ?
11:00 < jonatack> for now, it's important to have the code recognize i2p addresses with the correct length and gossip them
11:00 < sipa> and I2P uses a slightly different standard that omits the padding
11:00 < jonatack> so that when we add full i2p support, assuming it happens later on,
11:00 < jonatack> then previous releases (beginning with the next one containing this code) can gossip i2p addresses
11:01 < brikk> i looked into a test for it to make sure it behaves, because there was none that I could find
11:01 < vasild> I guess the decode must be prepare to see non-multiple-of-8 input and pad it itself with = before decoding (once we start parsing i2p addresses)
11:01 < jonatack> brikk: great
11:01 < wumpus> to be clear, I2P support is not a goal for the initial PR
11:02 < jonatack> right, for later on
11:02 < jonatack> BHow do you think Bitcoin Core should make the transition from Tor v2 to v3? All at once, or v3 first opt-in, then default (and v2 opt-in or deprecated)?
11:02 < sipa> i don't think we should relay I2P addresses before there is support
11:02 < wumpus> we'd like torv3 support as soon as possible, I2P would be nice but can be done later if the gorundwork is done
11:02 < brikk> so is the pr doing a bit too much at this point?
11:02 < jonatack> Should we just bump to v3, or go thru first v3 opt-in, v2 default...
11:03 < wumpus> jonatack: first both, imo
11:03 < michaelfolkson> jonatack: So definitely not all at once. I'd say opt-in and then default
11:03 < sipa> brikk: the BIP defines I2P, so it makes sense to include the BIP-defined checks for it
11:03 < wumpus> jonatack: opt in is not necessary imo
11:03 < michaelfolkson> Oh     
11:03 < sipa> that doesn't mean Bitcoin Core needs to relay them
11:03 < brikk> sipa: i see
11:03 < jonatack> #endmeeting
11:03 < wumpus> jonatack: there should be no reason why you'd not want v3 but want v2, but I can see a reason for keeping the v2 open for now, for older nodes
11:03 < urethane> I don't see the motivation to make it opt-in
11:03 < wumpus> sipa: right
11:04 < jonatack> wumpus: right
11:04 < vasild> https://bitnodes.io/nodes/ -- 22% run the latest version
11:04 < michaelfolkson> So v2 would be deprecated at some point but a long time in future? Or never deprecated?
11:04 <@jnewbery> thanks jonatack! Great meeting. I didn't say much, but I found the discussion really interesting :)
11:04 < jonatack> we have 4 weeks to FF
11:04 < michaelfolkson> Thanks jonatack!
11:04 < jonatack> thanks jnewbery!
11:04 < wumpus> michaelfolkson: after Tor removes it from their codebase, we should too, I think
11:04 < vasild> michaelfolkson: tor itself will drop v2 in about a year https://blog.torproject.org/v2-deprecation-timeline
11:04 < troygiorshev> thanks jonatack!
11:05 < wumpus> thanks jonatack
11:05 < michaelfolkson> But people could be running old version of Tor?
11:05 < jonatack> please review the PR everyone :)
11:05 < emzy> Thanks jonatack!
11:05 < michaelfolkson> (even when Tor removes it)
11:05 < wumpus> michaelfolkson: uhm, Tor versions that don't support v3 are ancient by now, and actively dangerous to run
11:05 < michaelfolkson> Ok makes sense
11:05 < wumpus> they've supported it for a long time
11:06 < vasild> michaelfolkson: hmm, given that tor relays through some random tor nodes, I don't know what will happen if you run an old tor node that insists on doing v2 stuff and newer ones have dropped support for it
11:06 < sipa> torv3 is supported as of 0.3.2.9, released in january 2018
11:06 < sipa> that's not _that_ long ago
11:07 < wumpus> for Tor that's really long ago
11:07 < sipa> i guess :)
11:07 < wumpus> a lot happens there
11:07 -!- Napoleon59Emard [~Napoleon5@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
11:07 < wumpus> it's not unlike Bitcoin in that regard
11:07 < urethane> tor v2 depreciation time line https://blog.torproject.org/v2-deprecation-timeline
11:07 < vasild> I guess it may likely be impossible to reach torv2 services after https://blog.torproject.org/v2-deprecation-timeline
11:07 < jonatack> s/it's important to have the code recognize i2p addresses with the correct length and gossip them/just recognize them/
11:07 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
11:07 < sipa> vasild: i think so
11:08 < urethane> July 15th, 2021 0.4.6.x: Tor will no longer support v2 and support will be removed from the code base.
11:08 < urethane> October 15th, 2021 We will release new Tor client stable versions for all supported series that will disable v2.
11:08 < wumpus> in any case if you're still running those Tor versions by the time addrv2 is removed (and I suppose, the directories and such shut down), they won't be able to use hidden services at all I think
11:09 < sipa> i think the bigger question is when directory services etc will stop supporting v2
11:09 < vasild> sipa: my take on "gossip i2p in 0.21 is that, because only 22% run latest version, when we add i2p supprt in e.g. 0.22 then old nodes (0.21) will also gossip it
11:09 < wumpus> but I don't think bitcoind needs to support pre-addrv3 Tor
11:10 < sipa> vasild: i'm not sure that's a good idea, as nothing in the network can determine the existance of such addresses...
11:10 < vasild> sipa: worried about junk traffic?
11:10 < sipa> so little ways of purging garbage i2p someone may start rumouring
11:10 < sipa> more worried about garbage in addrmans
11:10 < vasild> hmm     
11:11 < sipa> i'd say first start gossipping it only between i2p peers, which actually have i2p connectivity
11:11 < vasild> same with torv2/torv3 addresses for a node that has no tor connectivity. Or IPv6 addresses for a node that has only IPv4 connectivity...
11:12 < sipa> once there is a tangible network, anything can start gossipping it, as it's useful to prevent partitions
11:12 < sipa> if there was a concrete plan to have i2p proxy support in the near future, maybe that could be different
11:12 -!- Napoleon59Emard [~Napoleon5@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 272 seconds]     
11:14 < wumpus> i'd say first start gossipping it only  between i2p peers, which actually have i2p connectivity <- agree
11:14 < jonatack> seems sensible
11:15 < sipa> for torv3 i think we expect a torv3-reachable set of bitcoind nodes to appear almost immediately
11:15 < wumpus> you could say so :)
11:16 < vasild> currently we gossip addresses from unreachable networks to just 1 peer (and addresses from reachable networks to 2 peers)
11:16 < sipa> vasild: 1.5!
11:16 < vasild> did it get merged?
11:16 < sipa> https://github.com/bitcoin/bitcoin/pull/19728 yup
11:17 < vasild> yes, https://github.com/bitcoin/bitcoin/pull/19728
11:17 < sipa> so i think that for "not known to exist" networks that number should probably be even lower, or 0
11:17 < vasild> so you propose to extend that logic to reachable: 2, unreachable-non-i2p 1.5, unreachable-i2p: 0
11:18 < sipa> same with cjdns
11:18 < vasild> unreachable-ipv4-ipv6-tor: 1.5
11:19 < vasild> reachable: 2, unreachable-ipv4-ipv6-torv2-torv3: 1.5, unreachable-anything-else: 0
11:22 < vasild> sipa: "more worried about garbage in addrmans" currently for a node to be able to protect itself from this it must have connectivity to all 3: ip4, ip6 and tor, right?
11:24 -!- troygiorshev [~troygiors@d67-193-140-136.home3.cgocable.net] has quit [Quit: leaving]     
11:24 < sipa> assuming some reasonable number of honest nodes, it's not that black and white
11:24 < sipa> as ipv6-capable nodes will learn about useless ipv6 addresses being rumoured, and prune them
11:25 < sipa> hmm, maybe this isn't that big of a concern
11:25 < sipa> it just feels strange to me to permit addrman space to be taken up by addresses in a network we know doesn't ezist
11:26 < vasild> I will sleep over with this, maybe limit size in addrman also based on reachable/unreachable
11:33 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has joined #bitcoin-core-pr-reviews     
11:36 < jonatack> michaelfolkson: thank you for adding to the bitcoinstackexchange answer! just saw that you mentioned it above
11:36 < sipa> he's been adding many :)
11:36 < urethane> +1     
11:38 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has quit [Ping timeout: 258 seconds]     
11:41 -!- urethane [~urethane@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: urethane]     
11:44 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
12:02 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has quit [Quit: jaybny]     
12:13 < michaelfolkson> No problem jonatack. It is really useful stuff
12:17 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
12:19 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]     
12:30 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]     
12:52 -!- musdom [~Thunderbi@202.184.190.229] has quit [Ping timeout: 260 seconds]     
13:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]     
13:00 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-pr-reviews     
13:05 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
13:06 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
13:38 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
13:42 -!- tralfaz is now known as davterra     
14:18 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has quit [Quit: jaybny]     
14:19 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
14:23 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has joined #bitcoin-core-pr-reviews     
14:23 < jonatack> the meeting log is up at https://bitcoincore.reviews/19845
14:24 -!- Fichte42 [~fichte42@213-47-47-176.cable.dynamic.surfer.at] has quit [Client Quit]     
15:08 -!- mol_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
15:09 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
15:11 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
15:12 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
15:12 -!- molz_ [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
15:14 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]     
15:17 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]     
15:28 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]     
15:37 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]     
15:38 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
15:55 -!- mol [~mol@unaffiliated/molly] has joined #bitcoin-core-pr-reviews     
16:16 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
16:16 -!- shaunsun [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 272 seconds]     
16:33 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has quit [Quit: jaybny]     
16:42 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
17:01 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has quit [Quit: jaybny]     
17:02 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has joined #bitcoin-core-pr-reviews     
17:13 -!- jaybny [~jaybny@c-73-162-160-252.hsd1.ca.comcast.net] has quit [Quit: jaybny]     
17:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
17:34 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
18:03 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
18:03 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
18:15 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:7100:a9d6:e349:d9ad] has joined #bitcoin-core-pr-reviews     
18:45 -!- seven_ [~seven@2a00:ee2:410c:1300:19fc:c12a:d398:d4c3] has quit [Ping timeout: 272 seconds]     
19:37 -!- musdom [~Thunderbi@202.184.190.229] has joined #bitcoin-core-pr-reviews     
20:37 -!- worc3131 [~quassel@2a02:c7f:c026:9500:7d0b:65d0:38a4:4786] has quit [Ping timeout: 272 seconds]     
20:47 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
20:47 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
20:55 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:7100:a9d6:e349:d9ad] has quit [Ping timeout: 244 seconds]     
21:10 -!- da39a3ee5e6b4b0d [~textual@2403:6200:8876:37d7:55fb:4d37:ffc2:715b] has joined #bitcoin-core-pr-reviews     
21:29 -!- kristapsk___ [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]     
21:45 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Read error: Connection reset by peer]     
21:45 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
21:59 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
21:59 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
22:45 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
22:45 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
22:46 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
22:46 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
22:47 -!- S3RK [~s3rk@47.246.66.112] has quit [Remote host closed the connection]     
22:47 -!- S3RK [~s3rk@47.246.66.112] has joined #bitcoin-core-pr-reviews     
23:17 -!- tralfaz [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-pr-reviews     
23:18 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]