<p>You could concievably remove the CTV validation code after its deactivation has been buried under enough proof-of-work so that a reorg is very unlikely to happen – similar to removing the deployment parameters of soft forks after their activation is sufficiently buried.</p>
<p>The problem is that now your software isn't a fully validating node – you're assuming that the chain with the most proof-of-work only has valid CTV spends. A full node should allow its users to completely verify the chain they're on.</p>
<p>For some this might be more of a semantics discussion, and that's fine, there are other (potentially bigger) issues with this proposal.</p>

CC BY-SA 4.0
2022-04-27T16:40:45.317Z
2022-04-27T16:40:45.317Z
Vojtěch Strnad
<p>Overall I generally agree with your summary and Vojtěch's answer. The probability of a year long re-org with an invalid CTV spend in it is infinitesimally small (not exactly zero) and would be <strong>extremely</strong> expensive to create.</p>
<blockquote>
<p>So the only problem I can see with the deactivation is how would new transactions spending outputs with CTV be treated after deactivation. But that seems orthogonal to this problem as this is something that the deactivation is actually about, at least how I understood it. One should remove CTV protected outputs before CTV deactivation, otherwise of course, after being deactivated, it should no longer work as previously expected.</p>
</blockquote>
<p>This is indeed one of the biggest problems. How do the protocol developers remove particular constraints without the consent of the owners of those outputs? Hope the owners receive the information that a particular constraint is going to expire? That seems very much against the ethos of Bitcoin to me.</p>
<p>The conditions on which protocol developers would decide to remove a particular constraint (and revert an opcode back to a OP_NOP) is also a can of worms. These conditions wouldn't be pre-encoded like say Ethereum's difficulty bomb (in Ethereum that is regularly overriden anyway) and whatever the conditions were could be easily gamed in advance of the decision.</p>
<p>In reality, the least controversial thing to do at the time of that decision would be to not revert it back to a OP_NOP at that time or ever. So essentially this proposal for a transitory soft fork activation was just a proposal for a permanent soft fork activation.</p>

CC BY-SA 4.0
2022-05-04T14:01:02.767Z
2022-05-04T14:01:02.767Z
Michael Folkson
<p>Recently, Harding discussed on bitcoin-dev mailing list an idea for a transitory soft fork activation e.g. for CTV. The idea (if I understood correctly) was that the activation would come with inbuilt deactivation after certain period of time (e.g. 5 years) and should the feature prove itself, the deactivation part could be deactivated :-).</p>
<p>Against this idea, a couple of responders mentioned that this does not help with reducing the cost of maintenance in the feature because full validation would still need to implement the CTV rules even after the deactivation of the feature, if deactivation happened.</p>
<p>My question is specifically related to such proposal like CTV that are forked in via replacing NOP operation. I don't understand the counterargument that the fully validating node would need the CTV (or other NOP-replacement) rules in order to perform full validation.</p>
<p>Suppose that CTV was activated and then deactivated 5 years later and then after 1 year after deactivation the code validating CTV would be removed from the code base. I would expect that removing CTV rules from the validation would leave blocks with transactions using CTV in that 5 year period as blocks with NOP operation. As such those blocks would be valid. Hence it does not seem to me that the validation code would be necessary to be kept in.</p>
<p>Of course, should anyone create an alternative chain of blocks, they could insert invalid CTV transactions inside, but in the example above they would need to provide a chain stronger than the last 1 year of blocks in order for this to matter.</p>
<p>So the only problem I can see with the deactivation is how would new transactions spending outputs with CTV be treated after deactivation. But that seems orthogonal to this problem as this is something that the deactivation is actually about, at least how I understood it. One should remove CTV protected outputs before CTV deactivation, otherwise of course, after being deactivated, it should no longer work as previously expected.</p>
<p>Or is this only discussion about semantics of what is understood as full validation? I.e. if a node would read those transactions from the activated period as NOP, it would not be by definition doing full validation as the reality was that it was not NOP? What am I missing?</p>

