12022-12-16T00:06:14 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has joined #bitcoin-core-dev
22022-12-16T00:13:40 *** gnaf <gnaf!~gnaf@93-190-140-117.hosted-by-worldstream.net> has quit IRC (Ping timeout: 252 seconds)
32022-12-16T00:40:40 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has quit IRC (Ping timeout: 252 seconds)
42022-12-16T01:16:38 <ariard> yes you could construct txC has conflicting with multiple inputs from unrelated chain of transactions, that way gaining a batching effect as an adversary
52022-12-16T01:30:30 *** sdhsdsj <sdhsdsj!~sdhsdsj@163.116.192.118> has joined #bitcoin-core-dev
62022-12-16T03:12:07 *** tun4 <tun4!~tun4@cpe08a7c0b41e4e-cm08a7c0b41e4c.cpe.net.cable.rogers.com> has joined #bitcoin-core-dev
72022-12-16T04:01:57 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
82022-12-16T04:03:14 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
92022-12-16T04:03:29 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has quit IRC (Ping timeout: 255 seconds)
102022-12-16T04:03:51 *** ghost43 <ghost43!~ghost43@gateway/tor-sasl/ghost43> has joined #bitcoin-core-dev
112022-12-16T04:08:37 *** tun4 <tun4!~tun4@cpe08a7c0b41e4e-cm08a7c0b41e4c.cpe.net.cable.rogers.com> has quit IRC (Quit: Client closed)
122022-12-16T04:13:37 *** jonatack2 <jonatack2!~jonatack@user/jonatack> has joined #bitcoin-core-dev
132022-12-16T04:14:03 *** jonatack1 <jonatack1!~jonatack@user/jonatack> has quit IRC (Ping timeout: 260 seconds)
142022-12-16T04:20:04 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 252 seconds)
152022-12-16T04:32:14 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
162022-12-16T04:51:43 *** sdhsdsj <sdhsdsj!~sdhsdsj@163.116.192.118> has quit IRC (Quit: Client closed)
172022-12-16T04:52:08 *** sdhsdsj <sdhsdsj!~sdhsdsj@163.116.192.118> has joined #bitcoin-core-dev
182022-12-16T05:01:01 *** cmirror <cmirror!~cmirror@4.53.92.114> has quit IRC (Remote host closed the connection)
192022-12-16T05:01:32 *** cmirror <cmirror!~cmirror@4.53.92.114> has joined #bitcoin-core-dev
202022-12-16T05:14:55 *** sdhsdsj <sdhsdsj!~sdhsdsj@163.116.192.118> has quit IRC (Quit: Client closed)
212022-12-16T06:01:48 *** b_101_ <b_101_!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
222022-12-16T06:04:12 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 252 seconds)
232022-12-16T06:04:44 *** sudoforge <sudoforge!~sudoforge@wireguard/tunneler/sudoforge> has quit IRC (Quit: 404)
242022-12-16T06:34:58 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Remote host closed the connection)
252022-12-16T06:37:00 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
262022-12-16T06:46:21 *** bitdex_ <bitdex_!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
272022-12-16T06:46:23 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has quit IRC (Ping timeout: 255 seconds)
282022-12-16T07:55:53 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
292022-12-16T07:56:12 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
302022-12-16T07:57:08 *** b_101_ <b_101_!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 252 seconds)
312022-12-16T08:07:22 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has quit IRC (Quit: as2333)
322022-12-16T08:10:18 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has joined #bitcoin-core-dev
332022-12-16T08:17:31 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/03708dac0ac6...5055d07edf46
342022-12-16T08:17:32 <bitcoin-git> bitcoin/master c39619e Hennadii Stepanov: clang-tidy: Fix `readability-redundant-string-init` in headers
352022-12-16T08:17:32 <bitcoin-git> bitcoin/master 5055d07 MarcoFalke: Merge bitcoin-core/gui#685: clang-tidy: Fix `readability-redundant-string-...
362022-12-16T08:17:33 <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
372022-12-16T09:00:04 *** euclid[m] <euclid[m]!~euclidhni@2001:470:69fc:105::2b6f> has quit IRC (Quit: You have been kicked for being idle)
382022-12-16T09:09:41 *** Guyver2 <Guyver2!~Guyver@77-174-98-73.fixed.kpn.net> has left #bitcoin-core-dev (Closing Window)
392022-12-16T09:37:52 <fanquake> * [new tag] v23.1 -> v23.1
402022-12-16T09:37:59 <bitcoin-git> [bitcoin] fanquake pushed tag v23.1: https://github.com/bitcoin/bitcoin/compare/v23.1
412022-12-16T10:03:36 *** kexkey <kexkey!~kexkey@static-198-54-132-140.cust.tzulo.com> has quit IRC (Ping timeout: 272 seconds)
422022-12-16T10:04:14 *** kexkey <kexkey!~kexkey@static-198-54-132-140.cust.tzulo.com> has joined #bitcoin-core-dev
432022-12-16T10:19:41 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 255 seconds)
442022-12-16T10:21:30 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
452022-12-16T10:23:32 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Remote host closed the connection)
462022-12-16T10:48:59 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
472022-12-16T10:50:06 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
482022-12-16T10:54:37 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
492022-12-16T10:55:59 <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
502022-12-16T11:03:18 *** jespada_ is now known as jespada
512022-12-16T11:10:25 *** szkl <szkl!uid110435@id-110435.uxbridge.irccloud.com> has joined #bitcoin-core-dev
522022-12-16T11:19:19 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334> has joined #bitcoin-core-dev
532022-12-16T11:27:04 <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
542022-12-16T11:28:08 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Ping timeout: 265 seconds)
552022-12-16T11:34:46 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
562022-12-16T11:35:44 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Ping timeout: 255 seconds)
572022-12-16T11:35:44 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 255 seconds)
582022-12-16T11:59:06 <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
592022-12-16T12:01:08 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
602022-12-16T12:26:38 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
612022-12-16T12:27:06 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
622022-12-16T12:38:22 *** jonatack2 <jonatack2!~jonatack@user/jonatack> has quit IRC (Ping timeout: 252 seconds)
632022-12-16T12:55:47 <sdaftuar> glozow: i was thinking more about package validation (re: package feerate definition and #26711)
642022-12-16T12:55:48 <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
652022-12-16T12:56:19 <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?
662022-12-16T12:58:30 <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.
672022-12-16T12:58:31 <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
682022-12-16T12:59:03 <sdaftuar> it's not clear to me whether we want those diamond transaction packages in our mempool or not!
692022-12-16T13:14:50 <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.
702022-12-16T13:15:30 <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
712022-12-16T13:15:37 <sdaftuar> at least as big as the package feerate, that we abort
722022-12-16T13:25:52 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has joined #bitcoin-core-dev
732022-12-16T13:40:03 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334> has quit IRC (Remote host closed the connection)
742022-12-16T13:40:30 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334> has joined #bitcoin-core-dev
752022-12-16T13:44:49 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334> has quit IRC (Ping timeout: 252 seconds)
762022-12-16T14:01:36 <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.
772022-12-16T14:08:51 <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
782022-12-16T14:09:32 <sdaftuar> so that's still consistent with the idea of 26711
792022-12-16T14:12:39 <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
802022-12-16T14:14:07 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334> has joined #bitcoin-core-dev
812022-12-16T14:14:15 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/5055d07edf46...7386da7a0b08
822022-12-16T14:14:15 <bitcoin-git> bitcoin/master a272480 fanquake: doc: add 23.1 release notes
832022-12-16T14:14:16 <bitcoin-git> bitcoin/master 7386da7 fanquake: Merge bitcoin/bitcoin#26709: doc: add 23.1 release notes
842022-12-16T14:14:27 <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
852022-12-16T14:18:31 *** brunoerg <brunoerg!~brunoerg@2804:14d:5281:8ae2:7424:ed32:d5a9:334> has quit IRC (Ping timeout: 252 seconds)
862022-12-16T14:22:07 *** brunoerg <brunoerg!~brunoerg@187.183.43.178> has joined #bitcoin-core-dev
872022-12-16T14:24:11 <glozow> sdaftuar: ah yes, that makes sense to me
882022-12-16T14:26:12 <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:
892022-12-16T14:26:43 <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.
902022-12-16T14:27:09 <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
912022-12-16T14:27:17 <instagibbs> unless it's trimmed
922022-12-16T14:27:18 <instagibbs> yes
932022-12-16T14:27:26 <sdaftuar> if that transaction is large, it could be used as a parent of incoming transacitons which will also never be mined
942022-12-16T14:27:45 <sdaftuar> this only works when the mempool is not full -- or else as instagibbs notes it would be trimmed
952022-12-16T14:27:50 <sdaftuar> but this still seems vaguely bad?
962022-12-16T14:28:42 <glozow> I was thinking about this the other day as well. let me find my writeup...
972022-12-16T14:29:05 <glozow> https://gist.github.com/glozow/f0ddaa36290d7263a67e64bd7c0b8a92
982022-12-16T14:29:50 <instagibbs> actually it relies on the mempool being pretty much empty?
992022-12-16T14:29:58 <sdaftuar> instagibbs: yeah
1002022-12-16T14:30:02 <instagibbs> otherwise the only difference is min relay vs free
1012022-12-16T14:30:37 <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)
1022022-12-16T14:30:50 <instagibbs> Yeah I get it
1032022-12-16T14:31:16 <glozow> I suppose then, in `TrimToSize()`, we should evict low-descendant-feerate junk even when we are not at capacity
1042022-12-16T14:32:29 <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
1052022-12-16T14:34:00 <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?
1062022-12-16T14:34:07 <instagibbs> unpaid-for-things getting evicted from a wallet perspective is fine, we'll just send a package again
1072022-12-16T14:35:39 <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?
1082022-12-16T14:37:24 <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?
1092022-12-16T14:37:44 <instagibbs> one we've already validated, holding onto it isn't that expensive(?)
1102022-12-16T14:38:08 <sdaftuar> instagibbs: i think that's fair but its complicated to stop a new tx from chaining off it, at first glance
1112022-12-16T14:38:45 <instagibbs> right, single txn evaluation would have to be modified
1122022-12-16T14:39:42 <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
1132022-12-16T14:39:52 <instagibbs> mhmm yeah
1142022-12-16T14:39:57 <sdaftuar> it would be hard to tell (after the large fee paying child is replaced) whether the parent should be allowed or not
1152022-12-16T14:39:58 <instagibbs> i can see
1162022-12-16T14:40:03 <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.
1172022-12-16T14:40:38 <instagibbs> from a usability perspective I think dropping is fine, so now it would "just" be a DoS thing
1182022-12-16T14:42:04 <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
1192022-12-16T14:42:22 <sdaftuar> new tx would ahve no in-mempool parents
1202022-12-16T14:42:48 <glozow> ahhh good point yes! 100 packages is possible
1212022-12-16T14:44:26 <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?
1222022-12-16T14:44:44 <sdaftuar> though i guess it'll be the interaction of that and package validation that we need to really evaluate
1232022-12-16T14:45:44 <sdaftuar> another option is that TrimToSize() can just bail early after a certain number of evictions, and continue again later
1242022-12-16T14:45:59 <sdaftuar> it's probably not critical that we evict everything immediately (if we're not full)
1252022-12-16T14:46:22 <instagibbs> Sorry, what does doing it in stages accomplish?
1262022-12-16T14:46:25 <glozow> bail early because we don't want `TrimToSize()` to take a long time?
1272022-12-16T14:46:31 <sdaftuar> glozow: yeah
1282022-12-16T14:46:34 <instagibbs> ah :)
1292022-12-16T14:46:45 <sdaftuar> i dunno, maybe it's fast, i have no idea :)
1302022-12-16T14:47:17 <glozow> we would want to finish these evictions before we validate another transaction for acceptance, right?
1312022-12-16T14:48:31 <sdaftuar> glozow: i agree that would be simplest
1322022-12-16T14:49:48 <sdaftuar> the alternative would be to add complexity to our logic to prevent relay of a transaction that we ultimately drop
1332022-12-16T14:51:07 <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?
1342022-12-16T14:52:01 <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
1352022-12-16T14:52:12 <sdaftuar> seems messy
1362022-12-16T14:52:43 <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
1372022-12-16T14:53:32 <sdaftuar> hopefully evicting 2500 transactions is fast enough, relative to transaction validation, that we can ignore this question
1382022-12-16T14:53:51 <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
1392022-12-16T14:54:14 <sdaftuar> makes sense
1402022-12-16T14:55:47 <instagibbs> eviction benchmark needs some beefing :)
1412022-12-16T14:56:48 <glozow> yeah, can write a bench
1422022-12-16T14:57:35 <instagibbs> one exists, it's just very trivial
1432022-12-16T14:57:36 <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
1442022-12-16T15:07:52 *** jonatack2 <jonatack2!~jonatack@user/jonatack> has joined #bitcoin-core-dev
1452022-12-16T15:40:50 <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
1462022-12-16T15:41:58 <sdaftuar> it's the same scenario i wrote above: imagine zero-fee txA arrives with txB, which pays for it.
1472022-12-16T15:42:16 <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.
1482022-12-16T15:42:45 <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
1492022-12-16T15:43:17 <sdaftuar> so again we'd end up with transactions in the mempool that never get mined.
1502022-12-16T15:44:26 <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
1512022-12-16T15:44:35 <sdaftuar> that would be akin to how single-transactionv alidation works today
1522022-12-16T15:45:36 <instagibbs> basically track how sub-packages get accepted together
1532022-12-16T15:45:47 <sdaftuar> right
1542022-12-16T15:46:07 <sdaftuar> if we could implement taht, i think it would solve DoS concenrs, but raise potential incentive compatibility concerns
1552022-12-16T15:47:35 <instagibbs> things getting kicked out when they would have improved the next template?
1562022-12-16T15:47:38 <instagibbs> or something else
1572022-12-16T15:47:54 <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.
1582022-12-16T15:49:01 <sdaftuar> oh i guess the way i stated it, you'd get logical contradictions too. sigh.
1592022-12-16T15:49:07 <sdaftuar> not sure how to solve this
1602022-12-16T15:49:18 <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
1612022-12-16T15:49:20 <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
1622022-12-16T15:49:20 <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
1632022-12-16T15:49:21 <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
1642022-12-16T15:50:46 <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?
1652022-12-16T15:50:56 <sdaftuar> now imagine it has a somewhat different ancestry...
1662022-12-16T15:56:22 <glozow> yeah...
1672022-12-16T15:58:59 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 255 seconds)
1682022-12-16T16:00:24 <_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..)
1692022-12-16T16:02:34 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
1702022-12-16T16:04:19 <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
1712022-12-16T16:06:14 <glozow> _aj_: do you mean that, after the RPC finishes, all 6 transactions would be in our mempool?
1722022-12-16T16:06:54 <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
1732022-12-16T16:07:39 <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
1742022-12-16T16:08:12 <_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
1752022-12-16T16:09:21 <_aj_> glozow: X,Y,.. conflicts with A,B,C so you should never have all of them in your mempool
1762022-12-16T16:09:57 <sdaftuar> _aj_: i don't think i understand the problem you're trying to solve
1772022-12-16T16:10:06 <_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)
1782022-12-16T16:10:44 <sdaftuar> would those transactions then be relayed on the p2p network, once accepted to the mempool?
1792022-12-16T16:11:07 <_aj_> sdaftuar: not sure, i'm assuming "no"
1802022-12-16T16:11:46 <sdaftuar> ok i definitely do not understand what would be achieved then :)
1812022-12-16T16:12:03 <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.
1822022-12-16T16:12:03 <sdaftuar> a transaction relay network that is separate from the one we maintain?
1832022-12-16T16:13:20 <sdaftuar> glozow: are you suggesting that we rewrite TrimToSize() to look at ancestor packages and evict ones that are below minrelayfee?
1842022-12-16T16:13:26 <_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
1852022-12-16T16:13:40 <sdaftuar> _aj_: got it, now i understand
1862022-12-16T16:14:54 <glozow> _aj_: if it's a fee-related pin, prioritisetransaction() may help?
1872022-12-16T16:16:35 <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
1882022-12-16T16:16:41 <_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?)
1892022-12-16T16:16:45 <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.
1902022-12-16T16:17:16 <sdaftuar> glozow: ahh i see
1912022-12-16T16:17:35 <glozow> _aj_: yeah if you want it to be replaceable normally afterwards, you could just undo the prioritisetransaction after it's in.
1922022-12-16T16:17:37 <_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)
1932022-12-16T16:17:51 <sdaftuar> glozow: yeah i think that works?
1942022-12-16T16:18:33 <glozow> sdaftuar: (though I know that makes package acceptance much less cool...)
1952022-12-16T16:18:55 <sdaftuar> glozow: if we can get anything that works i think we should call it a win :)
1962022-12-16T16:19:06 <sdaftuar> all this rbf/package stuff seems too hard...
1972022-12-16T16:19:51 <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
1982022-12-16T16:19:56 <_aj_> "can't bump a 0sat/vb tx" ?
1992022-12-16T16:20:48 <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.
2002022-12-16T16:24:30 <sdaftuar> i can't recall if we require that rbf'ing a v3 transaction requires the replacement to be v3 itself?
2012022-12-16T16:24:46 <glozow> sdaftuar: it doesn't, no
2022022-12-16T16:24:59 <sdaftuar> i guess either way, you can't chain a v2 child on a v3 0fee transaction so maybe doens't matter
2032022-12-16T16:25:35 <sdaftuar> so the rule is that non-v3 transactions must always have minrelayfee on them?
2042022-12-16T16:25:48 <glozow> yep
2052022-12-16T16:26:13 <sdaftuar> i think that works... will give it more thought
2062022-12-16T16:27:53 <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.
2072022-12-16T16:28:41 <_aj_> glozow: can't you have n 0-fee txs as a package of size n+1 ?
2082022-12-16T16:29:41 <glozow> _aj_: no, because of other v3 rules. v3 can only have v3 ancestors, and only v3 descendants.
2092022-12-16T16:29:52 <glozow> and a v3 can only have 1 child
2102022-12-16T16:30:11 <glozow> and only 1 parent
2112022-12-16T16:30:11 <_aj_> glozow: right, so n 0-fee parents and 1 hihg-fee child that cpfp's all of them?
2122022-12-16T16:31:24 <glozow> _aj_: ancestor limit = 2: https://github.com/bitcoin/bitcoin/pull/25038/files#diff-526d4fd6bad9d82601d03afcb3e250f1476b0f650b96d75dd702354ec2ae8cf6R23
2132022-12-16T16:31:51 <glozow> (this is new from the last ~month)
2142022-12-16T16:33:36 <_aj_> is there doc/rationale for that? it seems pretty limiting?
2152022-12-16T16:34:15 <glozow> https://github.com/bitcoin/bitcoin/pull/25038#issuecomment-1320295394
2162022-12-16T16:37:01 <instagibbs> there's a pin behind every blade of grass
2172022-12-16T16:37:15 <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,
2182022-12-16T16:37:15 <glozow> and C is 99KvB paying 1sat/vB, adding a 1000vB child of B and C increases the cost to replace B by 101Ksat.
2192022-12-16T16:37:24 <_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
2202022-12-16T16:37:54 <glozow> instagibbs: hashtag v3 fixes this
2212022-12-16T16:38:20 <instagibbs> reasoning about this stuff is so hard :(
2222022-12-16T16:38:31 <_aj_> not being able to pay for multiple parents means v3-ephemeral isn't a replacement for sighash_group anymore
2232022-12-16T16:38:48 <_aj_> (not that sighash_group doesn't have all the same pinning issues itself)
2242022-12-16T16:38:53 <instagibbs> yeah
2252022-12-16T16:39:22 <_aj_> huh
2262022-12-16T16:40:16 <_aj_> hmm, un-"huh", that was a dumb thought bubble
2272022-12-16T16:40:57 *** ajonas_ <ajonas_!uid385278@id-385278.helmsley.irccloud.com> has joined #bitcoin-core-dev
2282022-12-16T16:42:11 <_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)
2292022-12-16T16:43:13 <instagibbs> V3 is still interesting for anything that isn't batching, imo
2302022-12-16T16:43:22 <instagibbs> batch bumps* I mean
2312022-12-16T16:43:28 <instagibbs> batched payouts, still interesting
2322022-12-16T16:49:25 <_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
2332022-12-16T16:49:38 <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
2342022-12-16T16:51:02 <_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?
2352022-12-16T16:51:10 <instagibbs> correct
2362022-12-16T16:51:45 <instagibbs> well.... maybe they gave up on using the carveout
2372022-12-16T16:51:48 <instagibbs> can't recall
2382022-12-16T16:52:36 <_aj_> the carveout's there so you can always use your anchor, even if your counterparty is trying to otherwise hit descendant limits
2392022-12-16T16:53:18 <_aj_> (iirc)
2402022-12-16T16:53:20 <instagibbs> you're assuming you see the other's commit tx in mempool, then spend the anchor
2412022-12-16T16:53:33 <instagibbs> or attacker does the other side
2422022-12-16T16:53:54 <instagibbs> if no one actually implements it, we can probably speed up removal...
2432022-12-16T16:54:02 <_aj_> yeah; i don't believe in ignoring the mempool :)
2442022-12-16T16:55:04 <instagibbs> feel free to yell at LN implementations :D
2452022-12-16T16:56:40 <glozow> yes sorry i should have said "if double anchor outputs are no longer *used*"
2462022-12-16T16:57:22 <instagibbs> I guess the risk is evil nodes run by _aj_ *would* scrape the mempool and pin honest users
2472022-12-16T16:57:37 <instagibbs> when trying to submit their own commit tx
2482022-12-16T17:03:16 <_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
2492022-12-16T17:03:16 <_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
2502022-12-16T17:13:37 *** as2333 <as2333!~as2333@host95.201-252-100.telecom.net.ar> has joined #bitcoin-core-dev
2512022-12-16T17:21:29 <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
2522022-12-16T17:23:53 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
2532022-12-16T17:25:34 *** jespada <jespada!~jespada@nmal-24-b2-v4wan-166357-cust1764.vm24.cable.virginm.net> has quit IRC (Quit: Textual IRC Client: www.textualapp.com)
2542022-12-16T17:33:13 <_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?
2552022-12-16T17:35:54 <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
2562022-12-16T17:35:56 <instagibbs> or gossiped
2572022-12-16T17:37:06 <_aj_> sure you can? if an old commitment was posted, it'll just be ignored
2582022-12-16T17:37:54 <instagibbs> We must be talking about different things
2592022-12-16T17:38:46 <_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?
2602022-12-16T17:39:34 <_aj_> (spamming the anchor tx pointlessly while waiting is fine, since you can't distinguish the latter two cases)
2612022-12-16T17:40:14 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has quit IRC (Ping timeout: 272 seconds)
2622022-12-16T17:40:21 *** b_101 <b_101!~robert@189.236.6.68> has joined #bitcoin-core-dev
2632022-12-16T17:44:46 *** b_101 <b_101!~robert@189.236.6.68> has quit IRC (Ping timeout: 252 seconds)
2642022-12-16T17:45:22 *** b_101 <b_101!~robert@173.254.196.62.adsl.inet-telecom.org> has joined #bitcoin-core-dev
2652022-12-16T17:47:26 <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
2662022-12-16T17:48:24 <instagibbs> If you mean old commit tx are too dangerous for attacker to use a a pin, sure
2672022-12-16T17:48:34 <instagibbs> they could still do it, but then their risk goes through the roof
2682022-12-16T17:48:42 <_aj_> i mean, if they successfully use it as a pin, you don't lose any money?
2692022-12-16T17:48:54 <_aj_> for ln-penalty, not eltoo of course
2702022-12-16T17:49:06 <instagibbs> if you never see it, you can't penalize it
2712022-12-16T17:49:15 <instagibbs> if it gets mined game over
2722022-12-16T17:49:18 <instagibbs> (for attacker)
2732022-12-16T17:51:08 <_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
2742022-12-16T17:51:25 *** pablomartin <pablomartin!~pablomart@194.35.233.212> has joined #bitcoin-core-dev
2752022-12-16T18:07:04 *** Hercules1 <Hercules1!~Hercules@ti0018a400-7782.bb.online.no> has joined #bitcoin-core-dev
2762022-12-16T18:28:27 <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
2772022-12-16T18:38:32 *** bomb-on <bomb-on!~bomb-on@user/bomb-on> has quit IRC (Quit: aллилѹÑа!)
2782022-12-16T18:44:35 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 255 seconds)
2792022-12-16T18:56:31 *** jonatack2 <jonatack2!~jonatack@user/jonatack> has quit IRC (Quit: WeeChat 3.7.1)
2802022-12-16T18:59:57 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
2812022-12-16T19:00:22 <achow101> #startmeeting
2822022-12-16T19:00:22 <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.
2832022-12-16T19:00:22 <core-meetingbot> Available commands: action commands idea info link nick
2842022-12-16T19:00:28 <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
2852022-12-16T19:00:28 <achow101> paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar S3RK sipa vasild
2862022-12-16T19:00:53 <kanzure> hi
2872022-12-16T19:01:03 <achow101> There are no pre-proposed wallet meeting topics. Does anyone have anything to discuss this week?
2882022-12-16T19:01:10 <darosior> Hi
2892022-12-16T19:01:21 <sipa> hi
2902022-12-16T19:01:35 <brunoerg> hi
2912022-12-16T19:02:00 <furszy> hi
2922022-12-16T19:02:02 <darosior> I guess i'm curious if people have thought about using descriptors for estimating the size of inputs
2932022-12-16T19:02:26 <darosior> Rather than doing a dry run of the signing logic every time
2942022-12-16T19:02:37 <achow101> That seems reasonable
2952022-12-16T19:02:41 <Murch1> Hi
2962022-12-16T19:02:44 <darosior> It would really simplify things moving forward with more advanced scripts
2972022-12-16T19:03:10 <achow101> would it just use the worst case size estimation?
2982022-12-16T19:03:11 <Murch1> Also the wallet should keep track of its UTXOs
2992022-12-16T19:03:13 <darosior> Context: #26567 and #24149
3002022-12-16T19:03:14 <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
3012022-12-16T19:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/24149 | Signing support for Miniscript Descriptors by darosior · Pull Request #24149 · bitcoin/bitcoin · GitHub
3022022-12-16T19:03:32 <darosior> achow101: yes but eventually we should tweak that for Taproot
3032022-12-16T19:03:58 *** kmartin <kmartin!~kmartin@20014C4E24D79A0034E61D173F32658B.dsl.pool.telekom.hu> has joined #bitcoin-core-dev
3042022-12-16T19:04:13 <sipa> One old idea was that descriptors could contain annotations about which keys/subtrees are available or not.
3052022-12-16T19:04:32 <sipa> Or might be available.
3062022-12-16T19:04:44 <sipa> The miniscript logic can do size estimation with that information, though there is no way to encode that in descriptors now.
3072022-12-16T19:04:55 <darosior> Yeah. Also rust-miniscript is experimenting with another approach: https://github.com/rust-bitcoin/rust-miniscript/pull/481
3082022-12-16T19:06:04 <darosior> I didn't look into it, but on the surface it sounds similar to having annotations within the descriptor directly.
3092022-12-16T19:08:34 <achow101> how would that information would get from the user to the size estimation?
3102022-12-16T19:08:44 <achow101> since it could change per transaction
3112022-12-16T19:09:03 <darosior> Yeah, a downside is that it would be static
3122022-12-16T19:09:21 <darosior> (A downside to hardcoding it within the descriptor)
3132022-12-16T19:10:18 <sipa> yeah it's more flexible if it can be done on a per-signature level, but that's a UX nightmare
3142022-12-16T19:10:34 <sipa> but there may be useful static information as well
3152022-12-16T19:11:18 <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.
3162022-12-16T19:11:37 <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
3172022-12-16T19:11:44 <sipa> if it's not in a hardware wallet
3182022-12-16T19:12:25 <achow101> it would definitely be useful to indicate that the keypath is never going to be used
3192022-12-16T19:12:31 <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.
3202022-12-16T19:12:46 <sipa> opr even better: the key path is always is going to be used
3212022-12-16T19:13:17 <sipa> darosior: Yeah, you could, but I think that's only part of the picture, because within one script the same thing applies
3222022-12-16T19:13:34 <sipa> And there you very much may want to know everything, even informaton about execution branches you won't use.
3232022-12-16T19:14:19 <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.
3242022-12-16T19:14:34 <darosior> sipa: wouldn't it be uncommon to have different paths within a single branch?
3252022-12-16T19:14:47 <darosior> And for pre-Taproot you don't care, since you always publish the whole script anyway
3262022-12-16T19:15:49 <sipa> But even pre-taproot your witness estimation may very much depend on which keys are available.
3272022-12-16T19:20:06 <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
3282022-12-16T19:21:12 <sipa> I think post-partial-descriptors we can actually move the signing logic into descriptors, rather than the other way around.
3292022-12-16T19:21:17 <sipa> And anything that interacts with signing like size estimation too.
3302022-12-16T19:21:32 <darosior> Yes i was thinking of going in this direction too.
3312022-12-16T19:22:41 <achow101> that could be useful
3322022-12-16T19:24:38 <achow101> anything else to discuss?
3332022-12-16T19:24:39 <darosior> I need to leave unfortunately. Thank you all for the discussion, happy to see there is interest in this.
3342022-12-16T19:25:20 <sipa> Murch had a topic I think
3352022-12-16T19:25:52 <furszy> i have a one too.
3362022-12-16T19:26:20 <achow101> Murch1: what was your topic?
3372022-12-16T19:27:04 <Murch1> Ah
3382022-12-16T19:27:32 <Murch1> No, just a ceterum censeo
3392022-12-16T19:27:42 <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
3402022-12-16T19:27:53 <achow101> furszy: go ahead
3412022-12-16T19:29:00 <furszy> Murch1: agree, I actually have a card in my board to move into that direction too.
3422022-12-16T19:29:01 <furszy> so
3432022-12-16T19:29:19 <furszy> my topic arose here
3442022-12-16T19:29:21 <furszy> https://github.com/bitcoin/bitcoin/pull/26661#issuecomment-1353087751
3452022-12-16T19:29:31 <furszy> it's the "Second point" there
3462022-12-16T19:29:44 <furszy> and S3RK answer to it.
3472022-12-16T19:30:23 <furszy> if we agree, could "standardize" it and create a guideline for it.
3482022-12-16T19:31:30 <achow101> I've actually tended to avoid using exceptions since we don't have general exception handling
3492022-12-16T19:31:45 <achow101> I've only really used them in places where there was no other way to return an error
3502022-12-16T19:32:26 <achow101> IIRC an exception will kill the gui
3512022-12-16T19:32:46 <Murch1> furszy: Awesome!
3522022-12-16T19:33:15 <achow101> but having some guidelines would probably be useful
3532022-12-16T19:33:49 <Murch1> Err, just to be clear, that was directed at furszy's UTXO pool plans
3542022-12-16T19:33:56 <furszy> yeah, I know achow101. I ended up adding a try catch to the GUI create tx flow because of it.
3552022-12-16T19:34:41 <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
3562022-12-16T19:34:52 <furszy> *can't
3572022-12-16T19:35:34 <furszy> which isn't something related to the wallet's module. It's a GUI issue.
3582022-12-16T19:36:13 <achow101> sure, but we need to consider the effects of throwing exceptions on the rest of the software
3592022-12-16T19:36:45 <achow101> it would be worthwhile to write up some guidelines and fix qt simultaneously
3602022-12-16T19:37:02 <achow101> given that we already do throw exceptions in some places that can already be problematic for the gui
3612022-12-16T19:38:24 <furszy> by fixing at you mean the place that require to catch the exception?
3622022-12-16T19:38:49 <furszy> or by trying to find a way to catch them all at once
3632022-12-16T19:39:02 <achow101> trying to catch them all generically
3642022-12-16T19:39:05 <achow101> like we do for the rpc
3652022-12-16T19:40:41 <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..)
3662022-12-16T19:41:44 <furszy> thus why ended up coding https://github.com/bitcoin-core/gui/pull/666
3672022-12-16T19:43:50 <achow101> hmm, that's something to look into again
3682022-12-16T19:44:07 <achow101> just generally though, we should try to avoid things that will cause crashes
3692022-12-16T19:44:33 <furszy> well. another possibility is to move all the gui backend calls to be done on a generic worker that catches all the exceptions.
3702022-12-16T19:45:20 <furszy> that could also helps in terms of the gui freezing time
3712022-12-16T19:46:01 <furszy> sort of "dispatcher"
3722022-12-16T19:46:03 <achow101> yeah, there's definitely improvements that could be made there
3732022-12-16T19:46:28 <furszy> yep. Will see if can cook something up for it.
3742022-12-16T19:46:38 <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
3752022-12-16T19:46:55 <achow101> and what we could do to make those parts handle them better
3762022-12-16T19:47:19 <achow101> any other topics to discuss?
3772022-12-16T19:50:29 <achow101> #endmeeting
3782022-12-16T19:50:29 <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
3792022-12-16T19:50:29 <core-meetingbot> Meeting ended Fri Dec 16 19:50:29 2022 UTC.
3802022-12-16T19:50:29 <core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2022/bitcoin-core-dev.2022-12-16-19.00.moin.txt
3812022-12-16T19:55:06 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6180:500:31a5:ed4d:13:2df6> has joined #bitcoin-core-dev
3822022-12-16T19:56:32 *** jonatack <jonatack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
3832022-12-16T19:58:30 *** Hercules1 <Hercules1!~Hercules@ti0018a400-7782.bb.online.no> has quit IRC (Quit: Leaving)
3842022-12-16T20:05:48 *** kmartin <kmartin!~kmartin@20014C4E24D79A0034E61D173F32658B.dsl.pool.telekom.hu> has quit IRC (Quit: Client closed)
3852022-12-16T20:08:17 *** vasild <vasild!~vd@user/vasild> has quit IRC (Ping timeout: 255 seconds)
3862022-12-16T20:18:31 *** brunoerg <brunoerg!~brunoerg@187.183.43.178> has quit IRC ()
3872022-12-16T20:19:47 *** ajonas_ <ajonas_!uid385278@id-385278.helmsley.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
3882022-12-16T20:22:28 *** vasild <vasild!~vd@user/vasild> has joined #bitcoin-core-dev
3892022-12-16T20:31:36 *** MrFrancis <MrFrancis!~MrFrancis@2001:8a0:fa4c:901:e521:9ffd:bd17:3cda> has joined #bitcoin-core-dev
3902022-12-16T20:42:25 *** MrFrancis <MrFrancis!~MrFrancis@2001:8a0:fa4c:901:e521:9ffd:bd17:3cda> has quit IRC (Ping timeout: 252 seconds)
3912022-12-16T20:54:22 *** bomb-on <bomb-on!~bomb-on@user/bomb-on> has joined #bitcoin-core-dev
3922022-12-16T21:31:59 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 255 seconds)
3932022-12-16T21:53:37 *** yanmaani1 <yanmaani1!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
3942022-12-16T22:15:28 *** MrFrancis <MrFrancis!~MrFrancis@2001:8a0:fa4c:901:e036:4c22:796e:e07c> has joined #bitcoin-core-dev
3952022-12-16T22:26:09 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
3962022-12-16T22:27:34 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Remote host closed the connection)
3972022-12-16T22:31:10 <bitcoin-git> [bitcoin] achow101 pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/7386da7a0b08...66c08e741dc8
3982022-12-16T22:31:11 <bitcoin-git> bitcoin/master e6906fc Aurèle Oulès: rpc: Enable wallet import on pruned nodes
3992022-12-16T22:31:11 <bitcoin-git> bitcoin/master 71d9a7c Aurèle Oulès: test: Wallet imports on pruned nodes
4002022-12-16T22:31:11 <bitcoin-git> bitcoin/master 564b580 Aurèle Oulès: test: Introduce MIN_BLOCKS_TO_KEEP constant
4012022-12-16T22:31:24 <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
4022022-12-16T22:50:37 *** jon_atack <jon_atack!~jonatack@user/jonatack> has joined #bitcoin-core-dev
4032022-12-16T22:52:19 *** jonatack <jonatack!~jonatack@user/jonatack> has quit IRC (Ping timeout: 260 seconds)
4042022-12-16T22:59:22 *** MrFrancis <MrFrancis!~MrFrancis@2001:8a0:fa4c:901:e036:4c22:796e:e07c> has quit IRC (Ping timeout: 252 seconds)
4052022-12-16T23:14:54 *** pablomartin <pablomartin!~pablomart@194.35.233.212> has quit IRC (Ping timeout: 252 seconds)
4062022-12-16T23:33:29 *** andrewtoth_ <andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has quit IRC (Ping timeout: 255 seconds)
4072022-12-16T23:33:31 *** _andrewtoth_ <_andrewtoth_!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
4082022-12-16T23:45:24 *** AaronvanW <AaronvanW!~AaronvanW@user/AaronvanW> has quit IRC (Quit: Leaving...)