Review Club: add missing segwitv1 test cases to script_standard_tests and exploring v3 transaction relay

[zaidmstrr]

Session Details

Date: 16-01-2025
Time: IST 20:00 (UTC 14:30)
Link: PR #31340
Difficulty: Hard

Motivation

Currently, Bitcoin supports two SegWit version 1 (segwitv1) output script types that are recognized as standard:

1. TxoutType::WITNESS_V1_TAPROOT (P2TR): Introduced with the Taproot soft-fork, this script type uses a witness program of size 32.
2. TxoutType::ANCHOR (P2A): Introduced through policy (#30352), this script type defines a witness program {0x4e, 0x7e} and establishes the PayToAnchor (P2A) standard for specific spending scenarios

Despite their standardization, there are gaps in the script standardness unit tests, particularly for their use with key functions like ExtractDestination and GetScriptForDestination. This PR addresses these gaps by adding the missing unit tests, ensuring better coverage and alignment with Bitcoin's script standardness framework.

Notes

• A package is an ordered list of transactions, representable by a connected Directed Acyclic Graph (a directed edge exists between a transaction that spends the output of another transaction).

• Ephemeral anchors are a special type of output that are watermarked (by policy only) via a short static output script. Ephemeral Anchors enable a new pattern for adding fees to presigned transactions, with a few key improvements:

  1. The anchor output can have any nValue, including amounts below the dust threshold such as 0, as long as it is spent immediately, i.e. relayed in a package with a fee-bumping child. Implementing this policy requires ensuring that the anchor is always spent after subsequent mempool updates, so it is only implemented for TRUC transactions which are restricted to a very simple topology. This portion of the proposal was split into its own “ephemeral dust” PR, #30239.

  2. The anchor output is “keyless” or “anyone-can-spend”, reducing the amount of data (and thus fees) needed in the CPFP transaction, and making it easier for watchtowers to help broadcast presigned transactions. This part of the proposal, #30352, is independent of the “ephemeral dust” concept, and the implementation is simple regardless of transaction topology.

• Package RBF describes a policy enabling a child to pay for replacing transactions its parent conflicts with when they are submitted as a package. (Package CPFP is a prerequisite for this). The main use case of Package RBF is to allow LN commitment transactions (which conflict with each other but whose fees cannot be changed) to replace each other in mempools using fees added at broadcast time using children attached to anchor outputs.

• A Pinning Attack is a type of transaction relay censorship in which the attacker takes advantage of mempool policy to prevent a transaction from being mined or entering a mempool. An introduction to mempool policy and pinning attacks is transcribed here.

• A “v3 transaction” refers to a transaction that has its nVersion field set to 3. These types of transactions are currently standard in Bitcoin Core.

Refer
TRUC Transactions
Ephemeral Dust
Ephemeral Anchors
Transaction Pinning
Version 3 transaction relay

Questions

• What is PayToAnchor(P2A) and in which transaction version does it build upon? 
• Tell any two v3 policies that facilitate package RBF?
• Tell the difference between anchor outputs and ephemeral anchors?
• Why does the usage of ephemeral anchors rely on package relay?
• Before TxoutType::ANCHOR is defined in this PR, what TxoutType would a scriptPubKey OP_1 <0x4e73> be classified as? (Hint: what would Solver return?) 
• By default, a transaction must pass standardness checks to be accepted to the mempool. What does IsStandardTx() inspect?

Learnings

P2P
V3 transaction relay
RBF/CPFP
TRUC transactions