<bitcoin-git>
[gui] laanwj opened pull request #868: qt: Replace stray tfm::format to cerr with qWarning (master...2025-05-qt-stray-format) https://github.com/bitcoin-core/gui/pull/868
kevkevin has joined #bitcoin-core-dev
jespada has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 260 seconds]
kevkevin has quit [Ping timeout: 252 seconds]
jespada has joined #bitcoin-core-dev
pablomartin has quit [Ping timeout: 268 seconds]
Cory46 has quit [Quit: Client closed]
Cory46 has joined #bitcoin-core-dev
pablomartin has joined #bitcoin-core-dev
pablomartin has quit [Ping timeout: 252 seconds]
pablomartin has joined #bitcoin-core-dev
abubakarsadiq has quit [Quit: Connection closed for inactivity]
_flood has joined #bitcoin-core-dev
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
Cory46 has quit [Quit: Client closed]
Cory46 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 245 seconds]
kevkevin has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
Christoph_ has joined #bitcoin-core-dev
neutrino777 has joined #bitcoin-core-dev
neutrino1 has quit [Ping timeout: 252 seconds]
bugs_ has joined #bitcoin-core-dev
kevkevin_ has joined #bitcoin-core-dev
kevkevin has quit [Read error: Connection reset by peer]
Cory46 has quit [Quit: Client closed]
Cory46 has joined #bitcoin-core-dev
<jeremyrubin>
sipa: noticed that minisketch is using std::uniform_int_distribution and std::random_device... might make sense to do proper seeding as this might, on some platforms, give you the same seed for every object made. Also, std::uniform_int_distribution can be platform dependent (in case any tests are supposed to rely on a specific value being
<jeremyrubin>
generated)
<bitcoin-git>
[bitcoin] vasild opened pull request #32338: net: remove unnecessary check from AlreadyConnectedToAddress() (master...AlreadyConnectedToAddress) https://github.com/bitcoin/bitcoin/pull/32338
jonatack has quit [Ping timeout: 244 seconds]
<sipa>
jeremyrubin: seems like a good idea, yeah
<sipa>
(to use explicit initialization)
Cory18 has joined #bitcoin-core-dev
catnip has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
Cory46 has quit [Ping timeout: 240 seconds]
jonatack has joined #bitcoin-core-dev
gerle has joined #bitcoin-core-dev
catnip has quit [Ping timeout: 240 seconds]
<jeremyrubin>
is minisketch a submodule with repo elsewhere? or is it fully in tree
_flood has quit [Remote host closed the connection]
_flood has joined #bitcoin-core-dev
<sipa>
it's a subtree, like all other pinned dependencies (libsecp256k1, ctaes, crc32c, leveldb)
<sipa>
This cannot make flows or excesses negative, or decrease distance to the sink.
<achow101>
There's 1 preproposed meeting topic this week, any last minute ones to add?
<johnny9dev>
hi
<laanwj>
hi
<dzxzg>
hi
<sipa>
hi, at lunch (as are glozow and darosior), we'll be there in a few
Guest71 has quit [Quit: Client closed]
pablomartin4btc has joined #bitcoin-core-dev
Guest71 has joined #bitcoin-core-dev
<achow101>
sipa: glozow: I'll put your working group updates at the end of the list
<achow101>
#topic Erlay WG Update (sr_gi, gleb)
Cory15 has joined #bitcoin-core-dev
<glozow>
(I don’t have updates for orphan reso fwiw)
Guest71 has quit [Client Quit]
<sr_gi[m]>
Not much to report this week. I extended the functional tests to cover all protocol violations and edge cases and started working on Warnet deployment to test Erlay. I just started running some tests on Warnet
Emc87 has joined #bitcoin-core-dev
pablomartin has quit [Ping timeout: 252 seconds]
<sr_gi[m]>
That's all
<achow101>
#topic Kernel WG Update (TheCharlatan)
<TheCharlatan>
Still looking for review on #31382 and hunting Approach ACKs on #30595
<TheCharlatan>
They reported a significant validation speedup with the new kernel API design over the old libbitcoinconsensus API
<laanwj>
neat
<sipa>
TheCharlatan: that seems exciting
<achow101>
that's cool
<TheCharlatan>
yes, very cool that they decided to go and experiment with already :)
<cfields>
hi
<TheCharlatan>
I opened #32317 for separating retrieving, and spending Coins from the rest of block validation. This could more easily allow for validating blocks with just the coins spent in the block without the need to maintain a full utxo set.
<achow101>
#topic QML GUI WG Update (jarolrod, johnny9dev)
<johnny9dev>
Took a bit longer to get back in a rhythm after being away for 2 weeks but I managed to fix some issues found by Marnix as well as handle the case when there are no Coins to select in my Coin Control PR (bitcoin-core/gui-qml#448).
<johnny9dev>
I think that should be it for this iteration of coin control and will be looking to merge this is as well as start the PR for multiple send recipients next
<sipa>
hi
<stickies-v>
hi
<johnny9dev>
thats all for gui-qml for this week
<achow101>
#topic Script Validation WG Update (fjahr)
<fjahr>
Nothing new to report as far as I’m aware. Still looking for approach feedback on #29491 and working on tests.
<sipa>
one from the 1989 paper), and benchmarks for it.
<sipa>
I'm planning to open a PR to implement the spanning-forest one in the next week or so.
<sipa>
If you want to understand the justification, and trade-offs involved, please see the posts.
<sipa>
That's it for me, unless there are any questions.
zeropoint has joined #bitcoin-core-dev
<achow101>
#topic Move the repo to bitcoin-core github organization (achow101)
<achow101>
This past week, the topic of moving the repo to bitcoin-core has come up again due to possible issues with conflicting moderation between bitcoin/bitcoin and bitcoin/bips. The main point is that bans are issued at the organization level, but Bitcoin Core and BIPs are really two separate projects. It is therefore conceivable that Bitcoin Core would want to ban someone, but BIPs would not, and vice versa. Under the current setup, any ban from one
<achow101>
repo is necessarily a ban from both because it is a ban from the organization.
<achow101>
The solution to this issue is to not have both Bitcoin Core and BIPs under the same organization. We already have the bitcoin-core organization where all of our new repos go anyways, it would entirely make sense to move bitcoin/bitcoin to bitcoin-core/bitcoin-core, or something like that. There's also a bitcoin-bips organization that was created a couple of years ago for this, so bips could be moved there. But I think that's for the bip editors
<achow101>
to discuss.
<achow101>
Moving the repo to bitcoin-core would also reduce administration overhead - primarily that keeping 2 organizations' member and team lists in sync is kind of annoying.
<achow101>
Transferring the repo is trivial - the same people are owners of both bitcoin and bitcoin-core, it's just a matter of clicking the button. However, it is also something that I think requires contributor buy-in, and notice that it's happening.
<achow101>
The main issue that there could be is of course that bitcoin/bitcoin is referenced in a ton of places. However, github already handles this by redirecting all links from the old repo location to the new repo location. All PRs and issues are transferred, all links automatically redirect, and git remotes will automatically redirect too so no one would even have to change their git config. All that needs to happen is that a bitcoin/bitcoin repo
<achow101>
cannot be created after the transfer as that will break all of the redirects.
<achow101>
If everyone is okay with this, I can do it right after the meeting.
<achow101>
sorry for the wall of text
<fjahr>
FWIW, I have recently moved a few repos from my personal github account to the asmap org and I have not noticed any disruption, if that's a concern for anyone...
Emc99 has joined #bitcoin-core-dev
<laanwj>
sounds good to me, as long as the old git URL will keep working , it's been the plan for as long as the bitcoin-core org exists, really
<glozow>
Another solution is to move the bips repo somewhere else? iirc laanwj mentioned having an org already?
<fjahr>
There are redirects and they have worked without issue
<darosior>
I can attest that redirect still work for me on a project i moved 4 years ago, for what it's worth.
<laanwj>
yes could move the bips repo as well, empty out "bitcoin" completely eventually
<fanquake>
wouldn't moving the repo break the setup of banning from bitcoin/bitcoin, and then the person can actually comment in bitcoin-core/meta, otherwise if they both exist in the same org, how will the banne comment in meta
<achow101>
glozow: yes. I think moving both is preferable
<laanwj>
(or maybe except for meta)
<laanwj>
"libbase58" is also still in bitcoin i don't know what to do with that
<sipa>
Ignoring history, I think having bitcoin/bips and bitcoin-core/bitcoin makes most sense, in that BIPs are actually aiming to be a whole-Bitcoin-ecosystem wide thing.
<achow101>
fanquake: tbh I don't think meta is actually for banned people to appeal their ban
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<lightlike>
I'd prefer to wait a week or so with this (that is, if moving is decided) so people not present right now could say something if they want to.
<willcl-ark>
What are the advantages of vacating bitcoin/bitcoin? My natural instinct would be to retain that and move bips/ out from bitcoin/?
<achow101>
laanwj: I think libbase58 and libblkmaker can be archived
<cfields>
hmm, looking at what would be left in bitcoin/, it'd just be bips/libblkmaker/libbase58. There's been discussion about moving/deprecating the latter 2 for years. So that'd just leave bips in bitcoin/.
Emc87 has quit [Ping timeout: 240 seconds]
<laanwj>
achow101: agree
<sr_gi[m]>
lightlike: +1
<achow101>
willcl-ark: It also makes organizing the organization easier. right now we have two orgs, with separate member lists. everyone is invited to both, but not everyone accepts the invites
<darosior>
Leaving bips in bitcoin/ and having Core in bitcoin-core/ does make sense to me, although i haven't thought about drawbacks.
<glozow>
if you ban someone from bitcoin-core org, aren't they unable to comment on bitcion-core/meta issues?
<achow101>
glozow: yes
<sipa>
Would the bitcoin org ownership be handed to the BIPs editors then?
<glozow>
Oh i see now, you're saying that's a feature not a bug
<laanwj>
yes the parallel member list was always an annoyance to maintain
<achow101>
glozow: :)
<willcl-ark>
achow101: I see, thanks.
<achow101>
sipa: I guess so? I'd still prefer to also move bips out and we can sunset bitcoin/
<laanwj>
sipa: no i don't think so, if they want an org they can have bitcoin-bips
<darosior>
laanwj: +1
<fanquake>
achow: then shouldn't oversight be changed in the moderation guidelines?
<sipa>
+1 laanwj, i think that makes sense
<fanquake>
How is someone meant to open an issue if they can't open an issue
<achow101>
fanquake: they can also email
<cfields>
achow101: I don't think we want to leave bitcoin/ in a state where it could be perceived as dormant/up for grabs.
<sipa>
cfields: agreed
<fanquake>
wait why are we sunsetting bitcoin/
<achow101>
cfields: definitely not, it would still be owned by us(?), with a readme that says go somewhere else
<fanquake>
why wouldn't bips exist there
<glozow>
Slightly uncomfortable with the idea that the redirects only work if the owners of bitcoin org don't create a new bitcoin repo + giving admin up to bip editors
<sr_gi[m]>
Why tho?
<willcl-ark>
glozow: +1
<darosior>
achow101: wait if you have a README you don't have the redirect anymore?
rkrux has quit [Quit: Client closed]
<sipa>
fanquake: i think *our* decision here is whether to move bitcoin/bitcoin to bitcoin-core/bitcoin; the question whether bitcoin/bips moved elsewhere is up to the BIP editors
<achow101>
darosior: org level readme
<achow101>
or another repo
<laanwj>
glozow: right, we should keep admin there to make sure it's not used for anything else
<darosior>
glozow: +1
<fanquake>
sipa: then shouldn't we wait for them to have that discussion
<fanquake>
why are we doing anything
<sipa>
i think it's an independent decision
<fanquake>
not really, because we'd have to enact it for them
<fanquake>
none of them have admin permissions
<achow101>
moving our repo can be done before they decide what to do with bips though
<sipa>
yes, that's the point
<sipa>
they can stay under bitcoin org, where we have ownership
<sipa>
or decide to move somewhere where they do
<achow101>
and we can maintain ownership of bitcoin/ in the meanwhile
<fanquake>
seems odd that this is all happening because of moderation
<darosior>
I think the current group of owners of the bitcoin org have shown themselves to be trustworthy and i don't think we should take the risk to change it.
<laanwj>
independently, moving bitcoin's repo to bitcoin-core makes sense, even if just for consistency and to not have to maintain parallel teams/frequent contributor lists
<achow101>
fanquake: for me, it's not just about moderation, but that's what kickstarted this idea again
<darosior>
fanquake: yeah agree, maintaining the list is sync, as well as separating Bitcoin vs Bitcoin Core, seem more compelling reason to me.
<achow101>
i've had this thought for a while
<laanwj>
moving the repo eventually was the plan for a long time already, i think any reason it was controversial disappeared into the past long ago
<willcl-ark>
I'm not sure the benefit of having a single list less to sync, seems worth the risks
<sipa>
i think i'm in favor of moving bitcoin/bitcoin to bitcoin-core/bitcoin, and archiving libbase58/libblkmaker, if the plan is that we retain ownership of bitcoin
<achow101>
sipa: +1
<sipa>
mostly for reasons of making real organisation structure match github repository structure
<darosior>
Can we start bike-shedding the name of the repository in the bitcoin-core org then? :p
<achow101>
we can wait for another week as lightlike suggests if anyone not present has opinions
<laanwj>
yes, there isn't suddenly a hurry
<achow101>
well, not anymore
<laanwj>
right
<achow101>
darosior: we can call it bitcoin-core :p
<laanwj>
yes, the repo could be renamed too, i dont' think that will affect the redirect
<willcl-ark>
I feel like org member lists could be relatively trivially synced using a fine-grained token of some type (not checked this though)
<laanwj>
yes, they could be synced, but why?
<achow101>
willcl-ark: it's more about the fact that there are 2 invites, and not everyone remembers to accept both
<darosior>
willcl-ark: are you ~0 on moving the repo?
<achow101>
we've had this come up a couple of times already where people accepted the invite to one org but not the other, and then we have to spend some time figuring out which org they didn't accept to and reinvite them just so we can request a reviewer
<TheCharlatan>
that doesn't seem too anoying tbh
<glozow>
why are people people
<achow101>
TheCharlatan: you aren't the one dealing with it
<sipa>
i feel that the difficulty of this synchronization is only a minor side-effect of a bad structure
<vasild>
another possibility is to keep bitcoin/bitcoin as it is and move bitcoin-core/* into bitcoin/; move bitcoin/bips into another org
<laanwj>
so is there any strong reason to not move the repo?
<darosior>
This strikes me as a triviality and a bit of a weak motivation to move the repo. I find making the difference between Core and Bitcoin is more compelling a reason.
<sipa>
darosior: _1
<sipa>
+1
<achow101>
vasild: I don't think we should do that, and I think it's better to separate Bitcoin Core from Bitcoin
<willcl-ark>
achow101: I think I'm just not fully understanding the rationale or benefits here, and feel like there could be other potential risks
<laanwj>
why does it make sense to keep it separate from the rest
robszarka has quit [Quit: Leaving]
<achow101>
willcl-ark: could you give some examples of risks that you think there could be?
szarka has joined #bitcoin-core-dev
<sipa>
willcl-ark: i think the fact that it's not possible to ban someone from the Bitcoin Core org without also banning them from the BIPs org (whatever those orgs are) is a good motivation. It's not the reason on itself, but it demonstrates there is a mismatch in organisational structure. There is absolutely no reason why people maintaining a piece of software should have the ability to ban someone from
<sipa>
a standards organisation, or the other way around.
<glozow>
sipa: I think the cleaner solution to that is to have bips move though. Because assuming we're retaining ownership of the bitcoin org, we're still the ones pressing the ban button for bips
<darosior>
good point
<vasild>
glozow: +1
<sipa>
glozow: yeah, fair point
<achow101>
glozow: we can give ownership to the bip editors too, and make bitcoin/ jointly owned
<cfields>
glozow: so then what's left in bitcoin/ ?
<achow101>
but I also prefer both move out
<sipa>
i think the ideal solution is that both move, and bitcoin remains vestigial
<achow101>
sipa: +1
<sipa>
(and not up for grabs)
<glozow>
cfields: I think it's fine if nothing remains
<laanwj>
we need to keep sole ownership of bitcoin to make sure no one else creates a repo named bitcoin
<cfields>
mmm, I don't love the idea of _just_ squatting on it.
<fjahr>
There isn't a straightforward way to claim an unused org/username from github afaik
<darosior>
achow101: i don't think this is a good idea for you all to give/share ownership of bitcoin/
<fanquake>
fjahr: you just email GH
<fanquake>
they'll git it up if it's unused
<sipa>
ha, "git"
<achow101>
we can put an readme in the org profile that says something to the effect of keeping the organization to preserve redirects for the moved repos
<cfields>
right, because of ^^
<laanwj>
they won't give it up easily even if it's unused, i couldn't get bitcoincore back then
<fjahr>
fanquake: I looked into this and for something unrelated and nobody seemed have success with that in forums
<fanquake>
I have done it before
<achow101>
presumably it's also much harder if there are owners of the org that are active elsewhere
<fanquake>
Although this was 7-8 years ago
<darosior>
Our project is so high profile and such a scammer magnet that i'm not sure i'd want to risk it
<sr_gi[m]>
I still don't see what is the motivation for leaving bitcoin empty
<fjahr>
faking activity is also easy but not sure worth the effort and better than moving bips
<achow101>
sr_gi[m]: why should it be non-empty?
<sipa>
sr_gi[m]: as opposed to what?
Guest99 has joined #bitcoin-core-dev
<sr_gi[m]>
As opposed to keeping either bitcoin or bips on it
<sr_gi[m]>
I see the motivation for separating both, but not why both need to go out
<darosior>
sr_gi[m]: some of us are not comfortable with the current owners giving ownership away
<darosior>
(if keeping bips repo)
<sipa>
sr_gi[m]: who gets ownership after separation? either side would need to trust the other one not to break redirects
<lightlike>
darosior: agree, especially after the experiences with the transifex coup last year
<sipa>
not that i have any reason to distrust the current bips editors with that, to be clear
<sipa>
but things change
l0rinc has joined #bitcoin-core-dev
<achow101>
but the editors may change in the future, even to people who forget that the redirects exist
<glozow>
What if github stops doing redirects or kicks us for squatting? Not to be a doomer but what if some random money-stealing or just poorly maintained client takes over bitcoin/bitcoin? bitcoin.org not keeping up with software updates already causes people on the network to run unmaintained software.
<achow101>
(should bitcoin exist that long)
<vasild>
so the only solution seems to be to move bitcoin/bips to another org and leave the rest as it is?
<achow101>
they seem to have maintained redirects for a very long time now, don't see why they would stop doing that
<glozow>
sometimes sites that have been around for a long time try to release old unused usernames
<laanwj>
i mean the hope is that people will update their links, too, so the redirect will become less important over time
<achow101>
i mean, Murch[m] tried to get the username murch from an inactive profile and was absolutely unable to
<darosior>
It seems like in theory it would be nice to move but in practice it would result in unnecessary risk?
<achow101>
I think the risk is minimal
<laanwj>
i think so too
<sr_gi[m]>
I personally think that the risk of github breaking redirects is higher than someone in the bitcoin org creating a bips repo, and what the implications may be
<achow101>
I think there's a higher risk of an org owner accidentally breaking the redirect than github breaking it
<darosior>
Alright, maybe we can mull it over for some time and continue discussions in a Github issue?
<achow101>
I'll put it as a topic again for next week
<laanwj>
same, github really isn't known for breaking redirects even long-running ones, and they don't tend to give away even inactive cryptocurrency orgs to scammers
<achow101>
Any other topics to discuss?
<dzxzg>
I'm not asking whether they'll give it up, just wondering if it's an issue that there's an aural collision with this other org "bitcoincore/bitcoin" (but I'm overall +1 on moving to bitcoin-core)
<laanwj>
"bitcoincore" has been inactive since 2014 at least it's owned by a github staffer, it's not relevant here
<dzxzg>
I see, sorry
<glozow>
yeah I definitely don't think Bitcoin and Bitcoin Core are the same thing. Really no single piece of software could be == Bitcoin. But most users don't know that, they will search for something called 'bitcoin,' run it, and manage their money with it...
<sipa>
glozow: i think that's much more applicable to bitcoin.org vs bitcoincore.org than github.com/bitcoin vs github.com/bitcoin-core, but yeah
<laanwj>
dzxzg: oh i see your point now, yes it's less of an issue if we rename the repo to bitcoin-core too
<achow101>
also, if redirects do break, github support has re-established them in the past. I accidentally did this once with hwi.
<Murch[m]>
<achow101> "i mean, Murch tried to get the..." <- And I’m not even sure if it was a prior GitHub account I created myself that I just don’t retain the email address to. ;)
<laanwj>
heh
<achow101>
#endmeeting
<corebot>
achow101: Meeting ended at 2025-04-24T16:54+0000
<darosior>
Murch[m]: deleted-key covenant, but with a password
<kanzure>
this doc does not address redirect risk, absent redirect risk i am not sure there is a real problem
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
Cory94 has quit [Quit: Client closed]
Cory94 has joined #bitcoin-core-dev
<achow101>
kanzure: redirect risk in what way? redirects are addressed
<achow101>
i added a bullet for the takeover risk that was discussed
___nick___ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] laanwj opened pull request #32343: common: Close non-std fds before exec in RunCommandJSON (master...2025-04-closefds) https://github.com/bitcoin/bitcoin/pull/32343
<bitcoin-git>
[bitcoin] laanwj closed pull request #30756: run_command: Close non-std fds when execing slave processes (master...subproc_closefds) https://github.com/bitcoin/bitcoin/pull/30756
Talkless has quit [Quit: Konversation terminated!]