<bitcoin-git>
bitcoin/master e285e69 zaidmstrr: test: Fix list index out of range error in feature_bip68_sequence.py
<bitcoin-git>
bitcoin/master fa18304 merge-script: Merge bitcoin/bitcoin#32765: test: Fix list index out of range error in fe...
<bitcoin-git>
[bitcoin] fanquake merged pull request #32765: test: Fix list index out of range error in feature_bip68_sequence.py (master...test-feature-bip68-fix) https://github.com/bitcoin/bitcoin/pull/32765
<TheCharlatan>
...and some more conceptual feedback on #32427
<corebot`>
https://github.com/bitcoin/bitcoin/issues/32427 | (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store by TheCharlatan · Pull Request #32427 · bitcoin/bitcoin · GitHub
<sr_gi[m]1>
hi
<TheCharlatan>
I'm still not convinced by the counter proposal of writing single block files and getting rid of the block index altogether, but there have also has not been complete suggestions yet. I might try to write something up for that.
<TheCharlatan>
that's all
<achow101>
#topic Erlay WG Update (sr_gi, gleb)
<sr_gi[m]1>
I've been focusing on an issue with measuring the propagation time of the warnet simulations for the last few weeks, but I think I'm hitting a wall. The results I'm getting from simulations are promising regarding bandwidth, but the times seem too good to be true. I think something may be wrong with the way I'm testing for times, or there is a bug in the implementation that makes transactions propagate faster than they should
<sr_gi[m]1>
I think I may need some extra set of eyes here, since I haven't been able to figure it out myself
<sr_gi[m]1>
I'm currently writing this down and making it easily reproducible in case someone wants to give it a go, whether it is checking the code or the sims
<achow101>
is there a branch to look at?
<pinheadmz>
sr_gi[m]1 is your warnet project repo up to date?
<sr_gi[m]1>
achow101: yes, the full implementation branch is up to date as of yesterday. #30277
<sr_gi[m]1>
But I'll get all cleaned up and ready today
OYENRAZOR369 has quit [Quit: Client closed]
<sr_gi[m]1>
That's it from me. Happy to get anyone how's interested up to speed
OYENRAZOR369 has joined #bitcoin-core-dev
<achow101>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<sipa>
priority for review remains #31553, which got some recent review that led to discovering a bug in it (the eviction heuristic just wasn't as good as intended, fixed now, and contributed tests added)
<maflcko>
I brought it up, but the general idea is that having two orgs will have to duplicate everything that is org-specific, not just org-teams
<sipa>
right, of course
<achow101>
same org lets us also share caches
<dergoegge>
I still don't think the potential downsides are worth the minor improvements
<maflcko>
Currently the two worker pools are set up manually to share the cache
<maflcko>
dergoegge: Are there any specific technical downsides that I missed?
<dergoegge>
technical no, but the main motivation afaiu was always non-technical
<sipa>
for me the main motivation is non-technical; i don't know if that's the case for everyone
<darosior>
This is how i understand it as well, and i tend to agree with dergoegge.
<sr_gi[m]1>
That's also how I see it, but I won't be blocking this if there is consensus to move forward with it
<fanquake>
Me too. (happy to take any and all of the other team/org actions, if needed. Should only be a handful extra a year)
<willcl-ark>
Is there a problem with the status quo that is solved by moving?
OYENRAZOR369 has quit [Quit: Client closed]
<sipa>
people thinking that BIPs are bitcoin core thing
<maflcko>
willcl-ark: All the technical stuff that involves doing stuff twice (CI worker pools, CI settings, CI subscriptions, org-teams, ...)
<fanquake>
To be clear, again, that duplicated technical stuff is trivial in number compared to all other actions needed to maintain the repo
<achow101>
maflcko: would have the ci in both orgs also cost us double since that would be 2 subscriptions?
<maflcko>
achow101: Not sure, but I'd assume so
<dergoegge>
what is the cost of the CI now?
<maflcko>
dergoegge: Well, it is self-hosted right now
<maflcko>
But there was discussion to change that (for various reasons)
<dergoegge>
Right ok, I think the cost argument only makes sense if we know what it would actually be
<darosior>
dergoegge: and if it's substantially higher than the cost of engineering hours spent in moving the repo and associated infrastructure
<achow101>
I think the current plan is the new cirrus runners, which is $75/mo per machine (assuming we get the nonprofit discount)
<darosior>
How many machines we need?
<maflcko>
darosior: You could probably do with a single machine (everything will just be slower) for that org. Not sure if devs will be happy with that
<darosior>
At "feature parity" with today, how many machines we need? 2?
<willcl-ark>
Reall cirrus machines are "16 cpu", so you can split even one machine into eg 8 x 2cpu jobs.
<fanquake>
Things being slower in the GUI repo, doesn’t really seem like an issue? Given it’s running at a PR or two a week?
<fanquake>
Probably not even that many actually
<maflcko>
fanquake: Also, qa-assets and secp (aarch64)
<fanquake>
Sure, qa-assets is less than that even, I guess secp256k1 slightly over gui
<dergoegge>
secp Ci looks much less intense, e.g. the last arm64 cirrus jobs were 8 min each
<sipa>
secp CI has a ton of CI jobs, but all fairly short
<maflcko>
yeah, i think two runners (aarch64 + x86_64) would be enough. So that is 2k-4k per year, i'd guess
<achow101>
I think it's probably at least 3 machines, 2 x86, 1 arm. that at least matches the current setup
<sipa>
i can't imagine money being the problem with those numbers
<achow101>
and per org
<darosior>
achow101: ok thanks
<darosior>
sipa: yeah
<maflcko>
sipa: Yeah, it should be 10% of the other CI subscription, so money itself shouldn't be an issue
dzxzg has joined #bitcoin-core-dev
<maflcko>
My thinking is that moving the repo should be mostly hassle free (obviously I can't promise it) and has been discussed for years, so doing it now to save some hassle when setting up the CI or in the future when handling teams seems fine.
<sipa>
it makes sense to me, i remain of the opinion that it's just a confusing historical artifact how the orgs/repos are organized, and it's been discussed long enough to address it
<achow101>
i expect that making sure ci is setup correctly twice will cause more issues than moving the repo
<darosior>
I think moving the repo is a consequential decision which comports risk. Doing so today seems unnecessary and pretty bad timing.
<achow101>
but i'm okay with revisiting this later. we previously discussed revisting during coredev
<sipa>
but if too many people are skeptical, i'm not going to push it
abubakarsadiq has joined #bitcoin-core-dev
<fanquake>
Regardless of any technical reasons, personally, I don’t think anything is gained by us trying to create some perception that doesn’t currently reflect reality. I think this is also undermined by the fact that we are just going to redirect to ourselves anyways (so where is the separation?) If we did drop an org level readme in /bitcoin, would we also be listing/linking to every other implementation in there? If not, that’d seem to
<fanquake>
undermine the premise as well. If the plan was to move everything out, except kernel, that would be more interesting to me.
<maflcko>
yeah, I don't want to rush or push it. Just wondering why it is bad timing
<sipa>
fanquake: ideally there'd be a bitcoin-bips/bips and a bitcoin-core/bitcoin etc, and the bitcoin/ org remains vestigial just to avoid name squatting and for redirect
<darosior>
I think it would be highly inadvisable for us to link people to alternate implementations that are not consensus-compatible with what 99% of the Bitcoin network runs.
<maflcko>
yeah, the readme should just briefly say a redirect exists
<achow101>
fanquake: ideally we wouldn't need to have redirects, but there's way too many links to bitcoin/bitcoin that breaking them would be a bad idea
<sipa>
fanquake: i strongly disagree with the notion that kernel somehow deserves to be treated differently - it's a still just one implementation, and people can choose to use it or not
sbddesign has quit [Ping timeout: 265 seconds]
<achow101>
the point of having a redirect or links in a readme is purely to not break all existing documentation and habits, of which there are many. it's not to be an exhaustive list of implementations.
<sipa>
achow101: +1
<fanquake>
my point is that if /bitcoin is now meant to be neutral, why wouldn’t people ask for that?
<darosior>
sipa: i think it is an overstatement to say "it is just one implementation". Kernel de facto defines what the network today will accept.
<sipa>
darosior: no it doesn't, bitcoin core de facto does
<darosior>
It's what i meant
<sipa>
people can choose to use bitcoin core or not
<achow101>
fanquake: it's not meant to be neutral, it's meant to not exist. obviously it has to exist to not break anything existing
<fanquake>
well /bitcoin does need to exist, to host the bips repo
<achow101>
bips can also move
<sipa>
fanquake: well all of this would be much more meaningful if bips moves too
<fanquake>
Is it going to?
<darosior>
sipa: of course but i don't think it is related
<achow101>
no idea. I think opinions are split there as well
<maflcko>
I'd say bips moving (or not) shouldn't affect or concern whether to move /bitcoin
<darosior>
To be honest i feel like we are discussing whether to take a decision that could have nefarious real-world consequences just to make a philosophical point
<achow101>
darosior: what "nefarious real-world consequences"?
<sipa>
darosior: i understand the concern of "people who aren't familiar will search for bitcoin and be confused when they don't find a reference implementation under bitcoin/" i guess, but really, i find it categorically wrong for bitcoin core (or kernel, or any of its related projects) to somehow present itself as being "bitcoin", even though today - and hopefully for long in the future - it remains de
<sipa>
facto what users use and thus defines the network
<darosior>
achow101: confusing people and effectively leading them to run lower quality software to validate their money.
<willcl-ark>
It might be good to also have a concrete answer to whether setting up and maintaining CI twice is hard/too much work, or not? Or if it's cost constraints, or something else. I've now heard that it both isn't (last year), and now that it is (so much so that it's a contributing factor for moving the r
<willcl-ark>
epo). If it is, and we move to hosted runners, and don't move the repo then we will indeed need "double CI", but it's also unclear to me if even this is a problem (cost wise).
<sipa>
darosior: TBH, i think it's more confusing the other direction
<achow101>
darosior: I don't see at all how that is a possibility. links to bitcoin/bitcoin will redirect. when you go to the bitcoin org profile, there won't be a "bitcoin" repository under there. I highly doubt any new person is going to github.com/bitcoin and looking for the "bitcoin" repo when they want to start using Bitcoin
<dergoegge>
where is the perception of separation we'd be aiming for if the redirect exists?
<achow101>
the redirect will be permanent, and the bitcoin org owners aren't going to change in order to ensure that no new bitcoin/bitcoin that breaks the redirect
<sipa>
darosior, achow101: yeah, this argument applies far more to bitcoin.org vs bitcoincore.org, but there the naming is already correct
<sipa>
dergoegge: that seems like a strawman to me; over time, people will start using the bitcoin-core repo
<sipa>
the bitcoin/ repo isn't there to to direct people (as repos won't even show up under it) to a specific implementation, it's to redirect old historical usage that hasn't updated
<achow101>
dergoegge: any new links people generate will be the new repo. when you go to the old link, it automatically redirects you to the new repo which says "bitcoin-core/bitcoin-core" or whatever
<dergoegge>
ok so the hope is we'd be able to remove the redirect in time?
<achow101>
dergoegge: I'd love to be able to do that
<achow101>
it'll probably take more than our lifetimes though
<Murch[m]>
dergoegge, I mean, you would not be looking at the bitcoin org anymore when browsing the repository, even if you got there originally by calling up the bitcoin org
<maflcko>
I don't think it is possible to remove a redirect (other than to create a repo on top). Personally I think it is fine to leave the redirect
<janb84>
There is currently a view of certain people that "bitcoin-core" is trying to capture bitcoin, wouldn't moving the repo now bolster that viewpoint and give extra negative backlash ?
<sipa>
janb84: i'd say it would do the exact opposite?
<Murch[m]>
janb84: Could you explain why you think that, it seems like the opposite to me, too.
<sipa>
who knows how things can be misinterpreted, of course, but logically, this is exactly moving away from the (understandable) misdirection someone might take from bitcoin core being under the bitcoin/ org
<achow101>
anyways, we're near the end of the meeting. if there are opinions, maybe they would be best expressed in #32340
<janb84>
it's a delicate topic ofc. again the good intentions are easily misinterpreted, "look they are now 100% trying to gain control" etc
<darosior>
I understand many (including me) are concerned with the confusion of Bitcoin and Bitcoin Core. However i don't think this means we should ignore the fact that anybody serious who wants to use Bitcoin today with real money on the line will want to use Bitcoin Core. Moving the repository is not going to change this reality.
<Murch[m]>
At this point, anything we do seems to be represented in pretty much every possible way as there are a substantial number of Bitcoin geeks producing podcasts and blog posts that are overinvested in the OP_RETURN thing…
<achow101>
darosior: no one claimed it would change that reality?
<sipa>
darosior: i certainly hope it doesn't!
<abubakarsadiq>
the redirect from /bitcoin/bitcoin indicates that Bitcoin core is the dominant implementation :P
<darosior>
sipa: :)
<sipa>
but i don't see how bitcoin core not being under bitcoin/ would somehow mean we don't think people should use bitcoin core
<achow101>
#endmeeting
<corebot`>
achow101: Meeting ended at 2025-06-19T17:00+0000
<achow101>
willcl-ark: do we know, concretely, what steps need to be done in order to setup the new ci? that would inform us how much work we have to duplicate
<darosior>
achow101: it seems the push to move is at least in part fueled by thinking we would face less pressure. I think this view is incorrect and falling into the fallacy that the Github repo matters to define what the Bitcoin network is.
<sipa>
janb84: i mean, sure, i can imagine people saying that, but... that would literally be the polar opposite of what is happening?
<achow101>
darosior: I have had a couple of people say to me "well if you guys aren't bitcoin, why are you using bitcoin/bitcoin", so I don't think it's incorrect to say that we would face less pressure
<achow101>
but for me, the push to move is mainly the practical of duplicating work
<janb84>
sipa: i'm affraid that the action of "moving" can be interpreted as hostile/taking control.
<maflcko>
willcl-ark: It should certainly be doable to setup the CI twice and cost about 2k-4k more (see above) maybe up to 10k, if we want more runners, but I think money or hassle can't be measured if people oppose this philosophically
<darosior>
achow101: these statements are motivated by the desired conclusion. They would find another reason to annoy you even if we moved.
<sipa>
janb84: ... moving *away* is taking control?!
<pinheadmz>
i think before any action is taken it would be wise to do some kind of PR and i dont mean pull request
<Murch[m]>
Probably the attack would be more along the lines of "they are moving the repository to pretend that they have less responsibility"
<darosior>
janb84: you seem confused. The point is to move away from bitcoin/bitcoin toward bitcoin-core/bitcoin.
<abubakarsadiq>
achow101: is that less pressure really worth the switch. I think people will just come up with yet another controversy
<pinheadmz>
see what kind of take the tweeters have and address it in a blog or discussion to clear anything up before doing it
<janb84>
sipa: yes, in the public eye. can 100% see that happing
<darosior>
Murch[m]: yeah exactly
<sipa>
janb84: yes, obviously, that can happen - but i don't think we should let our actions be determined by fear of people misrepresenting it as the polar opposite of what is happening
<achow101>
abubakarsadiq: i mean, it's about 30 seconds of work and no one has to actually change anything...
<achow101>
the hardest part is finding my yubikey to authorize the move
<janb84>
darosior: i'm aware , it's the act of moving itself to some thing that is seen as controlled by core. it's deligate
<marcofleon>
darosior: I think janb84 was saying it could be somehow misinterpreted as the "final step" in core taking control of bitcoin
<Murch[m]>
Seeing some news that people are now mining transactions below min relay tx feerate
Cory22 has quit [Quit: Client closed]
<marcofleon>
but agreed that whoever would see it like that, it's likely not worth caring what they think
Cory22 has joined #bitcoin-core-dev
<janb84>
marcofleon: yes that's what I mean.
<pinheadmz>
Murch[m] mononaut tweet or it didnt happen
<darosior>
marcofleon, janb84: i see, thanks for clarifying.
<pinheadmz>
ah i thought it was gonna be a slipstream
eugenesiegel has quit [Quit: Client closed]
vasild has quit [Ping timeout: 244 seconds]
vasild has joined #bitcoin-core-dev
<TheCharlatan>
sipa, r.e. kernel deserving to be treated differently. if it becomes the common codebase for a bunch of implementations, it would be equally weird in my eyes if it were still in the bitcoin-core org and not a shared codebase to some extent.
brunoerg has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
Guest8072 has left #bitcoin-core-dev [#bitcoin-core-dev]
sbddesign has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
saturday- has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 248 seconds]
Saturday7 has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
<sr_gi[m]1>
I've included a description of the approach in #30277 to make it easier to review (cc/ achow101)