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

[Tamas Blummer <tamas.blummer@gmail.com>]

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

I see. The uncompressing needs to be done either to compare. How are chances for that BIP?

This BIP would be explicitly offering risk managment of miners biggest risk.
Doing so without relying on external markets or oracle, self cointained would be an impressive and adequate feature.

Tamas Blummer

> On May 23, 2019, at 21:21, Nathan Cook <nathan.cook@gmail.com> wrote:
> 
> 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: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]