Questions on Storm Eye spending paths and issuance transaction size

[kwsantiago]

Reading through the specification draft. Three things I could not resolve from the document, all in the Contracts section. Apologies if any of these are shorthand rather than gaps.

1. Merge path binding (§1.4.4)

The other three Storm Eye paths each assert jet::current_script_hash() == get_script_hash_for_storage(merkle_root), which binds the witness-supplied root to the UTXO actually being spent. §1.4.4 computes expected_current_script_hash but never compares it against jet::current_script_hash(). Its loop checks jet::input_script_hash(i) for i in 0..utxos_to_merge, and I do not see anything asserting that jet::current_index() falls inside that range, which §1.4.3 handles with assert(jet::current_index() == 0).

If both are absent, what stops a spender from supplying a root of their own construction, satisfying checks 1 through 5 with inputs they control, and spending an unrelated Storm Eye UTXO sitting at a higher input index? Is the binding assertion implied here?

For reference, examples/last_will.simf in SimplicityHL binds its covenant the same way §1.4.1 through §1.4.3 do, comparing jet::current_script_hash() against the output script hash so the constraint applies to the UTXO actually being spent.

2. Timelock spending path

Part IV §2 describes a three year timelock, renew-storm-utxos to push it forward, and recovery of the UTXOs by third parties if it lapses. §1.4 enumerates four spending paths and none is timelocked. Is that path omitted from the draft, and what is its spending condition? If it is unconditional after expiry, anyone inheriting those UTXOs also inherits the asset ID users are told to obtain from trusted sources in §1.1.

3. Issuance transaction size (Part VI §1.1)

MAX_TX_SIZE_IN_WEIGHT is set to 4,000,000, described as the maximum Liquid transaction size. In Elements that value is MAX_BLOCK_WEIGHT (src/consensus/consensus.h); the per transaction relay limit is MAX_STANDARD_TX_WEIGHT at 400,000 (src/policy/policy.h), enforced in IsStandardTx. calculate_max_issuance_round_tx_size() returns 666,666, which would exceed the standard relay limit. Should that constant be 400,000?

[ivanlele]

Hi! Thanks for the first contribution.

Regarding "3. Issuance transaction size", good catch! I’ve fixed it in the new Markdown spec that we’re migrating to.

Regarding "2. Timelock spending path", it is on the TODO list. Soon, the second Markdown file, specifically for the contract specification, will be added to the specs/ directory.

[Hrom131]

Hi @kwsantiago, regarding "1. Merge path binding (§1.4.4)"

Q: The other three Storm Eye paths each assert jet::current_script_hash() == get_script_hash_for_storage(merkle_root), which binds the witness-supplied root to the UTXO actually being spent. §1.4.4 computes expected_current_script_hash but never compares it against jet::current_script_hash(). Its loop checks jet::input_script_hash(i) for i in 0..utxos_to_merge, and I do not see anything asserting that jet::current_index() falls inside that range, which §1.4.3 handles with assert(jet::current_index() == 0).

A: Checks for the desired index cannot be used in this spending path, since all UTXOs to be merged will use the same spending path. For this reason, this check is not included. As for checking whether jet::current_script_hash() == get_script_hash_for_storage(merkle_root), yes, that check isn't there right now, but it could be useful as an additional layer of security.

Q: If both are absent, what stops a spender from supplying a root of their own construction, satisfying checks 1 through 5 with inputs they control, and spending an unrelated Storm Eye UTXO sitting at a higher input index? Is the binding assertion implied here?

A: Anyone wishing to spend a StormEye UTXO will not be able to use their own Merkle root, as this is part of the Taproot Storage UTXO, which cannot be altered. To satisfy checks 1–5, a valid signature for the merge of two or more StormEye UTXOs must be provided. Only the Oracle network itself can generate this signature. Given that jet::sig_all_hash() is used as the message for the signature, only the network can intentionally include in a transaction, for example, 5 StormEye UTXOs for the merge and one additional UTXO that they can spend on a different script_pubkey. This vulnerability is possible only if the entire network is compromised, which is the least of the problems in such a scenario.

Anyway, thanks for pointing that out. In any case, we could add a check for jet::current_script_hash() == get_script_hash_for_storage(merkle_root).

[kwsantiago]

Thanks, and confirmed 400_000 in the Markdown spec.

Two follow-ups on the merge path.

On the root. Agreed the attack fails, though I do not think root immutability is the reason. merkle_root is witness parameter 1, so nothing ties it to this UTXO unless the program compares get_script_hash_for_storage(merkle_root) against jet::current_script_hash(). What actually blocks it is check 5c: an attacker's own root would require Storm Eye asset held under a script derived from that root, and §1.5 issues the asset once with inflation_amount set to 0.

storm-tree/src/lib.rs already states the invariant: "This verifies only Merkle inclusion. Callers must separately validate the root against the authoritative network state." In the covenant that validation is the missing assertion, so I would read it as load-bearing rather than an additional layer.

On the index. The objection rules out the equality form, but assert(jet::current_index() < utxos_to_merge) holds for every UTXO in the merge set while still excluding inputs outside it.

Concretely: an approved merge of inputs 0 through 2 with utxos_to_merge = 3, plus a fourth Storm Eye UTXO at input 3. Input 3 runs the same program, checks 1 through 4 pass on the same witness, check 5 covers only inputs 0 through 2, and checks 6 through 8 validate output 0 against that sum. Input 3's amount is left unconstrained.

That does need a threshold signature, so it is closed to outsiders, but it does not seem to need the whole network either. §1.2 lists 11 validation checks for issuance and §2.2 lists 7 for burning, while §3.3.1 calls merge straightforward with none enumerated, so a buggy or dishonest requestor plus honest signers looks sufficient.

One aside: jet::num_inputs() == utxos_to_merge would not substitute, since §3.3 adds a Treasury fee input.