Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4BC3FE04 for ; Fri, 24 May 2019 16:23:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A691E821 for ; Fri, 24 May 2019 16:23:43 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id b18so10589859wrq.12 for ; Fri, 24 May 2019 09:23:43 -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=9uvFgujGpiNGbdz4HJaW5J29/dCYy0XPHzZhMMBYyEY=; b=GM8m5cQ2Khw5lzqVv//Vh6e4m5YHEq3MrV+Ts2vNfEr6BKN72LO/Lgn6Z2XXwq2LWp m3pN9Nv9dIJYOPhDxdTZcVhqWOuzfHVOWU44nb5YTghHhZx/mpKixiajfJ/HxeRG1hF8 Wqj9j5Q8oixYWH+nyyLJEQcZ0w5SRXYQ0kBPX0CFiDacingMFf0jnP6SMEcfnvBg6ZI3 o7+6XL998bZgNXGmJHh4j8Icl1D3hUxp0nMZ6hFXVh/+HMPaefgb1W4xXWO7RmQvgUHi 8QKuTBRvzZKQAsc7ISwpSGOxZJ4il96nL56zBizQeEq6FIakNIveSazzfPMkP50YhX9h v3tw== 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=9uvFgujGpiNGbdz4HJaW5J29/dCYy0XPHzZhMMBYyEY=; b=qsWDcgK3JKWK7Wd8vrJC+UJHyES8jTi9FwmNew2EZB1EbWVRxPLLLoZMGy7Z0lNuAB 9XpYUpU2FC9gBecW/r05FPVKMeRmrWL98YqDvUBvpJNHrDPW1xsvaNkMExOwD2KxVNWN rXvTnopDhtHgk+Ljf9XDimhhvlckS9xsRFClsyKwB949ICBOQUhhisu6mU+WBwDCEp+q 1vBdgyk6Hd+VtNb8zvvlcoRKZceXF6VqcgAryVZyJ3skq39+1uB7P8FFM78pfkDh9XzA 7X4a6Roj8WhODdGVB0wgXi+6gXsQUHXzYzhDmzYwucwaR6VJ0BuSyJiGawB6s6m2Udtg +uUg== X-Gm-Message-State: APjAAAUUsEa+ILB/p6U9teIJSUlXjbDgEumum3tI7vQAnPLHGHr8EnlY Aw4240E/gf7NRImV+qXBb5E= X-Google-Smtp-Source: APXvYqxUWdi+I2zAOeT7sZd6p8ZEBCPddrARyHvidcxmOI7vgfmvbpY7Lq67KBK8zdtOUAbstZKE3w== X-Received: by 2002:a5d:6249:: with SMTP id m9mr2149886wrv.270.1558715022196; Fri, 24 May 2019 09:23:42 -0700 (PDT) Received: from p200300dd67196b790d05e91a053cc573.dip0.t-ipconnect.de (p200300DD67196B790D05E91A053CC573.dip0.t-ipconnect.de. [2003:dd:6719:6b79:d05:e91a:53c:c573]) by smtp.gmail.com with ESMTPSA id x187sm3272945wmg.11.2019.05.24.09.23.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 May 2019 09:23:41 -0700 (PDT) From: Tamas Blummer Message-Id: <2502B467-092D-45A6-8F7B-9E3D08D5BB15@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_08DA8D34-0820-4E61-9B89-7C23C42C5592"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 24 May 2019 18:23:38 +0200 In-Reply-To: To: Natanael 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, HTML_MESSAGE, 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: Fri, 24 May 2019 19:07:11 +0000 Cc: Bitcoin Protocol Discussion , Pieter Wuille 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: Fri, 24 May 2019 16:23:44 -0000 --Apple-Mail=_08DA8D34-0820-4E61-9B89-7C23C42C5592 Content-Type: multipart/alternative; boundary="Apple-Mail=_29C2B4AE-A53C-432B-B1F9-9D3DFBCF6F0F" --Apple-Mail=_29C2B4AE-A53C-432B-B1F9-9D3DFBCF6F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii yes, log2work is already computed and would be a strictly increasing = value, like time. Thank you for this suggestion. I think attempting an = implementation will give further clues it this more suitable to express = the same. Tamas Blummer > On May 24, 2019, at 10:36, Natanael wrote: >=20 > On Thu, May 23, 2019 at 9:58 PM Pieter Wuille via bitcoin-dev = > wrote: > If the difficulty can be directly observed by the script language, you > would need to re-evaluate all scripts in unconfirmed transactions > whenever the difficulty changes. This complicates implementation of > mempools, but it also makes reasoning about validity of (chains of) > unconfirmed transactions harder, as an unconfirmed predecessor may > have conditions that change over time. >=20 > To deal with potentially wildly varying difficulty, could the value = exposed be the sum of accumulated PoW, or in other words the sum of each = block's difficulty value in the entire chain? This should be a value = that will only rise unless a reorg happens after a difficulty drop = happens (only likely to be the result of users manually blacklisting an = otherwise valid block that is several blocks back in the chain). >=20 > This mimics the effect of the block number which only grows. So if = you're starting at time A with difficulty X, then you'd estimate what = you think the accumulated PoW ought to be at time B with expected = difficulty Y (as compared to the current value at time A), and put that = value into the script. --Apple-Mail=_29C2B4AE-A53C-432B-B1F9-9D3DFBCF6F0F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
yes, log2work is already computed and would = be a strictly increasing value, like time. Thank you for this = suggestion. I think attempting an implementation will give further clues = it this more suitable to express the same.

