Re: [bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols
Hello Gloria, Great work on synthesizing so much feedback into a proposal like this! Death to carve-out rule. I'd like to elaborate on some caveats and give a few incomplete thoughts. There are basically two types of pinning in my estimation today: 1) rule#3 pinning: Make it uneconomical to replace whatever is in mempool via large in size but low feerate junk that won't get mined anytime soon. Replacing this with feerate-based policy seems apt, but fraught with DoS risks. 2) package limit pinning: disallowing transaction propagation by package limits being hit: size, ancestor count, descendant count. Today it is mitigated by having all outputs be 1 csv timelocked, and having up to 2 anchor outputs(1 without carve-out rule). Would kind of be nice if package RBF would detect a "sibling output spend" conflict, and knock it out of the mempool via the other replacement rules? Getting rid of the requirement to 1 block csv lock every output would be quite nice from a smart contracting composability point of view. > "Does this fix Rule 3 Pinning?" As you likely know from previous discussions the biggest scenario this does not fix in my estimation is ANYONECANPAY situations. If the parent transaction can be "inflated" by tacking on additional inputs, this means the total weight of the parent tx lowers the effective feerate of the package. Due to this pinning attack there aren't many(?) deployed schemes that use the signature type. To mitigate this we would likely have to opt into a more complex policy scheme, committing in the annex to "total mempool package weight", which would allow mempool package limits to be picked at signing time. Maybe ANYONECANPAY isn't a very useful paradigm in general, I cannot speak to that, but it came up in eltoo-related designs using BIP118, which adopts ACP-like signing behavior. This can be mitigated via straight forward policy updates as well for BIP118 deployment, but off topic so will leave it there. The other scenario it doesn't really fix is where HTLC/commitment-like transactions are being resolved in a batch, but due to relative time constraints, you may want to accelerate some and not others. Now you must pay higher rates to replace all of the transaction bumps. This is a "self-pin" and "get good at utxos noob" type problem, but it's something that axing rule#3 in favor of a Replace-by-ancestor-feerate system would get us. > "Can a V2 transaction replace a V3 transaction and vice versa?" Circling back to my ACP point, this regime still allows pinning anytime you are sharing a transaction with someone else where you don't have control over *all* the inputs. So anytime you are doing a coinjoin-like transaction, someone else's inputs can be self-double-spent, requiring you to satisfy rule#3 when replacing theirs, if they're bip125-signaling. If they're not bip125 signaling, you'll have to somehow detect this and/or double-spend your input back to yourself. Finally, a couple suggestions I've already made elsewhere: 1) I do think that we should seriously consider allowing OP_TRUE to become a standard script type as part of this policy update. If pinning is solved, then there's no reason to require all those extra bytes for "binding" an anchor to a specific wallet/user. We can save quite a few bytes by having the input be empty of witness data. 2) If we allow for a single dust-value(0 on up) output which is immediately spent by the package, anchors become even easier to to design. No value has to be "sapped" from contract participants to make an anchor output. There's more complications for this, such as making sure the parent transaction is dropped if the child spend is dropped, but maybe it's worth the squeeze. I do think that any L2 uptake of these new rules will take significant time... maybe we should be a bit more ambitious? Cheers, Greg On Fri, Sep 23, 2022 at 11:27 AM Gloria Zhao via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi everyone, > > I'm writing to propose a very simple set of mempool/transaction relay > policies intended to aid L2/contract protocols. I realized that > the previously proposed Package Mempool Accept package RBF [1] > had a few remaining problems after digging into the RBF logic more [2]. > This additional set of policies solves them without requiring a huge RBF > overhaul. > > I've written an implementation (and docs) for Bitcoin Core: > https://github.com/bitcoin/bitcoin/pull/25038 > > (You may notice that this proposal incorporates feedback on the PR - > thanks Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony Towns, > and others.) > > If you are interested in using package RBF/relay to bump presigned > transactions, I think you may be interested in reviewing this proposal. > This should solve Rule 3 pinning and perhaps allow us > to get rid of CPFP carve-out (yay!). I'm keen to hear if people find > the 1-anchor-output, 1000vB child limit too restrictive. Also, if you find > a > pinning attack
[bitcoin-dev] New transaction policies (nVersion=3) for contracting protocols
Hi everyone,
I'm writing to propose a very simple set of mempool/transaction relay
policies intended to aid L2/contract protocols. I realized that
the previously proposed Package Mempool Accept package RBF [1]
had a few remaining problems after digging into the RBF logic more [2].
This additional set of policies solves them without requiring a huge RBF
overhaul.
I've written an implementation (and docs) for Bitcoin Core:
https://github.com/bitcoin/bitcoin/pull/25038
(You may notice that this proposal incorporates feedback on the PR - thanks
Suhas Daftuar, Gregory Sanders, Bastien Teinturier, Anthony Towns, and
others.)
If you are interested in using package RBF/relay to bump presigned
transactions, I think you may be interested in reviewing this proposal.
This should solve Rule 3 pinning and perhaps allow us
to get rid of CPFP carve-out (yay!). I'm keen to hear if people find
the 1-anchor-output, 1000vB child limit too restrictive. Also, if you find a
pinning attack or something that makes it unusable for you, I would
really really like to know.
Note that transactions with nVersion=3 ("V3 transactions") are
currently non-standard in Bitcoin Core. That means **anything that was
standard before this policy change would still be standard
afterwards.** If you don't want your transactions to be subject to
these rules, just continue whatever you're doing and don't use
nVersion=3. AFAICT this shouldn't break anything, but let me know if
this would be disruptive for you?
**New Policies:**
This includes:
- a set of additional policy rules applying to V3 transactions
- modifications to package RBF rules
**V3 transactions:**
Existing standardness rules apply to V3 (e.g. min/max tx weight,
standard output types, cleanstack, etc.). The following additional
rules apply to V3:
1. A V3 transaction can be replaced, even if it does not signal BIP125
replaceability. (It must also meet the other RBF rules around fees,
etc. for replacement to happen).
2. Any descendant of an unconfirmed V3 transaction must also be V3.
*Rationale*: Combined with Rule 1, this gives us the property of
"inherited" replaceability signaling when descendants of unconfirmed
transactions are created. Additionally, checking whether a transaction
signals replaceability this way does not require mempool traversal,
and does not change based on what transactions are mined. It also
makes subsequent rules about descendant limits much easier to check.
*Note*: The descendant of a *confirmed* V3 transaction does not need to be
V3.
3. An unconfirmed V3 transaction cannot have more than 1 descendant.
*Rationale*: (Upper bound) the larger the descendant limit, the more
transactions may need to be replaced. This is a problematic pinning
attack, i.e., a malicious counterparty prevents the transaction from
being replaced by adding many descendant transactions that aren't
fee-bumping.
(Lower bound) at least 1 descendant is required to allow CPFP of the
presigned transaction. The contract protocol can create presigned
transactions paying 0 fees and 1 output for attaching a CPFP at
broadcast time ("anchor output"). Without package RBF, multiple anchor
outputs would be required to allow each counterparty to fee-bump any
presigned transaction. With package RBF, since the presigned
transactions can replace each other, 1 anchor output is sufficient.
4. A V3 transaction that has an unconfirmed V3 ancestor cannot be
larger than 1000 virtual bytes.
*Rationale*: (Upper bound) the larger the descendant size limit, the
more vbytes may need to be replaced. With default limits, if the child
is e.g. 100,000vB, that might be an additional 100,000sats (at
1sat/vbyte) or more, depending on the feerate.
(Lower bound) the smaller this limit, the fewer UTXOs a child may use
to fund this fee-bump. For example, only allowing the V3 child to have
2 inputs would require L2 protocols to manage a wallet with high-value
UTXOs and make batched fee-bumping impossible. However, as the
fee-bumping child only needs to fund fees (as opposed to payments),
just a few UTXOs should suffice.
With a limit of 1000 virtual bytes, depending on the output types, the
child can have 6-15 UTXOs, which should be enough to fund a fee-bump
without requiring a carefully-managed UTXO pool. With 1000 virtual
bytes as the descendant limit, the cost to replace a V3 transaction
has much lower variance.
*Rationale*: This makes the rule very easily "tacked on" to existing
logic for policy and wallets. A transaction may be up to 100KvB on its
own (`MAX_STANDARD_TX_WEIGHT`) and 101KvB with descendants
(`DEFAULT_DESCENDANT_SIZE_LIMIT_KVB`). If an existing V3 transaction
in the mempool is 100KvB, its descendant can only be 1000vB, even if
the policy is 10KvB.
**Package RBF modifications:**
1. The rule around unconfirmed inputs was
originally "A package may include new unconfirmed inputs, but the
ancestor feerate of the child must be at least as high as the ancestor
feerates of every transaction being
