đź“… Original date posted:2019-05-23
đź“ť Original message: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.blummer at 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.blummer at 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.cook at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190523/d5bd334b/attachment-0001.html>;
Nathan Cook [ARCHIVE] /
npub1qp…9lsqv
2023-06-07 18:18:13
in reply to nevent1q…ppc8
Author Public Key
npub1qp30q8l5nqgsxyw4nxrt8gyge6qjvm4syfg8zpmrc2pg8265s52sw9lsqvPublished at
2023-06-07 18:18:13Event JSON
{
"id": "1d0262ef985f29e0312b4c8006b7a451fb1f60e52167aeb56fb653c450e96c7f",
"pubkey": "0062f01ff498110311d59986b3a088ce81266eb02250710763c28283ab548515",
"created_at": 1686161893,
"kind": 1,
"tags": [
[
"e",
"b72b1e530f79fa4fb81932af44198e28a4dcc369f9d5dfdf733984b5542ef714",
"",
"root"
],
[
"e",
"c54b79c69bc603c0b50cbf75ce19f19da430e48cd9cab46762a9aae7944ec12e",
"",
"reply"
],
[
"p",
"c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7"
]
],
"content": "📅 Original date posted:2019-05-23\n📝 Original message:You're right, I didn't remember the whole procedure. You provide the\n80-byte header in the spend script, duplicate it on the stack, hash it, and\ncompare to what OP_CHECKBLOCKATHEIGHT gives you. Then you do bit masking on\nthe header with OP_AND to extract the difficulty. You can compare two\ncompressed difficulties directly by using more bit masking to separate the\nexponent and mantissa.\n\nOn Thu, 23 May 2019 at 22:54, Tamas Blummer \u003ctamas.blummer at gmail.com\u003e wrote:\n\n\u003e Block hash can suggest much higher difficulty than what is in effect, so\n\u003e OP_CHECKBLOCKATHEIGHT would not work to decide if difficulty is above the\n\u003e level of the bet.\n\u003e\n\u003e \u003e On May 23, 2019, at 21:45, Tamas Blummer \u003ctamas.blummer at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e I see. The uncompressing needs to be done either to compare. How are\n\u003e chances for that BIP?\n\u003e \u003e\n\u003e \u003e This BIP would be explicitly offering risk managment of miners biggest\n\u003e risk.\n\u003e \u003e Doing so without relying on external markets or oracle, self cointained\n\u003e would be an impressive and adequate feature.\n\u003e \u003e\n\u003e \u003e Tamas Blummer\n\u003e \u003e\n\u003e \u003e\u003e On May 23, 2019, at 21:21, Nathan Cook \u003cnathan.cook at gmail.com\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e It's true that it fetches the block hash; the idea is to compare the\n\u003e block hash's numeric value to the desired (uncompressed) difficulty\n\u003e directly, using a 256-bit version of OP_LESSTHAN.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Nathan Cook\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e On Thu, 23 May 2019 at 22:18, Tamas Blummer \u003ctamas.blummer at gmail.com\u003e\n\u003e wrote:\n\u003e \u003e\u003e That opcode would not help as it fetches block hash and not the content\n\u003e of the header.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\u003e On May 23, 2019, at 21:05, Nathan Cook \u003cnathan.cook at gmail.com\u003e wrote:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e You can get the same effect with OP_CHECKBLOCKATHEIGHT as proposed by\n\u003e Luke Dashjr (\n\u003e https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki) if you\n\u003e also re-enable/extend certain opcodes like OP_AND and OP_LESSTHAN. See\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013149.html\n\u003e and the ensuing thread.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Nathan Cook\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e On Thu, 23 May 2019 at 21:33, Tamas Blummer via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\u003e Difficulty change has profound impact on miner’s production thereby\n\u003e introduce the biggest risk while considering an investment.\n\u003e \u003e\u003e\u003e Commodity markets offer futures and options to hedge risks on\n\u003e traditional trading venues. Some might soon list difficulty futures.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e I think we could do much better than them natively within Bitcoin.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e A better solution could be a transaction that uses nLocktime\n\u003e denominated in block height, such that it is valid after the difficulty\n\u003e adjusted block in the future.\n\u003e \u003e\u003e\u003e A new OP_DIFFICULTY opcode would put onto stack the value of\n\u003e difficulty for the block the transaction is included into.\n\u003e \u003e\u003e\u003e The output script may then decide comparing that value with a strike\n\u003e which key can spend it.\n\u003e \u003e\u003e\u003e The input of the transaction would be a multi-sig escrow of those who\n\u003e entered the bet.\n\u003e \u003e\u003e\u003e The winner would broadcast.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Once signed by both the transaction would not carry any counterparty\n\u003e risk and would not need an oracle to settle according to the bet.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e I plan to draft a BIP for this as I think this opcode would serve\n\u003e significant economic interest of Bitcoin economy, and is compatible with\n\u003e Bitcoin’s aim not to introduce 3rd party to do so.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Do you see a fault in this proposal or want to contribute?\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e Tamas Blummer\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e _______________________________________________\n\u003e \u003e\u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190523/d5bd334b/attachment-0001.html\u003e",
"sig": "0bf4bf1e1e3eddf93f7b26c2d0059c588cfb0a9e66f3171667c9d7fa7e977648d143612edb3a1220ae0ef111c0a7d9975389d84ae549dd9495f6cf754352c754"
}