<soft-fork><bip119-checktemplateverify><activation>
Automatically reverting soft forks
Wapac
# Automatically reverting soft forks

(Asked by: username_0 on 2022-04-27)

Recently, Harding discussed on bitcoin-dev mailing list an idea for a transitory soft fork activation e.g. for CTV. The idea (if I understood correctly) was that the activation would come with inbuilt deactivation after certain period of time (e.g. 5 years) and should the feature prove itself, the deactivation part could be deactivated :-).

Against this idea, a couple of responders mentioned that this does not help with reducing the cost of maintenance in the feature because full validation would still need to implement the CTV rules even after the deactivation of the feature, if deactivation happened.

My question is specifically related to such proposal like CTV that are forked in via replacing NOP operation. I don't understand the counterargument that the fully validating node would need the CTV (or other NOP-replacement) rules in order to perform full validation.

Suppose that CTV was activated and then deactivated 5 years later and then after 1 year after deactivation the code validating CTV would be removed from the code base. I would expect that removing CTV rules from the validation would leave blocks with transactions using CTV in that 5 year period as blocks with NOP operation. As such those blocks would be valid. Hence it does not seem to me that the validation code would be necessary to be kept in.

Of course, should anyone create an alternative chain of blocks, they could insert invalid CTV transactions inside, but in the example above they would need to provide a chain stronger than the last 1 year of blocks in order for this to matter.

So the only problem I can see with the deactivation is how would new transactions spending outputs with CTV be treated after deactivation. But that seems orthogonal to this problem as this is something that the deactivation is actually about, at least how I understood it. One should remove CTV protected outputs before CTV deactivation, otherwise of course, after being deactivated, it should no longer work as previously expected.

Or is this only discussion about semantics of what is understood as full validation? I.e. if a node would read those transactions from the activated period as NOP, it would not be by definition doing full validation as the reality was that it was not NOP? What am I missing?

**Tags:** soft-fork, bip119-checktemplateverify, activation


---

## 2 answers

### Answer by username_1 on 2022-04-27. Score: 1

You could concievably remove the CTV validation code after its deactivation has been buried under enough proof-of-work so that a reorg is very unlikely to happen – similar to removing the deployment parameters of soft forks after their activation is sufficiently buried.

The problem is that now your software isn't a fully validating node – you're assuming that the chain with the most proof-of-work only has valid CTV spends. A full node should allow its users to completely verify the chain they're on.

For some this might be more of a semantics discussion, and that's fine, there are other (potentially bigger) issues with this proposal.


---

### Answer by username_2 on 2022-05-04. Score: 0

Overall I generally agree with your summary and username_1's answer. The probability of a year long re-org with an invalid CTV spend in it is infinitesimally small (not exactly zero) and would be **extremely** expensive to create.

> So the only problem I can see with the deactivation is how would new transactions spending outputs with CTV be treated after deactivation. But that seems orthogonal to this problem as this is something that the deactivation is actually about, at least how I understood it. One should remove CTV protected outputs before CTV deactivation, otherwise of course, after being deactivated, it should no longer work as previously expected.

This is indeed one of the biggest problems. How do the protocol developers remove particular constraints without the consent of the owners of those outputs? Hope the owners receive the information that a particular constraint is going to expire? That seems very much against the ethos of Bitcoin to me.

The conditions on which protocol developers would decide to remove a particular constraint (and revert an opcode back to a OP\_NOP) is also a can of worms. These conditions wouldn't be pre-encoded like say Ethereum's difficulty bomb (in Ethereum that is regularly overriden anyway) and whatever the conditions were could be easily gamed in advance of the decision.

In reality, the least controversial thing to do at the time of that decision would be to not revert it back to a OP\_NOP at that time or ever. So essentially this proposal for a transitory soft fork activation was just a proposal for a permanent soft fork activation.


---

