The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #bitcoin-core/gui/650 (Add Import to Wallet GUI by KolbyML)
• #28246 (wallet: Use CTxDestination in CRecipient instead of just scriptPubKey by achow101)
• #28244 (Break up script/standard.{h/cpp} by achow101)
• #28217 (set DEFAULT_PERMIT_BAREMULTISIG to false by Retropex)
• #28201 (Silent Payments: sending by josibake)
• #28126 (wallet legacy: bugfix, disallow importing invalid scripts via importaddress by furszy)
• #28122 (Silent Payments: Implement BIP352 by josibake)
• #28031 (Package Relay 1/3: Introduce TxPackageTracker as Orphan Resolution Module by glozow)
• #27827 (Silent Payments: send and receive by josibake)
• #27432 (contrib: add tool to convert compact-serialized UTXO set to SQLite database by theStack)
• #26840 (refactor: importpubkey, importprivkey, importaddress, importmulti, and importdescriptors rpc by KolbyML)
• #26711 (validate package transactions with their in-package ancestor sets by glozow)
• #26451 (Enforce incentive compatibility for all RBF replacements by sdaftuar)
• #20892 (tests: Run both descriptor and legacy tests within a single test invocation by achow101)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

🐙 This pull request conflicts with the target branch and needs rebase.

What's the point of having a non-malleable version? Okay, so a miner cannot add extra pushes to the input script that spends the anchor, but there is nothing to stop the miner from mining an alternative child transaction that spends only the anchor. Thus, the party that had broadcast the original child transaction will be forced to construct a new spending transaction with a different TxID anyway. Indeed, anyone (not only a miner) is free to propose a replacement child that spends only the anchor, so it will never be okay to depend upon the TxID of a transaction that spends an ephemeral anchor. So again I ask, what is the point of having a non-malleable ephemeral anchor?

Thus, the party that had broadcast the original child transaction will be forced to construct a new spending transaction with a different TxID anyway

Canonical example here which motivated the change was that of LN channel splicing being used to cpfp bump another transaction, would could be another channel's commitment transaction itself. This requires the ephemeral anchor-spending tx(the splice) to retain txid stability otherwise funds are locked up in the new funding output.

I understand that not all use-cases require such things, but two points:

1. It's easy to expand standardness, and really hard to restrict. In deploying one version, we'll likely learn lessons we'd want to apply to other versions. If we see tons of uptake from wallets that explicitly don't care about txid stability? That's a signal as well.
2. "I don't see the problem" is much weaker than "there is no problem" and I'd rather be able to reason via modern bitcoin rules

This requires the ephemeral anchor-spending tx(the splice) to retain txid stability otherwise funds are locked up in the new funding output.

The point I was missing is that a non-malleable anchor ensures that the other output(s) do not get spent in a transaction whose TxID was not known in advance of signing. Thank you for the answer.