--- Log opened Fri Dec 16 00:00:47 2022
00:07 -!- as2333 [~as2333@host95.201-252-100.telecom.net.ar] has quit [Quit: as2333]
00:10 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has joined #bitcoin-core-dev
00:17 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/03708dac0ac6...5055d07edf46
00:17 < bitcoin-git> bitcoin/master c39619e Hennadii Stepanov: clang-tidy: Fix `readability-redundant-string-init` in headers
00:17 < bitcoin-git> bitcoin/master 5055d07 MarcoFalke: Merge bitcoin-core/gui#685: clang-tidy: Fix `readability-redundant-string-...
00:17 < bitcoin-git> [gui] MarcoFalke merged pull request #685: clang-tidy: Fix `readability-redundant-string-init` in headers (master...221215-tidy-string) https://github.com/bitcoin-core/gui/pull/685
01:00 -!- euclid[m] [~euclidhni@2001:470:69fc:105::2b6f] has quit [Quit: You have been kicked for being idle]
01:09 -!- Guyver2 [~Guyver@77-174-98-73.fixed.kpn.net] has left #bitcoin-core-dev [Closing Window]
01:37 < fanquake> * [new tag]             v23.1 -> v23.1
01:37 < bitcoin-git> [bitcoin] fanquake pushed tag v23.1: https://github.com/bitcoin/bitcoin/compare/v23.1
02:03 -!- kexkey [~kexkey@static-198-54-132-140.cust.tzulo.com] has quit [Ping timeout: 272 seconds]
02:04 -!- kexkey [~kexkey@static-198-54-132-140.cust.tzulo.com] has joined #bitcoin-core-dev
02:19 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
02:21 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
02:23 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Remote host closed the connection]
02:48 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
02:50 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
02:54 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
02:55 < bitcoin-git> [bitcoin] hebasto opened pull request #26710: clang-tidy: Fix `performance-for-range-copy` in headers (master...221216-tidy-range) https://github.com/bitcoin/bitcoin/pull/26710
03:03 -!- jespada_ is now known as jespada
03:10 -!- szkl [uid110435@id-110435.uxbridge.irccloud.com] has joined #bitcoin-core-dev
03:19 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334] has joined #bitcoin-core-dev
03:27 < bitcoin-git> [bitcoin] glozow opened pull request #26711: [WIP] validate package transactions with their in-package ancestor sets (master...2022-12-subpackages) https://github.com/bitcoin/bitcoin/pull/26711
03:28 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Ping timeout: 265 seconds]
03:34 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
03:35 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 255 seconds]
03:35 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
03:59 < bitcoin-git> [gui] hebasto opened pull request #686: clang-tidy, qt: Force checks for headers in `src/qt` (master...221216-tidy) https://github.com/bitcoin-core/gui/pull/686
04:01 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
04:26 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
04:27 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
04:38 -!- jonatack2 [~jonatack@user/jonatack] has quit [Ping timeout: 252 seconds]
04:55 < sdaftuar> glozow: i was thinking more about package validation (re: package feerate definition and #26711)
04:55 <@gribble> https://github.com/bitcoin/bitcoin/issues/26711 | [WIP] validate package transactions with their in-package ancestor sets by glozow · Pull Request #26711 · bitcoin/bitcoin · GitHub
04:56 < sdaftuar> glozow: can we say that it should never be the case that the "package feerate" of a transaction should never exceed the transaction's own feerate?
04:58 < sdaftuar> conceptually i assume that even after #26711, that would still be possible -- imagine a "diamond" transaction chain, where you have a low fee parent A, 2 children B and C that each can't quite pay for A on their own, but once joined via a transactin D that spends them both, results in the package making it in.
04:58 <@gribble> https://github.com/bitcoin/bitcoin/issues/26711 | [WIP] validate package transactions with their in-package ancestor sets by glozow · Pull Request #26711 · bitcoin/bitcoin · GitHub
04:59 < sdaftuar> it's not clear to me whether we want those diamond transaction packages in our mempool or not!
05:14 < sdaftuar> on further thought, letting in diamond chains can be bad, because you could imagine in the worst case that our mempool could be full of transactions that we wouldn't ever mine.
05:15 < sdaftuar> so maybe the easiest protection is just to require that when evaluating ancestor packages for mempool inclusion, if the child transaction's own feerate is not 
05:15 < sdaftuar> at least as big as the package feerate, that we abort
05:25 -!- AaronvanW [~AaronvanW@user/AaronvanW] has joined #bitcoin-core-dev
05:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334] has quit [Remote host closed the connection]
05:40 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334] has joined #bitcoin-core-dev
05:44 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334] has quit [Ping timeout: 252 seconds]
06:01 < glozow> sdaftuar: I suppose one could say the diamond shouldn't get in - similar idea to a long chain of 0-fee transactions with a big fee-bumper at the bottom. I'm not sure "if the child transaction's own feerate is not at least as big as the package feerate, that we abort" is sufficient. If we have 2 parents, 1 bumping the other, and a low-feerate child spending both, we should keep the parents.
06:08 < sdaftuar> yes i agree with that. i was just thinking that whenever we consider a (sub-)package for validation, that a final sanity check would be that the child tx feerate exceed the (sub-)package feerate, or else we reject/move on
06:09 < sdaftuar> so that's still consistent with the idea of 26711
06:12 < sdaftuar> one concern i have is that even with a check like this, there may be some topologies we still shoulnd't let in for some sort of DoS reason
06:14 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334] has joined #bitcoin-core-dev
06:14 < bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5055d07edf46...7386da7a0b08
06:14 < bitcoin-git> bitcoin/master a272480 fanquake: doc: add 23.1 release notes
06:14 < bitcoin-git> bitcoin/master 7386da7 fanquake: Merge bitcoin/bitcoin#26709: doc: add 23.1 release notes
06:14 < bitcoin-git> [bitcoin] fanquake merged pull request #26709: doc: add 23.1 release notes (master...historical_rel_notes_23_1) https://github.com/bitcoin/bitcoin/pull/26709
06:18 -!- brunoerg [~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334] has quit [Ping timeout: 252 seconds]
06:22 -!- brunoerg [~brunoerg@187.183.43.178] has joined #bitcoin-core-dev
06:24 < glozow> sdaftuar: ah yes, that makes sense to me
06:26 < sdaftuar> in thinking about potential DoS vectors i have a new concern that i'm not quite sure how to think about, relating to package validation:
06:26 < sdaftuar> package validation gives us a way to have (eg) a zero fee tx in the mempool, if it comes in with a child that pays for it.
06:27 < sdaftuar> if that child were to get RBF'ed by a replacement tx that drops the zero fee parent, then we'll end up with a transaction in the mempool that will never be mined
06:27 < instagibbs> unless it's trimmed
06:27 < instagibbs> yes
06:27 < sdaftuar> if that transaction is large, it could be used as a parent of incoming transacitons which will also never be mined
06:27 < sdaftuar> this only works when the mempool is not full -- or else as instagibbs notes it would be trimmed
06:27 < sdaftuar> but this still seems vaguely bad?
06:28 < glozow> I was thinking about this the other day as well. let me find my writeup...
06:29 < glozow> https://gist.github.com/glozow/f0ddaa36290d7263a67e64bd7c0b8a92
06:29 < instagibbs> actually it relies on the mempool being pretty much empty?
06:29 < sdaftuar> instagibbs: yeah
06:30 < instagibbs> otherwise the only difference is min relay vs free
06:30 < sdaftuar> i think my concern is that the mempool shouldn't have things in it that would never get mined, eg because they're below minrelay fee (which we compare against in the mining code iirc)
06:30 < instagibbs> Yeah I get it
06:31 < glozow> I suppose then, in `TrimToSize()`, we should evict low-descendant-feerate junk even when we are not at capacity
06:32 < sdaftuar> specifically things below minrelayfee (i think its ok if things are below mempool minfee). that may work, not sure if there are any downsides to that
06:34 < glozow> that makes sense to me. apart from TrimToSize, do we want to try to calculate the txns that will be below minrelay fee due to replacement?
06:34 < instagibbs> unpaid-for-things getting evicted from a wallet perspective is fine, we'll just send a package again
06:35 < sdaftuar> glozow: reading your gist now... i guess the worst case is that we drop 2400 additional transactions from the mempool due to this type of behavior?
06:37 < instagibbs> so is there two concepts: allowing existing child-less txns to hang around for 2 weeks, vs letting a *new* tx in that we wouldn't mine?
06:37 < instagibbs> one we've already validated, holding onto it isn't that expensive(?)
06:38 < sdaftuar> instagibbs: i think that's fair but its complicated to stop a new tx from chaining off it, at first glance
06:38 < instagibbs> right, single txn evaluation would have to be modified 
06:39 < sdaftuar> instagibbs: yes and in a way that i think isn't really possible. imagine the same scenario of leaving a zero fee transaction in, but before you drop the child which paid for it, you first add a bunch of small lowfeerate children
06:39 < instagibbs> mhmm yeah
06:39 < sdaftuar> it would be hard to tell (after the large fee paying child is replaced) whether the parent should be allowed or not
06:39 < instagibbs> i can see
06:40 < glozow> sdaftuar: yes, that's the worst case I could come up with is 50 packages, 1 child each bumping 24 parents. replacement conflicts directly with 1 parent from each package. 100 total to meet Rule 5, 23*50=1150 total txns that are now below minrelay fee but weren't counted in the 100.
06:40 < instagibbs> from a usability perspective I think dropping is fine, so now it would "just" be a DoS thing
06:42 < sdaftuar> glozow: nitpicking but i believe 100 packages should be possible, each of which has 1 child bumping 24 parents and another input that is confirmed. replacement can conflict with each of the 100 children (double spending the confirmed input only, and dropping the package), resulting in 100 conflicts total and 2400 additional low fee parents that would have to be dropped
06:42 < sdaftuar> new tx would ahve no in-mempool parents
06:42 < glozow> ahhh good point yes! 100 packages is possible
06:44 < sdaftuar> it may be worth a standalone PR that adds removal of txs below the minrelayfee to TrimToSize and see if any reviewers spot an issue with that?
06:44 < sdaftuar> though i guess it'll be the interaction of that and package validation that we need to really evaluate
06:45 < sdaftuar> another option is that TrimToSize() can just bail early after a certain number of evictions, and continue again later
06:45 < sdaftuar> it's probably not critical that we evict everything immediately (if we're not full)
06:46 < instagibbs> Sorry, what does doing it in stages accomplish?
06:46 < glozow> bail early because we don't want `TrimToSize()` to take a long time?
06:46 < sdaftuar> glozow: yeah
06:46 < instagibbs> ah :)
06:46 < sdaftuar> i dunno, maybe it's fast, i have no idea :)
06:47 < glozow> we would want to finish these evictions before we validate another transaction for acceptance, right?
06:48 < sdaftuar> glozow: i agree that would be simplest
06:49 < sdaftuar> the alternative would be to add complexity to our logic to prevent relay of a transaction that we ultimately drop
06:51 < glozow> what would preventing relay look like? it would fail a fee filter when we announce (though it's possible we've already announced it). would we add another filtering step when we respond to getdata?
06:52 < sdaftuar> i don't really know - i was just imagining coming up with a special case for what happens when we validate a transaction at a time when we know TrimToSize() didn't finish, and needing a way to delay relay of anything until that completes
06:52 < sdaftuar> seems messy
06:52 < sdaftuar> the issue here being transactinos whose own feerates pass feefilter, but with a (eg) zero-fee parent that shouldn't be in the mempool, would not be accepted
06:53 < sdaftuar> hopefully evicting 2500 transactions is fast enough, relative to transaction validation, that we can ignore this question
06:53 < glozow> if we're confident that it's bounded (2400 seems somewhat ok), it seems like evicting in TrimToSize() seems like the simplest approach. another would be for CTxMemPool to mark things as "to be lazily removed" and not hand those entries out
06:54 < sdaftuar> makes sense
06:55 < instagibbs> eviction benchmark needs some beefing :)
06:56 < glozow> yeah, can write a bench
06:57 < instagibbs> one exists, it's just very trivial
06:57 < sdaftuar> i think the right metric is as a percentage of transaction validation time... unfortunately that can be slow for a tx with a lot of inputs, and very slow if an adversary wants it to be... but from that perspective taking a little more time in the mempool will seem minor
07:07 -!- jonatack2 [~jonatack@user/jonatack] has joined #bitcoin-core-dev
07:40 < sdaftuar> oh... i just realized that TrimToSize() can't really do what we need here, for the same reason as why it would be hard to change single-tx validation to not allow using a parent that should have been removed
07:41 < sdaftuar> it's the same scenario i wrote above: imagine zero-fee txA arrives with txB, which pays for it.
07:42 < sdaftuar> before txB is removed from the mempool via an RBF that drops A as a parent, imagine that txC and txD arrive and are children of txA.
07:42 < sdaftuar> you can construct txC and txD so that the descendant feerate of A is greater than the minrelayfee, but neither C nor D have an ancestor feerate greater than the minrelayfee
07:43 < sdaftuar> so again we'd end up with transactions in the mempool that never get mined.
07:44 < sdaftuar> i'm starting to wonder if we should try to staple packages together, so taht if any part get RBF'ed out, the whole package has to go
07:44 < sdaftuar> that would be akin to how single-transactionv alidation works today
07:45 < instagibbs> basically track how sub-packages get accepted together
07:45 < sdaftuar> right
07:46 < sdaftuar> if we could implement taht, i think it would solve DoS concenrs, but raise potential incentive compatibility concerns
07:47 < instagibbs> things getting kicked out when they would have improved the next template?
07:47 < instagibbs> or something else
07:47 < sdaftuar> yeah something like that. an RBF that doens't pay for the whole package's eviction but just a small piece of it, etc.
07:49 < sdaftuar> oh i guess the way i stated it, you'd get logical contradictions too. sigh.
07:49 < sdaftuar> not sure how to solve this
07:49 < glozow> I do think it could be beneficial to track what transactions got in together, or somehow keep track of/update "fee dependencies" between `CTxMemPoolEntry`s? it would also help with persisting packages through a dump/load
07:49 < bitcoin-git> [bitcoin] JeremyRubin closed pull request #23309: [WIP] Add a basic python REST API Server Wrapper (master...rest-python) https://github.com/bitcoin/bitcoin/pull/23309
07:49 < bitcoin-git> [bitcoin] JeremyRubin closed pull request #22954: [TESTS] Allow tx_invalid.json tests to include flag rules for if_unset: [A,B,C] then_unset: [D] (master...if_unset_then_unset) https://github.com/bitcoin/bitcoin/pull/22954
07:49 < bitcoin-git> [bitcoin] JeremyRubin closed pull request #22876: [TESTS] Update Transaction Tests to permit setting a flag as always on and disabling the exhaustive failure test (master...update-txvalid-json) https://github.com/bitcoin/bitcoin/pull/22876
07:50 < sdaftuar> glozow: gets tricky with RBF. imagine a package comes in, and then the child is replaced with a new child (which has the same ancestry). you'd swap out the old child for the new child in your package tracking?
07:50 < sdaftuar> now imagine it has a somewhat different ancestry...
07:56 < glozow> yeah...
07:58 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
08:00 < _aj_> glozow, sdaftuar: what do you think of a "mempoolreplace" rpc, that allows you to add a tx package [A,B,C] to your mempool, despite conflicts X,Y,Z, ignoring all rbf rules (at most optionally trying to read X,Y,.. to the mempool and doing so if they're valid rbf replacements of A,B,C..)
08:02 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
08:04 < glozow> correct me if i'm wrong - today, you could have a parent + 2 children at the bottom of the mempool, where the parent's descendant feerate is above mempool min feerate but each child's ancestor package is below mempool min feerate. so not evicted, but also not great. though everything is above min relay fee, so not entirely wasted space
08:06 < glozow> _aj_: do you mean that, after the RPC finishes, all 6 transactions would be in our mempool?
08:06 < sdaftuar> glozow: yeah i think there's a distinction in my mind between mempool min fee and minrelayfee, because once you go below minrelayfee the mining code will always ignore it
08:07 < sdaftuar> so if you are able to get stuff in below minrelayfee, that is a free relay DoS on the network. seems like it's bounded because once the mempool fills up, it goes away, but i wonder if we can do better
08:08 < _aj_> glozow: after the RPC finishes, either (a) A,B,C are in your mempool or, (b) it's as-if you had A,B,C in your mempool and then received X,Y,... via (package) relay
08:09 < _aj_> glozow: X,Y,.. conflicts with A,B,C so you should never have all of them in your mempool
08:09 < sdaftuar> _aj_: i don't think i understand the problem you're trying to solve
08:10 < _aj_> glozow: (the idea being that this would allow you to build an alternative layer 2 relay network and populate your mempool using it, if there's some subset of transactions where regular rbf is sub-optimal)
08:10 < sdaftuar> would those transactions then be relayed on the p2p network, once accepted to the mempool?
08:11 < _aj_> sdaftuar: not sure, i'm assuming "no"
08:11 < sdaftuar> ok i definitely do not understand what would be achieved then :)
08:12 < glozow> sdaftuar: right so if, as a short term workaround, all transactions have to meet min relay fee but packages can cpfp things below mempool min fee, seems like we would be on par with current situation? not ideal, but trying to get a sense of what -0 looks like.
08:12 < sdaftuar> a transaction relay network that is separate from the one we maintain?
08:13 < sdaftuar> glozow: are you suggesting that we rewrite TrimToSize() to look at ancestor packages and evict ones that are below minrelayfee?
08:13 < _aj_> sdaftuar: if you have a tx X which you want mined, you relay it over p2p but it's pinned by Y and goes nowhere. so you also relay it over L2-relay, and hope that a miner is on L2-relay. i think this is what would be necessary to make that possible
08:13 < sdaftuar> _aj_: got it, now i understand
08:14 < glozow> _aj_: if it's a fee-related pin, prioritisetransaction() may help?
08:16 < sdaftuar> _aj_: i think you'll run into the same issues we have in Bitcoin Core's logic wrt DoS. fundamentally we don't have a total ordering on transaction desirability, and that leads to the DoS concerns we have
08:16 < _aj_> glozow: could be a non fee-related pin, but also seems like that would also allow you to prevent D,E,F at higher feerates from replacing A,B,C in the normal way, which would be annoying (i guess you could prioritisetransaction, sendrawtx, de-prioritisetransaction?)
08:16 < glozow> sdaftuar: I guess I'm (lightly) suggesting / wondering what it looks like to only use package feerate for the mempool min feerate, and not min relay fee check. so you could bump a 1sat/vB tx when the mempool's full, but you can't bump a 0sat/vB tx.
08:17 < sdaftuar> glozow: ahh i see
08:17 < glozow> _aj_: yeah if you want it to be replaceable normally afterwards, you could just undo the prioritisetransaction after it's in.
08:17 < _aj_> sdaftuar: that would then be L2-relay's problem, the idea being you only apply L2-relay to some very limited subset of txs where you can come up with a sane solution to that problem (and this is just an rpc for such a thing to use)
08:17 < sdaftuar> glozow: yeah i think that works?
08:18 < glozow> sdaftuar: (though I know that makes package acceptance much less cool...)
08:18 < sdaftuar> glozow: if we can get anything that works i think we should call it a win :)
08:19 < sdaftuar> all this rbf/package stuff seems too hard...
08:19 < sdaftuar> _aj_: fundamentally i'd agree that we could offer infrastructure (such as RPCs) to allow for off-network transaction relay, and outsource the DoS problems 
08:19 < _aj_> "can't bump a 0sat/vb tx" ?
08:20 < glozow> okay so then we'd be at -0. and let's say we then loosen to "with package relay, you can bump a v3 transaction below min relay fee" ? then we could do all our evictions inside of `TrimToSize()` - there can only be 100 i think, and none of them can have descendants.
08:24 < sdaftuar> i can't recall if we require that rbf'ing a v3 transaction requires the replacement to be v3 itself?
08:24 < glozow> sdaftuar: it doesn't, no
08:24 < sdaftuar> i guess either way, you can't chain a v2 child on a v3 0fee transaction so maybe doens't matter
08:25 < sdaftuar> so the rule is that non-v3 transactions must always have minrelayfee on them?
08:25 < glozow> yep
08:26 < sdaftuar> i think that works... will give it more thought
08:27 < glozow> yeah. so any 0-fee transaction can only be in a package of size 2. Limit 100 replacements = limit 100 such 0-fee transactions afterwards. None of them can have any other descendants.
08:28 < _aj_> glozow: can't you have n 0-fee txs as a package of size n+1 ?
08:29 < glozow> _aj_: no, because of other v3 rules. v3 can only have v3 ancestors, and only v3 descendants.
08:29 < glozow> and a v3 can only have 1 child
08:30 < glozow> and only 1 parent
08:30 < _aj_> glozow: right, so n 0-fee parents and 1 hihg-fee child that cpfp's all of them?
08:31 < glozow> _aj_: ancestor limit = 2: https://github.com/bitcoin/bitcoin/pull/25038/files#diff-526d4fd6bad9d82601d03afcb3e250f1476b0f650b96d75dd702354ec2ae8cf6R23
08:31 < glozow> (this is new from the last ~month)
08:33 < _aj_> is there doc/rationale for that? it seems pretty limiting?
08:34 < glozow> https://github.com/bitcoin/bitcoin/pull/25038#issuecomment-1320295394
08:37 < instagibbs> there's a pin behind every blade of grass
08:37 < glozow> (in case the comment doesn't load) Let's say an adversary wants to pin a tx B (make it hard to replace). They add a high-fee descendant of B that also spends from a large, low-feerate mempool transaction, C. The child may pay a very large fee but not actually be fee-bumping B if its overall ancestor feerate is still lower than B's individual feerate. For example, assuming the default ancestor size limit is 101KvB, B is 1000vB paying 2sat/vB, 
08:37 < glozow> and C is 99KvB paying 1sat/vB, adding a 1000vB child of B and C increases the cost to replace B by 101Ksat.
08:37 < _aj_> okay, goes in my "makes package acceptance much less cool..." but "if we can get anything that works i think we should call it a win" bucket
08:37 < glozow> instagibbs: hashtag v3 fixes this
08:38 < instagibbs> reasoning about this stuff is so hard :(
08:38 < _aj_> not being able to pay for multiple parents means v3-ephemeral isn't a replacement for sighash_group anymore
08:38 < _aj_> (not that sighash_group doesn't have all the same pinning issues itself)
08:38 < instagibbs> yeah
08:39 < _aj_> huh
08:40 < _aj_> hmm, un-"huh", that was a dumb thought bubble
08:40 -!- ajonas_ [uid385278@id-385278.helmsley.irccloud.com] has joined #bitcoin-core-dev
08:42 < _aj_> glozow: is it interesting to test this on signet/inquisition in general; or only in the context of eltoo btw? (the cpfp 0-fee txs stuff needs miner support presumably)
08:43 < instagibbs> V3 is still interesting for anything that isn't batching, imo
08:43 < instagibbs> batch bumps* I mean
08:43 < instagibbs> batched payouts, still interesting
08:49 < _aj_> just not sure what parts are fine to just test on mainnet vs are worth exploring in something more controlled that's not just regtest
08:49 < glozow> v3 in general should make stuff less pinnable and our rbf heuristics more accurate. replacing a v3 transaction doesn't require the RBF carve out (where if we have 1 conflict, we add its descendant size to the descendant count to avoid overestimating). we might also be able to get rid of cpfp carve out if double anchor outputs are no longer necessary
08:51 < _aj_> i don't think we could get rid of cpfp-carveout until there were ~0 old ln channels remaining; ie years and years away?
08:51 < instagibbs> correct
08:51 < instagibbs> well.... maybe they gave up on using the carveout
08:51 < instagibbs> can't recall
08:52 < _aj_> the carveout's there so you can always use your anchor, even if your counterparty is trying to otherwise hit descendant limits
08:53 < _aj_> (iirc)
08:53 < instagibbs> you're assuming you see the other's commit tx in mempool, then spend the anchor
08:53 < instagibbs> or attacker does the other side 
08:53 < instagibbs> if no one actually implements it, we can probably speed up removal...
08:54 < _aj_> yeah; i don't believe in ignoring the mempool :)
08:55 < instagibbs> feel free to yell at LN implementations :D 
08:56 < glozow> yes sorry i should have said "if double anchor outputs are no longer *used*"
08:57 < instagibbs> I guess the risk is evil nodes run by _aj_ *would* scrape the mempool and pin honest users
08:57 < instagibbs> when trying to submit their own commit tx
09:03 < _aj_> instagibbs: anchors are only relevant if the mempool's not empty (otherwise the native fee on the commitment will get it mined) and the dual anchors are only needed in case your counterparty is trying to prevent the channel from actually closing for some reason (waiting for a htlc to expire? keeping your funds hostage?). if both those things are true, you either need an L2-relay to bypass the 
09:03 < _aj_> pinning, or need to see what's going on in the mempool to add your own anchor... i think you know the txid of their commitment, so you could construct a spend for your anchor tx off their commitment despite not having their signature for their commitment, and just optimistically broadcast that to random nodes
09:13 -!- as2333 [~as2333@host95.201-252-100.telecom.net.ar] has joined #bitcoin-core-dev
09:21 < instagibbs> gossip over LN p2p is kinda interesting, you won't know necessarily any old commit tx txid(?) but if a LN peer sees it, they might take your bump of it 
09:23 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
09:25 -!- jespada [~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:33 < _aj_> if it's an old commit, you claim all the funds as soon as it hits the blockchain, and it doesn't really much matter when that happens?
09:35 < instagibbs> my point was you can't blindly spam the spend of the latest commit tx based on knowing the txid. If it's in your mempool you're good to go of course
09:35 < instagibbs> or gossiped
09:37 < _aj_> sure you can? if an old commitment was posted, it'll just be ignored
09:37 < instagibbs> We must be talking about different things
09:38 < _aj_> if they haven't posted a commitment tx, yours relays; if they've posted their current version and pinned it, your anchor spend spamming works; if they posted an old one, then you wait and punish. you win in each case?
09:39 < _aj_> (spamming the anchor tx pointlessly while waiting is fine, since you can't distinguish the latter two cases)
09:40 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has quit [Ping timeout: 272 seconds]
09:40 -!- b_101 [~robert@189.236.6.68] has joined #bitcoin-core-dev
09:44 -!- b_101 [~robert@189.236.6.68] has quit [Ping timeout: 252 seconds]
09:45 -!- b_101 [~robert@173.254.196.62.adsl.inet-telecom.org] has joined #bitcoin-core-dev
09:47 < bitcoin-git> [bitcoin] brunoerg opened pull request #26714: test: add coverage for unparsable `-maxuploadtarget` (master...2022-12-maxuploadtarget-parse-test) https://github.com/bitcoin/bitcoin/pull/26714
09:48 < instagibbs> If you mean old commit tx are too dangerous for attacker to use a a pin, sure
09:48 < instagibbs> they could still do it, but then their risk goes through the roof
09:48 < _aj_> i mean, if they successfully use it as a pin, you don't lose any money?
09:48 < _aj_> for ln-penalty, not eltoo of course
09:49 < instagibbs> if you never see it, you can't penalize it
09:49 < instagibbs> if it gets mined game over
09:49 < instagibbs> (for attacker)
09:51 < _aj_> i suppose (1. pin old commitment. 2. wait for htlcs to timeout. 3. let old commitment expire, unmined. 4. publish current commitment, claim expired htlcs) works, if successful
09:51 -!- pablomartin [~pablomart@194.35.233.212] has joined #bitcoin-core-dev
10:07 -!- Hercules1 [~Hercules@ti0018a400-7782.bb.online.no] has joined #bitcoin-core-dev
10:28 < bitcoin-git> [bitcoin] achow101 opened pull request #26715: Introduce `MockableDatabase` for wallet unit tests (master...test-wallet-corrupt) https://github.com/bitcoin/bitcoin/pull/26715
10:38 -!- bomb-on [~bomb-on@user/bomb-on] has quit [Quit: aллилѹіа!]
10:44 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
10:56 -!- jonatack2 [~jonatack@user/jonatack] has quit [Quit: WeeChat 3.7.1]
10:59 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
11:00 < achow101> #startmeeting
11:00 <@core-meetingbot> Meeting started Fri Dec 16 19:00:22 2022 UTC.  The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
11:00 <@core-meetingbot> Available commands: action commands idea info link nick
11:00 < achow101> #bitcoin-core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr furszy gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack josibake jtimon kallewoof kanzure kvaciral laanwj larryruane lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos Murch nehan NicolasDorier 
11:00 < achow101> paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar S3RK sipa vasild
11:00 < kanzure> hi
11:01 < achow101> There are no pre-proposed wallet meeting topics. Does anyone have anything to discuss this week?
11:01 < darosior> Hi
11:01 < sipa> hi
11:01 < brunoerg> hi
11:02 < furszy> hi
11:02 < darosior> I guess i'm curious if people have thought about using descriptors for estimating the size of inputs
11:02 < darosior> Rather than doing a dry run of the signing logic every time
11:02 < achow101> That seems reasonable
11:02 < Murch1> Hi
11:02 < darosior> It would really simplify things moving forward with more advanced scripts
11:03 < achow101> would it just use the worst case size estimation?
11:03 < Murch1> Also the wallet should keep track of its UTXOs
11:03 < darosior> Context:  #26567 and #24149
11:03 <@gribble> https://github.com/bitcoin/bitcoin/issues/26567 | Wallet: estimate the size of signed inputs using descriptors by darosior · Pull Request #26567 · bitcoin/bitcoin · GitHub
11:03 <@gribble> https://github.com/bitcoin/bitcoin/issues/24149 | Signing support for Miniscript Descriptors by darosior · Pull Request #24149 · bitcoin/bitcoin · GitHub
11:03 < darosior> achow101: yes but eventually we should tweak that for Taproot
11:03 -!- kmartin [~kmartin@20014C4E24D79A0034E61D173F32658B.dsl.pool.telekom.hu] has joined #bitcoin-core-dev
11:04 < sipa> One old idea was that descriptors could contain annotations about which keys/subtrees are available or not.
11:04 < sipa> Or might be available.
11:04 < sipa> The miniscript logic can do size estimation with that information, though there is no way to encode that in descriptors now.
11:04 < darosior> Yeah. Also rust-miniscript is experimenting with another approach: https://github.com/rust-bitcoin/rust-miniscript/pull/481
11:06 < darosior> I didn't look into it, but on the surface it sounds similar to having annotations within the descriptor directly.
11:08 < achow101> how would that information would get from the user to the size estimation?
11:08 < achow101> since it could change per transaction
11:09 < darosior> Yeah, a downside is that it would be static
11:09 < darosior> (A downside to hardcoding it within the descriptor)
11:10 < sipa> yeah it's more flexible if it can be done on a per-signature level, but that's a UX nightmare
11:10 < sipa> but there may be useful static information as well
11:11 < darosior> But i guess it's already an improvement in some potential common usecases with Taproot like have keyspend for day-to-day and a timelocked cold key for recovery. You can tell the wallet you use day-to-day to expect that all transactions you will be creating with it will be for the keyspend, and to not overestimate.
11:11 < sipa> e.g. you know that any signature that your bitcoin core wallet will be involved in, will have access to that wallet's private key
11:11 < sipa> if it's not in a hardware wallet
11:12 < achow101> it would definitely be useful to indicate that the keypath is never going to be used
11:12 < darosior> Hmm you could emulate that with partial descriptors? Only import the complete descriptor for the branches you may use on this wallet. And when estimating the size the wallet ignores unknown branches.
11:12 < sipa> opr even better: the key path is always is going to be used
11:13 < sipa> darosior: Yeah, you could, but I think that's only part of the picture, because within one script the same thing applies
11:13 < sipa> And there you very much may want to know everything, even informaton about execution branches you won't use.
11:14 < furszy> separate thing,about the overpaying topic: if we overpay, coin selection would increase its chances to create a change output, which is something that we usually try to avoid.
11:14 < darosior> sipa: wouldn't it be uncommon to have different paths within a single branch?
11:14 < darosior> And for pre-Taproot you don't care, since you always publish the whole script anyway
11:15 < sipa> But even pre-taproot your witness estimation may very much depend on which keys are available.
11:20 < achow101> can we use descriptors to remove the need for the dummy signer entirely? Even with size estimation, we still need the dummy signer for filling PSBTs
11:21 < sipa> I think post-partial-descriptors we can actually move the signing logic into descriptors, rather than the other way around.
11:21 < sipa> And anything that interacts with signing like size estimation too.
11:21 < darosior> Yes i was thinking of going in this direction too.
11:22 < achow101> that could be useful
11:24 < achow101> anything else to discuss?
11:24 < darosior> I need to leave unfortunately. Thank you all for the discussion, happy to see there is interest in this. 
11:25 < sipa> Murch had a topic I think
11:25 < furszy> i have a one too.
11:26 < achow101> Murch1: what was your topic?
11:27 < Murch1> Ah
11:27 < Murch1> No, just a ceterum censeo
11:27 < Murch1> The Bitcoin Core wallet should really keep track of its UTXO pool instead of recalculating it from its list of transactions every time it needs it
11:27 < achow101> furszy: go ahead
11:29 < furszy> Murch1: agree, I actually have a card in my board to move into that direction too.
11:29 < furszy> so
11:29 < furszy> my topic arose here
11:29 < furszy> https://github.com/bitcoin/bitcoin/pull/26661#issuecomment-1353087751
11:29 < furszy> it's the "Second point" there
11:29 < furszy> and S3RK answer to it.
11:30 < furszy> if we agree, could "standardize" it and create a guideline for it.
11:31 < achow101> I've actually tended to avoid using exceptions since we don't have general exception handling
11:31 < achow101> I've only really used them in places where there was no other way to return an error
11:32 < achow101> IIRC an exception will kill the gui
11:32 < Murch1> furszy: Awesome!
11:33 < achow101> but having some guidelines would probably be useful
11:33 < Murch1> Err, just to be clear, that was directed at furszy's UTXO pool plans
11:33 < furszy> yeah, I know achow101. I ended up adding a try catch to the GUI create tx flow because of it.
11:34 < furszy> but.. it sounds that we are avoiding having a somewhat "good" library structure because our qt framework can handle exceptions in a generic manner
11:34 < furszy> *can't
11:35 < furszy> which isn't something related to the wallet's module. It's a GUI issue.
11:36 < achow101> sure, but we need to consider the effects of throwing exceptions on the rest of the software
11:36 < achow101> it would be worthwhile to write up some guidelines and fix qt simultaneously
11:37 < achow101> given that we already do throw exceptions in some places that can already be problematic for the gui
11:38 < furszy> by fixing at you mean the place that require to catch the exception?
11:38 < furszy> or by trying to find a way to catch them all at once
11:39 < achow101> trying to catch them all generically
11:39 < achow101> like we do for the rpc
11:40 < furszy> yeah ok, I briefly tried it in the past but IIRC, there wasn't a way to catch exceptions on slots generically (at least not a way that worked fine on that time..)
11:41 < furszy> thus why ended up coding https://github.com/bitcoin-core/gui/pull/666
11:43 < achow101> hmm, that's something to look into again
11:44 < achow101> just generally though, we should try to avoid things that will cause crashes
11:44 < furszy> well. another possibility is to move all the gui backend calls to be done on a generic worker that catches all the exceptions.
11:45 < furszy> that could also helps in terms of the gui freezing time
11:46 < furszy> sort of "dispatcher"
11:46 < achow101> yeah, there's definitely improvements that could be made there
11:46 < furszy> yep. Will see if can cook something up for it.
11:46 < achow101> my main point was that when we write guidelines for how errors should be emitted, we need to keep in mind how the rest of the project will handle those
11:46 < achow101> and what we could do to make those parts handle them better
11:47 < achow101> any other topics to discuss?
11:50 < achow101> #endmeeting
11:50 <@core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
11:50 <@core-meetingbot> Meeting ended Fri Dec 16 19:50:29 2022 UTC.  
11:50 <@core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2022/bitcoin-core-dev.2022-12-16-19.00.moin.txt
11:55 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has joined #bitcoin-core-dev
11:56 -!- jonatack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
11:58 -!- Hercules1 [~Hercules@ti0018a400-7782.bb.online.no] has quit [Quit: Leaving]
12:05 -!- kmartin [~kmartin@20014C4E24D79A0034E61D173F32658B.dsl.pool.telekom.hu] has quit [Quit: Client closed]
12:08 -!- vasild [~vd@user/vasild] has quit [Ping timeout: 255 seconds]
12:18 -!- brunoerg [~brunoerg@187.183.43.178] has quit []
12:19 -!- ajonas_ [uid385278@id-385278.helmsley.irccloud.com] has quit [Quit: Connection closed for inactivity]
12:22 -!- vasild [~vd@user/vasild] has joined #bitcoin-core-dev
12:31 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:e521:9ffd:bd17:3cda] has joined #bitcoin-core-dev
12:42 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:e521:9ffd:bd17:3cda] has quit [Ping timeout: 252 seconds]
12:54 -!- bomb-on [~bomb-on@user/bomb-on] has joined #bitcoin-core-dev
13:31 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 255 seconds]
13:53 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined #bitcoin-core-dev
14:15 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:e036:4c22:796e:e07c] has joined #bitcoin-core-dev
14:26 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
14:27 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
14:31 < bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7386da7a0b08...66c08e741dc8
14:31 < bitcoin-git> bitcoin/master e6906fc Aurèle Oulès: rpc: Enable wallet import on pruned nodes
14:31 < bitcoin-git> bitcoin/master 71d9a7c Aurèle Oulès: test: Wallet imports on pruned nodes
14:31 < bitcoin-git> bitcoin/master 564b580 Aurèle Oulès: test: Introduce MIN_BLOCKS_TO_KEEP constant
14:31 < bitcoin-git> [bitcoin] achow101 merged pull request #24865: rpc: Enable wallet import on pruned nodes and add test (master...2022-04-importwallet-pruned) https://github.com/bitcoin/bitcoin/pull/24865
14:50 -!- jon_atack [~jonatack@user/jonatack] has joined #bitcoin-core-dev
14:52 -!- jonatack [~jonatack@user/jonatack] has quit [Ping timeout: 260 seconds]
14:59 -!- MrFrancis [~MrFrancis@2001:8a0:fa4c:901:e036:4c22:796e:e07c] has quit [Ping timeout: 252 seconds]
15:14 -!- pablomartin [~pablomart@194.35.233.212] has quit [Ping timeout: 252 seconds]
15:33 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 255 seconds]
15:33 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
15:45 -!- AaronvanW [~AaronvanW@user/AaronvanW] has quit [Quit: Leaving...]
16:06 -!- Talkless [~Talkless@mail.dargis.net] has joined #bitcoin-core-dev
16:32 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #bitcoin-core-dev
16:33 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
17:37 -!- sipsorcery [~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6] has quit [Ping timeout: 265 seconds]
18:11 -!- pablomartin [~pablomart@178.238.11.92] has joined #bitcoin-core-dev
18:17 -!- pablomartin [~pablomart@178.238.11.92] has quit [Ping timeout: 252 seconds]
19:54 -!- lopo [~lopo@45.134.142.215] has joined #bitcoin-core-dev
20:06 < bitcoin-git> [bitcoin] JeremyRubin closed pull request #21702: Implement BIP-119 Validation (CheckTemplateVerify) (24.x...checktemplateverify-rebase-4-15-21) https://github.com/bitcoin/bitcoin/pull/21702
20:12 -!- pablomartin [~pablomart@194.35.233.212] has joined #bitcoin-core-dev
20:37 -!- lopo [~lopo@45.134.142.215] has quit [Read error: Connection reset by peer]
20:58 -!- pablomartin [~pablomart@194.35.233.212] has quit [Ping timeout: 268 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
22:13 -!- bitdex_ [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 255 seconds]
22:20 -!- bitdex_ [~bitdex@gateway/tor-sasl/bitdex] has joined #bitcoin-core-dev
22:37 -!- as2333 [~as2333@host95.201-252-100.telecom.net.ar] has quit [Quit: as2333]
23:13 -!- jarthur [~jarthur@user/jarthur] has quit [Quit: jarthur]
23:15 -!- Guest46 [~textual@101.114.207.112] has joined #bitcoin-core-dev
23:25 -!- Guest46 [~textual@101.114.207.112] has quit [Remote host closed the connection]
23:54 -!- pablomartin [~pablomart@178.238.11.93] has joined #bitcoin-core-dev
--- Log closed Sat Dec 17 00:00:39 2022