From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5BAA9255 for ; Sat, 8 Jun 2019 18:59:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F823711 for ; Sat, 8 Jun 2019 18:59:13 +0000 (UTC) Received: by mail-wr1-f52.google.com with SMTP id x4so2624528wrt.6 for ; Sat, 08 Jun 2019 11:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=4VpOP6eRmLZDcTDAggbob19bBb754kNa/TORvlCIjPo=; b=FRM1RALXLBROqU3anJ3oCWFIDGSZdW1fevvmkiXQWa4HaQcXRuG5SHzwPA32kIkfz+ wHQUfp9OI2+JRvbMKtHG3R4AH1lcpgL1Oau+/eJyVyPeZIh5wmOOQbbQ/c7n9glc7uTM imm8kwU2i2EBPAtRYGnyTHipy6M1E2NnSVaQ9wc5Q8489uLtnwzbDuS4Vprf+osfDsYW a1aCKOU3CiCVi9hElQIc0pSGbZnSq8Bl6Z6oxNNbmgbdVovIzkZQwc/3iYk50j7rm8v6 VluVC8X33Uieo/OJr6YpRbkz9UXLHLoWRWYRYkfUZ1j2RJ/5QKDP+HEVoowLtVQvgiCD UvUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=4VpOP6eRmLZDcTDAggbob19bBb754kNa/TORvlCIjPo=; b=MPTutC5YdnKux2TcPgvPCG2lqv9Ta/o/To7gbZBCqUVKMtL8RQuZVOMJJOuRS1SRv7 oCVUda7vsTVG2GaRyxKlTrIYJ4YsNFt/mhp5UpglSR1Br2uCpNCoONxUuYc85UH+IBct mzadxnTPThrfrb/yJXCBRgfIMY6sU2M/hwaM5td57Arx3kqkLU4RWPkX7dFd4g5QxaI9 y//qe48EjL/HBpC+A7aF8r+yFanc2cNq/vVpwOopm0TAYOz6OY95rPSP5v7v6n1vArNj /8T4jYzTz30enXdSPWTgYXmsLelVgJbxx16JpNIDwNHrnlVFG35KffVZv3bypE/mMgfh agAQ== X-Gm-Message-State: APjAAAVAMctWAcGZwI7zNZUTKiWULwMapHzlbnqDSC41ylM3Z+dKLYrY 7iK7DRBcG6wIXGSPrJBbvH3FAVcf X-Google-Smtp-Source: APXvYqzeij0WItgWPt0ilcRO6fdJnJdOiHtD1BFcUPbU6juXhZsTbVxKa6D4YjUB13Gr3RLV9FdEyA== X-Received: by 2002:adf:ecca:: with SMTP id s10mr21769031wro.168.1560020351723; Sat, 08 Jun 2019 11:59:11 -0700 (PDT) Received: from p200300dd67196b3001e4ab7e7184621e.dip0.t-ipconnect.de (p200300DD67196B3001E4AB7E7184621E.dip0.t-ipconnect.de. [2003:dd:6719:6b30:1e4:ab7e:7184:621e]) by smtp.gmail.com with ESMTPSA id q9sm9555593wmq.9.2019.06.08.11.59.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Jun 2019 11:59:10 -0700 (PDT) From: Tamas Blummer Content-Type: multipart/signed; boundary="Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sat, 8 Jun 2019 20:59:09 +0200 To: Bitcoin Protocol Discussion 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: Sun, 09 Jun 2019 08:19:34 +0000 Cc: Pieter Wuille Subject: [bitcoin-dev] WORKVERIFY: uncensorable contracts hedging biggest risk of mining without 3rd party or oracle 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: Sat, 08 Jun 2019 18:59:14 -0000 --Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In an earlier post [1] I suggested an approach to create native Bitcoin = contracts that reduce mining's income volatility and received very = helpful comments on implementation from Pieter Wuille [2] and Natanael = [3] After processing those comments I instead suggest the following = restricted interpretation of nSequence and a new opcode WORKVERIFY that = in combination is easier to implement and reason about as it follows the = implementation pattern of CHECKSEQUENCEVERIFY[5] Accumulated work on the blockchain is strictly increasing, therefore = transaction eligibility rule with a >=3D condition on it would need no = re-evaluation for descendant blocks, in mempool or at re-org, since = additional blocks or re-org can only increase the accumulated work. = Accumulated work is just like time, it is actually an alternate measure = of time through computation[6], therefore analogous to MTP based = restriction implemented with BIP68 [4]. =3D=3D=3D (the implementation proposal) =3D=3D=3D (needs soft fork for two reasons, activation logic tbd.) I. Stricter interpretation of nSequence to optionally refer accumulated = work: Only if bit 31 AND bit 30 is set in nSequence can the transaction be = included into any block. This is a restricting a rule of BIP68 [4] that = only required bit 31 to be set for unrestricted inclusion into blocks. = Otherwise nSequence refers to accumulated work (see encoding later) and = it is only viable to include the transaction into a block if the block = has >=3D work accumulated. This would define the meaning of one = additional bit in nSequence, but leave all other freedom of later = improvement left by BIP68. II. New WORKVERIFY opcode redefining a NOPx in transaction script as: Terminate script with false for any reason described in BIP112 or if bit = 31 is set but bit 30 is not set and 256 bit unsigned integer on stack is = higher than (nSequence &0xffff)>> 6 * 2^((nSequence & 0x3f) + 84) =3D=3D=3D (end proposal) =3D=3D=3D Notes on the work encoding: Total accumulated work as of now is > 2^90 and if we assume that mining = capacity keeps increasing with Moore=E2=80=99s law (double every year) = for the next 50 years, then it could sum up to 2^140. We have much less = bits available in nSequence therefore we have to encode accumulated work = in a floating point number with sufficient precision. The work accumulated during the current difficulty adjustment cycle is > = 2016 * 2^74 which is > 2^84. It is rather unlikely that accumulated work = in a difficulty adjustment period drops below 2^80 ever again in future = which means we need not be more precise than 2^80/2^90 or 2^-10 to = allow for contracts that reference increment until the next adjustment. = Therefore a mantissa of 10 bits should be sufficient. Using 6 bits of = exponent and an offset of 2^84 we can express the range of [2^84, 2^148) = that should be sufficient now and for foreseeable future. Please let me = know if the approach is not optimal or future proof in your opinion. Why, should we build this into Bitcoin ? The most influential risk factor in miners' investment decision is the = anticipated change of difficulty over the time horizon of the mining = equipment's expected lifetime. Their investments secure the network. The = ability to create contracts that reduce income volatility would lead to = additional investment into mining. A native Bitcoin contract is far superior to alternatives that could be = offered on traditional markets as: a native Bitcoin contract would be: - uncensorable: It requires only the agreement to terms between those = financially involved - fully collaterized: no counterparty risk which means Miner could buy = hedging contracts from any unkown and un-trusted actor that is able to = commit collateral - no oracle is needed - no disagreement on the settlement - publicly observable: allow to observe market opinion on future = difficulty - the length of the contract could match miner's investment horizon = extending over several difficulty adjustments. Why not on a side-chain ? Work is fundamental and intrinsic to the base layer. A contract that = reduces earnings volatility helps to attract more capital for mining and = therefore increase security on the base layer. How would this be used? Miner and Speculator sign a transaction that has an nLockTime of S in = the future. This gives both parties the option to alternatively spend = committed output in case the other would not follow through and publish = committing the collateral until S. Speculators contribution to collateral is higher than that of the Miner. = Miner=E2=80=99s collateral is the premium for the insurance provided by = Speculator. The single output of the transaction has following script: IF CHECKLOCKTIMEVERIFY DROP CHECKSIGVERIFY ELSE WORKVERIFY DROP CHECKSIGVERIFY ENDIF This allows the speculator to take back its collateral plus the option = premium after the maturity time point, which would however only be = possible if it was not taken earlier by Miner as sufficient work was = reached. The contract in finance terms is an american digital call option with = maturity and sufficient work as strike. The Miner profits of the = contract if work accumulated is more than contracted in which case he = would also have lower mining income, hence the contract would reduce = earnings shortcome. The Speculator would earn the option premium if the = contracted work was not required until maturity. In this case higher = mining income through higher market share compensates Miner for the loss = of option premium. In both cases Miner=E2=80=99s income volatility is = reduced. The Speculator may find it attractive to enter the contract if = the probability weighted option premium represents an attractive = interest on the capital committed. Contracted work would reflect the consenus of expected difficulty = increase over future time horizons. Observing above contracts on the = blockchain would allow calculation of market implied forward curve of = mining difficulty and its implied volatility which again would help = evaluating investment proposals into mining. An alternate more flexible setup would be a Lightning Network like = re-allocation of total collateral. Which would allo parties to mark the = option to market (observed work and volatility) as time passes and allow = for cooperative unwind. Tamas Blummer [1] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016952.ht= ml [2] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016958.ht= ml [3] = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016969.ht= ml [4] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki [5] https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki [6] = https://medium.com/@tamas.blummer/measuring-time-with-chain-of-blocks-893a= 38cc06bb --Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlz8BX0ACgkQ9nKRxRdx ORxSkgf+JzDoNo6hEpRZzDyGVkyCDwcanm+qS2NeDrXGLkrnHiXS9GykfYnS1wkv oSwCgdPYgXwICwByJ3mEfaSBxHUTqhW2ZTebmU4j/NwUgStUQwFfiIiFWCGsLVOV qfZTh/FtI9dXFRt+TEPPcsPlUVbFRAHv6DmFFTnbcezWUOYQ/qOZB8AR1KgADzsg CWmPnKq/npuSKcxtpaRW8HyDX6L9Td/Llb9kVh4krn1n2fPVcfVI4ABY7n6LpLlh ZGXnOY/+erf+3lxO6RDxaQ7nB5+j5Bl5izFJnUErEl0ipXoMetef4CFxw3q2jjJv 9EhfQN+7oq0joLV8VU8OmwjlQ7DjsQ== =rsYw -----END PGP SIGNATURE----- --Apple-Mail=_2D92696C-D95F-4E94-93D4-09B965BFB70F--