As Bitcoin has grown into a network that holds several billion in value and clears billions per day in transactions, you can understand that any proposed changes will be combed over for every spelling mistake. The amount of value people have invested in it and the amount of value it creates by settling transactions is far too important to take any code change lightly.
Additionally, we’re working with tools we’ve never used before, and we don’t know how the market will receive any updates. This makes protocol changes a very complicated topic. An example of this was the heated discussions that took place between 2016 and 2017 with the SegWit2x proposal as well as Taproot.
As Bitcoin gets, older BIPs are getting harder to push through, especially those that require a soft fork. For example, SIGHASH_ANYPREVOUT and its precedent iterations have been discussed since 2016.
The ossification of the Bitcoin code base ensures that only ideas that have really been put through the wringer make it through, while other ideas are pushed to second-layer solutions instead of bogging down the base chain.
But that doesn’t mean we won’t see proposals for Bitcoin upgrades in the future or that they won’t be merged into the code base as an updated version of Bitcoin core.
Now that you know a bit about upgrades, let’s look at BIP-118 and why it’s been hanging around this long.
What is ANYPREVOUT?
Given the interest in, and demand for, both simple covenants and better off-chain protocols, BIP118 is a soft fork candidate that could benefit Bitcoin and complement its direction in terms of scaling.
BIP 118 was written in 2017 and was then known as SIGHASH_NOINPUT. This proposal was initially made by the writers of the Lightning Network paper (Joseph Poon and Thaddeus Dryja) to solve a problem known as “transaction malleability”, later solved by SegWit.
BIP-118 proposes a soft fork that allows transactions not just to spend a specific previous transaction output, but, instead, any transactions output that uses the same signing key, in the case of SIGHASH_ANYPREVOUTANYSCRIPT (APOAS), or that spends an output with a specific amount and script in the case of SIGHASH_ANYPREVOUT (APO).
Use of these two sighashes is enabled only for Taproot script path spends of Taproot transactions that reference a public key prepended with a new public key type.
ANYPREVOUT is a signature hash flag that allows a signature to be used to spend any UTXO with the same script. This means that the signature does not need to be specific to the UTXO being spent, which can be useful in certain situations.
What ANYPREVOUT allows, in a nutshell, is not to sign the part of the information that refers to the previous transaction. A transaction with this type of sighash flag is not linked to past transactions and can spend any bitcoin from addresses with the same public key (or conditions for spending).
How ANYPREVOUT works
ANYPREVOUT works by hashing the scriptPubKey of the input, the sequence number, and the amount of the output being spent. This hash is then used to sign the transaction.
When the transaction is later verified, the signature is checked against the hash of the scriptPubKey and the sequence number.
If the signature is valid, then the transaction is considered valid.
Benefits of using ANYPREVOUT
There are a few benefits to using ANYPREVOUT. First, it can simplify the process of creating transactions.
For example, suppose you are creating a transaction that will spend multiple UTXOs with the same script. In that case, you can use ANYPREVOUT to sign the transaction once rather than signing each UTXO individually.
Second, ANYPREVOUT can improve the privacy of transactions. When you use a regular signature hash flag, the signature is specific to the UTXO being spent. This means that if someone knows the hash of the UTXO being spent, they can also know the signature. However, with ANYPREVOUT, the signature is not specific to the UTXO being spent, so it is more difficult for someone to track your transactions.
Another use case is an alternative form of “covenants” instead of CHECK TEMPLATE VERIFY. These covenants would allow for more complex smart contracts such as blind statechains, spacechains, creating safer Bitcoin Vaults or using Eltoo.
Covenants are a way to make sure one transaction can only be spent based on a specific condition which can be achieved using this secret little trick that embeds the signature for transaction t+1 right inside the output of the transaction.
Drawbacks of using ANYPREVOUT
There are also a few drawbacks to using ANYPREVOUT.
First, the issue is once you broadcast the transaction, you can’t undo or “take back” the previously signed transaction. All you can do is sign a new one and give it the ability to update or negate the previous transaction if someone tries to use it, but you can never take it back.
Second, ANYPREVOUT would not be supported by all Bitcoin wallets. This means that if you want to use ANYPREVOUT, you must ensure your wallet and your receiver’s wallet support it.
Soft forking and backward compatibility
Older software will continue to operate without modification as a soft fork, and users who do not wish to deal with these features can continue as normal.
Nodes that have not upgraded to support BIP 341 will see all taproot witness programs as anyone-can-spend scripts, and nodes that have upgraded to support BIP 341 and BIP 342 but not BIP 118 will treat any non-empty signature against a BIP 118 public key as valid.
As such, nodes are encouraged to upgrade to validate signatures for the new public key type fully.
Non-upgraded wallets can receive and send bitcoin from non-upgraded and upgraded wallets using SegWit version 0 programs, traditional pay-to-pubkey-hash, etc.
Depending on the implementation, non-upgraded wallets may be able to send to a SegWit version 1 program if they support sending to BIP350 Bech32m addresses and do not prevent the transaction from being broadcast due to considering the outputs non-standard.
Smoother transitions between on-chain and off-chain
ANYPREVOUT is a useful feature in certain situations that might not be popular right now but would definitely have an impact in the future. If we adopt more Bitcoin users, the flow between on-chain and various off-chain protocols will need to be smoother, or your scaling solution won’t realise its full impact.
Suppose you’re stuck using traditional on-chain transactions in a high fee/competitive block space environment. In that case, you’re either left with living in a layer two walled garden until fees are reasonable or waiting it out to move in and out of L2s which isn’t an ideal situation for Bitcoin.
Do your own research.
If you want to learn more about ANYPREVOUT on Bitcoin, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
