Lightning Network (LN) commitment transactions may use anchor outputs to allow channel
participants to fee-bump the presigned transactions through Child Pays For Parent (CPFP) at broadcast time. The current design (see BOLT
3)
has a few limitations described in this blog post.
The most relevant point here is the fact that the anchors currently specify a p2wsh script including two spending
paths: using the party’s funding key, or anyone 16 blocks after the transaction confirms. Spending this anchor
output requires paying fees for a relatively large amount of data. We call these anchors keyed because of the
presence of a key in the locking script.
Assuming there are no reasons to use keyed anchor outputs (there are, but that is out of scope for this review club), a keyless
anchor may reduce complexity (including for a watchtower) and make fee-bumping more space and fee-efficient.
Ephemeral Anchors enable a new pattern for adding fees to
presigned transactions, with a few key improvements:
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.
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.
While scriptPubKeys can be fairly freeform, Bitcoin Core enumerates several TxoutTypes. These correspond to output
types that you may be familiar with like SCRIPTHASH (P2SH), WITNESS_V0_KEYHASH (P2WPKH), WITNESS_V0_SCRIPTHASH
(P2WSH), and NULL_DATA (OP_RETURN or datacarrier).
Solver pattern-matches scriptPubKeys to classify their output type; anything that does not fall into the known categories is TxoutType::NONSTANDARD.
By default, a transaction must pass standardness checks to be accepted to mempool. IsStandardTx()
inspects the TxoutTypes of each of the transaction’s inputs and outputs, among other checks.
Notice the difference in rules applied to inputs and outputs. A particular output type may be
nonstandard to create but standard to spend, and vice versa.
This PR does two things: it defines OP_1 <0x4e74> as a new output type, and relaxes policy rules to make it standard
to spend this output type, as long as the witness is empty.
Before TxoutType::ANCHOR is defined in this PR, what TxoutType would a scriptPubKeyOP_1 <0x4e73> be classified as? (Hint:
what would Solver return?)
Based on the answer to the previous question, would it be standard to create this output type? What about to spend it?
(Hint: how do IsStandard and AreInputsStandard treat this type?)
Before this PR, with default settings, which output types can be created in a standard transaction? Is
that the same as the script types that can be spent in a standard transaction?
Define anchor output, without mentioning Lightning Network transactions (try to be more general).
The PR description claims that creation of the defined P2A output type is already standard prior to the PR. Is this true, and how did you verify this?
Why does the size of the output script of an anchor output matter?
What other ways can you think of to implement an ‘anyone-can-spend’ anchor?
Continuing on the previous question, what would be the problem with using P2SH(OP_TRUE)?
What is the difference between OP_TRUE and OP_1? (Hint: where are they defined in the code?)
How many virtual bytes are needed to create and spend a P2A output?
The 3rd commit addsif (prevScript.IsPayToAnchor()) return false to IsWitnessStandard. What does this do, and why
is it needed?
How is witness program defined in BIP141? Where is it implemented in the code? (Hint: look for IsWitnessProgram)
VerifyWitnessProgram is modified to allow version 1, <0x4e73>, if is_p2sh is false. Why is !is_p2sh needed?
<vostrnad> instagibbs: sure but policy can be changed any time, perhaps there could be a dust policy carve out for P2A as it's unusually cheap to spend
<monlovesmango> i guess i am fuzzy on whether its a problem if there is only a single presigned tx. however if there were multiple presigned txs strung together, the miner could insert a OP_NOP in the scriptSig which would change the tx id
<instagibbs> an adversary could take an honest spend, add stuff to witness, propagate it at a lower feerate, and honest user would have to pay incremental fees to replace it...