14:00:14 <achow101> #startmeeting 
14:00:21 <dergoegge> hi
14:00:22 <glozow> hi
14:00:27 <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:42 <Murch[m]> Hi
14:00:46 <furszy> hi
14:00:50 <achow101> There are 2 preproposed meeting topics this week. Any last minute ones to add?
14:00:52 <LarryRuane> Hi
14:00:58 <lightlike> Hi
14:01:08 <josie> hi
14:01:15 <stickies-v> hi
14:01:18 <luke-jr_> hi
14:01:21 <Sjors[m]> hi
14:01:30 <achow101> #topic package relay updates (glozow)
14:01:46 <glozow> #28948 still the PR to review. Still working on implementing your comments achow101 (thanks!).
14:01:48 <gribble> https://github.com/bitcoin/bitcoin/issues/28948 | v3 transaction policy for anti-pinning by glozow · Pull Request #28948 · bitcoin/bitcoin · GitHub
14:02:21 <glozow> I'm also writing a doc (bip?) and trying to index all the discussion comments / questions / answers.
14:03:12 <instagibbs> I think it'd be helpful for #28984 if I split off the cluster mempool-y diagram checking parts, if no one objects I'll open that part only?
14:03:14 <gribble> https://github.com/bitcoin/bitcoin/issues/28984 | Cluster size 2 package rbf by instagibbs · Pull Request #28984 · bitcoin/bitcoin · GitHub
14:03:27 <instagibbs> infrastructure + unit/fuzz tests?
14:03:44 <TheCharlatan> hi
14:04:20 <achow101> instagibbs: seems reasonable
14:04:40 <glozow> instagibbs: I think it's a good idea. would help reduce the complexity
14:04:57 <instagibbs> ok, will open the "first cluster mempool PR" to nerd snipe some folks
14:05:07 <kanzure> hi
14:05:29 <gleb> hi
14:05:35 <GregTonoski> hi
14:05:37 <glozow> also: https://delvingbitcoin.org/t/an-overview-of-the-cluster-mempool-proposal/393
14:06:01 <pinheadmz> hi
14:06:38 <GregTonoski> Can we talk about spam in Bitcoin and the scope of datacarriersize scope, perhaps?
14:06:49 <achow101> GregTonoski: please wait until your topic is announced
14:06:50 <luke-jr_> GregTonoski: we're on package relay topic right now
14:07:03 <achow101> #topic silent payments updates (josie)
14:07:15 <josie> review happening on #28560
14:07:17 <gribble> https://github.com/bitcoin/bitcoin/issues/28560 | wallet, rpc: `FundTransaction` refactor by josibake · Pull Request #28560 · bitcoin/bitcoin · GitHub
14:07:46 <josie> also had several rounds of review on the BIP and was able to finalize the input hashing
14:08:08 <josie> i updated the BIP and will be working on #28122 to match the BIP
14:08:10 <gribble> https://github.com/bitcoin/bitcoin/issues/28122 | Silent Payments: Implement BIP352 by josibake · Pull Request #28122 · bitcoin/bitcoin · GitHub
14:08:44 <josie> thats all for me!
14:08:49 <achow101> is the bip ready to be merged?
14:09:07 <achow101> kinda annoying to have to look through the prs list to find it
14:09:21 <josie> id like to have at least RubenSomsen take a look and sign off after my most recent push
14:09:46 <josie> but id say its pretty close to merge
14:09:57 <josie> but yes, it is v annoying
14:10:24 <RubenSomsen> will do
14:10:41 <josie> ty!
14:10:47 <achow101> #topic multiprocess updates (ryanofsky)
14:12:31 <achow101> #28921 is the current pr, still waiting on review
14:12:33 <gribble> https://github.com/bitcoin/bitcoin/issues/28921 | multiprocess: Add basic type conversion hooks by ryanofsky · Pull Request #28921 · bitcoin/bitcoin · GitHub
14:13:09 <achow101> #topic Ad-hoc high priority for review
14:13:14 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
14:13:39 <Murch[m]> achow101: Could you please add CoinGrinder?
14:14:03 <Murch[m]> The code is pretty mature now and I’d love to get it merged before 27, in case the fees shoot up again
14:14:13 <achow101> Murch[m]: added
14:14:19 <Murch[m]> Thanks!
14:16:05 <achow101> #topic spam threats and protection in Bitcoin Core (GregTonoski)
14:17:04 <GregTonoski> Is there any plan to harden anti-spam measures in Bitcoin Core in the next version, perhaps?
14:17:55 <reardencode> I'd suggest removing all limits on OP_RETURN size/count to reduce impacts on the UTXO set and mitigate long term consequences of the current scamtoken craze.
14:18:07 <luke-jr> that's the wrong direction
14:18:22 <achow101> probably not. as has been stated many times, many contributors do not think that changing policy rules will have an effect
14:18:27 <luke-jr> I've listed several possible options here FWIW: https://github.com/bitcoin/bitcoin/issues/29187
14:18:29 <wk057> It doesn't seem to make sense to increase limits for OP_RETURN beyond the original scope of why OP_RETURN was made standard in the first place.
14:18:40 <luke-jr> achow101: which is nonsense
14:19:00 <achow101> it's clearly a controversial topic, I don't think rehashing the same argument here is going to be useful
14:19:11 <Murch[m]> OP_RETURN was introduced to give a valve for people using more detrimental ways of putting data in the blockchain such as bare multisig
14:19:21 <achow101> unless there is something new to say, I would suggest that we move on from this topic
14:19:33 <luke-jr> achow101: intentionally leaving a vulnerability being actively exploited in, is not acceptable
14:19:51 <wk057> achow101: there have been serveral new suggestions in #29187 that merit consideration
14:19:52 <gribble> https://github.com/bitcoin/bitcoin/issues/29187 | Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428) · Issue #29187 · bitcoin/bitcoin · GitHub
14:20:03 <GregTonoski> 2023 was a year of spam in Bitcoin. Isn't it important topic to discuss?
14:20:11 <dergoegge> not everyone considers it a vulnerability
14:20:20 <instagibbs> ok we're aware that a PR exists, that's all that's required here
14:20:22 <achow101> wk057: they can be discussed if/when such PRs are opened
14:20:30 <luke-jr> dergoegge: objectively it is
14:20:33 <Earnestly> (It's a tad disingenuous to shut down discussion merely because it's controversial; if there is genuine misunderstanding those need to be surfaced. Lots of people are watching and want resolution on this.)
14:20:40 <josie> what is the goal of bringing this topic? calling other peoples opinions on the matter nonsense and continuing to claim there is a vulnerability (when others dont share that view) is not a discussion
14:20:47 <_aj_> instagibbs: the above was an issue, the prior PR is closed, there hasn't been a new PR filed yet, aiui
14:21:12 <luke-jr> josie: if you disagree, you can set datacarriersize=4000000; it's not an excuse to deny others a fix
14:21:14 <Murch[m]> I don’t think a policy change by default is going to get merged
14:21:15 <instagibbs> _aj_ tracking issue even better
14:21:52 <Murch[m]> I could see a new option that makes your node treat inscriptions as non-standard that is off by default be considered
14:21:55 <_aj_> achow101: (off-topic: tnx for the merge)
14:21:59 <Murch[m]> Then people who want that can gimp their own node
14:22:01 <wk057> it's objectively a vulnerability.  the ability to inject data into a system in an unintended way is pretty much the most common exploit in existence. saying it's not a vulnerability is odd.
14:22:04 <Earnestly> achow101: If the filters are behind a flag, and people can choose to use it, why would that necessarily be a blocker? Does there need to be more robust evidence that the filters prevent the behaviour it's designed to stop?
14:22:19 <_aj_> wk057: "unintended" is not an objective criterion
14:22:23 <achow101> Earnestly: never said that it was
14:22:27 <instagibbs> again, this is nothing new, there is nothing to discuss here
14:22:52 <Earnestly> I see, so a PR adding such a feature would be fine
14:23:42 <wk057> instagibbs: it merits discussion.  since the original PR was closed for being "controverial", then finding a solution that checks all the boxes would merit discussion for an obvious issue.
14:23:46 <GregTonoski> Pieter Wuille said that 4MB block is ""pathological" . It occurred in 2023.
14:23:47 <luke-jr> _aj_: it pretty much is, at least in this case; pretending it was intended is dishonest
14:23:57 <instagibbs> And I'm done engaging with this. thanks.
14:24:10 <_aj_> luke-jr: the people sending the spam certainly intend it
14:24:10 <GregTonoski> 4MB block: 0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae
14:24:28 <achow101> wk057: since there is an issue open, discussing in that issue should be sufficient
14:24:30 <luke-jr> _aj_: pfft, so does every attacker
14:24:39 <Earnestly> I certainly don't want to store this data on my node, is there anything I can do to mitigate it?
14:24:45 <sipa> Earnestly: run a pruned node
14:24:54 <achow101> especially since discussion here is transient
14:24:58 <Earnestly> sipa: I do, but I don't want to process it (I also want to keep historical nodes as well)
14:25:03 <instagibbs> Is this the last topic?
14:25:06 <achow101> instagibbs: no
14:25:16 <reardencode> Earnestly: rot13maxi made a script to invalidate blocks containing inscriptions. it'll put you on your own fork of bitcoin.
14:25:31 <wk057> achow101: seems this is a broad enough topic to warrant at least some realtime developer discussion to make the solutions that would be acceptable for merge more obvious before dev effort is expended on something that has no hope of merging
14:25:34 <Murch[m]> Suggestion:... (full message at <https://matrix.bitcoin.ninja/_matrix/media/v3/download/bitcoin.ninja/EVtcNPNYvjzsBmTKCrJgoTdP>)
14:25:51 <achow101> Murch[m]: your message was too long
14:26:04 <achow101> (matrix bridge elided it)
14:26:12 <brunoerg> next topic?
14:26:14 <glozow> fwiw I disagree that this is a vulnerability. I already reviewed 28408 and summarized all of the arguments for/against it, concluding it shouldn't be merged. I have a writeup on my notes repo. I plan on reviewing and opening PRs that I think are important, and this discussion isn't changing that.
14:26:20 <glozow> #proposedmeetingtopic note to use new logging macros (#28318)
14:26:23 <gribble> https://github.com/bitcoin/bitcoin/issues/28318 | logging: Simplify API for level based logging by ajtowns · Pull Request #28318 · bitcoin/bitcoin · GitHub
14:27:07 <luke-jr> glozow: every argument against it, has been amply refuted already
14:27:15 <sipa> luke-jr: people clearly disagree with you here
14:27:17 <Earnestly> glozow: Why wouldn't be considered as such if a specific sequence of operators are selected specifically to bypass OP_RETURN, why don't they just use op_return?
14:27:26 <wk057> glozow: you seem to have conveniently skipped over some key points in your summary, but that PR is closed, so the discussion is to determine the best way forward from here without wasting additional developer resources
14:27:40 <glozow> luke-jr: having read through all of the comments and mailing list posts and a lot of twitter, I disagree.
14:27:43 <reardencode> Earnestly: they don't use OP_RETURN because it is limited to 80 bytes - hence my suggestion.
14:27:52 <Earnestly> reardencode: Why was it limited?
14:28:04 <achow101> wk057: from the existing discussions on the topic, there generally seems to be agreement that a default off option to enable such filters may be acceptable, at least more so than the datacarriersize change
14:28:09 <Murch[m]> achow101: Thanks, it was just a summary of above: Make it a default-off optional new configuration option that only applies to inscriptions, and I could see it get merge.
14:28:39 <achow101> wk057: does that sufficiently resolve your desire to have a discussion here?
14:28:40 <wk057> achow101: default off option doesn't address the issue.  I agree it should be an option, but default off doesn't actually solve anything.
14:29:00 <luke-jr> achow101: Murch[m]: so we add a new option for every new spam scheme?
14:29:30 <_aj_> luke-jr: for any that are controversial, certainly
14:29:36 <Murch[m]> If you think that is a useful way of spending your time, be my guest
14:29:40 <luke-jr> refusing to admit it's a vulnerability, and making such crazy suggestions, just strikes me as dishonesty, sorry
14:29:41 <Earnestly> luke-jr: Would it be possible to provide a more generic mechanism that reads in a set of rules, in some DSL format, that can be used to filter?
14:29:44 <_aj_> luke-jr: (and spammers will naturally try to make them all controversial, so...)
14:29:47 <wk057> that was what I was writing.  so everyone who wants to address a vulnerability needs to get a PR approved for a new option that defaults to allowing exploitation of that vulnerability? that doesn't seem reasonable.
14:30:08 <Earnestly> In that manner you can then add new rules to this file to catch any new mechanisms used to bypass the original limit
14:30:14 <wk057> The people exploiting a bug shouldn't really get a say in whether or not the bug is fixed.
14:30:28 <Murch[m]> I think the topic is now "note to use new logging macros (#28318)", though
14:30:31 <gribble> https://github.com/bitcoin/bitcoin/issues/28318 | logging: Simplify API for level based logging by ajtowns · Pull Request #28318 · bitcoin/bitcoin · GitHub
14:30:39 <achow101> Murch[m]: not yet
14:30:54 <Earnestly> luke-jr: So instead of having to hardcode a set of rules directly in the codebase they can be expressed as a file
14:31:14 <_aj_> Murch[m]: that was proposed, not switched to
14:31:27 <Murch[m]> ah, you’re right
14:31:30 <achow101> I think the specific details regarding the implementation of such a flag can be discussed in its PR, once open
14:31:31 <sipa> sigh, there is economic demand for block space, whether you like it or not - the buyers and sellers of that space both want the transaction to occur, i don't see what anyone thinks they can do about that
14:31:32 <dergoegge> can we move on?
14:31:38 <instagibbs> dergoegge +1
14:31:44 <kevkevin> dergoegge +1
14:31:49 <brunoerg> dergoegge +1
14:31:51 <josie> dergoegge +1
14:31:53 <glozow> dergoegge +1
14:31:53 <achow101> #topic bip324 defaults for 27.0 (achow101)
14:31:53 <Murch[m]> dergoegge: +1
14:32:11 <wk057> achow101: since there's been development time on the original PR that's been "spinning wheels", it would make sense to try to limit further wasted efforts
14:32:30 <achow101> The 27.0 feature freeze is in a month, so what defaults should we try to get for bip324 in before then?
14:32:38 <instagibbs> re:bip324, did all the open testing PRs get merged? it seems t obe getting reasonable runtime as I've seen both incoming and outgoing v3 connections
14:32:47 <instagibbs> v2
14:32:56 <sipa> there is the big functional test PR, #24748
14:33:00 <gribble> https://github.com/bitcoin/bitcoin/issues/24748 | test/BIP324: functional tests for v2 P2P encryption by stratospher · Pull Request #24748 · bitcoin/bitcoin · GitHub
14:33:14 <sipa> which i consider the one blocker to enabling bip324 b
14:33:18 <sipa> y default
14:33:25 <instagibbs> that was my impression as well
14:33:41 <achow101> I think it would be good to have v2transport enable trying v2 for all outbound connections. as it is now, people don't seem to fully get that the only way to have a v2 outbound is with the addnode rpc
14:34:07 <_aj_> sipa: so it should go on the high-pri list?
14:34:08 <sipa> achow101: not anymore since #29058
14:34:10 <gribble> https://github.com/bitcoin/bitcoin/issues/29058 | net, cli: use v2transport for manual/addrfetch connections, add to -netinfo by mzumsande · Pull Request #29058 · bitcoin/bitcoin · GitHub
14:34:35 <achow101> -addnode is still needed though
14:34:36 <josie> _aj_ +1, was surprised the func test PR was still open
14:34:46 <lightlike> achow101: -connect also works now
14:35:12 <instagibbs> i have a non-manual outbound v2 on v26, did I previously -connect it or something?
14:35:16 <sipa> achow101: for automatic connections, if both sides run with `-v2transport`, and the service flag propagated ahead of time, a bip324 connection will be used
14:35:26 <instagibbs> sipa ah ok 👍
14:36:12 <glozow> _aj_: added
14:36:54 <achow101> sipa: really? my previously addnode'd connections don't seem to use v2 after I restart
14:37:20 <sipa> achow101: i was talking about automatic connections, not manual ones
14:37:32 <sipa> manual ones will all be v2 since 29058
14:37:52 <sipa> i think?
14:39:31 <lightlike> yes, if specified with the -addnode bitcoind command. if you use the addnode rpc, you have to use the option.
14:39:36 <achow101> not sure. will try to test a bit more then
14:40:44 <achow101> anyways, I think we should try to get #24748 in to take a look at defaults for 27.0
14:40:46 <gribble> https://github.com/bitcoin/bitcoin/issues/24748 | test/BIP324: functional tests for v2 P2P encryption by stratospher · Pull Request #24748 · bitcoin/bitcoin · GitHub
14:41:05 <achow101> #topic note to use new logging macros (#28318) (glozow)
14:41:08 <gribble> https://github.com/bitcoin/bitcoin/issues/28318 | logging: Simplify API for level based logging by ajtowns · Pull Request #28318 · bitcoin/bitcoin · GitHub
14:41:43 <glozow> Just want to bring it to people's attention, please use the new macros in new code.
14:42:02 <achow101> Can the old ones be scripted-diff'd away?
14:42:10 <_aj_> probably should do a scripted diff at least for net_processing; https://github.com/bitcoin/bitcoin/pull/28318#issuecomment-1701170263
14:42:42 <jonatack> Hi
14:42:43 <glozow> I think that's a good idea. Would be nice to have more unified logging across the codebase
14:42:53 <stickies-v> see https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#logging for how to use the new macros
14:43:16 <josie> glozow: +1
14:43:19 <jonatack> Would be good for someone to open a PR to simplify the API for level based logging after that merge
14:43:29 <lightlike> there will be tons of conflicts. maybe do it after the branch-off or something?
14:43:43 <achow101> lightlike: good point
14:43:57 <_aj_> lightlike: it's a scripted diff so should be easy to maintain until the branch off
14:45:07 <achow101> Any other topics to discuss?
14:45:09 <fanquake> Why is after branch off better?
14:45:14 <fanquake> There's still the same number of conflicts
14:45:19 <fanquake> and backports are now just harder to do
14:45:35 <jonatack> The goal and review feedback I gave was to have a unified interface of one single Log() macro.
14:45:36 <_aj_> after feature freeze maybe
14:45:37 <maflcko> It will be a scripted-diff, but not a refactor, right? The log output will change slightly, to include "warning" or "error" prefixes?
14:46:09 <_aj_> maflcko: a refactor, log output won't change
14:46:23 <lightlike> fanquake: so that higher-prioritised projects that still need to get into v27 are not delayed by this.
14:46:24 <glozow> jonatack: hm, I don't really think that'd be better. This way we use the same macro the vast majority of the time, and don't need to pass in an arg for all of them.
14:46:28 <jamesob> #proposedmeetingtopic assumeutxo chainparams merge when?
14:46:43 <glozow> I'm not a fan of the verbosity of that approach
14:46:53 <dergoegge> glozow: +1
14:46:56 <maflcko> _aj_: A right
14:47:00 <jonatack> Also, that merge invalidated the 2 ACKs for a bugfix open since almost a year now https://github.com/bitcoin/bitcoin/pull/27231
14:47:12 <glozow> after feature freeze seems fine
14:47:14 <fanquake> lightlike: right, not sure there would be "tons" of conflicts in the high-prio PRs though? I'll take a look
14:47:21 <jonatack> on the blockers list. Oh well :)
14:47:38 <achow101> jonatack: there's only one ack, and (althought not explicitly said) a nack
14:47:46 <_aj_> jonatack: that PR had unaddressed feedback since september...
14:47:48 <achow101> and no activity for a long time
14:48:00 <maflcko> jonatack: Is it still relevant after the merge?
14:48:07 <maflcko> Wasn't "NONE" removed anyway?
14:48:15 <_aj_> maflcko: aspects of it are, yes
14:48:21 <maflcko> ok
14:48:51 <glozow> ISTM the project ended up choosing an alternate approach maybe just close that PR? we don't need more logging fragmentation
14:48:55 <jonatack> glozow: a single Log(level, category) is a simple as it gets.  Multiple macros with differing APIs requires developers to remember more context, and necessitates more code, docs, and test coverage
14:49:14 <stickies-v> a single function doesn't equal a simple interface though
14:49:17 <lightlike> fanquake: I think there is no PR yet with the scripted diff, so probably best to open that and look just how many conflicts threre actually are.
14:49:34 <jonatack> The new APIs don't all take the same arguments. Devs will have to remember which macros take which parameters. Etc.
14:50:19 <achow101> I already don't remember what macros take which parameters, so that's nothing new
14:50:25 <_aj_> lightlike: +1
14:50:37 <jamesob> jonatack: yeah, that I do have beef with - left some commentary in the recent PR
14:50:54 <jonatack> jamesob: yes
14:51:12 <achow101> anyways, open prs and let's discuss there
14:51:25 <achow101> #topic assumeutxo chainparams merge when? (jamesob)
14:51:47 <maflcko> Seems a bit early when there are still outstanding bugs and crashes, no?
14:51:57 <jamesob> So it's not really clear to me what the criteria is for when we're ready to merge the assumeutxo PRs. IMO it's pretty low risk to do so and let "expert users" start calling the RPC to make use of it
14:52:00 <sipa> shouldn't we figure out distribution/P2P fetching of chainstates before nailing that down, as it may mean we need to change serialization format?
14:52:09 <jamesob> Are there bugs and crashes?
14:52:16 <maflcko> Yes
14:52:25 <sipa> i guess it's fair that there is no problem changing the format afterwards
14:52:29 <jamesob> sipa: I think that will take a very long time to do
14:53:01 <jamesob> maflcko: mind actually referencing the bugs and crashes?
14:53:01 <jonatack> glozow: just close which PR, please?  The bugfix is still relevant.
14:53:06 <fanquake> also need to decide about things like #28598
14:53:07 <gribble> https://github.com/bitcoin/bitcoin/issues/28598 | assumeutxo: Ensure transactions are not presented as confirmed until background sync is complete · Issue #28598 · bitcoin/bitcoin · GitHub
14:53:39 <jamesob> I'm aware of a  number of refactoring/cleanup/test PRs that are proposed, some of which IMO are matters of taste
14:54:35 <maflcko> jamesob: Sorry, I am looking for it ...
14:54:54 <instagibbs> there should probably(still?) be a tracking issue sounds like
14:55:14 <jamesob> Anyway, I'm not saying we should merge the params now - but it would be nice to develop an understanding of when we're ready for expert users to start trying it out for real
14:55:28 <maflcko> #28791 
14:55:32 <gribble> https://github.com/bitcoin/bitcoin/issues/28791 | snapshots: dont core dump when running -checkblockindex after `loadtxoutset` by maaku · Pull Request #28791 · bitcoin/bitcoin · GitHub
14:55:34 <jamesob> I really don't think it should just hang out waiting for a P2P scheme to come along, or for the dump format to change
14:55:48 <_aj_> i don't see any "bugs and crashes" in the open issues list under a search for assumeutxo? be good to add an issue if there's not one already
14:55:55 <sipa> jamesob: i'm not saying wait for it, i'm saying work on it!
14:56:13 <maflcko> _aj_: "crash" -> "core dump"
14:56:13 <jamesob> sipa: ain't gonna be me!
14:56:39 <sipa> but fair enough, if we expect that not to happen anytime soon, it may be reasonable to go for a "experts use only" deployment before that part is fleshed out
14:56:41 <jamesob> maflcko: thanks for the link
14:57:00 <achow101> I think enabling it for the rpc should be fine to do prior to figuring out distribution
14:57:13 <achow101> but also crashes should be fixed first
14:57:16 <fanquake> #28616 the PR for above
14:57:17 <jamesob> achow101: agreed
14:57:18 <gribble> https://github.com/bitcoin/bitcoin/issues/28616 | Show transactions as not fully confirmed during background validation by Sjors · Pull Request #28616 · bitcoin/bitcoin · GitHub
14:57:52 <achow101> Anything else to discuss in our last few minutes today?
14:57:52 <jamesob> I'll review that Sjors wallet PR
14:59:21 <_aj_> so fix known crash bugs, then add mainnet params/update testnet/signet params?
14:59:48 <achow101> sounds like it
14:59:49 <fanquake> then decide on how to represent this to users. if anything needs changing or not
14:59:50 <instagibbs> experimental "add footgun here", let pre-packaged node distros try it out, seems natural
15:00:01 <achow101> #endmeeting