--- Day changed Wed Jan 13 2021
00:00 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
00:31 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]     
00:45 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
00:46 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
00:52 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
00:58 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
02:04 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Remote host closed the connection]     
02:04 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews     
02:19 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 256 seconds]     
02:27 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]     
02:36 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has joined #bitcoin-core-pr-reviews     
02:58 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has quit [Ping timeout: 264 seconds]     
03:00 -!- norisgOG [~norisgOG@89.45.6.108] has joined #bitcoin-core-pr-reviews     
03:18 -!- Karine11Armstron [~Karine11A@static.57.1.216.95.clients.your-server.de] has joined #bitcoin-core-pr-reviews     
03:23 -!- Karine11Armstron [~Karine11A@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 240 seconds]     
04:55 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has joined #bitcoin-core-pr-reviews     
05:22 -!- ecola [~3cola@95.175.17.147] has joined #bitcoin-core-pr-reviews     
05:22 -!- norisgOG [~norisgOG@89.45.6.108] has quit [Ping timeout: 240 seconds]     
05:27 -!- norisgOG_ [~norisgOG@89.45.6.92] has joined #bitcoin-core-pr-reviews     
05:29 < norisgOG_> Hello all I have a question concering signatures in bitcoin, where in the transaction can I see which HASH_Type I have to use to calculate the transaction hash ?
06:14 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
06:17 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]     
06:20 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]     
07:12 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
07:18 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has joined #bitcoin-core-pr-reviews     
07:30 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined #bitcoin-core-pr-reviews     
07:35 < michaelfolkson> norisgOG_: For P2PKH https://bitcoin.stackexchange.com/questions/37125/how-are-sighash-flags-encoded-into-a-signature
07:39 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-pr-reviews     
07:45 -!- pitchas [bfb5393f@191.181.57.63] has joined #bitcoin-core-pr-reviews     
07:46 < michaelfolkson> Or this, also for P2PKH. After the signature https://www.siliconian.com/blog/16-bitcoin-blockchain/22-deconstructing-bitcoin-transactions
07:59 < norisgOG_> michaelfolkson merci beaucoup :)
08:05 -!- SN55 [3e2b34c6@62.43.52.198.dyn.user.ono.com] has joined #bitcoin-core-pr-reviews     
08:08 -!- SN55 is now known as S3CR375     
08:23 -!- pinheadmz [~pinheadmz@68.161.139.178] has quit [Remote host closed the connection]     
08:23 -!- pinheadmz [~pinheadmz@68.161.139.178] has joined #bitcoin-core-pr-reviews     
08:26 < dhruvm> Hi everyone! We will get started with PR review club for #19825: Simpler setban and new ban manipulation commands in 34 minutes.
08:26 -!- S3CR375 [3e2b34c6@62.43.52.198.dyn.user.ono.com] has quit [Ping timeout: 248 seconds]     
08:26 < pinheadmz> dhruvm great! p.s. can you see my messages? Im having weird IRC issues today
08:26 < dhruvm> pinheadmz: yes
08:27 < pinheadmz> w00t
08:30 -!- oxtr [~tommy@13.84-234-189.customer.lyse.net] has joined #bitcoin-core-pr-reviews     
08:30 -!- oxtr1 [54eabd0d@13.84-234-189.customer.lyse.net] has joined #bitcoin-core-pr-reviews     
08:34 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has joined #bitcoin-core-pr-reviews     
08:36 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:39 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:18d1:c1a9:13be:6f9e] has joined #bitcoin-core-pr-reviews     
08:47 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:18d1:c1a9:13be:6f9e] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
08:50 -!- oxtr1 [54eabd0d@13.84-234-189.customer.lyse.net] has quit [Quit: Connection closed]     
08:57 -!- AnthonyRonning [3480306a@52.128.48.106] has joined #bitcoin-core-pr-reviews     
08:59 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has joined #bitcoin-core-pr-reviews     
08:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]     
08:59 -!- jadi [~jadi@178.131.52.33] has quit [Remote host closed the connection]     
09:00 < dhruvm> #startmeeting
09:00 -!- enjoying [~enjoying@195.181.160.175.adsl.inet-telecom.org] has joined #bitcoin-core-pr-reviews     
09:00 < glozow> hai     
09:00 < emzy> hi     
09:00 < dhruvm> Hello everyone! Welcome to the PR Review Club for #19825: rpc: simpler setban and new ban manipulation commands.
09:00 < _0x0ff> hey     
09:00 < enjoying> hi     
09:00 < norisgOG_> hi     
09:00 < dhruvm> Please say hi so everyone knows who is in attendance.
09:00 < AnthonyRonning> hi     
09:00 -!- andozw [496d3971@73.109.57.113] has joined #bitcoin-core-pr-reviews     
09:00 < theStack> hi     
09:00 < felixweis> hey hey heyyy
09:00 < murtyjones> hi     
09:00 < oxtr> hi guys
09:00 < thomasb06> hi     
09:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
09:00 < dhruvm> Anyone here for the first time?
09:00 < jnewbery> hi     
09:00 -!- anir [40bba0b7@64.187.160.183] has joined #bitcoin-core-pr-reviews     
09:00 -!- effexzi [uid474242@gateway/web/irccloud.com/x-fwgfmvfauhwvcdwo] has joined #bitcoin-core-pr-reviews     
09:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
09:00 < amiti> hih     
09:01 < _0x0ff> this will be my first
09:01 < dhruvm> Welcome _0x0ff !
09:01 < setpill> hi     
09:01 < enjoying> welcome _0x0ff
09:01 < dhruvm> A reminder of meeting convention: When you have a question, don't ask to ask, just ask.
09:01 < anir> hey everyone
09:01 < michaelfolkson> hi     
09:01 < jnewbery> welcome _0x0ff!
09:01 < setpill> sorta kinda first time
09:01 < schmidty> howdy
09:01 < dhruvm> welcome setpill !
09:01 < effexzi> Hi     
09:01 < jnewbery> sorta welcome setpill!
09:01 < ecola> hi     
09:01 < _0x0ff> thanks everyone, happy to join!
09:01 < oxtr> This is my first time dhruvm
09:02 < dhruvm> hi oxtr !
09:02 < jnewbery> welcome oxtr :)
09:02 < dhruvm> Did everyone get a chance to review the PR? How about a quick y/n from everyone
09:02 < glozow> y     
09:02 < _0x0ff> y     
09:02 < murtyjones> y (briefly)
09:02 < AnthonyRonning> y     
09:02 < setpill> y     
09:02 < felixweis> y     
09:02 < ecola> n     
09:02 < thomasb06> y     
09:02 < anir> y     
09:02 < theStack> n     
09:02 < emzy> n     
09:02 < enjoying> y     
09:02 < norisgOG_> 1/2 y
09:02 < effexzi> N     
09:02 < oxtr> n     
09:02 < dhruvm> Awesome, let's get started.
09:02 < dhruvm> Q: What are some use cases for banning specific IP addresses or subnets?
09:03 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
09:03 < emzy> Ban a known IP address/network that is misbehaving or you don’t like. For example chain analyses companies.
09:03 < jonatack> hi     
09:03 < felixweis> maybe you want to not allow connections from/to certain cloud providers. they have a lot of ip ranges
09:03 < thomasb06> it's rather for not up-to-date nodes or bugged nodes
09:03 < AnthonyRonning> Ban nodes not sending blocks or nodes attempting to swarm your node.
09:03 < ccdle12> hi     
09:03 < anir> to keep the network healthy from bad actors such as spy nodes
09:03 < theStack> e.g. if nodes misbehave (i.e. violate the protocol) and discouragement them is not enough for us
09:03 < theStack> *discouraging
09:04 < ecola> avoid being eclipsed
09:04 < dhruvm> that's right emzy felixweis anir theStack !
09:04 -!- larryruane_ [uid473749@gateway/web/irccloud.com/x-tuzsiyftnkimzhqh] has joined #bitcoin-core-pr-reviews     
09:04 < dhruvm> Those are all great answers! As an example, we may want to ban addresses or subnets that are used by crawlers like bitnodes.io, etc. There are people in the bitcoin community that maintain banlists shared widely.
09:05 < dhruvm> thomasb06: we use consensus rules and eviction logic for that
09:05 < thomasb06> ok     
09:05 < dhruvm> AnthonyRonning: peers not sending blocks are rotated out using eviction logic
09:05 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
09:05 < dhruvm> (if necessary)
09:05 < AnthonyRonning> good to know!
09:05 -!- Caralie [185a59be@cpe-24-90-89-190.nyc.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:05 < dhruvm> Q: Is automatic banning/disconnection an effective DoS countermeasure for misbehaving peers?
09:06 < jnewbery> ecola: banning IP addresses wouldn't protect you from being eclipsed
09:06 < murtyjones> To some extent, although IPs can be rotated.
09:06 < thomasb06> if the network is dense, it's efficient: a node can always find other nodes to gossip
09:06 < norisgOG_> dhruvm I guess its very cheap to change Ip addresses so I am a bit sceptic
09:06 < ccdle12> nope, it's pretty cheap for an attacker to use another IP address
09:06 < setpill> if there is a DoS vuln in bitcoin core you are not going to protect against it with selective bans,
09:06 < theStack> i think that question is also answered in the notes: "Neither banning nor discouragement fully protect against a determined attacker, since IP addresses are inexpensive."
09:06 < AnthonyRonning> maybe for low hanging fruit but not for persistent attackers due to IP's
09:06 < michaelfolkson> "we may want to ban addresses or subnets that are used by crawlers like bitnodes.io" Do people actually do this?
09:06 < setpill> it might work against a DDoS if the ip range is small
09:07 < felixweis> i was wondering, with asmap, could we also have ban behaviour where we ban certain ASes?
09:07 < anir> No because doing so risks splitting the network
09:07 < michaelfolkson> Monitor which addresses are on bitnodes and ban them?
09:07 < emzy> Yes. But doesn’t protect against an attacker fully.
09:07 < _0x0ff> can automatically banning (if flaswed logic) cause a split?
09:08 < dhruvm> murtyjones norisgOG_ ccdle12 setpill theStack you got it!
09:08 < dhruvm> Automatic banning/disconnection is not an effective DoS countermeasure as the primary key for banlists are IP addresses that are inexpensive. An attacker can change their banned identity for ~$0.01 per hour.
09:08 < glozow> _0x0ff: yes, if you were programmatically banning based on a rule that isn't consistent throughout the network
09:08 < dhruvm> michaelfolkson: i try pretty hard to ban bitnodes :)
09:08 < glozow> er by "you" i mean some part of the network
09:08 < enjoying> michaelfolkson I think dhruvm was saying, ban peers which are bitnodes, not ban nodes that are listed on bitnodes
09:08 < AnthonyRonning> what kind of information does bitnodes try to abuse?
09:09 < dhruvm> enjoying: yes
09:09 < felixweis> maybe give the rpc a single ip inside an AS we want to discourage connections to/from and then the system does a lookup into the ASMAP and deduces the rest
09:09 < dhruvm> AnthonyRonning: I don't know if they abuse it. Just seems strange. I'd rather they not know all the nodes.
09:10 < dhruvm> felixweis: today we only have ip and subnet bans. I know ASN bans have been discussed in the past.
09:10 < AnthonyRonning> are tor bans separate?
09:10 < enjoying> having dossiers on network topology isn't healthy for adversarial operating coniditions
09:10 < felixweis> oh ok. thanks dhruvm
09:10 < michaelfolkson> I would guess that would be really really hard. You need to not connect to nodes that might gossip your address to bitnodes
09:10 < emzy> AnthonyRonning: no way to ban clients from tor seperatly.
09:11 < AnthonyRonning> interesting
09:11 -!- sishir [465dca45@cpe-70-93-202-69.natsow.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:11 < emzy> AnthonyRonning: that's by design
09:11 < dhruvm> michaelfolkson: your addr might be gossiped but if they can't verify the node exists, they don't really know if the gossip is accurate
09:11 < enjoying> emzy ban torrents *using* tor or ban peers connecting to you through tor ?
09:12 < dhruvm> some of the conversation is leading nicely into the next question:  How can automatic banning/disconnection be abused by an attacker, or create a network split?
09:12 < enjoying> dhruvm I think verifying the node exists is less of a need, surveillance's goal is just to winnow the full set down to a more manageable set to go after
09:13 < thomasb06> when a subnet is banned, it hides trustworthy nodes
09:13 < enjoying> ban peers using tor*
09:13 < AnthonyRonning> If there’s honest nodes on a subnet, a user could unintentionally ban the whole subnet an attack is using.
09:13 < dhruvm> enjoying: wouldn't that leave surveillance open to a saturation attack with garbage addr calls?
09:14 < setpill> if everyone programmatically bans a subnet that subnet is cut off
09:14 < setpill> bans the same* subnet
09:14 < _0x0ff> one misbehaving node could cause a ban of a subnet that belongs to other well behaving nodes
09:14 < glozow> how would you get everyone to ban a specific subnet?
09:14 < setpill> if it was included in bitcoin core
09:15 < enjoying> dhruvm it would but would you agree, gossiped peer ip's that aren't actual nodes would be more surprising than them being actual nodes?
09:15 < theStack> glozow: if it was automatic banning (there isn't, i guess because of the mentioned reasons :))
09:16 < felixweis> dont think its possible right now, but if there would be logic that once you have many attacks coming from the same subnet but constantly changing ip suffixes it might feel like a mitigation
09:16 < dhruvm> thomasb06 setpill _0x0ff: automatically banning a subnet for a misbehaving ip wouldn't really make sense. How would you select how large to make the subnet?
09:16 < setpill> dhruvm: that wasn't the question ;)
09:16 < dhruvm> enjoying: not really - it could be due to network settings, full slots, and many other reasons.
09:16 < thomasb06> dhruvm: if several banned ip are in the same subnet
09:17 -!- SN21 [3e2b34c6@62.43.52.198.dyn.user.ono.com] has joined #bitcoin-core-pr-reviews     
09:17 < glozow> wait are we talking about a hardcoded automatic subnet ban, or are we talking about a programmatic rule for banning based on some misbehavior?
09:17 < dhruvm> glozow: the latter
09:17 < setpill> glozow: I was talking about the latter
09:18 < setpill> Also talking about how it could *accidentally* lead to a netsplit rather than being abused by an attacker
09:18 < glozow> o ok mhm
09:18 < jnewbery> I think the question might be better phrased as "how *could* automatic banning..." We don't do automatic banning in Bitcoin Core. Why not?
09:18 < setpill> I guess an attacker could read the hypothetical bitcoin core ban rules and create a situation that triggers them for a subnet
09:19 < _0x0ff> exactly, it was just a hypotetical issue that could occur if it were implemented
09:19 < emzy> enjoying: there is no from address in tor. So you can ban all clients or none.
09:19 < setpill> (And this is why they aren't used)
09:19 < dhruvm> setpill: you've got it. sorry for the question wording.
09:19 < thomasb06> with an automatic banning, a node can become isolated
09:19 < _0x0ff> automatic banning can also be very opinionated I guess
09:19 < dhruvm> Automatic banning/disconnection can increase network partition risk if not implemented well. Segwit activation can illustrate this risk. Upgraded segwit nodes had stricter validation rules. If they punished older nodes that published invalid blocks(containing invalid segwit transactions), we would have partition risk. Luckily nodes are not punished in such cases after a recent consensus
09:20 < dhruvm> change.
09:20 < dhruvm> See: https://github.com/bitcoin/bitcoin/blob/7b975639ef93b50537a3ec6326b54d7218afc8da/src/net_processing.cpp#L1076
09:20 -!- SN21 [3e2b34c6@62.43.52.198.dyn.user.ono.com] has quit [Client Quit]     
09:20 < setpill> ahhh yeah segwit is a good case
09:20 -!- SN27 [3e2b34c6@62.43.52.198.dyn.user.ono.com] has joined #bitcoin-core-pr-reviews     
09:21 < jnewbery> dhruvm: this is a very important point. Everyone should try to understand it!
09:21 -!- SN27 is now known as S3CRE75     
09:21 < theStack> interesting. curious now to find out how exactly "recent" is defined
09:21 < norisgOG_> dhruvm are you talking about an attack, if older node would construct invalid segwit tx?
09:21 < jnewbery> If there's some rule that would cause Bitcoin Core to ban connections, then it could potentially be used to partition the network
09:22 < setpill> norisgOG_: it would be an attack, a malicious entity could feed innocent pre-segwit nodes bad segwit txes that would lead to them being cut off by segwit nodes
09:22 < dhruvm> norisgOG_: an older node, with less strict rules, could consider an invalid segwit tx input to be valid.
09:22 < norisgOG_> setpill thanks
09:23 < norisgOG_> dhruvm got it
09:23 < norisgOG_> thx     
09:23 < glozow> fascinating, so scary
09:23 < enjoying> emzy I think I'm not understanding something, are you saying that peers to connect through an onion address aren't specified in a manner we can selectively tell the node, "disconnect peer at jx2o6mp3dtql4bn2.onion" for example?
09:23 < norisgOG_> you are talking about recent, does it change after some time
09:23 < _0x0ff> i didn't consider the code in net_processing, i understand what you mean now
09:23 < dhruvm> in that example, neither node is dishonest. we have to be careful in the definition of honesty.
09:23 < jnewbery> The risk was more in a block containing an invalid segwit transaction. Old nodes would reject unconfirmed segwit transactions because of policy, but they'd accept blocks containing segwit transactions (which is what makes segwit a soft fork)
09:24 < anir>  what happens if the network partitions?
09:24 < setpill> dhruvm: but invalid segwit txes don't create themselves, so there would be a dishonest entity involved somewhere, right?
09:24 < dhruvm> anir: hash rate is split and network security with it.
09:24 < enjoying> anir decreased effective hashrate. possibility of double spends,
09:24 < jnewbery> anir: there's no longer consensus of what the state of the ledger is
09:24 < emzy> enjoying: yes there is no from address. Only hidden services have an to address.
09:25 < dhruvm> setpill: maybe, but it's not the relaying node
09:25 < michaelfolkson> There is a difference between chain split (half the network follows one chain, half the network another) due to one disputed SegWit transaction and peers banning other peers for sending a particular transaction
09:25 < setpill> dhruvm: true
09:25 < dhruvm> ok, let's keep rolling
09:25 < dhruvm> Q: Would well-formed `setban ip add`/`setban ip remove` RPC calls ever throw an error? Should they?
09:26 < glozow> u mean on master?
09:26 < dhruvm> glozow: right, on master
09:26 < _0x0ff> If user is adding/removing things in as it's expected it shouldn't. Errors should only be thrown when user is trying to add/remove something ambiguous
09:26 < murtyjones> They could (and I think should) throw errors for malformed data being passed in
09:26 < emzy> enjoying: they look like this: "127.0.0.1:57372"
09:26 < dhruvm> _0x0ff: can you verify that with the code here? https://github.com/bitcoin/bitcoin/blob/22fa9673b02edf512d2a9fecf403955d225b97e5/src/rpc/net.cpp#L707
09:27 < AnthonyRonning> In master, it does throw an error if the IP is already banned. I don't think it should because the intent is still correct even if already banned.
09:27 < enjoying> emzy because bitcoind is proxying through the tor service on the box?
09:27 < felixweis> it might stop scripts that feed a list into the rpc if the script exits on error
09:27 < ccdle12> raised errors should be for something serious that justifies an exit
09:27 < _0x0ff> ah, i didn't know we need to answer for what would happen with what's on master now. My answer was how it should be implemented.
09:27 < emzy> enjoying: yes it looks like localhost 127.0.0.1
09:28 < dhruvm> AnthonyRonning: ccdle12: exactly right!
09:28 < dhruvm> On master, `setban ip add` throws an error if a subnet is already banned (as an ip or is a member of a banned subnet), and `setban ip remove` throws an error if we are trying to unban an ip/subnet that is not banned.
09:28 < setpill> master throws JSONRPCError if the ip/subnet was already banned
09:28 < dhruvm> #19825 takes the stance that no well-formed ban/unban instruction is illegal.
09:28 < dhruvm> setpill: yup!
09:28 < emzy> I get this: "error code: -23 / error message: / Error: IP/Subnet already banned"
09:28 < felixweis> emzy: is it possible to make them look like they come from a different ip than 127.0.0.1? to differentiate them from local programs.
09:29 < dhruvm> Q: On master, what happens if you try to ban the same IP address twice? How does this affect the UX for ban scripts?
09:29 < dhruvm> (some of you have already answered the first part)
09:29 < glozow> yeah it sounds inconvenient to error when there's not really anything wrong with the script
09:29 < sishir> What about throwing an error after an updated as described by gmaxwell? https://github.com/bitcoin/bitcoin/pull/19825#issuecomment-683372477
09:29 < _0x0ff> An error is thrown, which means ban scripts need to take that error into account and then remove the ban and re-add it. This complicates ban scripts because a narrower ban would be rejected in case there's a wider ban taken into effect and handling this is a mess.
09:29 < glozow> oh hey sishir
09:29 < emzy> felixweis: I think there is already someting like that in place. I'm not sure,
09:30 < sishir> hello glozow
09:30 < dhruvm> felixweis: glozow: _0x0ff: correct!
09:30 < dhruvm> Banning an already banned address throws an rpc error: https://github.com/bitcoin/bitcoin/blob/7b975639ef93b50537a3ec6326b54d7218afc8da/src/rpc/net.cpp#L710
09:30 < AnthonyRonning> Error is thrown in master, it makes it complicated for scripts to complete without error if they're pulling from a list and don't know exact state of the banlist.
09:30 < dhruvm> this means that ban scripts are not idempotent
09:31 < dhruvm> and scripts would exit on error making life harder
09:31 < glozow> was there consideration for printing a warning or something? like "just fyi these were already banned"
09:31 < glozow> just curious, not really suggesting that
09:32 < dhruvm> glozow: it seems unnecessary as the user intent is already accomplished
09:32 < dhruvm> a well-formed ban/unban instruction can't be illegal
09:33 < dhruvm> Alright, next question.
09:33 < dhruvm> Q: Before this PR, if setban 192.168.1.1/24 add is followed by setban 192.168.1.1 add, an error is thrown. However you can setban 192.168.1.1/32 add. Why does this happen?
09:33 < emzy> This are separate lists. BanMan::Ban(CNetAddr&) and BanMan::Ban(CSubNet&)
09:33 < AnthonyRonning> because /32 includes more IP’s in the subnet than /24 while 192.168.1.1 is already banned
09:33 < setpill> because setban [..]/32 is a broader range, so it is not already banned by /24, so it isnt considered an error
09:33 < _0x0ff> Because the /24 ban is wider and banman doesn't reject the narrower ban.
09:33 < dhruvm> emzy: they are added to the same ban list, but via different functions
09:33 -!- AnthonyRonning [3480306a@52.128.48.106] has quit [Quit: Connection closed]     
09:34 -!- AnthonyRonning [3480306a@52.128.48.106] has joined #bitcoin-core-pr-reviews     
09:34 < dhruvm> AnthonyRonning: /32 is 1 ip address, /24 is 256 addresses
09:34 < AnthonyRonning> ohhh, got those mixed up
09:35 < setpill> I made the same error lol
09:35 < norisgOG_> dhruvm how often are these lists refreshed, in which thread do they run?
09:35 < setpill> oh     
09:35 < dhruvm> Can you follow through to the `IsBanned` calls here: https://github.com/bitcoin/bitcoin/blob/22fa9673b02edf512d2a9fecf403955d225b97e5/src/rpc/net.cpp#L709 and investigate why this may be happening?
09:35 < setpill> I get it
09:35 < setpill> subnet bans are checked for *exact match* whereas ip bans are checked if they are contained in a subnet ban
09:36 < dhruvm> norisgOG_: the lists are kept in memory and marked as dirty to persist to disk upon change
09:36 < dhruvm> See `BanMan::DumpBanList`
09:36 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]     
09:37 < dhruvm> setpill: that's correct!
09:37 < dhruvm> On master, `BanMan::IsBanned(CNetAddr&)` checks if the provided ip address is a member of any banned subnet. However, `BanMan::IsBanned(CSubNet&)` only checks for exact matches: https://github.com/bitcoin/bitcoin/blob/master/src/banman.cpp#L77-L104. Since the rpc code for setban checks `IsBanned` prior to banning, the behavior is different for ip addresses and subnets.
09:37 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has joined #bitcoin-core-pr-reviews     
09:37 < AnthonyRonning> Is there any particular reason for that? Couldn't it deduce that there's no reason to add a smaller subnet if the larger is already banned?
09:38 < dhruvm> emzy: both ip addresses and subnets are stored in the same ban list. they are both stored as subnets.
09:38 < dhruvm> AnthonyRonning: just how the code happens to be structured on master. #19825 changes everything to be CSubNet calls.
09:38 < setpill> AnthonyRonning: actually sishir just linked a comment by gmax that smaller subnet bans still make sense if they are longer duration than the bigger subnet ban
09:39 < AnthonyRonning> yeah if they are longer, it makes sense.
09:39 -!- sishir [465dca45@cpe-70-93-202-69.natsow.res.rr.com] has quit [Quit: Connection closed]     
09:39 -!- sishir [465dca45@cpe-70-93-202-69.natsow.res.rr.com] has joined #bitcoin-core-pr-reviews     
09:40 < dhruvm> AnthonyRonning: setpill: longer, narrower bans and shorter, wider bans make sense and there is potential to consolidate ban entries. However #19825 no longer consolidates.
09:41 < dhruvm> So, that leads us to ask: Are there any downsides to allowing overlapping ban entries as this PR does?
09:41 < AnthonyRonning> Possible internal overhead in tracking bans with minor differences, each requiring a lock and write to a file when added.
09:41 < setpill> Very mild inefficiency
09:41 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
09:41 < emzy> It will be hard to implement this logic into a program that uses the RPC.
09:41 < setpill> what logic?
09:42 < dhruvm> AnthonyRonning: setpill: yes!
09:42 < dhruvm> emzy: that's right. any consolidation in ban entries can confuse scripts that are trying to maintain state
09:42 < dhruvm> because their view of the ban list could look different than the output of `listbanned`
09:43 < dhruvm> #19825 just adds new ban entries instead of trying to consolidate/reject overlapping ones. There is some cost to more entries in the banmap(memory) and increased cost of `IsBanned`(cpu/time). However, the most prominent place `IsBanned` is invoked is in `CConnman::AcceptConnection` which is relatively infrequent. The reduced code complexity is well-worth it.
09:43 < ecola> idempotence is the key here
09:43 < setpill> yeah, that's what I was thinking - less code complexity in bitcoin core is a worthy tradeoff for what seems like a small overhead
09:44 < setpill> (hadn't considered the case of scripts that try to maintain a ban list)
09:44 < dhruvm> setpill: that's what i have learnt as well
09:44 < theStack> don't know what a typical banlist looks like but i could also imagine that overlapping ban ranges are actually quite rare, so it's even less of a problem?
09:45 < dhruvm> Let's talk about the RPC use cases.
09:45 < setpill> theStack: yeah and if not, write a better script :P
09:45 < dhruvm> Q: How can the user figure out which ban entries might be blocking outbound connections to a certain IP (before and after this PR)?
09:45 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews     
09:45 < _0x0ff> Before: user had to call `listbanned` which returned all banned ranged and look in there ... After: `listbanned <ip>` outputs all banned ranges that match a given ip
09:45 < AnthonyRonning> `listbanned` command before, checking subnet; `listbanned ip` after.
09:45 < theStack> setpill: true ;)
09:46 < dhruvm> _0x0ff: AnthonyRonning: correct
09:46 < emzy> before: “bitcoin-cli listbanned | less” and search
09:46 < emzy> after: “listbanned x.x.x.x”
09:46 < theStack> ah, that's a neat idea
09:47 < dhruvm> How about unbanning an addr?
09:47 < dhruvm> How can the user completely unban an IP (before and after this PR)?
09:47 < _0x0ff> Before: i'm not 100% certain, but I believe user had to call `listbanned` and go over the list and manually call `setban <subnet> remove` in order to unban a particular IP ... After: `setban <ip> removeall` removes all subnets that would ban a given ip or subnet
09:47 < AnthonyRonning> Before, `listbanned` and find all subnets to remove, or call `setban ip remove` on all subnets, ignoring errors if a subnet was not already banned. After, `setban removeall ip`
09:48 < setpill> Before: 1. figure out all the rules that apply to the IP (using previously discussed methods) 2. call setban remove on all of them
09:48 < setpill> After: setban removeall ip
09:49 < setpill> Correction: setban ip removeall
09:49 < dhruvm> _0x0ff: AnthonyRonning: setpill: you've got it! Hopefully it's easier to manage banlists if the PR is merged.
09:49 < dhruvm> Well, those are all the quetions I have and we're a bit early, so are there any final questions anyone would like to ask?
09:49 < _0x0ff> i like the change, makes the code a lot cleanear
09:49 < sishir> I thought this feature was very cool and would love to test it out? Is there proper doc or any descriptions for testing?
09:50 < dhruvm> thanks, _0x0ff
09:50 < _0x0ff> what are some of the popular balists?
09:50 < AnthonyRonning> agreed, idempotency is always great to have as an api consumer
09:50 < setpill> dhruvm: why was IsBanned( const CSubNet& sub_net) removed?
09:50 < ccdle12> sishir: there are updated tests in p2p_disconnect_ban.py
09:50 < dhruvm> sishir: i'd recommend running bitcoind and using bitcoin-cli to emulate the functional tests in the code review
09:50 < felixweis> i like the splitting up into different commits, was easier to follow the changes
09:50 < theStack> i tried to understand the nodes are not punished in such cases after a recent consensus
09:51 < dhruvm> setpill: it was not being used
09:51 < sishir> ccdle12 dhruvm ooh okay! Thanks
09:51 < dhruvm> felixweis: thank you for reviewing!
09:51 < theStack> sorry -- * i tried to understand the "nodes are not punished in such ases after a recent consensus change" argument
09:51 < michaelfolkson> Nice work updating the fuzz tests. Is that everything that is impacting the fuzz tests?
09:51 -!- sishir [465dca45@cpe-70-93-202-69.natsow.res.rr.com] has quit [Quit: Connection closed]     
09:51 < setpill> dhruvm: in a way this could be a regression for scripts that rely on the "error on existing ban rule" mechanism
09:51 < theStack> i can't find any code that actually uses the BLOCK_RECENT_CONSENSUS_CHANGE enum. what am i missing?
09:52 < setpill> if they tend to ban entire subnets, they now can't even check for them to avoid adding duplicates
09:52 < theStack> s/uses/sets/
09:52 < dhruvm> michaelfolkson: for this change, i think so
09:52 < dhruvm> setpill: ah, i hadn't thought about that. but it shouldn't break the scripts as the intent will still be established.
09:52 < AnthonyRonning> are there any procedures / process in place for changing the behavior of api's?
09:52 < ccdle12> theStack: in MaybePunishNodeForBlock(), but the case statement now omits any logic on that
09:52 < michaelfolkson> Why fuzzed_data_provider.ConsumeIntegralInRange<int>(0, 11) -> fuzzed_data_provider.ConsumeIntegralInRange<int>(0, 6))?
09:53 < setpill> hmm, well, i guess they could use setban listbanned for an ip and then check
09:53 < setpill> the output
09:53 < glozow> theStack: break in MaybePunish, i.e. don't punish
09:53 < dhruvm> theStack: See the comment here: https://github.com/bitcoin/bitcoin/blob/4a540683ec40393d6369da1a9e02e45614db936d/src/consensus/validation.h#L28-L33
09:53 < setpill> would it make sense to have setban listbanned subnet?
09:53 < dhruvm> michaelfolkson: some of the integrals were not being used prior the change on master
09:54 < dhruvm> michaelfolkson: and then some functions being tested were eliminated by #19825
09:54 < theStack> glozow: ccdle12: dhruvm: yes, but in which part of the code a validation result was ever set to {TX,BLOCK}_RECENT_CONSENSUS_CHANGE?
09:54 < glozow> theStack: I guess on master there aren't any recent consensus changes
09:54 < michaelfolkson> Cool dhruvm, thanks
09:54 -!- Caralie [185a59be@cpe-24-90-89-190.nyc.res.rr.com] has quit [Quit: Connection closed]     
09:54 < theStack> i guess it was in releases shortly after segwit, but i don't find any (maybe it has been renamed)
09:55 < dhruvm> setpill: we decided to do removeall only for ips for now, but yes, i think it can make sense for subnets
09:55 < dhruvm> theStack: we'd have to look in git history. jnewbery taught me yesterday that `git log -S` can be useful for such use cases
09:56 < theStack> dhruvm: yes, that's what i used. maybe my local git history is not deep enough
09:56 < jnewbery> `git log -S` is the BEST
09:56 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-pr-reviews     
09:56 < dhruvm> git log -S BLOCK_RECENT_CONSENSUS_CHANGE
09:56 < dhruvm> give me commit sha: a27a2957ed9afbe5a96caa5f0f4cbec730d27460
09:57 < dhruvm> i guess that's a wrap. thank you everyone for coming to PR review club!
09:57 < dhruvm> #endmeeting
09:57 < enjoying> thanks dhruvm
09:57 < ecola> thanks
09:57 < jnewbery> Thanks for hosting dhruvm!
09:57 < AnthonyRonning> thank you dhruvm! I learned a lot.
09:57 < murtyjones> thank you dhruvm for the walkthrough!
09:57 < jonatack>  To see the git log of a function over time, git log -L:function:file.cpp is cool too
09:57 < felixweis> thanks dhruvm!
09:57 < thomasb06> thanks dhruvm
09:57 < norisgOG_> thanks dhruvm
09:57 < larryruane_> thanks dhruvm!
09:57 -!- murtyjones [60ef6e85@pool-96-239-110-133.nycmny.fios.verizon.net] has quit [Quit: Connection closed]     
09:57 < theStack> thanks dhruvm!
09:57 < jonatack> thanks dhruvm!
09:57 < glozow> thanks dhruvm!
09:57 < emzy> Thank yoy dhruvm!
09:58 < setpill> thanks dhruvm and others
09:58 < oxtr> thanks dhruvm, great session!
09:58 < ccdle12> thanks dhruvm
09:58 < _0x0ff> thank you dhruvm, it was a great PR to review
09:58 < schmidty> thanks dhruvm!
09:58 < jnewbery> Next week, jonatack is hosting. Notes and questions will be on the site by the weekend.
09:58 < glozow> oo which pr jonatack?
09:58 < jnewbery> (sorry to break the thanksdhruvmchain!)
09:58 < dhruvm> jonatack: is git function-aware in all languages?
09:58 < jonatack> glozow: haven't decided yet :)))
09:59 < dhruvm> jnewbery: thanks again for the opportunity to host. super fun!
09:59 < jonatack> dhruvm: great job
09:59 -!- AnthonyRonning [3480306a@52.128.48.106] has quit [Quit: Connection closed]     
09:59 < theStack> hm commit a27a2957ed9afbe5a96caa5f0f4cbec730d27460 is from 2019, long after segwit activation
10:00 < glozow> jonatack: u takin suggestions? :P
10:00 < jonatack> bribes yeah
10:00 < glozow> theStack: I saw a bunch of refactors, I think renamed since segwit
10:00 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]     
10:00 -!- oxtr [~tommy@13.84-234-189.customer.lyse.net] has left #bitcoin-core-pr-reviews ["WeeChat 3.0"]     
10:01 < theStack> jonatack: :D
10:01 < theStack> glozow: ok, will dig a bit deeper
10:01 < wumpus> dhruvm: that's a good question, i've wondered too about the logic in git that makes it (sometimes) show the function for a diff
10:01 < jonatack> feel free to send me PR suggestions by irc dm
10:02 < jonatack> dhruvm: idk, haven't tried using it outside of cpp and c
10:02 < dhruvm> wumpus: git is quite magic - i mostly bumble my way through :)
10:03 -!- ecola [~3cola@95.175.17.147] has quit [Quit: Leaving]     
10:03 < enjoying> emzy to dredge up the tor, onion addressing, tor proxying topic again: are you saying that a node cannot selective ban an onion addressed peer because bitcoind only refers to it as a local ip?  my mental model of tor-based peering is at odds with that, if bitcoind can observe onion-addressed peers connecting and disconnecting from it, why would it also not be possible to have logical associated with each of
10:03 < enjoying>  those onion-addressed peers?  worst case scenario of bitcoind not being able to differentiate nodes based on their onion address, couldn't a node just drop "127.0.0.1:57372"
10:05 < emzy> enjoying: I mean a peer can have an onion Hidden Service address that it reports, but it doesn't need one.
10:05 -!- pitchas [bfb5393f@191.181.57.63] has quit [Quit: Connection closed]     
10:06 < emzy> enjoying: The peer can simply connect again and it will have another port "127.0.0.1:57783" for example. So makes no sense to ban the first.
10:06 -!- andozw [496d3971@73.109.57.113] has quit [Ping timeout: 248 seconds]     
10:06 < wumpus> dhruvm: this lists the languages (and you can define your own) https://git-scm.com/docs/gitattributes#_defining_a_custom_hunk_header
10:07 < emzy> enjoying: It is by design that you can't find out who is connecting to you or if it is the same client again.
10:08 < wumpus> enjoying: it can never ban incoming onion peers because tor doesn't identify where incoming connections come from in any way, onion connections don't 'come from' an onion address
10:08 < wumpus> onions are only end points in one direction
10:09 < wumpus> this makes it different from other overlay networks like cjdns and I2P which (IIRC) do have bidirectional addressing
10:09 -!- andozw [496d3971@73.109.57.113] has joined #bitcoin-core-pr-reviews     
10:09 -!- andozw [496d3971@73.109.57.113] has quit [Client Quit]     
10:10 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
10:11 < wumpus> that said, banning is of questionable use for most of them because generating a new address is so cheap, and can be done fully programmatically
10:11 < enjoying> wumpus My next question would be how is onion encryption handled on the packet being sent back?
10:12 < enjoying> sure, I agree that banning peers connecting on tor isn't a dominating strategy, easy, simple for an adversary to obviate the ban
10:13 < wumpus> enjoying: i cannot answer that i don't really know much about Tor internal architecture, the specs are fairly readable though this is the one for addrv3: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt
10:14 -!- anir [40bba0b7@64.187.160.183] has quit [Quit: Connection closed]     
10:15 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 265 seconds]     
10:16 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has joined #bitcoin-core-pr-reviews     
10:16 < enjoying> wumpus thanks
10:24 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
10:33 -!- TechMiX [~techtux@2001:4649:61c8:0:b0d5:b430:a76f:2209] has joined #bitcoin-core-pr-reviews     
10:37 -!- TechMiX [~techtux@2001:4649:61c8:0:b0d5:b430:a76f:2209] has left #bitcoin-core-pr-reviews []     
10:37 -!- norisgOG_ [~norisgOG@89.45.6.92] has quit [Remote host closed the connection]     
10:38 -!- TechMiX [~techtux@2001:4649:61c8:0:b0d5:b430:a76f:2209] has joined #bitcoin-core-pr-reviews     
10:45 -!- enjoying [~enjoying@195.181.160.175.adsl.inet-telecom.org] has left #bitcoin-core-pr-reviews []     
10:56 < theStack> fwiw, i think i found where the code where upgraded segwit nodes took care of not punishing older nodes that published blocks containing invalid segwit transactions:
10:56 < theStack> https://github.com/bitcoin/bitcoin/blob/8b49040854be2e26b66366aeae1cba4716f93d93/src/main.cpp#L5485-L5489
10:58 < jonatack> ✨ meeting log is up at https://bitcoincore.reviews/19825
11:15 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]     
11:19 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 256 seconds]     
11:22 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 264 seconds]     
11:47 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-pr-reviews     
11:47 -!- TechMiX [~techtux@2001:4649:61c8:0:b0d5:b430:a76f:2209] has left #bitcoin-core-pr-reviews []     
11:48 -!- S3CRE75 [3e2b34c6@62.43.52.198.dyn.user.ono.com] has quit [Quit: Connection closed]     
11:53 < jnewbery> Thanks jonatack!
12:01 < _0x0ff> \o/     
12:14 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has quit [Ping timeout: 260 seconds]     
12:39 -!- test032 [~test032@50-200-10-106-static.hfc.comcastbusiness.net] has joined #bitcoin-core-pr-reviews     
12:40 -!- test032 [~test032@50-200-10-106-static.hfc.comcastbusiness.net] has quit [Client Quit]     
13:03 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has joined #bitcoin-core-pr-reviews     
13:03 -!- jonatack [~jon@134.19.179.235] has quit [Ping timeout: 246 seconds]     
13:05 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-pr-reviews     
13:05 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has quit [Read error: Connection reset by peer]     
13:21 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has joined #bitcoin-core-pr-reviews     
13:23 -!- thomasb06 [~user@eth-west-pareq2-46-193-0-224.wb.wifirst.net] has quit [Remote host closed the connection]     
13:38 -!- ccdle12 [~ccdle12@243.222.90.149.rev.vodafone.pt] has quit [Quit: ccdle12]     
13:48 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]     
13:49 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-pr-reviews     
14:02 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 272 seconds]     
14:03 -!- jonatack [~jon@88.124.242.136] has joined #bitcoin-core-pr-reviews     
14:10 -!- effexzi [uid474242@gateway/web/irccloud.com/x-fwgfmvfauhwvcdwo] has quit [Quit: Connection closed for inactivity]     
14:21 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
14:33 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 256 seconds]     
14:59 -!- ctrlbreak_MAD [~ctrlbreak@159.2.165.130] has joined #bitcoin-core-pr-reviews     
15:02 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has quit [Ping timeout: 240 seconds]     
15:47 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has quit [Ping timeout: 264 seconds]     
15:52 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-pr-reviews     
15:57 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has joined #bitcoin-core-pr-reviews     
16:17 -!- prayank [~andr0irc@2405:205:2180:41f3:133:6444:5db:787c] has quit [Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )]     
16:18 -!- jessepos_ [~jp@2601:645:200:162f:129:157d:4d2b:a6f4] has joined #bitcoin-core-pr-reviews     
16:20 -!- jesseposner [~jp@2601:645:200:162f:f8fc:719c:d404:10c2] has quit [Ping timeout: 264 seconds]     
16:34 -!- jessepos_ [~jp@2601:645:200:162f:129:157d:4d2b:a6f4] has quit [Quit: Textual IRC Client: www.textualapp.com]     
16:35 -!- jesseposner [~jp@2601:645:200:162f:129:157d:4d2b:a6f4] has joined #bitcoin-core-pr-reviews     
16:50 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds]     
16:51 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
16:54 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Ping timeout: 240 seconds]     
17:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has joined #bitcoin-core-pr-reviews     
17:20 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 260 seconds]     
17:48 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
17:54 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews     
18:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:255c:8c1d:42fb:24ab:a8e9] has quit [Ping timeout: 264 seconds]     
18:01 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]     
18:04 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-pr-reviews     
18:09 -!- seven__ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Read error: Connection reset by peer]     
20:31 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
20:36 -!- jadi [~jadi@178.131.52.33] has quit [Ping timeout: 240 seconds]     
20:42 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:3656:8ea:afab:481d:8a34] has joined #bitcoin-core-pr-reviews     
20:55 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
20:55 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Disconnected by services]     
20:55 -!- vasild_ is now known as vasild     
21:11 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]     
21:24 -!- musdom [~Thunderbi@202.184.0.102] has joined #bitcoin-core-pr-reviews     
21:44 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:3656:8ea:afab:481d:8a34] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
21:50 -!- jadi [~jadi@178.131.52.33] has joined #bitcoin-core-pr-reviews     
22:20 < dhruvm> wumpus: that's neat!
22:26 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has joined #bitcoin-core-pr-reviews     
23:17 -!- jeremyrubin [~jr@2601:645:c200:14:91a5:d8cb:fe32:d136] has quit [Ping timeout: 264 seconds]     
23:28 -!- da39a3ee5e6b4b0d [~da39a3ee5@49.228.237.19] has joined #bitcoin-core-pr-reviews     
23:32 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Remote host closed the connection]     
23:32 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-pr-reviews     
23:52 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews     
23:53 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has quit [Remote host closed the connection]     
23:54 -!- seven_ [~seven@cpe-90-157-197-248.static.amis.net] has joined #bitcoin-core-pr-reviews