<p>No, there are currently no Script opcodes that access information about the difficulty. There has been discussion about a proposal called <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018085.html" rel="nofollow noreferrer">OP_DIFFICULTY</a> in the past.</p>
<p>In a similar direction, I saw some people discussing an idea to create a betting market where funds would be locked up to a shared address of two Bitcoin users, Alice and Bob, with a script that can be spent in two ways: either at a given blockheight to Alice, or at a given median time passed to Bob. Depending on whether mining is faster or slower than expected, either one or the other would come to pass earlier. I can’t find the discussion at the moment, though.</p>
<p>Vojtěch Strnad pointed out in the comments this paper on <a href="https://github.com/blockrate-binaries/paper/blob/master/blockrate-binaries-paper.pdf" rel="nofollow noreferrer">Blockrate Binaries</a>.</p>

CC BY-SA 4.0
2023-08-20T16:45:00.000Z
Thanks I would appreciate link to the discussion if you ever remember where it was. In theory could the logic for such a script be represented with simplicity or CTV?
Poseidon
CC BY-SA 4.0
2023-08-20T17:36:26.607Z
You probably mean Blockrate Binaries: https://github.com/blockrate-binaries/paper/blob/master/blockrate-binaries-paper.pdf
Vojtěch Strnad
CC BY-SA 4.0
2023-08-21T13:49:42.340Z
@Poseidon Bitcoin Script, in general, cannot observe anything that isn't part of the transaction data or committed to by it; this isn't something script additions can change (without fundamental design change). The way to add something like this would be to add some kind of assertion in the transaction (like nLockTime for absolute time and nSequence for relative time) first, and then possibly make that assertion observable by a script opcode (like OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY for locktime/sequence respectively).
Pieter Wuille
CC BY-SA 4.0
2023-08-20T16:02:18.397Z
2023-08-21T13:20:02.423Z
2023-08-21T13:20:02.423Z
Murch
<p>When the network sees a block appear with enough difficulty nodes can detect this as potentially the longest valid chain allowing the blocks miner to officially claim the block reward via coinbase transaction. Is it possible to create a Bitcoin output that is locked to the same difficulty conditions but is not a coinbase transaction? For example I could calculate the difficulty in 10 blocks and lock Bitcoin until a block with that difficulty is mined at which point the miner who wins the block will have priority to include a transaction claiming these Bitcoins.</p>

<script><mining-reward><difficulty><opcodes>
Is it possible to create an output locked to a specific mining difficulty target?
Poseidon
# Is it possible to create an output locked to a specific mining difficulty target?

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

When the network sees a block appear with enough difficulty nodes can detect this as potentially the longest valid chain allowing the blocks miner to officially claim the block reward via coinbase transaction. Is it possible to create a Bitcoin output that is locked to the same difficulty conditions but is not a coinbase transaction? For example I could calculate the difficulty in 10 blocks and lock Bitcoin until a block with that difficulty is mined at which point the miner who wins the block will have priority to include a transaction claiming these Bitcoins.

**Tags:** script, mining-reward, difficulty, opcodes


---

## 1 answers

### Answer by username_1 on 2023-08-20. Score: 2 | Accepted answer

No, there are currently no Script opcodes that access information about the difficulty. There has been discussion about a proposal called [OP\_DIFFICULTY](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018085.html) in the past.

In a similar direction, I saw some people discussing an idea to create a betting market where funds would be locked up to a shared address of two Bitcoin users, Alice and Bob, with a script that can be spent in two ways: either at a given blockheight to Alice, or at a given median time passed to Bob. Depending on whether mining is faster or slower than expected, either one or the other would come to pass earlier. I can’t find the discussion at the moment, though.

username_2 pointed out in the comments this paper on [Blockrate Binaries](https://github.com/blockrate-binaries/paper/blob/master/blockrate-binaries-paper.pdf).

> **Comments:**
> **username_0**: Thanks I would appreciate link to the discussion if you ever remember where it was. In theory could the logic for such a script be represented with simplicity or CTV?  
> **username_2**: You probably mean Blockrate Binaries: https://github.com/blockrate-binaries/paper/blob/master/blockrate-binaries-paper.pdf  
> **username_3**: @username_0 Bitcoin Script, in general, cannot observe anything that isn't part of the transaction data or committed to by it; this isn't something script additions can change (without fundamental design change). The way to add something like this would be to add some kind of assertion in the transaction (like nLockTime for absolute time and nSequence for relative time) first, and then possibly make that assertion observable by a script opcode (like OP_CHECKLOCKTIMEVERIFY and OP_CHECKSEQUENCEVERIFY for locktime/sequence respectively).  

---

