Zenton has quit [Remote host closed the connection]
Zenton has joined #bitcoin-core-dev
codingp110 has joined #bitcoin-core-dev
codingp110 has quit [Quit: Client closed]
Zenton has quit [Remote host closed the connection]
Zenton has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] maflcko opened pull request #31481: fuzz: Faster leak check, and SeedRand::ZEROS before every input (master...2412-fuzz-stable-fast) https://github.com/bitcoin/bitcoin/pull/31481
<achow101>
There are no preproposed meeting topics this week. Any last minute ones to add?
moresteakpls has joined #bitcoin-core-dev
<achow101>
#topic Erlay WG Update (sr_gi, gleb, marcofleon)
<maxedw>
hi
<sr_gi[m]>
That's me
<sr_gi[m]>
We've been compiling a list of simulations to run, writing down design decision so we can re-evaluate if needed down the line and see what has been considered. I've been updating the simulator and started to simulate some of them. The PR has also been brought up to date with the pending feedback. Gleb is working on a rebase of the whole Erlay implementation so some things can also be tested with real nodes in a warnet-like environment,
<sr_gi[m]>
plus also reviving his simulator to run cross sims
guest_glozow has joined #bitcoin-core-dev
<sr_gi[m]>
There has also been some fuzzing by marko pointing out bugs to fix
<sr_gi[m]>
I think that's it
<achow101>
#topic Kernel WG Update (TheCharlatan)
<marcofleon>
I'm looking to fuzz more once the rebase is done. And still wrapping my head around some of the design stuff
<TheCharlatan>
Skipped the last few updates, so I'll do a drop of what I've been working on.
<TheCharlatan>
I opened some more PRs for de-duplicating and simplifying logic for potential future users of the lib.
<TheCharlatan>
Moving the final flush before shutdown to the ChainstateManager destructor: #31382 . This simplifies the tear-down procedure for the library significantly.
<TheCharlatan>
After seeing the recent demand for better script debuggers, I was thinking how the kernel library might be useful for this in the future. It seems like btcdeb is not really usable for external projects, or projects extending the script interpreter.
<TheCharlatan>
The hooks are gated by a macro, so users would have to compile with `ENABLE_SCRIPT_DEBUG`.
<TheCharlatan>
This might be more viable than btcdeb for these kind of users, since only the interpreter itself would have to be changed for supporting new functionality, leaving changing the output of the debugger entirely up to the user. It could also be used to better test some of the internals of the interpreter.
MyNetAz has joined #bitcoin-core-dev
<sipa>
hi
<TheCharlatan>
Lastly, I'd like to point out the RFC PR #31425, which checks that the static libbitcoinconsensus can be compiled for 32bit riscv bare metal.
SpellChecker has quit [Remote host closed the connection]
<sipa>
there remains one critical piece of logic at the TxGraph layer before the full cluster mempool code can be rebased on it (#28676), namely exposing an interface to deal with (too big) reorgs, as it is possible that reorgs merge the entire mempool together into a single cluster, and we need to do *something* in that case (we can't just reject them like RBFs)
<sipa>
that said, there is enough code in 31363 and 31444 that deserves review, and it's complete with a simulation test that i think covers most if not all of the behavior we want from it
SpellChecker has joined #bitcoin-core-dev
<sipa>
in particular, i'm quite happy with how the test simulates mempool changesets: the transactions are stored in shared_ptrs, so to start a changeset, the simulation graph is just copied, on abort it's deleted, on commit it replaces the main graph
<sipa>
that's it from me, unless there are questions/comments
<instagibbs>
appreciate the additional context provided by newest PR, im finding it a bit difficult to do a deep review without the whole thing
<sipa>
would it help to have a writeup of what txgraph's responsibility is, and what the hard problems it solves are?
jonatack has quit [Ping timeout: 244 seconds]
<sipa>
in order to get review in before the full thing is PRed?
<instagibbs>
Hard to say, I'm having difficulty judging if the API is sensible if I don't actually see it used in anger
<instagibbs>
some things are obviously correct, others im unsure
<sipa>
fair point
<sipa>
i guess i can't really help with that apart from getting closer to a point where 28676 can be rebased
itsarjn has joined #bitcoin-core-dev
<instagibbs>
will circle back after looking at newest PR
<achow101>
#topic MuSig2 WG Update (achow101)
<achow101>
A couple fuzz crashes were found in #31247 which have been fixed
<achow101>
The next PRs to review are still #31242 and #31243
<gribble>
https://github.com/bitcoin/bitcoin/issues/31242 | wallet, desc spkm: Return SigningProvider only if we have the privkey by achow101 · Pull Request #31242 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/31243 | descriptor: Move filling of keys from `DescriptorImpl::MakeScripts` to `PubkeyProvider::GetPubKey` by achow101 · Pull Request #31243 · bitcoin/bitcoin · GitHub
<achow101>
#topic Legacy Wallet Removal WG Update (achow101)
<achow101>
In reviewing #30328, we've been finding some additional migration edge cases, and further edge cases in the PRs to fix those edge cases.
<gribble>
https://github.com/bitcoin/bitcoin/issues/31451 | wallet: migration, avoid loading legacy wallet after failure when BDB isnt compiled by furszy · Pull Request #31451 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/31423 | wallet: migration, dont create spendable wallet from a watch-only legacy wallet by furszy · Pull Request #31423 · bitcoin/bitcoin · GitHub
<achow101>
These edge cases aren't additional scripts that should be migrated, just different wallet configurations that caused migration failures or could be migrated in a better way.
<achow101>
So already migrated wallets don't need to worry
<sipa>
ah good
<achow101>
Lastly, #30328 has been getting review and is being updated to be clearer on why it is doing some things
<achow101>
IsMine has been reported to be very confusing to reviewers so I've been trying to make it clearer as to why the replacement code is correct
<achow101>
#topic Multiprocess WG Update (ryanofsky)
<ryanofsky>
hi
<ryanofsky>
There's a backlog of PRs in #31098 that have one or two acks and could use another review to get unstuck. These are needed to get IPC mining features enabled in the next release
<ryanofsky>
Another thing that happened recently darosior has written rust code to be able to call the Chain interface over IPC. Can see his comments in #29409
<ryanofsky>
There's a lot that needs to come together
<TheCharlatan>
will the release be macos and linux only?
<fanquake>
Does our code-signing for macOS need any accomodations for multiprocess? i.e some entitlement to spawn other bins or similar
brunoerg has quit [Remote host closed the connection]
Zenton has quit [Remote host closed the connection]
<ryanofsky>
Unless I get windows support together in time I think so. There's an issue in the libmultiprocess repo saying what needs to be done but I haven't started that yet
<TheCharlatan>
ok
<ryanofsky>
fanquake, pretty sure that's not true. If that's the case the wrapper executable would also have problems
<fanquake>
Ok, great if that doesn't need any other changes
<achow101>
It doesn't seem like there's an entitlement for that. But the other bins will also need to be codesigned
<ryanofsky>
In worst case first multiprocess release would just be linux only which is probably ok
<achow101>
presumably we'd ship both multiprocess and monolithic for a while
<ryanofsky>
well the multiprocess release should include both sets of binaries
<ryanofsky>
(long discussion about that in #30983)
<sipa>
i think it would be good to try to end up with just a single type eventually
guest_glozow has quit [Quit: Client closed]
<sipa>
if multiprocess can do everything that normal builds can, there is no need to keep supporting more configurations longer
<sipa>
but not as long as there compatibility issues or other hassles with it of courde
<achow101>
ok, will read through the discussion in 30983
<ryanofsky>
sipa, i think biggest issue there is performance. gui and wallet interfaces are not really optimized to work well over ipc, but they could be
<sipa>
ryanofsky: thanks, will rrad
<sipa>
huh, that surprises me a bit
<ryanofsky>
i think they are mostly just doing a lot of stupid things that add latency. if you run functional tests with ipc there is a definite slowdown
<achow101>
#topic package relay WG Update (glozow)
<achow101>
glozow says "We’re making steady progress on #31397, and I would like to find additional reviewers for #31385."
<gribble>
https://github.com/bitcoin/bitcoin/issues/31385 | package validation: relax the package-not-child-with-unconfirmed-parents rule by glozow · Pull Request #31385 · bitcoin/bitcoin · GitHub
Guyver2 has left #bitcoin-core-dev [Closing Window]
<achow101>
Anything else to discuss today?
<achow101>
#endmeeting
bitdex has quit [Quit: = ""]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
moresteakpls has quit [Quit: Client closed]
jonatack has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<sipa>
TheCharlatan: in general i can't say i'm a fan of adding complexity to the script interpreter just for the purpose of inspection/debugging, but i have to say this approach you have is really extremely limited in how intrusive it is
mcey_ has joined #bitcoin-core-dev
<darosior>
I agree, although i'm not really sure what's wrong with btcdeb.
emcy__ has quit [Ping timeout: 248 seconds]
brunoerg has quit [Remote host closed the connection]
<dergoegge>
Would be cool if projects like that could use the kernel to make sure they don't incorrectly re-implement the interpreter
<dergoegge>
darosior: not sure if btcdeb could accomplish this as well?
Zenton_ has joined #bitcoin-core-dev
Zenton has quit [Read error: Connection reset by peer]
<darosior>
wow, did they reimplement the Script interpreter in lua? lol
Zenton_ has quit [Remote host closed the connection]
Zenton_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<darosior>
dergoegge: it probably could. But i was mostly replying to `btcdeb` being hard to use (i used it in the past and found it pretty helpful). But given it is unmaintained and i'm not volunteering to rebase it, TheCharlatan's patch is probably the most pragmatic approach to give people external to the project the tools to experiment with the
<darosior>
interpreter. And i agree it's a worthwile goal.
Zenton_ has quit [Quit: Leaving]
<dergoegge>
darosior: they did at least partially
brunoerg_ has joined #bitcoin-core-dev
brunoerg has quit [Read error: Connection reset by peer]
Zenton has joined #bitcoin-core-dev
brunoerg_ has quit [Remote host closed the connection]