bip-0118: allow ANYPREVOUT without ANYONECANPAY #1472

pull reardencode wants to merge 1 commits into bitcoin:master from reardencode:master changing 1 files +26 −12

reardencode commented at 10:40 pm on July 7, 2023: none

This enables CTV emulation without txid malleability

bip-0118: allow ANYPREVOUT without ANYONECANPAY

This enables CTV emulation without txid malleability

Signed-off-by: Brandon Black <freedom@reardencode.com>

ce5f3f1e25

ajtowns commented at 2:19 pm on July 8, 2023: contributor

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 commented at 3:51 pm on July 8, 2023: none

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 commented at 8:45 pm on July 8, 2023: none

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 commented at 9:17 pm on July 8, 2023: contributor

@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 commented at 1:51 pm on July 9, 2023: none

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).
luke-jr added the label Proposed BIP modification on Jul 9, 2023
moonsettler commented at 7:43 pm on July 11, 2023: none

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 commented at 3:57 pm on August 22, 2023: none

I feel like this is an excellent pull request for an explainer. sometimes it’s better to just look at the code.
ChrisMartl commented at 11:10 am on August 30, 2023: none

@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 commented at 6:27 pm on May 1, 2024: contributor

@reardencode, @ajtowns: What’s the status of this PR?
bitcoin deleted a comment on May 1, 2024
murchandamus added the label PR Author action required on May 8, 2024
5twelve approved
murchandamus commented at 1:03 pm on July 1, 2024: contributor

I’m closing this PR, because it has not made progress in almost a year, and my request for a status update was left unanswered for two months. If you are still working on this, please request reopening or open another pull request.
murchandamus closed this on Jul 1, 2024

Contributors
reardencode ajtowns RubenSomsen moonsettler earonesty ChrisMartl murchandamus 5twelve

Labels
Proposed BIP modification PR Author action required