V3 transaction policy for anti-pinning

[harding]

@instagibbs

sometimes the best thing to do is just burn the ephemeral anchor value by itself, which results in a 65 vbyte txn. I think in the end it’s the same risk as people paying transaction accelerators so they can use fewer inputs in an RBF?

I think the expected use of an ephemeral anchor would be:

• Parent: 1 input, x+1 outputs. The +1 is the ephemeral anchor.
• Child: >=2 inputs, >=1 outputs. One input is the anchor spend; the other contributes fees.

In the pathological case, the parent is the same but the child is never created. So we need a requirement that spending the parent can only be done at a cost equal to at least 2-inputs and 1 output.

That requirement doesn’t need to be an input requirement; it could also be treating a childless parent as if it had the additional weight of a 2-input, 1-output child.