Tamas Blummer

On = May 24, 2019, at 10:36, Natanael <natanael.l@gmail.com> wrote:

On Thu, May 23, 2019 at 9:58 PM = Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
If the difficulty can be = directly observed by the script language, you
would need to re-evaluate all scripts in unconfirmed transactions
whenever the difficulty changes. This complicates implementation of
mempools, but it also makes reasoning about validity of (chains of)
unconfirmed transactions harder, as an unconfirmed predecessor may
have conditions that change over time.

To deal with potentially wildly varying = difficulty, could the value exposed be the sum of accumulated PoW, or in = other words the sum of each block's difficulty value in the entire = chain? This should be a value that will only rise unless a reorg happens = after a difficulty drop happens (only likely to be the result of users = manually blacklisting an otherwise valid block that is several blocks = back in the chain).

This mimics the effect of the block number which only grows. = So if you're starting at time A with difficulty X, then you'd estimate = what you think the accumulated PoW ought to be at time B with expected = difficulty Y (as compared to the current value at time A), and put that = value into the script.

= --Apple-Mail=_29C2B4AE-A53C-432B-B1F9-9D3DFBCF6F0F-- --Apple-Mail=_08DA8D34-0820-4E61-9B89-7C23C42C5592 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlzoGooACgkQ9nKRxRdx ORzW5Qf+PMgZzJvgT/uPjTHBoUx1UzuB6dcIPj2J35L2jxr8WUmo+Ik7CvQfAclp kDMf+nnX5A8iRQXRAbXZ5lRHLxvgeYdTsPTjHBzIPYpOgGggmezD0S5eZsiIklw5 DEP9jOuUYMTKJdoMrkczxcTU9kKoZox1UQwgD9FnTpqinxhiOteFd6XYJp6dQgCL z4ns89dPkw492sVFtxHk63IjnWL0aU1Q1he2cbHTRwyAl5t7paXciI43DF95Zguu RTyQWupF6MXIhsU2L7l61rGFqkI/aliXKcq10ddOPRYvfV8m2xwHDK5CpVWZtvxC na4Y3yxH/AiT+AH9zW2cEVNdsw4aVg== =MVph -----END PGP SIGNATURE----- --Apple-Mail=_08DA8D34-0820-4E61-9B89-7C23C42C5592--