kevkevin_ has quit [Remote host closed the connection]
nejos97 has joined #bitcoin-core-dev
nejos97 has quit [Ping timeout: 252 seconds]
justache has quit [Read error: Connection reset by peer]
justache has joined #bitcoin-core-dev
dzxzg2 has quit [Remote host closed the connection]
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Ping timeout: 246 seconds]
flag has quit [Ping timeout: 260 seconds]
flag has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg_ has joined #bitcoin-core-dev
brunoer__ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 244 seconds]
brunoerg_ has quit [Read error: Connection reset by peer]
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
brunoer__ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
cmirror has quit [Remote host closed the connection]
brunoerg_ has quit [Read error: Connection reset by peer]
cmirror has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] Ataraxia009 closed pull request #33813: init: Changing the rpcbind argument being ignored to a pop up warning (master...rpc-bind-warning) https://github.com/bitcoin/bitcoin/pull/33813
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
Guest35 has joined #bitcoin-core-dev
Guest35 has quit [Write error: Broken pipe]
brunoerg has quit [Read error: Connection reset by peer]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
szarka has quit [Quit: Leaving]
robobub has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 240 seconds]
kevkevin has joined #bitcoin-core-dev
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
Palaver has joined #bitcoin-core-dev
Palaver has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 244 seconds]
javi404 has quit [Ping timeout: 260 seconds]
javi404 has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
brunoerg_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
kevkevin has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg_ has quit [Ping timeout: 260 seconds]
brunoerg_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg_ has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 245 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg_ has quit [Ping timeout: 246 seconds]
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
<dergoegge>
fanquake: I wouldn't expect any issues but let's see...
BGL has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
l0rinc has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
<hebasto>
laanwj: are you building on your risc-v cloud instance as root, or as a non-privileged user?
kevkevin has quit [Ping timeout: 246 seconds]
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
l0rinc has quit [Quit: l0rinc]
brunoerg has quit [Ping timeout: 240 seconds]
<laanwj>
hebasto: as a non-privileged user, i created a user gitian-build for it
<laanwj>
sorry, brainfart, guix-build ofc
<hebasto>
laanwj: so did I; have you experienced system hanging during the build process?
l0rinc has joined #bitcoin-core-dev
<laanwj>
hebasto no hangs, no, but i did have memory corruption(?) at some point (#33873). system hangs could have been a possible outcome too. sadly their RISC-V cluster isn't too stable and reporting it didn't do anything, they just quoted their terms of service for labs that i couldn't sue them :)
<laanwj>
hmm yes, thanks for linking that, i didn't know. that definitely complicates things
Earnestly has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 265 seconds]
<laanwj>
as i understand, rv64imafdcsu, as on their server, isn't even RVA20, let alone RVA23 (missing the fancy Zi* extensions)? what kind of devices is ubuntu aiming for, really, they seem to be getting far ahead of themselves
kevkevin has quit [Ping timeout: 245 seconds]
<Sjors[m]1>
Pre-meeting Stratum v2 workgroup update: would be nice to get #33965 reviewed and backported to v30.x.
<Sjors[m]1>
I tested custom block templates with DMND pool and found some bugs, but they don't seem to be on our end.
<fjahr>
Final reminder that the asmap file building will happen in 2 hours, just start it any time until then, there will be a countdown and it will do its thing while you are in the meeting: https://github.com/asmap/asmap-data/issues/36
<bitcoin-git>
[bitcoin] l0rinc opened pull request #34005: util: generalize `util::Result` to support custom errors (master...l0rinc/generalized-Result-error) https://github.com/bitcoin/bitcoin/pull/34005
brunoerg has quit [Remote host closed the connection]
<dergoegge>
"Coordinated launch mode: Waiting until 1764864000" 🫡
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
_flood has quit [Read error: Connection reset by peer]
<stickies-v>
There is one pre-proposed meeting topics this week. Any last minute ones to add?
<jonatack>
hi
<fjahr>
hi
<dergoegge>
hi
<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
<darosior>
hi
<stickies-v>
no fuzzing updates today, so skipping that
<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).
andrewtoth has joined #bitcoin-core-dev
<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).
<andrewtoth>
hi
<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.
<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
<l0rinc>
because of the Pool Allocator introduced in #25325 and if it's still optimal to have it after the input fetching optimizations above.
<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
<stickies-v>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<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.
sipa has quit [Read error: Connection reset by peer]
sipa has joined #bitcoin-core-dev
<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
jerryf has quit [Remote host closed the connection]
jerryf has joined #bitcoin-core-dev
<sipa>
hi
<cfields>
+1
<stickies-v>
#topic Net Split WG Update (cfields)
andrewtoth has joined #bitcoin-core-dev
<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.
<_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)
<b10c>
hi
<cfields>
🚀
<stickies-v>
#topic A short update on BIP 54 / Consensus Cleanup work (darosior)
<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
<darosior>
there is now an implementation for review at Bitcoin Inquisition.
<darosior>
The test vectors were also recently merged in the BIP repository
<Murch[m]>
Great, what do you see as the next steps?
<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
<dergoegge>
Why in inquisition and not in the main repo?
<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
<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
<dergoegge>
So if the spec changes due to review on the main repo, we'll have to redo all of that?
<darosior>
But that's the first stage of an implementation, so feel free to nitpick/bikeshed it to death!
<Murch[m]>
I am just looking at the Inquisition PR. Somehow I expected it to be less than ~27k lines of code. ;)
<Murch[m]>
How much of that is tests?
<darosior>
dergoegge: i very much don't expect the spec to change at this point
<fanquake>
_aj_: can you approve the CI to run in that PR?
<darosior>
dergoegge: The spec has been researched / designed / debated to death for more than 2 years now
<instagibbs>
Murch[m] its also including Simplicity (joke joke)
<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?
<_aj_>
fanquake: done
<darosior>
Of course it can always happen but i don't think it's likely
<darosior>
Murch[m]: 99.9%
<dergoegge>
the code might change in significant ways as well
<darosior>
The consensus changes are something like 10 lines
<Murch[m]>
Yeah, that’s what I was expecting :)
<sedited>
darosior, is the preparatory PR relevant for the upstream repo too?
<dergoegge>
I just don't see why or how this became part of the process
<darosior>
dergoegge: between inquisition and main Core repo? I don't think so
<darosior>
sedited: i don't expect the relevant code to change much between Inquisition and upstream, so yes it is relevant
<dergoegge>
I think the review should happen on the main repo, you can still deploy the PR where ever you want
<fanquake>
How many major versions is inquisition lagging behind master at the moment?
<darosior>
dergoegge: why?
<sedited>
would it make sense to PR that then in the meantime?
<darosior>
fanquake: a single one, it's on 29
<fanquake>
darosior: right, so 1 version + any current changes (like cluster etc)
<darosior>
I don't think there is any need to rush anything with a PR to the main repo
<dergoegge>
I'm not saying merge the PR just review
<darosior>
fanquake: yes, but that shouldn't be relevant
* darosior
shrugs
<darosior>
I can also PR to the main repo, if people really feel so strongly about not coming review stuff in Inquisition
<dergoegge>
wouldn't you want the visibility of the main repo for review?
<dergoegge>
I'm not gonna review the inquisition PR
<darosior>
Ok, does anyone else feel like dergoegge?
<darosior>
Glad i brought it up, i didn't expect this
<_aj_>
is there any particular problem with reviewing code in different repos? we already have gui, eg
<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?
<dergoegge>
it's been open for more than a month there and there's been basically no review
<darosior>
And cmake, which was the main annoyance before the 29 rebase of inquisition
<darosior>
stickies-v: that's what i'm looking for yes
<dergoegge>
I don't think consensus changes should be reviewed elsewhere. What would be the reason for that?
<_aj_>
dergoegge: are you assuming it won't get further review when PRed for core?
<darosior>
Are we going to go into a discussion about the raison d'etre of Inquisition?
<dergoegge>
i don speak french
<sedited>
:D
<fjahr>
dergoegge: for many changes the rebasing is annoying here, nobody is stopping anyone from reviewing on inquisition
<stickies-v>
is anyone arguing for less review on the main repo? i don't think so?
<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
<dergoegge>
fjahr: I'm guessing people just aren't aware
<jonatack>
ca se cumule de toute facon :)
<stickies-v>
okay let's keep it english on here please
<sipa>
ah bon baguette
<darosior>
Alright, i think i got across what i wanted to
<darosior>
Just a heads up to people that there is code for review at Inquisition, if you are interested in having a look
<stickies-v>
thanks darosior!
<darosior>
I may open a PR to the Bitcoin Core main repo later on
<darosior>
Meanwhile, that's where the action is
<darosior>
jonatack: yes that's what i'm looking for :)
<stickies-v>
#topic why is #33723 not merged yet (dergoegge)
<stickies-v>
it does look like there is pretty overwhelming support for the change, and sufficient time for feedback/recourse?
<sipa>
indeed
<sedited>
have changes to the seed list been backported historically?
<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
<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)
<fanquake>
sedited: I think if the rationale for removing it holds, it holds the same for all maintained branchs
<instagibbs>
Luke hasn't seemed to weigh in, could ping him now that it's unlocked again, and give a timeline?
<stickies-v>
sedited: it looks like #29691 was backported
<dergoegge>
it's also not about the seed not working properly, it's about trust.
<fjahr>
ah, thanks
<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
<Murch[m]>
Right, I don’t think it matters at this point which version of nodes he surfaces
<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
<instagibbs>
to ask a shorter question: why should he care if "malware" is using his seeder
<Murch[m]>
Well, he said he doesn’t, but that it might help Bitcoin Core to have another dnsseed
<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
<stickies-v>
(or if anything is missing, that should be added on the PR instead of here)
<instagibbs>
Ok I retract :)
<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
<stickies-v>
agreed, i'll give it another minute for a response otherwise i'll move on
<Murch[m]>
I guess then this is just a “33734 looks RFM”
<stickies-v>
hah, well that's your answer dergoegge
<dergoegge>
🥰
<darosior>
lol
<pinheadmz>
productive meeting !
<kevkevin>
:0
<eugenesiegel>
nice
<cfields>
darosior: apparently you just asked the wrong question about the gcc :p
<stickies-v>
#topic IRC chair having triage permissions (darosior / stickies-v)
<darosior>
haha :)
<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.
<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
<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.
<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
<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
<darosior>
hosting providers.
<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?
<darosior>
Woops
<pinheadmz>
oof
<stickies-v>
darosior mentioned earlier that IRC chair could/should have triage permissions on the repo, so just wanna quickly address that here
<darosior>
I saw the ping and assumed it was about the AddrMan peer selection
<fjahr>
trigger happy
<instagibbs>
prematurely blue yourself
<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?
<darosior>
Sorry about that :/
<sipa>
i see issue with giving either of them triage permissions
<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
<sipa>
sorry, i see *NO* issue
<fanquake>
Yea. I think if the idea is to rotate meeting chair, then no need to tie permissions to it
<darosior>
Yes i must say my comment was specifically for stickies-v
<darosior>
But if you don't need it, then you shouldn't have it, for sure
<sipa>
yeah
<darosior>
Can revisit if you bump into it again in the future?
<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
<stickies-v>
sounds good
<stickies-v>
Anything else to discuss?
<darosior>
Yes i had a topic
<darosior>
About outbound peers selection
l0rinc has quit [Quit: l0rinc]
<darosior>
I proposed it shortly before the meeting, unsure if it got registered
<stickies-v>
#topic an outbound connection selection strategy more resistant to eclipse attacks (darosior)
<darosior>
Ok now i'm shooting it
<stickies-v>
(sorry it doesn't show up in the topics list but i see it in the logs here)
<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.
<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
<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.
<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
<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
<darosior>
hosting providers.
<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?
<Murch[m]>
The proposedmeetingtopic thing seems to not work, it also said “unknown command” during the meeting
<_aj_>
it's a separate script that updates a github page, probably on a timer; the # just confuses meetbot
<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
<darosior>
connections of a node, let alone of a large fraction of nodes on the network.
<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
<corebot>
darosior: Error: That URL raised <Connection timed out.>
<sipa>
i'd like to think/simulate more about this
<darosior>
sipa: of getting connected to sure, but not of being *exclusively* connected to
<Murch[m]>
sipa: Good point. Maybe pick some with that strategy and others by randomly sampling from all?
<instagibbs>
what's the best place to discuss this topic with paper trail for permanence
<darosior>
I don't think we should worry about making one or two connections to an attacker
<lightlike>
open an issue maybe?
<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?
<sipa>
fjahr: buckets are not netgroups
<sipa>
(there is a correlation, but it's much more subtle than that)
<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
<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
<_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
purpleKarrot has joined #bitcoin-core-dev
<sipa>
_aj_: ?
<fjahr>
I should spend more time with the code and simulation is definitely needed
<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
<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
<_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
<_aj_>
sorry, s/3k/5k/
<jonatack>
darosior: is this the guy who was proposing to change the default outbound connection count to 48-64 peers as a solution?
<sipa>
_aj_: i'm missing some context, are you talking about what an attacker should do? with or without this proposed change?
<Murch[m]>
I think AJ is giving probability of having at least one connection to some peer running a lot of nodes
<_aj_>
sipa: yeah, vs "an attacker can increase their probability of being connected to by finding an obscure AS"
<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
<_aj_>
Murch[m]: probability of the first connection being to a given attacker, i guess
<Murch[m]>
darosior: So, is your concern that we’d make all our outbound connections to someone sybilling like that?
<_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
<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?
<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
<darosior>
Murch[m]: yes
<eugenesiegel>
I think this guy could cause some damage if he withheld blocks, even if only for 10 minutes...
<darosior>
Definitely
<darosior>
stickies-v: i can open an issue
<stickies-v>
superb, thank you darosior
<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.
<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)
<darosior>
lightlike: yes exactly
<darosior>
It would still have network wide effect though, and it's now clear how to anticipate that
<_aj_>
s/now/not/ ?
<instagibbs>
s/now/not/
<sipa>
s/?/!/
<stickies-v>
thanks for the lively meeting everyone, it's been a pleasure
<stickies-v>
#endmeeting
<corebot>
stickies-v: Meeting ended at 2025-12-04T17:00+0000
<Murch[m]>
If we have multiple connections to someone in the same /16, wouldn’t we cycle them out as our feeler connection finds other potential peers?
<instagibbs>
Murch[m] would love to discuss on hte issue, I need to learn more on it
<sipa>
Murch[m]: we never make multiple connections to the same netgroup
<Murch[m]>
Then I guess I don’t understand how we’d have three connections to the don’t-spam-me-bro sybil. Are they across multiple netgroups?
<_aj_>
*are there any bip324 people
<_aj_>
Murch[m]: exactly
<sipa>
darosior's observation is that netgroups with many peers still get more connections to them (in aggregate) than netgroups with few peers, because addrman selection picks uniformly random peers, not random netgroups - and then filter by not-have-connection-to-group-already
<Murch[m]>
I see
<sipa>
Murch[m]: yes, they have a number of netgroups
<instagibbs>
Murch[m] they have access to making many "nodes" on at least 4 AS's too
<Murch[m]>
I see, I missed that earlier
phantomcircuit_ is now known as phantomcircuit
<_aj_>
darosior: i would have thought any global effect the change has in rearranging how the p2p graph is interconnected would be beneficial rather than detrimental, fwiw
<Murch[m]>
So basically right now, we sample randomly and only connect if it’s a new netgroup, but obviously having a lot of nodes in some groups makes them more likely to be picked. If we randomly sampled netgroups and then picked one node in them, we’d instead be much more likely to pick obscure groups, but those nodes would be much more likely to have no inbound slots left, and we’d get more cycling?
<sipa>
Murch[m]: seems like a good summary
<Murch[m]>
Might be interesting to flip a coin and use one or the other strategy for each connection attempt.
memset has quit [Remote host closed the connection]
kevkevin has quit [Read error: No route to host]
memset has joined #bitcoin-core-dev
<abubakarsadiq>
re: stratumV2 I was with the stratumV2 irl today discussing the current mining interface issue of memory management of blocktemplates and crash during IBD, the crash has an issue opened which has a couple of discussion already. I prefer a LIFO approach from the node side other contributors prefer that we provide a mechanism for the client to be able to know memory usage or notify the tha client when the memory
<abubakarsadiq>
limit is reached and they evict a candidate, The SRI guys said there eviction strategy is LIFO, so it makes sense to just evict LIFO on the node side. I think I provide more info here https://github.com/bitcoin/bitcoin/pull/33922 could appreciate more eyes
kevkevin has joined #bitcoin-core-dev
kevkevin_ has joined #bitcoin-core-dev
kevkevin has quit [Read error: Connection reset by peer]
memset has quit [Remote host closed the connection]
kevkevin_ has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
<ryanofsky>
abubakarsadiq, my understanding is that the node will be able to delete templates using the memory tracking added in #33922. 33922 doesn't change memory managerment it just adds tracking
<abubakarsadiq>
yes. I asked them how the are going evict when the limit reached they mentioned LIFO as well so why not do it ourself? My concern is when the client don't do it correctly and we run out of memory?
Guest89 has quit [Ping timeout: 250 seconds]
<ryanofsky>
seems reasonable for the node to do it, especially if that's what clients want. i was just unsure if they wanted templates to disappear without being notified, or if they wanted notifications or what
nejos97 has joined #bitcoin-core-dev
<abubakarsadiq>
I agree but there is no realistic scenario where they will want to even be notified before the we evict I think, the miners have long switched to the latest before the limit reached.
<ryanofsky>
All right, that wasn't obvious to me. But sounds good
<ryanofsky>
I'm reviewing #33922 currently FWIW. I see it as a building block for any memory management scheme, but you can let me know if that's not right