16:00:18 <achow101> #startmeeting 
16:00:18 <corebot> achow101: Meeting started at 2025-04-24T16:00+0000
16:00:19 <corebot> achow101: Current chairs: achow101
16:00:20 <corebot> achow101: Useful commands: #action #info #idea #link #topic #motion #vote #close #endmeeting
16:00:21 <corebot> achow101: See also: https://hcoop-meetbot.readthedocs.io/en/stable/
16:00:22 <corebot> achow101: Participants should now identify themselves with '#here' or with an alias like '#here FirstLast'
16:00:27 <achow101> #bitcoin -core-dev Meeting: abubakarsadiq achow101 _aj_ ajonas b10c brunoerg cfields darosior dergoegge fanquake fjahr furszy gleb glozow hebasto 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
16:00:30 <rkrux> hi
16:00:32 <hebasto> hi
16:00:32 <TheCharlatan> hi
16:00:36 <maxedw> hi
16:00:39 <vasild> hi
16:00:40 <lightlike> Hi
16:00:40 <willcl-ark> hi
16:00:41 <furszy> hi
16:00:49 <fjahr> hi
16:00:51 <Murch[m]> Hi
16:00:53 <sr_gi[m]> hi
16:01:04 <achow101> There's 1 preproposed meeting topic this week, any last minute ones to add?
16:01:06 <johnny9dev> hi
16:01:09 <laanwj> hi
16:01:10 <dzxzg> hi
16:01:19 <sipa> hi, at lunch (as are glozow and darosior), we'll be there in a few
16:01:52 <achow101> sipa: glozow: I'll put your working group updates at the end of the list
16:02:10 <achow101> #topic Erlay WG Update (sr_gi, gleb)
16:03:03 <glozow> (I don’t have updates for orphan reso fwiw)
16:03:24 <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
16:04:02 <sr_gi[m]> That's all
16:04:09 <achow101> #topic Kernel WG Update (TheCharlatan)
16:04:17 <TheCharlatan> Still looking for review on #31382 and hunting Approach ACKs on #30595
16:04:20 <corebot> https://github.com/bitcoin/bitcoin/issues/31382 | kernel: Flush in ChainstateManager destructor by TheCharlatan · Pull Request #31382 · bitcoin/bitcoin · GitHub
16:04:22 <corebot> https://github.com/bitcoin/bitcoin/issues/30595 | kernel: Introduce initial C header API by TheCharlatan · Pull Request #30595 · bitcoin/bitcoin · GitHub
16:04:29 <TheCharlatan> Floresta (the Rust Utreexo client) has started experimental integration of the library through its Rust wrapper: https://github.com/vinteumorg/Floresta/pull/456
16:04:43 <TheCharlatan> They reported a significant validation speedup with the new kernel API design over the old libbitcoinconsensus API
16:04:50 <laanwj> neat
16:04:50 <sipa> TheCharlatan: that seems exciting
16:04:52 <achow101> that's cool
16:05:26 <TheCharlatan> yes, very cool that they decided to go and experiment with already :)
16:05:34 <cfields> hi
16:05:43 <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.
16:05:45 <corebot> https://github.com/bitcoin/bitcoin/issues/32317 | kernel: Separate UTXO set access from validation functions by TheCharlatan · Pull Request #32317 · bitcoin/bitcoin · GitHub
16:06:02 <TheCharlatan> This is potentially useful for building things like non-assumevalid swiftsync and utreexo through a kernel API.
16:06:13 <cfields> 🚀
16:06:59 <TheCharlatan> that's all from me
16:07:16 <achow101> #topic MuSig2 WG Update (achow101, rkrux)
16:07:22 <achow101> Both #31243 and #31247 were merged. The remaining PRs have been rebased and updated.
16:07:27 <corebot> https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
16:07:30 <corebot> https://github.com/bitcoin/bitcoin/issues/31247 | psbt: MuSig2 Fields by achow101 · Pull Request #31247 · bitcoin/bitcoin · GitHub
16:07:33 <achow101> The current PRs to review are #31622 and #31244
16:07:38 <corebot> https://github.com/bitcoin/bitcoin/issues/31622 | psbt: add non-default sighash types to PSBTs and unify sighash type match checking by achow101 · Pull Request #31622 · bitcoin/bitcoin · GitHub
16:07:40 <corebot> https://github.com/bitcoin/bitcoin/issues/31244 | descriptors: MuSig2 by achow101 · Pull Request #31244 · bitcoin/bitcoin · GitHub
16:07:46 <achow101> #topic Legacy Wallet Removal WG Update (achow101, furszy)
16:07:54 <achow101> #31250 has been getting additional review and a few minor issues uncovered. I've addressed all remaining comments on it.
16:07:56 <corebot> https://github.com/bitcoin/bitcoin/issues/31250 | wallet: Disable creating and loading legacy wallets by achow101 · Pull Request #31250 · bitcoin/bitcoin · GitHub
16:07:59 <achow101> It's probably rfm
16:08:15 <achow101> #topic QML GUI WG Update (jarolrod, johnny9dev)
16:08:20 <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).
16:08:21 <corebot> https://github.com/bitcoin-core/gui-qml/issues/448 | Introduce Coin Selection page by johnny9 · Pull Request #448 · bitcoin-core/gui-qml · GitHub
16:08:27 <laanwj> yes seems rfm or very near
16:08:28 <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
16:08:36 <sipa> hi
16:08:55 <stickies-v> hi
16:09:26 <johnny9dev> thats all for gui-qml for this week
16:09:36 <achow101> #topic Script Validation WG Update (fjahr)
16:09:44 <fjahr> Nothing new to report as far as I’m aware. Still looking for approach feedback on #29491 and working on tests.
16:09:47 <corebot> https://github.com/bitcoin/bitcoin/issues/29491 | [EXPERIMENTAL] Schnorr batch verification for blocks by fjahr · Pull Request #29491 · bitcoin/bitcoin · GitHub
16:10:10 <achow101> #topic Cluster Mempool WG Update (sdaftuar, sipa)
16:11:00 <sipa> The next PR to review remains #31444, which has been getting some ACKs. Hopefully some more soon; it also had a review club yesterday.
16:11:02 <corebot> https://github.com/bitcoin/bitcoin/issues/31444 | cluster mempool: add txgraph diagrams/mining/eviction by sipa · Pull Request #31444 · bitcoin/bitcoin · GitHub
16:12:51 <sipa> On the research front, I've made two big posts on Delving, https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/68 and https://delvingbitcoin.org/t/how-to-linearize-your-cluster/303/73 with a summary of the differences between the 3 broad classes of linearization algorithms (old exponential, spanning forest based on the LP formulation from the Bitcoin Research Week, and the min-cut based
16:12:57 <sipa> one from the 1989 paper), and benchmarks for it.
16:13:18 <sipa> I'm planning to open a PR to implement the spanning-forest one in the next week or so.
16:13:35 <sipa> If you want to understand the justification, and trade-offs involved, please see the posts.
16:14:18 <sipa> That's it for me, unless there are any questions.
16:15:43 <achow101> #topic Move the repo to bitcoin-core github organization (achow101)
16:15:50 <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
16:15:50 <achow101> repo is necessarily a ban from both because it is a ban from the organization.
16:15:54 <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
16:15:54 <achow101> to discuss.
16:15:59 <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.
16:16:06 <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.
16:16:16 <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
16:16:16 <achow101> cannot be created after the transfer as that will break all of the redirects.
16:16:22 <achow101> If everyone is okay with this, I can do it right after the meeting.
16:16:30 <achow101> sorry for the wall of text
16:17:09 <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...
16:17:24 <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
16:17:30 <achow101> We recently moved libmultiprocess as well, from https://github.com/chaincodelabs/libmultiprocess which was moved to https://github.com/bitcoin-core/libmultiprocess
16:17:33 <glozow> Another solution is to move the bips repo somewhere else? iirc laanwj mentioned having an org already?
16:17:33 <fjahr> There are redirects and they have worked without issue
16:18:10 <darosior> I can attest that redirect still work for me on a project i moved 4 years ago, for what it's worth.
16:18:13 <laanwj> yes could move the bips repo as well, empty out "bitcoin" completely eventually
16:18:14 <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
16:18:15 <achow101> glozow: yes. I think moving both is preferable
16:18:43 <laanwj> (or maybe except for meta)
16:19:25 <laanwj> "libbase58" is also still in bitcoin i don't know what to do with that
16:19:42 <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.
16:19:43 <achow101> fanquake: tbh I don't think meta is actually for banned people to appeal their ban
16:19:57 <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.
16:19:58 <willcl-ark> What are the advantages of vacating bitcoin/bitcoin? My natural instinct would be to retain that and move bips/ out from bitcoin/?
16:20:17 <achow101> laanwj: I think libbase58 and libblkmaker can be archived
16:20:28 <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/.
16:20:55 <laanwj> achow101: agree
16:21:19 <sr_gi[m]> lightlike: +1
16:21:24 <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
16:21:31 <darosior> Leaving bips in bitcoin/ and having Core in bitcoin-core/ does make sense to me, although i haven't thought about drawbacks.
16:21:32 <glozow> if you ban someone from bitcoin-core org, aren't they unable to comment on bitcion-core/meta issues?
16:21:41 <achow101> glozow: yes
16:22:00 <sipa> Would the bitcoin org ownership be handed to the BIPs editors then?
16:22:01 <glozow> Oh i see now, you're saying that's a feature not a bug
16:22:03 <laanwj> yes the parallel member list was always an annoyance to maintain
16:22:06 <achow101> glozow: :)
16:22:08 <willcl-ark> achow101: I see, thanks.
16:22:29 <achow101> sipa: I guess so? I'd still prefer to also move bips out and we can sunset bitcoin/
16:22:33 <laanwj> sipa: no i don't think so, if they want an org they can have bitcoin-bips
16:22:43 <darosior> laanwj: +1
16:22:44 <fanquake> achow: then shouldn't oversight be changed in the moderation guidelines?
16:22:45 <sipa> +1 laanwj, i think that makes sense
16:22:55 <fanquake> How is someone meant to open an issue if they can't open an issue
16:23:08 <achow101> fanquake: they can also email
16:23:12 <cfields> achow101: I don't think we want to leave bitcoin/ in a state where it could be perceived as dormant/up for grabs.
16:23:18 <sipa> cfields: agreed
16:23:32 <fanquake> wait why are we sunsetting bitcoin/
16:23:35 <achow101> cfields: definitely not, it would still be owned by us(?), with a readme that says go somewhere else
16:23:47 <fanquake> why wouldn't bips exist there
16:23:50 <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
16:23:51 <sr_gi[m]> Why tho?
16:23:58 <willcl-ark> glozow: +1
16:24:03 <darosior> achow101: wait if you have a README you don't have the redirect anymore?
16:24:11 <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
16:24:15 <achow101> darosior: org level readme
16:24:18 <achow101> or another repo
16:24:19 <laanwj> glozow: right, we should keep admin there to make sure it's not used for anything else
16:24:20 <darosior> glozow: +1
16:24:46 <fanquake> sipa: then shouldn't we wait for them to have that discussion
16:24:53 <fanquake> why are we doing anything
16:24:56 <sipa> i think it's an independent decision
16:25:05 <fanquake> not really, because we'd have to enact it for them
16:25:12 <fanquake> none of them have admin permissions
16:25:17 <achow101> moving our repo can be done before they decide what to do with bips though
16:25:18 <sipa> yes, that's the point
16:25:26 <sipa> they can stay under bitcoin org, where we have ownership
16:25:36 <sipa> or decide to move somewhere where they do
16:25:37 <achow101> and we can maintain ownership of bitcoin/ in the meanwhile
16:25:48 <fanquake> seems odd that this is all happening because of moderation
16:25:50 <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.
16:25:52 <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
16:26:18 <achow101> fanquake: for me, it's not just about moderation, but that's what kickstarted this idea again
16:26:19 <darosior> fanquake: yeah agree, maintaining the list is sync, as well as separating Bitcoin vs Bitcoin Core, seem more compelling reason to me.
16:26:27 <achow101> i've had this thought for a while
16:27:23 <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
16:27:27 <willcl-ark> I'm not sure the benefit of having a single list less to sync, seems worth the risks
16:27:47 <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
16:28:17 <achow101> sipa: +1
16:28:43 <sipa> mostly for reasons of making real organisation structure match github repository structure
16:28:54 <darosior> Can we start bike-shedding the name of the repository in the bitcoin-core org then? :p
16:28:59 <achow101> we can wait for another week as lightlike suggests if anyone not present has opinions
16:29:15 <laanwj> yes, there isn't suddenly a hurry
16:29:25 <achow101> well, not anymore
16:29:37 <laanwj> right
16:30:08 <achow101> darosior: we can call it bitcoin-core :p
16:30:29 <laanwj> re: archiving libbase58, a "decide future direction of library" issue has been open since 2018 https://github.com/bitcoin/libbase58/issues/6 , no one has been stepping up
16:30:58 <laanwj> yes, the repo could be renamed too, i dont' think that will affect the redirect
16:31:11 <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)
16:31:31 <laanwj> yes, they could be synced, but why?
16:31:40 <achow101> willcl-ark: it's more about the fact that there are 2 invites, and not everyone remembers to accept both
16:31:45 <darosior> willcl-ark: are you ~0 on moving the repo?
16:32:24 <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
16:33:06 <TheCharlatan> that doesn't seem too anoying tbh
16:33:12 <glozow> why are people people
16:33:13 <achow101> TheCharlatan: you aren't the one dealing with it
16:33:13 <sipa> i feel that the difficulty of this synchronization is only a minor side-effect of a bad structure
16:33:18 <vasild> another possibility is to keep bitcoin/bitcoin as it is and move bitcoin-core/* into bitcoin/; move bitcoin/bips into another org
16:33:25 <laanwj> so is there any strong reason to not move the repo?
16:33:27 <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.
16:33:33 <sipa> darosior: _1
16:33:34 <sipa> +1
16:33:56 <achow101> vasild: I don't think we should do that, and I think it's better to separate Bitcoin Core from Bitcoin
16:33:56 <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
16:34:11 <laanwj> why does it make sense to keep it separate from the rest
16:34:22 <achow101> willcl-ark: could you give some examples of risks that you think there could be?
16:35:40 <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
16:35:46 <sipa> a standards organisation, or the other way around.
16:36:21 <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
16:36:46 <darosior> good point
16:36:47 <vasild> glozow: +1
16:37:16 <sipa> glozow: yeah, fair point
16:37:28 <achow101> glozow: we can give ownership to the bip editors too, and make bitcoin/ jointly owned
16:37:29 <cfields> glozow: so then what's left in bitcoin/ ?
16:37:33 <achow101> but I also prefer both move out
16:37:45 <sipa> i think the ideal solution is that both move, and bitcoin remains vestigial
16:37:52 <achow101> sipa: +1
16:37:56 <sipa> (and not up for grabs)
16:37:56 <glozow> cfields: I think it's fine if nothing remains
16:38:07 <laanwj> we need to keep sole ownership of bitcoin to make sure no one else creates a repo named bitcoin
16:38:17 <cfields> mmm, I don't love the idea of _just_ squatting on it.
16:38:23 <fjahr> There isn't a straightforward way to claim an unused org/username from github afaik
16:38:24 <darosior> achow101: i don't think this is a good idea for you all to give/share ownership of bitcoin/
16:38:34 <fanquake> fjahr: you just email GH
16:38:41 <fanquake> they'll git it up if it's unused
16:38:47 <sipa> ha, "git"
16:39:12 <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
16:39:12 <cfields> right, because of ^^
16:39:13 <laanwj> they won't give it up easily even if it's unused, i couldn't get bitcoincore back then
16:39:36 <fjahr> fanquake: I looked into this and for something unrelated and nobody seemed have success with that in forums
16:39:43 <fanquake> I have done it before
16:40:06 <achow101> presumably it's also much harder if there are owners of the org that are active elsewhere
16:40:15 <fanquake> Although this was 7-8 years ago
16:40:31 <darosior> Our project is so high profile and such a scammer magnet that i'm not sure i'd want to risk it
16:40:59 <sr_gi[m]> I still don't see what is the motivation for leaving bitcoin empty
16:41:12 <fjahr> faking activity is also easy but not sure worth the effort and better than moving bips
16:41:17 <achow101> sr_gi[m]: why should it be non-empty?
16:41:18 <sipa> sr_gi[m]: as opposed to what?
16:41:36 <sr_gi[m]> As opposed to keeping either bitcoin or bips on it
16:41:54 <sr_gi[m]> I see the motivation for separating both, but not why both need to go out
16:41:59 <darosior> sr_gi[m]: some of us are not comfortable with the current owners giving ownership away
16:42:24 <darosior> (if keeping bips repo)
16:42:24 <sipa> sr_gi[m]: who gets ownership after separation? either side would need to trust the other one not to break redirects
16:42:44 <lightlike> darosior: agree, especially after the experiences with the transifex coup last year
16:42:45 <sipa> not that i have any reason to distrust the current bips editors with that, to be clear
16:42:52 <sipa> but things change
16:43:05 <achow101> but the editors may change in the future, even to people who forget that the redirects exist
16:43:13 <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.
16:43:13 <achow101> (should bitcoin exist that long)
16:43:53 <vasild> so the only solution seems to be to move bitcoin/bips to another org and leave the rest as it is?
16:44:16 <achow101> they seem to have maintained redirects for a very long time now, don't see why they would stop doing that
16:44:31 <glozow> sometimes sites that have been around for a long time try to release old unused usernames
16:45:08 <laanwj> i mean the hope is that people will update their links, too, so the redirect will become less important over time
16:45:09 <achow101> i mean, Murch[m] tried to get the username murch from an inactive profile and was absolutely unable to
16:45:17 <dzxzg> who controls https://github.com/bitcoincore
16:45:40 <laanwj> dzxzg: https://github.com/aimeedonahue does
16:45:42 <achow101> dzxzg: probably the one person in https://github.com/orgs/BitcoinCore/people
16:45:49 <darosior> dzxzg: also this seems orthogonal
16:45:53 <sipa> glozow: i hear you - but it also just feels inappropriate that Bitcoin Core ended with the bitcoin/ org name, for historical reasons
16:46:06 <darosior> glozow: i think this is again a good point to bring up bitcoin.org
16:46:22 <sipa> we like the project to be easy to find, and be prominent, but it isn't Bitcoin
16:46:31 <laanwj> and no they don't want to give it away, nor does github want to release the org, though i haven't tried for a long time
16:46:41 <achow101> did you know about the https://github.com/bitcoin/Bitcoin.org redirect? that was moved a while ago too
16:47:14 <darosior> It seems like in theory it would be nice to move but in practice it would result in unnecessary risk?
16:47:29 <achow101> I think the risk is minimal
16:47:38 <laanwj> i think so too
16:47:45 <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
16:48:12 <achow101> I think there's a higher risk of an org owner accidentally breaking the redirect than github breaking it
16:48:29 <darosior> Alright, maybe we can mull it over for some time and continue discussions in a Github issue?
16:48:46 <achow101> I'll put it as a topic again for next week
16:49:08 <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
16:49:24 <achow101> Any other topics to discuss?
16:49:35 <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)
16:50:16 <laanwj> "bitcoincore" has been inactive since 2014 at least it's owned by a github staffer, it's not relevant here
16:50:35 <dzxzg> I see, sorry
16:50:38 <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...
16:51:38 <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
16:52:26 <laanwj> dzxzg: oh i see your point now, yes it's less of an issue if we rename the repo to bitcoin-core too
16:53:09 <achow101> also, if redirects do break, github support has re-established them in the past. I accidentally did this once with hwi.
16:53:35 <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. ;)
16:54:05 <laanwj> heh
16:54:11 <achow101> #endmeeting