<bitcoin-git>
[bitcoin] KaueTech closed pull request #33139: Add Docker support with multi-arch build and user permissions handling (master...add-docker-support) https://github.com/bitcoin/bitcoin/pull/33139
<sipa>
i'm working on a small PR to improve/control/observe memory usage in TxGraph, but review can shift to sdaftuar's PR now
w0xlt has quit [Ping timeout: 240 seconds]
<sipa>
i had a few ideas on improving SFL too during my offline vacation too, will post about in due time, nothing urgent about that
<sipa>
that's it for me
<achow101>
#topic MuSig2 WG Update (achow101)
<achow101>
#29675 is the final PR and is ready to be reviewed. I've addressed the current comments as well as pulling in several of the followup suggestions from #31244.
<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
<sipa>
darosior: i have a very last minute, possible-even-simpler idea for getting rid of WITNESS_STRIPPED, will either open a PR in the next hour or so, or review #33105
<darosior>
darosior: nice. Feel free to ping me, i'm reviewing stuff for feature freeze today
<darosior>
s/darosior/sipa
<sipa>
haha
<l0rinc>
fanquake: first is a test that was dead for some time and we've modified related code in this release; second is a very common complaint for people that they don't know why IBD is suddenly getting slow.
<hodlinator>
fanquake: Will look into making it more clear. But essentially the release process will probably bump some values which will make tests cover less realistic behavior. Sorry for the redundancy.
<achow101>
#topic should #33106 be backported before 29.1 is released (darosior)
<corebot>
https://github.com/bitcoin/bitcoin/issues/33106 | policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee by glozow · Pull Request #33106 · bitcoin/bitcoin · GitHub
<darosior>
So it seems like we agree it should be on the milestone for 30, but what do people think of backporting it to 29.1 (currently in rc1)?
<glozow>
There will be an rc2 fosho
<TheCharlatan>
makes sense imo
<Murch[m]>
with such a big portion of transactions being below 1 s/vB it seems reasonable to me
<darosior>
I initially thought it was too late for .1 and it'd have to go in .2, but maybe that's too much churn for release managers? What do maintainers say
<glozow>
^that was me saying it can go in .1
<Murch[m]>
Should be tested a bit more, though, especially if we not just roll it out to the new release but also backport it
<darosior>
(I also think it should be backported, that's what i'm bringing it up)
<glozow>
It doesn't seem like something we'd normally backport
<darosior>
Murch[m]: yeah, still no review. I've been going through it this morning but definitely needs more eyes to be sneaked into post rc1
<sipa>
i was trying to measure how much memory cluster mempool uses per transaction... "getmempoolinfo" -> "usage": 6217176... that can't be right?!
<achow101>
we don't usually backport features
<fanquake>
this isn't a feature though?
<fanquake>
it's fixing compact block relay
<fanquake>
if we do backport it to 29, then it should also go to 28
<dergoegge>
since block relay is degraded, it makes sense to backport
<glozow>
I agree it's closer to a bug fix than a feature
<lightlike>
yes, an adaptation to changed fee condition, so it's a fix
<sipa>
we have treated softfork activations as "bug fixes", which is why they tend to be in .1 releases... in the sense that network conditions have changed, and bitcoin core needs to adapt to those
<darosior>
I guess this boils down to "how much would backporting it in 29.1 provide a relief for the current network conditions?" which i gets boils down to whether we expect 29.1 to be out before 30.
bugs_ has quit [Quit: Leaving]
<achow101>
uptake of minor releases after a major release is made is usually not that high
<fanquake>
if this pr hadn't come up, 29.1 likely would have been out within a week or so
<fanquake>
and I'd say adoptoin of 29 is currently blocked somewhat, on the existence of the .1
<Murch[m]>
Also, just a few nodes rolling out with the new mempool policy will probably drastically alleviate the issue for any nodes that upgrade
<sipa>
and 29.2, if any, likely comes after 30.0?
<fanquake>
likely
<achow101>
sipa: yeah
<fanquake>
has anyone found any issues with the rc1, in their testing so far?
<sipa>
i think it's not unreasonable to backport a change like this given the network conditions, but whether it's worth doing does seem to depend on the realistic timing of getting the release out
<darosior>
fanquake: i haven't, but haven't gone out of my way to try and test edge cases either
<fanquake>
sipa: I'd think ~4-7 days post backporting it
<achow101>
at best 29.1 will be out 2 months before 30, i guess that's not too bad
<jon_atack>
29.1 inclusion seems based on review/testing then
<darosior>
re rc1: it's also not like there is new features to exercise, and i don't run a mining pool to just be able to say "didn't break my operations" 🤷
<achow101>
probably more like 1 month though
<darosior>
achow101: 2 months (or even a bit less) seems like a win
<fanquake>
why 1 month?
<fanquake>
That'd mean it takes a month to review this PR, and run an rc2
<achow101>
v30 is targeted for Oct 3. reviewing, merging, and backporting 33106, then rc that, then release in 3 weeks?
<achow101>
s/in/within
<fanquake>
Why would that take 3 weeks though?
<achow101>
seems actually a bit tight with the way we usually do things
jespada has joined #bitcoin-core-dev
<darosior>
Seems like it's highly dependent on the time it'll take to get it reviewed. Should we try to coordinate to get it properly reviewed within the next week?
<achow101>
anyways, i don't feel that strongly about it
<sipa>
yeah let's first try to get it in master
zeropoint has joined #bitcoin-core-dev
jespada_ has quit [Ping timeout: 244 seconds]
<jon_atack>
yes
<achow101>
Any other topics to discuss?
<fanquake>
rc1 testing
<achow101>
#topic v29.1rc1 testing (fanquake)
<fanquake>
Curious to hear what testing has happend etc, amongst core contributors
<fanquake>
Given rc1 has been out for a week or so
<dergoegge>
haven't tested it at all
<sipa>
i was unaware :s
<darosior>
Not much. Been running it on one of my nodes (where i was manually looking at reconstructions before b10c rolled into the thread with proper stats). It's also the binary i used to generate the stats i shared on the minrelaytxfee PR.
<achow101>
have it on one of my nodes, but that's all
<darosior>
I could test it with downstream software (like running functional tests of wallets). But that would only reveal things like RPC breakage which would be very unlikely for a point release. I think my time is better spent elsewhere
<dergoegge>
looks like lnd is using it in CI
<darosior>
oh nice
<dergoegge>
nvm they use .0 (got confused by a comment saying rc1 can be good for testing)
<eugenesiegel>
I heard that the change does not break things in lnd
<sipa>
it'd be very surprising if it did, i think
<sipa>
but still, good to know
<achow101>
Anything else to discuss?
<l0rinc>
yes, I've investigated the excessive header hash calculations
<l0rinc>
phantomcircuit: I've removed almost all header hashing duplication logic, but it doesn't seem to result in any IBD or reindex speedup - guess hashing is just really fast.
<l0rinc>
There is a tiny speedup for headers sync and a few places where it's trivial to deduplicate, I might push a PR for that later.
MrHAPPY has joined #bitcoin-core-dev
<sipa>
l0rinc: are you on hardware with sha256 hw acceleration? since we do care about validation time on hardware without, it may make sense to disable that if you are
<darosior>
l0rinc: how did you remove the duplicate hashing? Caching? What's the excess memory usage?
jerryf has quit [Remote host closed the connection]
jonatack has joined #bitcoin-core-dev
jerryf has joined #bitcoin-core-dev
<l0rinc>
just local caching usually, e.g. instead of iterating the headers twice, getting the hashes each time, I've merged the loop
<l0rinc>
and in other cases just passing them along with the block in a new parameter - not the pretties solution, but wanted to see first if there's any difference
<l0rinc>
*merged the two loops
<achow101>
l0rinc: were you able to find what the cause was? iirc we found it was being bounded by the block download window
<corebot>
https://github.com/bitcoin/bitcoin/issues/29415 | Broadcast own transactions only via short-lived Tor or I2P connections by vasild · Pull Request #29415 · bitcoin/bitcoin · GitHub
jonatack has quit [Ping timeout: 240 seconds]
l0rinc has quit [Quit: l0rinc]
w0xlt has quit [Ping timeout: 272 seconds]
Guest2 has joined #bitcoin-core-dev
Guest2 has quit [Client Quit]
Christoph_ has joined #bitcoin-core-dev
Christoph_ has quit [Client Quit]
Naiyoma has quit [Ping timeout: 244 seconds]
robobub has joined #bitcoin-core-dev
mudsip has joined #bitcoin-core-dev
w0xlt has joined #bitcoin-core-dev
mudsip has quit []
enochazariah has quit [Quit: Client closed]
l0rinc has joined #bitcoin-core-dev
Guest6560 has joined #bitcoin-core-dev
eugenesiegel has quit [Quit: Client closed]
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 265 seconds]
Christoph_ has joined #bitcoin-core-dev
valwal___ has quit [Server closed connection]
valwal___ has joined #bitcoin-core-dev
<achow101>
33106 is not a clean backport
jespada_ has joined #bitcoin-core-dev
<sipa>
#33106
<corebot>
https://github.com/bitcoin/bitcoin/issues/33106 | policy: lower the default blockmintxfee, incrementalrelayfee, minrelaytxfee by glozow · Pull Request #33106 · bitcoin/bitcoin · GitHub
jespada has quit [Ping timeout: 272 seconds]
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 248 seconds]
Christoph_ has quit [Quit: Christoph_]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
l0rinc has quit [Quit: l0rinc]
l0rinc has joined #bitcoin-core-dev
abubakarsadiq has quit [Quit: Connection closed for inactivity]
<bitcoin-git>
[bitcoin] l0rinc opened pull request #33154: test: use local `CBlockIndex` in block read hash mismatch check (master...l0rinc/readblock-hash-mismatch-test) https://github.com/bitcoin/bitcoin/pull/33154
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 272 seconds]
Guest6560 has quit [Quit: WeeChat 4.1.1]
l0rinc has quit [Quit: l0rinc]
l0rinc has joined #bitcoin-core-dev
<Murch[m]>
If anyone is interested in playing around with a signet relaying a lot of transactions below 1 s/vB, you can join this one: