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
|
Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D7582279
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 23:02:32 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com
[209.85.192.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 27471102
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 23:02:32 +0000 (UTC)
Received: by pdrg1 with SMTP id g1so48936519pdr.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 16:02:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=subject:to:references:from:message-id:date:user-agent:mime-version
:in-reply-to:content-type;
bh=DFe5VNK0ZtRUnFRXW5wsJfP9P1eDm4KngiCSsAAc08I=;
b=KNN259qo6ZFlJiQvyXn0ix78lB5s+io1QzEU7KnpMQetM7lKLjUuMJjp/ZZNLnZMHX
XeMdWRKM1rzg/NzCpKo3cBa7noLmj8rsjE9rykM5Xsj8y4ftVKmj4i8snPUeeJH2TWOc
9NLC68ofNXbcn+HD9IqyQfNe36OTN+xFHNc4YJhDH4Yxsd8Atthcn3i10lErdMjSHTQj
Q5LqIuvR3wqPpkJF5KCPgUmsshuxpr1L+THGIkwCp8sKcVdigJGLU+dQTub9Z3th164e
PvKo/hIgbHIq/rH+/FqoCHIPQvm56ZPrNP7znz3gf0rCiOWSqBkfymVb2R9/mE4tS6pg
AQ7A==
X-Received: by 10.70.109.165 with SMTP id ht5mr40901013pdb.137.1439766151877;
Sun, 16 Aug 2015 16:02:31 -0700 (PDT)
Received: from [192.168.1.126] ([168.70.69.242])
by smtp.googlemail.com with ESMTPSA id
hi1sm12376249pbc.47.2015.08.16.16.02.30
for <bitcoin-dev@lists.linuxfoundation.org>
(version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 16 Aug 2015 16:02:30 -0700 (PDT)
To: bitcoin-dev@lists.linuxfoundation.org
References: <CADWuND3EfO6YO3g4H09_mWhrHC4PX4SZpTTuETiX2PyCxSRCsQ@mail.gmail.com>
From: Cameron Garnham <da2ce7@gmail.com>
Message-ID: <55D1167B.1060107@gmail.com>
Date: Mon, 17 Aug 2015 07:02:19 +0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CADWuND3EfO6YO3g4H09_mWhrHC4PX4SZpTTuETiX2PyCxSRCsQ@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature";
boundary="IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF"
X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
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: Re: [bitcoin-dev] Bitcoin XT 0.11A
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: Sun, 16 Aug 2015 23:02:33 -0000
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I think that it is important to note that Bitcoin XT faces a natural
uphill battle.
Since it is possible to setup atomic inter-fork coin trades. I do not
see how Bitcoin XT could possibly win if Satoshi decides to sell 10000
XTBTC for BTC everyday for the first 100 days after the fork.
In many ways Satoshi gets to decide the winning fork just by his huge
economic investment in Bitcoin.
Here is some simple game-theory for non-consensus forks:
1. Spoil the ballot. Have Bitcoin Core propagate the Bitcoin XT version
string.
2. Encourage all miners to false vote for the Bitcoin XT fork.
- Now people have no-idea what % of the economy Bitcoin XT holds. -
Making it impossible for people to put economic faith behind Bitcoin XT.
3. Setup good Atomic Swap markets.
4. Setup a fork of Bitcoin XT that allows people to easily make a
transaction only on the XT fork (while leaving the original BTC coins
untouched).
This means that the Bitcoin XT fork will be born per-mature. Probably
with only a small % of hashing power behind it (contrary to the almost
100% that falsely claim to support it). It will be embarrassing that for
the goal of larger blocks, XT instead has blocks (before re-adjustment)
every 2h.
The price for XTBTC coins will plummet, Satoshi progressively dumping
his 1M stash over a year or so will make sure that it doesn't recover
either.
I cannot see how Bitcoin XT is but-not in a extremely weak position from
game theory.
I'm sure smarter people than I could come up with even more ways to
disrupt non-consensus forks.
Cam.
On 16/8/2015 6:39 AM, muyuubyou via bitcoin-dev wrote:
> I posted this to /r/BitcoinMarkets but I thought I might post it here a=
s
> well.
>=20
> ---
> Currently 0 mined blocks have voted for XT.
>=20
> If it ever gets close to even 50%, many things can happen that would
> reshape the game completely.
>=20
> For instance:
>=20
> - Core could start boycotting XT by not relying to them and/or not rely=
ing
> from them.
>=20
> - Core could appropriate the version string of XT, making it impossible=
to
> know how much they are progressing and a losing bet to actually execute=
the
> fork.
>=20
> This kind of node war if the factions were sizeable would make it very
> risky to transact at all - balances in new addresses could end up
> vanishing. Usability of the system would plummet.
>=20
> Note that any disagreement between the network and the biggest economic=
> actors - mainly the exchanges at this point, "wallet services" maybe -
> would mean BTC plummets. Hard. And so would confidence.
>=20
> It's a risky game to play.
> ---
>=20
> PS: I consider this attempt at takeover about as foul as it gets. The
> equivalent of repeating a referendum until a yes is obtained: the
> reasonable reaction to this is actively blocking said "referendum". The=
re
> was a fair play alternative which is voting through coinbase scriptSig =
like
> plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment=
=2E
> Once a majority is obtained in this way, devs have to react or if they
> don't then this sort of foul play would be justified. But this wasn't t=
he
> case.
>=20
> -----
> =E7=82=BA=E3=81=9B=E3=81=B0=E6=88=90=E3=82=8B
>=20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
--IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iF4EAREIAAYFAlXRFoUACgkQBJ8cMDO159b73gD/c4PzfzqrMlm5X5w+Bq2LR1Yc
8cPbgFyWxLjLUIzJIZ0A/ilCMIrQ0NTclLx/rR7X+QgMSSaTlJovL47YHdaXy1VQ
=UTBc
-----END PGP SIGNATURE-----
--IPAgNEAXiLLvFuiEIfr6plbDfpDvwEpPF--
|
