pablomartin4btc has quit [Ping timeout: 240 seconds]
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
abubakarsadiq has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
pablomartin4btc_ is now known as pablomartin4btc
pablomartin4btc has quit [Ping timeout: 255 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
abubakarsadiq has quit [Quit: Connection closed for inactivity]
benwestgate has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
<bitcoin-git>
[bitcoin] luke-jr opened pull request #28564: Bugfix: configure: Correct check for fuzz binary needing a main function (master...fix_conf_fuzzbin_main) https://github.com/bitcoin/bitcoin/pull/28564
<bitcoin-git>
[bitcoin] fanquake merged pull request #28543: build, macos: Fix `qt` package build with new Xcode 15 linker (master...230927-qt-sonoma) https://github.com/bitcoin/bitcoin/pull/28543
_16738 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
_16738 has quit [Quit: Leaving]
brunoerg has quit [Ping timeout: 272 seconds]
__ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<fjahr>
fanquake: I haven't touched the gha stuff so far but giving it a shot
brunoerg has quit [Ping timeout: 248 seconds]
<bitcoin-git>
[bitcoin] fjahr opened pull request #28567: ci: Only run functional tests on windows in master (master...2023-10-gha-win) https://github.com/bitcoin/bitcoin/pull/28567
DarrylTheFiish has quit [Ping timeout: 258 seconds]
Guyver2 has joined #bitcoin-core-dev
Flow has quit [Ping timeout: 248 seconds]
Flow has joined #bitcoin-core-dev
__ has quit [Quit: Leaving]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
dberkelmans has joined #bitcoin-core-dev
dberkelmans has quit [Ping timeout: 245 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
<sdaftuar>
glozow: instagibbs: can you remind me, do we have a workable plan for getting rid of the carveout rule?
<sdaftuar>
i thought maybe v3 + package rbf would be enough, except i wasn't sure if that covered the case where the replacement package used the same parent as what was in the mempool (and so package deduplication would reduce to a sibling eviction case, which was not necessarily something that would work?)
brunoerg has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fjahr opened pull request #28569: Don't log cache rebalancing in absense of a snapshot chainstate (master...2023-10-au-cache-log) https://github.com/bitcoin/bitcoin/pull/28569
brunoerg has quit [Ping timeout: 252 seconds]
brunoerg has joined #bitcoin-core-dev
<glozow>
sdaftuar: yep, hoping to get rid of it with v3. there’s logic to handle the v3 child replacing a v3 child so that it doesn’t get rejected for the parent looking like it has 2 children (in ApplyV3Ruled iirc). if it’s not a replacement then yeah they’re out of luck
<glozow>
Intended usage is that people just have 1 anchor output, so it should be a replacement
<sdaftuar>
ah, i didn't realize that intended usage. could we deploy v3 rules even without package relay then, to immediately make carveout no longer necessary?
<sdaftuar>
er even without package rbf
dberkelmans has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 258 seconds]
lbia1 is now known as lbia
brunoerg has joined #bitcoin-core-dev
jamesob7 has joined #bitcoin-core-dev
jamesob has quit [Ping timeout: 240 seconds]
jamesob443688173 has quit [Ping timeout: 240 seconds]
jamesob7 is now known as jamesob
jamesob2 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 258 seconds]
jamesob has quit [Read error: Connection reset by peer]
jamesob has joined #bitcoin-core-dev
jamesob2 has quit [Ping timeout: 240 seconds]
<sdaftuar>
glozow: the context for this line of thinking is that i don't believe carveout can be made to work in a cluster-size-limited mempool, so to avoid breaking functionality i wonder if we can roll out an initial version of v3 policy first (and then breaking carveout with cluster limits won't be an issue)
dberkelmans has quit [Ping timeout: 245 seconds]
<bitcoin-git>
[bitcoin] fanquake opened pull request #28571: depends: fix unusable memory_resource in macos qt build (master...qt_fix_more_macos_broken) https://github.com/bitcoin/bitcoin/pull/28571
brunoerg has joined #bitcoin-core-dev
jamesob4 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
jamesob has quit [Ping timeout: 240 seconds]
jamesob4 is now known as jamesob
brunoerg has joined #bitcoin-core-dev
<glozow>
Definitely in favor of getting rid of carve out asap. I suppose ideally we'd want to keep carveout until LN doesn't need 2 anchors anymore? But IIUC to make the single anchor output scheme work, we'd need package RBF + relay.
<sdaftuar>
Do we need more than regular RBF to be as good as the status quo?
<glozow>
Are you still thinking of getting rid of descendant limits for cluster mempool?
<sdaftuar>
Yeah
<sdaftuar>
I'm hopeful that it'll work to eliminate all ancestor and descendant statistics from the mempool, which I am expecting will speed up mempool operations substantially
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
preimage has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
<glozow>
I think status quo is "either party can always bump the shared tx provided it's already in mempool" so I think the only options are to give each person an anchor to CPFP + carveout, or have package RBF.
brunoerg has joined #bitcoin-core-dev
<glozow>
Hm, I've been thinking that we could get v3 package relay a bit faster if we added logic that was like "tx failed for too low fee? check if child is in orphanage + submit them together" like what you had in #16401.
<sdaftuar>
i thought from the above that in the future, LN could use a single anchor output (of a v3 transaction) that could be spent by either party in an unconfirmed v3 descendant
<sdaftuar>
then either party could use regular RBF to replcae that descendant if it was too low fee?
<sdaftuar>
even without package rbf, or package relay, that would be as good as carveout today, no?
<sdaftuar>
or is the issue that there are other outputs that could be spent as wlel, which would require sibling eviction? if so, i think sibling eviction in the v3-world is doable, but more complex than i was hoping to need
<glozow>
oh i see what you're saying. yeah that seems fine... the other outputs are on a 1-block relative timelock so they can't be spent unconfirmed
<sdaftuar>
i was just skimming #25038 -- i think if we wanted a new v3 policy by itself, without package validation or package rbf changes, it should be a much smaller changeset
<glozow>
yes it would! I've been thinking of opening a separate PR for it as I was hoping to defer package RBF until post-cluster mempool
<sdaftuar>
yeah i think that makes sense to me as well, though i'm afraid of gating anything on cluster-mempool, i also think that carveout could be a blocker for cluster-limits so would be good to eliminate that first if we can
<bitcoin-git>
bitcoin/master e14cc8f furszy: gui: macOS, do not process dock icon actions during shutdown
<bitcoin-git>
bitcoin/master bae209e furszy: gui: macOS, make appMenuBar part of the main app window
<bitcoin-git>
bitcoin/master 88e5a02 Hennadii Stepanov: Merge bitcoin-core/gui#751: macOS, do not process actions during shutdown
<bitcoin-git>
[gui] hebasto merged pull request #751: macOS, do not process actions during shutdown (master...2023_gui_fix_appbar_crash) https://github.com/bitcoin-core/gui/pull/751
<sdaftuar>
are we confident that v3 will satisfy the LN use case in the way you describe? not sure how much vetting that needs or how much time we need to give for other software to migrate to it
<sdaftuar>
(even after its deployed in our software)
vasild has quit [Remote host closed the connection]
<glozow>
I think instagibbs would be better for this question, I've only really had conversations about both package relay + v3
<bitcoin-git>
[bitcoin] ryanofsky opened pull request #28573: github actions: Fix test-one-commit when parent of head is merge commit (master...pr/onecommit) https://github.com/bitcoin/bitcoin/pull/28573
<sdaftuar>
i guess for the purposes of cluster-size limits, the thing we need to avoid needing a carevout rule for lightning is just to have any notion of a topology restriction in our policy rules
<sdaftuar>
so the v3 rules, of requiring the whole thing to just be 1parent-1child (at most), are even more restrictive than we'd need. that's fine, but there could be room to relax it in the future.
<glozow>
would it be more involved to enforce topo restrictions if anc/desc statistics are removed from mempool entries? Do we calculate them on the fly when submitting a transaction?
<sdaftuar>
good question to raise, but i think it should be fine. my intuition is that any complicated topology needs more info than just count-with-ancestors and count-with-descendants anyway (so you have to walk everything), while simple topologies like we've proposed (1 parent, 1 child, etc) are just as easy to do without the cached state
<sdaftuar>
we do cache direct parents and direct children, which i think we'd keep
Flow has quit [Ping timeout: 272 seconds]
mudsip has joined #bitcoin-core-dev
<glozow>
sounds good
Flow has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
vasild has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
luke-jr has quit [Ping timeout: 260 seconds]
vasild has joined #bitcoin-core-dev
Guyver2 has left #bitcoin-core-dev [Closing Window]
<bitcoin-git>
[bitcoin] furszy opened pull request #28574: wallet: optimize migration process, batch db transactions (master...2023_wallet_batch_migration) https://github.com/bitcoin/bitcoin/pull/28574
Talkless has quit [Quit: Konversation terminated!]
preimage has quit [Ping timeout: 260 seconds]
zeropoint has joined #bitcoin-core-dev
jonatack has quit [Read error: Connection reset by peer]
jonatack has joined #bitcoin-core-dev
ahsjfid has joined #bitcoin-core-dev
__ has joined #bitcoin-core-dev
__ has quit [Client Quit]
_i_n_j_i_r_ has joined #bitcoin-core-dev
<instagibbs>
sdaftuar concept ACK on getting rid of limits if it cleans up things(it also makes thinking about things easier), and I was indeed wondering about the interaction with cluster mempool.
<instagibbs>
To get real uptake I really think you need v3 + package rbf at a minimum. That said, the cpfp carveout is really weakly motivated in practice. Might be worth putting out an e-mail asking if it's ok to look to remove it, especially if it moves cluster mempool(and possible top-of-mempool-replacement changes) forward?
<instagibbs>
In practice you can't actually use the carve-out, mostly, because it only works if you see the other counter-parties commitment transaction in your local mempool, and then CPFP it, vs just package RBF'ing it with your own.