1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
|
Return-Path: <pieter.wuille@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AADECF58
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 19:45:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f169.google.com (mail-oi1-f169.google.com
[209.85.167.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 235FD821
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 19:45:50 +0000 (UTC)
Received: by mail-oi1-f169.google.com with SMTP id w9so5291877oic.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 May 2019 12:45:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-transfer-encoding;
bh=iRD/rumXY6Km6gazx4y83mQsQVienDPSax0A68Pgx+c=;
b=A4/adCC7oXUSyLuBrgqaOqGzjI8Slp/WYLbPgr26Q9MKCZsz88gWwF4KLxwnz0CEhQ
7YQe5MfWy6n0UPtnzTOIyqXMvm4ZcMb7o10KuR8dg542sleugLo0ork1kku8fGpTjHeu
xO7wG8FtoNz/giLvfNibgEEs9gpWUi579NQ8KlNxkLZ09jA/AeDRuRrRIO3NX94ccVZe
9mSwj/WUfdDA5Jl+Rl8BNaG1dvyf3Oy3jgJstyZ5RF1AtNmUYAgw3loSmp1SObf7VEOf
uLQbXK62Ve3QeKp6CJPVQD3H/M4PaxP4JEm18bSd/qXv6yE3phCcUQdSA1ki8eWT0Oau
dLaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:content-transfer-encoding;
bh=iRD/rumXY6Km6gazx4y83mQsQVienDPSax0A68Pgx+c=;
b=D4tB2Wl0nextwrS38GK+7McORoVsI1nPnneRktK+csbh0+93IoRTeLJxTBzxirmQ/w
VgX9e6/ZxSwKuENvJICOPxO0yCADFZCUkokSDA0XGokBRKrFwyzJYNwLyKdxUURqvg3t
I37qh0BsFWwjNdD8x1qMSDeI/jLiuX2LMfM5B3c3UcBmQlZMVO0b3sKFo0AMSse2ZKmp
CaEpHuSHYZJs4c6y4sVPGySZmjl0JgPNiEbj2yIBsNioKSor3GgDkoiu6wv3CxkMs7hs
dVCPyefH5FxFOVQE/RyxyMePGdEazKw4TQSsfLQQi8/BOQ7FQsQZA2O9IJvHXteWyKd5
hXxw==
X-Gm-Message-State: APjAAAUQRfW4Hn6KaSCVK9J0v6Wt3OIbGg4D7ns715IiOvTAqQ2MUr+v
Foc/txaGEFwR6oCSIFrI4kjXMMI+o8VK6nm+Pm8=
X-Google-Smtp-Source: APXvYqz6ww1tziRQQazSOtCgL60XPMRtie5r7Rhh9B4EVFTOmrlh9GMdCf5YqAzPsoHk8QX7bpaPg65jgTzJvf4EmXA=
X-Received: by 2002:a05:6808:98a:: with SMTP id a10mr69317oic.57.1558640749923;
Thu, 23 May 2019 12:45:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
In-Reply-To: <42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, 23 May 2019 12:45:37 -0700
Message-ID: <CAPg+sBged=ivVLj9tAM6zZdvWdYnG5pj4gozac5EupFPLtwyfA@mail.gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:57:54 +0000
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 May 2019 19:45:51 -0000
On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Difficulty change has profound impact on miner=E2=80=99s production there=
by 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 f=
or the block the transaction is included into.
> The output script may then decide comparing that value with a strike whic=
h key can spend it.
> The input of the transaction would be a multi-sig escrow of those who ent=
ered the bet.
> The winner would broadcast.
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.
For things like block time/height, this is solved by not having the
script itself observe the context state directly, but instead having
an assertion on the state outside of script (nLockTime for absolute
time/height and nSequence for relative), and then having opcodes
inside script that observe the assertion (OP_CLTV and OP_CSV). By
doing so, script validity is a single context-free yes or not that can
be evaluated once, and the variable part is just transaction-level
reasoning that doesn't involve a full script interpreter.
Additionally, the supported assertions are restricted in such a way
that if they are true within a particular block, they're also true in
any descendant, removing the complexity of reasoning about validity
(apart from the inevitable reasoning about possible double-spend
before confirmation).
I feel a similar construction is needed for observing block
difficulty. This can be done by either having an opcode that as a side
effect of execution "posts" an assertion (e.g. "difficulty at block
height X is at least Y"), instead of putting the difficulty on the
stack. An alternative is having the assertion be part of the
transaction structure (for example in the annex we propose in
bip-taproot), and having an opcode that observes the difficulty
assertion inside script.
I don't have a strong opinion either way on the usefulness of having
difficulty-dependent transaction/scripts.
Cheers,
--=20
Pieter
|
