Topology Restrictions for Pinning

  BIP: 431
  Layer: Applications
  Title: Topology Restrictions for Pinning
  Authors: Gloria Zhao 
  Status: Draft
  Type: Informational
  Assigned: 2024-01-10
  License: BSD-3-Clause
  Discussion: 2022-01-27: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019817.html [bitcoin-dev] discussion
              2022-01-27: https://gist.github.com/glozow/25d9662c52453bd08b4b4b1d3783b9ff gist discussion
              2022-09-23: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-September/020937.html [bitcoin-dev] proposal
              2024-01-02: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340 Delving Bitcoin post
              2024-01-16: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418 Delving Bitcoin post

Abstract

This document describes pinning problems that can arise from limitations in mempool policy.

It also describes a type of policy with adjusted topology limits which, combined with other policy rules, helps minimize the potential pinning problems. These restrictions simplify the assessment of incentive compatibility of accepting or replacing such transactions, thus helping ensure any replacements are more profitable for the node. Within the context of nodes that implement this policy, fee-bumping is more reliable for users.

Motivation

Mempools typically accept and relay transactions that spend outputs from other unconfirmed transactions, but restrict package sizes through ancestor and descendant limits

to limit the computational complexity of mempool operations and mitigate Denial of Service attacks.

Users may also create unconfirmed transactions that conflict with -- or are "double spends" of -- each other by spending the same input(s) in both. Instead of always keeping the first-seen transaction, many mempools also have some kind of Replace by Fee (RBF) policy

to keep the more incentive compatible transaction, i.e. one that would earn a miner more fees. Users utilize these rules when they create higher feerate double-spends (replacements) to expedite confirmation of their transactions.

However, these policies make imperfect trade-offs between incentive compatibility and DoS-resistance. For example, malicious actors may sometimes exploit limitations to prevent incentive-compatible transactions from being accepted or fee-bumped (pinning).

Pinning is consequential to contracting protocols in which untrusted parties construct and sign time-sensitive transactions to be broadcast on-chain later . When the funds available to be redeemed by each party depend on a transaction confirming within a specific time window, a malicious party may be able to steal money if the honest party cannot get their transaction confirmed. As such, the ability to fee-bump a transaction to entice miners to include it in their blocks is crucial to the security of the protocol.

RBF pinning through absolute fees

Imagine that counterparties Alice and Mallory have transactions (or packages) A and B, respectively, which conflict with each other. Alice broadcasts A and Mallory broadcasts B. RBF rules require the replacement transaction pay a higher absolute fee than the aggregate fees paid by all original transactions ("Rule 3"). This means Mallory may increase the fees required to replace B beyond what Alice was planning to pay for A's fees.

1. Adding transaction(s) that descend from B and pay a low feerate (too low to fee-bump B through CPFP).

2. Adding a high-fee descendant of B that also spends from another large, low-feerate mempool transaction (where the fee of the descendant is too low to fee-bump both B and its other parent through CPFP).

RBF pinning through number of conflicts

RBF rules require that no replacement trigger the removal of more than 100 transactions ("Rule 5"). This number includes the descendants of the conflicted mempool transactions. Mallory can make it more difficult to replace transactions by attaching lots of descendants to them. For example, if Alice wants to batch-replace 5 transactions but each has 21 descendants, her replacement will be rejected regardless of its fees.

RBF incentive compatibility requirements

There is currently no effective rule to enforce that a replacement transaction would be more incentive compatible to keep in the mempool. It is difficult to quantify the incentive compatibility of a set of transactions, especially in comparison with another set of transactions, but the requirement of a feerate increase ("Rule 6") is far too simplistic.

For example, a user could create a replacement transaction that pays more fees and is higher feerate, but has a low feerate ancestor and would confirm slower than the original transaction. As a result, all transactions signed with SIGHASH_ANYONECANPAY are vulnerable to being replaced by a transaction that will confirm later than the original.

Child fees don't count towards RBF rules

A transaction must meet all fee-related requirements (Rules 3, 4, 6) alone; its child's fees cannot be used. A Package RBF policy would allow a transaction's child to be used for its RBF requirements.

In LN Penalty, conflicting commitment transactions signed with the same fees cannot replace each other, even if accompanied by a fee-bumping child. This limitation necessitates the presence of two anchor outputs, allowing both parties to fee-bump either commitment transaction that enters their mempool.

Package limit pinning and replacing CPFP Carve Out

Mempool policies limit the number and total virtual size of an unconfirmed transaction's descendants. A fee-bumping child of an unconfirmed transaction (CPFP) may be rejected for exceeding the descendant limit. When a transaction has multiple outputs owned by different parties, a malicious party can prevent the other(s) from CPFPing their transaction by attaching enough descendants to monopolize the descendant limit (package limit pinning).

LN commitment transactions rely on CPFP carve out to avoid package limit pinning.

There are weaknesses with this approach of using 2 anchors and CPFP Carve Out. This proposal helps address a few of them (see Related Work for how other weaknesses are addressed):

• Cluster Mempool necessitates the removal of CPFP Carve Out .
• CPFP Carve Out only allows one more child to be added to the transaction. This means it cannot guarantee the ability to CPFP for more than 2 parties of a shared transaction.

Topologically Restricted Until Confirmation

This section describes one approach for opt-in policy rules that can realistically be deployed today and is useful to today's applications. It is based on the idea that most limitations stem from existing ancestor/descendant package limits being too permissive for the majority of use cases.

The scope of the policy's anti-pinning benefits is limited to the individual node's mempool, and the degree to which a user's transaction is safe from pinning depends how much of the network has adopted this policy.

Similarly, there are multiple approaches to creating a policy to minimize pinning, more may become available over time (see Related Work section), and the details of this approach can be tweaked if conditions change. For example, if loosening one of the topology restrictions enables a new use case while still providing acceptable pinning bounds, it can be changed.

Specification

Senders can signal that they want a transaction to be Topologically Restricted Until Confirmation (TRUC). Specifically, set nVersion=3. A node that implements this policy would apply their existing standardness and policy rules, along with the following set of rules, to TRUC transactions:

1. A TRUC transaction signals replaceability, even if it does not signal BIP125 replaceability.

2. Any TRUC transaction's unconfirmed ancestors must all be TRUC. Any descendant of an unconfirmed TRUC transaction must also be TRUC.

Note: A TRUC transaction can spend outputs from confirmed non-TRUC transactions. A non-TRUC transaction can spend outputs from confirmed TRUC transactions.

3. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed ancestor. An unconfirmed TRUC transaction cannot have more than 1 unconfirmed descendant. CPFP Carve Out is not granted to TRUC transactions.

4. A TRUC transaction cannot have a sigop-adjusted virtual size larger than 10,000 vB.

5. A TRUC transaction that has an unconfirmed TRUC ancestor cannot have a sigop-adjusted virtual size larger than 1000 vB.

6. An individual TRUC transaction is permitted to be below the mempool min relay feerate, assuming it is considered within a package that meets the mempool's feerate requirements. Rationale: This allows contracting protocols to create presigned transactions with 0 fees and f