You're right, I didn't remember the whole procedure. You provide the 80-byte header in the spend script, duplicate it on the stack, hash it, and compare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on the header with OP_AND to extract the difficulty. You can compare two compressed difficulties directly by using more bit masking to separate the exponent and mantissa.
On Thu, 23 May 2019 at 22:54, Tamas Blummer <tamas.blum...@gmail.com> wrote: > Block hash can suggest much higher difficulty than what is in effect, so > OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the > level of the bet. > > > On May 23, 2019, at 21:45, Tamas Blummer <tamas.blum...@gmail.com> > wrote: > > > > 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.c...@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.blum...@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.c...@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 > >> > > > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
