15:00:17 <jnewbery> #startmeeting 
15:00:17 <core-meetingbot> Meeting started Tue Jan 12 15:00:17 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
15:00:17 <core-meetingbot> Available commands: action commands idea info link nick
15:00:19 <jnewbery> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
15:00:25 <jnewbery> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
15:00:36 <glozow> hai
15:00:40 <jamesob> hi
15:00:49 <ariard> yo
15:00:51 <jonatack> hola
15:00:52 <vasild> hi
15:01:05 <ajonas> hi
15:01:22 <amiti> hi
15:01:27 <jnewbery> hi folks. Welcome to the first p2p meeting of 2021!
15:01:47 <jnewbery> We have three proposed meeting topics: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#12-jan-2021
15:01:48 <sdaftuar> hi
15:01:50 <gribble> https://github.com/bitcoin/bitcoin/issues/12 | Monitor transactions and/or blocks · Issue #12 · bitcoin/bitcoin · GitHub
15:02:28 <jnewbery> Before we get on to those, I suggest we start with our regular topic of priorities. What are people working on/hoping to make progress on over the next weeks/months?
15:02:49 <jnewbery> don't be shy!
15:03:00 <vasild> On my end #20788
15:03:03 <gribble> https://github.com/bitcoin/bitcoin/issues/20788 | net: add RAII socket and use it instead of bare SOCKET by vasild · Pull Request #20788 · bitcoin/bitcoin · GitHub
15:03:19 <vasild> it would help #19203 and #20685 to move forward
15:03:21 <gribble> https://github.com/bitcoin/bitcoin/issues/19203 | net: Add regression fuzz harness for CVE-2017-18350. Add FuzzedSocket. Add thin SOCKET wrapper. by practicalswift · Pull Request #19203 · bitcoin/bitcoin · GitHub
15:03:23 <gribble> https://github.com/bitcoin/bitcoin/issues/20685 | Add I2P support using I2P SAM by vasild · Pull Request #20685 · bitcoin/bitcoin · GitHub
15:04:05 <jonatack> On my end https://github.com/bitcoin/bitcoin/pull/20197
15:04:30 <jonatack> #20197 and adding more unit test coverage to the eviction logic
15:04:32 <jnewbery> My main priority for the start of this year is to make progress on the net/net_processing split (#19398). I'm currently waiting for #20811 because I think my remaining changes are less disruptive after that.
15:04:33 <gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: improve onion detection in AttemptToEvictConnection() by jonatack · Pull Request #20197 · bitcoin/bitcoin · GitHub
15:04:33 <gribble> https://github.com/bitcoin/bitcoin/issues/19398 | Move remaining application layer data to net processing · Issue #19398 · bitcoin/bitcoin · GitHub
15:04:36 <gribble> https://github.com/bitcoin/bitcoin/issues/20811 | refactor: move net_processing implementation details out of header by ajtowns · Pull Request #20811 · bitcoin/bitcoin · GitHub
15:04:50 <ariard> reviewing erlay/package testmempoolaccept and updating #20277 with last sdaftuar feedback
15:04:54 <gribble> https://github.com/bitcoin/bitcoin/issues/20277 | p2p: Stop processing unrequested transactions during IBD and extend p2p_ibd_txrelay.py coverage by ariard · Pull Request #20277 · bitcoin/bitcoin · GitHub
15:06:20 <jnewbery> Reminder that aj maintains a board of p2p PRs here: https://github.com/users/ajtowns/projects/1
15:07:15 <jnewbery> ok, if no-one has anything else, let's move onto the first topic
15:07:23 <jnewbery> #topic disabletx P2P message (sdaftuar)
15:07:24 <core-meetingbot> topic: disabletx P2P message (sdaftuar)
15:07:28 <sdaftuar> ooh i'm up
15:07:40 <sdaftuar> ok so the context here is #20726
15:07:44 <gribble> https://github.com/bitcoin/bitcoin/issues/20726 | p2p: Add DISABLETX message for negotiating block-relay-only connections by sdaftuar · Pull Request #20726 · bitcoin/bitcoin · GitHub
15:08:20 <sdaftuar> it's gotten a decent bit of feedback so far, so not sure if it's helpful for me to go through all the context again?
15:08:30 <sdaftuar> but i can for anyone who hasn't looked at it
15:09:02 <sdaftuar> the main goal here is to be able to increase the number of inbound connection slots on the network, in order to feel good about increasing hte number of block-relay-only connections we make
15:09:28 <sdaftuar> which in turn is in order to add security to the network by increasing its partition resistance, at relatively low cost (block-relay-only connections are low-resource)
15:10:06 <sdaftuar> but to do all that, we need to give nodes a way to know that an inbound peer is a block-relay-only peer. currently block-relay-only peers use the fRelay flag from BIP37 to instruct their peer they don't want transactions
15:10:14 <sdaftuar> but BIP37 allows for transaction relay to resume with a FILTERCLEAR message
15:10:21 <jnewbery> sdaftuar: when you say low-resource, are you mostly talking about memory, bandwidth of something else?
15:10:27 <jnewbery> *or something else
15:10:28 <sdaftuar> memory and bandwidth
15:10:34 <sdaftuar> and cpu, i guess
15:11:28 <sdaftuar> so my proposal is to add a new p2p message ("disabletx") which means that a connection will never relay transactions, for its lifetime
15:11:50 <amiti> sdaftuar: do I understand correctly the current proposal is a `disabletx` messages that explicitly disables transactions & implicitly disables addresses? And the thinking is that in the future we could have a message that explicitly enables addresses ? I followed your reasoning for opt out vs opt in (why would we ever opt out of blocks?), but what do you think about implementing block-relay conns with two
15:11:51 <amiti> messages, `disabletx` and `disableaddr` or something?
15:11:53 <vasild> if the node is up to date, then block-relay conveys just a few MB of data per 10 minutes, right? But if the node is not up to date...
15:11:53 <sdaftuar> this in turn will allow us to write code to increase the number of connections lots by reserving additional slots for disabletx-peers
15:12:49 <sdaftuar> amiti: right, so block-relay-only connections currently have no way to communicate that they also don't want addr messages
15:13:23 <sdaftuar> and my proposal for now is to just have the BIP "RECOMMEND" that we not send addrs to peers sending disabletx
15:13:39 <sdaftuar> with the idea being that in the future, we should adopt some kind of addr relay negotiation protocol, which would then take precedence
15:13:55 <sdaftuar> however i think designing an addr relay protocol will take some work, and i'm not ready to propose one now
15:14:10 <sdaftuar> i think there are a bunch of questions around what the goals of addr relay should be, and how best we might achieve them
15:14:37 <sdaftuar> and so i don't think it makes sense to propose something that we'd likely just want to change soon after
15:14:51 <amiti> ah I see, you think the long term design should be more than a toggle (like with txs)?
15:15:15 <sdaftuar> yeah, at the least i suspect we want to communicate information about particular networks (as described in BIP 155)
15:15:59 <amiti> yeah, that makes sense.
15:16:01 <sdaftuar> and it's not clear to me yet what our different handling should be for different networks (ie addresses we understand versus ones we don't)
15:16:42 <vasild> tx relay is unrelated to addr relay, linking both together under "disabletx" would be confusing?
15:17:45 <sdaftuar> vasild: both are related to block-relay-only peer logic, which is the only thing that will be using this at the start... i don't see why it's a problem to have a recommendation for this?
15:17:55 <sdaftuar> software that ignores the addr-relay suggestion will not be in violation of the design
15:18:09 <sdaftuar> but it accommodates our desired behavior today
15:19:15 <sdaftuar> if there were some other software that was going to be using this which wanted different functionality, then i might agree
15:19:22 <jnewbery> I agree that it seems strange to link the two things (tx relay and addr relay) in the BIP
15:19:39 <vasild> then isn't s/disabletx/relayblocksonly/ more clear (relay only blocks and nothing else - no tx, no addr)?
15:20:16 <ariard> but the alternative to introduce a `disabeladdr` will be superceded when we have a better addr relay protocol?
15:20:31 <sdaftuar> vasild: that was my first approach, but many people seemed to feel that having a BIP that governed too much behavior was also confusing or bad protocol design, for future compatibility
15:20:51 <vasild> :)
15:20:54 <sdaftuar> vasild: so this approach is narrow -- just specifies required behavior for tx-relay -- but the motivation gives us an implication for other behavior as well
15:21:04 <sdaftuar> in the absence of protocol support
15:21:07 <jonatack> sdaftuar: fwiw i like the original "blockrelay"
15:22:08 <jnewbery> (the original discussion of blockrelay -> disabletx is here: https://github.com/bitcoin/bitcoin/pull/20726#discussion_r548352366)
15:22:10 <sdaftuar> (trying to figure out how to do an ascii shrug)
15:22:30 <jonatack> sometimes in those discussions the squeaky wheel gets the grease, so mentioning it as a fwiw here
15:22:59 <sdaftuar> i mean i could go either way. i think there's benefit to understanding the network from communicating more exactly what these connections do, and establishing first-class support in the protocol
15:23:16 <sdaftuar> which was more inline with my initial proposal / description
15:23:39 <sdaftuar> but i can see the argument that it imposes design burden on future protocol implementers to figure out how new features should interact with this
15:24:00 <sdaftuar> so making this more narrowly tailored shifts the burden back on just software implementing this feature
15:24:05 <jonatack> jnewbery: i thought it was here: https://github.com/bitcoin/bitcoin/pull/20726#discussion_r548352366
15:24:44 <jonatack> jnewbery: nvm, GitHub doesn't work for me correctly, your link sent me to a different one
15:24:56 <sdaftuar> i think i can implement what i would like to implement with either approach, so i'm hoping that we can just pick a path and move forward.
15:25:16 <sdaftuar> i don't think my current proposal inhibits any future protocol extensions at all
15:25:49 <jnewbery> I don't see much difference between the original proposal and the disabletx proposal. They both interact with addr relay in a potentially unexpected way.
15:26:07 <sdaftuar> jnewbery: but it's just a recommendation.  what drawback is there to having it in there?
15:26:57 <sdaftuar> obviously it could be removed; it just seems to me that it makes things strictly worse.
15:27:22 <jonatack> sdaftuar: hm, the latest push of 20726 seems smaller and inbound-block-relay was dropped?
15:27:35 <ariard> sdaftuar: implementation-wise, how do we tread `disabletx` peers keep sending us addrs? we disconnect or ignore msgs ?
15:27:56 <sdaftuar> jonatack: yes, i switched to using just a bool to track whether the peer is a disabletx bool, rather than upgrading connection type.
15:27:59 <jnewbery> If there is some new addr relay negotiation method introduced in future you have to specify how that interacts with the disabletx BIP
15:28:26 <sdaftuar> jnewbery: obviously it takes precedence, as the disabletx BIP only has a recommendation, and not MUST semantics, and it even calls out this possibility
15:28:36 <sipa> good morning
15:29:09 <jonatack> sdaftuar: ok. we already have a de facto inbound block relay type IIUC and it would be nice to formalize it, if so, but I understand that it may not be central to your proposal
15:29:20 <sdaftuar> jonatack: there was feedback that the connection type change was not the right fit for this. i don't feel strongly, but in changing the thinking from explicitly communicating BLOCKRELAY to a peer, to sending a DISABLETX, it felt more in line with just another setting on a peer's preferred transaction relay
15:29:51 <jnewbery> I think it's probably more useful to discuss the protocol proposal at this stage than implementation details
15:30:33 <sdaftuar> here's my question for people who are concerned abotu the addr relay interaction:
15:30:46 <sdaftuar> let's say we deployed disabletx. shoudl bitcoin core relay addrs to software sending these messages?
15:31:05 <vasild> yes
15:31:20 <amiti> I would prefer if there was a way to be explicit about what we are relaying (tx / block / addr). both the original & current proposal are suggesting one message to communicate two pieces of information. I see the challenges of designing for a future where we want more advanced addr relay, but I'm still wondering how we could do both.
15:31:49 <sdaftuar> vasild: the fact that we relay addrs to inbound-block-relay-only peers is a problem, no?
15:32:04 <amiti> hm, if bitcoin core relayed addrs to software that sends disabletx, we aren't able to take advantage of the savings that is the goal, right?
15:32:09 <sdaftuar> isn't that behavior strictly worse than not relaying addrs?
15:32:25 <sdaftuar> amiti: that's a minor goal. addr relay is not nearly as big a deal as tx-relay
15:32:31 <sdaftuar> the data structure is much smaller, i believe
15:32:33 <amiti> ok
15:32:34 <sdaftuar> but yes, a bit annoying
15:33:05 <ariard> it can be cleanup when an addr relay negotiation protocol is introduced
15:33:10 <sdaftuar> one of the drawbacks to increasing the number of inbound-block-relay-only peers is that we create a bunch of addr-relay blakc holes
15:33:29 <sdaftuar> i don't see why we can't make progress on this while deferring design of an actual addr relay protocol ot the future?
15:33:30 <jnewbery> amiti: the receiving node could just drop all addr/getaddr messages. There wouldn't be any memory cost and minimal bandwidth cost
15:33:31 <vasild> I mean "yes", because they did not send "disableaddr" (which does not exist) -- i.e. don't link addr and tx relay in one option
15:35:10 <amiti> jnewbery: ah. right.
15:35:45 <jonatack> sdaftuar: ack
15:37:10 <jnewbery> sdaftuar: do you have any further thoughts about what a future addr relay negotiation method would look like? I know you were pushing for something similar with BIP155
15:38:08 <sdaftuar> i have a guess, but i think we need to get everyone on the same page about the goals of addr relay are, and come up with some relay policies that we think would achieve that goal, and then make sure our design supports those relay policies
15:38:22 <sdaftuar> there's currently no writeup anywhere on how addr relay should work, to my knowledge
15:39:35 <sdaftuar> but my naive guess is that adding some kind of feature negotiation where we signal support (not sure 0/1 or if more precision is necessary) for different networks (as defined in bip 155) is probably what we will eventually want
15:39:49 <sdaftuar> i just can't defend that right now
15:40:04 <jnewbery> what's the downside of removing the addr relay RECOMMEND point and punting on how to do addr relay negotiation?
15:40:16 <sdaftuar> jnewbery: first you answer my question from above please!
15:40:27 <ariard> even assuming you have one goal, and nodes operators might wish different relay strategies in function of their privacy needs
15:40:45 <sdaftuar> let's say we deployed disabletx. shoudl bitcoin core relay addrs to software sending these messages?
15:40:53 <sdaftuar> i think the answer to that is of course not
15:41:01 <jnewbery> it depends what the spec says, of course
15:41:33 <sdaftuar> well then that creates the black-hole problem, which will prevent us from wanting to add more blokc-relay connections
15:41:58 <sdaftuar> i mean we can certainly gate all these improvements on addr relay improvements. i just think that will set us back a long time
15:42:37 <ariard> sdaftuar: to be clear you're envisioning 1) adding more block-relay connection and then 2) addr relay improvements?
15:42:58 <sdaftuar> ariard: yes i think we know how to do 1), while 2) requires research
15:43:10 <jnewbery> You don't want a disableaddr message because it won't be useful after the new addr relay negotiation method?
15:43:11 <sdaftuar> i've started doing some research on 2), but it might be a year or more before i feel good about proposing anything, i don't know
15:43:38 <sipa> sdaftuar: i hadn't considered the fact that adding more block-only connections (a goal of disabletx), actually worsens the addr black hole problem
15:43:46 <jonatack> sdaftuar: i agree that incremental and possibly iterative is the pragmatic way forward here
15:44:16 <sdaftuar> sipa: this came up in #15759 when first proposed, and was one of the reasons we kept it at 2 connections
15:44:21 <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub
15:44:58 <sdaftuar> based on looking at my own nodes at the time, i didn't feel it was a material worsening of the sitaution, given the other software on the network
15:45:16 <sdaftuar> but i would feel uncomfortable advocating going up to 8 peers without really looking at it a lot more carefully
15:45:23 <sdaftuar> in the absence of us changing our default behavior for disabletx peers
15:45:39 <sdaftuar> jnewbery: yes i think a disableaddr message would be short-lived
15:46:33 <sipa> right
15:46:41 <ariard> to be back on the question "should bitcoin core relay addrs to software sending these messages?" _currently_ we don't accept addr msgs from outbound-block-relay peers so why it's worsening the black-hole problem?
15:46:58 <sdaftuar> ariard: the outbound peer will choose us for addr relay (sometimes)
15:47:06 <sdaftuar> and we will drop it and not relay further
15:47:25 <sdaftuar> so increasing the number of connections that drop addr messages could inhibit addr relay
15:47:52 <sdaftuar> this gets to what i was saying before though, i don't think anyone has studied addr relay. this is an open area of research that is (to my knowledge) very undeveloped
15:47:55 <ariard> yeah because you have less peers doing useful addr relay, but I think we should defer this discussion when we introduce more block-relay connectiions
15:48:00 <sdaftuar> so i'm just trying to not make things worse
15:48:35 <ariard> I agree things aren't worse post-#20726
15:48:39 <gribble> https://github.com/bitcoin/bitcoin/issues/20726 | p2p: Add DISABLETX message for negotiating block-relay-only connections by sdaftuar · Pull Request #20726 · bitcoin/bitcoin · GitHub
15:48:54 <sdaftuar> ariard: well i'd like to establish that people are comfortable with not relaying addrs to disabletx peers
15:49:04 <sdaftuar> because if not, then i don't to advocate for this
15:49:33 <ariard> sdaftuar: and my feeling is some folks would prefer introduce a `disableaddr` to have a clean protocol signaling
15:49:33 <sdaftuar> (not relaying addrs to disabletx peers until such time that we deploy addr-relay negotiation, to be clear)
15:49:36 <ariard> I'm ~0 on this
15:49:49 <sipa> i don't think it's unreasonable to recommend not relaying addresses to disabletx peers; so far addr relay is completely local policy anyway with no BIPs discussing it at all afaik
15:50:07 <sdaftuar> sipa: my understanding as well that there are no BIPs on it
15:50:25 <sipa> it's what we'd do anyway, unless the BIP explicitly says the opposite
15:53:23 <jnewbery> any additional points, or should we move on?
15:53:32 <jonatack> subject to review, concept ack on the BIP draft and 20726
15:54:18 <jnewbery> jonatack: we only have 5 minutes left, so I propose we punt your topics to the next meeting
15:54:19 <sdaftuar> thanks. i'm planning to mark 20726 ready for review once a bip number is assigned, fyi
15:55:15 <jnewbery> One quick topic before we end. How do people feel about a different time for this meeting? It would have been nice to have aj here, but it's 1am for him, so it's not the most sociable time.
15:55:22 <jonatack> jnewbery: that's fine. for now i'd only like to mention that connection type implementations are open for the CLI and GUI (and partially merged in the GUI), in case people didn't see them
15:55:57 <jonatack> and they have had to go beyond the literal connection types to cover the actual cases
15:56:11 <jnewbery> 2100 UTC is 07:00 in Brisbane, 16:00 in New York and 13:00 in California
15:56:13 <sipa> jnewbery: earlier will be hard for me
15:56:43 <vasild> 21:00 UTC is 22:00 central europe, I will not be able to attend
15:57:13 <sipa> timezones suck :(
15:57:16 <vasild> (I rarely attend the other two meetings because they are too late too)
15:57:18 <jonatack> agreed
15:57:35 <jonatack> (they suck and the meetings are late :)
15:58:42 <jnewbery> ok, let's keep it at the current time for now.
15:58:56 <jnewbery> time's up
15:58:58 <jnewbery> #endmeeting