--- Log opened Wed Feb 16 00:00:01 2022
00:35 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
00:50 -!- anrichp [~anrichp@82-68-12-63.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
01:06 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
01:58 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
02:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
02:55 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
02:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
03:00 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:15 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
03:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
04:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
04:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
04:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
04:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
05:00 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
05:24 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
05:29 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
05:41 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has joined #bitcoin-core-pr-reviews
05:51 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
06:07 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
06:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
06:33 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
06:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
06:58 -!- RepeatedNonce [~RepeatedN@49.204.142.3] has joined #bitcoin-core-pr-reviews
06:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
07:14 -!- RepeatedNonce [~RepeatedN@49.204.142.3] has quit [Quit: Client closed]
07:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
07:32 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
08:29 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
08:45 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
08:55 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
08:55 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has joined #bitcoin-core-pr-reviews
08:58 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has joined #bitcoin-core-pr-reviews
08:59 -!- ziggie [uid521459@user/ziggie] has joined #bitcoin-core-pr-reviews
08:59 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has joined #bitcoin-core-pr-reviews
09:00 < lightlike> #startmeeting
09:00 < svav> Hi
09:00 < lightlike> hi
09:00 < kouloumos> hi
09:00 < stickies-v> hi!
09:00 < glozow> hi
09:00 < willcl_ark> Hi
09:00 < ziggie> hi
09:00 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:00 < lightlike> Today's Review Club will be about PR 23542 ("Open p2p connections to nodes that listen on non-default ports")
09:01 < michaelfolkson> hi
09:01 < lightlike> See https://bitcoincore.reviews/23542 for the notes
09:01 < dergoegge> hi
09:01 < lightlike> Is anyone here for the first time?
09:01 < sipa> hi
09:01 < jnewbery> hi
09:02 < larryruane> hi
09:02 < schmidty> hi
09:02 < sipa> this meeting seems to be hi-ly attended
09:02 -!- bitplebpaul [~bitplebpa@24.114.109.147] has joined #bitcoin-core-pr-reviews
09:02 < lightlike> OK - who got the chance to review this week's PR (y/n)?
09:02 < bitplebpaul> y
09:02 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
09:02 < glozow> y
09:02 < svav> n but I read the notes and looked at the code
09:03 < stickies-v> y
09:03 < dergoegge> n
09:03 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
09:03 < willcl_ark> light y
09:03 < sipa> I read through it in an earlier iteration.
09:03 < ziggie> n
09:03 < kouloumos> n
09:03 < effexzi> Hi every1
09:03 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:04 -!- bitplebpaul67 [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:04 -!- bitplebpaul [~bitplebpa@24.114.109.147] has left #bitcoin-core-pr-reviews []
09:04 -!- bitplebpaul67 [~bitplebpa@24.225.251.48] has quit [Client Quit]
09:04 < lightlike> and what's your impression? Concept ACK / NACK?
09:04 < emzy> hi
09:04 < emzy> n
09:04 -!- bitplebpaul92 [~bitplebpa@24.225.251.48] has joined #bitcoin-core-pr-reviews
09:05 < Kaizen_Kintsugi_> hello
09:05 < stickies-v> tACK 36ee76d - properly being able to use different ports seems a great idea to make the network more resilient
09:05 < svav> Concept ACK - it seems a good idea in terms of not being able to easily shut down the network
09:05 < sipa> concept ack
09:05 < Kaizen_Kintsugi_> y
09:05 < michaelfolkson> I think if you are Concept ACK of #23306 you have to be a Concept ACK of this PR. And #23306 is merged :)
09:06 < lightlike> michaelfolkson: yes, there's a point to that.
09:06 < sipa> Agreed (especially as I wrote 23306, :p)
09:06 < lightlike> ok, lots of concept ACKs - let's move to the first q:
09:06 < lightlike> What were the historical reasons for the preferential treatment of the default port?
09:06 < svav> to prevent the Bitcoin P2P network from being leveraged to perform a DoS attack on other services, if their IP/port would get rumoured.
09:06 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
09:07 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:07 < ziggie> how does addrman disfavour other ports right now, does disfavour mean no chance to get a connection to another port than 8333, or is there a way ? 
09:08 < glozow> in the past, i imagine addrs were also gossiped more freely, i.e. with fewer rate limits?
09:08 < bitplebpaul92> ziggie i believe there are ports that won't ever be attempted, like port 22 (ssh)
09:08 < sipa> ziggie: addrman actually doesn't care about ports; it's the outgoing connection logic that favors standard ports
09:08 < lightlike> zigger: addrman doesn't disfavor ports - the connection logic in net.h does.
09:08 < stickies-v> based on sipa 's answer I found somewhere, another reason could to be make it harder for an attacker to fill people's addrtable with many IP/port combinations of the same node, which could potentially be used for eclipse attack
09:08 < lightlike> sorry, net.cpp
09:08 < sipa> svav: That's the folklore reason, not actually the historical reason ;)
09:08 < svav> Doh!
09:08 < stickies-v> oh - I think mine is folklore too
09:09 < glozow> yeah, sipa's description on #23306
09:09 < bitplebpaul92> by folklore do you mean a sort of revisionist history?
09:09 < sipa> Though I don't know to what extent this is public. I recently saw some (alleged) leaked satoshi emails that justified this preference, and it only mentioned the concern about eclipse attacking (before that term existed).
09:09 < bitplebpaul92> I've never come across the term folklore in this context
09:10 < lightlike> maybe it was also about reputational concerns? Bad publicity if bitcoin nodes connect to you on various ports, even if this is not DOS-worthy?
09:10 < michaelfolkson> Ok so Satoshi's concern was eclipse attacking but he/she was wrong to be concerned about that
09:10 < sipa> The explanation of worrying about non-Bitcoin services being DoS'ed by Bitcoin... I don't know where it came from.
09:10 < sipa> michaelfolkson: I don't think he was! The pre-addrman IP address table was certainly vulnerable to that.
09:11 < sipa> (but to many other concerns too)
09:11 < michaelfolkson> Wrong to be concerned about that with regards to supporting different ports
09:11 < emzy> Maybe only have a allowed range of port like >1024
09:12 < lightlike> emzy: in a way, that is what the blacklist does
09:12 < sipa> emzy: The PR does introduce a "bad ports" concept
09:12 < glozow> I was trying to figure out if this was a common concern - your software being used to DoS services and thus you ban certain ports that correspond to those services, and it seems like it's indeed a thing? https://jazzy.id.au/2012/08/23/why_does_chrome_consider_some_ports_unsafe.html
09:12 < sipa> lightlike: Yeah, the reputation aspect is a weak but real concern perhaps - that's also the reason why the PR has this bad ports concept.
09:12 < emzy> You see me unprepared :)
09:13 < michaelfolkson> It does seem simpler and easier to remember if everyone uses the same port. UX
09:13 < michaelfolkson> (Not that that is a strong enough rationale to demand everyone does)
09:13 < lightlike> michaelfolkson: yes, but there are also some advantages if not everyone does, which leads to the next question:
09:13 < lightlike> What are the benefits of removing this preferential treatment with this PR?
09:14 < svav> It’s not obvious that a Bitcoin node is running on an IP address.
09:14 < glozow> Hopefully over time we move towards a healthy balance of 8333 and non-8333 nodes to make Bitcoin connection traffic a bit less easily identifiable?
09:14 < stickies-v> it allows people that can't/don't want to listen on 8333 to still receive incoming connections, increasing the number of available nodes to connect to for the entire network
09:15 < svav> What is the answer to Q2 if it's not prevention of using Bitcoin for DoS attacks?
09:15 < glozow> stickies-v: ah indeed, if there are currently a bunch of under-utilized nodes listening on non-8333 ports
09:16 < glozow> are there? o.O
09:16 < lightlike> glozow: I think that incoming Bitcoin connection traffic would still be identifiable without too much effort. But blocking it is not as easy as just blocking a single port.
09:16 < stickies-v> glozow is the 8333/n-8333 a healthiness indicator for the network though? I think the network doesn't really care about the balance itself - it just allows more people to participate?
09:16 -!- Franklin [~Franklin@197.210.55.60] has joined #bitcoin-core-pr-reviews
09:16 < bitplebpaul92> can ISP's ban specific ports?
09:16 < stickies-v> glozow I'm not sure about numbers, but I'd imagine there are / could be in the future?
09:16 < sipa> svav:  The historical reason, as far as I know, was concerns about someone being able to listen on 1000s of ports on the same machine, rumouring all of those as separate addrs, and thereby sort of cheaply eclipse attacking the network.
09:17 < svav> sipa: ok thanks
09:17 < sipa> (and it doesn't apply anyone since addrman, which buckets based on source range of IP anyway; it doesn't treat multiple ports on the same IP any different anymore from multiple IPs in the same range)
09:17 < sipa> *anymore
09:17 < willcl_ark> With bitcoin traffic so easily identifiable on the wire I do wonder how much benefit it can bring to someone being censored at e.g. ISP level on port 8333 though... However if people have a simple local block on the port, I suppose it can help a little
09:17 < glozow> stickies-v: er, i probably shouldn't have used the word "healthy," just like... varied
09:17 < lightlike> not sure if ISP's are in the business of doing this, but local network administrators (e.g in public netowrks) certainly can and do.
09:18 -!- observer93 [~observer@cpe-23-242-148-67.socal.res.rr.com] has joined #bitcoin-core-pr-reviews
09:18 < glozow> lightlike: so theoretically an ISP or local network admin drops stuff that's going to a 8333 port?
09:18 < sipa> Also don't forget that ISPs aren't free from government intervention/regulation.
09:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
09:18 < willcl_ark> Yeah, much easier for a gov to say "block port 8333" than the vague "block all bitcoin traffic"
09:19 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit [Remote host closed the connection]
09:19 < willcl_ark> ...but perhaps not that much harder (without fully encrypted traffic)
09:19 < sipa> Costs matter.
09:19 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has joined #bitcoin-core-pr-reviews
09:19 < sipa> And BIP324 (v2 p2p transport with opportunistic encryption) will make it more expensive still.
09:20 < emzy> I can think of an easy eclipse attack with configurable ports. Run 10 bitcoind on the same random port and filter the internet connection of the victim to that port. 
09:20 < willcl_ark> Was just trying to look up where that got to :)
09:20 < ziggie> how are tor/2pp/ip4/ip6 connection favoured for incoming connection, are they regarded with the same importance ?
09:20 < stickies-v> and perception matters. It's much easier to claim a network needs to close certain ports for security reasons (without specifically targeting use cases), than to specifically target bitcoin packets (which you have to be specific about)?
09:20 < ziggie> *i2p
09:21 < sipa> all of tor and all of i2p are treated as one or a few "network groups".
09:21 < ziggie> sipa thanks
09:21 < larryruane> basic question... doesn't ability to connect to alternate ports already exist because it's used by the functional tests (regtest)? Does this PR enable such for non-regtest? (seems like it's doing a lot more than that)
09:21 < sipa> ipv4 and ipv6 consist of many network groups; if you use asmap, those groups are the AS numbers of providers
09:21 < bitplebpaul92> kazhakstan and ISP & government world has been interesting re. the protests there
09:22 < glozow> larryruane: oh, interesting. but those are manual connections right?
09:22 < sipa> larryruane: It's not that functionality to connect to custom ports doesn't exist (it has always existed), and for manual connections you can do whatever you like. The change is that this PR stops the *automatic* outgoing connection selection mechanism from *disfavoring* non-8333.
09:22 < lightlike> larryruane: the ability was always there (and it is possible to connect to other ports via manual connections) it's just the automatic connections, where we wouldn't  connect (although we technically could)
09:22 < svav> Someone explain this please - If you don't have a standard port for Bitcoin, isn't this going to make it difficult for the network to function, because no-one knows a standard port that will be used??
09:22 < stickies-v> larryruane ThreadOpenConnections allows you to specificy manual addresses to connect to which comes before this non-default port logic: https://github.com/bitcoin/bitcoin/blob/1e8aa02ec5cc2819c67ef40a7573c4b23a4c11cc/src/net.cpp#L1877
09:23 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
09:23 < larryruane> thanks!
09:23 < sipa> svav: That's the bootstrap problem, and it's an annoying problem, but we do have some mechanisms for it. It isn't particularly made harder by not having a standard port though.
09:23 < jnewbery> sipa: I believe the tor/i2p network group is based on the first 4 bits of the address so each address is in one of 16 netgroups
09:24 < lightlike> svav: if you are on a non-standard port, you also advertise your own address with it in addr gossip relay, so others will know to connect to you on that port.
09:24 < sipa> jnewbery: that sounds right
09:24 < stickies-v> svav I think another way to look at it is that the IP address is as unknown as the port, so if you know one you should be able to know the other through the same communication?
09:25 < svav> ok I see
09:25 < sipa> In IPv4 it's kind of possible to literally trying to connect to every IP address on a particular port (certain botnets have done that), which would be a... very naive way of bootstrapping that's technically made impossible by using random ports. On the other hand... don't do that.
09:26 < lightlike> but this means if you for some reason chose a new random port every second day, you'll likely not get many incoming connections - so that would not be advised
09:26 < sipa> stickies-v: One thing is that DNS seeds can only convey IP addresses, not ports. But there are alternatives (DNS seeds also can't relay torv3).
09:26 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
09:27 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
09:27 < lightlike> great, moving on the next question:
09:27 < stickies-v> sipa oh right lightlike did comment that on the PR. Would a straightforward solution then not be to upgrade the seeders to relay ports too? Is there anything technically complicating that?
09:28 < lightlike> Before this change, automatic connections to peers listening on non-default ports were discouraged, but not impossible. Under what circumstances would a node still connect to such a peer?
09:28 < emzy> So the dns seeds would be only good for default port nodes. I think not many people would change the default port. So no problem.
09:28 < sipa> stickies-v: That would be very hard, actually, because the DNS system isn't designed for resolving ports, only IPs. But there are alternatives to using DNS in the first place.
09:28 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:28 < glozow> after 50 invalid addresses?
09:29 < stickies-v> ah right I didn't think of DNS limitations, thanks. interesting
09:29 < sipa> It's the Domain name system, not the Service name system.
09:30 < lightlike> glozow: correct! and this behavior is kept the same for the "bad port" list, so if nothing else works for 50 tries, we'll also try a "bad port"
09:30 < emzy> DNS seeds sould be still good enough to get some good nodes.
09:30 < ziggie> can I somehow dump all my know ipaddress with their specific ports with bitcoin-cli ?
09:30 < bitplebpaul92> +1 ziggie
09:31 < glozow> so our treatment of "bad ports" is treated how we used to treat non-8333, and non-bad non-8333 and 8333 is treated the same as how we used to treat 8333
09:31 < lightlike> it would just be bad if DNS nodes listed IPs that are listening on non-default ports (so that other nodes would try to connect to them on the default port and fail). But I think this is not he case with the current seeder software.
09:31 < jnewbery> ziggie: getnodeaddresses 0
09:31 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Client Quit]
09:33 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has joined #bitcoin-core-pr-reviews
09:33 < lightlike> glozow: yes, that sounds right!
09:33 < lightlike> moving on: After this PR, the default port still plays a role in bitcoin core. Where is it still used?
09:33 < sipa> From my bitcoin-seeder software, in db.h:
09:33 < sipa>   bool IsGood() const {
09:33 < sipa>     if (ip.GetPort() != GetDefaultPort()) return false;
09:34 < willcl_ark> As our default listen port?
09:35 < glozow> Guess: if no port is provided, we connect using the default?
09:35 < stickies-v> lightlike I think it also defines the default port of the rpc?
09:35 < svav> Is it still used to help new nodes get onto the network somehow?
09:35 < lightlike> willcl_ark, glozow: yes! that is not changing with this PR.
09:36 < lightlike> stickies-v: the rpc default is different from the p2p default port.
09:36  * stickies-v is clearly not an RPC poweruser
09:36 < glozow> is that this? https://github.com/bitcoin/bitcoin/blob/1e8aa02ec5cc2819c67ef40a7573c4b23a4c11cc/src/net.cpp#L427-L428
09:37 -!- Franklin [~Franklin@197.210.55.60] has quit [Quit: Client closed]
09:38 < lightlike> glozow: I think that code just gives you the default p2p port, depending on what you connect to (a string, or an IP address)
09:38 -!- Franklin [~Franklin@197.210.227.23] has joined #bitcoin-core-pr-reviews
09:39 < lightlike> but as mentioned before, the default port is also added to the DNS seeder results we get, to be able to connect to theses addresses and save them to addrman
09:40 < lightlike> related q: Should it be a long-term goal to abandon the notion of a default port entirely?
09:41 < bitplebpaul92> i would think no
09:41 -!- baraclese [~baraclese@static.24.164.119.168.clients.your-server.de] has joined #bitcoin-core-pr-reviews
09:41 < glozow> mmmaybe not? We have different default ports for testnet vs mainnet, would it be bad if we didn't have those distinctions?
09:41 < emzy> lightlike: I think that will make DNS seeds not work anymore (ipv4/ipv6). 
09:42 < lightlike> emzy: yes, I agree, at the very least we'd need an alternative to the DNS seeds before doing something like this.
09:42 < stickies-v> I'm not sure there's a need for that - it wouldn't really be user friendly to make everyone (including people who don't know what a port is) define which port they want to use?
09:42 < bitplebpaul92> if a node couldn't find peers, a default port would still be useful as a last-resort?
09:42 < sipa> @glozow Network magic will still make inter-network connections fail immediately anyway.
09:42 < glozow> sipa: aha, thanks
09:43 < stickies-v> hmm it could just be a random port instead of user defined port of course. Still not sure there's a clear benefit to that
09:44 < kouloumos> sipa mentioned that there are alternatives to using DNS, what those could be?
09:44 < lightlike> bitplebpaul92: a port alone won't help you find peers as a last resort, you'll also need an address from a peer.
09:44 < bitplebpaul92> right
09:45 < willcl_ark> We could switch to BBS :P
09:45 < sipa> or back to IRC seeding
09:45 < svav> Do we know a reason why this PR (and 23306) was felt necessary at this stage? Is it just to make Bitcoin more resilient? Is there any reason to feel default ports make it vulnerable?
09:47 < sipa> It's just an terrible gratuitous privacy leak today.
09:47 < sipa> Using port 8333 is yelling "bitcoin node here!!!"
09:47 < lightlike> svav: I thing that one reason is that all further attempts to obfuscate bitcoin traffic are a bit moot if everythin just goes over 8333
09:47 < sipa> And it's practically impossible to use any other port die to the discouragement rule.
09:47 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
09:48 < lightlike> next q: The PR introduces a list of “bad ports” that was taken from internet browsers. Do you agree with having a list like this in general? Are there any reasons to deviate from the list used by browsers?
09:48 < stickies-v> have we had any/significant amount of reports from people unable to use port 8333 or is that more of a preventative thing? difficult to measure of course, just wondering how big of a role that played in the prioritization
09:48 < sipa> And, after realizing how little of a change the previous PR was (the one permitting multiple ports per ip), there was little reason not to go for itm
09:48 < svav> OK I see
09:48 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
09:49 < bitplebpaul92> lightlike the rational of avoiding ssh ports and other ports where attempted communications might result in a banned IP address make sense to me
09:49 < sipa> @[stickies-v] Nobody even tries. It requires a custom config that is equivalent to "I only want scrapers/spy node connections".
09:49 < sipa> And it isn't that people necessarily actively want to run on a different port.
09:50 < sipa> It's us that should be working on reducing the friction for doing so.
09:50 < lightlike> I agree. there is issue https://github.com/bitcoin/bitcoin/issues/24284 with a suggestion to also include ports used by browsers (which are obviously not on the browser's lists) that may make sense
09:50 < svav> Re security leak, you can see 8333 means Bitcoin node here, but once you know that, are you then easily able to further compromise the node? I mean is it easy to start reading node traffic?
09:50 < michaelfolkson> Are there other protocols using particular ports who are going to be annoyed if a few Bitcoin users use those ports?
09:51 < sipa> @svav If you're under an authoritarian regime, you may not want people to know you're running a Bitcoin node in the first place
09:52 < sipa> That on itself is an issue already, even ignoring what's possible with that information.
09:52 < sipa> @svav And yes, reading traffic is trivial.
09:52 < michaelfolkson> Not sure how one tries to discourage other protocols from using "your" protocol's port. Other than loudly trying to claim it as your protocol's port
09:52 < sipa> (but even doing that at scale may be costly to attackers)
09:52 < baraclese> I use a socks5 proxy for my bitcoin node at home
09:52 < lightlike> michaelfolkson: there may be webadmins (e.g. in organisations) that monitor specific ports and may become annoyed.
09:53 < sipa> The thing with 80 and 443 (http and https) is that they are very commonly "public services" that always get connections from everywhere.
09:53 < sipa> That's not true for 22 (ssh) for example.
09:54 < sipa> Also, I think we want to keep the possibility of disguising Bitcoin P2P traffic as https traffic in the future.
09:54 -!- observer93 [~observer@cpe-23-242-148-67.socal.res.rr.com] has quit [Ping timeout: 256 seconds]
09:54 < lightlike> so 80 and 443 may be particularly good choices to run a bitcoin node, because the traffic isn't looked into deeply anyway if everyone uses them?
09:54 < sipa> (after BIP324 encryption)
09:55 < sipa> Quite possibly.
09:55 < sipa> It'd be even better if the traffic actually can't be distinguished by third parties from actual https traffic.
09:56 < lightlike> moving on to the last question, which is about the second part of the PR (addr relay):
09:56 < lightlike> What is the reason for allowing callers to pass salts to CServiceHash and then initializing it with CServiceHash(0, 0) in commit d0abce9?
09:57 -!- Franklin [~Franklin@197.210.227.23] has quit [Ping timeout: 256 seconds]
09:57 < stickies-v> we want the randomness to be deterministic, so by passing the same (0, 0) salts the same IP:port should lead to the same hash consistently
09:57 < glozow> We always use the same salt so that, if we get the same address again (within the 24hr time slot), we relay it to the same "random" peers, so there's no advantage to sending us the same address twice
09:58 < bitplebpaul92> after 24 hours what changes? a nonce?
09:59 < lightlike> stickies-v glozow : exactly! If we'd use a different salt, we'd send a given address to different peers in that 24h window, which is not what we want.
10:00 < glozow> bitplebpaul92: the hash changes, which means the peers we select also changes
10:00 < lightlike> alright, thanks for participating everyone!
10:00 < lightlike> #endmeeting
10:00 < willcl_ark> Thanks!
10:00 < bitplebpaul92> ah
10:00 < glozow> we're using the hash to select 1-2 random peers to forward the address
10:00 < glozow> thanks lightlike!
10:00 < bitplebpaul92> thanks lightlike and everyone
10:00 < emzy> Thanks lightlike and all!
10:00 < jnewbery> thanks lightlike! Great meeting!
10:00 < ziggie> Thanks lightlike for hosting 
10:00 -!- monlovesmango [monlovesma@gateway/vpn/protonvpn/monlovesmango] has quit []
10:00 < sipa> thanks @lightlike!
10:00 < stickies-v> bitplebpaul92 we use integer divsion on https://github.com/vasild/bitcoin/blob/36ee76d1afbb278500fc8aa01606ec933b52c17d/src/net_processing.cpp#L1781 which causes the hashed message to change only every 24 hours
10:01 < svav> Thanks lightlike and all!
10:01 < stickies-v> thank you lightlike !
10:01 < michaelfolkson> +1
10:01 < glozow> thanks for the great opPortunity to look at net.cpp!
10:01 -!- Franklin [~Franklin@197.210.227.23] has joined #bitcoin-core-pr-reviews
10:03 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
10:03 < glozow> next week, stickies-v is hosting on #24098!
10:03 < effexzi> Thanks every1.
10:04 < stickies-v> you should feel super refreshed afterwards because it's promising to be a RESTful conversation
10:05 < emzy> hehe
10:05 -!- bitplebpaul92 [~bitplebpa@24.225.251.48] has quit [Quit: Connection closed]
10:10 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
10:11 < michaelfolkson> opPortunity, missed that one
10:11 < michaelfolkson> Really have to be on constant pun alert
10:11 < Kaizen_Kintsugi_> Thanks everyone! learned a lot again. Networking is my weakest area
10:26 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
10:29 -!- baraclese [~baraclese@static.24.164.119.168.clients.your-server.de] has quit [Quit: Leaving]
10:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
10:31 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
10:35 -!- Franklin [~Franklin@197.210.227.23] has quit [Ping timeout: 256 seconds]
10:41 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
10:54 -!- sanya [~sanya@79-101-150-15.dynamic.isp.telekom.rs] has quit [Quit: Connection closed]
10:59 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
11:03 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 256 seconds]
11:06 -!- svav [~svav@82-69-86-143.dsl.in-addr.zen.co.uk] has quit [Quit: Connection closed]
11:09 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
11:13 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 252 seconds]
11:24 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
11:31 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
11:36 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
11:39 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
11:44 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 272 seconds]
12:12 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
12:14 -!- lukedashjr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
12:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
12:17 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Ping timeout: 272 seconds]
12:17 -!- lukedashjr is now known as luke-jr
12:20 -!- kouloumos [uid539228@id-539228.tinside.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:24 -!- effexzi [uid474242@id-474242.ilkley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:42 -!- gleb7454386 [~gleb@178.150.137.228] has quit [Ping timeout: 256 seconds]
12:42 -!- gleb7454386 [~gleb@178.150.137.228] has joined #bitcoin-core-pr-reviews
12:46 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
12:48 -!- ___nick___ [~quassel@cpc68286-cdif17-2-0-cust533.5-1.cable.virginm.net] has quit [Ping timeout: 272 seconds]
12:51 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 240 seconds]
13:17 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
13:34 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Remote host closed the connection]
13:50 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
14:04 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Remote host closed the connection]
14:21 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
14:25 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
14:28 -!- anrichp [~anrichp@82-68-12-63.dsl.in-addr.zen.co.uk] has quit [Read error: Connection reset by peer]
14:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
15:35 -!- pg156 [sid518209@id-518209.hampstead.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- pg156 [sid518209@id-518209.hampstead.irccloud.com] has joined #bitcoin-core-pr-reviews
15:35 -!- robot-dreams [sid463268@id-463268.uxbridge.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- stick [sid403625@user/prusnak] has quit [Ping timeout: 245 seconds]
15:35 -!- hugohn [sid304114@id-304114.lymington.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- josibake [sid509132@id-509132.helmsley.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- lightlike [sid521075@user/lightlike] has quit [Read error: Connection reset by peer]
15:35 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- amiti [sid373138@id-373138.lymington.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- josibake [sid509132@id-509132.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews
15:35 -!- fjahr [sid374480@id-374480.uxbridge.irccloud.com] has joined #bitcoin-core-pr-reviews
15:35 -!- jkczyz [sid419941@id-419941.lymington.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- jarolrod [sid475272@id-475272.uxbridge.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- amiti [sid373138@id-373138.lymington.irccloud.com] has joined #bitcoin-core-pr-reviews
15:35 -!- ajonas [sid385278@id-385278.helmsley.irccloud.com] has quit [Read error: Connection reset by peer]
15:35 -!- larryruane [sid473749@id-473749.uxbridge.irccloud.com] has quit [Read error: Connection reset by peer]
15:36 -!- blkncd [sid505676@id-505676.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews
15:36 -!- ajonas [sid385278@2a03:5180:f:1::5:e0fe] has joined #bitcoin-core-pr-reviews
15:36 -!- robot-dreams [sid463268@2a03:5180:f:5::7:11a4] has joined #bitcoin-core-pr-reviews
15:36 -!- hugohn [sid304114@2a03:5180:f:2::4:a3f2] has joined #bitcoin-core-pr-reviews
15:36 -!- jkczyz [sid419941@id-419941.lymington.irccloud.com] has joined #bitcoin-core-pr-reviews
15:36 -!- jarolrod [sid475272@2a03:5180:f:5::7:4088] has joined #bitcoin-core-pr-reviews
15:36 -!- stick [sid403625@user/prusnak] has joined #bitcoin-core-pr-reviews
15:36 -!- larryruane [sid473749@2a03:5180:f:5::7:3a95] has joined #bitcoin-core-pr-reviews
15:36 -!- lightlike [sid521075@user/lightlike] has joined #bitcoin-core-pr-reviews
15:42 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
16:08 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has quit [Quit: Ping timeout (120 seconds)]
16:09 -!- jamesob [~jamesob@pool-108-31-54-223.washdc.fios.verizon.net] has joined #bitcoin-core-pr-reviews
16:11 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
16:16 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
16:37 -!- luke-jr [~luke-jr@user/luke-jr] has quit [Read error: Connection reset by peer]
16:37 -!- luke-jr [~luke-jr@user/luke-jr] has joined #bitcoin-core-pr-reviews
16:46 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
17:04 -!- S3RK [~S3RK@user/s3rk] has quit [Ping timeout: 256 seconds]
17:06 -!- S3RK [~S3RK@user/s3rk] has joined #bitcoin-core-pr-reviews
17:50 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
17:56 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
18:03 -!- m011 [sid489830@id-489830.helmsley.irccloud.com] has quit [Quit: Updating details, brb]
18:03 -!- l_sx01 [sid489830@id-489830.helmsley.irccloud.com] has joined #bitcoin-core-pr-reviews
18:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
18:23 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
18:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
19:20 -!- grettke [~grettke@cpe-65-29-228-30.wi.res.rr.com] has joined #bitcoin-core-pr-reviews
19:39 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 240 seconds]
19:54 -!- brunoerg [~brunoerg@187.183.47.88] has joined #bitcoin-core-pr-reviews
20:00 -!- greypw254 [~greypw2@grey.pw] has quit [Remote host closed the connection]
20:00 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews
20:01 -!- greypw254 [~greypw2@grey.pw] has quit [Remote host closed the connection]
20:02 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews
20:02 -!- greypw254 [~greypw2@grey.pw] has quit [Remote host closed the connection]
20:02 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews
20:03 -!- greypw254 [~greypw2@grey.pw] has quit [Remote host closed the connection]
20:03 -!- greypw254 [~greypw2@grey.pw] has joined #bitcoin-core-pr-reviews
20:04 -!- greypw254 [~greypw2@grey.pw] has quit [Remote host closed the connection]
20:23 -!- RepeatedNonce [~RepeatedN@49.205.80.205] has joined #bitcoin-core-pr-reviews
20:44 -!- RepeatedNonce [~RepeatedN@49.205.80.205] has quit [Quit: Client closed]
20:58 -!- brunoerg [~brunoerg@187.183.47.88] has quit [Ping timeout: 256 seconds]
21:41 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
22:30 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has quit [Ping timeout: 252 seconds]
22:50 -!- kcalvinalvin [~kcalvinal@ec2-52-79-199-97.ap-northeast-2.compute.amazonaws.com] has quit [Quit: ZNC 1.7.4 - https://znc.in]
22:59 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:9d7:c243:f6c3:1ebf] has joined #bitcoin-core-pr-reviews
23:08 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has joined #bitcoin-core-pr-reviews
23:31 -!- kcalvinalvin [~kcalvinal@ec2-3-38-183-204.ap-northeast-2.compute.amazonaws.com] has quit [Quit: ZNC 1.7.4 - https://znc.in]
--- Log closed Thu Feb 17 00:00:01 2022