15:00:07 <jnewbery> #startmeeting
15:00:07 <lightningbot> Meeting started Tue Aug 11 15:00:07 2020 UTC.  The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:07 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:15 <jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
15:00:15 <jonatack> hola
15:00:21 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
15:00:21 <troygiorshev> hi
15:00:24 <jnewbery> Hi folks! Welcome to the first p2p IRC meeting.
15:00:26 <dongcarl> hi
15:00:27 <ajonas> hi
15:00:28 <amiti> hi!
15:00:28 <fanquake> hi
15:00:30 <jnewbery> Please say hi to let everyone know you're here and planning to participate.
15:00:31 <pinheadmz> hi
15:00:35 <sdaftuar> hi
15:00:43 <jnewbery> We have a one suggested topics at https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings (and aj has added his priorities as well - thanks!)
15:00:44 <ariard> hi
15:00:57 <theStack> hi
15:00:57 <aj> hi
15:01:12 <jnewbery> (please don't use the gist any more. I've moved the notes to the bitcoin-core wiki)
15:01:24 <elichai2> Hi
15:01:48 <jnewbery> I suggest we start with priorities/focus as a topic
15:01:49 <sipa> hi
15:02:19 <jnewbery> #topic priority/focus
15:02:47 <jnewbery> aj: would you like to start. You've listed what you're working on https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings but do you have anything else to add?
15:03:27 <aj> i'm mostly caring about taproot-critical-path-things, which i think is now mostly not p2p stuff
15:03:53 <aj> but copied stuff off my whiteboard in case it's missing anything interesting or important
15:04:01 <adiabat> hi
15:04:43 <jnewbery> sdaftuar: any priorities?
15:04:51 <sdaftuar> i've got a bunch of things i am thinking about...
15:05:17 <sdaftuar> i'd say my current priorities are to get the transaction download stuff (sipa's 19184 i think) reviewed.  and erlay is on my mind right after that
15:05:45 <sdaftuar> but i'm also thinking about a bunch of other things that i want to mention, because if others are interested in any then maybe we can make progress on other fronts as well
15:06:08 <jnewbery> do you want to list them now?
15:06:10 <sdaftuar> some stuff is related to network-topology improvements:
15:06:34 <sdaftuar> more block-relay only peers (which is probably gated on negotiating block-relay connections at connect-time)
15:07:11 <sdaftuar> more improvements to syncing our tips with more peers (possibly including tx-relay-peer rotation, which can help here as well)
15:07:23 <sdaftuar> improved eviction logic (pr open)
15:07:45 <sdaftuar> and other stuff is related to transaction relay policy, particularly package relay, which is a whole beast of a topic by itself
15:07:58 <sdaftuar> but also rbf pinning (which may be a related problem)
15:08:01 <aj> #19670 ?
15:08:04 <gribble> https://github.com/bitcoin/bitcoin/issues/19670 | Protect localhost and block-relay-only peers from eviction by sdaftuar · Pull Request #19670 · bitcoin/bitcoin · GitHub
15:08:08 <sdaftuar> yep
15:08:37 <sdaftuar> so that's a lot of stuff, and depending on what others view as priorities, that will influence where i focus my time
15:08:56 <jnewbery> thanks sdaftuar
15:09:02 <jnewbery> jonatack: priorities?
15:09:57 <jonatack> review
15:10:02 <jonatack> refactoring/cleanup
15:10:15 <jonatack> for a couple of weeks i was working on inbound eviction policy
15:10:19 <jonatack> methodology was (1) an observation dashboard (#19643), 2) test coverage, and 3) optimisation
15:10:22 <gribble> https://github.com/bitcoin/bitcoin/issues/19643 | Add `-netinfo` peer connections dashboard by jonatack · Pull Request #19643 · bitcoin/bitcoin · GitHub
15:10:32 <jonatack> i didn't realize that suhas was working on it as well
15:11:01 <jonatack> i was then asked by a few devs to consider picking up bip324 implementation
15:11:19 <jonatack> talked with jonas schnelli today and he will be back on it soon
15:11:32 <jonatack> he needs help with one sticking point
15:12:08 <jonatack> i don't have the gist handy, will provide a bit later, we were discussing this with ariard, warren, moneyball, wumpus and jonasschnelli
15:12:31 <jonatack> atm i need to do some work on #11413 followups
15:12:34 <gribble> https://github.com/bitcoin/bitcoin/issues/11413 | [wallet] [rpc] sendtoaddress/sendmany: Add explicit feerate option by kallewoof · Pull Request #11413 · bitcoin/bitcoin · GitHub
15:12:45 <dongcarl> jonatack: do you have link to bip324 discussion?
15:13:23 <jonatack> so will stick with review and p2p refactoring on the side until that's done: we need a universal explicit feerate rpc
15:13:33 <jnewbery> ok, thanks jonatack
15:13:42 <jonatack> dongcarl: yes, will post, that's it for now
15:13:45 <jnewbery> troygiorshev: priorities?
15:13:56 <troygiorshev> two p2p things I've been focusing on
15:14:07 <troygiorshev> big refactor: #19107, moving header verification from net_processing to net.  came out of a PR review club of a jonasschnelli pr.  it's not flashy, but cleaning up this interface will make everything easier going forward.
15:14:10 <gribble> https://github.com/bitcoin/bitcoin/issues/19107 | p2p: Move all header verification into the network layer, extend logging by troygiorshev · Pull Request #19107 · bitcoin/bitcoin · GitHub
15:14:23 <troygiorshev> feature: #19031 addrv2.  tor v2 deprecation and obsolescence is quickly approaching, addrv2 is needed before we can update to tor v3.
15:14:27 <gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
15:14:36 <jonatack> +1
15:15:02 <jnewbery> ok, thanks troy
15:15:02 <jonatack> 15 sept tor v2 deprecation begins, obsolete next july
15:15:12 <jnewbery> dongcarl: priorities?
15:15:31 <dongcarl> mostly review
15:15:40 <dongcarl> focused on the PRs populating the Peer struct
15:15:55 <dongcarl> also, waiting on Shadow simulator v2 from Tor project
15:16:05 <dongcarl> which I think will be the best way to test our P2P
15:16:12 <dongcarl> Link: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Sponsor38
15:16:17 <dongcarl> that's it!
15:16:23 <jnewbery> (Peer struct is #19607)
15:16:26 <gribble> https://github.com/bitcoin/bitcoin/issues/19607 | [p2p] Add Peer struct for per-peer data in net processing by jnewbery · Pull Request #19607 · bitcoin/bitcoin · GitHub
15:16:28 <jnewbery> thanks carl!
15:16:36 <jnewbery> ajonas: priorities?
15:17:00 <ajonas> I can wait until we move onto the next topic
15:17:12 <jnewbery> ok
15:17:16 <jnewbery> amiti: priorities?
15:17:28 <amiti> My main focus has been 19316- simplifying how we track different types of connections. Got some reviews yesterday & hopefully its getting close to merge, so planning to address outstanding review comments in a follow up.
15:17:43 <amiti> (ps @dongcarl, @jnewbery if you wanna take another look :))
15:17:49 <amiti> After that I’m excited about #19315 to enable more p2p testing. And I want to make my way back to the rebroadcast work!
15:17:53 <gribble> https://github.com/bitcoin/bitcoin/issues/19315 | [tests] Allow outbound & block-relay-only connections in functional tests. by amitiuttarwar · Pull Request #19315 · bitcoin/bitcoin · GitHub
15:18:21 <amiti> In terms of review, there’s a lot of PRs I’m excited about and slowly making my way through. Currently reviewing #19670. Also on my list are #17428 (anchors), #19184 (tx logic overhaul). and the per-peer stuff #19509 & #19607 is also interesting
15:18:23 <gribble> https://github.com/bitcoin/bitcoin/issues/19670 | Protect localhost and block-relay-only peers from eviction by sdaftuar · Pull Request #19670 · bitcoin/bitcoin · GitHub
15:18:28 <gribble> https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
15:18:28 <jonatack> dongcarl: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
15:18:31 <gribble> https://github.com/bitcoin/bitcoin/issues/19184 | Overhaul transaction request logic by sipa · Pull Request #19184 · bitcoin/bitcoin · GitHub
15:18:34 <gribble> https://github.com/bitcoin/bitcoin/issues/19509 | Per-Peer Message Logging by troygiorshev · Pull Request #19509 · bitcoin/bitcoin · GitHub
15:18:38 <jnewbery> I left my ACK on 19316 this morning :)
15:18:39 <gribble> https://github.com/bitcoin/bitcoin/issues/19607 | [p2p] Add Peer struct for per-peer data in net processing by jnewbery · Pull Request #19607 · bitcoin/bitcoin · GitHub
15:18:55 <amiti> oh I didn't see that yet. awesome thanks!!
15:18:58 <jnewbery> thanks amiti
15:19:18 <jnewbery> fanquake: priorities?
15:19:55 <fanquake> Nothing I am/have been working on is really p2p related. Can probably skip me.
15:20:05 <jnewbery> ok
15:20:10 <jnewbery> pinheadmz: priorities?
15:20:25 <pinheadmz> sorry not much to contribute today
15:20:33 <jnewbery> no problem
15:20:43 <jnewbery> ariard: priorities?
15:21:15 <ariard> yes so AltNet (#18988) is pending on Russ multiprocess
15:21:18 <gribble> https://github.com/bitcoin/bitcoin/issues/18988 | RFC: Introducing AltNet, a pluggable framework for alternative transports by ariard · Pull Request #18988 · bitcoin/bitcoin · GitHub
15:21:35 <ariard> it would make it far easier to leverage the new multiprocess framework introduced
15:21:55 <ariard> also spend a bit of time evaluating which package relay/RBF pinning flavor would solve pinning
15:22:32 <ariard> I'm also interested in tx-relay peer rotation, to improve transaction propagation wrt to pinning/mempool obstruction
15:23:20 <ariard> I would be glad to get #19645, even if utility is reduced until further mempool/transaction relay policy changes, that's a first step to solve wtxid-pinning issues
15:23:22 <gribble> https://github.com/bitcoin/bitcoin/issues/19645 | Allow wtxid-acceptance to the mempool by ariard · Pull Request #19645 · bitcoin/bitcoin · GitHub
15:23:45 <ariard> and I'm staying available to review transaction request overhaul/erlay/others
15:23:53 <ariard> that's it
15:24:07 <jnewbery> thanks ariard!
15:24:12 <jnewbery> theStack: priorities?
15:25:06 <jnewbery> elichai2: priorites?
15:25:55 <jnewbery> sipa: priorities?
15:26:13 <jnewbery> (if you missed your turn you can jump in again later)
15:26:37 <sipa> so
15:27:02 <sipa> the next thing on my list is addressing some feedback in 19184 (tx overhaul), and rebasing on top of wtxid relay
15:27:45 <sipa> i'm also interested in helping with bip324 efforts and addrv2, though i haven't found much time for that
15:28:17 <sipa> outbound peer rotation also sounds interesting; i wasn't aware there was recent interest in that
15:29:04 <aj> jnewbery: (priorities?)
15:29:19 <elichai2> I don't work on anything p2p related right now, but I do plan to review a bunch of stuff, so if there'll be a high priority for review out of this it would be great
15:29:32 <jnewbery> we haven't done adiabat and vasild yet, but I can go next
15:29:45 <jnewbery> My short-term focus is on the backports. I've reviewed #19680 and 19681. I've also backported wtxid relay in #19606, which I still think we should backport to v0.20.
15:29:47 <gribble> https://github.com/bitcoin/bitcoin/issues/19680 | 0.20: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19680 · bitcoin/bitcoin · GitHub
15:29:49 <gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
15:29:58 <jnewbery> I also have a branch that backports the orphan relay stuff on top of that, which I think makes sense to PR separately, but I can add to v0.20 if that makes it easier for reviewers.
15:30:44 <jnewbery> I'd advocate for people to bump reviewing backports up their priority list (both for these backports and in general inBitcoin Core)
15:30:55 <jnewbery> Longer-term, I want to make progress on #19398, where the main goal is to clarify the interface between net and net_processing, while not expanding the scope of cs_main (and then eventually reduce the scope of cs_main by moving data into the new Peer struct).
15:30:56 <gribble> https://github.com/bitcoin/bitcoin/issues/19398 | Move remaining application layer data to net processing · Issue #19398 · bitcoin/bitcoin · GitHub
15:31:06 <jnewbery> The first PR is #19607. theuni left some review comments last week which I need to respond to.
15:31:08 <gribble> https://github.com/bitcoin/bitcoin/issues/19607 | [p2p] Add Peer struct for per-peer data in net processing by jnewbery · Pull Request #19607 · bitcoin/bitcoin · GitHub
15:31:16 <jnewbery> that's me
15:31:25 <jnewbery> adiabat: anything you want to add/share?
15:32:00 <jnewbery> vasild: priorities?
15:32:26 <vasild> my priority is to get BIP155 / addrv2 https://github.com/bitcoin/bitcoin/pull/19031 merged.
15:32:39 <jnewbery> great. Thanks
15:32:45 <jnewbery> Thanks everyone! I hope that topic wasn't too slow. I just wanted to make sure everyone had a chance to share what they're working on/prioritizing.
15:32:57 <jnewbery> we had one other topic suggestion from ajonas
15:33:07 <ajonas> hi
15:33:10 <jnewbery> #topic Opt-in review begging experiment
15:33:30 <vasild> so, I address review suggestions as quickly as possible and rebase it to resolve conflicts. But mostly it is in the hands of reviewers. While waiting on that I am reviewing some randomly picked PRs.
15:33:43 <ajonas> Let me start with the priorities I'm tracking: https://gist.github.com/adamjonas/85137e2623f12450f1978d291a28d680. I think there are some things on there that weren't mentioned or that other people who care about, but weren't here today to mention.
15:34:38 <ajonas> Please ping me if I got something wrong or there are things that you'd like to add
15:34:44 <vasild> maybe I can improve on what I pick to review. https://github.com/bitcoin/bitcoin/projects/8 is the correct place to pick "important" PRs to review?
15:35:26 <ajonas> Ok. A few months ago, I was reading over https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-07-priorities/, which articulates some possibilities for how to better coordinate review. Since then, I've been experimenting with asking for reviews directly. (This was also the motivation of #18949).
15:35:29 <gribble> https://github.com/bitcoin/bitcoin/issues/18949 | doc: Add CODEOWNERS file to automatically nominate PR reviewers by adamjonas · Pull Request #18949 · bitcoin/bitcoin · GitHub
15:36:03 <ajonas> Right now the sample size and the circle I feel comfortable bothering is small. Here are the results so far: https://docs.google.com/spreadsheets/d/1INEN1RrZTsu-V4GH6kr0aVhFOVY8nGgx0ajHf3NEYlc/.
15:36:29 <jnewbery> vasild: importance is subjective. Being on that list doesn't necessarily mean that other people think it's important, but everyone is allowed to add one PR to the list, so you can see what each author is prioritizing.
15:36:38 <ajonas> To date, I've cherry picked the PRs that I think I have a chance to help out with so while the numbers look good, there are some notable exceptions where I couldn't move the needle.
15:36:58 <ajonas> And on some of those I just got lucky I think,
15:37:20 <jonatack> ajonas: some of those are merged
15:37:37 <jonatack> e.g. 16756
15:38:17 <ajonas> Right. Column J shows the time from PR open to merge
15:38:33 <troygiorshev> ajonas: how did you define "review" in "review to merged (days)".  first ACK, first ACK on the current rebase, when you felt that there was enough review that it was RFM?
15:38:39 <ajonas> Sorry that's column I
15:38:46 <jonatack> ajonas: oic
15:39:26 <ajonas> yeah, that's misleading troygiorshev. I mean first nag to merge.
15:39:39 <vasild> Yes, importance is subjective. However, it would be convenient to have one place to look for important PRs, even if that place contains different people's lists.
15:39:42 <troygiorshev> ajonas: ah ok
15:39:55 <ajonas> Anyways, if anyone interested in p2p reviewing and would like to opt-in, I'd be interested in expanding my experiment that part of the code.
15:40:00 <jnewbery> I think there are so many other factors, that I
15:40:12 <sdaftuar> ajonas: you mean opt-in to being nagged by you, right?
15:40:16 <jnewbery> 'm not sure the numbers have much meaning
15:40:39 <aj> i had been maintaining https://github.com/users/ajtowns/projects/1 to track p2p/mempool PRs by category things, but hadn't automated it and slacked off this year, it's on my todo to try automating again
15:40:47 <ajonas> sdaftuar: yes
15:41:32 <jnewbery> aj: I found that project board useful to find p2p PRs
15:41:48 <ajonas> jnewbery: fair enough. I'm just trying to track the work I've done. Not trying to claim credit for the merges. Just trying to help coordinate.
15:42:25 <jonatack> vasild: i think it's fine to define one's own list of important PRs to review. e.g. longer term for me would be: BIP155/addrv2, BIP324, BIPs340-342, BIP325
15:42:28 <troygiorshev> vasild: I plan on using this meeting log as a "one place to look" :)
15:42:56 <aj> jnewbery: maybe ajonas should opt me in to nags about it then
15:42:58 <jnewbery> ajonas: I understand! I'm just saying that you might not find much signal in the quantative data there
15:43:28 <vasild> ack
15:44:06 <ajonas> That's all I had.
15:44:18 <jnewbery> ajonas: are you asking people to opt-in now or should they message you?
15:44:31 <ajonas> Either works.
15:44:47 <jnewbery> ok, thanks
15:45:11 <sipa> i am open to nagging
15:45:28 <jnewbery> no more proposed topics. Was there anything else anyone wanted to discuss? sdaftuar: it sounded like you might have wanted to go into a bit more detail on some of your priorities?
15:45:33 <sdaftuar> topic suggestion: feature negotiation (new bip proposal from me)
15:45:37 <fanquake> One related comment I'd make is that the "ACK recap" comments can sometimes be misleading. I think there can also be confusion as to why a PR which looks like it has *lots* of ACKs, maybe after a review-club bomb, hasn't been merged.
15:45:39 <ajonas> sipa: great!
15:46:10 <troygiorshev> fanquake: ack recap?
15:46:11 <jnewbery> #topic feature negotiation
15:46:30 <aj> troygiorshev: ajonas sometimes posts a PR comment summarising previous acks
15:46:32 <sdaftuar> i was planning to send this to the mailing list today or tomorrow, so figured this would be a good place to mention it
15:46:34 <sdaftuar> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki
15:46:36 <amiti> fanquake: can you tell me more? I find those ACK recap comments helpful when there's lots of convo on the PR. is there something that can be done to make them more useful?
15:46:44 <troygiorshev> aj: thanks
15:47:02 <sdaftuar> basically wtxid-relay uses a new feature-negotiation method (exchanging messages between version and verack), that would be nice to codify as a method in the future
15:47:20 <jonatack> amiti: +1 i find them useful as well
15:47:29 <sdaftuar> however, i think we need to make sure software on the network knows to ignore unknown messages pre-verack to make this a possibility.  bitcoin core historically has disallowed unknown messages pre-verack
15:47:57 <sdaftuar> so i think it would be nice to get this out there and hopefully make this a standard way we can do things going forward
15:48:02 <sdaftuar> (end)
15:48:43 <jnewbery> is the idea that each feature has its own p2p message for enabling the feature (like wtxidrelay)?
15:48:55 <sdaftuar> features that need to negotiate at connection startup time.
15:48:56 <ariard> sdaftuar: I think that's good it was unclear between matt and I on bip339 implemn in rust-bitcoin about why 339 bumps both protocol version and wtxid-relay
15:48:57 <troygiorshev> (like addrv2)
15:49:01 <sdaftuar> so many features don't need that, which is fine
15:49:08 <fanquake> amiti: it depends on the PR. Concept ACKs from months ago, after the code has changed significantly are not always relevant. A large amount of ACKs from new/unknown contributors obviously don't hold as much weight  as from contributors with more experience in that part of the code.
15:49:15 <sdaftuar> but the next time we want to negotiate something that is in place before a connection is fully setup, i think this is the best way to do it
15:49:27 <sdaftuar> in particular i'd like to leverage this method for negotiating block-relay only connections
15:49:40 <ajonas> fanquake: I have made an effort to stay away from review club PRs
15:50:08 <fanquake> It's also sometimes unclear what reviewers actually mean when they ACK. i.e if they've just run the functional tests after glancing at the diff on GH, that isn't necessarily meaningful.
15:50:32 <jnewbery> fanquake: can we discuss this next?
15:50:46 <aj> sdaftuar: i thought wtxid message made sense, so making it easily reusable makes sense
15:50:47 <amiti> sdaftuar: I'm a +1 to an explicit message/negotiation for block-relay only connections
15:51:00 <fanquake> jnewbery: sure. don't want to hijack.
15:51:06 <troygiorshev> sdaftuar: concept ACK
15:51:19 <jonatack> troygiorshev: i think vasild's addrv2 implementation can set itself anytime during the connection, not only at handshake
15:51:27 <sdaftuar> one point that occurred to me, is that might update the draft i pasted above to NOT further bump the version number to signal support
15:51:28 <ariard> if I understand well this bip is disentangling protocol version bump from feature negotiation by allowing feature signaling between version/verack
15:51:50 <sdaftuar> because software that chooses to not implement wtxid-relay should already be adopting this proposed bip, basically (if they bump their version number to 70016 or higher at any point)
15:52:06 <sdaftuar> that's a bit in the weeds though for there
15:52:08 <sdaftuar> here*
15:52:10 <jnewbery> I've always thought that extending the version message to include supported and required features would be a good way to negotiate features
15:52:56 <sdaftuar> ariard: yes. more importantly than that is that we're establishing that unknown messages should not cause peer disconnections, which could be problematic for network topology if we get this wrong in the future
15:53:05 <sdaftuar> even if those unknown messages are before VERACK
15:53:11 <troygiorshev> jonatack: right.  I think I remember discussion as to whether that was the right choice though
15:53:40 <sipa> sdaftuar: this all sounds reasonable
15:53:44 <vasild> https://github.com/sdaftuar/bips/blob/2020-08-generalized-feature-negotiation/bip-p2p-feature-negotiation.mediawiki -- something like that came to my mind when doing the BIP155 sendaddrv2 message. Is every new feature going to add its own message sendfoowhatever? Not very nice.
15:53:45 <sdaftuar> wtxid-relay BIP implied that, i'm just now making that more explicit. this would require a change to bitocin core as well
15:54:21 <sdaftuar> vasild: that's basically how we've done every p2p protocol upgrade in the last 4-5 years i think?
15:54:28 <sipa> i find the reliance on protocol versions to enable feature-negotiability a bit ugly still - less so than the earlier feature negotiation through version numbers directly, but still
15:54:28 <sdaftuar> well either that or a service bit i guess
15:54:31 <sdaftuar> but service bits are rare
15:54:32 <troygiorshev> vasild: your point is the motivation for jnewbery's "extended version" iirc
15:54:49 <jnewbery> sdaftuar: do you know whether there are nodes that disconnect on unknown message types? Bitcoin Core just drops them (which I think is the only sensible behaviour)
15:55:14 <sdaftuar> jnewbery: it's been the de facto standard (not documneted anywhere to my knowledge) that unknonw messages after a connection is setup are ignored by software
15:55:23 <vasild> jonatack: troygiorshev: yes, the BIP155 sendaddrv2 can come any time, but we try to do it early so that when the peer is about to advertise his own address to us, he has the option to send us addrv2 - would be important if his address is torv3 because he wouldn't be able to advertise it to us with addr(v1)
15:55:26 <sdaftuar> it has not been the standard, to my knowledge, to allow unknown messages pre-verack
15:55:43 <jnewbery> ah ok. That's the difference
15:57:05 <jnewbery> ok, any final topics?
15:57:37 <jnewbery> that's a wrap then. Thanks everyone
15:57:39 <ariard> sdaftuar: what do you mean by broad agreement? we need this BIP to be widely deployed before using the new feature signaling mechanism ?
15:57:42 <jnewbery> Let me know if you liked the format of this meeting or if you want to change it up for next time.
15:57:42 <aj> sdaftuar: my thinking on big changes priority-wise is: tx relay overhaul up next, then erlay if we can get to it; but package relay is back to the drawing board. happy to think about ...
15:57:57 <troygiorshev> jnewbery: this was great, thanks for organizing it!
15:58:08 <sdaftuar> aj: yeah that's where i'm at as well on that side of things
15:58:11 <aj> sdaftuar: ... some of the topology type stuff, in before erlay i guess?
15:58:17 <sdaftuar> aj: i'm trying to figure out how to squeeze in topology work too
15:58:18 <jonatack> there was an irc discussion on the pre-verack messages here: https://bitcoincore.reviews/18044#l-159
15:58:48 <adiabat> maybe tangential but... any thoughts on port flexibilty
15:58:59 <adiabat> I've gotten servers shut down, and all they do is see that 8333 is open
15:59:25 <sdaftuar> ariard: well, if any software authors brought up concerns about why using unknown messages between version and verack is a problem, then we should factor that in--
15:59:44 <sdaftuar> if some software clients choose to not follow my proposal, that would create implications for us trying to use it down the road
15:59:47 <sdaftuar> as it could partition the network
16:00:06 <sdaftuar> i am not aware of any opposition; i brought this issue up with wtxid-relay and no one commented on it
16:00:20 <jnewbery> #endmeeting