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
|
Return-Path: <andrewlecody@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 262E2259
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 18:37:45 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com
[209.85.218.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8271AEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 18:37:44 +0000 (UTC)
Received: by oiew67 with SMTP id w67so50263442oie.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 11:37:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:content-type; bh=jjZspZ51v3sActUNkANqSZUZnxuiKMqoaVmdaZMWs3A=;
b=KiUwUkQG5FU2XcdU+JN7BB7fILjNpiAUs5MvnnsoG9Fq0YREOxv9Dx7rlyHe1u3ADf
KTP7Bfa7rDpdZ0Gt1vY4HxTmR9Cil3lKNq6m+m23i7vPWMbM8PzU/5883ogDnqeESyuF
3HOSr46EuqRON42jT64w5wiv73dOPGnLMZ7Vv5Cyp3yS/Btl3lAwHEd+5wf46QNDCQ0N
Mbk4zBgn/nvhoexROpABJnTTs+hv4KGw0sU8F6xuTfv5FK59t0NHX8Iid101J9IuSl/D
6phetnYcxAC2gN+z251kZzZ9A1sTzi2oszsWEvPJfkK42LXtUZ/MxMOkcO5kXOt1VMCF
dEnw==
X-Received: by 10.202.52.2 with SMTP id b2mr22922262oia.125.1439750263841;
Sun, 16 Aug 2015 11:37:43 -0700 (PDT)
MIME-Version: 1.0
References: <CADWuND3EfO6YO3g4H09_mWhrHC4PX4SZpTTuETiX2PyCxSRCsQ@mail.gmail.com>
In-Reply-To: <CADWuND3EfO6YO3g4H09_mWhrHC4PX4SZpTTuETiX2PyCxSRCsQ@mail.gmail.com>
From: Andrew LeCody <andrewlecody@gmail.com>
Date: Sun, 16 Aug 2015 18:37:34 +0000
Message-ID: <CAEX2NSc9Q5_VqV3JneKxsQAgymMt4CsgS5x+xnrsmyVZ+JragA@mail.gmail.com>
To: muyuubyou <muyuubyou@gmail.com>, bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113d600a0aae14051d71fbca
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: 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 18:37:45 -0000
--001a113d600a0aae14051d71fbca
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
> 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". There
was a fair play alternative which is voting through coinbase scriptSig like
plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
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 the
case.
I fail to see how voting with version numbers is different than voting with
coinbase scriptSig. Other than the fact that the voting XT is doing is
formally defined instead of ad-hoc.
On Sat, Aug 15, 2015 at 5:40 PM muyuubyou via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> I posted this to /r/BitcoinMarkets but I thought I might post it here as
> well.
>
> ---
> Currently 0 mined blocks have voted for XT.
>
> If it ever gets close to even 50%, many things can happen that would
> reshape the game completely.
>
> For instance:
>
> - Core could start boycotting XT by not relying to them and/or not relyin=
g
> from them.
>
> - Core could appropriate the version string of XT, making it impossible t=
o
> know how much they are progressing and a losing bet to actually execute t=
he
> fork.
>
> 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.
>
> 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.
>
> It's a risky game to play.
> ---
>
> 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". There
> was a fair play alternative which is voting through coinbase scriptSig li=
ke
> plain 8MBers are doing, or like BIP 100 proposes for dynamic adjustment.
> 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 the
> case.
>
> -----
> =E7=82=BA=E3=81=9B=E3=81=B0=E6=88=90=E3=82=8B
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a113d600a0aae14051d71fbca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">>=C2=A0PS: I consider this attempt at takeover about as=
foul as it gets. The equivalent of repeating a referendum until a yes is o=
btained: the reasonable reaction to this is actively blocking said "re=
ferendum". There was a fair play alternative which is voting through c=
oinbase scriptSig like plain 8MBers are doing, or like BIP 100 proposes for=
dynamic adjustment. 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 the case.<div><br></div><div>I fail to see how voting w=
ith version numbers is different than voting with coinbase scriptSig. Other=
than the fact that the voting XT is doing is formally defined instead of a=
d-hoc.<br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sat, Aug 15, 2=
015 at 5:40 PM muyuubyou via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">I posted this=
to /r/BitcoinMarkets but I thought I might post it here as well.<div><br><=
/div><div>---</div><div><div>Currently 0 mined blocks have voted for XT.</d=
iv><div><br></div><div>If it ever gets close to even 50%, many things can h=
appen that would reshape the game completely.</div><div><br></div><div>For =
instance:</div><div><br></div><div>- Core could start boycotting XT by not =
relying to them and/or not relying from them.</div><div><br></div><div>- Co=
re 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 for=
k.</div><div><br></div><div>This kind of node war if the factions were size=
able would make it very risky to transact at all - balances in new addresse=
s could end up vanishing. Usability of the system would plummet.</div><div>=
<br></div><div>Note that any disagreement between the network and the bigge=
st economic actors - mainly the exchanges at this point, "wallet servi=
ces" maybe - would mean BTC plummets. Hard. And so would confidence.</=
div><div><br></div><div>It's a risky game to play.</div></div><div>---<=
br></div><div><br></div><div>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". There was a fair play alternative which is voting through=
coinbase scriptSig like plain 8MBers are doing, or like BIP 100 proposes f=
or dynamic adjustment. Once a majority is obtained in this way, devs have t=
o react or if they don't then this sort of foul play would be justified=
. But this wasn't the case.</div><div><br></div><div>-----</div><div>=
=E7=82=BA=E3=81=9B=E3=81=B0=E6=88=90=E3=82=8B<br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>
--001a113d600a0aae14051d71fbca--
|
