<bitcoin-git>
[bitcoin] fanquake opened pull request #32584: depends: hard-code necessary c(xx)flags rather than setting them per-host (master...depends_hard_code_flags) https://github.com/bitcoin/bitcoin/pull/32584
<bitcoin-git>
bitcoin/master 6b4bcc1 David Gumberg: random: Use modern Windows randomness functions
<bitcoin-git>
bitcoin/master 35bf3f8 merge-script: Merge bitcoin/bitcoin#32400: random: Use modern Windows randomness functio...
<bitcoin-git>
[bitcoin] fanquake merged pull request #32400: random: Use modern Windows randomness functions (master...5-1-25-winbcrypt) https://github.com/bitcoin/bitcoin/pull/32400
<gmaxwell_>
darn thats sad that arm continues to be such a circus of incompatible hardware. :(
gmaxwell_ is now known as gmaxwell
charlie_capt has quit [Quit: Client closed]
_flood has joined #bitcoin-core-dev
flooded has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] maflcko opened pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Read error: Connection reset by peer]
kevkevin has joined #bitcoin-core-dev
charlie_capt has joined #bitcoin-core-dev
charlie_capt has quit [Client Quit]
purpleKarrot has quit [Quit: purpleKarrot]
purpleKarrot has joined #bitcoin-core-dev
Cory80 has quit [Quit: Client closed]
Cory80 has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
u0_a268 has joined #bitcoin-core-dev
u0_a268 has quit [Read error: Connection reset by peer]
u0_a268 has joined #bitcoin-core-dev
u0_a2682 has quit [Ping timeout: 276 seconds]
u0_a2682 has joined #bitcoin-core-dev
u0_a268 has quit [Read error: Connection reset by peer]
u0_a2682 has quit [Read error: Connection reset by peer]
u0_a268 has joined #bitcoin-core-dev
u0_a2682 has joined #bitcoin-core-dev
u0_a2683 has joined #bitcoin-core-dev
u0_a2682 has quit [Read error: Connection reset by peer]
u0_a268 has quit [Read error: Connection reset by peer]
<bitcoin-git>
[bitcoin] i-am-yuvi opened pull request #32587: [WIP] test: Fix reorg patterns in mempool tests to use proper fork-based approach (master...2025-05-update_test_reorg_behaviour) https://github.com/bitcoin/bitcoin/pull/32587
<bitcoin-git>
[bitcoin] maflcko opened pull request #32588: util: Abort on failing CHECK_NONFATAL in debug builds (master...2505-abort-debug-check-nonfatal) https://github.com/bitcoin/bitcoin/pull/32588
u0_a268 has joined #bitcoin-core-dev
u0_a2682 has joined #bitcoin-core-dev
u0_a268 has quit [Read error: Connection reset by peer]
<achow101>
There are 2 preproposed meeting topics this week. Any last minute ones to add?
<furszy>
hi
<instagibbs>
hi
<Murch[m]>
Hi
<stickies-v>
hi
<jon_atack>
hi
<achow101>
#topic Kernel WG Update (TheCharlatan)
kevkevin has joined #bitcoin-core-dev
<purpleKarrot>
hi
<TheCharlatan>
We've been having more directional conversations on the role of the library within the project, whether it should include the mempool, and whether the library could eventually be split out into a separate repository.
Cory80 has quit [Quit: Client closed]
<TheCharlatan>
I'll try to have some demo repositories / draft PRs open about these topics over the next few weeks.
<glozow>
hi
Cory80 has joined #bitcoin-core-dev
<TheCharlatan>
Other than that, looking for review on #32317 and #31382.
<sipa>
I have also opened #32545, to replace the existing linearization algorithm with SFL (spanning forest linearization), a drop in replacement which apparently performs far better on hard clusters
<achow101>
The final PR, #29675, is fully rebased and up to date if anyone wants to test that out or if it will help with reviewing 31244.
<corebot>
https://github.com/bitcoin/bitcoin/issues/29675 | wallet: Be able to receive and spend inputs involving MuSig2 aggregate keys by achow101 · Pull Request #29675 · bitcoin/bitcoin · GitHub
<achow101>
#topic orphan resolution WG Update (glozow)
<glozow>
I've pushed to #31829 and it is ready for review. It includes the multi-index reimplementation and the new eviction strategies we discussed at coredev. I think it's fine as 1 PR, but open to ideas on reorganizing/splitting.
<corebot>
https://github.com/bitcoin/bitcoin/issues/31829 | p2p: improve TxOrphanage denial of service bounds and increase -maxorphantxs by glozow · Pull Request #31829 · bitcoin/bitcoin · GitHub
<sipa>
cool, will look
<glozow>
I talked to marcofleon today about adding a fuzzer for checking that 1p1cs always propagate regardless of spammy peers. But there are various tests etc on that PR as well
<glozow>
sipa: thanks!
Cory80 has quit [Quit: Client closed]
<glozow>
that's it from me
Cory80 has joined #bitcoin-core-dev
<achow101>
#topic QML GUI WG Update (jarolrod, johnny9dev)
<johnny9dev>
This week we onboarded a new contributor, goqusan. He will be helping implement the QML components in the wallet views. He's starting with the receive page and added QR encoding. bitcoin-core/gui-qml#454
<johnny9dev>
Christoph has been doing work on the Animations for the wallet and fixed the main transition easing with bitcoin-core/gui-qml#453
<johnny9dev>
For me, I implemented the initialization states for the WalletQmlController and added the first instance of the Skeleton loading animation that Christoph proposed last week. bitcoin-core/gui-qml#454
<johnny9dev>
This following week we'll be focused on getting bitcoin-core/gui-qml#450 mergable, implementing more of the Receive page, and adding input validation and error strings on to the Send page.
<sipa>
Does mingw-w64 building not work on Windows?
<fanquake>
You could just use that with the windows subsystem for linux yes
<hebasto>
from within WSL
<achow101>
but not natively with like cygwin or similar?
<fanquake>
I'd encourage devs to do that in any case, so they are actually testing what we are shipping to users
<hebasto>
we tested only MSVC native builds
<gmaxwell>
If it was good enough for Satoshi... ;)
<achow101>
#topic Statement on transaction relay policy (sipa)
<sipa>
Hi.
<cfields>
👋
<sipa>
I've written a short statement about the relation between Bitcoin Core developments and transaction relay policy, with the help of darosior and glozow
<sipa>
I think it would be useful to publish something like this, possibly on the bitcoincore.org website if enough people agree
<sipa>
but i'm open to hearing opinions
<darosior>
Ack.
<achow101>
will review
<gmaxwell>
I couldn't remember if the project had every blocked a widespread active use. The closest I could find is the dust limit stuff, but that seemed to go in after the penny dust had pretty much stopped AFAICT.
<gmaxwell>
s/every/ever/
<stickies-v>
very nice statement, will think of suggestions but ack for me too, thank you all for writing this up
<sipa>
So, what do people think... have a short period for comments, and then ask who would be willing to put their name under it?
<dzxzg>
"Within transaction relay, this may include adding policies for DoS protection and fee assessment, but not blocking relay of transactions that have sustained economic demand and reliably make it into blocks." I agree with this, but it seems to beg the question, how is demand weighed against DoS potential?
<sliv3r__>
nice statement
<sipa>
dzxzg: thankfully not a question i feel like we've had to answer yet, but a day may come
<instagibbs>
DoS here doesn't mean usage of blockspace you don't like, but cpu/memory/etc
<gmaxwell>
in any case, I think it's a very nice statement, and it feels very much in the tradition of the values I always understood coming from the project.
<sipa>
right, exactly
<instagibbs>
may be important to spell that out
<achow101>
sipa: maybe a week for comments, and next week we can discuss posting to the website and who wants to put their name on it?
<fanquake>
I'm not sure that having a list of names below is going to be beneficial, or is actually needed?
<darosior>
sipa: re what do people think, maybe open a PR on the website for comments?
<jon_atack>
fanquake: agree
Cory80 has quit [Quit: Client closed]
<jon_atack>
sipa: well done
<glozow>
I think this can be opened as a PR to the website
Cory80 has joined #bitcoin-core-dev
<TheCharlatan>
"> Note that this is not condoning non-financial data block space usage." this is what the issue seems to boil down to for users of Bitcoin Core, but I feel like this is not clear enough.
<sipa>
glozow: right now? that would make suggesting corrections easy
<abubakarsadiq>
nicely written, ack
<sipa>
TheCharlatan: happy to hear ideas on making it clearer, but i'm also weary of going into too much detail
<glozow>
sipa: I think so, given people are writing their comments here for specific lines. Perhaps worth doing this review process on the PR
<darosior>
I would say yes because i don't see how waiting before opening the PR to the website would help
<dzxzg>
instagibbs: Sure, whatever you take it to mean, the question would still stand. What if bare multisig outputs were to become popular? But I agree with sipa that maybe this question can be postponed for if/when it arrives
<fanquake>
(if nobody wants their name attached, would we post it anyway? I'd like to think yes, if it represents the software we are shipping)
<glozow>
dzxzg: I don't think bare multisig is a good example of DoS vs demand. Perhaps gigantic transacttions?
<gmaxwell>
dzxzg: those don't fall under the dos banner (uh except related to sigops limit?)
<instagibbs>
dzxzg bare multisig isn't a DoS (except for jank sigops counting), but sure if some new thing came up it would have to be weighed independently
<gmaxwell>
instagibbs++
<sliv3r__>
won't it end up an open PR like datacarriers' ones?
<gmaxwell>
dzxzg: DOS obviously means to me things like quadratic hashing.
<instagibbs>
like, if dust was being completely ignored (eep)
<sipa>
dzxzg: bare multisig is standard (up to 3 pubkeys), but even if bigger multisig were to become common, my personal opinion would be to relax the policy - it's not DoSy in any way, only (perhaps subjectively) dumb
<gmaxwell>
dzxzg: the closest to 'usage' I see DOS going might be dusting attacks. but generally I expect DOS to mean memory/algorithimic non-linearities.
<dzxzg>
I thought bare multisig had a DoS issue, my mistake.
<instagibbs>
block building gets annoying, as certain pools have found 😬
<gmaxwell>
sipa: except for sigop counting.
<darosior>
The question of DoS is interesting and i remember discussing it with some other contributors, but debating it now is off topic i think
<sipa>
ah, and bare multisig of course has higher UTXO set impact
<sipa>
that's perhaps a legitimate concern
<sipa>
yeah, seems a bit of tangent today
<achow101>
fanquake: I think the point of having individual names is because it should be perceived as a statement made with group support. possibly there are contributors who disagree with it and would not want their name to be on it, which would be less clear if there was not a list of names attached?
<gmaxwell>
sipa: because dumb consenssus rules count sigops in OUTPUTS...
<Murch[m]>
sipa: Especially due to its use for stamps and them getting spent at an uncommonly low rate
<gmaxwell>
I actually think clarifying dos would be nice and important, but it might not be possible.
<dzxzg>
Sure, I didn't mean to debate it, I was just sharing a question that I had reading the document, sorry for pushing off-topic
<instagibbs>
gmaxwell ++ yeah just saying
<stickies-v>
attaching names could be powerful but only if a large number of contributors are willing to do so, otherwise it could have the opposite effect
<gmaxwell>
The first three alternatives I considered were worse. "to address vulnerablities in the software or protocol" -- worse.
<fanquake>
achow101: right, but if you end up with, for example, 4 names, that'd be a weird thing to post
<sipa>
dzxzg: it is a good question, and i don't know the answer :)
<achow101>
and I do think that if no one wanted to put their name on it, we wouldn't post it to the website
<Murch[m]>
fanquake: I think there would be more than four names.
<glozow>
fwiw I don't think the goal of this post is to prescribe what policy is for, I think it's just a statement to clarify a general intention to remove certain kinds of policy and why
<instagibbs>
(or add)
<achow101>
fanquake: yeah, there's definitely a threshold
<stickies-v>
i'm supportive of adding my name, with the only caveat that we probably don't want to create too much precedent of having to sign off blog posts by contributors that support it
<Murch[m]>
Happy to sign, fwiw
<fanquake>
Murch: sure, but it's not clear what the threshhold is
<sipa>
stickies-v: there is precedent, though very rare, and quite long ago
<gmaxwell>
I hope there aren't significant contributors that disagree with this, if there are that should be hammered out (hammer mostly to be applied to contributor). :P
<achow101>
also, having names would allow other people not necessarily involved in the project be able to endorse it as well
<jon_atack>
re names, it could have consequences for those who add (naming and shaming) and for those who do not (didn't show support)
<darosior>
I am happy to put my name on it but i agree with fanquake that it's not necessary. This what the project has always done and published binaries implementing this vision, i think it's fine to have it spelled out without necessarily stating who agrees explicitly or not
<rkrux>
+1 for opening a PR - I'd review it, don't mind signing it
<fanquake>
gmaxwell: that's kind of why I think the names are redundant
<cfields>
achow101: I don't see anything I disagree with, but I also don't feel as though my signature adds any value here. I'm not sure individual names are necessary.
<gmaxwell>
achow101: maybe better to just have another thing where people can lodge their support.
<jon_atack>
omitting the names would avoid that
<fanquake>
if people didn't agree, we'd have a PR, with enough ACKs, to change the software
<fanquake>
and then the project would ship something different
<fanquake>
If that's not the case, then what we are shipping represents the views of the project
<cfields>
yeah, releases with policy changes don't come with statements/signatures :)
<fanquake>
so it seems like any statement on the website, can be from the project, collectively
<Murch[m]>
I’m also fine with presenting this as the view of the project
<stickies-v>
the only reason in this case i'd be supportive of adding names is that it seems some people have a perception of maintainers / some contributors being almighty, and adding names helps show that it's not just a cabal pushing this but has widespread support among contributors
<darosior>
fanquake: +1
<glozow>
I also don't know if signatures are worth putting - people who want to personally endorse it can post it on social media? I think this post can follow our typical governance process for things that go onto the website. If people are strongly opposed then maybe we can have a conversation about something more granular than on/off website.
<achow101>
stickies-v: yes, that
<stickies-v>
but agreed with fanquake that it absolutely shouldn't be necessary
<gmaxwell>
I can say that in the little contribution I've been doing in public outreach I'd like to be able to say that it went in without any opposition from the regular contributors.
<sipa>
i feel there is a bit of a philosophical difference, in that releases represent the contributors' agreement at this very moment, while a post like this is a longer-term vision - and it's good to recognize that it's still a vision of specific people, and the set of people can change over time
<cfields>
maybe fanning the flames, but something like this could potenially be PRd to Core as a guideline, and referenced/copied on the website for visibility.
<Murch[m]>
And the threshold thing cuts the opposite way. If a couple minor contributors disagree, would we still publish etc?
<gmaxwell>
cfields+1.
<gmaxwell>
Murch[m]: they can also be asked to leave.
<gmaxwell>
There is nothing wrong with people having a different vision!
<darosior>
sipa: people's vision change, i don't think why we should expect a blog post to reflect someone's future vision more so than a binary
<gmaxwell>
presumably if this understanding gets change the document should be amended/marked historical.
<lightlike>
gmaxwell: why would they be asked to leave - there is nothing wrong with people withing the project having a different vision imo
<glozow>
there can be a sentence saying "this only reflects the views of the *current* contributors" etc
rkrux has quit [Quit: Client closed]
<instagibbs>
If your work doesn't touch relay (most don't), I don't know why it would be an issue
rkrux has joined #bitcoin-core-dev
Christoph_ has quit [Quit: Christoph_]
<gmaxwell>
lightlike: sometimes, sometimes not! depends on their approach. e.g. having a different view is fine, but not if it's in the form of being obstructionist. Some people historically around the project have had difficulty with that.
<darosior>
lightlike: depends on the compatibility of their vision, the specific things they disagree with, etc.. It's a case by case basis and in any ways i think someone that disagree with everybody else would leave without needing to be asked
<gmaxwell>
hahaha
<sliv3r__>
glozow: that + the date I think would work
<gmaxwell>
but anyways, I apologize for starting a tangent.
<achow101>
the point of having names is to shape how people will perceive the post, and I think that having the names of people who have not been actively participating in the discussion would help bolster the point that it is actually an opinion of many people in the project, not something being "forced" onto the project
<achow101>
(and it seems highly likely that people not actively participating in the discussion would put their names on it, based on this discussion)
<Murch[m]>
darosior: If only ;)
<gmaxwell>
unfortunately most of the public has no idea who many people are, so unless you're gonna list them along side git blame LOC percentages...
<glozow>
I'm a little wary of enumerating the people that twitter should channel hatred towards
<jon_atack>
glozow: yep
<gmaxwell>
(As I learned when public comments where accusing me and bluematt of having no idea of how compactblocks works... :P )
<sipa>
gmaxwell: hahaha
<darosior>
I don't think having names is a good idea, but i also don't feel strongly. Whichever the author chooses.
<achow101>
I think it's also not a good assumption to expect people to understand how ACK/NACKs work with merging changes to both the software and the website
<sipa>
gmaxwell: i think you're right in that "being able to say that it went it without opposition from regular contributors" is important, perhaps more important than having actual names on it
<instagibbs>
names could also be on the PR via ACK, then not on website, halfway 🤷
<Murch[m]>
gmaxwell: To which you obviously replied "Do you have any idea who I am?"
<gmaxwell>
sipa: right I mean that's the point that I think would matter in my discussions.
<sipa>
ok, will open PR on website, without list of signatories for now, but can be discussed further there
<gmaxwell>
Murch[m]: I really try to not do that ever. holy crap. what a gross thing to do. I did one time say "don't you know who HE is" pointing at pieter, however. :P
<Murch[m]>
sorry, that was a joke about Charles Hoskinson
<sipa>
The first of his name.
<darosior>
lol
<gmaxwell>
oh really hah
<instagibbs>
Murch[m] oh you need metamask help??
<instagibbs>
dm me
<ajonas>
instagibbs: To better anticipate objections (if any), did you get pushback from your write up? Obviously not the same thing, but you were asked to do that for the group.
<instagibbs>
ajonas we didn't converge on a unified voice in our little group
<glozow>
I think we should review wording on the PR, not do signatures, aim to get a lot of (concept) ACKs, perhaps more than normal (text is easier than code review right?), and then merge when we have rough consensus. The people who ACK'd are supporting it in a public place, which imo is enough.
<cfields>
People will most definitely conflate the a signature on statement with an ACK to the policy changes btw. The former I feel qualified to do, but not the latter. I agree with the guiding principles laid out in the post, but lack the expertise to judge the specific changes. So I'm +1 for no names.
<instagibbs>
ajonas it's also possible I'm just weak willed and gave up early
<ajonas>
instagibbs: that's tracks
<gmaxwell>
so a problem you will face on the PR is that a lot of total randos will show up and throw mud at it unproductively.
<gmaxwell>
And then there will be false implications that the project didn't broadly support it.
<gmaxwell>
Sorry I don't have a solution, but I almost guarentee this will happen.
<darosior>
Agree with what glozow suggests
<achow101>
gmaxwell: put a comment at the top "if you don't contribute to this project, your comment will be deleted"
<sipa>
gmaxwell: sgtm
<sipa>
eh
<sipa>
glozow: sgtm
<gmaxwell>
can you limit a PR to project members? (obviously contributors are wider...)
<glozow>
perhaps unpopular opinion, but maybe the website repo should have stricter contribution requirements than the bitcoin/bitcoin repo
<glozow>
achow101: yeah or that
<achow101>
there is a roundabout way to make conversation locking let contributors comment, but it requires giving everyone write access
<gmaxwell>
glozow: historically website has had some good help from people who aren't developers, though I agree with that view.
<gmaxwell>
ugh, damn github.
<achow101>
for the website, I think that's probably fine though since deploying the site has several extra steps that happen off github
<glozow>
gmaxwell: yeah agree. but I think it's perfectly reasonable that this particular PR only seeks input from regular contributors
<glozow>
seek*
<Murch[m]>
And just like predicted, the brigading now lead to development channels becoming more permissioned :p
<achow101>
we can also turn on the "have contributed to this repo before" limit, but that actually probably excludes many regular contributors
<sliv3r__>
what about the statement without names + pgp signatures?
<gmaxwell>
glozow: yes exactly. It's their statement not anyone elses. supportive comments (like mine!) I hope are welcome but could be channeled via recent contributors.
<achow101>
sliv3r__: that's the same thing, but with more friction?
<Murch[m]>
sliv3r__: That’s just extra work on the person that writes the scathing investigative breaking news Twitter article :p
<glozow>
Murch[m]: I get what you're saying and generally agree, but this post isn't development at all. It's contributors agreeing on wording!
<Murch[m]>
glozow: Fair enough
<Murch[m]>
Also, I think it would be easier to lock it to contributors than to delete non-contributors
<fanquake>
I've found the setting that should limit the interaction to people in the frequent contribs group
<Murch[m]>
Maybe "easier" is the wrong word, but less abrasive
<fanquake>
Don't think we need to hand out write access
<achow101>
fanquake: which setting?
<gmaxwell>
The delete has some bad effects which I can discuss later cause its a total tangent.
<gmaxwell>
sipa: authors could also just offer to forward on any comments from contributors that have issues getting to the repo.
<achow101>
fanquake: oh, limit to prior contributors does include org members, so I guess that would be fine too
<fanquake>
achow101: we should be able to restrict to collaborators, where collaborators are in frequent contributors
<jon_atack>
achow101: can the meeting header line about #here be dropped
<achow101>
fanquake: try again with the team removed, I think it'll still work
<achow101>
jon_atack: not really
<jon_atack>
unclear if we should be joining meetings with "hi" or #here
<jon_atack>
ok
bitdex has joined #bitcoin-core-dev
<achow101>
it doesn't matter, both will be counted as participants
<fanquake>
achow101: yea looks like non-org accounts are still limited, so this should work for what we want to do
<fanquake>
If needed
<glozow>
As a regular reminder: if you feel you should/shouldn't be on the frequent contributors list, please message a maintainer. There is no formal process or cadence / nobody is purposefully excluding people. Sometimes it's just been a while.
<achow101>
jon_atack: it's https://github.com/pronovic/hcoop-meetbot if you want to submit a pr to them, or find the right configuration options for me to set to the turn it off. but afaik, i can't
<sipa>
achow101: woah, i always assumed it was entirely custom
<achow101>
sipa: that's way too much effort :p
<sipa>
achow101: says the person who reimplemented all of apple's executable signing logic?
<achow101>
lol
zeropoint has joined #bitcoin-core-dev
<Murch[m]>
gmaxwell: So, your point was that deleting people’s comments would allow them to collect a "victim badge" whereas not letting them post in the first place doesn’t give people access to playing such games?
Emc99 has quit [Quit: Client closed]
<jon_atack>
achow101: ok
<achow101>
fanquake: I think we should leave turn the interaction limit on when the pr is open, i'd rather preempt the brigading rather than turning it on after the fact
hensou has joined #bitcoin-core-dev
<stickies-v>
hebasto: i upvoted all the unresolved MSVC issues
<fanquake>
Yea I don't mind. We can turn it on at that point
<bitcoin-git>
bitcoin/master 4c8c90b Cory Fields: validation: only create a CCheckQueueControl if it's actually going to be ...
<bitcoin-git>
bitcoin/master c3b0e6c Cory Fields: validation: make CCheckQueueControl's CCheckQueue non-optional
<bitcoin-git>
[bitcoin] fanquake merged pull request #32467: checkqueue: make the queue non-optional for CCheckQueueControl and drop legacy locking macro usage (master...checkqueue_control_mandatory) https://github.com/bitcoin/bitcoin/pull/32467
<bitcoin-git>
[bitcoin] fanquake merged pull request #32586: ci: Downgrade DEBUG=1 to -D_GLIBCXX_ASSERTIONS in centos task (master...2505-ci-centos-debug) https://github.com/bitcoin/bitcoin/pull/32586
<gmaxwell>
lightlike: to clarify the 'asked to leave' comment from earlier. In watching PRs and bitcoin related traffic on social media, I've seen repeated participation from people who are overtly hostile to the project, it's activities, and contributors... including stuff that would get them immediately ejected from any professional enviroment. And while constructive criticism about proposals is
<gmaxwell>
essential, someone who just hates the project has no business being on the repository at all. That's just not want it's for, its for the project to develop the projects software. So I was referring to that stuff, just just someone minding their business in GUI strings or what not.
<hebasto>
stickies-v: thanks!
Talkless has joined #bitcoin-core-dev
<gmaxwell>
I would hope some earnest niche contributor could agree that the resulting document is the position of _the project_ if it's not their own.
dzxzg has quit []
Christoph_ has joined #bitcoin-core-dev
<lightlike>
gmaxwell: yes, i don't disagree with that. Though it should be possible for contributors to have fundamentally opposing views wrt one area such as policy (and be vocal about that, without fear of being asked to leave) - as long as they accept it if they don't get their way in the end and don't have that same problem in other areas.
<gmaxwell>
::nods:: that's why I thought it was useful to clarify what I was referring to.
<gmaxwell>
The underlying principle I, personally, would keep in mind is that the repository exists so that its significant contributors can collaborate and produce the best bitcoin software they can. It does not exist to be fair, inclusive, friendly, to anyone -- except to the (very significant!) extent that those things help to produce good bitcoin software.
<gmaxwell>
and this is my view because simply if it doesn't work that way it will be replaced with something that does. Exactly like this IRC channel, which functionally replaced #bitcoin-dev, because the other wasn't maintained in a way that preserved the participation of the major participants.
<gmaxwell>
(and I'd recommend the fictional novel "Walkaway" by Cory Doctorow, in spite of my general reservations about his writing, for its musing on the social structures surrounding truly voluntary efforts and collaborations)
<gmaxwell>
Murch[m]: right. like encountering a closed door might make you sad, but being heaved out the door makes some people feel humilitated and turns them into long term enemies even when it should have been totally expected.
hensou has joined #bitcoin-core-dev
<lightlike>
gmaxwell: that is certainly what open source projects in general should default to - but even if in theory everyone can run their own software, in practice bitcoin core is still the de-facto reference implementation, which makes it a bit unique. As long as most other node impls are not serious alternatives I'd argue that implies at least some additional responsibilities other projects don't have - only up to some point though (e.g. we
<lightlike>
certainly should not merge things we think are harmful even if everyone else wants them), and it's not clear to me where that point should be.
<gmaxwell>
I think I feel somewhat the opposite, the whole point of bitcoin is defeated if other people control your usage. So trying to act like a pseudogovernment isn't in Bitcoin's interest, as some people will mistake the pomp and circumstance of power with actual power that should not and must not exist.
<gmaxwell>
I mean obviously there is no point in doing it if people don't actually want to run the result (and development in the project wouldn't continue if people stopped using it-- if people didn't want to work on an impactful system they wouldn't be here, it's so much harder than something inconsequential)
<bitcoin-git>
[bitcoin] theuni opened pull request #32592: threading: remove ancient CRITICAL_SECTION macros (master...remove-critsect) https://github.com/bitcoin/bitcoin/pull/32592
hensou has quit [Ping timeout: 276 seconds]
<gmaxwell>
So I agree to you to at least that extent. But I've absolutely seen it go wrong, including e.g. one coinbase filing in litigation explaining that bitcoin was decenteralized because anyone can make a pull request. ... and I don't really blame coinbase, it's easy to see how the very elaborate pesudogovernmental procedures in the project got mistaken for the origin of Bitcoin's properties.
<gmaxwell>
So at least for that specific purpose, it would have been better if contributing.md just said "Stuff goes in here if Achow likes it, you can use this repo if you like it, otherwise take a hike" :P ... cause if coinbases lawyers saw that they'd go okay obviously *this* isn't where bitcoin's properties arise. And instead would have made the case that no one controls the software users run and in
<gmaxwell>
fact significant effort has gone into preserving/amplifying that power.
<gmaxwell>
lightlike: re serious alternatives: the code the user is running *right now* is a serious alternative to a future release. A future release with whatever adverse change backed out is a serious alternative -- even a moderately technical user can now reverse apply a diff and build bitcoin core with the help of an LLM. :) And of course people will make alternatives. And especially if the issue
<gmaxwell>
of concern is substantive the alternatives will be competent.
<gmaxwell>
The fact that the current alternatives aren't so impressive is just a product that they are driven by their own motivations that don't have much/anything to do with specific bad choices in bitcoin core.
<gmaxwell>
one of the few positive oppturnities in this recent turmoil I think is an chance for people to learn to apply a diff and run a patched copy. That's a skill that any serious bitcoin power user ought to have. and while (IMO) completely unjustified for the current issue, it's exactly what people might need to do in the face of an adverse change.
<darosior>
Lol at the pull request comment. Really hits home, interacted with so many confused people fetishizing them.
<gmaxwell>
'cause at the day it's not the developers being great people that protects bitcoin (thoug they are!) -- great people can still have guns held to their heads (figuritively or litterally!) or can go crazy.
<gmaxwell>
darosior: yeah they actually copied in most of contributing.md ...
reasonableD00F has joined #bitcoin-core-dev
reasonableD00F has quit [Client Quit]
<gmaxwell>
I dunno how to manage it though because all this openness and inclusiveness are fantastic tools for making good software, and also important to people's good feelings towards the project. But they just simply can't be where Bitcoin's security comes from.
reasonableD00F has joined #bitcoin-core-dev
reasonableD00F has quit [Client Quit]
hensou has joined #bitcoin-core-dev
<gmaxwell>
in BCH which has a far smaller and less resourced community, the main development group decided to add code to direct a portion of mining rewards to a development fund-- a decision they were commited to. And they were entirely replaced, by a new project that didn't exist before then. (There were other implementations, but they were mostly 1/2 person projects like the alternative
<gmaxwell>
implementations in Bitcoin today, the thing that replaced the BCH 'reference implementation' was created in response to the adverse change)
<gmaxwell>
so I'm entirely not worried about that. I worry more about stuff like the project becoming a zombie, like-- failing to implode when it ought to. :)
<cfields>
jeremyrubin: do you remember why the cuckoocache requires an external lock rather than just using an internal mutex? I'm guessing because not all of the functions require locking?
<cfields>
nm, found a github comment.
hensou has quit [Ping timeout: 248 seconds]
Guest10 has joined #bitcoin-core-dev
Guest10 has quit [Client Quit]
kevkevin has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
<sipa>
darosior: which pull request comment?
<gmaxwell>
my comment about coinbase attributing bitcoin's decenteralization to anyone being able to open a pull request.
<sipa>
ah yes ok, i thought darosior was commenting about a specific PR being mentioned that i missed
<gmaxwell>
I thought that too for a moment.
cold has quit [Ping timeout: 260 seconds]
midnight has quit [Ping timeout: 276 seconds]
cold has joined #bitcoin-core-dev
midnight has joined #bitcoin-core-dev
hensou has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
midnight has quit [Ping timeout: 244 seconds]
cold has quit [Ping timeout: 272 seconds]
bugs_ has quit [Quit: Leaving]
midnight has joined #bitcoin-core-dev
cold has joined #bitcoin-core-dev
ghost43_ has joined #bitcoin-core-dev
ghost43 has quit [Ping timeout: 264 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
abubakarsadiq has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] achow101 opened pull request #32593: wallet, rpc: Move (Un)LockCoin WalletBatch creation out of RPC (master...improve-lockcoin-interface) https://github.com/bitcoin/bitcoin/pull/32593
hensou has quit [Ping timeout: 272 seconds]
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
<bitcoin-git>
[bitcoin] theStack opened pull request #32596: wallet, rpc, doc: various legacy wallet removal cleanups in RPCs (master...2025-wallet-rpc-related_legacy_wallet_cleanups) https://github.com/bitcoin/bitcoin/pull/32596
sliv3r__ has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
Cory80 has quit [Quit: Client closed]
Cory80 has joined #bitcoin-core-dev
sliv3r__ has joined #bitcoin-core-dev
<Earnestly>
(It's interesting to me that during this topic discussion there was total agreement, there were no dissenting voices despite so much contention (I've been reading more about it).)
<w473rm3l0n>
sipa: re: relay_policy.md, I agree with everything written in the gist. Although it doesn't contain anything new that users haven't already read several times. The only thing that makes it different is that it would be on the core website and likely posted by core's X account.
<w473rm3l0n>
Another factor that could set it apart is if it's signed by developers who are respected in the community and avoid controversies, drama etc.
<w473rm3l0n>
Restricting the pull request will only add fuel to the fire. Instead, changes can be suggested in the gist. A pull request can then be opened and merged with some ACKs from regular contributors.
<w473rm3l0n>
I don't think any such post will make a difference, because some people are unhappy with the way bitcoin core development works and their concerns or perception go beyond just OP_RETURN.
<Earnestly>
That is my perception too, OP_RETURN appears to be the last few straws
<Earnestly>
The gist covers 3 main points, which many people have already seen, discussed, refuted/challenged, etc. The gist doesn't really add anything new
<Earnestly>
(I.e. 1) fee estimation, 2) block prop, 3) avoiding miners using dark pools)
w473rm3l0n79 has joined #bitcoin-core-dev
w473rm3l0n79 has quit [Client Quit]
<Earnestly>
From my brief reading of the situation many of the anti-core voices largely think exactly what the gist contains; they don't think core is malicous (some do, ignore) but misguided. Ultimately what I personally think they want is core to /signal/ an anti-spam stance, which core likely does not want to do
<Earnestly>
The logic being that a signal will have a social effect on vc funding of spam activity, preventing them from becoming self-sustaining
<Earnestly>
(Also I'd suggest dropping the language of "brigading", and the pathologysing of users who have grievances, here and elsewhere too. People do see it.)