Recursive covenant opposition, or the absence thereof, was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT



Summary:

In a recent discussion on the bitcoin-dev mailing list, the topic of creating an encumbrance that would require any spend from a covenant to only be sent to a script involving a specific key controlled by an authority figure was brought up. While such a walled garden could already be created with multisig and restrictions on where coins can be withdrawn to from exchanges, this proposal would use a recursive covenant to accomplish the same outcome. However, it was pointed out that exit from the restriction is still possible under the consensus rules of the protocol in non-consensus based systems. It was suggested that this sort of encumbrance is already possible by sending bitcoin to an OP_RETURN address that registers the value as "proof of burn" on a different system. Bitcoin consensus guarantees the value cannot be extracted back out of the OP_RETURN value. This concept is effectively taken up by spacechains for their one-way peg, which requires a covenant construct to track the single-tx-per-bitcoin-block that commits to the spacechain but is not directly used for the BTC value pegged into the spacechain. If OP_RETURN did not exist, it would be possible to pay to a pubkey constructed from a NUMS point or pedersen commitment that is guaranteed unspendable until secp256k1 is broken via bitcoin's consensus rules. This method was used for XCP/Counterparty's ICO in 2014, at about 823 uBTC per XCP on average. While these proposals may be possible, they may not be practical or desirable for users. It is more of a warning against such actions rather than a prevention of them.


Updated on: 2023-05-22T17:25:37.745389+00:00