<bitcoin-git>
bitcoin/master 33268a8 Max Edwards: test: exit with code 1 when no fn tests are found
<bitcoin-git>
bitcoin/master 59567d7 fanquake: Merge bitcoin/bitcoin#29576: Update functional test runner to return error...
<bitcoin-git>
[bitcoin] fanquake merged pull request #29576: Update functional test runner to return error code when no tests are found to run (master...fn-test-runner-no-tests) https://github.com/bitcoin/bitcoin/pull/29576
szkl has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
jon_atack has quit [Ping timeout: 246 seconds]
AaronvanW has joined #bitcoin-core-dev
BrandonOdiwuor has quit [Ping timeout: 250 seconds]
Srishti has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dergoegge opened pull request #29583: fuzz: Apply fuzz env (suppressions, etc.) when fetching harness list (master...2024-03-ubsan-sup) https://github.com/bitcoin/bitcoin/pull/29583
scare_crow has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 264 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
TheRec has quit []
jon_atack has joined #bitcoin-core-dev
jonatack has quit [Ping timeout: 246 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
<bitcoin-git>
[bitcoin] fanquake opened pull request #29585: contrib: list other binaries in manpage output (master...list_other_pages_in_man) https://github.com/bitcoin/bitcoin/pull/29585
<sdaftuar>
Hi, I pushed a rebase of the draft PR (#28676) this morning. This is still not a fully optimized implementation, and as a reminder the plan is still to re-engineer this to be awesome before moving the PR out of draft.
<sdaftuar>
In the meantime, interested reviewers can run this branch locally and collect their own benchmarking information if they’d like. Also, you can use the `getmempoolfeesize` rpc to produce a feerate diagram of the whole mempool, which is fun to look at.
<sdaftuar>
For now, anyone looking to help can look at the test changes in the draft PR and start thinking about ways to improve what I’ve done (or fix tests I’ve broken) or add additional test coverage.
<sdaftuar>
In a few weeks, I’ll likely start pinging people for help with changes to mini_miner and the wallet.
<sdaftuar>
Currently, I’m starting do some initial benchmarking of how the current (unoptimized) implementation performs on historical data, and comparing with master.
<sdaftuar>
These findings will be most interesting once we have a more fully optimized transaction graph module to use, but I can report some initial statistics on this unoptimized implementation to give everyone a sense of what we’re at right now, and to start answering some of the questions I posed in the OP of #28676.
<josie>
still heads down on reviewing and hashing out ideas for the libsecp module. based on that, i think id like to remove silent payments as a priority project for v28
<josie>
last week i was optimistic that the work could happen in parallel, but after trying that for a week, i dont think its a good idea
<achow101>
we can replace silent payments with legacy wallet removal since that has the next most votes
<glozow>
ACK
<josie>
yeah, seems like a better use of this meeting time
<hebasto>
achow101: maybe make priorities as pinned gh issues again?
<b10c>
hi
<achow101>
hebasto: yes, will do that
<fanquake>
don't think we can do that while we are testing rcs etc
<achow101>
we can only have 3 pinned at a time
<achow101>
#topic assumeutxo mainnet chainparams for v27 (fjahr)
<fjahr>
Hi, so it was pretty much agreed to get the assumeutxo main net chainparams in for v27. Unfortunately there are still some blockers, some of which that were not tagged for v27. So there would still be some review work needed, namely #26045 and #29519
<gribble>
https://github.com/bitcoin/bitcoin/issues/29519 | p2p: For assumeutxo, download snapshot chain before background chain by mzumsande · Pull Request #29519 · bitcoin/bitcoin · GitHub
<fjahr>
Question is if people think we should delay the release for this so that v27 can have the main net chainparams included.
<fjahr>
IMO the two PRs are not much work to review but there wasn't much action on them lately so it would need more peoples attention
<fanquake>
I don't think so. It's a shame that the relvant PR's haven't gotten review, but clearly (bad) bugs are still being found, and I don't see any conclusion to the GUI discussion?
<fjahr>
I think most people don't see the GUI as a blocker, aside from luke probably...
<lightlike>
I think we should make a decision whether it's acceptable to just have entries added to chainparams, without having any distribution mechanism.
<instagibbs>
lightlike to be clear, you mean not having some built in distribution mechanism?
<fanquake>
Sure, we can disregard the GUI, but not all the unreviewed code and remaining bugs
<fjahr>
The distribution mechanism was not part of James' proposal so if that is a blocker that should have been pointed out much earlier
<fanquake>
and I don't see a pressing reason to rush all that in, post branch of, and an rc1 tag
<lightlike>
not necessarily. we could also have consensus to put it on awbebsite, or maybe a torrent or whatever.
<sipa>
imo without distribution mechanism it's not really usable for non-expert users anyway, so i don't think having the parameters set matters much?
<achow101>
since the release cycle for 27.0 was much shorter than usual, I think it's okay that some things we thought could make it to 27.0 don't, and we can defer them to 28.0
<achow101>
i'd rather not push the release back, otherwise we get back to the inconvenient release timings that we are trying to avoid
<fjahr>
and there are good ways to get around it, I don't think we need to block people from using it like who set up a btcpayserver. They even had their own solution for this for some time.
<fjahr>
Anyone can put it in a torrent or on a website
<sipa>
fair point, these pre-packaged systems can make use of it
<instagibbs>
I agree, but I don't think delaying release is the right move
<sipa>
that may in practice mean that the distribution aspect is just handled by them
<fanquake>
If delaying the release was ever going to happen, this should have been raised weeks ago, not after branch-off
<sipa>
fanquake: agreed
<josie>
+1
<fjahr>
ok, still wanted to raise the point. I hope everyone help by keeping it in mind for v28. Thanks!
<achow101>
Any other topics to discuss?
<achow101>
#endmeeting
<instagibbs>
fjahr I think it makes sense to merge mainnet params any time once bug hunting is finished, let people start testing in more live fashion
<Chris_Stewart_5>
sdaftuar: Have you written about what you view as the deployment story for cluster mempool? I.e. deploy behind some sort of -clustermempool flag and if this isn't active use old mempool logic. If you have, please link
<sdaftuar>
Chris_Stewart_5: no special thought given to that. currently i can't think of a reason why we wouldn't just deploy in the next release after the PR is merged.
<Chris_Stewart_5>
and that means ripping out the old logic and replacing it with the new logic wholesale ?
<fjahr>
instagibbs: how do we know that bug hunting is finished? How do you measure that?
<sdaftuar>
essentially, yes. the way i've staged the branch so far is that i add the cluster implementation and limits first, and then remove the existing ancestor/descendant tracking
<instagibbs>
fjahr well, at least close out the current PRs/issues
<sdaftuar>
in theory, we could merge something that just adds cluster limits and doesn't take away the other stuff? but this seems like a worse idea to me.
<instagibbs>
if they're blockers as described
<Chris_Stewart_5>
Cool, i'll take a look in the next few weeks. That context helps with what the goal currently is and if it affects any public facing APIs
<sdaftuar>
sounds good, thanks! feel free to drop questions here or on the PR as you go through it
<fjahr>
instagibbs: If everyone would have been passionate about the chainparams we could have probably done it in a few days but it's fine, I just wanted to raise awareness but I already knew the chance were slim of that happening
<instagibbs>
just trying to encourage it to happen whenever it's ready, not wait for a release
<instagibbs>
for the first time around, later on I think syncing with releases makes sense
<bitcoin-git>
[bitcoin] Christewart opened pull request #29589: tests: Fix bug `CScriptOp.encode_op_n()` where `OP_1NEGATE` was not handled correctly (master...2024-03-07-op1neg-py) https://github.com/bitcoin/bitcoin/pull/29589
puchka has joined #bitcoin-core-dev
luke-jr has quit [Read error: Connection reset by peer]
Guest42 has joined #bitcoin-core-dev
Guest42 has quit [Quit: Client closed]
puchka has quit [Ping timeout: 264 seconds]
TheRec has quit [Read error: Connection reset by peer]
TheRec_ has joined #bitcoin-core-dev
TheRec has joined #bitcoin-core-dev
TheRec_ has quit [Read error: Connection reset by peer]