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
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
|
Return-Path: <tier.nolan@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3D1DEC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 19:00:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 240D687847
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 19:00:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id hbpmiKItEenl
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 19:00:03 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com
[209.85.221.47])
by whitealder.osuosl.org (Postfix) with ESMTPS id BEBEA877E0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 19:00:02 +0000 (UTC)
Received: by mail-wr1-f47.google.com with SMTP id r4so12775452wrx.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2020 12:00:02 -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;
bh=DSXBJ5k3fWj4LHqxIMTsp/kHjCV0tdBFYmG+F2s22SA=;
b=FbxjzaCBJ+G+x4v7UlBh3IlCtDDMNhE/0Xv/PN2Shur+e7GaSDz9kmOZtzC9cWu7a8
ZM82WLRhuS3s0HVYVmojabrqVgBmD6ZBZ3Q9bOK4FRkGfXtbt4JReg6YY5IN4evvhOL9
rBSfXlVkblWGgAEjzRW2WkEwOGqiDnGfTwOoIdMQTkWSG2vte7p6pLuSk9jUiQWjWDLf
l2jHflmB29OzZ/2qySfll2OoX5f8CWvOHT+y9JaYVh9NA8WiYupGATyGGE2OtFWmNog8
iS1KtvOywhivp8oCLNH1ch9iDnYvBgseWGgyLQfa/aqEtH4mHhpDijLWt5G67S5XfQ8s
8Dag==
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;
bh=DSXBJ5k3fWj4LHqxIMTsp/kHjCV0tdBFYmG+F2s22SA=;
b=lLpMa4UJ0kchdXIpsNhSX7MN1j3A84F/uXHovVtGFnioJ0gpMcUNzWYNCgpLYFLt27
yeiicocVfVc31fb2AEY7ayZr2oRg/AbmX1XuMs1lQvfwpUfo+jitGF1j8dfwqd+AxpCI
riYA7dnafLWUV1O73Uwe9dRvYwvYc7vBmCk9kjVDB3+eKwiT+yklEKam4w5PK6csyHde
1B8fX8A2AS77DVduLQZWgWvY2mhBeJFYxKK+mfbQVD9nQzGfa5BLpaBUZ7JZl9T8H0WF
RpFJPTSCZprjFo1nLQ3tBagjYnvvtuEpaZ3mWG7cndY9Zmw2MJKN15/OHrhx72EIKHBE
sHmg==
X-Gm-Message-State: AOAM532wkeEfwhLKNIzQnbgHMvp4uhqL3T5X8F3gpUejG2wFaz8q5M1M
1VnS+2+JOLKnpjCqCiI6Q8o8m2qR/FjxI3aZrdUoSdlJblw=
X-Google-Smtp-Source: ABdhPJwhPUGPqaD54/Xja4UWDxg2D69TEyZ83Z+/+gDbdylWMufOFi2mZyJrg8RIhYO5uCg+YxyC4UAZzFtybjQ/Kxk=
X-Received: by 2002:a05:6000:1203:: with SMTP id
e3mr11955824wrx.324.1597604400903;
Sun, 16 Aug 2020 12:00:00 -0700 (PDT)
MIME-Version: 1.0
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Sun, 16 Aug 2020 19:59:25 +0100
Message-ID: <CAE-z3OVCcAL2x39TswA8zrZ+yjSqdx4hccTWn9Ug8MQ5=k-Pgg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000cebef405ad0342b3"
Subject: Re: [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 <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: Sun, 16 Aug 2020 19:00:04 -0000
--000000000000cebef405ad0342b3
Content-Type: text/plain; charset="UTF-8"
On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
Any kind of opcode is a binary option. Either the output can be spent or
it can't.
You could get a pseudo-continuous future by having lots of outputs with
different thresholds.
Alice and Bob create a transaction with 100 outputs and each having 1% of
the future's value.
Output 0: Pay Alice if diff < 1.00 trillion else Bob
Output 1: Pay Alice if diff < 1.01 trillion else Bob
....
Output 98: Pay Alice if diff < 1.98 trillion else Bob
Output 99: Pay Alice if diff < 1.99 trillion else Bob
If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob
gets outputs 25-99. The future has a tick size of 1%. It isn't very
efficient though
It would be good to have the option to specify a block height for the
future too. If it triggered on block time, then miners have an incentive
to give false block times.
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 agree you would need covenants or something similar.
There needs to be a way to check the outputs (value and script) of the
spending transaction. You also need a way for Alice and Bob to create
their spending transaction in sequence.
Output 0: Pay Alice if [output value 0] <= Diff / 1 trillion AND [output
value 1] >= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
To spend her output, Alice has to create a transaction which pays Bob and
assigns the coins in the right ratio. [output value x] means the output
value of the spending transaction for output x.
To get it to work Alice creates a transaction with these restrictions
Output 0:
Script: Anything (Alice gets it to pay herself)
Value: <= Diff / 1 trillion
Output 1:
Script: Must pay to Bob
Value: >= (2 trillion - Diff) / 1 trillion
You also need to handle overflows with the calculations.
Bob can then spend output 1 and get his money.
There is a hold-up risk if Alice doesn't spend her money. You can make the
output script so either of them can spend their coins to avoid that.
Output 0:
Pay Alice if [output value 0] <= Diff / 1 trillion AND [output value 1]
>= (2 trillion - diff) / (1 trillion) AND [output 1 pays to Bob]
OR
Pay Bob if [output value 0] <= (2 trillion - Diff) / 1 trillion AND
[output value 1] >= Diff / (1 trillion) AND [output 1 pays to Alice]
You would need a covenant-like instruction to check the output values and
scripts and the diff opcode to get the difficulty.
--000000000000cebef405ad0342b3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sun, Aug 16, 2020 at 4:50 PM Thoma=
s Hartman via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoun=
dation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex">My understanding is that a=
dding a single op_difficulty operation as<br>
proposed would enable not true difficulty futures but binary options<br>
on difficulty.<br>
<br>
<a href=3D"https://en.wikipedia.org/wiki/Binary_option" rel=3D"noreferrer" =
target=3D"_blank">https://en.wikipedia.org/wiki/Binary_option</a></blockquo=
te><div><br></div><div>Any kind of opcode is a binary option.=C2=A0 Either =
the output can be spent or it can't.</div><div><br></div><div>You could=
get a pseudo-continuous future by having lots of outputs with different th=
resholds.</div><div><br></div><div>Alice and Bob create a transaction with =
100 outputs and each having 1% of the future's value.<br></div><div><br=
></div>
<div class=3D"gmail_quote"><div>Output 0:=C2=A0 Pay Alice if diff < 1.00=
trillion else Bob<br></div>Output 1:=C2=A0 Pay Alice if diff < 1.01 tri=
llion else Bob</div>
<div class=3D"gmail_quote"><div>....<br></div><div>Output 98:=C2=A0 Pay Ali=
ce if diff < 1.98 trillion else Bob<br></div>Output 99:=C2=A0 Pay Alice =
if diff < 1.99 trillion else Bob</div><div class=3D"gmail_quote"><br></d=
iv><div class=3D"gmail_quote">If the difficulty is 1.25 trillion, then Alic=
e gets outputs 0-24 and Bob gets outputs 25-99.=C2=A0 The future has a tick=
size of 1%.=C2=A0 It isn't very efficient though</div><div class=3D"gm=
ail_quote"><br></div><div class=3D"gmail_quote">It would be good to have th=
e option to specify a block height for the future too.=C2=A0 If it triggere=
d on block time, then miners have an incentive to give false block times.<b=
r></div><br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I am not clear if there is a way to solve the accounting for the<br>
payouts, but perhaps there is a way to do this with covenants.<br></blockqu=
ote><div><br></div><div>I agree you would need covenants or something simil=
ar.</div><div><br></div><div>There needs to be a way to check the outputs (=
value and script) of the spending transaction.=C2=A0 You also need a way fo=
r Alice and Bob to create their spending transaction in sequence.</div><div=
><br></div><div>Output 0:=20
Pay Alice if [output value 0] <=3D Diff / 1 trillion AND [output value =
1] >=3D (2 trillion - diff)=C2=A0 / (1 trillion) AND [output 1 pays to B=
ob]</div><div><br></div><div>To spend her output, Alice has to create a tra=
nsaction which pays Bob and assigns the coins in the right ratio.=C2=A0 [ou=
tput value x] means the output value of the spending transaction for output=
x.</div><div><br></div><div>To get it to work Alice creates a transaction =
with these restrictions</div><div><br></div><div>Output 0:</div><div>Script=
: Anything (Alice gets it to pay herself)</div><div>Value:=20
<=3D Diff / 1 trillion <br></div><div><br></div><div>Output 1:</div><di=
v>Script: Must pay to Bob</div><div>Value: >=3D (2 trillion - Diff) / 1 =
trillion<br></div><div><br></div><div>You also need to handle overflows wit=
h the calculations.</div><div><br></div><div>Bob can then spend output 1 an=
d get his money.</div><div><br></div><div>There is a hold-up risk if Alice =
doesn't spend her money.=C2=A0 You can make the output script so either=
of them can spend their coins to avoid that.</div><div><br></div><div>
Output 0: <br></div><div>=C2=A0=C2=A0=C2=A0 Pay Alice if [output value 0] &=
lt;=3D Diff / 1 trillion AND [output value 1] >=3D (2 trillion - diff)=
=C2=A0 / (1 trillion) AND [output 1 pays to Bob]
</div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 OR</div><div>=C2=A0=C2=A0=C2=A0 P=
ay Bob if [output value 0] <=3D (2 trillion - Diff) / 1 trillion AND [ou=
tput value 1] >=3D Diff / (1 trillion) AND [output 1 pays to Alice] <br>=
</div><div><br></div><div>You would need a covenant-like instruction to che=
ck the output values and scripts and the diff opcode to get the difficulty.=
<br></div></div></div>
--000000000000cebef405ad0342b3--
|
