--- Log opened Thu Oct 05 00:00:46 2023
00:11 -!- Guest99 [~Guest99@ec2-35-72-149-104.ap-northeast-1.compute.amazonaws.com] has joined #bitcoin-core-dev
00:17 -!- Guest46 [~Guest99@ec2-35-72-149-104.ap-northeast-1.compute.amazonaws.com] has joined #bitcoin-core-dev
00:18 -!- salvatoshi__ [~salvatosh@genymobile-2-6-86.fib.nerim.net] has quit [Quit: Leaving]
00:19 -!- Guest99 [~Guest99@ec2-35-72-149-104.ap-northeast-1.compute.amazonaws.com] has quit [Quit: Client closed]
00:19 -!- Guest46 [~Guest99@ec2-35-72-149-104.ap-northeast-1.compute.amazonaws.com] has quit [Client Quit]
00:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
00:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
00:33 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:39 < bitcoin-git> [bitcoin] hebasto pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/5b4478418b24...0e3de3b83e99
00:39 < bitcoin-git> bitcoin/master f08adec Hennadii Stepanov: qt: Add "Transport" label to peer details
00:39 < bitcoin-git> bitcoin/master d9c4e34 Hennadii Stepanov: qt: Add "Session id" label to peer details
00:39 < bitcoin-git> bitcoin/master 0e3de3b Hennadii Stepanov: Merge bitcoin-core/gui#754: Add BIP324-specific labels to peer details
00:39 < bitcoin-git> [gui] hebasto merged pull request #754: Add BIP324-specific labels to peer details (master...230911-bip324-peer-details) https://github.com/bitcoin-core/gui/pull/754
00:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
00:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 260 seconds]
00:48 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
00:53 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 248 seconds]
01:00 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
01:02 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
01:04 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
01:05 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
01:10 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
01:10 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
01:27 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
01:28 -!- mudsip [~mudsip@user/mudsip] has quit []
01:31 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
01:33 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
01:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
01:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 258 seconds]
02:01 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
02:06 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
02:10 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
02:21 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Ping timeout: 272 seconds]
02:27 -!- MatrixBot1234561 [~matrixbot@2001:bc8:1824:bc3::1] has quit [Quit: Bridge terminating on SIGTERM]
02:33 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
02:43 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 272 seconds]
02:45 < fanquake> To github.com:bitcoin-core/bitcoin-detached-sigs.git
02:45 < fanquake>  * [new tag]         v25.1rc1 -> v25.1rc1
02:55 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
02:56 -!- johnzweng [~johnzweng@zweng.at] has quit [Quit: Leaving...]
02:59 -!- johnzweng [~johnzweng@zweng.at] has joined #bitcoin-core-dev
02:59 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
03:11 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
03:16 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 240 seconds]
03:28 < bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/0e3de3b83e99...2eacc61ad74c
03:28 < bitcoin-git> bitcoin/master 7899402 Pieter Wuille: Add headerssync-params.py script to the repository
03:28 < bitcoin-git> bitcoin/master 53d7d35 Pieter Wuille: Update parameters in headerssync.cpp
03:28 < bitcoin-git> bitcoin/master 3d420d8 Pieter Wuille: Add instructions for headerssync-params.py to release-process.md
03:28 < bitcoin-git> [bitcoin] fanquake merged pull request #25970: Add headerssync tuning parameters optimization script to repo (master...202208_headerssync_script) https://github.com/bitcoin/bitcoin/pull/25970
04:03 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/2eacc61ad74c...78fd3c267240
04:03 < bitcoin-git> bitcoin/master e130896 Sebastian Falbesoner: test: BIP324: add checks for v1 prefix matching / wrong network magic dete...
04:03 < bitcoin-git> bitcoin/master 78fd3c2 fanquake: Merge bitcoin/bitcoin#28588: test: BIP324: add checks for v1 prefix matchi...
04:03 -!- benwestgate [~BenWestga@035-146-116-090.res.spectrum.com] has joined #bitcoin-core-dev
04:03 < bitcoin-git> [bitcoin] fanquake merged pull request #28588: test: BIP324: add checks for v1 prefix matching / wrong network magic detection (master...202310-test-add_v1_prefix_detection_wrong_network_magic_check) https://github.com/bitcoin/bitcoin/pull/28588
04:13 < fanquake> Chasing some eyes over #27609
04:13 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27609 | rpc: allow submitpackage to be called outside of regtest by glozow · Pull Request #27609 · bitcoin/bitcoin · GitHub
04:25 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
04:28 -!- benwestgate [~BenWestga@035-146-116-090.res.spectrum.com] has quit [Quit: Leaving.]
04:30 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Ping timeout: 255 seconds]
04:30 < darosior> I'll have another look
04:33 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
04:35 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has joined #bitcoin-core-dev
04:41 -!- pablomartin [~pablomart@217.146.93.22] has joined #bitcoin-core-dev
04:51 -!- pablomartin [~pablomart@217.146.93.22] has quit [Ping timeout: 240 seconds]
04:58 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #28595: ci: Avoid cache depends/build (master...2310-ci-built-) https://github.com/bitcoin/bitcoin/pull/28595
05:06 -!- benwestgate [~BenWestga@035-146-116-090.res.spectrum.com] has joined #bitcoin-core-dev
05:16 -!- pablomartin [~pablomart@185.216.146.240] has joined #bitcoin-core-dev
05:53 -!- pablomartin [~pablomart@185.216.146.240] has quit [Ping timeout: 255 seconds]
06:05 -!- johnzweng [~johnzweng@zweng.at] has quit [Ping timeout: 246 seconds]
06:06 < bitcoin-git> [bitcoin] fanquake pushed 7 commits to master: https://github.com/bitcoin/bitcoin/compare/78fd3c267240...52c6904c7891
06:06 < bitcoin-git> bitcoin/master 87c7067 dergoegge: [net processing] PeerManager holds a FastRandomContext
06:06 < bitcoin-git> bitcoin/master a648dd7 dergoegge: [net processing] PushAddress uses PeerManager's rng
06:06 < bitcoin-git> bitcoin/master 77506f4 dergoegge: [net processing] Addr shuffle uses PeerManager's rng
06:07 < bitcoin-git> [bitcoin] fanquake merged pull request #28558: Make PeerManager own a FastRandomContext (master...2023-10-peerman-rng) https://github.com/bitcoin/bitcoin/pull/28558
06:17 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
06:20 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:e128:5bce:e46a:8007] has quit [Remote host closed the connection]
06:39 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
06:41 -!- brunoerg [~brunoerg@2804:1600:115:e500:70c4:8bf5:6e57:a222] has joined #bitcoin-core-dev
06:50 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #28597: wallet: No BDB creation, unless -deprecatedrpc=create_bdb (master...2310-less-bdb-) https://github.com/bitcoin/bitcoin/pull/28597
06:53 -!- Guest26 [~Guest26@103.114.193.8] has joined #bitcoin-core-dev
06:54 -!- Guest26 [~Guest26@103.114.193.8] has quit [Client Quit]
07:00 < achow101> #startmeeting
07:00 < gleb> Hi
07:00 < 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
07:00 < hebasto> hi
07:00 < pinheadmz> hi!
07:00 < darosior> hi
07:00 < stickies-v> hi
07:00 < brunoerg> hi
07:00 < laanwj> hii
07:00 < achow101> There are no pre-proposed meeting topics this week. Any last minute ones to add?
07:00 < dergoegge> hi
07:00 < Sjors[m]> Hi
07:00 < glozow> hi
07:00 < Murch[m]> Hi
07:00 < gleb> I have something on erlay
07:00 < luke-jr> hi
07:01 < _aj_> hi
07:01 < lightlike> Hi
07:01 < furszy> hi
07:01 < achow101> #topic package relay updates (glozow)
07:01 < fjahr> hi
07:01 < sipa> hi
07:01 < sdaftuar> hi
07:01 < glozow> #26711 is the blocker PR. I've been trying to address feedback very quickly
07:01 <@gribble`> https://github.com/bitcoin/bitcoin/issues/26711 | validate package transactions with their in-package ancestor sets by glozow · Pull Request #26711 · bitcoin/bitcoin · GitHub
07:02 < glozow> If people are interested in #27609 for 26.0, please review
07:02 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27609 | rpc: allow submitpackage to be called outside of regtest by glozow · Pull Request #27609 · bitcoin/bitcoin · GitHub
07:02 < glozow> I've also been working on the p2p changes, making progress on TxDownloadMan fuzzing. But as discussed at coredev, waiting until the mempool stuff is finished before opening
07:03 < theStack> hi
07:03 < josie> hi
07:03 < glozow> Same thing with v3 stuff - waiting until after 26711 is in
07:04 < glozow> That's it for my updates
07:04 < Murch[m]> glozow: I’ll start reviewing that today
07:04 < glozow> Murch: awesome thanks :D
07:04 < achow101> #topic BIP 324 updates (sipa)
07:05 < sipa> hi!
07:05 < sipa> big stuff done
07:05 < glozow> \o/
07:05 < achow101> what's left to do? a few followups and the tests?
07:05 < laanwj> congrats!
07:06 < sipa> indeed
07:06 < sipa> and enabling by default
07:07 < laanwj> what's the plan for that? will the first release with it will have it disabled by default?
07:08 < sipa> laanwj: i think so
07:09 < achow101> The tests pr is #28374? are there any open followup prs (I know the 16 byte prefix stuff was merged yesterday)?
07:09 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28374 | test: python cryptography required for BIP 324 functional tests by stratospher · Pull Request #28374 · bitcoin/bitcoin · GitHub
07:09 < laanwj> makes sense
07:09 < sipa> there is work to be done with functional tests among other things, and we shouldn't enable things by default before that
07:09 < cfields> hi
07:09 < achow101> laanwj: 26.0 (in a few weeks) will have it disabled. hopefully we can enable it for 27.0?
07:09 < sipa> yeah, exactly
07:09 < fanquake> the tests pr is #24748
07:10 <@gribble`> https://github.com/bitcoin/bitcoin/issues/24748 | test/BIP324: functional tests for v2 P2P encryption by stratospher · Pull Request #24748 · bitcoin/bitcoin · GitHub
07:10 < sipa> there are no open PRs beyond that, i think
07:10 < lightlike> #28374 first I think (which has the crypto part of the tests)
07:10 < sipa> and #28374
07:10 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28374 | test: python cryptography required for BIP 324 functional tests by stratospher · Pull Request #28374 · bitcoin/bitcoin · GitHub
07:10 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28374 | test: python cryptography required for BIP 324 functional tests by stratospher · Pull Request #28374 · bitcoin/bitcoin · GitHub
07:10 < achow101> cool
07:11 < achow101> #topic libbitcoinkernel updates (TheCharlatan)
07:11 < laanwj> @achow101 yea imo, it's good to have it in 26.0 so enthousiasts can test it, then when there's confidence in it (likely enough to be in another 6 months) it makes sense to enable it by default
07:12 < theStack> laanwj: +1
07:13 < achow101> I think nothing has really changed for kernel this week, and TheCharlatan appears to not be here
07:13 < achow101> #topic assumeutxo updates (jamesob)
07:14 < fjahr> Not sure if jamesob is here for his victory lab ;) The big one was merged here too.
07:14 < fjahr> There is a list of follow-ups in #28562 I will address feedback and rebase shortly.
07:14 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28562 | AssumeUTXO follow-ups by fjahr · Pull Request #28562 · bitcoin/bitcoin · GitHub
07:14 < fjahr> And there is #28590 from ryan which we should try to get into 26. It changes the RPC
07:14 < luke-jr> still needs something so it doesn't display transactions as confirmed prematurely, right?
07:14 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28590 | assumeutxo: change getchainstates RPC to return a list of chainstates by ryanofsky · Pull Request #28590 · bitcoin/bitcoin · GitHub
07:14 < luke-jr> or did that get in somewhere already?
07:15 < fjahr> luke-jr: I don't think so, I don't know what PRs we have open on that off the top of my head
07:15 < Sjors[m]> luke-jr: it can't be used on mainnet without recompile
07:15 < fanquake> fjahr: were you planning on including all the post-merge review from 27596 in that PR? Or will be following up with other changes?
07:16 < fanquake> Quite a lot of post-merge review comments have been left
07:16 < fjahr> Yeah, I will comment in 27596 and not keep adding more stuff afterwards, so it says reviewable
07:16 < Sjors[m]> I plan to continue reviewing the original PR and then look at the followup PRs.
07:17 < fjahr> *so that 28562 stays reviewable, it already has 9 commits, I don't want to grow it much further
07:17 < Sjors[m]> Seems fine to have multiple followup PRs.
07:18 < luke-jr> Sjors[m]: I assume that's the goal, though, right?
07:18 < fjahr> There will surely be more follow-ups
07:18 < achow101> luke-jr: can you open an issue for that problem?
07:18 < fanquake> I think we also need to follow up with the release notes/rpc helps, and comparison to assumevalid etc Decide on exactly how this is presented.
07:18 < luke-jr> ok
07:19 < Sjors[m]> I haven't really tested GUI behavior for assumeutxo recently, but we should - at least before this becomes easier to use.
07:19 < fanquake> Multiple followups is fine, as long as we don't make post-branch-off changes to things like the rpc interface
07:19 < fanquake> Lets make sure most of that is done, if we're going to keep changing it
07:20 < abubakarsadiq> Hi
07:21 < achow101> #topic Ad-hoc high priority for review
07:21 < achow101> Anything to add or remove from https://github.com/orgs/bitcoin/projects/1/views/4
07:22 < cfields> last minute topic proposal: cmake pings
07:22 < achow101> Also reminder that 26.0 feature freeze is this Sunday.
07:22 < achow101> I don't think there's any need to push it back again
07:22 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
07:22 < sipa> i'm continuing to review #27255
07:22 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27255 | MiniTapscript: port Miniscript to Tapscript by darosior · Pull Request #27255 · bitcoin/bitcoin · GitHub
07:23 < darosior> 🚀
07:23 < fanquake> I can't see a reason to. Most stuff on https://github.com/bitcoin/bitcoin/milestone/60 will likely get in
07:23 < willcl-ark> hi
07:23 < achow101> sipa: hoping to get that in this weekend too
07:24 < fanquake> Not sure about #28037. We seem to keep finding bugs in the migration code
07:24 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28037 | rpc: Drop migratewallet experimental warning by achow101 · Pull Request #28037 · bitcoin/bitcoin · GitHub
07:24 < fanquake> but we do need to get the wallet upgrade path open
07:25 < achow101> fanquake: no money losing bugs, just weird wallets that aren't migrating
07:25 < sipa> by "aren't migrating", you mean migration gives a error code, and the migration doesn't happen?
07:25 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 246 seconds]
07:26 < achow101> at least it's in the gui now so more people will be using it
07:26 < fanquake> more like a segfault
07:26 < achow101> sipa: more like hitting an assert
07:26 < fanquake> i.e #28057
07:26 < luke-jr> fanquake: it's still open, even with a warning
07:26 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28057 | migratewallet crashes (wallet/scriptpubkeyman.cpp:1915: std::optional wallet::LegacyScriptPubKeyMan::MigrateToDescriptor(): Assertion `IsMine(desc_spk) != ISMINE_NO failed.) · Issue #28057 · bitcoin/bitcoin · GitHub
07:26 < sipa> fanquake: i guess that qualifies as an error code!
07:26 < _aj_> an assert in the gui is a bit obnoxious?
07:27 < _aj_> (or is it caught?)
07:27 < luke-jr> I don't think it's caught at least
07:27 < achow101> it's at least an attended process (the user had to be there to start it, and is presumably still there)
07:28 < achow101> for the vast majority of people, it should work correctly
07:28 < fanquake> luke-jr: yea, i just assume some people are going to avoid it with real funds, while it's still marked experimental
07:30 < achow101> #topic erlay (gleb)
07:30 < gleb> I wanted to share that i'm back to work after some absence. Amiti told me she saw some interest in Erlay at core dev, so that makes sense to continue moving it forward
07:31 < sipa> gleb: great to hear!
07:31 < gleb> It is already reviewable (#26283 and 21515), and a couple places with data and benchmarking results. I intend to make reviewing it easier. One thing is a tracking issue with FAQ.
07:31 <@gribble`> https://github.com/bitcoin/bitcoin/issues/26283 | p2p: Fill reconciliation sets and request reconciliation (Erlay) by naumenkogs · Pull Request #26283 · bitcoin/bitcoin · GitHub
07:31 < gleb> Do you have any initial thoughts on it? Anything particular that prevents you from reviewing to be covered?
07:31 < achow101> tracking issue would be good
07:31 < gleb> esp. sipa dergoegge brunoerg aureleoules ariard glozow mzumsande — those who already looked at the current PR piece.
07:31 < josie> gleb: welcome back! 
07:32 < sipa> gleb: i'll review again after 26 branch-off
07:32 < cfields> 👋
07:32 -!- pablomartin [~pablomart@217.146.93.22] has joined #bitcoin-core-dev
07:32 < gleb> Thank you.
07:33 < gleb> For others — It’s not to late to jump on this train. Later on it might be harder to start following it
07:33 < glozow> Nice that you're back gleb! Yeah I think a tracking issue would be great
07:33 < luke-jr> harder in what sense?
07:34 < gleb> Luke-jr you’ll have to review previous pr parts which are already merged.
07:34 < glozow> I suppose a tracking issue would help with that too - people would be able to review the merged PRs if they need to catch up
07:34 < gleb> Yeah
07:35 < lightlike> same - I plan to get back to reviewing it in the next weeks!
07:35 < brunoerg> same here
07:36 < gleb> Alright, we can move on if there are no comments. Feel free to text me later on — say if you need a call to discuss the code or whatever
07:36 < gleb> Thank you for your commitments to review.
07:36 < achow101> #topic cmake pings (cfields)
07:36 < cfields> Hi all. Sorry for being away for the last 2 weeks, I'll be back at my computer starting tomorrow.
07:36 < cfields> A quick CMake announcement: At coredev we discussed pinging people individually to test CMake before merge (still a few weeks away at minimum). Not necessarily to get individual ACKS, but to do a rough check to see if your build setup will have any problems post-merge.
07:37 < cfields> So, once hebasto and I suspect that things are in decent shape, we'll start doing pings for feedback. This is in addition to the PR review itself.
07:37 < cfields> The goal here is to try to address developers' concerns specifically, since we tend to build with the most non-standard configs. As a random example, if you're building libbitcoinkernel on FreeBSD x86-64 for Linux risc-v, you might run into an edge-case we haven't seen yet.
07:37 < cfields> tl;dr: if you get a ping request to try your day-to-day workflow with CMake, via IRC, Github, Signals, whatever, please please try to do so. That is a good chance to complain, not after merge :)
07:37 < luke-jr> cfields: my build system is quite abnormal now, so I'll plan on it (might need a reminder)
07:37 < cfields> luke-jr: ack, you'll get a ping for sure :)
07:37 -!- Chris_Stewart_5 [~Chris_Ste@37.19.200.133] has quit [Ping timeout: 272 seconds]
07:38 < luke-jr> where is the current codebase btw?
07:38 < cfields> still a few weeks out. Just wanted to everyone to know it's coming.
07:38 < sipa> cfields: what is the minimum supported cmake version (assuming there are no additional build dependencies or changes to minimum versions of existing one)?
07:38 -!- brunoerg [~brunoerg@2804:1600:115:e500:70c4:8bf5:6e57:a222] has quit [Remote host closed the connection]
07:39 -!- Chris_Stewart_5 [~Chris_Ste@66.63.167.149] has joined #bitcoin-core-dev
07:39 < hebasto> 3.13
07:39 < cfields> luke-jr: review is currently happening at hebasto's repo. There's an ubrella PR open in the core repo, but i'm not sure if it's current (sorry, I've been away this week)
07:39 < cfields> current: https://github.com/hebasto/bitcoin/pull/31
07:39 < sipa> hebasto: cool
07:39 < fanquake> If branch of is Sunday, do we have a cut off for how long we are willing to wait, before merging something? i.e 1 month post, then we push it again?
07:39 < hebasto> however, I will suggest 3.16 considering the time of merging
07:40 < fanquake> We don't want to do this too deep into the new release cycle.
07:40 < cfields> sipa: ^^.  Definitely up for discussion if it turns out a newer vers would have big benefits though.
07:40 < achow101> branch off is scheduled for 2 weeks
07:40 < cfields> fanquake: ack.
07:40 < hebasto> umbrella pr -- https://github.com/bitcoin/bitcoin/pull/25797
07:40 < fanquake> I assume people are also already working on all the downstream intregrations etc. So that we don't end up with broken downstreams for too long.
07:40 < sipa> the oldest system i regularly build on is an ubuntu 20.04, which has cmake 3.16
07:41 < cfields> at coredev we said ~2 weeks after would be reasonable. That puts us about a month from now.
07:41 < hebasto> sipa: exactly!
07:41 < fanquake> Ok.
07:42 < cfields> That seems reasonable to me, but I must admit I'd hoped to have this week for review and wasn't able, so I'm personally a week behind. But I'll try to catch up next week.
07:42 < achow101> Any other topics to discuss?
07:43 < fanquake> Yea
07:43 < cfields> So say 4 weeks from now we decide to merge, short extension, or punt?
07:43 < luke-jr> (on that note, should I just close #28564 or does anyone care to give it a quick review to fix current versions?)
07:43 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28564 | Bugfix: configure: Correct check for fuzz binary needing a main function by luke-jr · Pull Request #28564 · bitcoin/bitcoin · GitHub
07:43 < achow101> cfields: ack
07:43 < fanquake> cfields: that sounds ok, just don't want scope for this to start dragging out
07:43 < hebasto> ack :)
07:44 < fanquake> luke-jr: all build PRs are still relevant, it's not like cmake fixes the bugs in the branches we have to maintain for the next few years
07:44 < fanquake> so changes to the current build system are still needed, and useful
07:44 < _aj_> were we going to start polling for priority projects?
07:44 < cfields> fanquake: ack.
07:44 < cfields> _aj_: ah, right.
07:44 < luke-jr> ok, but absent additional changes, this bug amounts to a minor configure output thing IIUC
07:45  * luke-jr shrugs
07:45 < achow101> _aj_: next week I think
07:45 < achow101> I guess I can put up the issue for collecting possible projects
07:45 < _aj_> sounds good; seems like cmake is already a priority project :)
07:46 < fanquake> _aj_: if we have to pick 3, I'd kinda hope not. We have bitcoin problems to solve heh
07:47 < _aj_> well, if it's finished in four weeks time, nbd :)
07:47 < luke-jr> >finished
07:47 < luke-jr> o.o
07:47 < fanquake> I have one other quick topic
07:48 < fanquake> A 25.1rc1 has been tagged: https://github.com/bitcoin/bitcoin/releases/tag/v25.1rc1
07:48 < fanquake> So time to Guix build & test the bins.
07:48 < fanquake> Check out the release notes, and if you think there's something missing that should have been backported, let me know. 
07:48 < luke-jr> I'm still struggling with bootstrapping guix x.x
07:48 < fanquake> Ideally 25.1 is released some time not long after feature freeze.
07:48 < fanquake> Note there are also PRs for 24.x & 23.x backports open at the moment (both reviewable).
07:49 < fanquake> luke-jr: if you can point me to the issues you've opened upstream, I can follow up
07:49 < luke-jr> fanquake: upstream just doesn't support it at all
07:49 < luke-jr> their answer is that it's impossible
07:49 < achow101> #28599 for gathering projects to vote on
07:49 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28599 | Gathering Priorities for 27.0 · Issue #28599 · bitcoin/bitcoin · GitHub
07:50 < fanquake> luke-jr: ok, can you link me to the issue/mailing list thread where the discussion happned
07:50 < luke-jr> fanquake: just IRC
07:50 < fanquake> cool, link me to the logs?
07:50 < luke-jr> #guix isn't logged ...
07:51 < achow101> Any other topics?
07:51 < luke-jr> nm, found log link
07:51 < dergoegge> achow101: maybe mention that the vote is only relevant for frequent contributors? 
07:52 < sipa> we could also just do the discussion in a frequent contributor discussion, instead of a public issue
07:52 < achow101> sipa: github seems to have removed the feature for team discussions
07:53 < sipa> oh!
07:53 < sipa> indeed, there is just an json archive dump
07:55 < achow101> #endmeeting
07:55 < _aj_> could setup a private repo limit to freq-contrib and setup Discussions on that?
07:56 < luke-jr> fanquake: https://logs.guix.gnu.org/guix/2023-07-31.log and https://logs.guix.gnu.org/guix/2023-09-09.log mainly
07:56 < achow101> I think it's fine to leave it open unless there's actually a problem? we can more aggressively moderate if need be
07:57 < sipa> achow101: yeah
08:00 < fanquake> luke-jr: will read through
08:19 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/52c6904c7891...db19a7e89d19
08:19 < bitcoin-git> bitcoin/master fa28f5a MarcoFalke: test: Bump walletpassphrase timeouts to avoid intermittent issues
08:19 < bitcoin-git> bitcoin/master db19a7e Andrew Chow: Merge bitcoin/bitcoin#28403: test: Bump walletpassphrase timeouts to avoid...
08:19 < bitcoin-git> [bitcoin] achow101 merged pull request #28403: test: Bump walletpassphrase timeouts to avoid intermittent issues (master...2309-ci-bump-timeout-) https://github.com/bitcoin/bitcoin/pull/28403
08:27 -!- bugs_ [~bugs@user/bugs/x-5128603] has joined #bitcoin-core-dev
08:33 < achow101> darosior: sipa: any thoughts on how to deal with migrating a legacy wallet that has a hybrid pubkey?
08:33 < darosior> Error cleanly, tell the user they must create a new descriptor wallet and send the funds there?
08:33 < achow101> I'm leaning towards just giving an error that tells them to open an issue. it shouldn't be something that anyone actually uses
08:33 < josie> achow101: dont
08:35 < sipa> achow101: you'd need to have imported a hybrid pubkey manually, as watch-only (as there is no corresponding private key for it, in the CKey sense)
08:35 < darosior> instagibbs: https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1749112324 should it? I just modified rpc_packages.py to 'submitpackage' a parent with `DEFAULT_FEE * 10` and a child with `DEFAULT_FEE` and both were accepted. Maybe i just made a mistake.
08:36 < darosior> Oh right it's only watchonly
08:36 < darosior> So they don't even have to send any funds
08:36 < _aj_> as long as DEFAULT_FEE > mempool min fee, that's okay though
08:36 < darosior> Yes
08:37 < _aj_> at leat in my tests, when mempool min fee > child feerate, i get a reject
08:37 < darosior> That's what i was thinking from reading the code, so `submitpackage` can be used with a package that is not a CPFP. That's what i was telling Murch[m]
08:38 < glozow> I think some of us are thinking about the "child lower than package feerate and mempool minimum feerate" case, and some of us are just thinking about the "child lower than package feerate in general"
08:38 < sipa> what if the child has higher feerate than the mempool, but after submitting the parent, the mempool feerate increases to be higher than the child's?
08:38 < darosior> glozow: yes
08:39 < glozow> sipa: LimitMempoolSize() is not called until the end of `AcceptPackage`
08:39 < glozow> so that should not happen
08:40 < darosior> achow101: Maybe proceed with migrating all the rest and return a warning in the command result / log about how imported hybrid keys couldn't be migrated. In my opinion this should be so rare that it's not worth going out of your way. As long as there is a clear warning / error somewhere. Worst case it's in the log they don't notice it but no funds
08:40 < darosior> is actually lost.
08:44 < darosior> glozow: so the TrimToSize() pushing up the feerate by 1sat/vb you described in https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1542695316 can still happen right?
08:45 < glozow> darosior: not with `IsTree`, you can't have diamonds like that
08:46 < darosior> Yes i'm saying without the diamond, just with a child that ... Oooh ok got it :)
08:50 -!- pablomartin4btc [~pablomart@185.216.146.241] has joined #bitcoin-core-dev
08:51 -!- pablomartin [~pablomart@217.146.93.22] has quit [Ping timeout: 240 seconds]
08:51 < bitcoin-git> [bitcoin] fanquake pushed 11 commits to master: https://github.com/bitcoin/bitcoin/compare/db19a7e89d19...d9c1cc5f1f54
08:51 < bitcoin-git> bitcoin/master 5d84693 Andrew Chow: test: Add helper functions for checking node versions
08:51 < bitcoin-git> bitcoin/master 313d665 Andrew Chow: test: Fix 0.16 wallet paths and downgrade test
08:51 < bitcoin-git> bitcoin/master 53f35d0 Andrew Chow: test: Remove w1_v18 from wallet backwards compatibility
08:51 < bitcoin-git> [bitcoin] fanquake merged pull request #28027: test: Fixes and updates to wallet_backwards_compatibility.py for 25.0 and descriptor wallets (master...2023-07-test-wallet-back-compat-updates) https://github.com/bitcoin/bitcoin/pull/28027
08:57 -!- pablomartin4btc [~pablomart@185.216.146.241] has quit [Ping timeout: 255 seconds]
08:58 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d9c1cc5f1f54...6e5cf8e95391
08:58 < bitcoin-git> bitcoin/master c1e6c54 Pieter Wuille: descriptors: disallow hybrid public keys
08:58 < bitcoin-git> bitcoin/master 6e5cf8e Andrew Chow: Merge bitcoin/bitcoin#28587: descriptors: disallow hybrid public keys
08:59 < bitcoin-git> [bitcoin] achow101 merged pull request #28587: descriptors: disallow hybrid public keys (master...202310_no_hybrid_descriptors) https://github.com/bitcoin/bitcoin/pull/28587
09:00 < darosior> glozow: could you expand on your answer to sipa? How is it that you can't have a very large parent (say your mempool is 280MB, parent is 20MB) and a child whose feerate would position it at the very bottom of the mempool before accepting the parent, such as when you reach LimitMempoolSize() the child would get dropped and the minimum mempool
09:00 < darosior> feerate increased by 1sat/vb?
09:02 < _aj_> can't have parent/ancestors more than 400k weight?
09:05 < darosior> The example works with smaller sizes.
09:05  * darosior afk
09:08 < vasild> hebasto, cfields: so, to test my workflow with cmake, should I merge hebasto/cmake-staging into some local branch of mine and then "work as usual"?
09:09 < vasild> well, "work as usual" / modulo using cmake instead of autotools of course
09:10 < hebasto> vasild: no, merging will cause silent conflicts
09:10 < vasild> hum?
09:11 < vasild> conflicts between what? there is no cmake files in master now
09:11 < hebasto> there were changes in source file organisation
09:11 < hebasto> right now, the longest chain of reviewed commits is here -- https://github.com/hebasto/bitcoin/pull/31
09:11 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
09:12 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev []
09:13 < vasild> ok, this is the hebasto/230916-linear branch
09:13 < hebasto> correct
09:13 < vasild> is this the one to test?
09:13 < glozow> darosior: so walking through the scenario. I assume in this situation the large parent is higher feerate than the child. Parent gets in by itself, and we exceed the 300mb maximum temporarily. If we were to do a `TrimToSize()` perhaps the minimum feerate would change, but we're not. So we submit the child, and then we call `TrimToSize` at the end and evict by worst descendant score.
09:13 < vasild> shouldn't I also test unreviewed commits?
09:13 < glozow> iiuc sipa's question was whether the mempool minimum feerate can change in the middle of `AcceptPackage`, and the answer is no since #28251
09:14 <@gribble`> https://github.com/bitcoin/bitcoin/issues/28251 | validation: fix coins disappearing mid-package evaluation by glozow · Pull Request #28251 · bitcoin/bitcoin · GitHub
09:14 < hebasto> vasild: yes. that branch is a rebase of reviewed commits
09:14 < hebasto> and it is supposed to be new staging branch after acking
09:17 < vasild> hebasto: ok, I can test directly hebasto/230916-linear but this is a bit boring. I want to test it together with my PR, for this I guess I should merge one way or another. git diff --stat origin/master...hebasto/230916-linear looks pretty innocent wrt to merge conflics - just ++++ lines adding cmake stuff.
09:18 < _aj_> hebasto: what do you do to build that branch?
09:18 < hebasto> vasild: any conflict will and a cmake error. I'll make a fresh rebase for you
09:19 -!- cryptapus [~cryptapus@user/cryptapus] has quit [Ping timeout: 258 seconds]
09:19 < hebasto> _aj_: examples are here -- https://github.com/hebasto/bitcoin/pull/31#issuecomment-1722338779
09:20 < hebasto> is that what you meant?
09:21 < vasild> hebasto: So, hebasto/230916-linear is based on master from Sep 12. You are worried that if there were build related changed in master after Sep 12 that are included in my local branch, then hebasto/230916-linear will not be adapted to that?
09:21 < hebasto> correct
09:21 < vasild> I see
09:23 < _aj_> hebasto: how do i enable debug, Werror and c++20?
09:23 < vasild> ok, for now I will play with hebasto/230916-linear only
09:25 < hebasto> _aj_: `-DCXX20 -DCMAKE_BUILD_TYPE=Debug`  ; Werror not implemented yet
09:26 < hebasto> full list of options is here --https://github.com/bitcoin/bitcoin/pull/25797#issue-1330985812 (near bottom of the comment)
09:26 < vasild> _aj_: running ccmake gives some list of the options in a test/console ui, I find it useful
09:26 < vasild> s/test/text/
09:26 < hebasto> ^ indeed
09:27 < hebasto> also adding `-LH` will print options as well
09:30 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:b:f00a] has joined #bitcoin-core-dev
09:33 < _aj_> hebasto: that table says -DWERROR should do Werror?
09:34 < _aj_> ah, but it doesn't actually work
09:34 < hebasto> yes. but it is not implemented in the staging branch where commit-by-commit reviewing happens
09:35 < hebasto> the branch in the umbrella PR was fully-fledged with all options implemented
09:37 < bitcoin-git> [bitcoin] Retropex closed pull request #28217: set `DEFAULT_PERMIT_BAREMULTISIG` to false (master...Permitbaremultisig) https://github.com/bitcoin/bitcoin/pull/28217
09:43 < _aj_> so `cd build; cmake -S ..; cd ../src; touch net.h; cmake --build ../build -j 20` seems like it works okay
09:45 < _aj_> ccmake is pretty great
09:45 < vasild> well, hebasto/230916-linear compiles on freebsd
09:45 < hebasto> cool
09:46 < _aj_> how do i tell ctest where to look if i'm in src/ rather than build/ ?
09:57 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:e1b1:e648:f55b:1feb] has joined #bitcoin-core-dev
09:57 < hebasto> `--test-dir`
09:58 < _aj_> -test-dir ../build ?
09:59 < _aj_> seems to work, also seems like it orders the test by whichever took longest last time?
10:00 < hebasto> did not check the order
10:01 < _aj_> seems very nice, anyway
10:01 < hebasto> thanks!
10:04 -!- brunoerg [~brunoerg@2001:12d0:2080:2800:172:26:b:f00a] has quit [Remote host closed the connection]
10:17 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
10:25 < Murch[m]> <darosior> "feerate increased by 1sat/vb?" <- If the child gets dropped, _if_ that child had a higher feerate than the package, the parent would then also be below the dynamic minimum feerate and would also get dropped?
10:27 < Murch[m]> That’s why I was asking whether we generally restricted to packages where the child has a higher feerate than the package
10:28 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
10:29 < glozow> ^it's more that the parent would have a lower descendant score than the child, so parent+child would be selected before child for eviction. We don't proactively trim everything below our new minimum.
10:29 < glozow> No we don't explicitly enforce that
10:30 < instagibbs> darosior in general we will be gossiping packages that arent necessarily CPFPs, and we have to handle them in a good way
10:32 < Murch[m]> But I thought we were talking about the more narrow functionality of #27609?
10:32 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27609 | rpc: allow submitpackage to be called outside of regtest by glozow · Pull Request #27609 · bitcoin/bitcoin · GitHub
10:34 < instagibbs> Murch[m] feel free to recap your question to me, think I missed something
10:34 < Murch[m]> If the intended purpose for making the submitpackage RPC available in this release is to give to Lightning users with commitment transactions stuck on feerates below the dynamic minimum feerate an avenue for submitting their commitment tx and a bumping child to a node, why would we care in this context about packages where the child has a lower feerate than the package?
10:36 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
10:36 -!- mudsip [~mudsip@user/mudsip] has quit [Client Quit]
10:37 < Murch[m]> I guess you could have a construction where a grandparent tx has a high feerate, a parent tx has a low feerate, and the child has a medium feerate that is lower than the package, but then the grandparent would have been eligible by itself in the first place
10:37 -!- Guest36 [~Guest23@111.65.60.231] has joined #bitcoin-core-dev
10:37 < Murch[m]> And then you could only submit parent and child which would fulfill the criteria of the child having a higher feerate than the package
10:38 -!- Guest36 [~Guest23@111.65.60.231] has quit [Client Quit]
10:38 < instagibbs> it's not important for the rpc per se I guess, but when gossiping we need to support arbitrary things where a node comes back online, gets the low fee child, is missing the parent, and fetches the ancestors
10:38 < Murch[m]> Sure, but that’s #27611, which I gather is not slated to be in v26
10:38 < instagibbs> with a LN wallet "of course" the child will be high feerate, that's the point of the wallet logic
10:38 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27611 | refactor: Use ChainType enum exhaustively by TheCharlatan · Pull Request #27611 · bitcoin/bitcoin · GitHub
10:38 < glozow> are you proposing to add this restriction to packages that are submitted via submitpackage? because that's not something you can easily check prior to calling `AcceptPackage`
10:39 < Murch[m]> errrr #26711
10:39 <@gribble`> https://github.com/bitcoin/bitcoin/issues/26711 | validate package transactions with their in-package ancestor sets by glozow · Pull Request #26711 · bitcoin/bitcoin · GitHub
10:39 < instagibbs> 26711 "merely" makes the logic for acceptance smarter to avoid edge cases, and make it safe for non-tree
10:39 < Murch[m]> right
10:40 < Murch[m]> And from staring a bunch at packages in the context of candidate sets and miniminer in the last year, my suspicion would be that even a lot of the edge cases with diamonds mostly trigger around situations where a parent pays for a child
10:41 < Murch[m]> If the lowest descendant has a higher feerate than the package, wouldn’t that already preclude many/most/all of these edge cases, i.e. perhaps a decent way to shore up submitpackage for early release?
10:42 < instagibbs> ah, you mean master + check child for higher feerate? that's not sufficient 
10:42 < instagibbs> it's in the graveyard of ideas in the tree PR IIRC
10:43 < glozow> my point is also that this is way more involved to check than a simple topology restriction
10:43 < glozow> you don't know what the feerates are until you pass it to validation
10:43 < instagibbs> yeah, that too. checking topo is very cheap + easy to remove later
10:43 < instagibbs> you need PreChecks to get fee info
10:43 < Murch[m]> I thought packages were topologically restricted to having a single transaction descending from all other package members?
10:44 < glozow> correct, they have to be a child with unconfirmed parents
10:44 < Murch[m]> So wouldn’t it just amount to adding up the total package size and total package fees, and comparing that to the individual feerate of the latest descendant?
10:45 < glozow> how are you getting the fees though
10:45 < instagibbs> you can have weird fee structures in the subpackages
10:45 < instagibbs> that master + child check won't catch iirc
10:46 < Murch[m]> You mean a sub-ancestry that is self-sufficient and has a higher feerate by itself?
10:47 < Murch[m]> glozow: Child with unconfirmed parents, or child with all unconfirmed ancestors?
10:47 < glozow> parents
10:48 < instagibbs> maybe not, I've been focusing on 26711 and the comments look pretty stale unfortunately. things are really non-obvious
10:48 < Murch[m]> So the problem case would be if you had two parents and one has a high feerate and the other has a low feerate, and the child would have a lower feerate than the package?
10:49 < glozow> did you take a look at this example? https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1542695316
10:49 < Murch[m]> And we’d reject the package because the child fails the criteria, even though the high-feerate parent would be self-sufficient and then from the remainder the child would be of course higher feerate than the secnd parent?
10:50 < instagibbs> no, we'd accept the high feerate parent first in individual evaluation
10:50 < glozow> No I think worst case scenario is accepting a below-minfeerate child (as illustrated in that example)
10:51 < Murch[m]> Great example
10:51 < instagibbs> based on https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1544414801 it seems we had reasons why the last-child-feerate wasn't enough 
10:51 < glozow> Another example, which is not as bad, is this one where we miss out on 2 transactions that have good fees: https://github.com/bitcoin/bitcoin/pull/26711/commits/40bab000936bf1573824644a0e08020e63d73e51#diff-98ca28aa44cf84d5a29e4ce7eddbabf495a51154b02a6703a78977b80e19b17aR1297-R1364
10:51 < Murch[m]> My suggestion would be that the example you linked would be rejected because the child has a lower feerate than the package
10:52 < glozow> (that's not something we need to solve for the RPC imo, which I think people agree with)
10:52 < instagibbs> I'm not sure that would be sufficient, is my point. Tree topo is, and 26711 subsumes it
10:53 < sipa> So is the idea that 26711 only changes things for non-tree topologies?
10:54 < glozow> Well, 26711 also allows all ancestor packages, so a 3-generation tree is now permitted when it wasn't before
10:54 < instagibbs> for tree topos, the eval should be very close yes
10:54 < instagibbs> parents evaluaated one by one, then child, if all parents succeeded
10:55 < instagibbs> or all parents didnt get disallowed*
10:56 < instagibbs> s/succeed/dont fail for non-fee related reasons/
10:57 < sipa> i have a slightly uncomfortable feeling that this RPC access is being rushed, and i'd like to just see 26711 make it in instead
10:57 < Murch[m]> I see, so the point that I’m missing is that even in the experimental submitpackage RPC we want to support situations in which subsets of the package are eligible
10:58 < sipa> but i'm still trying to wrap my head around what the additional restrictions in 27609 mean... if it's the case that 26711 only changes things for things that 27609 doesn't permit anyway, then it obviously doesn't matter
10:58 < instagibbs> hm?
10:58 < glozow> Murch: I don't think your suggestion is a restriction that we can easily tack on / remove later, as you'd need to do it within validation. I also don't think it's sufficient as you can still add another tx under the diamond with the same feerate as the package
11:00 < glozow> 26711 would not change things for a child-with-parents package that is tree-shaped
11:01 < sipa> glozow: ok, thanks
11:01 < Murch[m]> aah, I see what I was missing
11:01 < bitcoin-git> [bitcoin] achow101 opened pull request #28602: descriptors: Disallow hybrid and uncompressed keys when inferring (master...migrate-hybrid-keys) https://github.com/bitcoin/bitcoin/pull/28602
11:02 < glozow> that being said I wouldn't want to propose the RPC if it makes people uncomfortable
11:02 < Murch[m]> We have the topology of the package because we see the outpoints being spent by descendants of other transactinos, but we don’t know the amounts of the spent UTXOs because we’d have to first look up the UTXOs and thus we can’t get the fees
11:02  * Murch[m] facepalms
11:02 < _aj_> trying to think about 26711 at the same time doesn't seem super helpful; the rpc just takes a super simple case (some unreleated parents and a child) and allows them to be added as a package. all the complex topologies are just disallowed
11:02 < instagibbs> Murch[m] yeah you need `PreCheck`s for that
11:03 < instagibbs> deep in eval territory 
11:03 < glozow> Murch: 👍
11:03 < Murch[m]> So it’s easy to restrict to parents + child, or only tree but no diamond, but not easy to check for the feerate
11:03 < Murch[m]> gotcha
11:04 < glozow> Yeah to be clear, the restriction of child+parents only is already in there
11:04 < glozow> However, given the fact that parents can spend parents, child-with-parents is not that much simpler than tx-with-ancestors when thinking about edge cases.
11:04 < glozow> That's why 26711 is so big, haha
11:05 < Murch[m]> Yeah, but in #27609 we do not allow parents to spend other parents, right?
11:05 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27609 | rpc: allow submitpackage to be called outside of regtest by glozow · Pull Request #27609 · bitcoin/bitcoin · GitHub
11:06 < instagibbs> parents, which are only spent by a single child
11:06 < glozow> yes exactly
11:08 < _aj_> so if you had minfee=10sat/vb, p1=30sat/vb, p2=6sat/vb, child=12sat/vb, #27609 would be wrong, i think? (p1 accept; but p2+child = 9sat/vb)
11:08 <@gribble`> https://github.com/bitcoin/bitcoin/issues/27609 | rpc: allow submitpackage to be called outside of regtest by glozow · Pull Request #27609 · bitcoin/bitcoin · GitHub
11:09 < glozow> _aj_: is p1+p2+child a tree?
11:09 < _aj_> glozow: child spends p1 and p2, no other relationships
11:09 < glozow> why wrong? you shouldn't take p2 and child
11:10 < _aj_> glozow: oh does p1 already get pre-accepted on its own?
11:10 < instagibbs> yeah
11:10 < glozow> yeah it's first tried by itself
11:10 < instagibbs> one by one eval first
11:10 < instagibbs> then "rest of package"
11:10 < instagibbs> is master
11:11 < _aj_> so after that phase, all remaining parents should be below minfee or they would already be accepted?
11:11 < glozow> correct
11:13 -!- dberkelmans [~dberkelma@2001:1c03:530d:8100:e1b1:e648:f55b:1feb] has quit [Quit: Client closed]
11:19 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/6e5cf8e95391...0b2c93bc560c
11:19 < bitcoin-git> bitcoin/master a9ef702 Ryan Ofsky: assumeutxo: change getchainstates RPC to return a list of chainstates
11:19 < bitcoin-git> bitcoin/master 0b2c93b Andrew Chow: Merge bitcoin/bitcoin#28590: assumeutxo: change getchainstates RPC to retu...
11:19 < bitcoin-git> [bitcoin] achow101 merged pull request #28590: assumeutxo: change getchainstates RPC to return a list of chainstates (master...pr/getchain) https://github.com/bitcoin/bitcoin/pull/28590
11:27 -!- mudsip [~mudsip@user/mudsip] has joined #bitcoin-core-dev
11:38 -!- mudsip [~mudsip@user/mudsip] has quit []
12:01 -!- OP_NOP [~OP_NOP@206.217.205.41] has joined #bitcoin-core-dev
12:18 -!- OP_NOP [~OP_NOP@206.217.205.41] has quit [Ping timeout: 240 seconds]
12:19 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 255 seconds]
12:21 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
12:21 -!- Talkless [~Talkless@mail.dargis.net] has quit [Quit: Konversation terminated!]
12:27 -!- nanotube [~nanotube@user/nanotube] has quit [Ping timeout: 272 seconds]
12:36 < bitcoin-git> [bitcoin] achow101 pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0b2c93bc560c...cf553e3ab7b3
12:36 < bitcoin-git> bitcoin/master fa071ae MarcoFalke: wallet: No BDB creation, unless -deprecatedrpc=create_bdb
12:36 < bitcoin-git> bitcoin/master cf553e3 Andrew Chow: Merge bitcoin/bitcoin#28597: wallet: No BDB creation, unless -deprecatedrp...
12:36 < bitcoin-git> [bitcoin] achow101 merged pull request #28597: wallet: No BDB creation, unless -deprecatedrpc=create_bdb (master...2310-less-bdb-) https://github.com/bitcoin/bitcoin/pull/28597
12:56 < bitcoin-git> [bitcoin] achow101 closed pull request #20892: tests: Run both descriptor and legacy tests within a single test invocation (master...better-descriptor-tests) https://github.com/bitcoin/bitcoin/pull/20892
12:56 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
13:03 -!- pablomartin4btc [~pablomart@217.146.93.23] has joined #bitcoin-core-dev
13:16 -!- brunoerg [~brunoerg@187.183.43.117] has joined #bitcoin-core-dev
13:21 -!- brunoerg [~brunoerg@187.183.43.117] has quit [Remote host closed the connection]
13:22 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has joined #bitcoin-core-dev
13:41 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has quit [Remote host closed the connection]
13:57 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has joined #bitcoin-core-dev
14:03 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has quit [Ping timeout: 240 seconds]
14:05 -!- Zenton [~user@user/zenton] has joined #bitcoin-core-dev
14:26 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has joined #bitcoin-core-dev
14:38 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 246 seconds]
14:44 -!- vysn [~vysn@user/vysn] has quit [Remote host closed the connection]
14:45 -!- brunoerg [~brunoerg@2804:14c:3bfb:8a:c597:597b:acf7:98cd] has quit [Remote host closed the connection]
14:46 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
15:19 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has joined #bitcoin-core-dev
15:36 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has quit [Remote host closed the connection]
15:41 -!- bugs_ [~bugs@user/bugs/x-5128603] has quit [Quit: Leaving]
15:47 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has joined #bitcoin-core-dev
15:50 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has quit [Quit: Connection closed for inactivity]
15:51 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has quit [Ping timeout: 240 seconds]
16:00 -!- brunoerg [~brunoerg@187.183.43.149] has joined #bitcoin-core-dev
16:08 < bitcoin-git> [bitcoin] achow101 pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/cf553e3ab7b3...54bdb6e07459
16:08 < bitcoin-git> bitcoin/master b4f28cc glozow: [doc] parent pay for child in aggregate CheckFeeRate
16:08 < bitcoin-git> bitcoin/master e32ba15 glozow: [txpackages] IsChildWithParentsTree()
16:08 < bitcoin-git> bitcoin/master 5b9087a glozow: [rpc] require package to be a tree in submitpackage
16:08 < bitcoin-git> [bitcoin] achow101 merged pull request #27609: rpc: allow submitpackage to be called outside of regtest (master...open-submitpackage) https://github.com/bitcoin/bitcoin/pull/27609
16:19 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
16:20 -!- benwestgate [~BenWestga@035-146-116-090.res.spectrum.com] has quit [Quit: Leaving.]
16:21 -!- brunoerg [~brunoerg@187.183.43.149] has quit [Remote host closed the connection]
16:23 < bitcoin-git> [bitcoin] achow101 opened pull request #28604: test: Use feerate higher than minrelay fee in wallet_fundraw (master...fix-fundraw-test-intermittent) https://github.com/bitcoin/bitcoin/pull/28604
16:42 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur]
17:13 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has joined #bitcoin-core-dev
17:17 -!- brunoerg [~brunoerg@2804:14d:5281:8c2e:351d:bb23:4f6a:30c3] has quit [Ping timeout: 240 seconds]
17:59 -!- brunoerg [~brunoerg@179.191.241.108] has joined #bitcoin-core-dev
18:19 -!- brunoerg [~brunoerg@179.191.241.108] has quit [Ping timeout: 255 seconds]
18:38 -!- flooded [flooded@gateway/vpn/protonvpn/flood/x-43489060] has joined #bitcoin-core-dev
18:42 -!- test_ [flooded@gateway/vpn/protonvpn/flood/x-43489060] has quit [Ping timeout: 260 seconds]
18:51 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
18:59 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 240 seconds]
19:07 -!- DarrylTheFiiish [~DarrylThe@user/DarrylTheFish] has joined #bitcoin-core-dev
19:10 -!- DarrylTheFiish [~DarrylThe@user/DarrylTheFish] has quit [Ping timeout: 248 seconds]
19:10 -!- DarrylTheFish [~DarrylThe@user/DarrylTheFish] has joined #bitcoin-core-dev
19:12 -!- DarrylTheFiiish [~DarrylThe@user/DarrylTheFish] has quit [Ping timeout: 255 seconds]
19:35 -!- puchka [~puchka@185.203.122.42] has quit [Ping timeout: 258 seconds]
19:36 -!- DarrylTheFiish [~DarrylThe@user/DarrylTheFish] has joined #bitcoin-core-dev
19:37 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
19:38 -!- DarrylTheFish [~DarrylThe@user/DarrylTheFish] has quit [Ping timeout: 240 seconds]
19:41 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 240 seconds]
20:10 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Remote host closed the connection]
20:10 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
20:11 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
20:15 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 240 seconds]
20:17 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 272 seconds]
20:40 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
20:41 -!- cryptapus [~cryptapus@user/cryptapus] has joined #bitcoin-core-dev
20:45 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
20:46 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 240 seconds]
20:49 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 240 seconds]
21:01 -!- cmirror [~cmirror@4.53.92.114] has quit [Remote host closed the connection]
21:01 -!- cmirror [~cmirror@4.53.92.114] has joined #bitcoin-core-dev
21:02 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
21:09 -!- Furry [~Admin1@47.200.93.48] has joined #bitcoin-core-dev
21:10 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 248 seconds]
21:23 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
21:28 -!- abubakarsadiq [uid602234@id-602234.hampstead.irccloud.com] has joined #bitcoin-core-dev
21:40 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 240 seconds]
21:47 -!- pablomartin4btc [~pablomart@217.146.93.23] has quit [Ping timeout: 255 seconds]
21:53 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
21:55 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
21:59 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 258 seconds]
22:00 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 258 seconds]
22:01 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
22:09 -!- Furry [~Admin1@47.200.93.48] has quit [Quit: Leaving]
22:11 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 272 seconds]
22:12 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
22:20 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 240 seconds]
22:32 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
22:37 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has quit [Ping timeout: 258 seconds]
22:40 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
22:43 -!- rolf [~rolf@162-1-21-31.ftth.glasoperator.nl] has joined #bitcoin-core-dev
22:45 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 258 seconds]
22:45 -!- rolf [~rolf@162-1-21-31.ftth.glasoperator.nl] has quit [Client Quit]
22:49 -!- jQrgen [~jQrgen@2001:8c0:ea04:37:208f:fbf5:f48b:bc67] has joined #bitcoin-core-dev
23:13 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
23:18 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 264 seconds]
23:27 -!- nanotube [~nanotube@user/nanotube] has joined #bitcoin-core-dev
23:45 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has joined #bitcoin-core-dev
23:50 -!- brunoerg [~brunoerg@2804:1600:115:e500:fcb4:571:ad53:6699] has quit [Ping timeout: 272 seconds]
23:52 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
--- Log closed Fri Oct 06 00:00:47 2023