19:00:17 <laanwj> #startmeeting 
19:00:18 <core-meetingbot`> Meeting started Thu Jan 13 19:00:17 2022 UTC.  The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:18 <core-meetingbot`> Available commands: action commands idea info link nick
19:00:34 <hebasto> hi
19:00:35 <laanwj> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball
19:00:37 <laanwj> morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
19:00:43 <achow101> hi
19:00:45 <michaelfolkson> hi
19:00:56 <cfields> hi
19:00:56 <laanwj> welcome to the weekly general bitcoin-core-dev meeting
19:01:00 <kvaciral[m]> hi
19:01:11 <b10c> hi
19:01:22 <provoostenator> hi
19:01:55 <laanwj> there have been no proposed meeting topics this week (this can be done using #proposedmeetingtopic <topic>), any last-minute ones?
19:02:06 <sipa> hi
19:03:57 <laanwj> #topic High priority for review
19:03:57 <core-meetingbot`> topic: High priority for review
19:04:01 <jonatack> hi
19:04:44 <laanwj> https://github.com/bitcoin/bitcoin/projects/8 has 8 blockers, no bugfixes, 1 chasing concept ACK at the moment
19:04:55 <laanwj> anything to add, remove, or that is ready for merge?
19:05:01 <MarcoFalke> can i haz #23629
19:05:02 <gribble> https://github.com/bitcoin/bitcoin/issues/23629 | refactor tests to fix ubsan suppressions by MarcoFalke · Pull Request #23629 · bitcoin/bitcoin · GitHub
19:05:32 <jonatack> #22932 has ACKs by hebasto and achow101 (thanks!), might need one more
19:05:35 <gribble> https://github.com/bitcoin/bitcoin/issues/22932 | Guard CBlockIndex::nStatus by cs_main, require GetBlockPos/GetUndoPos to hold cs_main by jonatack · Pull Request #22932 · bitcoin/bitcoin · GitHub
19:05:36 <_aj_> laanwj: #23508
19:05:37 <gribble> https://github.com/bitcoin/bitcoin/issues/23508 | Add getdeploymentinfo RPC by ajtowns · Pull Request #23508 · bitcoin/bitcoin · GitHub
19:06:27 <jeremyrubin> hi!
19:06:41 <laanwj> MarcoFalke _aj_: added
19:06:57 <laanwj> jonatack: good to know, will take a look
19:07:52 <jonatack> I've tried to diff-review #22702 after ACKing it a few months ago, but it requires a fresh re-review. Planning to do that.
19:07:54 <gribble> https://github.com/bitcoin/bitcoin/issues/22702 | Add allocator for node based containers by martinus · Pull Request #22702 · bitcoin/bitcoin · GitHub
19:08:13 <jonatack> laanwj: thanks
19:08:21 <jeremyrubin> #proposedmeetingtopic release processes / feature freezes / best practice & optionality w.r.t. BIP-119 for non-deployment code
19:08:26 <laanwj> it's a pretty tough PR to review, but would be good to have more eyes on it
19:09:11 <MarcoFalke> Maybe we should be holding back on risky stuff until after the branch off?
19:09:12 <jonatack> yes, agree, i need to go through it fully again
19:10:24 <laanwj> MarcoFalke: which one do you consider especially risky?
19:10:40 <MarcoFalke> The allocator stuff?
19:10:54 <MarcoFalke> (Not a expert on that, maybe it is not risky at all)
19:10:55 <jonatack> true
19:11:25 <laanwj> yes, ok, agree it's better to merge that at the beginning of a merge window instead of the end, but don't think it's done reviewing yet anyhow
19:11:51 <_aj_> we're ~four weeks from freeze, ~six weeks from branching?
19:12:03 <jeremyrubin> feb 15 feature freeze
19:12:08 <laanwj> _aj_: yep
19:12:21 <MarcoFalke> two weeks from translation soft freeze
19:13:17 <laanwj> #topic Release processes / feature freezes / etc (jeremyrubin)
19:13:17 <core-meetingbot`> topic: Release processes / feature freezes / etc (jeremyrubin)
19:13:37 <jeremyrubin> ok so for #21702
19:13:42 <gribble> https://github.com/bitcoin/bitcoin/issues/21702 | Implement BIP-119 Validation (CheckTemplateVerify) by JeremyRubin · Pull Request #21702 · bitcoin/bitcoin · GitHub
19:14:25 <jeremyrubin> i'm curious to know if there is a loss of "optionality" given usual precedent of merging non-activated code in a prior maj release that would motivate merging -- while still being reviewed / discussed for activation -- the CTV code
19:14:44 <jeremyrubin> if there is no loss of optionality in terms of normal release practices, it doesn't matter much
19:15:05 <jeremyrubin> (this was a discussion topic output from Tuesday's meeting)
19:15:41 <jeremyrubin> One of the considerations for doing it is e.g. the ease of backporting the feature to the last major version, for example.
19:15:52 <michaelfolkson> To state the obvious for observers there are many premature activation concerns on BIP 119 https://gist.github.com/michaelfolkson/352a503f4f9fc5de89af528d86a1b718
19:16:08 <provoostenator> I'm not sure about optionality,  but increasing complexity of consensus code - even in code paths that aren't hit - always carries some risk.
19:16:25 <michaelfolkson> I know Jeremy will keep his head in the sand regardless but for the sake of observers
19:17:23 <provoostenator> The patch is probably already as short as it gets, but you can always try to split of more stuff into seperate PR's if they have dual use.
19:18:04 <provoostenator> But after that I think rebase-purgatory is the place to be until there's broad consensus that people want this soft fork.
19:19:53 <jeremyrubin> provoostenator i think that's reasonable, I just want to ensure that "code wasn't in 0.2x" to contribute to a 6mo-1yr delay on a possible release timeline once that does exist, however it is to be measured (optionality)
19:20:01 <_aj_> backporting a small patch to older versions seems plausible for CTV compared to taproot or segwit too
19:20:16 <provoostenator> Backporting isn't necessarily easier; if you get some code in now and then have to dramatically change it later, including in backports, life isn't much easier.
19:21:36 <provoostenator> You could even maintain a patch with test on earlier branch to demonstrate that it's indeed not a problem.
19:23:34 <jeremyrubin> provoostenator that does seem doable I guess? once e.g. the split off happens I could rebase once onto the 0.23 and freeze that even if other branch needs updates
19:23:54 <provoostenator> I also tend to agree with your point above (before the meeting) that many changes you need for mempool and wallet handling are useful in general.
19:24:27 <provoostenator> jeremyrubin: at first glance that seems doable, but maybe a waste of time if nobody actually has that concern.
19:25:40 <provoostenator> And demonstrating CSV in a working and user friendly Core wallet might help increase excitement / decrease worries.
19:25:42 <jeremyrubin> i think the main negative impact (outside of bug/complexity) would be prematurely impacting the PrecomputedData code path, if it were merged now. It's not a huge overhead though, but it is something.
19:25:54 <provoostenator> * CTV
19:26:05 <jeremyrubin> One of the benefits of merging would be having a signet client with CTV validation
19:26:12 <jeremyrubin> that would aid testing
19:26:35 <provoostenator> I think Signet users can be expected to know how to compile though.
19:26:49 <jeremyrubin> fair
19:27:10 <provoostenator> That would be a good use case for maintaining a release branch
19:27:28 <provoostenator> So people can test with stable release + patch, rather than master + patch.
19:27:40 <jeremyrubin> are any maintainers able to weigh in on what advocates of CTV should be doing/aiming for? your input is valauble here too
19:28:22 <jeremyrubin> if you don't want to talk about CTV in particular, can talk generally about what OP_FOOBAR should do in the future
19:28:43 <achow101> I agree with provoostenator
19:29:36 <jeremyrubin> what do we think about doing what provoostenator but actually doing a release build of 23.0+experimental? So then people can just grab a binary
19:29:52 <provoostenator> jeremyrubin: you can just do that
19:30:19 <provoostenator> Should be -  if it isn't yet - a matter of maintaining a fork branch and some Guix tweaks
19:30:23 <jeremyrubin> sure, happy to. but if i'm the only signer i'd not advise people to run it
19:30:23 <_aj_> jeremyrubin: (i'd consider running out-of-tree code to mine ctv blocks on the real signet, though that would also mean figuring out how to make txs propogate, but there's a bunch of higher priority things on my todo list)
19:30:26 <provoostenator> So it'll even be reproducable
19:31:11 <jeremyrubin> _aj_: yeah, this is why when i looked into "can't i just make the signer on signet run the new code" it wasn't a workable option
19:31:41 <provoostenator> I think it warrants a fresh signet,.
19:32:47 <_aj_> jeremyrubin: (eh, i've tried code in the past to combine p2p service bits with consensus versionbits so nodes running a new fork can talk to each other; it's just work)
19:34:55 <jeremyrubin> _aj_: i'd be a bit out of my depth working on that and i don't want to impose on your time to do that; a new signet seems the simplest to make it happen. would be nice if could be done from the latest release without downloading a new thing, but that burden shouldn't be too large...
19:35:09 <provoostenator> Custom signet would also let you massively constrain block space there, which could be handy for testing.
19:35:59 <provoostenator> jeremyrubin: afaik you can point bitcoin.conf to arbirary signets
19:36:00 <_aj_> jeremyrubin: anyone trying to use a new consensus feature needs to be able to build their own wallet etc anyway, compiling their own bitcoind should be the least of their worries
19:36:22 <_aj_> provoostenator: (not if bitcoind doesn't support the opcode you're trying to test -- it won't be accepted into the mempool)
19:36:28 <jeremyrubin> _aj_: you can use sapio studio somewhat off the shelf right now
19:36:45 <jeremyrubin> but i guess that counts as "build" your own, less so "implement" your own
19:36:51 <provoostenator> _aj_: I'm assuming the signet is used with the custom branch or custom binary.
19:37:15 <_aj_> provoostenator: if it's a custom branch, you could add a new -chain=ctvsignet option i suppose
19:37:19 <provoostenator> But the patch itself won't be more complicated for using the custom signet.
19:41:15 <laanwj> any other topics?
19:43:06 <laanwj> #endmeeting