memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
timbo_xyz has quit [Remote host closed the connection]
katsu has quit [Remote host closed the connection]
katsu has joined #bitcoin-core-dev
afiore_ has joined #bitcoin-core-dev
afiore has quit [Remote host closed the connection]
afiore_ is now known as afiore
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko opened pull request #34230: fuzz: Reject too large descriptor leaf sizes in scriptpubkeyman target (master...2601-fuzz-scriptpubkeyman) https://github.com/bitcoin/bitcoin/pull/34230
<bitcoin-git>
[bitcoin] tboy1337 opened pull request #34231: consensus: Fix potential null pointer crash in CalculateSequenceLocks (master...fix-sequence-locks-nullptr-crash) https://github.com/bitcoin/bitcoin/pull/34231
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
afiore has quit [Remote host closed the connection]
timbo_xyz has quit [Remote host closed the connection]
afiore has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
<vasild>
dergoegge, ryanofsky: Is it not a convention to exit with !=0 if interrupted? At least sleep(1), nc(1) and python programs do that: "echo $?" afterwards returns 130
mudsip has quit [Client Quit]
<vasild>
cat(1) as well
mudsip has joined #bitcoin-core-dev
timbo_xyz has joined #bitcoin-core-dev
mudsip has quit []
timbo_xyz has quit [Ping timeout: 252 seconds]
<Sjors[m]1>
Do we want the IRC bot to also announce libmultiprocess PR openings and merges?
<hebasto>
^ +1 on that
abubakarsadiq has joined #bitcoin-core-dev
timbo_xyz has joined #bitcoin-core-dev
timbo_xyz has quit [Ping timeout: 252 seconds]
___nick___ has quit [Ping timeout: 240 seconds]
___nick___ has joined #bitcoin-core-dev
afiore has quit [Remote host closed the connection]
<vasild>
So, maybe it is not appropriate to return 0 when the program is interrupted with Control-C.
timbo_xyz has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
afiore has quit [Quit: GNU inetutils 1.3a (telnet)]
l0rinc has joined #bitcoin-core-dev
afiore has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] w0xlt opened pull request #34233: test: fix Windows CI failures in wallet_multiwallet and old binary tests (ancient wallets) (master...ascii-only-tmpdir) https://github.com/bitcoin/bitcoin/pull/34233
Cory51 has quit [Quit: Client closed]
Cory51 has joined #bitcoin-core-dev
___nick___ has quit [Ping timeout: 244 seconds]
___nick___ has joined #bitcoin-core-dev
<maflcko>
vasild: Those are utilities, not daemons. For a daemon, it is normal and expected to stop gracefully and sucessfully on CTRL+C
<maflcko>
E.g start "redis-server", then "^C323:signal-handler (1767878809) Received SIGINT scheduling shutdown...", "323:M 08 Jan 2026 13:26:49.711 # Redis is now ready to exit, bye bye...", "echo $?", "0"
<sedited>
Some progress is being made on experimenting with copy-on-write datastructures, janb84 has been running some preliminary benchmarks for replacing the current CChain with such a structure.
<sedited>
that's all
<fjahr>
#topic Benchmarking WG Update (l0rinc, andrewtoth)
<l0rinc>
#33866 was merged, so we rebased the related PRs:
<l0rinc>
#34207 - GetCoin() is an interface for querying the UTXO set, so production implementations should only ever return unspent coins - adjusted tests to make them more realistic and exercise cases that can actually happen.
<andrewtoth>
It is also faster connecting blocks at tip during steady state. It has been thoroughly fuzzed, and we split out two other PRs #34164, #34165 from it that could have small benefit on their own (and would help make #31132 easier to review).
<sipa>
the PR there proposes introducing more randomness for sorting equal-feerate transactions and chunks, to fix a privacy leak (reveal information about the order transactions were received)
<sipa>
but randomness also has downsides in terms of non-predictability, worse block propagation, and ability to monitor behavior on the network
<sipa>
so i'm considering (and implementation) and alternative that makes the ordering deterministic; PR forthcoming
<sipa>
that's it for me
<l0rinc>
would it be configurable?
<sipa>
i don't think it makes sense to make this configurable
<dergoegge>
hi
<fjahr>
#topic Net Split WG Update (cfields)
<instagibbs>
thanks sipa
<darosior>
hi
<cfields>
I've spent this week profiling and benchmarking a few assumptions (send/receive buffer sizes, corking behavior, etc) in our net code after the chacha20 speedups to ensure that the net split doesn't bake in any bad assumptions. Thankfully things look quite balanced, so I'm setting that aside and continuing with the manual code movement. Not much to see yet.
<l0rinc>
cfields: I have experimented a bit more with your ChaCha20 branch: do we understand why clang is ~2x faster than gcc? At least it is for me on every platform I tried
<cfields>
l0rinc: I mostly tested with clang, so I suppose that makes sense. I didn't realize there was _that_ much difference though. I can spend a little time looking at the generated code to see what the main differences are.
<sipa>
2x is remarkable - it sounds like some vectorization step that one compiler does and the other doesn't
<l0rinc>
I think I found a config that speeds up GCC - and even clang a bit, but it's still a lot slower
<fjahr>
Moving on, this is probably best discussed after the meeting :)
<fjahr>
#topic Fuzzing WG Update (dergoegge)
<cfields>
It's very sensitive to register allocation. Perhaps gcc misses out somewhere. l0rinc: let's chat after the meeting and compare notes.
<cfields>
fjahr: 👍
<dergoegge>
I think I mentioned last meeting that I'm writing a blog post series on fuzzamoto
<fjahr>
Ok, I am skipping Silent Payments because I didn't see Novo__ unless someone wants to add something. I can at least say there is quite a bit of action in secp currently.
<fjahr>
Yeah, I think conceptual feedback on the APIs and worst scanning concerns would great from anyone interested in using SP!
<fjahr>
Thanks everyone for the updates!
<fjahr>
#topic maintainer nomination (glozow)
<glozow>
I’m nominating TheCharlatan aka sedited to be a maintainer. He is a reliable reviewer who has worked extensively in critical areas of the codebase, thinks carefully about what we ship to users and developers, and understands the technical consensus process well.
<glozow>
I’ve spoken with him and the other maintainers already, and hope that the rest of you agree he is well-suited for the role. Please speak freely with your concerns and/or support.
<achow101>
ack
<dergoegge>
ack
<marcofleon>
ack
<hebasto>
ack
<brunoerg>
ack
<sliv3r__->
ack
<pinheadmz>
ack
<sipa>
ack
<instagibbs>
ack
<l0rinc>
ACK
<furszy>
ack TheCharlatan, I don't know sedited enough yet.
<fjahr>
ack, but I guess there will be an issue as well like last time?
<lightlike>
ack
<andrewtoth>
ack
<hodlinator>
ack
<janb84>
ack
<yancy>
ack
<stickies-v>
ack
nanotube has joined #bitcoin-core-dev
<glozow>
The next step would be for him to open a PR to add his key to trusted-keys
<darosior>
Ack. To add to that i agree especially with the part of him having a project-wide view and his care for what we ship to users.
<maxedw>
ack
<glozow>
sedited: do you want to add anything? :)
<sedited>
ty, fjahr do you have that issue number?
<abubakarsadiq>
ACK
<fjahr>
no, I meant that I think we opened an issue for discussion last time if I remember correctly and I asked if this is happening again.
<fjahr>
But maybe that was also the PR already
<glozow>
I don't think we did an issue, just a PR
<achow101>
just the pr
<darosior>
Maybe you are referring to the thread of the PR where the last person added their key?
<fjahr>
It's not so relevant, I need to go back and look at it
<fjahr>
It's been a while
<fjahr>
Anything else to add on this topic?
<maflcko>
ack, sedited seems a great fit for the role
<glozow>
I think that's it. The rest can be on the PR
<brunoerg>
Right now, I'm working on making the analysis more efficient, so your feedback is important. There is a section "Final notes" with some actions so I'd appreciate some feedback on that points.
___nick___ has quit [Quit: No Ping reply in 180 seconds.]
<brunoerg>
Also, if you want a mutation testing run on any PR, please ping me in the PR.
<kevkevin>
ack
<brunoerg>
That's all
sliv3r__- has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<cfields>
walked away for a few min. ACK sedited :)
sliv3r__ has joined #bitcoin-core-dev
<fjahr>
#topic fee estimation improvement
<fjahr>
go ahead :)
<abubakarsadiq>
I opened a #34075, which attempts to fix the ancient #27995 issue with a mempool-based fee estimator that only lowers the Block Policy Estimator.
<abubakarsadiq>
Empirically, I observed a 73% success rate with 0% overestimation, and 26% underestimation with this approach. I did some refactors to enable these. See PR op for more details.
<abubakarsadiq>
Bringing this here to request feedback on the approach and the assumption there.
<corebot>
https://github.com/bitcoin/bitcoin/issues/34075 | fees: Introduce Mempool Based Fee Estimation to reduce overestimation by ismaelsadeeq · Pull Request #34075 · bitcoin/bitcoin · GitHub
<sipa>
How do you define overestimation/underestimation here?
<abubakarsadiq>
overestimation is when you estimate a feerate for target x as y.
<abubakarsadiq>
but all the blocks since from current height to current height + x the estimated fee rate is above their 95th percentile fee rate
<abubakarsadiq>
that imply that you overshoot
<abubakarsadiq>
underestimation is when y is below the 5th percentile fee rate of all blocks from current height to current height + x
<sipa>
got it
<sipa>
cool
<l0rinc>
#topic (ATT)ACKs
enochazariah55 has quit [Quit: Client closed]
<l0rinc>
please let me know when the previous topic is finished
<fjahr>
I guess it is now ;)
<l0rinc>
I would also like your feedback on a different topic, since we saw fake ACKs being spread around - we could adjust the DrahtBot ACK summary with avatars and maybe italics for members to avoid impersonations. And while we're touching this, ryanofsky suggested we add links to all acks, not just the last one. Your feedback is welcome in https://github.com/maflcko/DrahtBot/pull/72
<abubakarsadiq>
yes go ahead
<l0rinc>
that's it, thanks
enochazariah has joined #bitcoin-core-dev
<achow101>
i don't like it, too much visual clutter
<achow101>
usernames is fine for me
<abubakarsadiq>
I think this is relevant to maintenance and how they weigh ACK, i doubt if avatar would improve their process
<instagibbs>
right, I think maintainers should speak up if anything can make their job easier
<sipa>
yeah, this seems to be something that mostly needs maintainer opinions
<fanquake>
~0 leaning the same way. I don't think avatars add anything (~20% of contribs use the GH default anyways), and org membership doesn't really matter?
<kevkevin>
can you instead sort them by when the account was first made?
<kevkevin>
not sure if there is any sorting done right now
<sliv3r__>
or sort by members, contributors, etc.
<brunoerg>
I don't like it as well, kinda polluted
<pinheadmz>
have there been ACK from actual homograph users? (like "s1pa" or soemthing)
<glozow>
avatars are copiable too
<l0rinc>
yes, of course, that's why members would be shown in italics
<sipa>
pinheadmz: on twitter, yes...
<achow101>
pinheadmz: i don't think we've had any yet
<sipa>
ah, ACKs, no
<l0rinc>
The new maintainer could do the funniest thing: TheCharltan -> sedited -> s1pa
<_aj_>
for PRs with a large number of acks, could consider breaking out the members/non-members into separate tables, as well as the bold distinction. the avatars don't seem that useful to me. links to prior acks would be handy sometimes though
<ryanofsky>
if impersonation is a problem i think we should find a way to remove impersoniated nicks from the table, not just display them differently
<glozow>
I don't think we are tricked so easily. The most harm these ack tables do is on social media. Any chance github allows comments that are only viewable by members?
<sipa>
i don't think impersonation is a problem - and it's something that can be dealt with if it ever becomes one
<fanquake>
We seem to have started with the assumption that this is actually a common issue. It isn't for 99.99% of PRs, and on the occasional PR it could be, I'm sure maintainers would be paying more attention. (the drahtbot comment sholdn't be a subsittute for checking anything)
<pinheadmz>
could add # of commits to repo after each username
<_aj_>
(marcofleon and maflcko have the homograph approach covered already as far as i'm concerned)
<instagibbs>
recently I've seen some "farming" but it you just weight those acks at ~0 unless proven competence otherwise
<l0rinc>
ok, thanks for the feedbacks
<achow101>
i think the table is fine as-is
purpleKarrot has quit [Quit: purpleKarrot]
<achow101>
low effort accounts and new contributors are already being filtered out in people's heads
<pinheadmz>
I had a draht bot PR that hid the table if the PR was labeled "controversial" but it was nacked and closed
<maflcko>
_aj_: pinheadmz: I think there were some attempts to deal with "controversial"/"verbose" pulls, but I think it went nowhere conclusive. Also, it only happens every year or two, so an automatated approach for a rare anomaly seems overkill
<fjahr>
ok, any more last minute topics?
<furszy>
happy to answer questions related to the recent bug via DM if needed.
<achow101>
same
<pinheadmz>
_aj_ I sign my ACKs too! Isn't everyone... verifying... those ?
<fjahr>
#endmeeting
<corebot>
fjahr: Meeting ended at 2026-01-08T16:46+0000
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
Cory34 has joined #bitcoin-core-dev
Cory47 has quit [Ping timeout: 272 seconds]
Cory93 has joined #bitcoin-core-dev
Cory34 has quit [Quit: Client closed]
Guest79 has joined #bitcoin-core-dev
Guest79 has quit [Client Quit]
willcl-ark_ has quit [Quit: left]
willcl-ark has joined #bitcoin-core-dev
willcl-ark has joined #bitcoin-core-dev
<willcl-ark>
ryanofsky: I see your trusted-keys gpg key as expired since 2026-01-01, so you may want to consider extending that soon. Apologies if you have done already and I've missed it; I only refreshed from keys.openpgp.org.
Cory27 has joined #bitcoin-core-dev
Cory93 has quit [Ping timeout: 272 seconds]
___nick___ has quit [Ping timeout: 264 seconds]
<ryanofsky>
willcl-ark, thanks will fix
Cory16 has joined #bitcoin-core-dev
Cory27 has quit [Ping timeout: 272 seconds]
Cory15 has joined #bitcoin-core-dev
Cory4 has joined #bitcoin-core-dev
Cory90 has joined #bitcoin-core-dev
Cory16 has quit [Ping timeout: 272 seconds]
Cory15 has quit [Ping timeout: 272 seconds]
Cory4 has quit [Ping timeout: 272 seconds]
willcl-ark_ has joined #bitcoin-core-dev
willcl-ark has quit [Read error: Connection reset by peer]
willcl-ark_ has quit [Ping timeout: 264 seconds]
memset has quit [Remote host closed the connection]