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
|
Return-Path: <odinn.cyberguerrilla@riseup.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E81078A6
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 03:22:48 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BE8489
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 21 Aug 2015 03:22:48 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.162])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
by mx1.riseup.net (Postfix) with ESMTPS id DE2CFC15D2;
Thu, 20 Aug 2015 20:22:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
t=1440127367; bh=k/rrv7XriL7bezfcdSKFfAFHEFEpw3EF9U08Zyao5TY=;
h=Date:From:To:Subject:References:In-Reply-To:From;
b=V/a3K5iQPHMFptrUvPqzqWh/CszoBtiEIPrLaxzBiMmM7lcKGXEI7egv9cOO4nyzR
JvQ9n8SrjMFIMeR7EQqwPostyEBmJLSez6IusQMDIRU58D0V+61ikrkN+M++Qrr59X
riYCNo0G5UW86LSEtiTghTkM9GlyJhXoUhLQpnYc=
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla)
with ESMTPSA id 8744B140C9F
Message-ID: <55D69986.3000307@riseup.net>
Date: Thu, 20 Aug 2015 20:22:46 -0700
From: odinn <odinn.cyberguerrilla@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Tier Nolan <tier.nolan@gmail.com>,
Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
References: <CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com>
In-Reply-To: <CAE-z3OWvA99Z9+wZ0K3XdKGZAV_XkJWYydw+Bo7tr4Oa2jQEWw@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
X-Spam-Status: No, score=-3.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD,
UNPARSEABLE_RELAY autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [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: Fri, 21 Aug 2015 03:22:49 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
That's interesting. But in all honesty I don't see most users being
able to pull off what you are describing. If people don't want XT it
isn't going to get used. If they are convinced that it is needed its
use will grow but they won't realize how bad they will be misled until
later, at which point it will be...
.. Too Late
On 08/20/2015 04:16 AM, Tier Nolan via bitcoin-dev wrote:
> 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.
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJV1pmGAAoJEGxwq/inSG8CH7sH/ik9CE8V97zcALmbRi0w/DFr
/LxJVUHpl3XhV/2BtQP0Z1qd9OkEhmuG3wOdweCi089ksMbj2BLZ16EgXOnmjXCe
kB+Wk+nG5DglvQwpV1Tnl7UGfqvtry0sOUH9g5wZxJGIdnin3YQEP+TofJTVkrHw
MvU/MifsJZlzBHYcjYjGmkyAzhGUcurUAD5q+wz+iq4JsE/Zvtr5mR3ctPoaKx2w
7wMjSsGRWLYejv+7qYKwEjSV/ELSZCVIPURBUGBzkwWSaXTKdMf17sb44xF5m42i
5CjsGQxA7pY7EMHbYTz/hfUqElZp5y7MXoxoYkPh9ehyG1HSPSyUnxAPrAhc/+Y=
=2F2R
-----END PGP SIGNATURE-----
|
