<p>Inputs are not necessarily evaluated for script validity in any particular order. Indeed, today certain calls to <code>CheckInputScripts()</code> will push the created <code>CScriptCheck</code> objects onto a vector (<code>pvChecks</code>). Those script check objects will be pulled off the vector by asynchronous workers and may be evaluated in any order.</p>
<p>Since there is no particular ordering today, the implementation of cross-input signature aggregation will not affect any guarantees that exist today.</p>
<p>This lack of ordered script checking may make dynamically computing certain data about &quot;like&quot; inputs difficult, which may be relevant when trying to design covenants whose spends can be batched together.</p>

CC BY-SA 4.0
2023-01-20T18:16:03.950Z
2023-01-20T18:16:03.950Z
James O'Beirne
<p>When a transaction is being checked for validity, is there a particular order that the inputs are evaluated for script correctness?</p>
<p>This might be relevant when determining what consensus changes might be practical to design. For example, if we wanted to add incremental metadata for a given transaction during validation -- for example, &quot;sum the nValues for inputs that are related ways x, y, z - but do it on the fly so we don't impair validation speed.&quot;</p>
<p>Whether or not inputs are validated in a certain order would help gauge the feasibility of  a consensus change that relayed on those kinds of &quot;lazy&quot; data computation.</p>
<hr />
<p>Right now in the source code, the <code>CheckInputScripts()</code> function creates <code>CScriptCheck</code> objects in order of <code>vin</code>. Does this mean that input scripts are validated in order of vin-index?</p>
<pre class="lang-cpp prettyprint-override"><code>// validation.cpp

    for (unsigned int i = 0; i &lt; tx.vin.size(); i++) {
        [...]

        // Verify signature
        CScriptCheck check(txdata.m_spent_outputs[i], tx, i, flags, cacheSigStore, &amp;txdata);
        if (pvChecks) {
            pvChecks-&gt;push_back(CScriptCheck());
</code></pre>
<p>If we got cross-input signature aggregation, would that change such an ordering?</p>

<script><validation><transaction-input><covenants><cross-input-signature-aggregation>
Is there a particular order in which transaction inputs are checked for script validity?
James O'Beirne
# Is there a particular order in which transaction inputs are checked for script validity?

(Asked by: username_0 on 2023-01-20)

When a transaction is being checked for validity, is there a particular order that the inputs are evaluated for script correctness?

This might be relevant when determining what consensus changes might be practical to design. For example, if we wanted to add incremental metadata for a given transaction during validation -- for example, "sum the nValues for inputs that are related ways x, y, z - but do it on the fly so we don't impair validation speed."

Whether or not inputs are validated in a certain order would help gauge the feasibility of a consensus change that relayed on those kinds of "lazy" data computation.

---

Right now in the source code, the `CheckInputScripts()` function creates `CScriptCheck` objects in order of `vin`. Does this mean that input scripts are validated in order of vin-index?

```cpp
// validation.cpp

    for (unsigned int i = 0; i < tx.vin.size(); i++) {
        [...]

        // Verify signature
        CScriptCheck check(txdata.m_spent_outputs[i], tx, i, flags, cacheSigStore, &txdata);
        if (pvChecks) {
            pvChecks->push_back(CScriptCheck());

```

If we got cross-input signature aggregation, would that change such an ordering?

**Tags:** script, validation, transaction-input, covenants, cross-input-signature-aggregation


---

## 1 answers

### Answer by username_0 on 2023-01-20. Score: 2

Inputs are not necessarily evaluated for script validity in any particular order. Indeed, today certain calls to `CheckInputScripts()` will push the created `CScriptCheck` objects onto a vector (`pvChecks`). Those script check objects will be pulled off the vector by asynchronous workers and may be evaluated in any order.

Since there is no particular ordering today, the implementation of cross-input signature aggregation will not affect any guarantees that exist today.

This lack of ordered script checking may make dynamically computing certain data about "like" inputs difficult, which may be relevant when trying to design covenants whose spends can be batched together.


---

