Should simple scripts (i.e. Multisig/Timelock) be allowed in transactions containing subtransactions?

[WhatisRT]

Since we can't have Plutus scripts of version 3 or eariler in transactions containing subtransactions (for various reasons - the most relevant to this question of them being that scripts may run in non-balanced contexts) a natural question is whether simple scripts also suffer from this issue.

A reason why this might not be a problem is that validity either depends on signatures or on time only. I cannot see why anyone would make a script that uses time only, and even if so, why there would be any issue wrt. subtransactions/transaction balancing.

For scripts that rely on a signature, a signing party can inspect the transaction and make a choice based on the contents. This means that off-chain code could be adjusted to properly reflect the intent of the script.

On the other hand, there might be strange things that people do with these scripts that we're currently not aware.

In case we don't allow these scripts to be used in this context, we would add a new 'version' of simple scripts that has exactly the same features as they currently do, except that this version is allowed in those new transactions. In practice this would just be a new CBOR tag so it should be very easy to adjust the tooling.

This is also a question that the community should be involved in. Specifically, there are two questions it would be great to get some feedback on:

1. Is the work on adjusting downstream tooling for a new simple script version more difficult than I'm assuming?
2. Is there any use case (current or imagined) that would suffer from simple scripts being allowed in transactions with the new features?

[colll78]

We need a new version of Simple Scripts anyway as a result of CIP 112, which introduces the following change to native scripts:

<native_script> ::=
             <RequireSignature>  <vkeyhash>
           | <RequireObserver>   <scripthash>
           | <RequireTimeBefore> <slotno>
           | <RequireTimeAfter>  <slotno>
           | <RequireAllOf>      <native_script>*
           | <RequireAnyOf>      <native_script>*
           | <RequireMOf>        <num> <native_script>*

Native scripts are typically represented in JSON syntax. We propose the following JSON representation for the RequireObserver constructor:

{
  "type": "observer",
  "keyHash": "OBSERVATION_SCRIPT_HASH"
}

This is a critical improvement to native scripts, and would immediately be used by the vast majority of dApps to replace their order / request scripts, and more generally 99% of yielding / proxy / forwarding validators.

[WhatisRT]

Right, this is CIP-112. I think that's a good point, but it might be a bit orthogonal to this issue because even with a new version if there are use cases for simple scripts that can't be used with subtransactions we'd still likely want both options for the new scripts.

[fallen-icarus]

As long as native script criteria is restricted to their contexts, I don't see any issues. By this, I mean a native script in a sub-transaction should only succeed if that sub-transaction has the required signatures. The same applies to any native scripts found in the top-level transaction.