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
|
Return-Path: <mappum@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9EB1C959
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Apr 2017 17:48:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com
[209.85.216.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 54E58175
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Apr 2017 17:48:38 +0000 (UTC)
Received: by mail-qt0-f178.google.com with SMTP id g60so32319231qtd.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Apr 2017 10:48:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=V6PUDJDeHyb7TvQo0yaZYI40uCcmzF1xPgrFpDj//xM=;
b=f/e8v9pIrPdPJRoXvoCFgRVhhMdltEqTEp3jlPY4DyzYEMQsKIQWDhx89SeVD5bzUM
KeJwqeLEgPPnRULJOPm1zG1qej9pz7qZ5makkKRCZ0HqhWEml/MMFokKk+GsxtRgQKWb
Iis/YMDCkF90de2po+EXbHPYz6inM9jpffcQWdtmLEhLphbMY/dIWy4pAoHVDQUJ3Fp/
UZ/AkCZ1Vys3U/XLNheDizqvKXbFjWOVT1nvR/e+z/zOrbd21M+ey49AzmZB0D8gYRF7
aYqI/edgnrrP2H7zh5++hUbf3f/xWEAUflsdiFlezFdM06BSms2r/ERJfJch3/Uq55YQ
gsEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=V6PUDJDeHyb7TvQo0yaZYI40uCcmzF1xPgrFpDj//xM=;
b=h/jObajGba+TQ36vWqmmjv5sIIhmu96brM6i56PLIn2pVtmm/F2nujMMy5mEcgFpyG
IcyTVsUKQpp+E3sGImhU6G5SjthKfs2eeXwhN+p6ZGVugkoMN5CF8xyIh7+PO5xonzm4
ZssPwPXrISznEMEADh4C2qKfW7ablEUrjqi35A+tGkZlIo15Fy9zxcc9wMHxywqq9Z66
LHtFsgTRDAbocfsPlNDOXh4ZjKzwIflmlp9A9mMWxnONR0i2iJ/cPA/m/0FEudJ8EeSO
1SdLAnNEq8YGt3LNjL0BATjcDn/U1kW+WP033l4dNAkNth+EpmnLgZIXs1MqBZIuooQH
3hPg==
X-Gm-Message-State: AN3rC/78KRK8kVMoQvMkTk+W46n7jZWagbglo2EhvrQ5PAnIse9U0A8R
YFMq5c3cO/J2lH38DtvRsMo1LSo3TtkMCUc=
X-Received: by 10.237.55.5 with SMTP id i5mr6163648qtb.76.1493315317239; Thu,
27 Apr 2017 10:48:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.138.7 with HTTP; Thu, 27 Apr 2017 10:48:16 -0700 (PDT)
From: Matt Bell <mappum@gmail.com>
Date: Thu, 27 Apr 2017 10:48:16 -0700
Message-ID: <CACV3+OU3wT6ZZ+ffUOEXpnmu9p0kf42fEBv3fPxnGPJ88BVwAg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114333820593fd054e29910f
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,
RCVD_IN_SORBS_SPAM 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, 27 Apr 2017 17:52:43 +0000
Subject: [bitcoin-dev] Trustless Segwit activation bounty protocol (aka.
bribing the miners)
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, 27 Apr 2017 17:48:39 -0000
--001a114333820593fd054e29910f
Content-Type: text/plain; charset=UTF-8
Hello everyone,
I've been thinking of an alternative to possibly get Segwit activated
sooner: bribing the miners. This proposal may not be necessary if everyone
is already set on doing a UASF, but miners seem to optimize for short-term
profits and this may make it easier for BitMain to accept its fate in
losing the ASICBoost advantage.
Here is a possible trustless contract protocol where contributors could
pledge to a Segwit bounty which would be paid out to miners iff Segwit is
activated, else the funds are returned to the contributor:
# Setup
- The contributor picks a possible future height where Segwit may be
activated and when the funds should be released, H.
- The contributor chooses a bounty contribution amount X.
- The contributor generates 3 private keys (k1, k2, and k3) and
corresponding pubkeys (K1, K2, and K3).
- The contributor creates and broadcasts the Funding Transaction, which has
2 outputs:
* Output 0, X BTC, P2SH redeem script:
<H> CHECKLOCKTIMEVERIFY DROP
<K1> CHECKSIGVERIFY
* Output 1, 0.00001 BTC, P2SH redeem script:
<H> CHECKLOCKTIMEVERIFY DROP
<K2> CHECKSIGVERIFY
- The contributor builds the Segwit Assertion Transaction:
* nTimeLock set to H
* Input 0, spends from Funding Transaction output 1, signed with k2,
SIGHASH_ALL
* Output 0, 0.00001 BTC, P2WPKH using K3
- The contributor builds the Bounty Payout Transaction:
* nTimeLock set to H
* Input 0, spends from Funding Transaction output 0, signed with k1,
SIGHASH_ALL
* Input 1, spends from Segwit Assertion Transaction output 0, signed with
k3, SIGHASH_ALL
* No outputs, all funds are paid to the miner
- The contributor publishes the Segwit Assertion Transaction and Bounty
Payout Transaction (with signatures) somewhere where miners can find them
# Process
1. After the setup, miners can find Funding Transactions confirmed on the
chain, and verify the other 2 transactions are correct and have valid
signatures. They can sum all the valid bounty contracts they find to factor
into their expected mining profit.
2A. Once the chain reaches height H-1, if Segwit has activated, miners can
claim the bounty payout by including the Segwit Assertion and Bounty Payout
transactions in their block H. Since Segwit has activated, the output from
the Segwit Assertion tx can be spent by the Bounty Payout, so both
transactions are valid and the miner receives the funds.
2B. If Segwit has not activated at height H, Input 1 of the Bounty Payout
is not valid since it spends a P2WPKH output, preventing the miner from
including the Bounty Payout transaction in the block. (However, the output
of the Segwit Assertion tx can be claimed since it is treated as
anyone-can-spend, although this is not an issue since it is a very small
amount). The contributor can reclaim the funds from Output 0 of the Funding
tx by creating a new transaction, signed with k1.
# Notes
- This is likely a win-win scenario for the contributors, since Segwit
activating will likely increase the price of Bitcoin, which gives a
positive return if the price increases enough. If it does not activate, the
funds will be returned so nothing is at risk.
- Contributors could choose H heights on or slightly after an upcoming
possible activation height. If contributors pay out to many heights, then
the bounty can be split among many miners, it doesn't have to be
winner-take-all.
- If Segwit does not activate at H, the contributor has until the next
possible activation height to claim their refund without risking it being
taken by another miner. This could be outsourced by signing a refund
transaction which pays a fee to some third-party who will be online at H
and can broadcast the transaction. If the contributor wants to pay a bounty
for a later height, they should create a new contract otherwise a miner
could invalidate the payout by spending the output of the Segwit Assertion.
Thanks, I'd like to hear everyone's thoughts. Let me know if you find any
glaring flaws or have any other comments.
Matt
--001a114333820593fd054e29910f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Hello everyone,</div><div><br></div><div>I've bee=
n thinking of an alternative to possibly get Segwit activated sooner: bribi=
ng the miners. This proposal may not be necessary if everyone is already se=
t on doing a UASF, but =C2=A0miners seem to optimize for short-term profits=
and this may make it easier for BitMain to accept its fate in losing the A=
SICBoost advantage.</div><div><br></div><div>Here is a possible trustless c=
ontract protocol where contributors could pledge to a Segwit bounty which w=
ould be paid out to miners iff Segwit is activated, else the funds are retu=
rned to the contributor:</div><div><br></div><div># Setup</div><div><br></d=
iv><div>- The contributor picks a possible future height where Segwit may b=
e activated and when the funds should be released, H.</div><div>- The contr=
ibutor chooses a bounty contribution amount X.</div><div>- The contributor =
generates 3 private keys (k1, k2, and k3) and corresponding pubkeys (K1, K2=
, and K3).</div><div>- The contributor creates and broadcasts the Funding T=
ransaction, which has 2 outputs:</div><div>=C2=A0 * Output 0, X BTC, P2SH r=
edeem script:</div><div>=C2=A0 =C2=A0 <H> CHECKLOCKTIMEVERIFY DROP</d=
iv><div>=C2=A0 =C2=A0 <K1> CHECKSIGVERIFY</div><div>=C2=A0 * Output 1=
, 0.00001 BTC, P2SH redeem script:</div><div>=C2=A0 =C2=A0 <H> CHECKL=
OCKTIMEVERIFY DROP</div><div>=C2=A0 =C2=A0 <K2> CHECKSIGVERIFY</div><=
div>- The contributor builds the Segwit Assertion Transaction:</div><div>=
=C2=A0 * nTimeLock set to H</div><div>=C2=A0 * Input 0, spends from Funding=
Transaction output 1, signed with k2, SIGHASH_ALL</div><div>=C2=A0 * Outpu=
t 0, 0.00001 BTC, P2WPKH using K3</div><div>- The contributor builds the Bo=
unty Payout Transaction:</div><div>=C2=A0 * nTimeLock set to H</div><div>=
=C2=A0 * Input 0, spends from Funding Transaction output 0, signed with k1,=
SIGHASH_ALL</div><div>=C2=A0 * Input 1, spends from Segwit Assertion Trans=
action output 0, signed with k3, SIGHASH_ALL</div><div>=C2=A0 * No outputs,=
all funds are paid to the miner</div><div>- The contributor publishes the =
Segwit Assertion Transaction and Bounty Payout Transaction (with signatures=
) somewhere where miners can find them</div><div><br></div><div># Process</=
div><div><br></div><div>1. After the setup, miners can find Funding Transac=
tions confirmed on the chain, and verify the other 2 transactions are corre=
ct and have valid signatures. They can sum all the valid bounty contracts t=
hey find to factor into their expected mining profit.</div><div>2A. Once th=
e chain reaches height H-1, if Segwit has activated, miners can claim the b=
ounty payout by including the Segwit Assertion and Bounty Payout transactio=
ns in their block H. Since Segwit has activated, the output from the Segwit=
Assertion tx can be spent by the Bounty Payout, so both transactions are v=
alid and the miner receives the funds.</div><div>2B. If Segwit has not acti=
vated at height H, Input 1 of the Bounty Payout is not valid since it spend=
s a P2WPKH output, preventing the miner from including the Bounty Payout tr=
ansaction in the block. (However, the output of the Segwit Assertion tx can=
be claimed since it is treated as anyone-can-spend, although this is not a=
n issue since it is a very small amount). The contributor can reclaim the f=
unds from Output 0 of the Funding tx by creating a new transaction, signed =
with k1.</div><div><br></div><div># Notes</div><div><br></div><div>- This i=
s likely a win-win scenario for the contributors, since Segwit activating w=
ill likely increase the price of Bitcoin, which gives a positive return if =
the price increases enough. If it does not activate, the funds will be retu=
rned so nothing is at risk.</div><div>- Contributors could choose H heights=
on or slightly after an upcoming possible activation height. If contributo=
rs pay out to many heights, then the bounty can be split among many miners,=
it doesn't have to be winner-take-all.</div><div>- If Segwit does not =
activate at H, the contributor has until the next possible activation heigh=
t to claim their refund without risking it being taken by another miner. Th=
is could be outsourced by signing a refund transaction which pays a fee to =
some third-party who will be online at H and can broadcast the transaction.=
If the contributor wants to pay a bounty for a later height, they should c=
reate a new contract otherwise a miner could invalidate the payout by spend=
ing the output of the Segwit Assertion.</div><div><br></div><div>Thanks, I&=
#39;d like to hear everyone's thoughts. Let me know if you find any gla=
ring flaws or have any other comments.</div><div>Matt</div><div><br></div><=
/div>
--001a114333820593fd054e29910f--
|
