<achow101>
There are no pre-proposed meeting topics this week. Any last minute ones to add?
<dzxzg>
hi
<sr_gi[m]1>
hi
<lightlike>
hi
<achow101>
#topic Erlay WG Update (sr_gi, gleb)
<brunoerg>
hi
<stickies-v>
hi
<l0rinc>
hi
<laanwj>
hi
<eugenesiegel>
hi
<cfields>
hi
<sr_gi[m]1>
I've been cleaning up and redesigning some parts of the full Erlay implementation so it's easier to follow, using txdownloadman as reference. I've also been adding all the missing unit tests and expanding part of the functional
<sr_gi[m]1>
Review keeps being needed on the initial PR
f321x has quit [Quit: f321x]
<sr_gi[m]1>
Nothing more to add on my end
<achow101>
#topic Kernel WG Update (TheCharlatan)
<TheCharlatan>
Steady progress on the API side, lots of discussions happening there, but seems like we are slowly coalescing on a common approach.
<TheCharlatan>
Hunting for ACKs in #33078 - should be close to merge now
<TheCharlatan>
^ it simplifies some of our API code a little bit.
<TheCharlatan>
Also had a steady stream of new contributors over the past few weeks, both looking to help flesh out the API, and write some new applications.
<sipa>
<TheCharlatan>
that's all :)
<kevkevin>
hi
<achow101>
#topic Benchmarking WG Update (josie, l0rinc)
<l0rinc>
Since we have added a warning for large dbcache flushes in previous release in #31534, it would be good if we could add a related optimization for speeding up the slow flushes, see #31645.
<l0rinc>
The change is only adjusting the already-configurable defaults, but has a measurable effect on a critical part of IBD performance.
<l0rinc>
Could we include it in v30?
<achow101>
we have less than a week to feature freeze and there's already a bunch of stuff in the milestone
<achow101>
how easy is it to review?
<l0rinc>
reveiw is trivial, basically just a value change, but reproducing it would take a few hours in the background
<achow101>
is there any urgency for it to be in 30?
<l0rinc>
no, just a preference since this release already contains 6 other IBD related optimizations
<achow101>
i don't think it should go into the milestone, but if it gets enough review before feature freeze, it can still go in
<l0rinc>
and slow flushing is a common complaint, users think the app is frozen
<l0rinc>
k, thanks
<l0rinc>
that's it from me
<achow101>
#topic Cluster Mempool WG Update (sdaftuar, sipa)
<sipa>
opened what i think is the last txgraph pr for now
<sipa>
then time to review cluster mempool PR itselr
<sipa>
nothing for 30.0 for sure
<sipa>
that's it
<achow101>
#topic MuSig2 WG Update (achow101)
<achow101>
No updates this week, please review #29675
<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 QML GUI WG Update (jarolrod, johnny9dev)
<johnny9dev>
was away on family vacation for the last week so getting caught up again. before I left there were a few PRs added for getting the new branch up to the feature set that I have in my personal fork.
<johnny9dev>
short term, the focus is just to catch up the send and payment request features
<johnny9dev>
another contributor, deer-gee is looking to upstream some events so he can complete his assumeutxo interface as well so that will likely start soon
bugs_ has quit [Quit: Leaving]
<johnny9dev>
thats all for now
<achow101>
#topic Script Validation WG Update (fjahr)
<fjahr>
There was some further development on the batch validation secp PR (review still welcome) but it still lacks pippenger support, I will probably wait a bit with rebasing the core PR until that’s the case. That’s it from me.
<achow101>
Anything to add or remove from the mileston?
<achow101>
And please review things in the milestone. Feature freeze is in 6 days
jon_atack has joined #bitcoin-core-dev
<achow101>
Anything else to discuss this week?
<l0rinc>
I have a different question about dbcache: given that we don't have fine-grained cache invalidation (we clear the cache, when full), has anyone investigated if we could reseed it with the past ~10 blocks after clearing?
jonatack has quit [Ping timeout: 260 seconds]
<willcl-ark>
hi
<sipa>
we don't always wipe completely anymore all the timr
<sipa>
it's worth experimenting with, i think
<sipa>
also at startup
<l0rinc>
yes, we already read 6 blocks for validation at the beginning, we could use those to seed the cache
<l0rinc>
thank you
<cfields>
I think Sjors[m]1 had a topic to discuss?
<achow101>
I don't see it?
<Sjors[m]1>
On mobile, so can't contribute much.
<Sjors[m]1>
Basically the request to add to milestone above
<cfields>
Ah, he just threw it out, not specifically for this meeting:
<cfields>
<Sjors[m]1> I'd like to propose #31802 for the v30 milestone, if only to discuss if it needs to be punted to the next release again.
<sipa>
my very 10000-mile view: i think it'd be nice if we had IPC enabled in from-source builds by default for a while before we add it to releases
<achow101>
does it need to be in this release?
<Sjors[m]1>
Although that makes sense the only people who currently want to test this prefer binaries over source builds.
<sipa>
Sjors[m]1: that's a good point
<achow101>
I agree with sipa
<Sjors[m]1>
And if I have to keep shipping a custom build anyway then I probably won't use the IPC variant because it's extra complexity.
<Sjors[m]1>
Compared to just integrating sv2 directly.
<Sjors[m]1>
So not sure how much we'll learn from waiting another six months.
<sipa>
Sjors[m]1: that seems like a false dichotomy; over time, i do expect we'll add it to release binaries
<Sjors[m]1>
Though maybe I'll ship a v30.0 + IPC patch binary myself.
<stickies-v>
"The initial main use case for IPC is to enable experimental support for the Mining IPC interface." this doesn't seem like a very strong reason to ship ipc binaries imo, i don't think we should rush it in
<darosior>
pinged Russ, fwiw
<Sjors[m]1>
Compared to six months ago it does seem much likely that eventually this will make it in, meaning that me maintaining an IPC binary won't be a dead end.
<sipa>
i also agree with thr view that we'll likely not learn that much if the use case is primarily people who want binatoes
<sipa>
*binaries
<sipa>
so, not opposed, but it feels rather unusual compared to how usually do thong
<sipa>
things
<fanquake>
Not sure I understand why it's extra complexity to ship the IPC binaries When it's either guix build 1 branch, or the other, to produce bins?
<ryanofsky>
Trying to catch up. I've open #31756 months ago to ask for feedback on this but haven't gotten much
thelounge4966 has quit [Ping timeout: 260 seconds]
stringintech has quit [Quit: Client closed]
jespada has quit [Ping timeout: 244 seconds]
jespada has joined #bitcoin-core-dev
bugs_ has joined #bitcoin-core-dev
Cory52 has joined #bitcoin-core-dev
Cory38 has joined #bitcoin-core-dev
Cory67 has quit [Ping timeout: 250 seconds]
Cory52 has quit [Ping timeout: 250 seconds]
jonatack has joined #bitcoin-core-dev
<darosior>
Re #33183 actually i'm not sure which way to go.. It's technically a gratuitous RPC breaking change? But if we say so then we need to revert the renaming that already happened in #33050...
<corebot>
https://github.com/bitcoin/bitcoin/issues/33183 | validation: rename block script verification error from "mandatory" to "block" by darosior · Pull Request #33183 · bitcoin/bitcoin · GitHub
<darosior>
Or we say there is no stability guarantees for strings in RPCs? That's really annoying that we don't give any clear guarantees regarding our RPC interface, downstream users are left guessing what they can rely on, and we just guess what we can break
<sipa>
in which RPCs does it get exposed?
<darosior>
In errors when submitting a transaction
<darosior>
And i suppose in errors when submitting a block?
jon_atack has joined #bitcoin-core-dev
w0xlt has joined #bitcoin-core-dev
<darosior>
I guess i'll push the release note to 33183 already. If we are to break the interface, it might as well at least be consistent
<sipa>
yeah
jonatack has quit [Ping timeout: 245 seconds]
<eugenesiegel>
release note is helpful, the change will break lnd's string parsing
jonatack has joined #bitcoin-core-dev
w0xlt has quit [Ping timeout: 255 seconds]
jon_atack has quit [Ping timeout: 252 seconds]
w0xlt has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
<darosior>
Ugh, good to know. I'm leaning toward avoiding an unnecessary break.
<darosior>
Actually the reason for the break is that #33050 dropped the detection, so without renaming it could have returned "non-mandatory" for consensus checks which would be a silent break. At least renaming makes it an explicit break.
<sipa>
eugenesiegel: for 33050 it's probably inevitable, because there is less validation actually done that could distinguish between formerly-observably-distinct cases?
kevkevin has quit [Remote host closed the connection]
<eugenesiegel>
sipa: I'm confused, is it because if the error string "non-mandatory-script-verify-flag" were kept, it would mask some consensus failures especially to downstream users? And that introducing a new error string is more correct?
<eugenesiegel>
fwiw, I don't have an issue with the change
<gmaxwell>
glozow: So whats with setting the mining fee to 1s/vkb? In the interest of timelyness I'll be tested acking the PR shortly, regardless, but I think setting that below the relay fee is a mistake. At least in my thinking the ideal way to roll out changes to minfeerate is to first decrease relay feerates then once the network has widely absorbed that change, lower mining feerates--... and if
<gmaxwell>
increasing go the other way, increase mining feerates then once few blocks include increase relay feerates. Is the assumption now just that too many miners are objectively hostile to the functioning of the network that there is no hope of doing a staged deployment anymore?
<gmaxwell>
W/ the mining feerate essentially mooted it means that any future update that lowers relay feelrates will immediately result in mining txn that have very poor propagation, which would be against the interests of the network. Even right now, say there are miners that have mining set to 1000 or 100 but have relay set to a non-default setting of under 100 will immediately start mining at that
<gmaxwell>
level, which won't relay well even with the PR deployed.
jonatack has joined #bitcoin-core-dev
<gmaxwell>
and while there are good arguments that 100 is plenty for anti-DOS so it's an easy decision to match whats being mined... if this PR did result in 1s/vkb being mined that would be a much more difficult question.
jon_atack has quit [Ping timeout: 244 seconds]
<gmaxwell>
But happy to hear if I'm just missing another perspective.
twistedline has quit [Ping timeout: 245 seconds]
joetor5 has joined #bitcoin-core-dev
jon_atack has joined #bitcoin-core-dev
Cory23 has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 244 seconds]
twistedline has joined #bitcoin-core-dev
Cory81 has quit [Ping timeout: 250 seconds]
twistedline has quit [Remote host closed the connection]
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
<_aj_>
gmaxwell: the thought from two years ago when we were looking at #26933 and #27018 was that we don't want things sitting in our mempool that we'll never consider for mining (eg, they might block us from accepting some tx we would mine due to rbf shenanigans). if miners are setting relay/incremental to sub-100, then already seems likely they'll also set blockminfee to a similar value
<corebot>
https://github.com/bitcoin/bitcoin/issues/27018 | mempool / miner: regularly flush <=0-fee entries and mine everything in the mempool by glozow · Pull Request #27018 · bitcoin/bitcoin · GitHub
<gmaxwell>
_aj_: sure not on an ongoing basis, but as some transitional thing I think harmless. There isn't a particular cost in stuff sitting in mempools and not getting mined. In practice what has happened in the past with prior transitions is that a few parties moved earlier, and clearted them out.
<gmaxwell>
_aj_: I think the alternative is to make infrastructure for defaults that chage on flag heights.
<gmaxwell>
change*
<_aj_>
yeah, flag heights/mediantimes would be my preference
<gmaxwell>
Basically, I agree relay policy and mining policy should match-- but when policy change paradoxically making your local relay and mining policy *not* match can make the two match better network wide.
<gmaxwell>
but yeah I suppose a flag point would be just superior across the board.
joetor5 has quit [Remote host closed the connection]
joetor5 has joined #bitcoin-core-dev
joetor5 has quit [Client Quit]
<bitcoin-git>
[bitcoin] ajtowns opened pull request #33191: net: Provide block templates to peers on request (master...202508-sendtemplate1) https://github.com/bitcoin/bitcoin/pull/33191
l0rinc has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
l0rinc has quit [Client Quit]
jon_atack has quit [Ping timeout: 245 seconds]
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 252 seconds]
sliv3r__ has quit [Server closed connection]
sliv3r__ has joined #bitcoin-core-dev
l0rinc has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
joetor5 has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 255 seconds]
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 260 seconds]
Cory43 has quit [Quit: Client closed]
Cory43 has joined #bitcoin-core-dev
kevkevin has joined #bitcoin-core-dev
hernanmarino has quit [Server closed connection]
hernanmarino has joined #bitcoin-core-dev
<sipa>
gmaxwell: i think the reduction to 1 sat/kvB is really a "there shouldn't be a separate rule for what to mine from the mempool, the mempool itself should be good enough at only accepting good things"
<sipa>
though i think there have been some suggestions that that should be a change to consider separately from the minrelayfee reduction PR
<sipa>
gmaxwell: i hadn't really considered your perspective here of seeing it as a way to coordinate ability to relay/mine separately, though - i thought it was mostly a way to allow miners to set a per-byte cost to including a transaction (due to the increased propagation delay including would cause the transaction to have), which is mostly outdated compact-blocks
PaperSword1 has joined #bitcoin-core-dev
PaperSword1 is now known as PaperSword
kevkevin has quit [Remote host closed the connection]