Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D61BF73 for ; Thu, 23 May 2019 19:10:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D67D1821 for ; Thu, 23 May 2019 19:10:57 +0000 (UTC) Received: by mail-wm1-f52.google.com with SMTP id c77so6976013wmd.1 for ; Thu, 23 May 2019 12:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mi1GeUfcm5xZFf/TRp7WbuihSDJm/cX0vzLJ927tamI=; b=l1InZKRZRD+o9sVhwL0husY+9Y5p2fyreHq1SXEnSU5yVKvbItkp8VgKfdimdW8JuR TU+eLZBxhUtkeCnd3mHCZDPCg+pTyQq536x3qkDuSiywEOIw7Z/HCKD0tCfe+T07Q26s w+X+mjMzLkuR71SO27ZwVfNYkaeQkpczeeIr7lJcWBpfJ8qsxNAyOxuXxrz6eNKOve8L ARHlQKa7c6KDIJAuUZK6qvNvpKBpBBfpJISZrCMGiYsZc0w+e4m1vHJb5LdYr6HIxHMt a+Vci8W/UO+2qfT6CeJ4tX4ZkjsU8KB97AtgXlOh3X8mTNh5MvjF9G6Zm0nBwhnmo7p+ kQYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mi1GeUfcm5xZFf/TRp7WbuihSDJm/cX0vzLJ927tamI=; b=qsqEAF7sp+FaeDn1k5UB77X5PWTuEtU6iZaGii4l3UJsrzvQxTsG1HOy5qAALb9K7x VfKP4BZ4RMXKpnl2bXd28zWDiUTlnZcn8q60Qtt1qY92AD+Sr/OrLtEKR60tQTHPjN6a bg7RN/uHOmXCbbkwuiamveWT959DZomN95dwlD0dLNtqKr9dd6OSztUdqZ2LN2TCRmWN OiL/eOuY7FExItxLs5x9jj6+hjNuMxNekpzNA8J5YhbRkFL7xAi103CErqEi713vZ2yk ojF3hdSUbo+pf7gz+yiE9NeWLUEb+4gDOL59ts600ljZXWRkEsWf91UdwYUU6Njj+vNa K3Ng== X-Gm-Message-State: APjAAAVcqme/Pd5UTwq0RdLwj9m9pyoksj2q+IffmxEDRWipBjmqizuJ U4mqtSOt3J/XdJLR9xxfLNQ= X-Google-Smtp-Source: APXvYqzqL4/lcNXqqCQ44dsYsQN/9q2ZSFtlvDwHHQBln7XfB24ZHgtbf+RJ0wziHPSH0m1RIpCMsA== X-Received: by 2002:a1c:3d87:: with SMTP id k129mr13592709wma.21.1558638656462; Thu, 23 May 2019 12:10:56 -0700 (PDT) Received: from p200300dd67196b11c120770d4d53396f.dip0.t-ipconnect.de (p200300DD67196B11C120770D4D53396F.dip0.t-ipconnect.de. [2003:dd:6719:6b11:c120:770d:4d53:396f]) by smtp.gmail.com with ESMTPSA id q68sm333591wme.11.2019.05.23.12.10.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 May 2019 12:10:55 -0700 (PDT) From: Tamas Blummer Message-Id: <31A492B1-AFDD-4A4D-AC2C-2020F8EF2954@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 23 May 2019 21:10:53 +0200 In-Reply-To: To: =?utf-8?Q?Jorge_Tim=C3=B3n?= References: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 23 May 2019 19:19:23 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party. X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 19:10:59 -0000 --Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The parameter used is property of the block just like the block height = is a property and is already evaluated in scripts, so no new kind of dependency or encapsulation break. The transaction itself was not invalid in a re-org but evtl. others = spending it if the difficulty on that fork is different, this is however intended as then on that fork the other was the winner. Tamas Blummer > On May 23, 2019, at 21:03, Jorge Tim=C3=B3n wrote: >=20 > The complains I could imagine about this, (apart from being a very > specific use case) are the same complains I heard about op_expiry. > Namely, that in a reorg, the same tx, having been valid in a given > block could potentially become invalid in some other block mining it. > I guess in this case the situation is less likely in this case than > with op_expiry, but it is still possible. > Another complain I could imagine is this kind of forces the > implementation to break some existing encapsulations, but I guess > those are just implementation details not that relevant here. > I personally don't have strong feelings towards this proposal one way > or the other, I'm just imagining what other people may complain about. >=20 > On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev > wrote: >>=20 >> Difficulty change has profound impact on miner=E2=80=99s 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. >>=20 >> I think we could do much better than them natively within Bitcoin. >>=20 >> 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. >>=20 >> Once signed by both the transaction would not carry any counterparty = risk and would not need an oracle to settle according to the bet. >>=20 >> 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=E2=80=99s aim not to introduce 3rd party to do so. >>=20 >> Do you see a fault in this proposal or want to contribute? >>=20 >> Tamas Blummer >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlzm8D0ACgkQ9nKRxRdx ORzZXgf/e/nH1YsPgW1IFZI7aGaACXFCc+hlvtcuWpfY7nN2bzkgqdrX5m0aP5O0 HSzuMXCOh0QkhxFCYtg7bl7gjJDf+BfahwLVRRAIkWw5ImDPGs4e4qrbjo0+/60q a8g3YYrgLZqpKmYiPt3Wbn1yoETjFUsb0BKz+86RRseg04Ri13Gx7Ge1acDd8OSx C7rsqC6oPLBt+j92L5+BJOJv5SdOEq5802uCd5b2o6gQLV7ZSGaHXjC76+03E6QG Zw7+rbyeaHeLdKRSkcjRNR8YJFXDJ/u0jlizaRJATSAuKOze3e4MwafVcE9YYu0Q 0lr79bbGs6k3BBBiBY1T/l0Q55NepA== =4Cx4 -----END PGP SIGNATURE----- --Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF--