Author: Jeremy Rubin 2022-05-03 15:51:18
Published on: 2022-05-03T15:51:18+00:00
The Bitcoin developer community is discussing the use of SIGHASH_ANYPREVOUT instead of CTV's proposed covenant design. The current concern with APO is that it gets dangerously close to fully recursive covenants, which could be possible by tweaking APO to use a Schnorr signature without PK commitment. However, a trusted setup key deletion covenant with APO can still set up a fully recursive covenant. One potential use case for this is a spacechain backbone that infinitely iterates. By adding other opcodes like OP_IN_OUT_AMOUNT, more interesting recursive covenant features can be added on top. On the other hand, the approach of smaller independent steps, such as adding CTV and then gradually adding more flags and ergonomic Opcodes for covenants, is a safer and more granular path. Some believe that reasonable people might discriminate the "complexity class" of the design space available with just CTV versus APO. It is suggested that BIP118 could be a soft fork candidate that could benefit more Bitcoin users, given the interest in both simple covenants and better off-chain protocols. APO-AS part of BIP118, which enables CTV's features, may also face opposition similar to BIP119.
Updated on: 2023-06-15T19:23:23.048866+00:00