If we were running a business that accepted unconfirmed transactions as payments, what changes should we make so that our wallet correctly tracks v3 transactions?
Who might be interested in using v3 transactions? Who probably wouldn’t be interested?
If there are some wallets/users/applications that use v3 while others don’t, is there a privacy issue (i.e. people
can fingerprint which wallet likely created a transaction by looking at its version)?
After the addition of v3, all non-v3 transactions are still subject to the existing limitations and pinning attacks.
Wouldn’t it be safer to enforce these rules for all transactions on the network?
V3 limits each transaction to 1 parent or 1 child (2 generations only), and perhaps that seems
restrictive. Let’s consider an alternative set of rules that allows each transaction to have 2
parents or 2 children (a transaction may have up to 2 children or up to 2 parents. They cannot have
both an unconfirmed parent and an unconfirmed child, so 2 generations only) - what would be the
maximum cluster size?
Why not limit the size of all v3 transactions to 1,000vB or something similarly small (Hint: what property of LN
channels depends on standard transaction
weight)?
Implementation
Why does ApplyV3Rulescheck whether the transaction conflicts with any of its ancestors’ children? What happens if you remove this check?
V3 ancestor/descendant limits are stricter than the default mempool limits. Do we need to call both
ApplyV3Rules
(which enforces v3 ancestor/descendant limits) andCalculateMemPoolAncestors()
(which enforces ancestor/descendant limits)? Why or why not?
V3 rules are added to the filtering function passed to removeForReorg() in Chainstate::MaybeUpdateMempoolForReorg.
Why do we need to check v3 rules in a reorg?
Is CTxMemPool::removeForReorg() the appropriate place for this check? Can you think of an alternative place to add this check?
How does
CheckMinerScores determine whether one transaction or package is more incentive compatible to mine than another? Is this function 100% accurate for v3 transactions? What about for non-v3 transactions?
V3 restrictions suck! Why can’t we just replace RBF Rules 3 and 4 with a better rule based on feerate? For example, “replacement tx must have a feerate 2x higher than each of the transactions it’s replacing.”
Why not allow packages with multiple parents and 1 child in v3?
Theoretically, if the mempool is not full, the maximum number of transactions that may be removed in a replacement is 100 (due to Rule 5). After this commit, what is the new limit?
<LarryRuane> there are many commits, because there is some RBF stuff in the PR too, so first step for me is try to identify which commits are relevant for this review club
<glozow> first question for today: If we were running a business that accepted unconfirmed transactions as payments, what changes should we make so that our wallet correctly tracks v3 transactions?
<abubakar_> Update our wallet bitcoin core node to the version that has v3 commits, and our mempool will start tracking v3 transaction which we can add to our wallet.
<michaelfolkson> Accepting unconfirmed isn't recommended (I guess it is worth stating the obvious) and especially if they are signaling RBF or are v3 that are also signaling RBF inherently
<glozow> LarryRuane: instagibbs: abubakar_: michaelfolkson: Murch: all good answers yep. upgrading so you understand v3 policy. understanding that v3 signals replaceability is pretty important
<Murch> Since they’re explicitly designed to limit the pinning attack surface, they would mostly be used by multiparty transactions, e.g. lightning channel commitment transactions.
<glozow> yep, no batched CPFP. so if you sent a bunch of transactions and want to batch them together, you can't do a cpfp. but hopefully if you made them all v3, you can just batch them together in an rbf
<glozow> If there are some wallets/users/applications that use v3 while others don’t, is there a privacy issue (i.e. people can fingerprint which wallet likely created a transaction by looking at its version)? (There is no "correct" answer to this question)
<abubakar_> I think you can just tell this transaction is from a wallet/user that uses v3 transactions, but you can not say which user or wallet application.
<glozow> pakaro: yeah I think some cases are worse than others. We don't really need to worry about "unilateral LN channel closes are identifiable" because they already are
<michaelfolkson> abubakar_: This depends on how many wallet applications support it. If only one does you can tell. If lots do you can't. The bigger the crowd (of wallets) the harder it is to know which wallet
<glozow> yeah i mean the argument "when very few wallets use it, it's easy to tell which wallet created a tx" is pretty weak, because then we should never update anything
<glozow> I'm going to move on to implementation questions since we're halfway. Why does `ApplyV3Rules` check whether the transaction conflicts with any of its ancestors’ children?
<theStack> ad Q1: this seems to be for the case that there is already a child of the parent in the mempool. we allow that if the child is replaced, IIUC
<glozow> next question. V3 ancestor/descendant limits are stricter than the default mempool limits. Do we need to call both ApplyV3Rules (which enforces v3 ancestor/descendant limits) and CalculateMemPoolAncestors() (which enforces ancestor/descendant limits)? Why or why not?
<glozow> V3 rules are added to the filtering function passed to removeForReorg() in Chainstate::MaybeUpdateMempoolForReorg. Why do we need to check v3 rules in a reorg?
<theStack> v3 rules are not consensus rules, i.e. after disconnecting a block we can't just unconditonally put txs in the mempool (v2 could spend v3 and vice-versa)
<glozow> e.g. if you had a mempool tx that spends from 50 transactions in a block, and then that block gets disconnected, you don't get to keep all of them.
<glozow> moving on to next question but if anybody comes up with a better way to check v3 rules in a reorg, please let me know because I personally find it a tad ugly
<instagibbs> glozow was thinking I'd like to do an ephemeral anchors sequel to v3 discussions if people are interested? mental delta should be quite small