Update spacechains row for ctv

[moonsettler]

APO should be No for Ark and CTV should be Yes for Ark, CTV can do the ATLC and APO can't.

[stevenroose]

APO should be No for Ark and CTV should be Yes for Ark, CTV can do the ATLC and APO can't.

APO and CTV are kinda symmetric as you can use APO with the signature in the output to emulate CTV and you can emulate APO by doing CTV and a sig check with CSFS.

@op, can you elaborate on how Spacechains with CTV would work? Pre-calculated BMM like with pre-signed?

[moonsettler]

APO and CTV are kinda symmetric as you can use APO with the signature in the output to emulate CTV

Yeah. that's what people used to say, and everyone just took it as granted. Upon closer inspection it falls apart.

BIP-118 ANYPREVOUTANYSCRIPT can constrain outputs of a spending transaction by hardcoding a 65-byte signature and a 33-byte unknown public key type in a script. Alternatively, BIP-119 CTV can directly constrain transaction outputs to a template hash.

APO/AS SIGHASH does not commit to the number of inputs (nor obviously the other input outpoints themselves). This has some interesting consequences for Ark, which relies on TXID non-malleability for it's ATLCs.

Either one of these cases seem to be true depending on how the contracts are constructed:

• APO only: Users can double spend the ASP (USER CAN STEAL)
• APO + ASP single sig: ASP can stop users from unilateral exit and sweep funds after 4 weeks (ASP CAN STEAL)
• n-of-n musig on the vTXO tree: trustless, APO however is not needed, full interactivity, analogous to key deletion covenant (NOBODY CAN STEAL)

APO/AS can also not be used for the ATLC itself, as it has to commit to the TX outpoint of the connector transaction.

OP_CTV however commits to the number of inputs explicitly, thus committing to a single input prevents TXID malleability and ensures the ATLC is going to be enforceable.

[1440000bytes]

Spacechains are already possible without covenants, but yes, just about any covenant proposal that lets you pre-commit the next tx would be useful for spacechains.

https://delvingbitcoin.org/t/lnhance-bips-and-implementation/376/10

Simple CTV Spacechain: https://github.com/nbd-wtf/simple-ctv-spacechain/

I think we can add more information about trade-offs related to BMM below the summary table. However, writing "half" for CTV would be misleading.

[stevenroose]

ack

[stevenroose]

merged as b72065264e834ae948383a490f6506edaa76aebd