<bitcoin-git>
[bitcoin] maflcko opened pull request #32507: ci: Exclude failing wallet_reorgsrestore.py from valgrind task for now (master...2505-ci-valgrind) https://github.com/bitcoin/bitcoin/pull/32507
<bitcoin-git>
[bitcoin] darosior closed pull request #32117: qa: make feature_assumeutxo.py test more robust (master...2503_more_assumeutxo_test_unbrittling) https://github.com/bitcoin/bitcoin/pull/32117
<bitcoin-git>
[bitcoin] m3dwards opened pull request #32513: ci: remove 3rd party js from windows dll gha job (master...250515-remove-js-ci) https://github.com/bitcoin/bitcoin/pull/32513
saturday- has joined #bitcoin-core-dev
Saturday7 has quit [Ping timeout: 260 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
<bitcoin-git>
[bitcoin] maflcko opened pull request #32514: scripted-diff: Remove unused leading newline in RPC docs (master...2505-rpc-newline) https://github.com/bitcoin/bitcoin/pull/32514
<instagibbs>
Any reason MiniWallet shouldn't be picking up all the newly generated block coinbase outputs in tests? It's starting with 49 outputs, no more can be added, they can be consumed, then more can be added later, up to 49 on rescan?
<instagibbs>
looks like it's stuck at the same 49 actually
gerle has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
zeropoint has joined #bitcoin-core-dev
fearbeag has quit [Read error: Connection reset by peer]
bob_x1 has quit [Ping timeout: 252 seconds]
bob_x1 has joined #bitcoin-core-dev
jespada has quit [Ping timeout: 276 seconds]
synexic has quit [Ping timeout: 272 seconds]
dviola has quit [Ping timeout: 248 seconds]
synexic has joined #bitcoin-core-dev
diego has joined #bitcoin-core-dev
diego has left #bitcoin-core-dev [#bitcoin-core-dev]
<darosior>
#proposedmeetingtopic communication about Core's vision for relay policy from current contributors (1000 feet view executive summary, not the specific recent drama)
<achow101>
#startmeeting
<corebot>
achow101: Meeting started at 2025-05-15T16:00+0000
<TheCharlatan>
I also discussed some future optimizations that this might enable today, e.g. reducing the scope of cs_main, running block validation in parallel.
<furszy>
hi
<TheCharlatan>
#32427 has already received a bunch of conceptual feedback, thanks for that!
<corebot>
https://github.com/bitcoin/bitcoin/issues/32427 | (RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store by TheCharlatan · Pull Request #32427 · bitcoin/bitcoin · GitHub
rkrux has joined #bitcoin-core-dev
<TheCharlatan>
I'd be interested in hearing some more opinions on if this could allow us to get rid of much of the reindexing logic
<rkrux>
hi
<TheCharlatan>
though some have raised concerns in the PR already that reindexing also encompasses recovering from block file corruption.
<laanwj>
hi
<TheCharlatan>
that's all for today
<achow101>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<sipa>
31444 got merged (yay!), #31553 is next to review
<sipa>
That's unfortunate, though I don't think it has much practical impact - it's still far better than what we have, and logistically much more useful than the 1989 paper algorithm.
<sipa>
So my thinking remains to in the near future work on replacing the current algorithm with that.
<Murch[m]>
What is the practical implication of that?
<sipa>
To clarify: it's a randomized algorithm, and the "no progress" possibility boils down to forever making terrible choices, it doesn't mean an inability to make progress.
<abubakarsadiq>
hi
<Murch[m]>
Would that mean that some clusters just never get linearized or just that some cycles would be wasted?
<Murch[m]>
Okay
<sipa>
In all examples found, there is something like a 50-80% chance of making progress anyway, whenever you're in such a (very rare) potential-not-making progress state.
<sipa>
But of course, there may exist examples for which the situation is worse.
<sipa>
50-80% chance per step
<sipa>
That's it for me.
<achow101>
#topic MuSig2 WG Update (achow101, rkrux)
<achow101>
Been addressing review and rebasing #31622
<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
<achow101>
PRs to review are still #31622 and #31244
<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
<fanquake>
johnny9dev: is the qml branch going to be rebased onto master at some point? I'd have assumed you'd want cmake + qt6 now that it's available
<johnny9dev>
Thats the current thought
<Murch[m]>
johnny9dev: I was a bit surprised at the sparse information in the coin control table, it looks like it is just amount and address. Is this going to be extended or is this the intended final state?
<hebasto>
it makes more sense after restoring Android builds
<johnny9dev>
I haven't had much slack time to experiment but I am very curious still about alternative deployments that have been discussed
<pinheadmz>
fanquake: I am working on that rebase
<pinheadmz>
(For fun!)
<pinheadmz>
400 commits and hundreds of conflicts. Mostly multiprocess interface and build system
<sipa>
pinheadmz: i'm impressed, can i ask what sort of thing you would consider not fun?
<pinheadmz>
Changing diapers ?
<pinheadmz>
Anyway. Once rebase is done idk what to do with it (force push to qml master?)
<sipa>
pinheadmz: are you trying to maintain the commit history? i can imagine that squashing parts or even all of it would make this a lot easier
<Murch[m]>
ah, was gonna say that it seems unrelated
<Murch[m]>
Thanks, I’ll take a look
<pinheadmz>
I think ideally qmlgui ends up with bitcoin/bitcoin as a git sub module
<pinheadmz>
Or muktiprocess something something
<johnny9dev>
I agree with that
<hebasto>
^^ as pointed by darosior
<TheCharlatan>
abubakarsadiq, marcofleon has written a differential fuzz test for the PR. Further testing would also be appreciated, what did you have in mind?
<achow101>
#topic communication about Core's vision for relay policy from current contributors (darosior)
<darosior>
Hi everyone. My proposal for the OP_RETURN standardness rule change has been severely mischaracterized online. This has led to genuine concerns from Bitcoin enthusiasts about the change itself, but also about Bitcoin Core. I do not think there is any ground for these concerns, but what is done is done. From my experience engaging with the community
<darosior>
in the past weeks i think we should hold off the change for some time (if it's gonna be merged doesn't matter if it is now or in 2 weeks) and work on our communication. To this end i suggest we post on the website a broad view of how Bitcoin Core approaches relay policy, to be signed off by people working in this area of the codebase. It should be
<darosior>
short, in the form of an executive summary. I think it would go a long way for people who heard about the drama but cannot afford to spend time digging on Github or the mailing list and interpret our technical discussions.
<achow101>
similar to what instagibbs tried to write up last week?
<darosior>
No
<achow101>
or more generic?
<darosior>
instagibbs' writeup was specific and technical, so much that it just confused people who aren't already familiar
<Murch[m]>
It sounds like it would be more about the goals and approaches, not the concrete case
<darosior>
Yes exactly
cfields has joined #bitcoin-core-dev
<cfields>
hi... ircd troubles.
<darosior>
cfields: got the logs?
<sipa>
I'm generally supportive of putting some statement on the website to have something to point people to, though obviously it'll depend on the content.
<achow101>
sipa: +1
<achow101>
darosior: do you have a draft to share?
<darosior>
I don't i wanted to take the temperature first
<cfields>
darosior: no, I'll catch up from context and read logs later. thanks though.
<abubakarsadiq>
@thecharlatan: I remember using py-bitcoinkernel for my mining research https://github.com/ismaelsadeeq/mining-analysis and it's a bit annoying I have to shutdown my bitcoind, so I am thinking whether it is at the stage I can reproduce try reproducing the research without shutting down bitcoind and halting other node activities I am running.
<Murch[m]>
Having spent a bunch of time discussing online in the past couple weeks, I do think that we should talk less about the nuanced trade-offs and more about what our priorities are
<sipa>
TheCharlatan, abubakarsadiq: stick to topic, please?
<willcl-ark>
hi
<Murch[m]>
Trying to convey the finer details exacerbated the amount of follow-up questions and results in finer grained misconceptions that take even more time to address. darosior’s idea sounds good to me.
<sipa>
It's a bit of a challenge I think to do this, as Bitcoin Core contributors are an ill-defined group and I think few people are comfortable speaking for others. But I can imagine a statement from some maintainers/regular contributors of the form "We believe many contributors feel the goal of relay/mempool/... should be", so rather than "Bitcoin Core believes X should happen", it is an observation
<sipa>
about current contributors' views
<darosior>
That sounds good to me
Guest66 has joined #bitcoin-core-dev
<achow101>
yeah, i'd prefer to have it be a statement from the contributors who sign off on it, rather than a statement from the project
<fanquake>
How many signatures do you need for it to be viable for the website?
<darosior>
i think we should be able to make statements from the problem, but this is a different discussion. A letter signed off by contributors in this area relayed on the website sounds good to me
<Murch[m]>
achow101, sipa: Would such a personal statement still be published on bitcoincore.org?
<darosior>
*from the project, sorry, not problem
<darosior>
I think a short explainer of why the binaries released by the project on the website are the way they are has absolutely its place on the website...
<achow101>
Murch[m]: depends on the content, and if enough people sign it?
<darosior>
I don't think it's the number of the signatures that matter, but who signs it
rkrux has quit [Quit: Client closed]
<stickies-v>
if there's enough consensus (among core devs) to merge it, there should be enough consensus to put a website post up
<sipa>
Hmm, I think I'm not getting my suggestion across well. I don't mean at all a personal statement by some/many people, individually signed by all.
<darosior>
stickies-v: exactly
<achow101>
darosior: sure, but we also don't want it to be perceived as a small group of people setting the direction of the project
<fanquake>
sipa: yea I think I'm missing the difference between "We believe many contributors feel" & "Bitcoin Core believes X",
<pinheadmz>
why imply anything? why wouldnt it be "we the undersigned believe..." ?
<darosior>
achow101: the set of people that would make such a change a reality (by signing off the PR) is not large. That's just the reality
<sipa>
fanquake: well for one it doesn't need to claim to be inclusive of all views
<sipa>
but yeah, maybe there isn't that much of a difference
<fanquake>
Sure. I guess in my mind, the view of the project is what we are shipping in the binaries
<darosior>
fanquake: +1
<stickies-v>
exactly this. if we ship based on rough consensus, we should be able to blog post based on rough consensus
<TheCharlatan>
there could be a difference between what is shipped, and what people believe the direction of policy over the next few years should be.
<willcl-ark>
So would this be an educational post, something like the compact blocks FAQ? Or more of a report, or just a "we the undersigned agree x" type of thing?
<darosior>
TheCharlatan: yeah i think there is a true distinction between what is and what should be in the future. That's up for debate too in my opinion, but here i am suggesting we do the former
<stickies-v>
sure, but 32406 specifically includes direction of policy by changing a default and deprecating the option, right?
<darosior>
heh, true
<sipa>
but even deprecation is not a promise, just an intent
<sipa>
and as contributors and their views change, intent can change
<instagibbs>
sipa +1
<darosior>
willcl-ark: something akin to "what we've been up to, and why"
<sipa>
darosior: i like that
<achow101>
I think I'll have more/stronger opinions once there's something to review
<darosior>
achow101: yeah, let me come up with a draft and we can reassess
<achow101>
it's too early for abstract thought :p
<sipa>
abubakarsadiq: wow, blast from the past :p
<darosior>
By the way i think it would be nice if we published more PSAs about what we've been up to. But this one is most important now because of the recent controversy
<stickies-v>
thank you for all your public work on this darosior (and others)
<darosior>
stickies-v: thanks for the thanks, and sorry to have triggered this in the first place
<darosior>
(although it was just unveiling resentment that was already there)
<bitcoin-git>
[bitcoin] maflcko opened pull request #32519: ci: Enable feature_init and wallet_reorgsrestore in valgrind task (master...2505-ci-valgrind) https://github.com/bitcoin/bitcoin/pull/32519
<achow101>
Any other topics to discuss?
<sipa>
darosior: *pew* (the sound of people shotting the messenger)
<darosior>
lol
<cfields>
I'm not sure what we're trying to accomplish here. My understanding is that the hate isn't coming so much from the change itself so much as the perception of how decisions are made and priorities are set. I'm not sure that "this is why we're doing X" is a constructive response to that?
<Murch[m]>
Aye, I think we should generally think a bit more about public communication, and even how we support users of Bitcoin Core
<darosior>
cfields: a decent part of misunderstanding is also coming from the change
<darosior>
Murch[m]: i agree, topic for the next Coredev? Also happy to discuss it during an IRC meeting
<glozow>
Light concept ACK to "here's the north star / what we've been doing and why." Also agree that perhaps communication about how decisions are made might be even more important
<Murch[m]>
I’ve been told by several people in the past couple months that they wish there were a way to contact Bitcoin Core if one had questions or support issues, and others have recommended that we might find a couple contributors that do public relations or developer advocacy in some form.
<stickies-v>
cfields: I was starting to type a similar response too, i think a lot of people have already heard a lot of the reasoning, but just fundamentally believe we / contributors / maintainers are evil or compromised and should not be trusted, and more reasoning may not convince them
<Murch[m]>
E.g., by trying to talk more about the big picture
<sipa>
cfields: i think having a place to describe motivations for a change can very much help with some misunderstandings i'm seeing (as opposed to needing individual contributors' social media posts, which can be hard to find, scattered, and easily drowned in noise)
<stickies-v>
but i don't know how to solve that, and having a brief, easy-to-point to statement might still be a helpful addition
<Murch[m]>
Someone actually recently approached me that they want to make some educational videos about Bitcoin Core
<Murch[m]>
It certainly doesn’t sound like stuff that’s close to our heart, but we also can’t lose three weeks on a good chunk of developers every time someone misrepresents a situation
<achow101>
stickies-v: if people believe that contributors are evil / compromised, I don't think any communication that we do would really change that opinion?
<darosior>
Murch[m]: this is more than 3 weeks of time that is at stake. It should not be overstated but i think it shook the trust in Bitcoin Core to some extent.
<sipa>
achow101: yes, but i think that's only a minority, and maybe not the most important one
<Murch[m]>
darosior: Yeah, I agree
<darosior>
achow101: this is not about convincing people that already made their mind but the silent majority of people that are currently hearing from only the side of "Core is evil"
<Murch[m]>
achow101: I think the perception that we are compromised or misguided is only tenable, because the actual motivations are not understood
<darosior>
And a lot of people that is important to not lose the trust of, don't have the time to dig up through dumpster fire Github threads and ML threads for our arguments
<TheCharlatan>
yes, my impression from the past three weeks is that people genuinely don't understand why and how we're nudging ecosystem behaviour with policy.
<darosior>
I am not saying that as a project we should address every single tin foil hat conspiracy out there, but we should at least have a statement about our vision out. Anyone genuine can hear them and read us. Right now they can only hear them.
<achow101>
sure, I think writing a statement is fine, I just don't think that a dissuading people who have that opinion should necessarily be a goal
<Murch[m]>
Yeah, the conversation being on Twitter, Nostr, Stacker News, Delving, the Mailing List, the podcast sphere, and probably a gazillion chats that we aren’t in, doesn’t help with getting our message out when we don’t feel that strongly about it, while the other side thinks the world is on fire
<abubakarsadiq>
I think more communication is always welcome and beneficial, but I don’t believe it will prevent misclassification or incidents like the one caused by the recent policy change PR.
<abubakarsadiq>
In an open-source project like this, some people will always complain or create noise when developers make a decision that doesn’t align with their views.
<abubakarsadiq>
I’m not sure there’s a clear way to address that.
<achow101>
but certainly explaining motivations may help to that effect
<Murch[m]>
There also generally have been a few things that the community has felt very strongly about that Bitcoin Core has not addressed, so it’s just been piling up
<darosior>
abubakarsadiq: we will never sway disingenuous people. There is still plenty of genuinely confused people out there to be swayed. I think a letter on the website is a very cost efficient way of working toward that goal.
<Murch[m]>
Given that we are such a small group compared to the Bitcoin user base, more simply resources served highly visibly might significantly reduce our effort
<darosior>
Murch[m]: yes, this is not about that specific issue. Resentment has been piling up and lack of communication is fueling it
<achow101>
anyways, it seems like the next thing to do is to have something written to review
<stickies-v>
i agree it's worth doing effort to provide resources to people genuinely trying to understand
<glozow>
Producing more and more text that nobody reads is a bad strategy imo. It seems like we''re always thinking "if I just write one more post, they'll get it" and that's not true. I don't think we can win an information war unless we devote significant resources to becoming influencers long term. We have code to write, and they don't.
<achow101>
that will probably help inform the questions about what the point is
<abubakarsadiq>
+1 glozow
<darosior>
glozow: this is not about writing one more blog post this is about writing the very first thing about it.
<Murch[m]>
glozow: Yeah, what I’m tryìng to express is that we might want to communicate less often, but simpler and more visibly
<glozow>
I think darosior, Murch, and many others have written a ton about op_return already. They are excellent and were worth the time. But who is the person who will be convinced by a bitcoincore.org post and not the ones you've already written?
<sipa>
glozow: i think there may be some
<glozow>
And how will they come across this post?
<darosior>
glozow: I don't think an executive of a Bitcoin company will go read my thousand line detailed technical refutation of mostly tin foil hat stuff and made-up objections. They will read two paragraphs published officially on the Bitcoin Core website.
<Murch[m]>
glozow: Yeah, I’m not talking about the spilt milk, I’m thinking that in hindsight, e.g., darosior’s one long post was a much better at broadly addressing the issue than my ~200 posts
<glozow>
Murch: that seems like a good strategy overall
<darosior>
glozow: the same way they come across binaries. Somehow they find their way.
<Murch[m]>
exactly what darosior said
arminsdev has joined #bitcoin-core-dev
<glozow>
darosior: I don't think so. I think they message a dev or somebody dev-adjacent that they trust
<achow101>
glozow: I think something that is jointly the opinion of multiple contributors will have more weight than the hundreds of separate posts arguing with specific people
<achow101>
at least more easily pointed to as an opinion of several contributors to the project
<Murch[m]>
Anyway, +1 on waiting with merging 32406, +1 on one or two simple statements of a few lines (that might take significant effort to craft) reserving the judgement after seeing the content ;)
<sipa>
yeah, let's discuss when there is some text
<achow101>
#endmeeting
<corebot>
achow101: Meeting ended at 2025-05-15T17:00+0000
<glozow>
Sorry I don't mean to discourage you from writing a post, and I'm interested in contributing to it. I just think we should manage expectations about how it will be received.
<sipa>
glozow: that's fair
<sipa>
this will not Fix Everything(tm)
<glozow>
I think it will be screenshotted and scrutinized just the same. You might send it to an executive, but they'll want you to hop on the phone and explain it to them.
<Murch[m]>
Yeah, definitely, thanks for clarifying
pablomartin_ has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
<cfields>
+1 glozow. That's what I was getting at as well. A post isn't going to end this. Questions about policy/consensus and how those decisions are made will always exist, and they'll always be a magnet for vitrol. This isn't about appeasing anyone. It's an opportunity for us to reflect and decide if we really are working in the users' best interests. If we are, we should continue on with the understanding that we'll get hate anyway. If we're lacking,
<cfields>
we should improve. Anything containing "we, the undersigned" will just fan the flames. Imo any communication should be about what we've learned from this debacle and what we intend to change. Not an explainer about policy.
<Murch[m]>
cfields: Thanks, that’s good food for thought
<Earnestly>
Is there a ml post (I can't subscribe, it probably just sits in mod queue forever) which goes over the rationale/reason (from bitcoin core's view) for why op_return is to be changed (and the option to configure it potentially removed in the future)?
<cfields>
lol
<instagibbs>
Poe's Law
Christoph_ has quit [Ping timeout: 276 seconds]
<Earnestly>
I've been here for awhile and don't think I've ever really been antagnostic
<Earnestly>
I've only seen a gist about this topic so far
<instagibbs>
Earnestly it's just comedic how hard communication is
<Earnestly>
Surely, but I was wondering if there was some ml discussion (I'm not sure if there is a ml anymore, I sort of just assumed the linux.org hosted one became an archive) about this other than PRs
<Earnestly>
(As the PRs don't really provide much background iirc)
<cfields>
Earnestly: just to be clear, I was just laughing at the timing of your question. Of course it's a reasonable one :)
<sipa>
Earnestly: instagibbs' first link is the ML post that started it all, plus the discussion that followed
<Murch[m]>
Earnestly: Instagibbs’s link from a few lines above has you covered
<Earnestly>
Yeah it seems good
<Earnestly>
Thanks, I'll have a read
<Earnestly>
I'll also try to see if I can just get a feed from google groups to something, nntp or whatever it is
<Murch[m]>
Earnestly: You can subscribe with any address, you don’t need a google account, if that is the problem
enochazariah has joined #bitcoin-core-dev
shytypes has joined #bitcoin-core-dev
<instagibbs>
sipa sdaftuar is there supposed to be some upper limit to reorg depth where if it's exceeded, we don't try to re-enter txns to the mempool?
<sipa>
instagibbs: i thought there was
<instagibbs>
ok, any idea where that would lie
Talkless has joined #bitcoin-core-dev
<instagibbs>
ah! found it
<sipa>
where?
<lightlike>
instagibbs: MAX_DISCONNECTED_TX_POOL_BYTES in disconnected_transaction.h
<instagibbs>
I ran into a clear 10->11 transition where things stop getting submitted, couldnt figure out why
Cory38 has quit [Quit: Client closed]
Cory38 has joined #bitcoin-core-dev
<instagibbs>
invalidateblock path is quite different too, TIL
<lightlike>
instagibbs: InvalidateBlock is only invoked in case of artificial reorgs (invalidateblock rpc). For actual reorgs, there is probably no depth limit, just MAX_DISCONNECTED_TX_POOL_BYTES?!
<instagibbs>
lightlike 👍
<sipa>
that matches the understanding i got when looking at this code a few months ago
<sdaftuar>
hmm. the way it's supposed to(tm) work is that we have a memory limit during any reorg, which once hit, will cause us to start evicting transactions from the pool of txs that we will eventually try to resubmit to the mempool.
<sdaftuar>
you're saying that isn't how it's done for actual reorgs?
<instagibbs>
invalidateblock is Special(TM)
<instagibbs>
that's the answer here
<sdaftuar>
ah ok
* sdaftuar
goes back to lurking
<instagibbs>
which like, I kind of wonder why
<sipa>
sdaftuar: for invalidateblock there is a depth limit above which it won't even try to re-enter disconnected blocks; for normal reorgs, it is only a memory limit, not a height liit
<instagibbs>
but yeah, will ignore it for now and make "real" reorgs instead
<sdaftuar>
sipa: got it, thanks for clarifying
jespada has joined #bitcoin-core-dev
Guest66 has quit [Quit: Client closed]
pablomartin_ has quit [Ping timeout: 276 seconds]
pablomartin_ has joined #bitcoin-core-dev
shytypes has quit [Quit: Client closed]
enochazariah has quit [Quit: Client closed]
Cory38 has quit [Quit: Client closed]
Cory38 has joined #bitcoin-core-dev
arminsdev has quit [Quit: Client closed]
<darosior>
We do have a limit on the number of blocks
<darosior>
Or at least we used to
<darosior>
IIRC it was 10 blocks
<instagibbs>
rewrote my scenario, it is now only limited based on memory, it seems
<darosior>
Oh that must be because of the invalidateblock difference that you pointed after, should have read scrollback
pablomartin_ has quit [Ping timeout: 248 seconds]
eugenesiegel has quit [Quit: Client closed]
pablomartin_ has joined #bitcoin-core-dev
Christoph_ has joined #bitcoin-core-dev
Christoph_ has quit [Ping timeout: 265 seconds]
pablomartin_ has quit [Ping timeout: 248 seconds]
skr0 has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
Cory38 has quit [Quit: Client closed]
pablomartin_ has joined #bitcoin-core-dev
Cory38 has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
eugenesiegel has quit [Quit: Client closed]
pablomartin_ has quit [Client Quit]
skr0 has quit [Quit: Leaving]
entropyx has quit [Ping timeout: 252 seconds]
entropyx has joined #bitcoin-core-dev
Cory38 has quit [Quit: Client closed]
Cory38 has joined #bitcoin-core-dev
Guest41 has joined #bitcoin-core-dev
dzxzg has joined #bitcoin-core-dev
<jonatack>
Caught up with the discussion in today's core dev meeting
<jonatack>
I'm willing to help review the draft before publication
<kanzure>
+1 to glozow's/cfield's comments. also, if there is no intention to change anything from this debacle (which might be a legitimate and correct outcome), then possibly it would make sense to say so, and indicate that we honestly believe that people did not read the pull request and made up misinformation: stating so may be helpful for helpful non-developers to understand that misinformation ...
<kanzure>
...about code proposals is a real problem that we acknowledge exists. finally, there may be some value in placating the larger community by re-announcing the availability of e.g. pruning flag that already works on their installations. (or some variation of this)
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
jespada has joined #bitcoin-core-dev
Guest41 has quit [Ping timeout: 240 seconds]
<bitcoin-git>
[bitcoin] darosior opened pull request #32521: policy: make pathological transactions packed with legacy sigops non-standard (master...2503_nonstd_tx_sigops) https://github.com/bitcoin/bitcoin/pull/32521
eugenesiegel has joined #bitcoin-core-dev
eugenesiegel has quit [Client Quit]
zeropoint has quit [Quit: leaving]
dzxzg has quit [Remote host closed the connection]
Cory38 has quit [Quit: Client closed]
Cory38 has joined #bitcoin-core-dev
<gmaxwell>
Making a post that explains whats up is just a good practice,-- it may not be at all helpful, but it's a good thing to do. Care should be taken to not do any more rake stomping with it, (e.g. mark drafts as drafts!) :P
bugs_ has quit [Quit: Leaving]
<gmaxwell>
One of the reasons, I fear, is that the root 'concern' material is just not actually that sincere or authentic. I've found that opponents of the change *reliably* disingage in discussions as soon as I join them, in a most unusual way. plus the flood of "I just switched to knots" posts from accounts that have never before made a comment related to bitcoin. I think it's likely that someone
<gmaxwell>
has found an oppturnity to fan drama and is exploiting it for some reason. In any case, to whatever extent if any the traffic is an attack it will continue to be unresponsive to good communications. But good communications is the right thing, so it just makes sense to keep doing the right thing.
robszarka has joined #bitcoin-core-dev
szarka has quit [Ping timeout: 268 seconds]
kevkevin_ has quit [Remote host closed the connection]