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
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D6D9140C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Jul 2017 06:30:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com
[209.85.220.176])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3D4BE0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Jul 2017 06:30:04 +0000 (UTC)
Received: by mail-qk0-f176.google.com with SMTP id 16so42748214qkg.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 07 Jul 2017 23:30:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=OKdcfQybGSy17GgkaurwCqi89IdRvvkm7RTAbZ+RrFU=;
b=s8rWjZwaUyZ6I8x1/2plKws/LKQRtMMtNtJj0IT+cpzSW40Jz4uPtwRUFLuGCEBqjP
pNxOFb/3x7pxkX4nvClbAyyu6K1/znfjYiufOxU1MSpQjdGUhQXtDm+b7BiwZbJtl7fa
Dg7Fb9KknxTpmrjcJKYZSNp3HJuDUsUO+wHUopwZZmbi3PSxEyN/yVE7YcNQ0NX6ORcv
sd8S94c+Rk4p0Gb7JO67IkU2KKG0hq0s/8MTL2NVZudh+3LjSeEoL4LympLSLMacA1da
TQhRIDNrFbN5dPpkzlFJ2kZqfQd7cCL0ymVTdnfaRNbCk5qh7Wu5MGCEazN/Zn27osYg
LTDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=OKdcfQybGSy17GgkaurwCqi89IdRvvkm7RTAbZ+RrFU=;
b=NL6vRfWNmpMXNnk3nwL6DA4mw3BLLdrxmP8JOukbYTsrknWgHMKmsrl99wIRouQKJc
IgnbsU930hM4SiSBQXtwdFfG6Vr2eDIJi60pIf53lwooyGqwjUd+RM4lS+lMk3zF0vI/
MTeJmWpvOZeHpEeCrhtCReIvEEQUdD0Q2+ppaKID0z6azQmput+43U+cqn6Jw2L4dqNN
UPwg3/TkuZfuTnKap8ioS784kUJAO1UihEgwmivAvcFWNAjDnK61G4IFWP9lZ2NSh8Kk
a/0N4vshKEO5nZRCxqS8lFEJRaoj8l8DuQ/X/MPzLr/VOGxs/cQSW/gGoEcYRiEsLIPR
VhjA==
X-Gm-Message-State: AIVw113z+6r8M3Xp08Bh7EwvILTa31KpV3bKsKSJGCucmrRQAbow5PzV
jKV66qurrM920GsU+3rwLoD/gQ9xl9z+a3w=
X-Received: by 10.55.179.197 with SMTP id c188mr34055010qkf.69.1499495404047;
Fri, 07 Jul 2017 23:30:04 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.61.145 with HTTP; Fri, 7 Jul 2017 23:30:03 -0700 (PDT)
In-Reply-To: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
References: <CAKzdR-qCmuj02yobAj9YDYq7Ed309z2VUaMtbL_i9vF3zkp5mw@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sat, 8 Jul 2017 02:30:03 -0400
X-Google-Sender-Auth: xD_JwLIUtqcGfVIf0PRKFfpoKvY
Message-ID: <CAJowKg+E8kJFBPa_q-QMGffpv20hWCeNaH1YYGs3JKELcWejbw@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c0658ece693340553c87a5c"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, 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
X-Mailman-Approved-At: Sat, 08 Jul 2017 10:54:55 +0000
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Segwit2x BIP
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: Sat, 08 Jul 2017 06:30:06 -0000
--94eb2c0658ece693340553c87a5c
Content-Type: text/plain; charset="UTF-8"
- The BIP91 portion of the fork seems OK to me. There are some issues with
timing, but since this is for miner coordination of segwit activation, and
has little to do with other network users, it could be included as an
option. (I'm a fan of adding options;plugins, etc. to Bitcoin... some
others aren't.)
- This hard fork portion of the proposal is being deployed with "emergency"
speed... even though there is not an emergency on the network today that I
am aware of. If enacted, it will certainly result in two chains - and
with no replay protection.. The results of this will be confusing - two
ledgers with many transactions appearing on both and others appearing only
on one.
- The BIP should be modified to provide evidence and justification for the
timeline that is consistent with the level of risk the network would bear
if it were enacted.
- The coercion used to drive production of this BIP is mired in a
misinterpretation of BIP9 and sets a precedent for Bitcoin that may
undermine the value prospect of all cryptocurrency in general. For this
reason alone - even if all of the engineering concerns and timelines are
improved - even assigning this BIP a number could be considered
irresponsible.
- If you still want to code up a fork for the Bitcoin network, consider
starting with Luke's hard fork code and changing the rates of growth as
needed for your desired effect. Also you might want to read this first
(code references are in there):
https://petertodd.org/2016/hardforks-after-the-segwit-blocksize-increase .
Plans are already underway for a hard fork, for reasons that have nothing
to do with block size, but could include a timeline for a block size growth
consistent with global average residential bandwidth growth.
--94eb2c0658ece693340553c87a5c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">- The BIP91 portion of the fork seems OK to me.=C2=A0 Ther=
e are some issues with timing, but since this is for miner coordination of =
segwit activation, and has little to do with other network users, it could =
be included as an option. =C2=A0 (I'm a fan of adding options;plugins, =
etc. to Bitcoin... some others aren't.)<div><br>- This hard fork portio=
n of the proposal is being deployed with "emergency" speed... eve=
n though there is not an emergency on the network today that I am aware of.=
=C2=A0 If enacted, it will certainly result in two chains - and with no re=
play protection..=C2=A0 The results of this will be confusing - two ledgers=
with many transactions appearing on both and others appearing only on one.=
=C2=A0=C2=A0</div><div><br><div><div><div>- The BIP should be modified to =
provide evidence and justification for the timeline that is consistent with=
the level of risk the network would bear if it were enacted. =C2=A0<div><b=
r></div><div>- The coercion used to drive production of this BIP is mired i=
n a misinterpretation of BIP9 and sets a precedent for Bitcoin that may und=
ermine the value prospect of all cryptocurrency in general. =C2=A0 For this=
reason alone - even if all of the engineering concerns and timelines are i=
mproved - even assigning this BIP a number could be considered irresponsibl=
e.<br><br>- If you still want to code up a fork for the Bitcoin network, co=
nsider starting with Luke's hard fork code and changing the rates of gr=
owth as needed for your desired effect. =C2=A0 Also you might want to read =
this first (code references are in there): <a href=3D"https://petertodd.org=
/2016/hardforks-after-the-segwit-blocksize-increase">https://petertodd.org/=
2016/hardforks-after-the-segwit-blocksize-increase</a> .=C2=A0 Plans are al=
ready underway for a hard fork, for reasons that have nothing to do with bl=
ock size, but could include a timeline for a block size growth consistent w=
ith global average residential bandwidth growth.<br></div></div></div></div=
></div><div><br></div></div>
--94eb2c0658ece693340553c87a5c--
|
