<glozow>
sipa instagibbs: hm yeah, there are various places with looping... e.g. what happens if you have 100 inbounds and they each announce 10k of the same small transactions to you. it's going to take a long time to finally evict an orphan because you're removing them as announcers one by one
<glozow>
I'm now quite interested in the idea of having separate orphanages for inbounds and outbounds
PaperSword1 has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 245 seconds]
PaperSword1 is now known as PaperSword
PaperSword1 has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 248 seconds]
PaperSword1 is now known as PaperSword
greypw149508 has quit [Remote host closed the connection]
greypw149508 has joined #bitcoin-core-dev
<sipa>
glozow: is this with a global (weight) limit, or a per-peer weight limit (ignoring count limit for this)
bitdex has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
PaperSword1 has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 248 seconds]
PaperSword1 is now known as PaperSword
Guest27 has joined #bitcoin-core-dev
Guest27 has quit [Client Quit]
jonatack has quit [Ping timeout: 248 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
PaperSword1 has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 244 seconds]
PaperSword1 is now known as PaperSword
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
<glozow>
sipa: this is with a per-peer weight limit
<glozow>
er wait, "this" = how we get the problem with looping a lot before we evict something?
zeropoint has quit [Quit: leaving]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
agentcasey has quit [Read error: Connection reset by peer]
agentcasey has joined #bitcoin-core-dev
mcey_ has quit [Remote host closed the connection]
mcey_ has joined #bitcoin-core-dev
MyNetAz has joined #bitcoin-core-dev
<_aj_>
glozow: if each of 100 inbounds announce the same 10k txs -- you add each tx to the orphan request tracker, prioritized randomly, hit the per-peer-limit as you're going, remove that peer's lowest priority tx, repeat? those should all be O(log(peers*peer_orphan_count_limit)) ? the peer_orphan_count_limit should presumably be lower than MAX_PEER_TX_ANNOUNCEMENTS=5000 since you need to keep the orphan
<_aj_>
tx around, not just a txid
<glozow>
_aj_: are you thinking of the orphan request tracker TxRequestTracker?
<_aj_>
glozow: yeah?
<glozow>
(In this situation we're remembering which invs correspond to which orphan txns so we can drop them right?)
<glozow>
ok so, we ended up dropping that, and just add the parent txids to normal `m_txrequest`
<_aj_>
glozow: the parent txid or a pointer to an orphan tracker?
<glozow>
the parent txid
<_aj_>
glozow: (32B for every non-orphan requested seems slightly lame)
<glozow>
what do you mean?
<_aj_>
if you have tx O as an orphan, with missing parents P1 and P2, you tock P1{O} and P2{O} into m_txrequest or you stick O into m_txrequest?
<_aj_>
tock? stick
<glozow>
we put P1 and P2 in m_txrequest
<glozow>
and don't remember that they are related to O
<_aj_>
hmm, why did the orphan tx tracker get dropped? seems much more efficient to have it, than not?
<_aj_>
(dropped from the design, i mean, not much value implementing it with the orphanage as it is currently)
<glozow>
yeah, it didn't add much value with the current orphan reso method
<glozow>
It's more helpful in the package relay world
<_aj_>
maybe make it PackageRequestTracker (where an orphaned child implies the pacakge of the child and its missing parents) and use it for making orphan handling efficient, and generalise it more as package relay progresses further? not having that and ending up with O(n^2) stuff doesn't seem surprising; that was what ~exactly the tracker was there to fix
<bitcoin-git>
[bitcoin] hebasto opened pull request #31765: cmake: Install man pages for built targets only (master...250130-man-inst) https://github.com/bitcoin/bitcoin/pull/31765
johnny9dev584508 has quit [Ping timeout: 245 seconds]
johnny9dev584508 has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
johnny9dev584508 has quit [Client Quit]
johnny9dev584508 has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
jespada has quit [Client Quit]
robszarka has joined #bitcoin-core-dev
rszarka has quit [Ping timeout: 276 seconds]
eval-exec has quit [Ping timeout: 248 seconds]
midnight has quit [Remote host closed the connection]
midnight has joined #bitcoin-core-dev
conman has quit [Read error: Connection reset by peer]
cman has joined #bitcoin-core-dev
rszarka has joined #bitcoin-core-dev
robszarka has quit [Ping timeout: 260 seconds]
<achow101>
jonatack: wanted to check that you no longer want to talk about the "release management rotation" you proposed at the end of last week's meeting
Emc99 has joined #bitcoin-core-dev
<glozow>
hi
<tdb3>
hi
<achow101>
#startmeeting
<corebot>
achow101: Meeting started at 2025-01-30T16:00+0000
<achow101>
There are 2 preproposed topics this week. Any last minute ones to add?
<brunoerg>
hi
<kevkevin>
#here
<sipa>
hi
<pinheadmz>
yo
<darosior>
#here \" DROP TABLE actions
<Sjors[m]>
hi
<cfields>
hi
<hodlinator>
hi
<achow101>
darosior: rude
<lightlike>
hi
<achow101>
#topic Erlay WG Update (sr_gi, gleb, marcofleon)
<fjahr>
hi
abubakarsadiq has quit []
abubakarsadiq has joined #bitcoin-core-dev
<sr_gi[m]>
Following from last week’s meeting, I mentioned that after running a wide range experiment with different combinations of parameters for how to select fanout peers, a less static approach was proposed by @murch: instead of having a fixed fanout rate (selecting some inbounds and outbounds), we could have a variable rate based on how the peer has received the transaction
<abubakarsadiq>
hi
<furszy>
hi
<sr_gi[m]>
This tries to guess how propagated the transaction is to use more fanout or more reconciliation to keep propagating it
<sr_gi[m]>
It is something we previously tried by checking how many peers may have announced a transaction by the time we needed to pick to how many peers to fanout to, but that approach, while promising, didn't seem to work too well
<sr_gi[m]>
Long story short, @murch suggestion yield really interesting results
<sr_gi[m]>
Reducing the transaction propagation latency by a significant bit while not affecting the bandwidth too much
<sr_gi[m]>
Next is to decide if modifying the poisson timers for erlay, in order to achieve better latency, is acceptable, and to what extend, or if we could find an alternative solution that may be less intrusive
<Sjors[m]>
I'm personally not assuming we'll meet the v29 release, but it would be good to continue the discussion there so we're on the same page for e.g. v30
<Sjors[m]>
Next on peoples review list, suggested: #31283
<achow101>
#topic orphan resolution WG Update (glozow)
<glozow>
I'm working on my per-peer orphanage branch, which is maybe 80% of the way there.
<glozow>
(80%TM)
<sipa>
the second 80% might take less than the first 80%
<glozow>
I'm trying to get #31666 merged soon as it's based on that. A little bit of active discussion left on the the AddChildrenToWorkset assignment, happy to punt that or defend it
<glozow>
sipa: haha. I'm going a little bit back and forth on the count limits thing, might just end up incorporating the struct memory usage after benching it
<glozow>
anyway I hope to have my PR up soon
<sipa>
glozow: happy to discuss more
<glozow>
I might actually trim things like "give outbounds more space than inbounds" to make it smaller / more realistic for v29
<glozow>
sipa: thanks
<sipa>
as in 400 kWU for everyone?
<glozow>
yes
<sipa>
do we have a way of gathering data whether or not that would affect any actual tx relay right now?
<instagibbs>
I asked timo but he's busy this week, so if anyone has high quality node data
<glozow>
hmmm, is the best way to analyze that to measure how many bytes peers use right now?
<instagibbs>
(read: not randomly shutting machines off like mine)
<sipa>
glozow: i think so
<glozow>
my byte accounting code seems correct(TM), we could start running that now
<glozow>
well this can also be inferred from the `getorphantxs` RPC results
<instagibbs>
beneficial to make sure logging is decent for 29.0. whatever happens?
<instagibbs>
I expect it to be very bursty
<glozow>
yeah i expect it to be very high at first, and then taper off
<glozow>
idea: orphanage can borrow some space from mempool when it's not full?
<glozow>
(maybe we should continue this later? meeting can go on?)
<instagibbs>
✅
<sipa>
let's discuss after
<achow101>
#topic mutation testing (brunoerg)
<brunoerg>
Hi, just a quick announcement that I’m performing mutation testing and publishing the reports at bitcoincore.space. I do it based on master branch once a week (every Monday, I guess) and then I update the website with the results
<brunoerg>
I started to do it on more important/critical part of the codebase (pow, tx_check, script interpreter, etc) but I intend to expand it soon. Any suggestions for function/code file to include next on it, let me know.
<brunoerg>
that's it
<sipa>
you run that website?
<brunoerg>
yes
<achow101>
how are you generating mutations? by hand?
<achow101>
#topic What should be the mid to long term goals of the project? (darosior)
<achow101>
this sounds like a question for coredev
<darosior>
Hi, see https://antoinep.com/posts/core_project_direction for the longer version but here is the TL;DR. With limited resources there is an upper bound on the amount of stuff the project can maintain. We can pay in either a limited project scope or a reduced overall software quality but we can't have it for free.
<darosior>
Resources are also spread inequally. It's very hard to onboard and make meaningful impact in important areas. With key people leaving or reducing their involvement we've at best had constant resources despite an increasing number of contributors. Despite this, the scope of the project has been constantly increasing.
<darosior>
Bitcoin Core cannot be the "everything Bitcoin app" without also diluting priorities. Not doing anything about it is making this choice by default. Finally, defining a scope is not only about pruning stuff. It can also help us shift focus toward things we would see as in-scope but not making enough progress.
<darosior>
For the purpose of this meeting i'm interested in:
<darosior>
1. do people make the same observation / agree with the problem statement in the first place?
<darosior>
2. do people agree that defining a scope / long term vision for the project is an appropriate solution?
<darosior>
3. hearing about others' thoughts about this issue.
<darosior>
Note i obviously do not expect to find a solution in a single IRC meeting. But i think it's good to kick off the discussion here, and continue it at Coredev.
<darosior>
achow101: yes but i figured it could be helpful to start the discussion here
zeropoint has quit [Quit: leaving]
<Sjors[m]>
In what areas has the scope been increasing in e.g. the last 5 years though?
<glozow>
I agree it's hard to do the topic justice in this meeting. appreciate that you're posting this here ahead of coredev
<Sjors[m]>
There's been 0 new GUI features, IIRC only a handful of new RPC calls.
<sipa>
i have many thoughts about this, but i'll try to organize them before coredev
<Sjors[m]>
There's certainly a desire to increase scope in various places, but this often goes nowhere because - as you point out - we're already quite stretched.
zeropoint has joined #bitcoin-core-dev
<achow101>
have a few thoughts on this as well, will also try to organize them before coredev
<glozow>
I disagree the scope hasn't increased - "a handful of RPCs" in the last 5 years is around 50. the security requirements certainly have increased
<darosior>
Sjors[m]: i don't want to make this a discussion about "should we drop the GUI", although removing it from the main project could definitely be part of defining a scope.
<abubakarsadiq>
@sjors[m] this might be an indicator that the gui is not getting much improvements
<TheCharlatan>
darosior beyond the three questions you are asking is there further homework we could be doing to be better prepared when discussing in person?
<darosior>
Sjors[m]: it's pretty obvious the project has been getting bigger in any metric one can think of, and you static you are not seeing that is an illustration of the issue we are facing here.
<darosior>
s/static/stating
<sipa>
I think RPCs are a bad metric for measuring scope creep, dilution, or lakc of focus (all of which are real problems we suffer from). The actual maintenance cost for most RPCs, on a per-RPC basis, is small; the cost is in the code subsystem behind it.
<glozow>
Right, should we be preparing our thoughts on what we think the goals should be + to what extent we think we should/can be planning?
<darosior>
TheCharlatan: thanks for asking, yes i think it would be nice if we all thought about "What should be the scope of the project", "What should be Bitcoin Core's mission", so we can get inputs from as many people as possible for this discussion
<glozow>
er yes, agree number of RPCs is not that meaningful, I just had a nitpick moment
<jonatack>
i've had concerns for some time now about the collectivist "we" approach, particularly in a project where decentralization is the fundamental value
<fanquake>
Sjors: I have a hard time agreeing with no scope increase. If we haven't increased our scope at all, what are the hundreds of thousands of new lines of code for
<Sjors[m]>
I'm using a fairly narrow defination of scope, things like features and functionality.
<achow101>
perhaps the first exercise is to define "scope"
<Sjors[m]>
But if you mean "scope" as in things people work on, then there's more, that would include refactors.
<darosior>
jonatack: yeah i agree with that, but also individual actions have negative externalities on the project at large and we need collective actions to work against them.
<sipa>
I also disagree that an expanding scope is *necessarily* a problem. I believe it's a natural consequence of shifting interesting in a software being developed, even if no prioritization/focus issues existed.
<lightlike>
what would help is concrete example of stuff that has been merged in the past but wouldn't / shouldn't have been merged with a "scope".
<sipa>
lightlike: yes, making this concrete helps for the purpose of discussion.
<fanquake>
lightlike: I think it's less things wouldn't have been merged, and more we need to face the reality that we can't keep adding new stuff with continued brain drain/flat-if-not-declining engineering capacity
<darosior>
jonatack: there is a balance to strike between "everyone work on their stuff and the project decays" and "some people decide what everybody else should be spending their time on"
<sipa>
darosior: agreed
<darosior>
achow101: yes i agree, when thinking about this i found that defining scope would be the first step to then layout a set of priorities and then take action upon those priorities
<fanquake>
we are already shipping things that you could consider unmaintained. i.e a GUI that doesn't work out of the box on one of the platforms we support (macOS)
<sipa>
fanquake: yes, but i think the correct thing to look at is concrete examples that cause us maintenance cost. I believe there can exist maintained, fully functional, but not being-developed, features in the codebase, which do not cause the project a high cost.
<sipa>
While there are other examples of things that exist in a half-finished state, which interact with lots of other things, and possible detract review power from other, more impactful things.
<sipa>
So I think it's important to keep this concrete, and not just look at the codebase and "look, more RPCs, more lines of code, bad!".
<darosior>
lightlike: yes i can try to compile a list of things that should have seen more focus and others that should have seen less before Coredev, but this is necessarily going to be stepping on eggs
<fanquake>
sipa: possibly, but that doesn't solve the issue that the poeple that wrote that code are dissapearing, and the new people don't understand/can't maintain it if needed
<sipa>
fanquake: that's fair, but i don't think this applies to the vast majority of the codebase
<fanquake>
sure, but it applies to the most important parts
<glozow>
I think we could focus more on how we spend resources + existing efforts to increase resources. That could potentially be a more productive conversation, though there are no easy solutions
<sipa>
so, i'd like to encourage people to come up with specific examples
<ajonas>
Coredev or here, I think the format to have this discussion is a challenge. Venting is healthy but there have been attempts to address meta-level project improvements in the past and it's hard to get to meat of it or come to any concrete steps going forward. It'd be great if there were ideas to discuss this in something other than a 1-to-N way where most people stay silent.
<Sjors[m]>
darosior: bring eggs :-) it's good to have examples as a starting point
<sipa>
We should discuss this on a meta-level too of course, but there is only so much talk can accomplish. Actually talking about specific projects can help people focus on them (for review, or for discussion on deprecation/removal/moving out alike!), and ultimately that is the only thing that will change things.
<jonatack>
darosior: when in doubt, I think the balance to strike is in favor of decentralizad, ad hoc, less process
<laanwj>
is the gui broken on macos?
<darosior>
jonatack: this is a bunch of undefined terms that are not helpful to take concrete actions
<fanquake>
laanwj: yes, it is unsable for any non-technical user, due to lack of notarization/codesigning issues
<achow101>
fanquake: there's literally a pr for that
<fanquake>
yes, with literally 0 review
<darosior>
achow101: that has seen no review
<laanwj>
fanquake oh, that, i was afraid it'd be another qt issue but that seems kind of meta
<darosior>
ie, nobody cares enough
<achow101>
fanquake: you're one of 2 people with the macos code signing key, you're the reviewer
<darosior>
haha
<fanquake>
we can't claim that we need to have feature x, but at the same time nobody is reivewing the changes needed to ship feature x
<fanquake>
achow101: I don't see how who has the signing keys is relevant here
<sipa>
fanquake: i think it's important to distinguish between "we should have feature X", and "hey guys we talked about feature X, it seems people want it, can it be reviewed please?".
<darosior>
Alright, i guess i've done my advertisement. Please everyone do a bit of thinking about the issue before Coredev so we all participate in this discussion and finally are able to take actions. We have been talking about this for years now.
<fanquake>
sipa: sure. I guess here I am talking about things we already have, which are just degrading
<sipa>
fanquake: i'd really like you to be specific :)
<fanquake>
sipa: the macOS gui
<Sjors[m]>
I do occasionally review those macOS signing key PRs, but they're often impossible to test without signatures.
<fanquake>
which doesn't work
<Sjors[m]>
IIRC I asked for those a while back, but can check again.
<achow101>
fanquake: a code signature from a code signer makes reviewing code signing changes easier/possible
<sipa>
ok, who here uses macOs?
<fanquake>
achow101: sure, if someone pings me for one in that PR I can provide, as can the other signer
<Sjors[m]>
And I use the macOS GUI all the time
<laanwj>
the only mac is have is old and support for its version of macos was dropped so i can't help in that regard, at least not with testing
<sipa>
achow101: what's the PR?
<achow101>
#31407
<jonatack>
I have a recent mac
<corebot>
https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
<darosior>
Let's not derail the discussion into specifics
greypw149508 has quit [Remote host closed the connection]
<Sjors[m]>
And I know people run into lack of codesigning for the daemon too, see #29749.
greypw149508 has joined #bitcoin-core-dev
<laanwj>
it's just that discussion about reducing scope always goes into "drop the gui" and "drop the wallet" which happen to be the parts i find very importnat
<achow101>
laanwj: indeed
<Sjors[m]>
Indeed, and the wallet is also a useful reference for other projects. See e.g. recent revival of PSBTv2 review.
<jonatack>
Regarding the specific case of the GUI, getting funding for working on it has been a non-starter for years, perhaps somewha partially related to moving out of the bitcoin core repo
<jonatack>
laanwj: achow101: agree
<glozow>
Ok so I think the meat here is "we seem to have lots of people, but people are not spending their energy on the right things. There are parts of the codebase that deserve significantly more/less attention than they're getting now. That can be dangerous for particularly important areas." I think we should come prepared to talk about what those specific areas are *with a specific focus on areas that require more attention, not less*. And think
<glozow>
about why we personally don't work on certain things. Perhaps people naturally haven't learned much about an area. Obviously we have limited time. Maybe people are not incentivized/encouraged to do so (I don't just mean economically but that is part of it).
<darosior>
jonatack: to be more concrete as to your concern which i would interpret as keeping enough "emergent process" in the project, i think this is desirable and not contradictory with defining a scope. Also, we can only take collective action about the scope of the project if there is rough consensus about said scope. If there is not, i don't think it
<darosior>
will be possible to take action. I also think it would be a pretty bad outcome for the project.
<laanwj>
re the gui, one reason for me losing the joy of working on it were these kind of discussions, it's always on the chopping block
<laanwj>
has been since 2012 or so
<Sjors[m]>
laanwj: it also just really hard to work with qt5. I'm hoping either QML + QT6 or multiprocess and external GUI will get things moving again eventually.
PaperSword1 has joined #bitcoin-core-dev
<hebasto>
further gui development requires expanding dependencies. it’s another concern
<laanwj>
in any case, i agree with keeping limit on scope creep in general, that's also what i've always tried, not every random RPC or GUI feature anyone asks for needs to be added, but i don't think that's the case either
PaperSword has quit [Ping timeout: 252 seconds]
PaperSword1 is now known as PaperSword
<sipa>
laanwj: agreed, it's not like we willy nilly take on extra features; "seems too tangential, can be done elsewhere" has long been a reason not to take things
<darosior>
Alright, thanks everyone for chiming in. I'll try and compile more thoughts and data/examples about this issue.
<laanwj>
hebasto: yeah, i tried limiting the build-time dependencies with my qtsowrap work last year, but there was almost no attention for it
<sipa>
laanwj: :(
<sipa>
i really liked that idea, but i also don't use the GUI
<lightlike>
glozow: there is no real guidance for newer contributors as to which areas of the codebase would need more attention. maybe a good thing would be if some experienced contributors would just publish a list of areas that they think could need more attention.
<jonatack>
laanwj: I empathize
<laanwj>
well it has to be updated for qt6 anyhow, that should go first
<sipa>
laanwj: another idea i've seen more recently is the possibility with multiprocess of having a few-dependency (maybe statically built) core, and having a gui binary connect to it with more dependencies
<laanwj>
but if we yet again go "oh maybe we should drop the gui" i find it hard to invest time in it
<laanwj>
sipa: that would make sense
<jonatack>
lightlike: yes. in general, I like the idea of contributors expressing these things in personal blog posts (rather than, say, in core dev documentation or processes)
<sipa>
so that everyone still uses the same release core binary, focusing testing/review, but if you want to use the gui, you take on the (inevitable) cost of having more dependencies too
szkl has quit [Quit: Connection closed for inactivity]
<fanquake>
statically built core is certainly already possible, it's just somewhat of a mess to integrate without somewhat overhauling how we build releases, as we'll likely need to split into separete non-gui and gui builds
<achow101>
I believe we're getting a bit off topic and into the weeds, so I'll end the meeting here. Feel free to continue discussing.
<achow101>
#endmeeting
<corebot>
achow101: Meeting ended at 2025-01-30T17:01+0000
<fanquake>
(to get have less complication / get the benefits of not having to boostrap all the qt deps in the build where they aren't needed)
<achow101>
fanquake: #31407 changes the workflow for macos code signers. I think it's completely reasonable, and in fact required, for at least one of, if not both of, the macos code signers to review and test it
<corebot>
https://github.com/bitcoin/bitcoin/issues/31407 | guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries by achow101 · Pull Request #31407 · bitcoin/bitcoin · GitHub
<achow101>
not to mention that it also requires additional credentials to be gotten from apple, which afaik, you're the only one who can do that.
<fanquake>
sipa: it's not even the cost of more deps, it's stuff like, us upgrading our fuzzing/test infra a new LLVM is blocked because some qt (or dep) doesn't compile
<darosior>
Yes there is risks to users, but the costs are mostly for maintenance and future work
<sipa>
fanquake: by "cost of deps" i mostly meant as a user, you get the cost of increased security surface
<fanquake>
the cost of features just get externalized to people working on other parts of the code
<glozow>
lightlike: I agree! And I was intimidated by certain projects/areas after learning about them, maybe others have a similar experience but idk. Perhaps we can do more to help people move out of their comfort zones
<sipa>
fanquake: of course for maintenance dependencies have a cost too, but that's inherent to having a GUI in the first place
<bitcoin-git>
[bitcoin] danielabrozzoni opened pull request #31767: rpc: Ensure -debug=0/none behaves consistently with -nodebug (master...debug_flag_consistency) https://github.com/bitcoin/bitcoin/pull/31767
<darosior>
Multiprocess will also make it possible to have different software that live in completely separate repositories. This would make it possible for people interested in working on one process to make progress, and possibly even iterate faster, without imposing cost on contributors interested in the node process.
<fanquake>
sipa: sure, but also not GUI specific, which is why we've generally pushed back on deps
<sipa>
fanquake: absolutely
<glozow>
great, so why isn't everybody working on multiprocess?
<darosior>
glozow: yes
<darosior>
Exactly this. Defining long term goals would help.
<sipa>
glozow: probably because... everybody sees it's not moving fast, so it's unclear to individual contributors how much their personal decision to contribute will have impact
<achow101>
Sjors[m]: I don't think so, and setting one up would be non-trivial at this time.
<sipa>
yay for self-fullfilling prophecies
<Sjors[m]>
achow101: ok, I'm trying to see if capnp is there, but I'm not sure what the URI would be. I'll try some guesses.
<fanquake>
glozow: probably the same reason most contributors were not working on the high priority for review items
<glozow>
I think before we tackle "why aren't other people working on the important things" we should fully grok "why haven't I been working on the things I claimed were important to me"
<fanquake>
or other deemed-high-priority-for-the-project project
<sipa>
jonatack: re decentralization, i think it's important to distinguish between coordination and control. I fully believe that nobody gets to decide what anyone works on. If someone has their own pet peeve project that they want to keep working on, and aren't interested in working on anything else, that's their right. But if nobody else is interested in reviewing/helping with it, that person should
<sipa>
also accept it might not go anywhere. Coordination is about...
<sipa>
trying - for people who want - to find common grounds for things that might have sufficient critical mass to make progress, so time can be spent on those.
<darosior>
sipa: It's not because something is being worked on and gets reviewed that it needs to live in Bitcoin Core.
<sipa>
darosior: that is true too, but that's part of the review process
<darosior>
sipa: there is a conflict about "right" here. It's as much the right of other contributors (especially maintainers) to not bear the cost of more stuff being added, as the right of people to work on what they want.
<fanquake>
That is also hard though, because it's unclear for reviewers (especially new ones) how to decide what should/shouldn't live in Core, without any real guidance.
<sipa>
darosior: i think that's a matter of speaking up
<sipa>
(which, we definitely don't do enough)
<fanquake>
(also because it's easier to ignore things than actually NACK)
<sipa>
fanquake: indeed
<darosior>
Not everyone affected by the costs of adding more stuff get to say it in the review process. Plus the cost is dispersed among everyone, current and future contributors, whereas the benefits of "getting my stuff merged in Bitcoin Core" are concentrated.
<sipa>
but a review comment of the form "this unduly increases the maintenance burden for the project" is fully valid
Emc99 has quit [Quit: Client closed]
<darosior>
sipa: yes but it's often too small to warrant blocking something individually, but it adds up
* darosior
lunch
* sipa
lunch
jonatack has quit [Ping timeout: 244 seconds]
jonatack has joined #bitcoin-core-dev
<instagibbs>
99.94% of txns seen in my orphanage are <=4kWU, 99.99% by 16kWU, 100% by 40kWU
<jonatack>
sipa: yes, I think for coordination when in doubt prefer ad hoc, informal, opt-in, organic, bottom up, lighter, less
<instagibbs>
(well, maybe 5 9's, not 100%)
andytoshi has quit [Ping timeout: 244 seconds]
<lightlike>
instagibbs: are you running with #31666, and if so, do you see whether your orphanage is smaller on average compared to before, due to more orphans being resolved quickly?
<instagibbs>
don't have those stats handy, my first pass was to look at the average case tx size, so if we go to per peer limits, in practice the storage capacity will go way up
<lightlike>
i see. i did getorphantxs before updating to #31666 (it was pretty well populated, at least 50 entries) and after (empty / almost empty) but it's just anecdotal (not enough datapoints).
<Murch[m]>
Could someone please ban https://github.com/Aldocapurro from the org? The account has been spamming empty reviews for a few days
<instagibbs>
lightlike yeah I think scraping logs and doing some comparisons there would make sense?
<lightlike>
or just calling getorphantxs and getting the count every 10 minutes, both pre- and after #31666.
Talkless has joined #bitcoin-core-dev
<instagibbs>
you could poll more often and count how many are "stuck" based on their age and reasonable lifespan
<instagibbs>
~2.5% of my node's total orphan bytes came from txns >4kWU, to normalize the statistic a bit
<achow101>
Murch[m]: they've been blocked
<Murch[m]>
achow101: Thanks
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
<glozow>
instagibbs: thanks for checking, now wondering if these pesky inbounds even deserve 400kwu
<instagibbs>
being the same amount is simpler...
<glozow>
true
<glozow>
also, I guess more accurate would be to look at the orphans that actually become useful. theoretically there could be a lot of small ones because somebody is already doing the "lots of tiny orphans" attack
<instagibbs>
yeah my data didnt actually filter for resolved orphans, which would be more interesting
<glozow>
not to knock the very helpful data
<bitcoin-git>
[bitcoin] brunoerg opened pull request #31768: test: check `scanning` field from `getwalletinfo` (master...2025-01-test-wallet-scan) https://github.com/bitcoin/bitcoin/pull/31768
<instagibbs>
though if we're regularly under attack by small orphan tx griefers, we already are hosed :)
PaperSword has quit [Ping timeout: 248 seconds]
PaperSword1 has joined #bitcoin-core-dev
PaperSword1 is now known as PaperSword
MyNetAz has quit [Remote host closed the connection]
MyNetAz has joined #bitcoin-core-dev
Guest26 has joined #bitcoin-core-dev
Guest26 has quit [Client Quit]
kevkevin has joined #bitcoin-core-dev
PaperSword1 has joined #bitcoin-core-dev
PaperSword has quit [Ping timeout: 260 seconds]
PaperSword1 is now known as PaperSword
Talkless has quit [Quit: Konversation terminated!]
dviola has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
jespada has quit [Ping timeout: 246 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
bugs_ has quit [Quit: Leaving]
jonatack has quit [Ping timeout: 272 seconds]
jonatack has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
tstearns has quit [Ping timeout: 276 seconds]
vasild has quit [Remote host closed the connection]