<bitcoin-git>
[bitcoin] Sjors opened pull request #32861: Have createwalletdescriptor auto-detect an unused(KEY) (master...2025/07/smart-createwalletdescriptor) https://github.com/bitcoin/bitcoin/pull/32861
sbddesign has quit [Ping timeout: 260 seconds]
kevkevin has joined #bitcoin-core-dev
memset has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master 6c364e0 Martin Zumsande: test: Enable various tests for usage with cli
<bitcoin-git>
bitcoin/master 7d5352a Martin Zumsande: test: use -stdin for large rpc commands
<bitcoin-git>
bitcoin/master 5b08885 Martin Zumsande: test: enable functional tests with large rpc args for cli
<bitcoin-git>
[bitcoin] fanquake merged pull request #32290: test: allow all functional tests to be run or skipped with --usecli (master...202505_fix_usecli) https://github.com/bitcoin/bitcoin/pull/32290
l0rinc has joined #bitcoin-core-dev
l0rinc has quit [Client Quit]
sbddesign has joined #bitcoin-core-dev
SpellChecker_ has joined #bitcoin-core-dev
SpellChecker has quit [Ping timeout: 244 seconds]
sbddesign has quit [Ping timeout: 248 seconds]
f321x has quit [Remote host closed the connection]
f321x has joined #bitcoin-core-dev
szkl has joined #bitcoin-core-dev
SpellChecker_ has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] fanquake merged pull request #32716: depends: Override host compilers for FreeBSD and OpenBSD (master...250610-depends-bsd) https://github.com/bitcoin/bitcoin/pull/32716
sbddesign has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 244 seconds]
sbddesign has quit [Ping timeout: 248 seconds]
sbddesign has joined #bitcoin-core-dev
sbddesign has quit [Ping timeout: 276 seconds]
<sipa>
phantomcircuit: yeah, i think that's what you want. But for it to be useful, you'd need the ability for net_processing to continue while ABC is running. However, you cannot process further messages from the peer that gave you the block, as that wouls violate the protocol (e.g. if they send a BLOCK followed by a PING, they only expect the PONG after the block is processed), so you need a way to mark
<sipa>
a peer in net_processing as "paused" while ABC is...
<sipa>
running for it, making net_processing skip the peer
f321x_ has quit [Quit: f321x_]
f321x has joined #bitcoin-core-dev
<_aj_>
sipa: you probably want to defer processing (and requesting?) transactions from other peers as well? probably also pause any peers that announce the same block/header at you?
<_aj_>
s/probably/possibly/g
PaperSword has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
<sipa>
_aj_: yes, i think what we really want is validation to work as a queue of (tx, block, cmpctblk, ...) objects, each with a callback for reporting success/failure. net_processing just hands the received objects to the queue, pausing the peer that gave them. Upon completion, the callback unpauses them (and perhaps relays, punishes, ...); the nice thing is that the validation queue can then be made to
<sipa>
reorder/prioritize its objects (e.g. prioritize blocks...
<sipa>
over txn), or split up processing (e.g. do an early header check first, or do things quickly if they are cached already, or even start doing transactioj validation in multiple script threads, ...)
<bitcoin-git>
[bitcoin] pinheadmz opened pull request #32862: rpc: use CScheduler for HTTPRPCTimer and remove RPCTimer (master...http-scheduler-notimer) https://github.com/bitcoin/bitcoin/pull/32862
<achow101>
There are no pre-proposed meeting topics this week. Any last minute ones to add?
<janb84>
hi
<danielabrozzoni>
hi
<brunoerg>
hi
<achow101>
#topic Erlay WG Update (sr_gi, gleb)
<vasild>
hi
l0rinc has joined #bitcoin-core-dev
<sipa>
hi
<dergoegge>
hi
<instagibbs>
hi
<Murch[m]>
Hi
<sr_gi[m]1>
It seems the propagation time issue I found last week may be what was making erlay times too good to be true. I've been re-running the simulations for small (50 nodes) and medium-size (200 nodes) networks. I'm currently re-working part of the warnet simulations so they can handle bigger networks (500 nodes is the most I've done, but the sims are a bit unreliable)
<pablomartin4btc>
hi
<sr_gi[m]1>
My goal is having the sims for all of them in the upcoming days so I can report back hopefully next week, and start moving forward
<sr_gi[m]1>
That's it on my end
<achow101>
#topic Fuzzing WG Update (dergoegge)
<dergoegge>
Found 2 bugs on PRs with fuzzamoto in the last two weeks. One really shallow one in the erlay sketch deserialization code and one in the cluster mempool PR. The mempool bug specifically is a nice example for the complex inputs that fuzzamoto can generate.
<dergoegge>
Also implemented a “netsplit” oracle, which already found a minor issue, fixed by instagibbs here: https://github.com/bitcoin/bitcoin/pull/32869 (would be nice to get some review on that)
<sipa>
the past week some extra benchmarks are tests were added, but i don't expect many further changes
<glozow>
hi
<instagibbs>
try not to rebase on master if possible :P
<sipa>
after that, the txgraph API will be largely complete, and i think we can start focusing on getting parts of the full cluster mempool implementation (#28676) in
<glozow>
sipa: would the plan be to do that PR all together?
<glozow>
(all of 28676)
<sipa>
unsure, i assume it contains some amount of preparatory work that can be split off
<sipa>
but the bulk, adding the cluster tracking, and switching out the mempool tracking, will need to be one PR I think (or at least a sequence of PRs that are all expected to go into the same release)
<glozow>
makes sense
<sipa>
that's it for me, unless more questions
<achow101>
#topic MuSig2 WG Update (achow101, rkrux)
<sipa>
abubakarsadiq: an optimal eviction algorithm could avoid that, but the trim algorithm is really just a best-effort of what we can accomplish in O(n log n)
enochazariah has joined #bitcoin-core-dev
<sipa>
with proper linearization we could do a lot better - but the whole point of trim is that it can work with much larger numbers of transactions than what fit in a cluster
<achow101>
#topic cluster mempool still
<abubakarsadiq>
yep, could just throw txs in compact block reconstruction txs with a bound if thats the case.
<sipa>
right
enochazariah has quit [Client Quit]
<abubakarsadiq>
Also I think if we evict children first, we could avoid that but the current best effort algorithm is better in terms of incentive compatibility I think
<sipa>
i'm not too worried about this, in practice i think the amount of oversized would-be clusters formed by reorged will be pretty small in non-attack scenarios
<instagibbs>
most clusters are singletons after all
<abubakarsadiq>
👍
<sipa>
and it costs creating a block to do something deliberately crazy
Guyver2 has left #bitcoin-core-dev [Closing Window]
enochazariah has joined #bitcoin-core-dev
<sipa>
abubakarsadiq: we're not restricted to the current Trim algorithm too; we could experiment with better algorithms later, or even have multiple algorithms depending on the size (e.g. have a medium-size trim algorithm that works acceptably fast for say ~200 transactions, but not 5000, for which we can still fall back to the current Trim one)
<sipa>
but those don't affect the API, so wouldn't block further cluster mempool progress
<abubakarsadiq>
yes please
memset has quit [Remote host closed the connection]
<sipa>
now back to your regularly scheduled MuSig2
memset has joined #bitcoin-core-dev
<achow101>
#topic MuSig2 WG Update (achow101, rkrux)
<achow101>
#31244 is probably rfm, otherwise, no updates
<glozow>
Worst case EraseForBlock times were pretty bad (if you have tons of transactions each spending hundreds of inputs all conflicting with the block)
<glozow>
yeah, I'm getting 35ms on my machine
<sipa>
EraseForBlock, but also EraseForPeer could trigger most (but not all) of the same work, which is potentially triggerable by non-miners
<instagibbs>
due to outpoint map?
<glozow>
Yes. EraseForBlock is slightly worse because it has the loop that builds the set of wtxids to erase (each of the 1750 wtxids is added ~180 times). And then it has to erase all of those entries from the outpoints map
enochazariah has quit [Quit: Client closed]
<instagibbs>
👍
<glozow>
The current ideated formula is that "announcement count" becomes 1 + floor(vin.size() / 10) for each tx. So the first 9 inputs are "free" and this limit is hopefully not relevant to normal transactions
<sipa>
the vin.size()/10 would be deduplicated across peers, while the 1 part isn't
<sipa>
as each tx's inputs only appear once in the outpoint index
<glozow>
right that part is similar to the memusage metric
<glozow>
Since last week I've also added sipa's simulation fuzzer + a few small tweaks and tests
<glozow>
that's all the updates
<achow101>
#topic QML GUI WG Update (jarolrod, johnny9dev)
<johnny9dev>
Not much this week on QML work. bitcoin-core/gui-qml#450 got merged and hebasto and pinheadmz are making good progress on bitcoin-core/gui-qml#472.
<l0rinc>
do we need to keep the mempool stats up-to-date when the mempool is still empty? My understanding is that when it becomes empty we definitely need to keep the fee estimation state updated, but not sure if that's necessary during IBD. And if I try skipping `MempoolTransactionsRemovedForBlock` notification for the resulting empty vector of removals, I'm getting a test failure and need some help in deciding if the test shows a representative behavior
<l0rinc>
or not - would be nice if we could avoid adding another callback into the validation queue...
<achow101>
#topic mempool in ibd
Naiyoma has quit [Ping timeout: 252 seconds]
<glozow>
Is the question whether the fee estimator needs to know about every `MempoolTransactionsRemovedForBlock`?
<l0rinc>
yes, in case of no removals
<l0rinc>
as is the case as far as I can tell during IBD before any mempool activity
<abubakarsadiq>
l0rinc: is it the fee estimator test that is failing?
<l0rinc>
it's feature_fee_estimation
<glozow>
I think this is the only way the fee estimator updates `txHeight`
Guest5846 has joined #bitcoin-core-dev
<glozow>
Is this slowing IBD down though? Doesn't this happen on a background thread?
<abubakarsadiq>
shouldn't it be no-op when their is no data on mempool, is their a measurable improvement from skipping that?
<jonatack>
hi
sbddesign has quit [Ping timeout: 276 seconds]
<l0rinc>
glozow: it's blocking the queue, as furzsy sais:
<l0rinc>
> First quick glance it seems that if the mempool is empty; we could avoid calling removeForBlock entirely. Which will save us from adding another callback into the validation queue too, which will leave space for processing another block during ibd.
<l0rinc>
> Yet, that was a fast check. Should check who is using the MempoolTransactionsRemovedForBlock event.
<l0rinc>
We don't have to resolve it here, if anyone has insights, please add it to the PR - otherwise I will keep the MempoolTransactionsRemovedForBlock call for empty txs_removed_for_block as well
<abubakarsadiq>
glozow: yes, we update `nHeight` after we are done with ibd and update the fee estimator stats for the first time it recorded data is marked as confirmed because of a new block.
<glozow>
so the fee estimator doesn't do anything during IBD?
Guest5846 has quit [Ping timeout: 276 seconds]
<abubakarsadiq>
yes it does not, it has to see transaction enter mempool first.
<glozow>
I meant to ask if the fee estimator gated on IBD?
<glozow>
if its functions are gated*
<glozow>
nvm, can look at this later
<abubakarsadiq>
the updates are redundant, we don't do anything and can be avoided I think.
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
<furszy>
l0rinc: I just had a quick talk with abubakarsadiq and It seems we still need to send the signal just to update the best seen height inside the fee estimation class, but we can skip some of the calculations on the event processing side (all the stats objects are initialized but contain only the default values, so we could avoid going through them while computing some mod operations). Still, not sure how much performance gain we will g
<furszy>
et from this. Matter of checking it.
<abubakarsadiq>
yeah working on it 👍🏾
Guest9 has joined #bitcoin-core-dev
Cory81 has quit [Quit: Client closed]
Cory81 has joined #bitcoin-core-dev
Talkless has quit [Quit: Konversation terminated!]
eugenesiegel has quit [Ping timeout: 272 seconds]
kevkevin_ has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
Cory81 has quit [Quit: Client closed]
Cory81 has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 276 seconds]
kevkevin has joined #bitcoin-core-dev
Guest9 has quit [Quit: Client closed]
szkl has quit [Quit: Connection closed for inactivity]
aleggg has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] 1BitcoinBoWP1FZ4xwTNkq6XksKidmgYYw opened pull request #32871: New SVG, Icons, PNGs and X PixMaps (master...master) https://github.com/bitcoin/bitcoin/pull/32871
kevkevin has quit [Remote host closed the connection]
Guest9863 has quit [Quit: WeeChat 4.1.1]
wafflefrie has quit [Quit: Connection closed for inactivity]
joetor5 has joined #bitcoin-core-dev
eugenesiegel has joined #bitcoin-core-dev
jespada has quit [Quit: My Mac has gone to sleep. ZZZzzz…]
memset has quit [Remote host closed the connection]
memset has joined #bitcoin-core-dev
joetor5 has quit [Ping timeout: 245 seconds]
Cory81 has quit [Quit: Client closed]
Cory81 has joined #bitcoin-core-dev
joetor5 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 244 seconds]
eugenesiegel has quit [Quit: Client closed]
bugs_ has quit [Quit: Leaving]
wafflefrie has joined #bitcoin-core-dev
joetor5 has quit [Ping timeout: 248 seconds]
BlueMatt has quit [Quit: Quit]
BlueMatt has joined #bitcoin-core-dev
joetor5 has joined #bitcoin-core-dev
stratospher[m] has quit [Ping timeout: 260 seconds]
b10c[m] has quit [Ping timeout: 245 seconds]
BlueMattMtrxBot has quit [Ping timeout: 272 seconds]
<bitcoin-git>
bitcoin/master a69c409 Hodlinator: rpc: take ownership of the file by WriteUTXOSnapshot()
<bitcoin-git>
bitcoin/master 4bb5dd7 Vasil Dimov: util: check that a file has been closed before ~AutoFile() is called
<bitcoin-git>
bitcoin/master 8bb34f0 Vasil Dimov: Explicitly close all AutoFiles that have been written
<bitcoin-git>
[bitcoin] achow101 merged pull request #29307: util: explicitly close all AutoFiles that have been written (master...AutoFile_error_check) https://github.com/bitcoin/bitcoin/pull/29307
BlueMattMtrxBot has joined #bitcoin-core-dev
stratospher[m] has joined #bitcoin-core-dev
memset has quit [Ping timeout: 244 seconds]
memset has joined #bitcoin-core-dev
jadi has quit [Ping timeout: 276 seconds]
joetor5 has quit [Ping timeout: 244 seconds]
jadi has joined #bitcoin-core-dev
Guest0 has joined #bitcoin-core-dev
Guest0 has quit [Client Quit]
joetor5 has joined #bitcoin-core-dev
joetor5 has quit [Ping timeout: 244 seconds]
memset has quit [Remote host closed the connection]