5

It appears to me that there are various ways to build covenants and vaults with opcodes and sighash flags that are not yet enabled in Bitcoin (e.g. OP_CHECKTEMPLATEVERIFY, SIGHASH_ANYPREVOUT, OP_CAT).

Assuming these are considered for the next soft fork in Bitcoin what downsides are there to just enabling all of them and seeing what people build with them?

Obviously taking up a reserved OP_SUCCESSx with a potentially suboptimal opcode is one downside. And in the worst case a botched opcode could mean that a UTXO might not be able to spent (or impose unacceptable verification costs on full nodes). Are there any other potential downsides?

I suppose this is partly answered by what motivated Satoshi to disable a lot of opcodes in 2010 which I'm not clear on. The motivation appears to be security but again I'm not clear on what exact attacks were possible with what opcodes and the severity of those attacks.

1
8

Every piece of additional consensus logic has implementation and ongoing maintenance cost which is perpetual and can never be removed without potentially confiscating some user's assets.

When Satoshi disabled those opcodes he took a risk that doing so would destroy some user's funds, but Bitcoin was young, their usage was apparently non-existent, and those opcodes all could be used to cause effectively unbounded memory usage or memory corruption and crash nodes. I don't know if Satoshi necessarily realised that he might be destroying people's funds, but given the threat at that point in Bitcoin's life (while Bitcoins had very little value), it was probably the right call. It wouldn't be anymore.

Any newly introduced functionality isn't just a risk to the user, it's a potential risk to the entire network-- since flaws in it could result in consensus inconsistencies, node crashes, increases in worst case processing times, or even remote code execution vulnerabilities. Protecting against that requires review and testing resources which could otherwise be spent on other functionality. The costs are not one-time-costs either, since the code must be maintained and bugs could be introduced later.

Additional complexity also makes life harder for alternative node implementations, since they also have to implement every consensus rule, and it works against the users freedom to modify their own node (or implement their own). Because of these costs, "maybe someone will find it useful" isn't a really compelling argument.

The costs also mean that once some functionality is implemented there is reason to not implement something else which is partially redundant with it, so if flaws in a feature kill some uses but not all, it will be harder to get an improved alternative that covers all the uses deployed.

As far as the advantages of offering a simplified and mostly orthogonal instruction set, I don't think that itself matters much. While a proliferation of operations is a nuisance for anyone authoring an analysis tool, people can generally subset script however they like. Even if it would create a burden that users who need to jointly construct a policy have to agree on a common subset that their analysis tools are happy with, I think this cost could easily be offset by the added functionality.

If OP_BAR is a footgun and its redundant with OP_BAZ which is less of one-- just blacklist OP_BAR and only use OP_BAZ. But if OP_BAR is implemented first it may be difficult to make the case that that marginal improvement of OP_BAZ is worth its additional costs. So in that manner the implementation of a weak feature can get in the way of a stronger alternative that could have been done in the first place if an appropriate amount of effort had gone into it. The same statement is true if you replace 'footgun' with 'inefficient'.

Sometimes poorly designed features can have negative system incentive effects. For example, the original construction of time based nlocktime created an incentive for miners to lie about their current time, pushing it forward in order to be able to collect later nlocktime transactions and their fees. If time based nlocktime transactions became very common, this could have eventually created a race to the bottom where all miners were setting their times as far forward as they could to maximise their fees, and potentially endangering the stability of the network as a result even for users that don't use locktime. Fortunately nlocktime was fixable in a compatible way. Similarly, poorly constructed features could unnecessarily fragment the anonymity set or incentivise users to reduce privacy for everyone.

It's easy to imagine contrived features which would create negative systemic effects: E.g. OP_BOBSIG where a txout using it can be spent with no restrictions so long as Bob has signed the whole block -- an extremely efficient choice for those who trust Bob. And it seems harmless to people who don't use it, until you consider that it gives bob-trusters an unfair advantage, gives bob's mining an unfair advantage, and eventually might effectively hand control over the whole system to Bob. But systematic effects are a less common concern, since they require a feature that is attractive enough for people to choose to use it but unattractive for the system as a whole. It's still a factor that needs to be considered.

Other than in system effect corner cases most Bitcoin experts would agree that the owner of a funds should have complete freedom in how they choose to manage them-- even if that means they might sometimes choose an inefficient or less personally secure. Best practices can be addressed outside of the system itself. But because the consensus rules have to be implemented by all nodes and can't be removed, there are costs. These costs create situations where the the choice between a poorly and a well constructed operation-- or just between two totally different operations-- is to some degree mutually exclusive. Because of this a new feature not only needs to be safe for the network, it also ought to be clearly useful, and at least reasonably well designed-- otherwise it may use resources which could otherwise be used to deploy something more useful or better constructed.

1
  • This is such a brilliant answer, thanks Greg. – Michael Folkson Jun 27 at 11:58
1

There is another consideration other than ensuring bounded resource usage in all edge cases for an opcode which was briefly discussed by others on IRC that I'll summarize here.

There are different philosophical approaches to designing future opcodes for Bitcoin. One dimension is whether opcodes should be designed using a RIS (reduced instruction set) approach or a CIS (complex instruction set) approach. A reduced instruction set (RIS) approach leads to opcodes with minimal functionality but they can be combined like building blocks with other opcodes to create greater functionality (ie UNIX like). A complex instruction set (CIS) leads to opcodes that offer complete and particular functionality.

Another dimension is regarding safety and whether opcodes should be designed to prevent footguns, restricting programmers from building scripts that can be misused in ways that could potentially harm user security. The alternative is not to worry so much about user safety, allow maximal flexibility and push safety concerns to higher abstract layers (e.g. Miniscript, Policy, descriptors etc).

These two dimensions are not entirely orthogonal. If these dimensions aren't considered then you end up with a ragbag of new opcodes (and sighash flags) enabled and it is not clear what opcodes should be used for what and what guidance (if any) should be offered on how to use them safely. When Satoshi was enabling and disabling opcodes he/she didn't have the understanding that we have in 2021 and wasn't dealing with a system storing and transferring billions of dollars with higher layers dependent on changes made to the base layer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.