14:00:24 <achow101> #startmeeting 14:00:28 <murch[m]> Hi 14:00:28 <stickies-v> hi 14:00:31 <achow101> #bitcoin -core-dev Meeting: achow101 _aj_ amiti ariard aureleoules b10c BlueMatt brunoerg cfields darosior dergoegge dongcarl fanquake fjahr furszy gleb glozow hebasto instagibbs jamesob jarolrod jonatack josibake kallewoof kanzure kouloumos kvaciral laanwj LarryRuane lightlike luke-jr MacroFake Murch phantomcircuit pinheadmz promag provoostenator ryanofsky sdaftuar S3RK stickies-v sipa theStack TheCharlatan vasild 14:00:31 <sipa> hi 14:00:32 <RubenSomsen> hi 14:00:34 <pinheadmz> hi 14:00:34 <hebasto> hi 14:00:36 <vasild> hi 14:00:41 <gleb> hi 14:01:04 <achow101> There's one pre-proposed meeting topic this week. Any last minute ones to add to the list? 14:01:18 <fjahr> hi 14:01:38 <fanquake> #topic dergoegge merge access in qa-assets 14:01:47 <fanquake> #topic shortly release cycle for 27.0 14:02:27 <achow101> #topic package relay updates (glozow) 14:02:45 <dergoegge> hi 14:02:48 <fjahr> instagibbs commented on it before the meeting 14:03:02 <achow101> instagibbs left an update before the meeting, read that 14:03:06 <Sjors[m]> Hi 14:03:08 <achow101> #topic silent payments updates (josie) 14:03:27 <RubenSomsen> josie is back now but I think he may have gotten the meeting time wrong 14:03:47 <RubenSomsen> No big changes from last week. Still actively taking review on BIP352 and responding to feedback. For the BIP we are still discussing how to handle the outpoints: https://github.com/bitcoin/bips/pull/1458#discussion_r1395934177 14:04:07 <kanzure> hi 14:04:15 <josie> hi 14:04:17 <maxedw> hi 14:04:26 <josie> haha i did have the meeting time wrong 14:04:29 <josie> but i am back! 14:05:36 <josie> regarding the outpoints, i think we have something that works (hashing one outpoint, and some hardening), but would be nice to have a few eyes on it before i go and start updating the PRs 14:06:33 <josie> ill also be reviewing #25273 this week 14:06:36 <gribble> https://github.com/bitcoin/bitcoin/issues/25273 | wallet: Pass through transaction locktime and preset input sequences and scripts to CreateTransaction by achow101 ÷ Pull Request #25273 ÷ bitcoin/bitcoin ÷ GitHub 14:06:43 <achow101> please do 14:06:46 <josie> (looks like it has a silent merge conflict tho) 14:07:26 <achow101> hmm, thought I fixed that. will take a look today 14:07:41 <achow101> #topic multiprocess updates (ryanofsky) 14:07:44 <josie> cool, thx! 14:08:29 <ryanofsky> Main next multiprocess PR for review is #28921. There is also serialization PR #28929 which simplifies things for multiprocess code, but is not essential. There is also now a design doc being added in #28978. 14:08:31 <gribble> https://github.com/bitcoin/bitcoin/issues/28921 | multiprocess: Add basic type conversion hooks by ryanofsky ÷ Pull Request #28921 ÷ bitcoin/bitcoin ÷ GitHub 14:08:33 <gribble> https://github.com/bitcoin/bitcoin/issues/28929 | serialization: Support for multiple parameters by ryanofsky ÷ Pull Request #28929 ÷ bitcoin/bitcoin ÷ GitHub 14:08:35 <gribble> https://github.com/bitcoin/bitcoin/issues/28978 | doc: Add multiprocess design doc by ryanofsky ÷ Pull Request #28978 ÷ bitcoin/bitcoin ÷ GitHub 14:08:59 <abubakarsadiq> hi 14:09:42 <ryanofsky> That's all I have if you want to go to next topic 14:09:58 <achow101> #topic Ad-hoc high priority for review 14:10:06 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4 14:12:15 <achow101> #topic cpp-subprocess integration (hebasto) 14:12:19 <hebasto> hi all 14:12:22 <hebasto> a year and a half ago the Replacing Boost Process issue was opened -- #24907 14:12:23 <gribble> https://github.com/bitcoin/bitcoin/issues/24907 | RFC: Replacing Boost Process ÷ Issue #24907 ÷ bitcoin/bitcoin ÷ GitHub 14:12:29 <hebasto> moreover, the recently discovered issue with Boost ASIO forces us to disable the external signer support for Windows, both cross and native builds -- #28967 14:12:30 <gribble> https://github.com/bitcoin/bitcoin/issues/28967 | build: disable external-signer for Windows by fanquake ÷ Pull Request #28967 ÷ bitcoin/bitcoin ÷ GitHub 14:12:35 <hebasto> https://github.com/arun11299/cpp-subprocess was suggested as a potential alternative, which basically is a single header-only C++11 implementation of the Python's `subprocess.Popen` interface 14:12:42 <hebasto> then theStack developed a branch that replaces Boost.Process with cpp-subprocess; however, some Windows-related issues remained 14:12:48 <hebasto> I fixed all Windows-related issues and submitted a full solution in #28981. Some of my patches have been accepted upstream already; others are in progress. 14:12:50 <gribble> https://github.com/bitcoin/bitcoin/issues/28981 | Replace Boost.Process with cpp-subprocess by hebasto ÷ Pull Request #28981 ÷ bitcoin/bitcoin ÷ GitHub 14:12:54 <hebasto> the question is: if we agree to use cpp-subprocess, what is the best way to integrate this header into our code base? 14:13:01 <hebasto> during discussion in the pr, a few options were suggested: 1 - subtree (sipa); 2 - add to the repo directly and prune out the unused code (fanquake); 3 - our fork subtree (hebasto); 4 - external dependency (luke-jr) 14:13:45 <achow101> is it actively maintained? 14:13:59 <hebasto> it is 14:14:06 <fanquake> depends on your definition of maintained 14:14:16 <sipa> it looks maintained, but not really developed anymore 14:14:21 <fanquake> the author doesn't actually review things, just insta merges etc 14:15:14 <sipa> how much of the file do we need? 14:15:25 <sipa> as in, for option two, how much would we keep? 14:15:46 <hebasto> maybe ~60..70% 14:16:00 <fanquake> I just want to avoid another boost process scenario, where upstream wasn't maintained well, and no one from our side actually reviewed any of it, or checked to see how it worked/what it was doing under the hood 14:16:33 <fanquake> Obviously having a static header in our repo is an improvement, similar to nanobench/tinyformat 14:17:19 <hebasto> in that case, we can adjust code for C++17/20 14:17:28 <fanquake> If it's unlikely we'll be pulling many/any updates, that seems better than adding the burnden of a subtree, and we can still prune unused code 14:17:35 <achow101> I'd be slightly concerned with copyright if we just included it in the repo directly, especially if people come along later and decide to refactor/split it 14:17:59 <sipa> does it *need* any changes right now? 14:18:00 <fanquake> Isn't it MIT licenesed? 14:18:11 <josie> yeah its MIT 14:18:13 <fanquake> What is the copyright concern 14:18:28 <hebasto> it needs Windows-specific fixes 14:18:30 <achow101> fanquake: the copyright header still needs to follow around any bits of code that we take from the project 14:18:47 <sipa> hebasto: but it looks like you've had some success already getting fixes upstreamed 14:18:49 <fanquake> Sure, we wouldn't delete that 14:19:12 <hebasto> sipa: correct, a couple more needed 14:19:22 <fanquake> Has anyone actually tested it on non-windows yet? 14:20:05 <fanquake> Note that upstream also has no macOS CI, but I guess the assumption is no real platform specific code? 14:20:07 <Sjors[m]> Not yet, will do soon(tm) on both Linux and macOS. 14:20:10 <hebasto> I tested with ledger on windows only for now 14:20:34 <fanquake> Ok, lets actually check it works on linux on mac first then 14:21:04 <sipa> agreed 14:21:36 <hebasto> okay 14:21:48 <Sjors[m]> Make sure to test QT, not just the RPC. 14:22:01 <hebasto> sure :) 14:22:03 <Sjors[m]> The latter is pretty well tested in the CI 14:22:52 <achow101> a potential alternative is to just completely rearchitect HWI so that it's a persistent daemon with a RPC interface 14:22:58 <achow101> but that sounds like a lot of work 14:23:26 <Sjors[m]> I'd also rather not have it run non stop, and/or manually start it as a seperate thing 14:23:40 <fanquake> HWI is still also usable without anything subprocess in Core right? Because users could just make the same calls that Core is doing, but themselves? 14:23:42 <dergoegge> or just have a native c++ (or maybe rust ð¦Â) lib to interface with the hw wallets? 14:23:50 <achow101> fanquake: yes 14:24:06 <josie> dergoegge: i think that exists? https://github.com/bitcoindevkit/rust-hwi 14:24:32 <dergoegge> but that's just a rust wrapper around hwi.py? 14:24:34 <Sjors[m]> I think that's just a wrapper? 14:24:38 <achow101> dergoegge: we don't/didn't want any of the hww stuff compiled in 14:25:07 <achow101> that would include the usb stack and a bunch of vendor specific things 14:25:10 <josie> ah gross. i think last time i talked with someone about it, i was under the impression they were going to move it away from being a wrapper 14:25:14 <josie> but looks like that hasn't happened 14:25:44 <dergoegge> we can also just delete external signer 14:25:51 <dergoegge> ðÂÂÂâÂÂâÂÂ︠14:26:08 <fanquake> Might have to get someone to add a GUI to that Rust thing 14:26:54 <fanquake> Anyways, be good for some people to at least test the subprocess thing works / is a drop in, before we worry further about how to integrate it 14:27:15 <achow101> indeed 14:27:26 <achow101> #topic dergoegge merge access in qa-assets (fanquake) 14:27:44 <fanquake> quick one for any thoughts 14:27:50 <fanquake> niklas and marco are are doing 90% of the contributing into qa-assets 14:27:55 <fanquake> given no one else reviews or merges there, doesn't make sense for me to always be a bottleneck 14:27:55 <achow101> ack 14:27:57 <fanquake> so I think it makes sense for niklas to be able to push in new inputs 14:28:01 <instagibbs> ack 14:28:06 <josie> ACK 14:28:08 <fjahr> ack 14:28:10 <fanquake> good stuff 14:28:14 <hebasto> ack 14:28:18 <sipa> ack 14:28:44 <achow101> maflcko too? 14:29:02 <darosior> ack 14:29:11 <fanquake> I don't think he wants to merge things. You can ask 14:29:41 <fanquake> That's all for that topic thought, we can sort out the admin side shortly 14:29:44 <fanquake> *though 14:29:50 <achow101> #topic shortly release cycle for 27.0 (fanquake) 14:30:14 <fanquake> *shorten whoops 14:30:15 <fanquake> Given that the past few releases have slipped a little, and 26.0 nearly happened during Christmas/New Years 14:30:19 <fanquake> I think it makes sense to have a shorter 27.0 cycle, and release in March/April. 28.0 in September/October 14:30:22 <fanquake> So that we move back away from holiday type times, and then keep that cadence going forward 14:30:25 <fanquake> Releasing around holiday times is bad because people are away etc 14:30:38 <fanquake> i.e If we have to do a 26.(0).1 soonish, it's not going to be an ideal time 14:30:40 <achow101> we should just do every 4 months to account for the slip 14:30:53 <fanquake> how does that account for slip 14:31:23 <achow101> +4 months from time of previous release 14:31:45 <sipa> releases are primarily extra work for maintainers; if you're ok with doing more frequent releases, there is little reason not to i think 14:31:46 <fanquake> So 3 major releases a year? 14:32:12 <sipa> fanquake: i think what achow101 is suggesting that the effective time between releases becomes (4 months + whatever time the previous one slipped) 14:32:40 <fanquake> Right, but I'm trying to remove variability 14:32:46 <fanquake> Othewise you just end up with the same problem again 14:32:49 <sipa> fanquake: agree 14:32:54 <stickies-v> strongly in favour of picking the 2 month in the year that we think work best, and being okay with certain releases being a bit more/less spaced apart 14:33:07 <fanquake> Pinning to ~April and ~Oct for example, means you shouldn't have this issue 14:33:15 <sipa> i like that idea 14:33:31 <josie> fanquake, stickies-v: +1 14:33:33 <stickies-v> it's better for users to have a more predictable release cycle, and it doesn't make things unnecessarily difficult for us. no downsides imo? 14:33:38 <achow101> is that target release in april, or branch in april? 14:33:44 <fjahr> yeah, well the two months in the year where the two following months are not too bad ;) 14:33:49 <_aj_> target the freeze dates, not the release dates? 14:33:50 <fanquake> I think we are also somewhat on track for an April release anyways, as we've already started merging stuff for 27.0 etc 14:33:58 <stickies-v> _aj_: +1 14:34:07 <sipa> so freeze dates in february/august? 14:34:39 <josie> freeze in feb seems pretty early, why not freeze in march? 14:35:38 <sipa> when was the freeze for 26.0? 14:35:51 <fanquake> https://github.com/bitcoin/bitcoin/issues/27758 14:36:00 <_aj_> sipa: early october? 14:36:00 <fanquake> october 8th 14:36:10 <achow101> it slipped a week though 14:36:19 <stickies-v> I'd be conservative and assume 2 months between freeze and release. If we want to avoid releasing in December, I think that means freeze in march and september? 14:36:22 <_aj_> branch off was last october 14:36:23 <fanquake> So yea, freeze the regular amount of time before april and october 14:36:31 <sipa> right, so there were basically 2 months between feature freeze and final release 14:37:21 <sipa> 25.0 was slightly shorter but still almost 8 weeks 14:37:33 <_aj_> (late october, not last october) 14:37:41 <achow101> I think we've previously targeted 6 weeks betweek feature freeze and release 14:37:57 <achow101> but that seems to never pan out, so 8 weeks is fine with me 14:38:02 <sipa> 24.0 had a 7 week interval between feature freeze and final release 14:38:40 <fanquake> and the breakdown is normally 1 month of freeze + ~1 month of rc(s)? 14:38:52 <achow101> normall 2 weeks of freeze 14:39:06 <fanquake> So freeze mid feb, start rc march, release april 14:39:36 <fanquake> freeze mid aug, start rc sept, release october? 14:39:42 <achow101> ack 14:39:43 <sipa> sgtm 14:39:53 <josie> ACK 14:39:57 <stickies-v> ack 14:39:57 <dergoegge> ð 14:39:58 <fanquake> So 2 1/2 months were of merging for 27.0 from now 14:40:06 <fanquake> Get those features in 14:40:33 <josie> haha 2 1/2 months, with holidays in between.. I think its going to be a very small release 14:40:58 <achow101> Any other topics to discuss? 14:41:02 <fanquake> Maybe we can fix more bugs than we introduce this time then 14:41:10 <_aj_> woah 14:41:21 <josie> fanquake: a christmas miracle! 14:41:26 <stickies-v> we could do a transition period where we do 27 one month later than (the new) usual before completely switching to the new schedule? 14:41:45 <fanquake> Can we not 14:41:49 <sipa> or we can decide that when the time comes 14:41:52 <maflcko> hi 14:42:04 <achow101> stickies-v: what we actually normally do is previous schedule +6 months, which is around april anyways 14:42:16 <josie> stickies-v: I think what's proposed is fine, more just point out we have a pretty big priority list for 27.0 that likely wont happen 14:42:21 <achow101> (the original schedule, not what actually happened) 14:42:23 <stickies-v> okay 14:42:33 <josie> but i dont think that should reflect badly on the priority projects experiment 14:42:43 <sipa> priority list is a set of things we are committed to making progress on - we don't need to finish them 14:43:33 <josie> sipa: agree! 14:43:54 <achow101> #endmeeting