timbo_xy1 has quit [Remote host closed the connection]
timbo_xyz has joined #bitcoin-core-dev
timbo_xyz has quit [Ping timeout: 252 seconds]
timbo_xyz has joined #bitcoin-core-dev
cmirror has joined #bitcoin-core-dev
timbo_xyz has quit [Ping timeout: 252 seconds]
bitdex_ has joined #bitcoin-core-dev
bitdex has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] sipa closed pull request #33335: txgraph: randomize order of same-feerate distinct-cluster transactions (master...202509_txgraph_rand) https://github.com/bitcoin/bitcoin/pull/33335
timbo_xyz has joined #bitcoin-core-dev
PaperSword has joined #bitcoin-core-dev
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has joined #bitcoin-core-dev
PaperSword has quit [Quit: PaperSword]
andrewtoth_ has quit [Remote host closed the connection]
ghost43 has quit [Ping timeout: 252 seconds]
ghost43 has joined #bitcoin-core-dev
WizJin has joined #bitcoin-core-dev
timbo_xyz has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] maflcko opened pull request #34296: refactor: [move-only] Merge core_io module, remove from libkernel (master...2601-core_io) https://github.com/bitcoin/bitcoin/pull/34296
WizJin_ has joined #bitcoin-core-dev
timbo_xyz has joined #bitcoin-core-dev
WizJin has quit [Ping timeout: 240 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
btsf_1 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] frankomosh opened pull request #34297: p2p: add validation checks for initial self-announcement (master...p2p-self-announcement) https://github.com/bitcoin/bitcoin/pull/34297
btsf_1 has quit [Remote host closed the connection]
Guyver2 has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko opened pull request #34298: ci: Add and use ci/test/modernize-deprecated-headers.py (master...2601-iwyu-modernize-deprecated-headers) https://github.com/bitcoin/bitcoin/pull/34298
___nick___ has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
<bitcoin-git>
[bitcoin] vasild opened pull request #34300: test: use ephemeral ports in p2p_private_broadcast.py (master...auto_ports_in_p2p_private_broadcast) https://github.com/bitcoin/bitcoin/pull/34300
<bitcoin-git>
[bitcoin] maflcko opened pull request #34302: fuzz: Restore SendMessages coverage in process_message(s) fuzz targets (master...2601-fuzz-restore-coverage) https://github.com/bitcoin/bitcoin/pull/34302
l0rinc has joined #bitcoin-core-dev
___nick___ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] brunoerg opened pull request #34303: test: addrman: test self-announcement time penalty handling (master...2026-01-test-addrman-selfannoucement) https://github.com/bitcoin/bitcoin/pull/34303
<bitcoin-git>
[bitcoin] l0rinc opened pull request #34304: ci: bump `Valgrind fuzz` timeout to pass with GHA (master...l0rinc/gha-valgrind-timeout) https://github.com/bitcoin/bitcoin/pull/34304
<bitcoin-git>
[bitcoin] fanquake opened pull request #34305: log: correct size output in disk space check (master...fix_space_warning_log) https://github.com/bitcoin/bitcoin/pull/34305
<bitcoin-git>
[bitcoin] l0rinc closed pull request #34304: ci: bump `Valgrind fuzz` timeout to pass with GHA (master...l0rinc/gha-valgrind-timeout) https://github.com/bitcoin/bitcoin/pull/34304
<bitcoin-git>
[bitcoin] l0rinc reopened pull request #34304: ci: bump `Valgrind fuzz` timeout to pass with GHA (master...l0rinc/gha-valgrind-timeout) https://github.com/bitcoin/bitcoin/pull/34304
<fanquake>
l0rinc: it would be good to know more about your expectations here. Should the CI pass when run somewhere that doesn't have the hardware to run it?
<fanquake>
If we added 10x the CPU to the main repo tomorrow, and expanded the number of tasks, and added heavier tasks, then more things would also fail in forks, without the extra hardware.
<fanquake>
I don't really see how to avoid that, without unnecessarily containing the main repo (based on some vague/possibly changing external requirements), or providing every contributor with the same hardware.
<fanquake>
(and I think we should be trying to expand the CI in the main repo, and add more jobs).
<fanquake>
I think we should be running as many tests, as fast as possible, and tuning timeouts/expectations around that. Not optimising for what might be happening outside the repo.
Zenton has joined #bitcoin-core-dev
andrewtoth has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
<fjahr>
And if there are any last minute ones to add of course...
<willcl-ark>
hi
<furszy>
hi
Cory87 has joined #bitcoin-core-dev
<fjahr>
Starting with the WGs!
<fjahr>
#topic Fuzzing WG Update (dergoegge)
<dergoegge>
Eugene has been working on incremental snapshot support for fuzzamoto (https://github.com/dergoegge/fuzzamoto/pull/103). This will hopefully, in the long run, enable the fuzzer to explore even deeper into the state space.
<dergoegge>
I've open sourced the continuous fuzzing infra I've been running for the past years: https://github.com/dergoegge/fuzzor (there are no docs, but let marcofleon or me know if you want to run this as well)
<sedited>
i'm on mobile, maybe stickies-v has something to add?
<stickies-v>
let's keep it for next week
<yancy>
hi
<fjahr>
#topic Benchmarking WG Update (l0rinc, andrewtoth)
<l0rinc>
nothing from my side
<andrewtoth>
same, no updates this week
<fjahr>
#topic Silent Payments WG Update (Novo)
<Novo>
I've been doing some experiments to improve worst case scan
<darosior>
hi
<Novo>
With randomization of the outputs and removal, we can half scan time
<Novo>
By removal, I mean removal of found outputs from the list
<Novo>
Of course the scan time is still significant, 4 minutes on my machine
<furszy>
which scanning approach are you using?
<Novo>
BIP style
Cory61 has quit [Ping timeout: 272 seconds]
<Novo>
I'm also working benchmarking LabelSet scanning with Block
<Novo>
*Blocks
<instagibbs>
4 minutes over what data?
<furszy>
cool. It would be nice to know what's the diff there
<Novo>
I'm implementing LabelSet on core to use for testing
<furszy>
instagibbs: I assume an entire block targeting a single entity
<Novo>
4 minutes on the secp worst-case benchmark with 23250 outputs
<instagibbs>
ah
<l0rinc>
how long does it take to scan every single block to find a single transaction at the very end?
<furszy>
let us know how it goes Novo. We should have updates on the libsecp side soon as well.
<Murch[m]>
hi
<fjahr>
Novo: Having a benchmark in secp that simulates a block seems easier to me than implementing LabelSet in core but I guess you considered that
<Novo>
@l0rinc a single transaction at the end doesn't usually influence scanning time. The time it takes to scan txs without payments will be normal
<l0rinc>
no, I mean just as a benchmark, how long would it take to scan every block
<Novo>
fjahr I want to test with mainnet and maybe create some special blocks on regtest with script
<Novo>
l0rinc I don't have an exact number for you. I can share that later
merlyn has quit [Remote host closed the connection]
merlyn has joined #bitcoin-core-dev
Cory87 has quit [Quit: Client closed]
<l0rinc>
I was just interested in the magnitude. 20 minutes, 20 hours...
Cory87 has joined #bitcoin-core-dev
<Novo>
l0rinc more like milliseconds
<abubakarsadiq>
hi
<l0rinc>
we can read every transaction that quickly - let's discuss it offline
<Murch[m]>
milliseconds for every block, or do you mean a single block?
<l0rinc>
*can't
<Novo>
Alright l0rinc
<fjahr>
#topic Net Split WG Update (cfields)
<Novo>
Murch[m] I meant per block
<cfields>
No net split update this week. But I did manage to track down and work around the gcc bug slowing down the chacha20 impl that l0rinc mentioned here last week: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107563#c13
<cfields>
For anyone wondering why I'm spending _so_ much time on chacha20, it's because I'm hoping to prove that writing generic vectorized code like this is a reasonable way forward for us for our low-level bottlenecks. If so, we could be more liberal with adding simd code as it's easier to review than bare asm.
jdoman has joined #bitcoin-core-dev
<l0rinc>
:+1:
<fjahr>
(not seeing the cluster people, feel free to speak up if there is something to share otherwise moving on in a few sec)
Novo has quit [Quit: Client closed]
eugenesiegel has joined #bitcoin-core-dev
<fjahr>
#topic Constant build failures on forked repos since introduction of `Valgrind fuzz` CI job (l0rinc)
<l0rinc>
The Valgrind fuzz job was introduced in e4b04630bcf59ea03c1373777a0167af699f92a4. Since then, ci/test/00_setup_env_native_fuzz_with_valgrind.sh seems to regularly time out on forked repositories (which fall back to GitHub-hosted runners), hitting the 240 minute job timeout, see: l0rinc/bitcoin/actions/runs/21003573850/job/60381011678
<l0rinc>
I first tried bumping the timeout to the GitHub Actions maximum, since the run took 4h 36m 50s.
<l0rinc>
maflcko suggested that we rather remove it from the CI matrix since it didn't reveal anything (similarly to how the valgrind no-fuzz task is handled) - which was rejected by others, see: #34304
<l0rinc>
Being able to run CI on forked repositories was working before #33461, it's useful to have a playground available to validate CI passing before we push to bitcoin/bitcoin - to avoid people pushing to bitcoin/bitcoin and experimenting there.
<l0rinc>
It's fine if certain heavy tasks are skipped on GitHub-hosted runners, but we shouldn't get used to red CI on forks, and we should make sure bitcoin/bitcoin isn't the only green build.
Cory32 has joined #bitcoin-core-dev
<fanquake>
I posted my thoughts above, before the meeting, but can copy them back here
<fanquake>
It would be good to know more about your expectations here. Should the CI pass when run somewhere that doesn't have the hardware to run it?
<fanquake>
If we added 10x the CPU to the main repo tomorrow, and expanded the number of tasks, and added heavier tasks, then more things would also fail in forks, without the extra hardware.
<fanquake>
I don't really see how to avoid that, without unnecessarily constraining the main repo (based on some vague/possibly changing external requirements), or providing every contributor with the same hardware.
<ryanofsky>
could it be fixed by having the job respect some RUN_SLOW_CHECKS variable that is only set in the main repo?
<fanquake>
(rember than GH CI in forks only works because GH gives away CPU for free, for now)
<fanquake>
I think we should be running as many tests, as fast as possible, and tuning timeouts/expectations around that. Not optimising for what might be happening outside the repo.
<l0rinc>
yes, that was an alternative that willcl-ark also suggested
<sipa>
hi
<darosior>
fanquake: +1. It seems the fact that CI can run in forked repos is just a byproduct of our CI configuration still being quite light compared to the size/importance of the project.
<l0rinc>
thus isn't an optimization, I just want to restore the build passing outside of bitcoin/bitcoin
<fanquake>
If someone wants to run the CI on a raspberry Pi, when shouldn't be optimising for that
<fanquake>
*we
Cory8 has joined #bitcoin-core-dev
enochazariah3 has quit [Ping timeout: 272 seconds]
enochazariah has quit [Ping timeout: 272 seconds]
Cory87 has quit [Ping timeout: 272 seconds]
jdoman has quit [Quit: Client closed]
<fjahr>
Investigating some RUN_SLOW_CHECKS variable seems like the best option, I can totally see that GH changes their policies in the future and this option goes away
<fjahr>
Seems like there is nothing to add to the conversation for now. sipa: Did you want to say something about cluster mempool?
<sipa>
cluster mempool update: #34259 got merged; i've marked #34257 as next to review. Since it's more than an implementation, I'm curious about more conceptual opinions on the matter too.
<sipa>
(and thanks for the review, we're in the home stretch)
Cory32 has quit [Ping timeout: 272 seconds]
<fjahr>
Thanks for the updates everyone! Anything else to discuss?
<furszy>
just a small add to the SP convo
<furszy>
Novo: l0rinc was asking for entire chain scanning. Just to add an answer for it: for now, the focus has been on adversarial scenarios (at least on libsecp), mostly the worst case for a single block. Outcomes of this obviously improve the overall scanning time as well, but the happy path has not been part of this first "let's do not introduce a DoS vector" step.
<furszy>
that's it.
<l0rinc>
thanks for clarifying furszy
<fjahr>
#endmeeting
<corebot>
fjahr: Meeting ended at 2026-01-15T16:24+0000
<darosior>
sipa: the discussion in #33335 is convincing that a deterministic tie breaker is preferable. But i find it quite unintuitive that between two equal-feerate transactions you would choose to pick the one that pays a miner less. Miners optimize for maximum fees, which often (though not always) means maximizing feerate first, but also just absolute
<darosior>
fees? Now i understand miners optimize for what actually ends up paying them, which is what they can actually pack in a template, and that sometimes smaller transactions can lead to higher-paying templates, but is that the common case?
andrewtoth has quit [Remote host closed the connection]
andrewtoth has joined #bitcoin-core-dev
<sipa>
darosior: it's important to note that this is just choosing the order of chunks within a group of equal-feerate ones - and that group has fixed size, and fixed total fee
<sipa>
so it's just a question of where to put the boundaries between chunks in it, and it's really the distance between where the block boundary falls and the last chunk boundary before it that matters
<darosior>
And more often than not you'd want to have the smaller transaction first because the larger (higher-fee) one would not fit and therefore if you didn't order this way you'd give up both their fees?
* darosior
spells out loud to make sure he understands