Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

[Nathan Cook <nathan.cook@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

It's true that it fetches the block hash; the idea is to compare the block
hash's numeric value to the desired (uncompressed) difficulty directly,
using a 256-bit version of OP_LESSTHAN.

Nathan Cook


On Thu, 23 May 2019 at 22:18, Tamas Blummer <tamas.blummer@gmail.com> wrote:

> That opcode would not help as it fetches block hash and not the content of
> the header.
>
> On May 23, 2019, at 21:05, Nathan Cook <nathan.cook@gmail.com> wrote:
>
> You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by Luke
> Dashjr (https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki)
> if you also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN.
> See
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html and
> the ensuing thread.
>
> Nathan Cook
>
>
> On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Difficulty change has profound impact on miner’s production thereby
>> introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on traditional
>> trading venues. Some might soon list difficulty futures.
>>
>> I think we could do much better than them natively within Bitcoin.
>>
>> A better solution could be a transaction that uses nLocktime denominated
>> in block height, such that it is valid after the difficulty adjusted block
>> in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of difficulty
>> for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike
>> which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who
>> entered the bet.
>> The winner would broadcast.
>>
>> Once signed by both the transaction would not carry any counterparty risk
>> and would not need an oracle to settle according to the bet.
>>
>> I plan to draft a BIP for this as I think this opcode would serve
>> significant economic interest of Bitcoin economy, and is compatible with
>> Bitcoin’s aim not to introduce 3rd party to do so.
>>
>> Do you see a fault in this proposal or want to contribute?
>>
>> Tamas Blummer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>

[-- Attachment #2: Type: text/html, Size: 4021 bytes --]