DRAFT [New Feature] Initial PayToAnchor support

[kdmukai]

Basic support for the new PayToAnchor (p2a) output type.

Corresponding trivial test added to test_script.py.

Keeping this as DRAFT for now as I'm still learning and exploring how p2a inputs and outputs interact with different scenarios.

[odudex]

Can you contextualize this feature? What demands would it address? Is it to be used with Lightning, or can it also be used with standard transactions? Does a coordinator wallet implement "child pays for parent" through p2a?

[kdmukai]

@odudex there are a few scenarios described here: https://bitcoinops.org/en/bitcoin-core-28-wallet-integration-guide/

But yes, the initial expected use cases are LN focused. However, even without the LN/v3 tx context, the CPFP and RBF optionality it provides is intriguing (I think this was written before p2a, but it's obvious where p2a fits in):

Ephemeral anchors build on the v3 transaction relay proposal to allow v3 transactions to include a zero-value output paying a script that is essentially OP_TRUE, which permits that transaction to be CPFP fee bumped by anyone on the network with a spendable UTXO. The fee-bumping child transaction can itself be RBF fee bumped by anyone else with a spendable UTXO. In combination with other parts of the v3 transaction relay proposal, it is hoped that this will eliminate all policy-based concerns about transaction pinning attacks against time-sensitive contract protocol transactions.

https://bitcoinops.org/en/newsletters/2022/12/07/

---

I think we can probably set aside the LN ephemeral anchor use case (I don't think offline signers will be involved in LN TRUC txs). In our context, I don't know if we'd see p2a outputs in our txs but I think it's more likely that we could be asked to "spend" (CPFP) a p2a output.

What the exact scenario would be, I'm still not there yet.

However un/likely p2a outputs may be, it was pretty easy to get them working:

(v3 txs can have a zero-value p2a, but 240 sats is the minimum for a regular tx to be relayed (though I need to confirm this))

More of a struggle figuring out p2a inputs, but a lot of that is just my own issues creating any kind of more complex custom psbt.

---

My sense is that p2a is a new general purpose tool that specifically addresses a thorny LN problem, but people seem optimistic that it'll find other uses as time goes by.

But mostly this initiative is for my own learning; I really can't absorb something by just reading about it. So I had to start directly playing with p2a to get anywhere. But I also wouldn't be surprised if it proves useful sooner than later for airgapped signing devices to begin supporting it.

Also note that Sparrow already supports p2a and even has a fun custom icon!

[odudex]

Seems a promising feature, and as Sparrow already supports it, we should too!