achow101 changed the topic of #bitcoin-core-dev to: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Weekly Meeting Thursday @ 16:00 UTC | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
Zenton has quit [Ping timeout: 252 seconds]
bitdex has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 252 seconds]
Cory81 has quit [Quit: Client closed]
Cory81 has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] achow101 pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/5e6dbfd14ea9...9a7eece5a4a1
<bitcoin-git> bitcoin/master 74690f4 Sjors Provoost: validation: refactor TestBlockValidity
<bitcoin-git> bitcoin/master 6077157 Sjors Provoost: ipc: drop BlockValidationState special handling
<bitcoin-git> bitcoin/master 94959b8 Sjors Provoost: Add checkBlock to Mining interface
<bitcoin-git> [bitcoin] achow101 merged pull request #31981: Add checkBlock() to Mining interface (master...2025/03/checkBlock) https://github.com/bitcoin/bitcoin/pull/31981
Zenton has joined #bitcoin-core-dev
Cory81 has quit [Quit: Client closed]
Cory81 has joined #bitcoin-core-dev
dviola has quit [Read error: Connection reset by peer]
diego has joined #bitcoin-core-dev
diego is now known as Guest5514
Earnestly has quit [Ping timeout: 248 seconds]
Guest5514 has quit [Read error: Connection reset by peer]
diego has joined #bitcoin-core-dev
diego is now known as Guest8434
_flood has quit [Remote host closed the connection]
Guest8434 has quit [Ping timeout: 260 seconds]
diego has joined #bitcoin-core-dev
diego is now known as Guest6261
Saturday7 has quit [Quit: ZNC 1.10.0 - https://znc.in]
Cory81 has quit [Quit: Client closed]
Cory81 has joined #bitcoin-core-dev
robszarka has joined #bitcoin-core-dev
szarka has quit [Ping timeout: 260 seconds]
Saturday7 has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
Saturday7 has quit [Ping timeout: 244 seconds]
Saturday7 has joined #bitcoin-core-dev
conman has quit [Remote host closed the connection]
conman has joined #bitcoin-core-dev
saturday- has joined #bitcoin-core-dev
Saturday7 has quit [Ping timeout: 252 seconds]
vasild_ has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
saturday- has quit [Quit: ZNC 1.10.0 - https://znc.in]
Saturday7 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 272 seconds]
<bitcoin-git> [bitcoin] maflcko opened pull request #32774: doc: Explain how to fetch commits directly (master...2506-doc-fetch-commit) https://github.com/bitcoin/bitcoin/pull/32774
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
Guyver2 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
mcey_ has joined #bitcoin-core-dev
mcey has quit [Ping timeout: 248 seconds]
kevkevin has quit [Ping timeout: 272 seconds]
mcey_ has quit [Remote host closed the connection]
mcey_ has joined #bitcoin-core-dev
S3RK_ has joined #bitcoin-core-dev
Earnestly has joined #bitcoin-core-dev
S3RK has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
Dansken has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
Dansken has joined #bitcoin-core-dev
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
kevkevin has quit [Ping timeout: 244 seconds]
l0rinc has quit [Ping timeout: 265 seconds]
kevkevin has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] Sjors opened pull request #32776: doc: taproot became always active in v24.0 (master...2025/06/taproot-bip) https://github.com/bitcoin/bitcoin/pull/32776
<bitcoin-git> [bitcoin] fanquake pushed 4 commits to 28.x: https://github.com/bitcoin/bitcoin/compare/e5a9e2435f16...e44d72b6480a
<bitcoin-git> bitcoin/28.x 3cd4fdb Ava Chow: build: Bump to 28.2
<bitcoin-git> bitcoin/28.x 90f78c7 Ava Chow: docs: Regenerate manpages for 28.2
<bitcoin-git> bitcoin/28.x 7135d75 Ava Chow: docs: Release notes for 28.2
<bitcoin-git> [bitcoin] fanquake merged pull request #32766: [28.x] Finalize 28.2 (28.x...28.2-final) https://github.com/bitcoin/bitcoin/pull/32766
kevkevin has quit [Ping timeout: 276 seconds]
Saturday7 has quit [Quit: ZNC 1.10.0 - https://znc.in]
kevkevin has joined #bitcoin-core-dev
Saturday7 has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake opened pull request #32777: doc: fix Transifex 404s (master...transifex_404) https://github.com/bitcoin/bitcoin/pull/32777
kevkevin has quit [Ping timeout: 248 seconds]
Cory81 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
darosior1 has joined #bitcoin-core-dev
darosior has quit [Ping timeout: 260 seconds]
darosior1 is now known as darosior
kevkevin has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9a7eece5a4a1...79afe6b7c092
<bitcoin-git> bitcoin/master 8ee8a95 Sjors Provoost: doc: taproot became always active in v24.0
<bitcoin-git> bitcoin/master 79afe6b merge-script: Merge bitcoin/bitcoin#32776: doc: taproot became always active in v24.0 (d...
<bitcoin-git> [bitcoin] fanquake merged pull request #32776: doc: taproot became always active in v24.0 (doc/bips.md) (master...2025/06/taproot-bip) https://github.com/bitcoin/bitcoin/pull/32776
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/79afe6b7c092...b86141925416
<bitcoin-git> bitcoin/master 53a996f fanquake: doc: fix transifex 404s
<bitcoin-git> bitcoin/master b861419 merge-script: Merge bitcoin/bitcoin#32777: doc: fix Transifex 404s
<bitcoin-git> [bitcoin] fanquake merged pull request #32777: doc: fix Transifex 404s (master...transifex_404) https://github.com/bitcoin/bitcoin/pull/32777
darosior has quit [Ping timeout: 245 seconds]
kevkevin has quit [Ping timeout: 276 seconds]
jespada has joined #bitcoin-core-dev
darosior has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b86141925416...e18322eff274
<bitcoin-git> bitcoin/master fa94fd5 MarcoFalke: doc: Explain how to fetch commits directly
<bitcoin-git> bitcoin/master e18322e merge-script: Merge bitcoin/bitcoin#32774: doc: Explain how to fetch commits directly
<bitcoin-git> [bitcoin] fanquake merged pull request #32774: doc: Explain how to fetch commits directly (master...2506-doc-fetch-commit) https://github.com/bitcoin/bitcoin/pull/32774
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
robszarka has quit [Quit: Leaving]
szarka has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
kevkevin has joined #bitcoin-core-dev
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
<bitcoin-git> [bitcoin] fanquake opened pull request #32780: lsan: add more Qt suppressions (master...qt_more_lsan) https://github.com/bitcoin/bitcoin/pull/32780
Guest6261 has quit [Ping timeout: 272 seconds]
diego has joined #bitcoin-core-dev
diego is now known as Guest8072
Earnestly has quit [Ping timeout: 252 seconds]
Earnestly has joined #bitcoin-core-dev
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e18322eff274...fa183045a1ea
<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
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fa183045a1ea...154b98a7aaae
<bitcoin-git> bitcoin/master cd1ae1b brunoerg: fuzz: wallet: remove FundTx from FuzzedWallet
<bitcoin-git> bitcoin/master 154b98a merge-script: Merge bitcoin/bitcoin#32772: fuzz: wallet: remove `FundTx` from `FuzzedWal...
<bitcoin-git> [bitcoin] fanquake merged pull request #32772: fuzz: wallet: remove `FundTx` from `FuzzedWallet` (master...2025-06-fuzz-delete-fundtx) https://github.com/bitcoin/bitcoin/pull/32772
<bitcoin-git> [bitcoin] Sjors opened pull request #32781: refactor: modernize deprecated ipc headers (master...2024/06/tidy) https://github.com/bitcoin/bitcoin/pull/32781
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
sbddesign has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
<bitcoin-git> [bitcoincore.org] dergoegge opened pull request #1146: advisories: Add point of contact details for disclosures (master...sec-poc-details) https://github.com/bitcoin-core/bitcoincore.org/pull/1146
sbddesign has quit [Ping timeout: 252 seconds]
OYENRAZOR369 has joined #bitcoin-core-dev
sbddesign has joined #bitcoin-core-dev
<bitcoin-git> [bitcoin] achow101 pushed tag v28.2: https://github.com/bitcoin/bitcoin/compare/v28.2
sbddesign has quit [Ping timeout: 260 seconds]
zeropoint has joined #bitcoin-core-dev
Emc99 has joined #bitcoin-core-dev
Emc99 has quit [Client Quit]
Emc99 has joined #bitcoin-core-dev
Emc99 has quit [Client Quit]
sbddesign has joined #bitcoin-core-dev
Emc99 has joined #bitcoin-core-dev
<achow101> #startmeeting
<corebot`> achow101: Meeting started at 2025-06-19T16:00+0000
<corebot`> achow101: Current chairs: achow101
<corebot`> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
<corebot`> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
<TheCharlatan> hi
<achow101> #bitcoin-core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto hodlinator instagibbs jarolrod jonatack josibake kanzure laanwj LarryRuane lightlike luke-jr maflcko marcofleon maxedw Murch pinheadmz provoostenator ryanofsky sdaftuar S3RK stickies-v sipa sr_gi tdb3 theStack TheCharlatan vasild willcl-ark
<darosior> hi
<pinheadmz> Hi from AA3058 to PHX
<willcl-ark> hi
<sipa> hi
<achow101> there is one preproposed meeting topics this week. Any last minute ones to add?
<stickies-v> hi
<theStack> hi
<lightlike> hi
<achow101> #topic Kernel WG Update (TheCharlatan)
<TheCharlatan> Looking for review on #32317
<corebot`> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
<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
<corebot`> https://github.com/bitcoin/bitcoin/issues/30277 | [DO NOT MERGE] Erlay: bandwidth-efficient transaction relay protocol (Full implementation) by sr-gi · Pull Request #30277 · bitcoin/bitcoin · GitHub
bugs_ has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
<sr_gi[m]1> The warnet repo is not, I'll update it today. The branch I'm using for the warnet tests is tho: https://github.com/sr-gi/bitcoin/tree/202406-erlay-full-draft-warnet
<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)
<corebot`> https://github.com/bitcoin/bitcoin/issues/31553 | cluster mempool: add TxGraph reorg functionality by sipa · Pull Request #31553 · bitcoin/bitcoin · GitHub
<sipa> #30605 is not urgent, but pretty close to merge, i think; it's just test / comment improvements
<corebot`> https://github.com/bitcoin/bitcoin/issues/30605 | Cluster linearization: separate tests from tests-of-tests by sipa · Pull Request #30605 · bitcoin/bitcoin · GitHub
<sipa> it also includes a fancy ascii-art diagram
<sipa> i have rebased #32545 on top of 30605, as there was some overlap, and it can wait
<corebot`> https://github.com/bitcoin/bitcoin/issues/32545 | Replace cluster linearization algorithm with SFL by sipa · Pull Request #32545 · bitcoin/bitcoin · GitHub
<sipa> that's it for me, unless someone has questions/comments
<achow101> #topic MuSig2 WG Update (achow101, rkrux)
<achow101> bips#1867 was merged. #31244 is updated to allow duplicate participant keys, and all review has been addressed.
<corebot`> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
<corebot`> https://github.com/bitcoin/bips/issues/1867 | 390: Allow repeated participant pubkeys and disallow ranged participants with aggregate derivation. by achow101 · Pull Request #1867 · bitcoin/bips · GitHub
<achow101> 31244 is still the pr to review
<achow101> #topic move the repo to bitcoin-core (achow101)
<achow101> wanted to bring this up again since there's some talk about changing CI, and having everything in one org would make that easier
<sipa> can you link to CI changing discussions?
<achow101> There was some discussion in #31965, but afaict, most is happening in signal
<corebot`> https://github.com/bitcoin/bitcoin/issues/31965 | Revisiting us self-hosting parts of our CI · Issue #31965 · bitcoin/bitcoin · GitHub
<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
<corebot`> https://github.com/bitcoin/bitcoin/issues/32340 | Moving this repo to bitcoin-core · Issue #32340 · bitcoin/bitcoin · GitHub
<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
Emc99 has quit [Quit: Client closed]
<sipa> abubakarsadiq: just the historical one
<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.
<janb84> darosior: no worries
<Murch[m]> Haven’t seen a mononaut tweet yet, but: https://nitter.space/ottosch_/status/1935712233230639176
<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)
<corebot`> https://github.com/bitcoin/bitcoin/issues/30277 | [DO NOT MERGE] Erlay: bandwidth-efficient transaction relay protocol (Full implementation) by sr-gi · Pull Request #30277 · bitcoin/bitcoin · GitHub
<sr_gi[m]1> The warnet repo is also up to date now pinheadmz: https://github.com/sr-gi/erlay-warnet
<pinheadmz> \m/
TheRec has quit []
<sipa> TheCharlatan: perhaps, but even then i don't think it deserves the "bitcoin" label
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 260 seconds]
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
sbddesign has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 276 seconds]
Talkless has quit [Quit: Konversation terminated!]
Guest25 has joined #bitcoin-core-dev
Guest25 has quit [Client Quit]
kevkevin has joined #bitcoin-core-dev
Cory22 has quit [Quit: Client closed]
Cory22 has joined #bitcoin-core-dev
TheRec has joined #bitcoin-core-dev
TheRec has joined #bitcoin-core-dev
<TheCharlatan> sipa that's fair I guess - though I would not necessarily call that "deserves" :P
sbddesign has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 252 seconds]
TheRec has quit [Ping timeout: 252 seconds]
TheRec has joined #bitcoin-core-dev
TheRec_ has joined #bitcoin-core-dev
TheRec has quit [Ping timeout: 248 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
Guest63 has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 276 seconds]
jespada has joined #bitcoin-core-dev
sbddesign has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 244 seconds]
sbddesign has joined #bitcoin-core-dev
bugs_ has quit [Quit: Leaving]
TheRec_ has quit []
brunoerg has joined #bitcoin-core-dev
TheRec has joined #bitcoin-core-dev
Guest63 has quit [Ping timeout: 272 seconds]
sbddesign has quit [Ping timeout: 252 seconds]
bitdex has quit [Ping timeout: 244 seconds]
PaperSword has quit [Quit: PaperSword]
bitdex has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
OYENRAZOR369 has joined #bitcoin-core-dev