<p>This is to avoid a preimage too large to be claimed by one of the parties in a contract.</p>
<p>For instance without this check it would be possible to create a Lightning HTLC that is only claimable by a preimage whose size is larger than the maximum standard witness stack element size. An attacker cooperating with a miner would be able to claim the HTLC onchain on both sides of the attacked node: on the sender side with the &quot;success&quot; transaction (containing the preimage) included in a block by a cooperating miner and on the receiver side after timeout since the Lightning node wouldn't have been able to broadcast the non-standard &quot;success&quot; transaction through the P2P network.</p>
<p>Another example is a cross-chain atomic swap, to avoid a preimage to be valid on one chain but not another with more restrictive size limits. For instance without the size check an atomic swap between chain A which restricts witness stack elements to (say) 50 bytes and chain B which restricts them to 51 bytes could be made non-claimable on A by using a 51 bytes preimage.</p>
<p>As a side effect this makes sure the witness size for satisfying this script can be accurately calculated. (You would otherwise need to take into account the preimage may be as large as the maximum witness stack element size.)</p>
<p>A <a href="https://github.com/sipa/miniscript/pull/133" rel="nofollow noreferrer">pull request</a> adding some rationale for this check on Pieter Wuille's website was recently merged. (EDIT: the rationale is now available on the website, at the bottom of the &quot;Translation table&quot; section.)</p>

CC BY-SA 4.0
2023-10-04T10:05:17.587Z
2023-10-04T14:01:03.910Z
2023-10-04T14:01:03.910Z
Antoine Poinsot
<p>When I input the following miniscript into <a href="https://bitcoin.sipa.be/miniscript/" rel="nofollow noreferrer">https://bitcoin.sipa.be/miniscript/</a>:</p>
<pre><code>and(pk(claimant_pk),sha256(H))
</code></pre>
<p>I get the following Script:</p>
<pre><code>&lt;claimant_pk&gt; OP_CHECKSIGVERIFY OP_SIZE &lt;20&gt; OP_EQUALVERIFY OP_SHA256 &lt;H&gt;
OP_EQUAL
</code></pre>
<p>Why does Miniscript add this size check? Is there a safety concern or some ability for a malicious ScriptSig/ScriptWitness to skip the OP_SHA256 opcode?</p>

<security><script><hash-time-locked-contract><miniscript>
Why does Miniscript add an extra size check for hash preimage comparisons?
Sachin Meier
# Why does Miniscript add an extra size check for hash preimage comparisons?

(Asked by: username_0 on 2023-10-04)

When I input the following miniscript into <https://bitcoin.sipa.be/miniscript/>:

```
and(pk(claimant_pk),sha256(H))

```

I get the following Script:

```
<claimant_pk> OP_CHECKSIGVERIFY OP_SIZE <20> OP_EQUALVERIFY OP_SHA256 <H>
OP_EQUAL

```

Why does Miniscript add this size check? Is there a safety concern or some ability for a malicious ScriptSig/ScriptWitness to skip the OP\_SHA256 opcode?

**Tags:** security, script, hash-time-locked-contract, miniscript


---

## 1 answers

### Answer by username_1 on 2023-10-04. Score: 6 | Accepted answer

This is to avoid a preimage too large to be claimed by one of the parties in a contract.

For instance without this check it would be possible to create a Lightning HTLC that is only claimable by a preimage whose size is larger than the maximum standard witness stack element size. An attacker cooperating with a miner would be able to claim the HTLC onchain on both sides of the attacked node: on the sender side with the "success" transaction (containing the preimage) included in a block by a cooperating miner and on the receiver side after timeout since the Lightning node wouldn't have been able to broadcast the non-standard "success" transaction through the P2P network.

Another example is a cross-chain atomic swap, to avoid a preimage to be valid on one chain but not another with more restrictive size limits. For instance without the size check an atomic swap between chain A which restricts witness stack elements to (say) 50 bytes and chain B which restricts them to 51 bytes could be made non-claimable on A by using a 51 bytes preimage.

As a side effect this makes sure the witness size for satisfying this script can be accurately calculated. (You would otherwise need to take into account the preimage may be as large as the maximum witness stack element size.)

A [pull request](https://github.com/sipa/miniscript/pull/133) adding some rationale for this check on Pieter Wuille's website was recently merged. (EDIT: the rationale is now available on the website, at the bottom of the "Translation table" section.)


---

