From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 87B09C0051 for ; Sun, 16 Aug 2020 15:41:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 7732220009 for ; Sun, 16 Aug 2020 15:41:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id syHvdGAuBAHc for ; Sun, 16 Aug 2020 15:41:42 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pj1-f49.google.com (mail-pj1-f49.google.com [209.85.216.49]) by silver.osuosl.org (Postfix) with ESMTPS id 339F11FB6B for ; Sun, 16 Aug 2020 15:41:42 +0000 (UTC) Received: by mail-pj1-f49.google.com with SMTP id mt12so6562861pjb.4 for ; Sun, 16 Aug 2020 08:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=hzCyS5rtm3YwDMQD6EXv27cEpqwHLeNnc/F6YzTStfE=; b=L7j+I+W4K67iIcRXG2GD7/6tVue6Jn7jIzpix18HWF5lD2+24l2ls9vW3zzzGUQVFu 8pkKQT3hnzb9jyLw/5TG6+LQ53c6YG52vtdIB73Atal2r6NlCltWFwcF8Nu65Pc0Ss8p 9lbjCJGph6G1rqr2tfw1IVvR9VoLp/SrC/G8h1ycXUxrTsaTu0etoNMeBaNAsxWlu0b/ nmNbSlE5Cq5HoOQ0vDOtj6rKbCjZt2RshmdAW3FZ7SRpWO7BeAAUWirKx5MDmvFkmppI Ak9mGahedmNO0frOLqKHnfykMfynfUlXAsgwyYvqMxqF4J2FnqTGHPLJF/Ndy90kUCvn 6RBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=hzCyS5rtm3YwDMQD6EXv27cEpqwHLeNnc/F6YzTStfE=; b=HrbN5txvSeKLbLBkranjA4gxyBoLdQKyXCgUiQk11VNf2FV6ce8UBPGDehqwZMsiLI PXLwW03ucUoeGGmU/lqxjK6SSnSUxAuRUE+azqH2NJhTvmXdKzhlanblCZ+B3AGrce/m rArGT711iSJ2IEHVswpdwHbVlvSZUiTy1uiWZQr9obKepEbF6VL5pvb6j55ynidi/8E4 KK1rEWOCYRGyYVwt98Fz9M+GRHCl+W4HHDz+LUXPt2g7WZ9x5XS+F+uPMmAhk7x0LQmG Pjq9n3bjJ+MbmEv4kXTlQ8fTeGv/JBcoGWmzsK76tVD82EURFhIoFVto6x6ce8ewV1iP EFwQ== X-Gm-Message-State: AOAM533QaCIkXq8yD90iYnBp4JWuplcD5mf6r+18QwhpK+MPHznZagsZ jRE/WjhM4On+cltr+6WYDb12/gg5H29coZY82SUyK+AZi+ozOqTg X-Google-Smtp-Source: ABdhPJyQS7MnbY/l+uobxIrwtIb0E2guWDh0IrxER3DRlrNQz9SbWwpBvpg1lkr57gApYjHVvorf0g1tpf/ny8M8vPE= X-Received: by 2002:a17:902:b18b:: with SMTP id s11mr8524857plr.211.1597592501323; Sun, 16 Aug 2020 08:41:41 -0700 (PDT) MIME-Version: 1.0 From: Thomas Hartman Date: Sun, 16 Aug 2020 11:41:30 -0400 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset="UTF-8" X-Mailman-Approved-At: Sun, 16 Aug 2020 15:50:50 +0000 Subject: [bitcoin-dev] reviving op_difficulty X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Aug 2020 15:41:43 -0000 First, I would like to pay respects to tamas blummer, RIP. https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer Tamas proposed an additional opcode for enabling bitcoin difficulty futures, on this list at https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html I really like this idea. 1) Trusted third parties are security holes https://nakamotoinstitute.org/trusted-third-parties/ and oracles (eg discreet log contracts) are really just trusted third parties in a blockchain's clothing. So truly ttp-free oracle-free on chain contracts are good. 2) Difficulty is a proxy for energy, which is a proxy for usd, which is what everyone currently cares about, which is bad. Energy is real. Bitcoin traders should care about future difficulty, not future usd price. So in sum I think this is a very good idea, and I would like to continue this work. Ideally I would like to see to completion the BIP that Tamas was unable to produce. Some initial thoughts on the technical merits. My understanding is that adding a single op_difficulty operation as proposed would enable not true difficulty futures but binary options on difficulty. https://en.wikipedia.org/wiki/Binary_option As the wikipedia article notes, "While binary options may be used in theoretical asset pricing, they are prone to fraud in their applications and hence banned by regulators in many jurisdictions as a form of gambling." The trouble is that because of the all or nothing nature binary options are more of a gamble than a hedge. They are popular with scammers, and even licensed binary options exchanges such as nadex are under constant scrutiny by regulators. Because any form of trusted third party-free / oracle free speculation would encourage economic use of blockchain space and support the transaction fee market, perhaps an economic case can be made for naive op_difficulty as above even it has more of a flavor of gambling than hedging. I think at a psychological level it would be good for a ttp-free difficulty speculation tool to capture mindshare. That being said, true difficulty futures -- real hedging and not just gambling -- would be far healthier for bitcoin than binary options. I am trying to wrangle what additional opcodes and protocol changes would be required beyond just op_difficulty, to get true difficulty futures on chain. I envision something like this. To give some context: Current difficulty is 16.9 Trillion. We're a week in to the current difficulty regime so there's aboout 1000 blocks to retarget, and predicted next difficuly is 18.5 Trillion. So let's pretend we sell a difficulty future that pays out in sats, of the next difficulty divided by a trillion. A reasonable price for this would be, say, 17.4 sats. So in our op_difficulty utxo, one address (the futures buyer) would get current difficulty / trillion, and the other address (the seller) would get however much value is locked in the utxo, minus that amount and miner fee. The payout would be limited by however much value is locked in the utxo. Since difficulty adjusts very slowly I don't think overflowing the locked up value would be much of a problem in practice. We also want a mechanism to enable on-chain purchase of such a contract, say for 17.4 sats. One additional opcode that apparently would be required is division. Some version of rshift could also do. I am not clear if there is a way to solve the accounting for the payouts, but perhaps there is a way to do this with covenants. I'm somewhat new to protocol and script. I would appreciate if anyone has any further advice on this. Cheers, Thomas.