21:00:29 <jnewbery> #startmeeting 
21:00:30 <core-meetingbot> Meeting started Tue Mar 23 21:00:29 2021 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
21:00:30 <core-meetingbot> Available commands: action commands idea info link nick
21:00:33 <gleb> hi!
21:00:35 <jnewbery> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow 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
21:00:41 <jnewbery> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
21:00:51 <amiti> hi
21:01:01 <aj> hey
21:01:23 <luke-jr> uh?
21:01:24 <jnewbery> We have one proposed topic in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings (Erlay update from Gleb)
21:01:36 <jamesob> hi
21:01:57 <sipa> hi
21:02:05 <jnewbery> Feel free to share your p2p priorities here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
21:02:22 <jnewbery> anyone have any quick updates or want to add a topic before we get on to erlay?
21:02:46 <jnewbery> ok
21:02:52 <jnewbery> #topic Erlay update (gleb)
21:02:52 <core-meetingbot> topic: Erlay update (gleb)
21:03:08 <gleb> So I just opened a new PR instead of the old one which was not reviewable any more.
21:03:20 <gleb> It's much-much refactored at this point.
21:03:30 <sipa> cool
21:03:42 <gleb> (I also believe I didn't skip any comment from the old PR except 1 or 2 debatable topics)
21:04:07 <glozow> hai
21:04:07 <gleb> I mark this as draft until I make sure it builds and passes test (including minisketch make check) smoothly
21:04:35 <gleb> But generally if you're fine with reviewing code by eyes and not building, it's pretty much ready.
21:04:47 <jnewbery> needs rebase :)
21:04:52 <jamesob> exciting
21:04:56 <gleb> Gonna make it non-draft tomorrow I hope. And yeah, I see the rebase...
21:05:00 <gleb> One big question though.
21:05:17 <gleb> I added a lot of functional tests for any possible path of Erlay
21:05:39 <gleb> But no unit tests yet... What would we want there? Something as big as testing framework we have for txrequest?
21:05:53 <gleb> (Maybe you can answer only after reviewing, which is fine)
21:06:01 <sipa> i don't think the goal should "having unit tests"
21:06:19 <sipa> your goal is to test the code you have, and for every kind of tests, there are more and less appropriate ways of doing so
21:06:28 <sipa> if everything can be tested through functional tests, that's great
21:06:45 <jamesob> and for P2P stuff, that's actually plausible...
21:07:03 <gleb> Well, I introduce like 5 new types of messages.
21:07:14 <sipa> but there are probably lower-level data structures etc that deserve testing in a more low-level way
21:07:18 <gleb> Testing all sequences in functional tests would be very messy...
21:08:28 <gleb> sipa: on the high-level I agree. On the low-level, I find it a bit challenging to find the right balance :)
21:08:47 <sipa> you can write a p2p fuzz tests like the net_process one that's specific to recon messages
21:09:19 <sipa> i'll need to look at the code for more specific suggestions
21:09:31 <gleb> alright, and I'll consider what you said so far. Thanks.
21:09:41 <gleb> I think that's it on my side, unless people have questions.
21:10:04 <jnewbery> thanks gleb!
21:10:35 <jnewbery> anyone else want to give any updates?
21:10:42 <michaelfolkson> Given Erlay is a bandwidth improvement it is just a case of normal P2P testing behavior rather than ensuring any Erlay specific guarantees right?
21:11:02 <sipa> michaelfolkson: everything should be tested
21:11:23 <jnewbery> or any review begs from https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities ?
21:11:28 <sipa> both the fact that p2p high-level goals still work (transactions propagate etc) and the fact that erlay itself works, down to as much detail as possible
21:11:30 <michaelfolkson> sipa: Right but I'm just thinking of where Erlay could break down and you'd need a specific test for that
21:12:09 <sipa> michaelfolkson: it could for example work perfectly, but be subtle different from the spec, i a way that makes it (a) useless and not actually saving bandwidth or (b) won't be compatible with other implementations
21:12:37 <michaelfolkson> sipa: Testing subtleties against spec, yeah that's a good one
21:12:39 <amiti> sure, happy to review beg for 21061 :) there are some outstanding comments I need to address, but approach feedback would be very useful!!
21:12:45 <sipa> #21061 
21:12:49 <gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
21:13:32 <jnewbery> I'm planning to review rebroadcast soon
21:13:32 <lightlike> I think it's also interesting how erlay and traditional relay work together in the transition phase, my intuition says that unexpected things could happen, considering the different time scales.
21:13:58 <amiti> jnewbery: thanks :)
21:14:25 <sipa> lightlike: that's a good question, but probably something that's hard to test through automated tests (unless you mean things like it actually failing to propagate at all)
21:14:46 <lightlike> sipa: yes - that's probably something for simulations
21:14:49 <sipa> more like something to verify in simulations or large deployments
21:14:53 <gleb> lightlike: yeah I saw your comment earlier.
21:15:22 <gleb> I can try simulating that too, it's just would be so much better for us if we had an alternative simul stack crafted by non-me :)
21:15:33 <jnewbery> I'd appreciate some more review on #21236. It got some attention early on but it seems to have stalled a bit.
21:15:36 <gribble> https://github.com/bitcoin/bitcoin/issues/21236 | Net processing: Extract `addr` send functionality into MaybeSendAddr() by jnewbery · Pull Request #21236 · bitcoin/bitcoin · GitHub
21:15:59 <michaelfolkson> What is the Erlay transition phase? I just assumed once merged Erlay would be used by everyone with a fallback of not Erlay if it didn't work.
21:16:45 <sipa> michaelfolkson: there will be a time while the public mainnet bitcoin P2P network is a mix of erlay nodes and non-erlay nodes, and propagation must work well across those nodes too
21:17:22 <sipa> michaelfolkson: these are network-level properties e.g. what % of nodes receive a transaction within some amount of time, not something on the scale of an individual connection
21:17:22 <lightlike> and one type of propagation shouldn't cannibalize the other
21:17:37 <sipa> and without spiking bandwidth
21:17:49 <michaelfolkson> sipa lightlike: Ok thanks, makes sense
21:18:43 <jnewbery> any last updates/comments before we wrap up?
21:19:23 <jnewbery> #endmeeting