📅 Original date posted:2019-05-24 📝 Original message:A gamble like this, ...

Johnson Lau [ARCHIVE] /

npub1fyh…2mv9

2023-06-07 18:18:15

in reply to nevent1q…jemr

📅 Original date posted:2019-05-24
📝 Original message:A gamble like this, decentralised or not, is easy to manipulate since difficulty is determined entirely by the last block in a cycle

> On 24 May 2019, at 1:42 AM, 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

Author Public Key

npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9

Show more details

Published at

2023-06-07 18:18:15

Kind type

1 Short Text Note

Event JSON

{ "id": "f2340c8a86ac221b2b5258c75a5a2278c166ef9d80855fb3c540c74ca59c4eb3", "pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7", "created_at": 1686161895, "kind": 1, "tags": [ [ "e", "b72b1e530f79fa4fb81932af44198e28a4dcc369f9d5dfdf733984b5542ef714", "", "root" ], [ "e", "4e16e5eeff32fb649786d23283b7c63437c0285268b479f42c891ca424c0984e", "", "reply" ], [ "p", "c632841665fccdabf021322b1d969539c9c1f829ceed38844fea24e8512962d7" ] ], "content": "📅 Original date posted:2019-05-24\n📝 Original message:A gamble like this, decentralised or not, is easy to manipulate since difficulty is determined entirely by the last block in a cycle\n\n\u003e On 24 May 2019, at 1:42 AM, Tamas Blummer via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e Difficulty change has profound impact on miner’s production thereby introduce the biggest risk while considering an investment.\n\u003e Commodity markets offer futures and options to hedge risks on traditional trading venues. Some might soon list difficulty futures.\n\u003e \n\u003e I think we could do much better than them natively within Bitcoin.\n\u003e \n\u003e 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.\n\u003e A new OP_DIFFICULTY opcode would put onto stack the value of difficulty for the block the transaction is included into. \n\u003e The output script may then decide comparing that value with a strike which key can spend it. \n\u003e The input of the transaction would be a multi-sig escrow of those who entered the bet. \n\u003e The winner would broadcast. \n\u003e \n\u003e Once signed by both the transaction would not carry any counterparty risk and would not need an oracle to settle according to the bet.\n\u003e \n\u003e 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.\n\u003e \n\u003e Do you see a fault in this proposal or want to contribute?\n\u003e \n\u003e Tamas Blummer \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev", "sig": "4bb4a652fa423dc6e0e9dc7fb9cfc6ee67446eb98cb6fecc20cdfd18cc2b5c8877a99d0ddd8aa0163a2b9279f3b2d212688f41c5773dcf629aad383477748598" }