< bitcoin-git>
bitcoin/master 7b3434f fanquake: build: don't try and use -fstack-clash-protection on Windows
< bitcoin-git>
bitcoin/master 1c3a857 fanquake: Merge #21421: build: don't try and use -fstack-clash-protection on Windows...
< bitcoin-git>
[bitcoin] fanquake merged pull request #21421: build: don't try and use -fstack-clash-protection on Windows (master...skip_stack_clash_windows) https://github.com/bitcoin/bitcoin/pull/21421
< bitcoin-git>
bitcoin/master 5555446 MarcoFalke: fuzz: Use ConsumeWeakEnum in addrman for service flags
< bitcoin-git>
bitcoin/master d400e67 MarcoFalke: Merge #21487: fuzz: Use ConsumeWeakEnum in addrman for service flags
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #21487: fuzz: Use ConsumeWeakEnum in addrman for service flags (master...2103-fuzzEnumWeak) https://github.com/bitcoin/bitcoin/pull/21487
< bitcoin-git>
bitcoin/master 1404c57 Sjors Provoost: [doc] Coin: explain that IsSpent() can also mean never existed
< bitcoin-git>
bitcoin/master 55ceaeb MarcoFalke: Merge #18030: doc: Coin::IsSpent() can also mean never existed
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18030: doc: Coin::IsSpent() can also mean never existed (master...2020/01/doc_is_spent) https://github.com/bitcoin/bitcoin/pull/18030
< bitcoin-git>
[gui] hebasto opened pull request #254: refactor: Drop redundant setEditTriggers(NoEditTriggers) calls (master...210323-edit) https://github.com/bitcoin-core/gui/pull/254
< bitcoin-git>
[gui] MarcoFalke merged pull request #248: Fix: For values of "Bytes transferred" and "Bytes/s" with 1000-based prefix names use 1000-based divisor instead of 1024-based (master...binary-prefix) https://github.com/bitcoin-core/gui/pull/248
< jnewbery>
anyone have any quick updates or want to add a topic before we get on to erlay?
< jnewbery>
ok
< jnewbery>
#topic Erlay update (gleb)
< core-meetingbot>
topic: Erlay update (gleb)
< gleb>
So I just opened a new PR instead of the old one which was not reviewable any more.
< gleb>
It's much-much refactored at this point.
< sipa>
cool
< gleb>
(I also believe I didn't skip any comment from the old PR except 1 or 2 debatable topics)
< glozow>
hai
< gleb>
I mark this as draft until I make sure it builds and passes test (including minisketch make check) smoothly
< gleb>
But generally if you're fine with reviewing code by eyes and not building, it's pretty much ready.
< jnewbery>
needs rebase :)
< jamesob>
exciting
< gleb>
Gonna make it non-draft tomorrow I hope. And yeah, I see the rebase...
< gleb>
One big question though.
< gleb>
I added a lot of functional tests for any possible path of Erlay
< gleb>
But no unit tests yet... What would we want there? Something as big as testing framework we have for txrequest?
< gleb>
(Maybe you can answer only after reviewing, which is fine)
< sipa>
i don't think the goal should "having unit tests"
< 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
< sipa>
if everything can be tested through functional tests, that's great
< jamesob>
and for P2P stuff, that's actually plausible...
< gleb>
Well, I introduce like 5 new types of messages.
< sipa>
but there are probably lower-level data structures etc that deserve testing in a more low-level way
< gleb>
Testing all sequences in functional tests would be very messy...
< gleb>
sipa: on the high-level I agree. On the low-level, I find it a bit challenging to find the right balance :)
< sipa>
you can write a p2p fuzz tests like the net_process one that's specific to recon messages
< sipa>
i'll need to look at the code for more specific suggestions
< gleb>
alright, and I'll consider what you said so far. Thanks.
< gleb>
I think that's it on my side, unless people have questions.
< jnewbery>
thanks gleb!
< jnewbery>
anyone else want to give any updates?
< 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?
< sipa>
michaelfolkson: everything should be tested
< 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
< michaelfolkson>
sipa: Right but I'm just thinking of where Erlay could break down and you'd need a specific test for that
< 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
< michaelfolkson>
sipa: Testing subtleties against spec, yeah that's a good one
< amiti>
sure, happy to review beg for 21061 :) there are some outstanding comments I need to address, but approach feedback would be very useful!!
< jnewbery>
I'm planning to review rebroadcast soon
< 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.
< amiti>
jnewbery: thanks :)
< 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)
< lightlike>
sipa: yes - that's probably something for simulations
< sipa>
more like something to verify in simulations or large deployments
< gleb>
lightlike: yeah I saw your comment earlier.
< 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 :)
< jnewbery>
I'd appreciate some more review on #21236. It got some attention early on but it seems to have stalled a bit.
< gribble>
https://github.com/bitcoin/bitcoin/issues/21236 | Net processing: Extract `addr` send functionality into MaybeSendAddr() by jnewbery · Pull Request #21236 · bitcoin/bitcoin · GitHub
< 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.
< 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
< 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
< lightlike>
and one type of propagation shouldn't cannibalize the other
< sipa>
and without spiking bandwidth
< michaelfolkson>
sipa lightlike: Ok thanks, makes sense
< jnewbery>
any last updates/comments before we wrap up?
< ariard>
jamesob: i'm not planning to do it, but would review it
< bitcoin-git>
[gui] hebasto opened pull request #256: Save/restore column sizes of the tables in the Peers tab (master...210323-peers) https://github.com/bitcoin-core/gui/pull/256