abubakarsadiq has quit [Quit: Connection closed for inactivity]
joetor5 has quit [Quit: joetor5]
Guest92 has joined #bitcoin-core-dev
zeropoint has quit [Quit: leaving]
Chris_Stewart_5 has quit [Ping timeout: 260 seconds]
Guest22 has joined #bitcoin-core-dev
Chris_Stewart_5 has joined #bitcoin-core-dev
Satoshi has joined #bitcoin-core-dev
Satoshi has quit [Client Quit]
Guest22 has quit [Quit: Client closed]
Guest92 has quit [Quit: Client closed]
joetor5 has joined #bitcoin-core-dev
joetor5 has quit [Ping timeout: 248 seconds]
joetor5 has joined #bitcoin-core-dev
pyth has joined #bitcoin-core-dev
pyth has quit [Read error: Connection reset by peer]
pyth has joined #bitcoin-core-dev
pyth has quit [Ping timeout: 245 seconds]
pyth has joined #bitcoin-core-dev
adil has joined #bitcoin-core-dev
joetor5 has quit [Quit: joetor5]
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
neutrino777 has joined #bitcoin-core-dev
neutrino1 has quit [Ping timeout: 252 seconds]
kevkevin_ has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
adil has quit [Ping timeout: 248 seconds]
kevkevin has quit [Ping timeout: 248 seconds]
brunoerg has quit [Ping timeout: 248 seconds]
pablomartin4btc is now known as pablomartin
pablomartin has quit [Ping timeout: 244 seconds]
pablomartin has joined #bitcoin-core-dev
robszarka has joined #bitcoin-core-dev
szarka has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 252 seconds]
dunxen has joined #bitcoin-core-dev
dunxen has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-core-dev
gerle has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
adil has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
adil has quit [Quit: adil]
adil has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 248 seconds]
pyth has quit [Remote host closed the connection]
adil has quit [Quit: adil]
<bitcoin-git>
[bitcoin] laanwj opened pull request #32423: rpc: Undeprecate rpcuser/rpcpassword, store all credentials hashed in memory (master...2025-05-remove-rpcpassword-deprecation) https://github.com/bitcoin/bitcoin/pull/32423
<bitcoin-git>
[bitcoin] TheCharlatan opened pull request #32427: (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store (master...blocktreestore) https://github.com/bitcoin/bitcoin/pull/32427
<bitcoin-git>
bitcoin/master b645c52 Sjors Provoost: doc: recommend modern make for macOS depends
<bitcoin-git>
bitcoin/master 22cff32 Sjors Provoost: doc: recommend gmake for FreeBSD
<bitcoin-git>
[bitcoin] fanquake merged pull request #32086: Shuffle depends instructions and recommend modern make for macOS (master...2025/03/mc-make) https://github.com/bitcoin/bitcoin/pull/32086
<Sjors[m]>
We should probably clarify somehow in CONTRIBUTING.md that there is a moderation policy. Or to be more exact, any fork MAY have one.
<Sjors[m]>
Some people are interpreting the ten year old text under "Peer Review" to mean that anything goes.
<Sjors[m]>
I this text was designed with an audience in mind that wants to be helpful, not for adverserial or just chaotic situations.
<Sjors[m]>
Oh oops
Guest74 has joined #bitcoin-core-dev
Guest74 has quit [Client Quit]
Murch[m] has quit [Changing host]
Murch[m] has joined #bitcoin-core-dev
<Sjors[m]>
gmaxwell: I've had mixed experiences on Nostr. Though I've interacted with far fewer accounts, even the very unpleasant ones don't seem to be throwaways.
<Sjors[m]>
Murch: yes, but some people do write walls of text along with NACK.
<Sjors[m]>
Anyway, it's clearly not written by a lawyer. Can't believe people were nice back then :-)
<gmaxwell>
always remember that what policy you commit to is primarily a weapon others use against you, collaborators will collaborate. Trouble makers will bludgon you with whatever tool is available. :)
<gmaxwell>
There is an instinct when people get rude to get proscriptive, but you can't legislate having good intentions.
<Sjors[m]>
gmaxwell: agreed. It may be better to be accused of arbritary censorship than to have a stated policy be gamed. Pick your poison.
<Sjors[m]>
But we have these guidelines, so it seems reasonable to at least point to them from various places.
<gmaxwell>
Yeah I suppose. :P
Johan_ has joined #bitcoin-core-dev
<gmaxwell>
Sjors[m]: I think that document has caused a bit of confusion, like for example in one lawsuit Coinbase cited from it extensively as an explination as to why bitcoin is not controlled by 'bitcoin core developers', but I think that's a terrible example because the policy there doesn't actually really achieve that... particularly since anyone with control over the repo (ultimately MSFT) could
<gmaxwell>
just freely make that say whatever.
<gmaxwell>
I mean, it's a fine process, and you're right it should cite the relevant stuff so perhaps best to ignore my old-man tangents. :P
<gmaxwell>
Sjors[m]: re: accused of censorship, the solution to that is to make it clear that the repository isn't a public square. It's the workshop of the contributors. No one else is entitled to use it as a platform. Helpful contributions are welcome, no one knows everything. Without that, the effect is that anyone malicious that wants to spin up some socks or just foam up an angry mob can
<gmaxwell>
essentially silence the contributors by flooding them out or making things toxic.
<gmaxwell>
there are so many other venues, no one is censored because they don't get to stand on your desk with a megaphone. :P
<gmaxwell>
But when you agonize over kicking out people who can't control themselves or just give tiny little short blocks, you send the message that the repository is public property and that access to it is somehow integral to the freedom of bitcoin or something... and then every removal is a high crime.
<Sjors[m]>
gmaxwell: I indeed think that people assume the bitcoin repo is a public square, because Bitcoin Core is open source and there's been very little historical moderation on the repo.
<Sjors[m]>
But it's really a private space.
<gmaxwell>
Sjors[m]: open source doesn't equal public square either. I mean through the 90s into the early 2000s you contributed to most open source software by emailing the main author(s)/maintainer. Bigger projects had public lists, yes...
<Sjors[m]>
Right, the MIT license just says you can do whatever you want with the source. Not with the people who write it.
<gmaxwell>
so that's kind of a transisition with github, but it's also coincided with a *massive* decline in productivty in many OSS projects. (though I think that is more due to other factors, like post 2008 job market changes, and the rise of app stores making small scale commercial development theoretically more viable)
<gmaxwell>
Indeed. You could even look it like "we let you do anything you want with the code we write, so you can leave us alone!" :P
<gmaxwell>
Of course, there is a risk of being too insular, which could result in lower quality software, fewer new contributors, etc ... then ultimately people would run different software... but I think the project is ssooooooo far away from that it's not even funny. Of course, people will *accuse* it of being, but it's all just vibes, it gets said because its a default assumtion, because it's an
<gmaxwell>
insult to something the contributors clearly care about.
<Sjors[m]>
I sketched an alternative timeline today on Nostr where the current project disappears and the existing contributors work for various companies in the industry.
<Sjors[m]>
There wouldn't be a single canonical repo.
<Sjors[m]>
Patches would go via email and such.
<Sjors[m]>
I think that would be bad.
<Sjors[m]>
But nothing in the MIT license prevents it.
<Sjors[m]>
But I also agree the current drama is nowhere near bad enough to move us towards such a scenario.
<gmaxwell>
single canonical repo is a natural 'attractor' in the space of possible project configurations.
<Sjors[m]>
I'm not sure if that remains the case under sufficient attack pressure.
<Sjors[m]>
But that's just a wild guess.
<gmaxwell>
Sensible developers have no problem collaborating with others, including ones that they have reasonable disagreements with.. and phenominal time and effort is saved by combining resources.
<gmaxwell>
Sjors[m]: I mean certantly a repo can commit suicide by being inclusive of attackers to the point where it can't make good decisions or retain good contributors. But that's a choice (or a product of many choices, really)
<gmaxwell>
Even in places like where they made a big intentional deal of having multiple projects, like in bcash.. very quickly they only had one. (or at least only one that mattered)
<gmaxwell>
and I think this is true even without domain specific concerns like consensus rule consistency.
<Sjors[m]>
Right, in my scenario it was basically ossification due to breakdown of coordination.
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
<Sjors[m]>
But the more optimistic take may be that there's always going to be a new shelling point where there is one dominant central repo, because it's indeed a huge advantage.
<gmaxwell>
Yeah, so I think for example bitcoin core repo could be killed by inclusive policy (or by being too insular but thats the opposite direction of its current challenges in my view) or by some toxic central figure or etc. But the result is that there would be something else which would eventually gather up the biggest collection of people who *can* collaborate. .. and it would be the obvious
<gmaxwell>
thing to use.
<gmaxwell>
Sjors[m]: there is also a secondary order of this effect, which is because there is such a huge collaboration advantage you find that the alternative projects apart from the main collaboration almost always end up centered around people who have personality properties that make it hard for them to collaborate at all, which fundimentally limits them. And I'm not say that to diss any particular
<gmaxwell>
people in the Bitcoin-o-sphere... you see the same thing in other open source projects like the ffmpeg/libav split, or in other cryptocurrencies.
<gmaxwell>
(of course, "I can't get along with other people" isn't the only reason to maintain an alternative instead of collaborating... but it's a big one!)
<Sjors[m]>
gmaxwell: you see the same thing in party politics (in countries with more than two)
<Sjors[m]>
Someone splits off from a big party, gets 20 seats, has to then quickly find people, and the new party falls apart fighting within a year or so.
brunoerg has quit [Ping timeout: 260 seconds]
<Sjors[m]>
At least thanks to Guix it's now practical to maintain such a fork in manner that can be reasonably audited. If you have the discipline to stick to a small number of patches.
dzxzg has quit []
<gmaxwell>
Sjors[m]: interesting point re party politics! I think some of that is also a property of opposition: if you're the opposition to something there is pressure for you to be the opposite of the thing, and this is often not great because most aspects of most groups are more or less right.
<Sjors[m]>
gmaxwell: that's certainly a dynamic, but there are long lived political parties that occasionally are part of the coalition and do fine in that role.
<gmaxwell>
Sjors[m]: it was occuring to me that it would be nice if these "bitcoin node" devices were setup so you could just drop patches in a directory and it would apply them if it could, run the tests, tell you the status.. making it easier for less developer-savvy users to just run patches. Hopefully they don't *need* to but like hopefully they don't *need* to run a node either. :P
<gmaxwell>
a year and change ago a friend asked me for a patch so their node would only connect to v2 encrypted peers, I wrote one. it's been stable and cleanly applying for over a year. (I think I had to rebase it once right after creating it, but its been stable since).
brunoerg has joined #bitcoin-core-dev
<gmaxwell>
( I mean I think that should be an upstream option, at least for the outbound connections you make, but I asked a contributor and they told me that they felt it would create drama... but it's fine as a patch)
<gmaxwell>
yeah I mean, thats fine, but having to adopt a whole other thing carries with it a bunch of collateral changes and risks, overkill when a patch would do.
<gmaxwell>
It's like the beauty of an escalator vs and elevator. When an elevator breaks it's useless. When an escalator breaks it becomes stairs. To the extent that some users issue or need can be fixed by a little patch, it should be. And lots of users showing up saying "hey we really think you should take this patch, we've all been using it for two years and its great" is compelling.
dzxzg has joined #bitcoin-core-dev
<Sjors[m]>
Most people find a standing still escalator to be quite disorienting :-)
<gmaxwell>
Sjors[m]: it took some effort, but in responding to people on opreturn I resisted going and mining people's comments for arguments they made that opposed other changes in knots. In particular, I saw someone spamming about switching to knots that I reconized as having been very upset over the full rbf stuff.
<gmaxwell>
:D
<Sjors[m]>
Another thing that would be nice is if you can select a bunch of open pull requests and get a custom guix build for it.
<gmaxwell>
Yeah. I mean in general building is so easy once you have the prereqs installed I kind think interested powerusers should just compile for themselves... at least anyone already running it on a linux device. And nothing that can _run_ bitcoin core would be unable to compile it.
<gmaxwell>
But I agree getting builds would be nice, also because that process could run the tests, which too often doesn't happen when people build for themselves.
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 252 seconds]
Cory37 has quit [Quit: Client closed]
Cory37 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 276 seconds]
dzxzg has quit [Ping timeout: 252 seconds]
dzxzg2 has joined #bitcoin-core-dev
dzxzg2 has quit [Client Quit]
Talkless has quit [Quit: Konversation terminated!]