16:00:11 <stickies-v> #startmeeting 
16:00:11 <corebot> stickies-v: Meeting started at 2025-12-04T16:00+0000
16:00:12 <corebot> stickies-v: Current chairs: stickies-v
16:00:13 <corebot> stickies-v: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:14 <corebot> stickies-v: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:15 <corebot> stickies-v: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:18 <sedited> hi
16:00:20 <sipa> hi
16:00:24 <eugenesiegel> hi
16:00:24 <hodlinator> hi
16:00:29 <yancy> hi
16:00:31 <stickies-v> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge dzxzg eugenesiegel fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs janb84 jarolrod jonatack josibake kanzure kevkevin laanwj LarryRuane lightlike l0rinc luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild
16:00:31 <stickies-v> willcl-ark
16:00:38 <hebasto> hi
16:00:39 <furszy> hi
16:00:41 <kevkevin> hi
16:00:42 <stringintech> hi
16:00:44 <janb84> hi
16:00:52 <pinheadmz> hi
16:00:58 <instagibbs> hi
16:01:00 <dzxzg> hi
16:01:02 <stickies-v> There is one pre-proposed meeting topics this week. Any last minute ones to add?
16:01:06 <jonatack> hi
16:01:09 <fjahr> hi
16:01:25 <dergoegge> hi
16:01:56 <stickies-v> let's get started with the WG updates, please have your updates (or at least a brief acknowledgement) ready so I can quickly skip to the next group in case of absence
16:02:11 <darosior> hi
16:02:15 <stickies-v> no fuzzing updates today, so skipping that
16:02:22 <stickies-v> #topic Kernel WG Update (sedited)
16:02:38 <sedited> A bunch of PRs on the board waiting for review: https://github.com/orgs/bitcoin/projects/3
16:03:13 <sedited> that's all for today.
16:03:21 <l0rinc> hi
16:03:28 <marcofleon> hi
16:03:32 <vasild> hi
16:03:32 <lightlike> hi
16:03:53 <stickies-v> #topic Benchmarking WG Update (l0rinc, andrewtoth)
16:03:58 <l0rinc> Continuing the work in #31132, fuzzing and benchmarks now use real LevelDB in the background for extra realism.
16:04:03 <corebot> https://github.com/bitcoin/bitcoin/issues/31132 | validation: fetch block inputs on parallel threads >40% faster IBD by andrewtoth · Pull Request #31132 · bitcoin/bitcoin · GitHub
16:04:08 <l0rinc> We've also measured the peak memory usage during reindex-chainstate: so far, it seems that the memory overhead is measurable (almost 100MB peak extra).
16:04:15 <l0rinc> Once we're close to the finish line, we can discuss whether we should do anything about it (e.g., we could lower the default dbcache size or try to reduce memory usage in other ways to compensate).
16:04:22 <andrewtoth> hi
16:04:24 <l0rinc> We still have to gather thorough flame graphs to understand the new usage patterns and see where the new bottlenecks will be after the change. We're also comparing how SSD and HDD are affected by different concurrency levels - these take really long, we don't have definitive results yet.
16:04:35 <l0rinc> We've also investigated whether we could avoid complete memory reallocations during IBD (after sync we need to fully release the memory), but it seems to slow down IBD so much (up to 3x on some platforms). Most likely this is because it forces each block to flush after the first one, since we're in a constant critical memory state if we don't reallocate (it behaves the same if we completely remove the reallocation). We will investigate if this is
16:04:35 <l0rinc> because of the Pool Allocator introduced in #25325 and if it's still optimal to have it after the input fetching optimizations above.
16:04:37 <corebot> https://github.com/bitcoin/bitcoin/issues/25325 | Add pool based memory resource by martinus · Pull Request #25325 · bitcoin/bitcoin · GitHub
16:04:44 <l0rinc> Reviews and fuzzing are still welcome, and in the meantime #30442 and #33602 would help make some progress on the above.
16:04:46 <corebot> https://github.com/bitcoin/bitcoin/issues/30442 | precalculate SipHash constant salt XORs by l0rinc · Pull Request #30442 · bitcoin/bitcoin · GitHub
16:04:49 <corebot> https://github.com/bitcoin/bitcoin/issues/33602 | [IBD] coins: reduce lookups in dbcache layer propagation by l0rinc · Pull Request #33602 · bitcoin/bitcoin · GitHub
16:05:06 <l0rinc> andrewtoth: anything else I left out?
16:05:10 <Murch[m]> Is sedited the artist formerly known as TheCharlatan?
16:05:33 <sipa> Murch[m]: what would you expect from a definitive Charlatan?
16:06:09 <l0rinc> that's it from me
16:06:11 <andrewtoth> any review is welcome. I think it's in a good spot right now.
16:06:14 <abubakarsadiq> hi
16:06:22 <darosior> Murch[m]: looks like it yes :)
16:06:28 <stickies-v> nice, thank you for the comprehensive overview and continued work on this!
16:06:33 <stickies-v> #topic Silent Payments WG Update (Novo__)
16:07:27 <sipa> not really a workgroup member, but i note this relevant ML discussion: https://groups.google.com/g/bitcoindev/c/bP6ktUyCOJI
16:08:16 <brunoerg> hi
16:08:35 <stickies-v> thanks sipa! we haven't had updates from the SP WG in quite a while so I suggest archiving this WG until one of the champions requests to activate again. lmk if anyone doesn't agree with this
16:08:44 <stickies-v> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:08:47 <sipa> Cluster mempool followups (33591) were merged, i'd encourage anyone to run with it, play around with the new RPCs, see if logging makes sense, etc. Next up for review is my #32545, which may end up being split into multiple PRs based on review.
16:08:49 <corebot> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
16:09:15 <abubakarsadiq> From Novo__I have rebased https://github.com/bitcoin/bitcoin/pull/32966 so it now tracks https://github.com/bitcoin-core/secp256k1/pull/1765. https://github.com/bitcoin-core/secp256k1/pull/1765 still needs review. The biggest issue is the worst case scanning performance, theStack and W0xlt have produced working solutions with tradeoffs that are being verified by benchmarks. Reviews are welcome!
16:09:18 <Murch[m]> Congrats!
16:10:18 <stickies-v> whoever's going to write the v31 testing guide should have a lot of fun with cluster mempool stuff
16:10:27 <instagibbs> I have a couple PRs I think should be in 31: #33892 and #33616
16:10:29 <corebot> https://github.com/bitcoin/bitcoin/issues/33892 | policy: Remove individual transaction <minrelay restriction by instagibbs · Pull Request #33892 · bitcoin/bitcoin · GitHub
16:10:31 <corebot> https://github.com/bitcoin/bitcoin/issues/33616 | policy: don't CheckEphemeralSpends on reorg by instagibbs · Pull Request #33616 · bitcoin/bitcoin · GitHub
16:10:42 <lightlike> sipa has connection problems, but that's it from him.
16:11:06 <stickies-v> I don't have permissions to set milestones but hopefully someone who does can update that for instagibbs ?
16:11:37 <stickies-v> sorry, i've been told milestones are already on there.
16:11:49 <dergoegge> #proposedmeetingtopic why is #33723 not merged yet
16:11:49 <corebot> dergoegge: Unknown command: #proposedmeetingtopic
16:11:51 <corebot> https://github.com/bitcoin/bitcoin/issues/33723 | chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us by SatsAndSports · Pull Request #33723 · bitcoin/bitcoin · GitHub
16:11:51 <instagibbs> :) just speaking up in case people want to review smaller prs
16:11:55 <stickies-v> #topic Stratum v2 WG Update (sjors)
16:12:25 <darosior> meta point: if stickies-v is going to run meetings regularly it'd make sense that he has triage permission on the Github repo
16:13:01 <sipa> hi
16:13:21 <cfields> +1
16:13:41 <stickies-v> #topic Net Split WG Update (cfields)
16:14:13 <cfields> Continuing to work on the initial PR to move some things into Peer. Got some nice feedback from AJ on the meta issue (#33958) that I'm working on a response to as well. That's about it, not much to see yet.
16:14:14 <corebot> https://github.com/bitcoin/bitcoin/issues/33958 | Net split meta issue · Issue #33958 · bitcoin/bitcoin · GitHub
16:15:04 <_aj_> (in working on that response, i finally got the bip324 short message type update idea from 3 years ago implemented which had been in my backlog)
16:15:29 <b10c> hi
16:15:40 <cfields> 🚀
16:16:13 <stickies-v> #topic A short update on BIP 54 / Consensus Cleanup work (darosior)
16:17:17 <darosior> Not a Bitcoin Core specific topic, but one that i think could be interesting to people here. As you know i've been working on the Consensus Cleanup proposal for over two years now. After Matt's previous attempt in 2019, i spent the end of 2023 and much of 2024 researching the best mitigations for each issue. We published a BIP in early 2025, and
16:17:17 <darosior> there is now an implementation for review at Bitcoin Inquisition.
16:17:56 <darosior> The test vectors were also recently merged in the BIP repository
16:17:59 <Murch[m]> Great, what do you see as the next steps?
16:18:12 <stickies-v> https://github.com/bitcoin-inquisition/bitcoin/pull/99
16:18:24 <darosior> So if anybody is interested in helping moving things forward, this is getting to the stage where i could use more eyes on the implementation
16:18:57 <dergoegge> Why in inquisition and not in the main repo?
16:19:48 <darosior> Because i want to run it on a test network for a while first, and Bitcoin Inquisition being a testbed for consensus changes seemed the appropriate place for now
16:20:23 <darosior> We can get it into inquisition, play with it for a couple months on signet, and possibly then consider a PR to the main Bitcoin Core repo
16:20:25 <dergoegge> So if the spec changes due to review on the main repo, we'll have to redo all of that?
16:20:46 <darosior> But that's the first stage of an implementation, so feel free to nitpick/bikeshed it to death!
16:20:54 <Murch[m]> I am just looking at the Inquisition PR. Somehow I expected it to be less than ~27k lines of code. ;)
16:20:54 <Murch[m]> How much of that is tests?
16:21:02 <darosior> dergoegge: i very much don't expect the spec to change at this point
16:21:08 <fanquake> _aj_: can you approve the CI to run in that PR?
16:21:25 <darosior> dergoegge: The spec has been researched / designed / debated to death for more than 2 years now
16:21:31 <instagibbs> Murch[m] its also including Simplicity (joke joke)
16:21:40 <stickies-v> i also don't think inquisition necessarily needs to be redone if the spec changes, depends on the circumstances if that makes sense?
16:21:41 <_aj_> fanquake: done
16:21:41 <darosior> Of course it can always happen but i don't think it's likely
16:21:56 <darosior> Murch[m]: 99.9%
16:22:01 <dergoegge> the code might change in significant ways as well
16:22:10 <darosior> The consensus changes are something like 10 lines
16:22:24 <Murch[m]> Yeah, that’s what I was expecting :)
16:22:26 <sedited> darosior, is the preparatory PR relevant for the upstream repo too?
16:22:26 <dergoegge> I just don't see why or how this became part of the process
16:22:35 <darosior> dergoegge: between inquisition and main Core repo? I don't think so
16:23:57 <darosior> sedited: i don't expect the relevant code to change much between Inquisition and upstream, so yes it is relevant
16:24:06 <dergoegge> I think the review should happen on the main repo, you can still deploy the PR where ever you want
16:24:10 <fanquake> How many major versions is inquisition lagging behind master at the moment?
16:24:18 <darosior> dergoegge: why?
16:24:25 <sedited> would it make sense to PR that then in the meantime?
16:24:29 <darosior> fanquake: a single one, it's on 29
16:24:54 <fanquake> darosior: right, so 1 version + any current changes (like cluster etc)
16:25:01 <darosior> I don't think there is any need to rush anything with a PR to the main repo
16:25:28 <dergoegge> I'm not saying merge the PR just review
16:25:30 <darosior> fanquake: yes, but that shouldn't be relevant
16:25:59 <darosior> shrugs
16:26:31 <darosior> I can also PR to the main repo, if people really feel so strongly about not coming review stuff in Inquisition
16:26:40 <dergoegge> wouldn't you want the visibility of the main repo for review?
16:26:52 <dergoegge> I'm not gonna review the inquisition PR
16:27:04 <darosior> Ok, does anyone else feel like dergoegge?
16:27:17 <darosior> Glad i brought it up, i didn't expect this
16:27:43 <_aj_> is there any particular problem with reviewing code in different repos? we already have gui, eg
16:27:49 <stickies-v> isn't it fine to merge on inquisition with less review, and then do the actual review on main - just to have some signet data available as extra information?
16:27:50 <dergoegge> it's been open for more than a month there and there's been basically no review
16:27:58 <darosior> And cmake, which was the main annoyance before the 29 rebase of inquisition
16:28:49 <darosior> stickies-v: that's what i'm looking for yes
16:29:08 <dergoegge> I don't think consensus changes should be reviewed elsewhere. What would be the reason for that?
16:29:42 <_aj_> dergoegge: are you assuming it won't get further review when PRed for core?
16:29:46 <darosior> Are we going to go into a discussion about the raison d'etre of Inquisition?
16:30:00 <dergoegge> i don speak french
16:30:06 <sedited> :D
16:30:28 <fjahr> dergoegge: for many changes the rebasing is annoying here, nobody is stopping anyone from reviewing on inquisition
16:30:41 <stickies-v> is anyone arguing for less review on the main repo? i don't think so?
16:30:52 <darosior> For the record, here is the rationale behind Inquisition https://gnusha.org/pi/bitcoindev/YyQioS3F942wu1HW@erisian.com.au/
16:31:13 <jonatack> darosior: je ne vois pas de souci de faire un premier tour de review sur inquistion puis un second tour de review dans le repo de bitcoin core
16:31:27 <dergoegge> fjahr: I'm guessing people just aren't aware
16:31:28 <jonatack> ca se cumule de toute facon :)
16:31:30 <stickies-v> okay let's keep it english on here please
16:31:31 <sipa> ah bon baguette
16:31:39 <darosior> Alright, i think i got across what i wanted to
16:32:02 <darosior> Just a heads up to people that there is code for review at Inquisition, if you are interested in having a look
16:32:14 <stickies-v> thanks darosior!
16:32:17 <darosior> I may open a PR to the Bitcoin Core main repo later on
16:32:23 <darosior> Meanwhile, that's where the action is
16:32:40 <darosior> jonatack: yes that's what i'm looking for :)
16:33:02 <stickies-v> #topic why is #33723 not merged yet (dergoegge)
16:33:04 <corebot> https://github.com/bitcoin/bitcoin/issues/33723 | chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us by SatsAndSports · Pull Request #33723 · bitcoin/bitcoin · GitHub
16:33:45 <dergoegge> (topic seems self explanatory)
16:34:41 <stickies-v> it does look like there is pretty overwhelming support for the change, and sufficient time for feedback/recourse?
16:35:18 <sipa> indeed
16:35:21 <sedited> have changes to the seed list been backported historically?
16:36:12 <sipa> i haven't commented myself, because as a DNS seed operator myself i feel sort of conflicted, but i do agree it looks like support for the change is overwhelming
16:37:09 <fjahr> I guess under normal circumstances the runner of the seed would be contacted and asked for a statement. Did anyone try to reach out? (I haven't looked at this at all)
16:37:34 <fanquake> sedited: I think if the rationale for removing it holds, it holds the same for all maintained branchs
16:37:43 <instagibbs> Luke hasn't seemed to weigh in, could ping him now that it's unlocked again, and give a timeline?
16:37:56 <stickies-v> sedited: it looks like #29691 was backported
16:37:58 <corebot> https://github.com/bitcoin/bitcoin/issues/29691 | Change Luke Dashjr seed to dashjr-list-of-p2p-nodes.us by luke-jr · Pull Request #29691 · bitcoin/bitcoin · GitHub
16:38:03 <dergoegge> he weighed in on the issue
16:38:08 <fjahr> Just like: Are you planning to fix this? And if there is no response this schould really be good to go
16:38:24 <fanquake> he already weighed in: https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3483326655
16:38:34 <dergoegge> it's also not about the seed not working properly, it's about trust.
16:38:41 <fjahr> ah, thanks
16:38:55 <darosior> I don't think the rationale is much about fixing, but about having our software point to a server ran by a person that is actively attacking the project. Just risk mitigation
16:40:05 <Murch[m]> Right, I don’t think it matters at this point which version of nodes he surfaces
16:40:57 <Murch[m]> He is actively attacking Bitcoin Core, we should rely as little as possible on him to act in the interest of Bitcoin Core
16:41:34 <instagibbs> to ask a shorter question: why should he care if "malware" is using his seeder
16:42:06 <Murch[m]> Well, he said he doesn’t, but that it might help Bitcoin Core to have another dnsseed
16:42:15 <stickies-v> i think rationale is already discussed in a lot of detail on the PR and issue, not sure that's worth repeating here
16:42:25 <stickies-v> (or if anything is missing, that should be added on the PR instead of here)
16:42:28 <instagibbs> Ok I retract :)
16:42:55 <dergoegge> yea, I was more curious why with all the agreement it hasn't been merged yet. Which is really something the maintainers should answer
16:43:14 <stickies-v> agreed, i'll give it another minute for a response otherwise i'll move on
16:44:37 <cfields> heh
16:44:41 <fjahr> there is your response
16:44:41 <Murch[m]> I guess then this is just a “33734 looks RFM”
16:44:43 <stickies-v> hah, well that's your answer dergoegge
16:44:47 <dergoegge> 🥰
16:44:48 <darosior> lol
16:44:58 <pinheadmz> productive meeting !
16:45:01 <kevkevin> :0
16:45:05 <eugenesiegel> nice
16:45:29 <cfields> darosior: apparently you just asked the wrong question about the gcc :p
16:45:41 <stickies-v> #topic IRC chair having triage permissions (darosior / stickies-v)
16:45:42 <darosior> haha :)
16:45:48 <darosior> Our current peer selection algorithm is to sample over all known node addresses and to pick a random one to connect to. The only way in which we enforce netgroup (/16 or, if configured, ASmap) diversity is that after picking an address at random we make sure it does not belong to a netgroup we are already connected to.
16:45:48 <darosior> I think this is pretty brittle from the perspective of preventing an attacker from controlling all our outbound connections. They just need to maximize the number of (possibly fake) nodes, as long as those are spread across as many netgroups as we make outbound connections by default. If we were to instead pick a random netgroup to connect to, and
16:45:48 <darosior> then pick a node from this netgroup, the probability for an attacker to control all of our outbound connections would be exponentially decreasing in the number of connections we make. So with 10 slots it would be essentially null, even if they control most of the available netgroups.
16:45:48 <darosior> Of course there is also a question of how much doing this would change the network graph. Currently the selection is biased towards connecting to netgroups with a large number of nodes, so in effect towards large hosting providers. Using a peer selection that first sample netgroups would remove this bias, and create a lot more connections to more
16:45:48 <darosior> "obscure" netgroups. Interestingly this would have a similar effect to turning ASmap on by default. We may not want to go all the way there, but maybe we could use this selection method for half of our outbound connection slots, as a middle ground between protecting from eclipse but still using the inbound connection slots available at large
16:45:49 <darosior> hosting providers.
16:45:49 <darosior> Aside from the AddrMan refactoring necessary to support this i first wanted to bring it up to discuss it conceptually. Do people think this is a good idea? A bad idea? Any other second-order effect that may be (in)desirable?
16:45:57 <darosior> Woops
16:46:03 <pinheadmz> oof
16:46:10 <stickies-v> darosior mentioned earlier that IRC chair could/should have triage permissions on the repo, so just wanna quickly address that here
16:46:11 <darosior> I saw the ping and assumed it was about the AddrMan peer selection
16:46:13 <fjahr> trigger happy
16:46:14 <instagibbs> prematurely blue yourself
16:46:23 <stickies-v> I don't think this is currently necessary, the IRC meeting chairs can do their job while maintainers/triagers do theirs, assuming at least 1 is on the meeting?
16:46:24 <darosior> Sorry about that :/
16:46:46 <sipa> i see issue with giving either of them triage permissions
16:46:46 <stickies-v> also, we have an IRC chair rotation, so it won't be just me going forward, and we shouldn't escalate permissions too much unless really necessary or helpful
16:46:54 <sipa> sorry, i see *NO* issue
16:46:58 <fanquake> Yea. I think if the idea is to rotate meeting chair, then no need to tie permissions to it
16:47:17 <darosior> Yes i must say my comment was specifically for stickies-v
16:47:36 <darosior> But if you don't need it, then you shouldn't have it, for sure
16:47:40 <sipa> yeah
16:48:00 <darosior> Can revisit if you bump into it again in the future?
16:48:16 <stickies-v> if maintainers/triager find they need more help doing the triaging i'm happy to consider, but i'm definitely not asking for it
16:48:23 <stickies-v> sounds good
16:48:30 <stickies-v> Anything else to discuss?
16:48:35 <darosior> Yes i had a topic
16:48:41 <darosior> About outbound peers selection
16:48:53 <darosior> I proposed it shortly before the meeting, unsure if it got registered
16:49:27 <stickies-v> #topic an outbound connection selection strategy more resistant to eclipse attacks (darosior)
16:49:38 <darosior> Ok now i'm shooting it
16:49:39 <stickies-v> (sorry it doesn't show up in the topics list but i see it in the logs here)
16:49:41 <darosior> Our current peer selection algorithm is to sample over all known node addresses and to pick a random one to connect to. The only way in which we enforce netgroup (/16 or, if configured, ASmap) diversity is that after picking an address at random we make sure it does not belong to a netgroup we are already connected to.
16:49:41 <darosior> I think this is pretty brittle from the perspective of preventing an attacker from controlling all our outbound connections. They just need to maximize the number of (possibly fake) nodes, as long as those are spread across as many netgroups as we make outbound connections by default. If we were to instead pick a random netgroup to connect to, and
16:49:41 <darosior> then pick a node from this netgroup, the probability for an attacker to control all of our outbound connections would be exponentially decreasing in the number of connections we make. So with 10 slots it would be essentially null, even if they control most of the available netgroups.
16:49:41 <darosior> Of course there is also a question of how much doing this would change the network graph. Currently the selection is biased towards connecting to netgroups with a large number of nodes, so in effect towards large hosting providers. Using a peer selection that first sample netgroups would remove this bias, and create a lot more connections to more
16:49:41 <darosior> "obscure" netgroups. Interestingly this would have a similar effect to turning ASmap on by default. We may not want to go all the way there, but maybe we could use this selection method for half of our outbound connection slots, as a middle ground between protecting from eclipse but still using the inbound connection slots available at large
16:49:41 <darosior> hosting providers.
16:49:42 <darosior> Aside from the AddrMan refactoring necessary to support this i first wanted to bring it up to discuss it conceptually. Do people think this is a good idea? A bad idea? Any other second-order effect that may be (in)desirable?
16:50:01 <Murch[m]> The proposedmeetingtopic thing seems to not work, it also said “unknown command” during the meeting
16:50:34 <_aj_> it's a separate script that updates a github page, probably on a timer; the # just confuses meetbot
16:50:39 <darosior> Of course there is also the question of how much can an attacker controlling all our outbound slots really achieve. For instance since #19858 they probably wouldn't be able to prevent us from seeing the most work chain for an extended period of time. But still i think it should be a goal to prevent an attacker from controlling all outbound
16:50:39 <darosior> connections of a node, let alone of a large fraction of nodes on the network.
16:50:41 <sipa> darosior: i worry that it cuts both ways: with the proposed modified strategy, an attacker can increase their probability of being connected to by finding an obscure AS or /16 with few bitcoin nodes in it, and just spinning up one in it
16:50:44 <corebot> darosior: Error: That URL raised <Connection timed out.>
16:51:04 <sipa> i'd like to think/simulate more about this
16:51:21 <darosior> sipa: of getting connected to sure, but not of being *exclusively* connected to
16:51:28 <Murch[m]> sipa: Good point. Maybe pick some with that strategy and others by randomly sampling from all?
16:51:33 <instagibbs> what's the best place to discuss this topic with paper trail for permanence
16:51:50 <darosior> I don't think we should worry about making one or two connections to an attacker
16:51:53 <lightlike> open an issue maybe?
16:51:54 <fjahr> I didn't have enough time to look at this but in Select_ we first pick a bucket and then a peer from it. So I think the netgroup does have a role or am I misunderstanding the code or lookign in the wrong place?
16:52:13 <sipa> fjahr: buckets are not netgroups
16:52:23 <sipa> (there is a correlation, but it's much more subtle than that)
16:52:27 <darosior> Some background for this is that this summer i looked into an entity that was spinning up a large number of fake nodes (see https://antoinep.com/posts/misbehaving_nodes/). I and a few others are now in discussion with the guy running this operation. He has since then scaled up and now controls 3000 reachable nodes, which is about 30% of all
16:52:27 <darosior> clearnet reachable nodes. As a result when you spin up a new nodes nowadays it would most of the time have around 3 outbound connections to this guy. We've had multiple reports of this happening. So all this to say my concern is not purely theoretical, there is an entity actively trying to demonstrate it, which is reasonably successful so far. This
16:52:27 <darosior> is discussed at b10c's https://bnoc.xyz/ forum. See https://bnoc.xyz/t/increase-in-the-number-of-reachable-ipv4-nodes-bitprojects-io/45/9 and https://bnoc.xyz/t/satoshi-29-1-0-dont-spam-me-bro-nodes/40/18
16:52:29 <fjahr> but they are part of forming the bucket?
16:52:35 <b10c> some data on this: there's currently an entity we sometimes have 4 outbounds to https://bnoc.xyz/t/satoshi-29-1-0-dont-spam-me-bro-nodes/40/19
16:52:42 <_aj_> sipa: why not just pick a /16 that doesn't have any listening nodes in it currently? there's still x000 /16s to choose from
16:53:11 <sipa> _aj_: ?
16:53:12 <fjahr> I should spend more time with the code and simulation is definitely needed
16:54:17 <sipa> darosior: yes, our goal is being not-exclusively-attacker-connected, and i think this means different behavior is desirable than minimizing attacker connections in general, but i have a hard time grasping how either strategy affects these
16:54:37 <darosior> Because the second-order effect on the network graph are similar to switching to ASmap by default i also looked into previous research into that, and Martin had an interesting comment a "ping pong effect" if the result is a network wide shortage of inbound connection slots
16:54:39 <darosior> https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609099274
16:54:56 <_aj_> sipa: your addrman has 10k nodes, split amongst 5k /16s, say. you have a 2k/10k chance of getting picked by node if you operate 2k nodes, but a 1/3k * 1/5 chance if you pick a /16 with 4 other nodes, or a 1/3k * 1/1 chance if you have a dedicated /16
16:55:44 <_aj_> sorry, s/3k/5k/
16:55:47 <jonatack> darosior: is this the guy who was proposing to change the default outbound connection count to 48-64 peers as a solution?
16:56:06 <sipa> _aj_: i'm missing some context, are you talking about what an attacker should do? with or without this proposed change?
16:56:34 <Murch[m]> I think AJ is giving probability of having at least one connection to some peer running a lot of nodes
16:56:38 <_aj_> sipa: yeah, vs "an attacker can increase their probability of being connected to by finding an obscure AS"
16:56:41 <darosior> jonatack: yes, he does seem quite confused about how all of this work, but i must hand it to him that i expected us to be more robust than that and his mainnet experiment demonstrated it to me
16:57:18 <_aj_> Murch[m]: probability of the first connection being to a given attacker, i guess
16:57:26 <Murch[m]> darosior: So, is your concern that we’d make all our outbound connections to someone sybilling like that?
16:57:57 <_aj_> Murch[m]: we somewhat trust outbounds, so if you're trying to spy on transactions being able to have most peers make an outbound connection to you may be helpful
16:57:57 <stickies-v> we're coming up to the meeting end - perhaps useful to continue the conversation on an github issue here, anyone volunteer to do that?
16:57:57 <darosior> I fail to see how this is a problem. Especially given that the probability that we make a higher number of connections to this one attacker is extremely small
16:58:54 <darosior> Murch[m]: yes
16:58:59 <eugenesiegel> I think this guy could cause some damage if he withheld blocks, even if only for 10 minutes...
16:59:06 <darosior> Definitely
16:59:18 <darosior> stickies-v: i can open an issue
16:59:31 <stickies-v> superb, thank you darosior
16:59:33 <lightlike> maybe a mixed strat could make sense: choose 50% of outbounds sampling by address as status quo, the other 50% sampling by /16 or AS.
16:59:35 <jonatack> darosior: yes please (one related thing I've had on my list is to improve awareness of addnode peers and how to use that)
16:59:49 <darosior> lightlike: yes exactly
17:00:03 <darosior> It would still have network wide effect though, and it's now clear how to anticipate that
17:00:11 <_aj_> s/now/not/ ?
17:00:13 <instagibbs> s/now/not/
17:00:21 <sipa> s/?/!/
17:00:42 <stickies-v> thanks for the lively meeting everyone, it's been a pleasure
17:00:44 <stickies-v> #endmeeting