<p>Everything that is &quot;hidden&quot; in a Taproot script will still be revealed whenever it is used. They only remain hidden as long as the &quot;key path&quot; is used (which means the hidden script with whatever new opcodes it might contain is not used and might as well not have ever existed in the first place).</p>

CC BY-SA 4.0
2023-09-16T13:35:28.360Z
I disagree with the notion that because it's not revealed it might as well not have existed in the first place. The existance of a script branch provides the ability to use that branch, and that may be enough to alter behavior of counterparties, or provide unlikely but necessary escape valves. E.g. in a 2-of-3, 2 of the 3 parties may be almost always available, so that branch is almost always used (hopefully key path), but that doesn't remove the need for branches with the 3rd party.
Pieter Wuille
CC BY-SA 4.0
2023-09-16T13:38:30.507Z
I agree with that, I was just trying to be very concrete with what the chain will actually see in case of a key path spend. The chain will never know about the hidden scripts.
fiatjaf
CC BY-SA 4.0
2023-09-16T13:48:29.273Z
Yes, I wasn't disagreeing with the overall point you're making here; just pointing out that seen in isolation, it can be misinterpreted.
Pieter Wuille
CC BY-SA 4.0
2023-09-16T13:29:05.920Z
2023-09-16T13:29:05.920Z
fiatjaf
<p>In potential future softforks e.g. anyprevout or op_ctv, will it be transparent that a transaction uses this newly added feature? Or will it be hiding in a Taproot script and therefore hidden behind a single Schnoor signature?</p>
<p>The question basically comes down to: will potential users of future features leave a clear fingerprint on the blockchain?</p>

CC BY-SA 4.0
2021-05-17T22:39:37.823Z
Are you specifically asking about these proposed changes, or in general whether softforks do this? The answer is probably highly dependent on the specifics, and on how/what they end up being used for by the ecosystem.
Pieter Wuille
CC BY-SA 4.0
2021-05-18T07:18:15.873Z
I was specifically asking about those proposed changes or other new op codes
Bertram Lund
<taproot><fungibility>
Will future softforks decrease fungibility?
Bertram Lund
# Will future softforks decrease fungibility?

(Asked by: username_0 on 2021-05-17)

In potential future softforks e.g. anyprevout or op\_ctv, will it be transparent that a transaction uses this newly added feature? Or will it be hiding in a Taproot script and therefore hidden behind a single Schnoor signature?

The question basically comes down to: will potential users of future features leave a clear fingerprint on the blockchain?

**Tags:** taproot, fungibility

> **Comments:**
> **username_1**: Are you specifically asking about these proposed changes, or in general whether softforks do this? The answer is probably highly dependent on the specifics, and on how/what they end up being used for by the ecosystem.  
> **username_0**: I was specifically asking about those proposed changes or other new op codes  

---

## 1 answers

### Answer by username_2 on 2023-09-16. Score: 1

Everything that is "hidden" in a Taproot script will still be revealed whenever it is used. They only remain hidden as long as the "key path" is used (which means the hidden script with whatever new opcodes it might contain is not used and might as well not have ever existed in the first place).

> **Comments:**
> **username_1**: I disagree with the notion that because it's not revealed it might as well not have existed in the first place. The existance of a script branch provides the ability to use that branch, and that may be enough to alter behavior of counterparties, or provide unlikely but necessary escape valves. E.g. in a 2-of-3, 2 of the 3 parties may be almost always available, so that branch is almost always used (hopefully key path), but that doesn't remove the need for branches with the 3rd party.  
> **username_2**: I agree with that, I was just trying to be very concrete with what the chain will actually see in case of a key path spend. The chain will never know about the hidden scripts.  
> **username_1**: Yes, I wasn't disagreeing with the overall point you're making here; just pointing out that seen in isolation, it can be misinterpreted.  

---

