bip-0118: allow ANYPREVOUT without ANYONECANPAY

[reardencode]

This enables CTV emulation without txid malleability

[ajtowns]

Emulating CTV with APO is unnecessarily costly -- you add an extra 64 bytes of data (32 byte pubkey plus 64 byte signature for APO vs 32 byte hash for CTV) and an additional ECC operation (sha256 plus sG=R+hP for APO vs just sha256 for CTV). If there's no other benefit than that, I don't think this is worth spending a sighash bit.

Note that if APO is available, txid malleability is less of an issue -- if you want to pre-sign a transaction that spends an unconfirmed output, then provided that output has a unique pubkey that support APO signatures, you can sign via APO and have the signature remain valid even if the txid changes.

[reardencode]

Emulating CTV with APO is unnecessarily costly

I agree. Partly the point of doing this was to put more clearly the relative power of the two proposals. APO is more general than CTV, but as currently published cannot fully emulate it. I'd love to see both in bitcoin. That said, spending a sighash bit in the constrained context of only on version 1 keys, only when 0x40 is set is a much smaller consumption of upgrade paths than consuming an opcode for CTV, so one argument for my proposal here is that it enables both CTV-based protocols and ln-symmetry without consuming an opcode.

Note that if APO is available, txid malleability is less of an issue

I've been trying to fully wrap my brain around this. I don't think this helps the Ark case because of the lack of trust between the party creating an output/signature and the party depending on it. cc @brqgoo

[reardencode]

Forgot to add: many of the use cases never intend to be on chain, so the byte cost is less important here than in other potential upgrades.

[RubenSomsen]

@reardencode the problem in Ark is that you're trying to get atomicity by adding an input to tx_A that is a child of tx_B that is not on-chain yet. If tx_B doesn't go on-chain then tx_A cannot go on-chain either. If you add APO into the mix, then the input of tx_A is no longer tied to tx_B since the only thing that was tying the child to tx_B was the txid, which has now become malleable. Any input that is similar to the child will do, instead of only that specific input.

You could work around this by using regular HTLCs for atomicity instead, but that makes Ark more complex (interactive and slower) since HTLCs are a multi round process while this is not, and probably defeats the purpose of using APO in the first place.

[reardencode]

APO-based Ark doesn't use APO signatures on the vTXO forfeit transaction, but in the trees of the pool transaction. What is needed is a sufficiently constraining covenant to provide stable leaf txids in the tree (enabling the forfeit transactions).

[moonsettler]

Note that if APO is available, txid malleability is less of an issue

It breaks the ATLC completely. the connectors would work with ASP single sig. We went over all this with Burak and he conceded that original APO can't really help to implement a functional Ark. This change makes it possible to use APO instead of CTV. Idk why anyone would want to, that's an other story.

[earonesty]

I feel like this is an excellent pull request for an explainer. sometimes it's better to just look at the code.

[ChrisMartl]

@reardencode

Could you please provide an analysis statement, which effects or how this proposal could increment the exploit exposure for the Bitcoin system due to the loose flexibility of Bitcoin’s script (predicative processing)?

Could you please provide an statement how this proposal will affect the Nash equilibrium between the distribution of affordable archival full nodes and affordable mining devices?

Concerns, that equilibrium is reached by highly capitalized and centralized original node (storage + mining) entities neither addressed nor mitigated.

[murchandamus]

@reardencode, @ajtowns: What’s the status of this PR?