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
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 98FB2C0D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Apr 2017 20:10:10 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E62F41F5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Apr 2017 20:10:09 +0000 (UTC)
Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by
mx.zohomail.com with SMTPS id 1493323807302352.65475720581696;
Thu, 27 Apr 2017 13:10:07 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Johnson Lau <jl2012@xbt.hk>
In-Reply-To: <CACV3+OU3wT6ZZ+ffUOEXpnmu9p0kf42fEBv3fPxnGPJ88BVwAg@mail.gmail.com>
Date: Fri, 28 Apr 2017 04:10:03 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <98AA9A95-0150-4D71-8667-613E1CCD597D@xbt.hk>
References: <CACV3+OU3wT6ZZ+ffUOEXpnmu9p0kf42fEBv3fPxnGPJ88BVwAg@mail.gmail.com>
To: Matt Bell <mappum@gmail.com>
X-Mailer: Apple Mail (2.3259)
X-ZohoMailClient: External
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [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 20:10:10 -0000
As other explained, your scheme is broken.
Unless we have a softfork first (OP_CHECKBIP9VERIFY: payment is valid =
only if a BIP9 proposal is active), it is not possible to create a =
softfork bounty in a decentralised way
On the other hand, hardfork bounty is very simple. You just need to make =
sure your tx violates existing rules
> On 28 Apr 2017, at 01:48, Matt Bell via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> Hello everyone,
>=20
> 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.
>=20
> 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:
>=20
> # Setup
>=20
> - 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
>=20
> # Process
>=20
> 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.
>=20
> # Notes
>=20
> - 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.
>=20
> Thanks, I'd like to hear everyone's thoughts. Let me know if you find =
any glaring flaws or have any other comments.
> Matt
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
