14:00:21 <achow101> #startmeeting 
14:00:26 <TheCharlatan> hi
14:00:32 <brunoerg> hi
14:00:33 <darosior> Hi
14:00:34 <gleb> hi
14:00:41 <lightlike> hi
14:00:42 <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:01:00 <furszy> hi
14:01:01 <PaperSword> hi
14:01:04 <dergoegge> hi
14:01:05 <achow101> there is one pre-proposed meeting topic this week. Any last minute topics to add to the list?
14:01:07 <_aj_> hi
14:01:19 <jamesob> hi
14:01:31 <achow101> #topic package relay updates (glozow)
14:02:16 <cfields> hi
14:02:20 <PaperSword> #topic https://github.com/bitcoin/bitcoin/pull/28217#
14:03:16 <achow101> I think glozow is not here today. #28199 is still the priority pr and has a few reviews.
14:03:18 <gribble> https://github.com/bitcoin/bitcoin/issues/28199 | test: tx orphan handling by glozow · Pull Request #28199 · bitcoin/bitcoin · GitHub
14:03:23 <achow101> #topic BIP 324 updates (sipa)
14:05:07 <achow101> The last major crypto pr was merged last week, so the current priority is now #28165
14:05:09 <gribble> https://github.com/bitcoin/bitcoin/issues/28165 | net: transport abstraction by sipa · Pull Request #28165 · bitcoin/bitcoin · GitHub
14:05:20 <sipa> hi
14:06:03 <sipa> i'm currently working on 28165 and 28196 (the latter has the option to experiment with)
14:06:51 <sipa> 28165 is i think mostly independently-useful improvements (though inspired by the needs of bip324)
14:07:03 <achow101> sipa: is #28100 something people should look at too?
14:07:05 <gribble> https://github.com/bitcoin/bitcoin/issues/28100 | crypto: more `Span ` modernization & follow-ups by sipa · Pull Request #28100 · bitcoin/bitcoin · GitHub
14:07:18 <lightlike> (28165 needs rebase after merge of #27981 a few hours ago)
14:07:20 <gribble> https://github.com/bitcoin/bitcoin/issues/27981 | Fix potential network stalling bug by sipa · Pull Request #27981 · bitcoin/bitcoin · GitHub
14:07:29 <sipa> lightlike: ah thanks, will do today
14:07:49 <sipa> achow101: possibly - i'm happy to continue with bip324 stuff without 28100 so it's not a blocker
14:07:56 <fanquake> 28100 is about done anyays after the current comments are addressed
14:08:31 <sipa> but i think it's nice, as throughout this effort lots of parts of the crypto/ codebase have been converted to use Span<std::byte> based interfaces, which work really nicely
14:08:38 <sipa> except ChaCha20 itself hasn't
14:09:47 <achow101> #topic libbitcoinkernel updates (TheCharlatan)
14:09:54 <TheCharlatan> No updates on the priority PR #27866
14:09:56 <gribble> https://github.com/bitcoin/bitcoin/issues/27866 | blockstorage: Return on fatal flush errors by TheCharlatan · Pull Request #27866 · bitcoin/bitcoin · GitHub
14:10:02 <TheCharlatan> Been working on pruning the boost multi index headers from our header tree.
14:10:06 <TheCharlatan> So far, I have a working proof of concept. Will spend the next week polishing this to something presentable.
14:10:13 <TheCharlatan> Once that's done we can look towards wrapping up stage 1 of the project.
14:10:21 <sipa> TheCharlatan: what's the reason for that?
14:10:26 <sipa> (pruning multiindex)
14:10:56 <_aj_> what does pruning mean? limiting or removing entirely?
14:11:17 <TheCharlatan> So we can ship the library without exporting boost.
14:11:27 <fanquake> 👍
14:11:31 <TheCharlatan> It's pruning the definitions from the headers.
14:11:35 <sipa> but multi-index is headers-only, right?
14:12:01 <_aj_> so only including multi_index from cpp files, not .h files?
14:12:02 <fanquake> Yea all of our Boost usage is headers only
14:12:14 <TheCharlatan> _aj_ yes
14:12:22 <sipa> aahh, by exporting you mean from the library's *include* files?
14:12:29 <sipa> not the library binary
14:12:36 <TheCharlatan> yes :)
14:12:39 <sipa> that makes sense!
14:14:06 <achow101> #topic assumeutxo updates (jamesob)
14:14:44 <achow101> looks like there's been movement on #27596
14:14:46 <gribble> https://github.com/bitcoin/bitcoin/issues/27596 | assumeutxo (2) by jamesob · Pull Request #27596 · bitcoin/bitcoin · GitHub
14:14:53 <jamesob> Still on #27596. Few people doing review (ryanofsky, fjahr) and provoostenator doing testing
14:14:55 <gribble> https://github.com/bitcoin/bitcoin/issues/27596 | assumeutxo (2) by jamesob · Pull Request #27596 · bitcoin/bitcoin · GitHub
14:15:23 <jamesob> Sjors reported  a stallout after ibd completion but I'm not really understanding the logs he pasted in
14:15:47 <achow101> i've started looking at it as well
14:16:27 <jamesob> 👍
14:16:46 <achow101> #topic Ad-hoc high priority for review
14:17:13 <achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
14:17:47 <provoostenator> jamesob: the shutdown stalled so I had to force quit, but it worked fine at restart.
14:18:12 <PaperSword> @jamesob I will compile and test.
14:18:30 <jamesob> provoostenator: do you think the coinscache might have been flushing? how long did you wait?
14:18:37 <jamesob> PaperSword: thanks
14:19:06 <PaperSword> you can log coinscache flushing with the USDT tacepoint script right?
14:19:46 <jamesob> yeah, though there should be a lower-tech way to do that... maybe we should log to the standard facilities if the flush duration is over some length of time
14:20:47 <PaperSword> contrib/tracing/log_utxocache_flush.py it works incredibly well IMO
14:21:07 <PaperSword> was using it with sjors DB_CACHE issue
14:21:08 <provoostenator> james: this was a pruned node, so it would have flushed a bunch of times. I also think it was more than 24 hours after IBD finished, but not 100% sure.
14:21:57 <jamesob> provoostenator: so you triggerd a shutdown, but then the shutdown process hung? or it hung during normal operation?
14:22:30 <cfields> If we're done with ad-hoc review items,  I have a quick item.
14:22:42 <achow101> #topic PR#27260 (PaperSword)
14:22:44 <gribble> https://github.com/bitcoin/bitcoin/issues/27260 | Enhanced error messages for invalid network prefix during address parsing. by russeree · Pull Request #27260 · bitcoin/bitcoin · GitHub
14:22:58 <achow101> cfields: there's a preproposed topic first
14:23:08 <cfields> 👍
14:23:09 <PaperSword> I was wondering mostly about relevance of this?
14:23:57 <achow101> can you be more specific?
14:24:59 <PaperSword> Was wondering if this is something that should be continued to be worked on mostly?
14:24:59 <PaperSword> Luke has reviewed some items in this PR, and those issues were addressed.
14:25:25 <sipa> PaperSword: that's up to whomever contributes individually
14:25:29 <PaperSword> Okay!
14:25:50 <PaperSword> That concludes my request
14:26:09 <achow101> #topic #28217 (PaperSword)
14:26:11 <sipa> the project does have a few projects that we choose to focus on, but aside from that, everyone decides for themselves where they spend time
14:26:12 <gribble> https://github.com/bitcoin/bitcoin/issues/28217 | set `DEFAULT_PERMIT_BAREMULTISIG` to false by Retropex · Pull Request #28217 · bitcoin/bitcoin · GitHub
14:26:17 <achow101> I assume this is about moderation?
14:27:10 <PaperSword> Sort of. It's a great issue to discuss though the nuances seem to get drowned out in the more charged statements.
14:27:38 <PaperSword> One thing I didn't understand was is there a reason for not checking for a valid Y component to an uncompressed pubkey
14:27:58 <PaperSword> https://mempool.space/testnet/tx/f58ebcc90e1173770202dbde22521ed0e516c7c450cd92ccc99a430cbb845a54
14:28:07 <sipa> i don't think that's actually relevant
14:28:10 <PaperSword> Okay
14:28:11 <achow101> iirc it's kinda expensive
14:28:45 <PaperSword> Yes, uses base blockdata only and each outpoint has to hit dust when relaying.
14:28:46 <sipa> a bit, yes
14:29:02 <sipa> but the big problem, i think, is about changing the policy is the first place
14:29:09 <PaperSword> absolutely
14:29:25 <sipa> so really the answer to why is the Y component not checked, i think, is because the Y component was not checked in the past
14:30:09 <PaperSword> It could be of interest, because by checking it during relay would not allow others to use the Y component for extra byes of arb storage.
14:30:35 <achow101> if you do want it checked, use a hybrid key? lol
14:30:51 <sipa> PaperSword: that's exactly what the controversy is about, it wouldn't change anything
14:31:39 <provoostenator> I don't think it makes sense to use relay policy to "fight" market forces. You'll just end up with private relay networks, which in turn
14:31:43 <luke-jr> of course it would
14:31:49 <provoostenator> means worse fee estimation, and maybe even pinning issues.
14:32:01 <sipa> indeed
14:32:27 <luke-jr> provoostenator: if miners maliciously try to bypass the network, it's at least clear they are acting maliciously, rather than a passive indifference
14:32:33 <luke-jr> and that alone may be sufficient
14:32:38 <PaperSword> Okay. current implementations of stamps and these protocols seem to only use 33 bytes per outpoint
14:32:41 <sipa> i very much doubt that
14:32:59 <sipa> given that they're already convincing miners to do whatever
14:33:03 <provoostenator> Full RBF is indicator of those dynamics.
14:33:05 <luke-jr> they're not
14:33:18 <luke-jr> there's a few bad actor pools, but many are not actively going around things
14:33:25 <PaperSword> What about the fact that items in the UTXO set that have an invalid Y coordinate could never be signed for?
14:33:30 <provoostenator> Also, it's not malicious if users are settings allow bare multisig to true.
14:33:33 <luke-jr> provoostenator: full RBF is not the same thing
14:33:34 <PaperSword> Would they then be prunable?
14:34:08 <sipa> PaperSword: P2PK and k-of-n P2MS with n-k+1 invalid, i think could be pruned yes
14:34:09 <darosior> PaperSword: you may be interested in reading the discussion in https://github.com/bitcoin/bitcoin/pull/24106. Some of the arguments from here may apply.
14:34:40 <PaperSword> Thank you @darosior
14:34:50 <luke-jr> provoostenator: it's malicious to setup private relay networks to mine attacks on Bitcoin that the community is actively trying to mitigate
14:35:10 <provoostenator> But it's not miners setting those up.
14:35:14 <sipa> luke-jr: you holding that opinion is irrelevant to people's behavior :)
14:35:29 <luke-jr> provoostenator: isn't that the argument being made? [10:31] <provoostenator> I don't think it makes sense to use relay policy to "fight" market forces. You'll just end up with private relay networks, which in turn
14:35:36 <sipa> (even though i largely agree, for some definition of attacks)
14:35:59 <provoostenator> All miners need to do is to not upgrade and/or manually set this setting. And then other users will get those transaction to them. Why would they not mine them
14:36:05 <luke-jr> sipa: yes, but it's not irrelevant to the big picture and sensible default policies
14:36:36 <PaperSword> Why would a P2MS or P2PK outpoint that could never be signed for be relayed IMO.
14:36:54 <vasild> hi
14:36:59 <_aj_> provoostenator: "why would they not mine them" -- because they have a long term investment in bitcoin, and they believe mining those txs is bad for that investment, same as the reason why people would want to remove the spam in the first place
14:37:06 <provoostenator> If we removed the setting entirely, maybe that changes the morality a bit.
14:37:12 <luke-jr> _aj_: +1
14:37:21 <sipa> PaperSword: why are OP_RETURNs relayed? they also can't be spent
14:37:28 <luke-jr> though in those cases, those miners can already not-mine them
14:37:38 <PaperSword> They are prunable, and pruned
14:37:52 <sipa> your question is about relayed, not about pruning :)
14:38:05 <provoostenator> _aj_ they can already choose not to mine them and leave the money on the table.
14:38:12 <PaperSword> tuche :D
14:38:22 <luke-jr> unfortunately, I have to leave early :< but hopefully my points have been made, and others can continue
14:38:45 <PaperSword> Okay then why can one do 196 bytes using p2ms using invlid pubkeys but only 80 bytes with OP_RETURN
14:38:58 <dergoegge> can we move on?
14:39:01 <PaperSword> sure
14:39:01 <sipa> PaperSword: i think this is becoming more a question for the ML
14:39:11 <PaperSword> ML sorry?
14:39:14 <sipa> mailing list
14:39:16 <sipa> bitcoin-dev
14:39:22 <PaperSword> I will submit.
14:39:29 <PaperSword> Thank you.
14:39:37 <sipa> i would encourage you to first read the ongoing discussion already :)
14:39:51 <sipa> and yes, we could prune some more unspendable outputs, but that's an implementation detail inside bitcoin core, which imho shouldn't really interact with questions about relay policy
14:40:09 <achow101> #topic cfields thing
14:40:25 <cfields> heh
14:40:33 <cfields> Just wanted to make a quick announcement to the wider group that we now have a clang-tidy plugin merged and hooked up to c-i. This means that we can now add our own (simple) compiler rules and have them enforced. It's most immediately useful for linting, but it could also enforce constraints that aren't possible with code alone.  For now we only have one simple check.
14:40:42 <cfields> I'll open a PR to expand the README so it's clear what it can and can't do (sorry, I meant to have that done by now). If anyone has any use for additional checks (besides the ones Marco has proposed), please ping me after the meeting or mention it in that PR once opened.
14:40:53 <dergoegge> 🎉
14:40:56 <cfields> That's all :)
14:41:07 <TheCharlatan> wootwoot
14:41:09 <sipa> cfields: can you give a quick cool example of what's possible with this?
14:41:10 <PaperSword> nice
14:41:10 <achow101> neat
14:41:42 <cfields> sipa: the initial one, for example, enforces that there's a "\n" at the end of every logprintf...
14:42:11 <fanquake> the checks that exist in LLVM: https://clang.llvm.org/extra/clang-tidy/checks/list.html
14:42:22 <fanquake> for inspo
14:42:35 <cfields> Another simple example would be enforcing some variable naming convention.
14:42:36 <fanquake> (and to ensure we don't recreate things that already exist)
14:42:39 <sipa> cfields: shouldn't we change LogPrintf to automatically add a \n in that case? (unrelated to your topic, but...)
14:42:59 <cfields> sipa: lol, that would work too :)
14:43:12 <_aj_> cfields' way has less churn?
14:43:13 <cfields> This was just an excuse for a first simple check.
14:43:35 <sipa> the reason we didn't do that, i thought, was because there were a few LogPrintf outputs that were split over multiple calls
14:43:37 <Earnestly> (For that kind of automatic transformation, coccinelle exists)
14:43:47 <sipa> but if there aren't any, let's just get rid of the requirement to have a \n
14:43:53 <lightlike> then we'd need a linting rule that enforces there aren't *two* \n at the end
14:43:56 <sipa> cfields: neat as an example still, though
14:44:05 <vasild> This is somehow related to https://github.com/bitcoin/bitcoin/issues/27825
14:44:29 <dergoegge> vasild: yea that can probably be closed now
14:44:41 <vasild> \o/
14:44:50 <achow101> any other topics to discuss today?
14:45:46 <jamesob> good old /* Continued */
14:46:02 <achow101> #endmeeting