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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AE77B323
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 11:16:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com
[209.85.192.47])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 79E4D14B
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 11:16:31 +0000 (UTC)
Received: by qgj62 with SMTP id 62so25693423qgj.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 20 Aug 2015 04:16:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=wnhvSJTAOWxCp7zFZBCMkvAvCXr81UQX7Krf9cp7RVE=;
b=m7kwbJtA8KD521aRdu2o8vJ2rwLtKSUrG7qpH8zmFIVclhlxkdxpIZC639lrmfp0xk
52n16+97vi9sju3jJWZvDVdXvyvRl+CZSlL6kxBQ0gTEp67NwTw6GNTXjJDoEZMmvUHy
K2ghtsPhP2YzGl0nLb3Yk8zDj7E4PcLu0b3nkMVn3kSJ+f6+nq8f6os8IVGf+inKJEd9
q4C8XWG449ZX9uL3JD6omBhgb921U2QChnVwtQQKOlJRLid5XS0NVq64ZUMT1sENMV1P
bRJlRgzdODGdDQEzj1s5/mDxp/dc4bypjIa+qnWpSbV1om6Qa3nSSNTnDFs6bsWVppgO
gwbw==
MIME-Version: 1.0
X-Received: by 10.141.28.2 with SMTP id f2mr4798388qhe.9.1440069390654; Thu,
20 Aug 2015 04:16:30 -0700 (PDT)
Received: by 10.140.31.181 with HTTP; Thu, 20 Aug 2015 04:16:30 -0700 (PDT)
Date: Thu, 20 Aug 2015 12:16:30 +0100
Message-ID: <CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a114239747b63fc051dbc48ea
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Economic majority vote by splitting coins
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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, 20 Aug 2015 11:16:32 -0000
--001a114239747b63fc051dbc48ea
Content-Type: text/plain; charset=UTF-8
The economic majority is defined as the will of those who actually use
Bitcoin as a payment system.
No matter what the miners want, if users and merchants refuse to accept
their fork, then the fork loses and cannot be considered the "true" bitcoin
fork.
The problem is that it is easy to measure a miner vote. The economic
majority is not so easy.
The relative value of two forks could be compared by adding a system
similar colored coins.
These contracts could be added with a soft fork like the P2SH one.
OP_IF
<fork_id1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script 1>
OP_EQUAL
OP_ENDIF
OP_IF
<fork_id3> OP_DROP OP_HASH160 <hash script 2> OP_EQUAL
OP_ENDIF
This works like P2SH and is template matching. You can have as many
entries as you want.
In the example, the output can be spent on fork 1 and fork 2 by the owner
of <hash script 1> and can be spent on fork 3 by the owner of <hash script
2>.
Until the deadline, the value on each fork must be preserved when spending
the output. If you provide the key(s), you are allowed to consolidate
entries. You can also consolidate multiple outputs to the same key even if
you don't have the key.
This means that split outputs are a little more hassle to use and the
transactions are larger. This doesn't matter much, since measuring the
relative value of the two sub-coins only requires some of them to be traded.
If someone wants to propose a hard fork, they create a new fork id and
deadline and release software that implements the hard fork at the given
deadline (no miner vote needed).
To prevent spam, there could be a cost to create a fork-id (BTC paid to
OP_RETURN) and the deadline could have a max time in the future (say 2
years).
After the deadline, core will allow conversion of outputs that pay to the
core fork-id (probably 1) to be converted into unencumbered outputs by the
person with the core-id script. Likewise, the fork software will allow
outputs that pay to the fork id to be converted. Legacy bitcoin that
haven't been "split" will be spendable on both sides equally.
This means that users can convert x legacy bitcoin into x fork-bitcoins and
x core-bitcoins in advance of the fork.
This means that Exchanges could support trading between the two. The side
that trades with the most value is the one that is supported by the
economic majority.
As it becomes clear which side is going to win, the price of coins on the
losing side should drop. It is unlikely that the two would stay at exactly
the same value without one side winning.
Users who want to to use the losing rules are free to do so but the
economic majority will have made its decision.
--001a114239747b63fc051dbc48ea
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div>The economic majority is defined as th=
e will of those who actually use Bitcoin as a payment system.<br><br></div>=
No matter what the miners want, if users and merchants refuse to accept the=
ir fork, then the fork loses and cannot be considered the "true" =
bitcoin fork.<br><br></div>The problem is that it is easy to measure a mine=
r vote.=C2=A0 The economic majority is not so easy.<br><br></div>The relati=
ve value of two forks could be compared by adding a system similar colored =
coins.<br><br></div><div>These contracts could be added with a soft fork li=
ke the P2SH one.<br><br></div><div>OP_IF <br>=C2=A0=C2=A0=C2=A0 <fork_id=
1> <fork_id2> OP_DROP OP_DROP OP_HASH160 <hash script 1> OP_=
EQUAL<br>OP_ENDIF<br></div><div>OP_IF<br>=C2=A0 =C2=A0=C2=A0 <fork_id3&g=
t; OP_DROP OP_HASH160 <hash script 2> OP_EQUAL<br></div><div>OP_ENDIF=
<br><br></div><div>This works like P2SH and is template matching.=C2=A0 You=
can have as many entries as you want.<br><br></div><div>In the example, th=
e output can be spent on fork 1 and fork 2 by the owner of <hash script =
1> and can be spent on fork 3 by the owner of <hash script 2>.<br>=
<br></div><div>Until the deadline, the value on each fork must be preserved=
when spending the output.=C2=A0 If you provide the key(s), you are allowed=
to consolidate entries.=C2=A0 You can also consolidate multiple outputs to=
the same key even if you don't have the key.<br></div><div><br></div><=
div>This means that split outputs are a little more hassle to use and the t=
ransactions are larger.=C2=A0 This doesn't matter much, since measuring=
the relative value of the two sub-coins only requires some of them to be t=
raded.<br></div><div><br></div><div>If someone wants to propose a hard fork=
, they create a new fork id and deadline and release software that implemen=
ts the hard fork at the given deadline (no miner vote needed).<br><br></div=
><div>To prevent spam, there could be a cost to create a fork-id (BTC paid =
to OP_RETURN) and the deadline could have a max time in the future (say 2 y=
ears).<br></div><div><br></div><div>After the deadline, core will allow con=
version of outputs that pay to the core fork-id (probably 1) to be converte=
d into unencumbered outputs by the person with the core-id script.=C2=A0 Li=
kewise, the fork software will allow outputs that pay to the fork id to be =
converted.=C2=A0 Legacy bitcoin that haven't been "split" wil=
l be spendable on both sides equally.<br><br></div><div>This means that use=
rs can convert x legacy bitcoin into x fork-bitcoins and x core-bitcoins in=
advance of the fork.<br><br></div><div>This means that Exchanges could sup=
port trading between the two.=C2=A0 The side that trades with the most valu=
e is the one that is supported by the economic majority.<br><br></div><div>=
As it becomes clear which side is going to win, the price of coins on the l=
osing side should drop.=C2=A0 It is unlikely that the two would stay at exa=
ctly the same value without one side winning.<br><br></div><div>Users who w=
ant to to use the losing rules are free to do so but the economic majority =
will have made its decision.<br></div></div>
--001a114239747b63fc051dbc48ea--
|
