# Verification of RISC-V execution using OP\_CCV

**URL:** <https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313>\
**Category:** Protocol Design\
**Created:** [December 21, 2023, 1:57pm UTC](https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313 "2023-12-21T13:57:50Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![halseth](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/halseth/32/198_2.png) [@halseth](https://delvingbitcoin.org/u/halseth)\
**Post date:** [December 21, 2023, 1:57pm UTC](https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313/1 "2023-12-21T13:57:50Z")

</div>

Hi, I just posted a proof of concept tool that can trace the execution of RISCV-32 binaries (ELFs), and generate Bitcoin script that can be used to verify this execution on-chain: [Bitcoin Elftrace](https://github.com/halseth/elftrace)

It relies on the OP\_CHECKCONTRACTVERIFY covenant opcode from [MATT](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021182.html).

The way it uses is OP\_CCV is by committing to a single 32-bit hash (a merkle root) in the output, then the spender of this transaction will modify this root according to the rules and commit the new root in the new output.

So essentially is just needs a covenant opcode that lets you enforce the embedding of a dynamic piece of data in the output and a (static) taptree. This is exaclty what OP\_CCV enables, but perhaps some of the other covenant proposals could be used for the same purpose.

Feedback appreciated!

TLDR: [https://twitter.com/johanth/status/1737778712987287990](https://twitter.com/johanth/status/1737778712987287990)

---

<div class="post-metadata">

**Author:** ![sjors](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/sjors/32/59_2.png) [@sjors](https://delvingbitcoin.org/u/sjors)\
**Post date:** [March 26, 2025, 2:07pm UTC](https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313/2 "2025-03-26T14:07:51Z")

</div>

IIUC you’re using the newly proposed `OP_CCV` as well as `OP_CAT`, but otherwise only existing op codes. It seems one particular annoyance you need to work around when emulating a 32 bit system is the [31 bit limitation](https://bitcoin.stackexchange.com/a/122944/4948) of `CScriptNum` .

Would your code get significantly easier and produce more compact leaves by allowing slightly bigger numbers? IIUC the Great Script Restoration project goe straight to 64 bit, but it seems just a few extra bits would do the trick here? [Restoring Bitcoin’s Full Script Power | Rusty Russell’s Quiet Corner of The Internet](https://rusty.ozlabs.org/2024/01/19/the-great-opcode-restoration.html)

Are there other currently disabled op codes that would help?

---

<div class="post-metadata">

**Author:** ![halseth](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/halseth/32/198_2.png) [@halseth](https://delvingbitcoin.org/u/halseth)\
**Post date:** [May 19, 2025, 4:41pm UTC](https://delvingbitcoin.org/t/verification-of-risc-v-execution-using-op-ccv/313/3 "2025-05-19T16:41:49Z")

</div>

Yes, the biggest improvement would come from 64-bit arithmetics.

Since we are emulating unsigned 32-bit RISC-V opcodes, and Bitcoin Script only supports 31-bit, we must reimplement the full bit-by-bit arithmetics in script (and the scripts get huge).