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
|
Return-Path: <akaramaoun@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 98BC941C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Jul 2015 16:11:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com
[209.85.223.177])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E808E63
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Jul 2015 16:11:17 +0000 (UTC)
Received: by ieik3 with SMTP id k3so80773307iei.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 17 Jul 2015 09:11:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=mTV9zYroF+gLQ3CMSpvza24bnQfq8lLcYHaha2hzOMM=;
b=HyjPCQ8klKKlBWrlM/6kyPNQofHayMAtNJAwi63U1eVEboSwZh9uw5OR+/X/tHEpaF
dyjOIh+WXZ8sx/unDAuaizwrMvuUFhsK7hhYXEoQf1U3nUmPZi4gOED6J23o66DwcOV1
Tx5dAxop1AC62YoU56ZFhdbNmmthLvy4SYhuTeakKyLfqIqfX+NyyoyDalKPhhqDkU7f
OxxMbZa28qZfxTZxeebI4jH6+/GYdZbQ2PJ8RpyUVbTWqb2it/z54oMI8amjl0qWuZhY
J+NdAvppPPuYWHCglTU8Zjk/ipiCGyJBB4X/+mNnwt5B1y9o5smNXE5TrmoFMbRl7MMU
hOvA==
MIME-Version: 1.0
X-Received: by 10.50.143.104 with SMTP id sd8mr11807777igb.34.1437149477326;
Fri, 17 Jul 2015 09:11:17 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.107.134.196 with HTTP; Fri, 17 Jul 2015 09:11:17 -0700 (PDT)
In-Reply-To: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
References: <CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com>
Date: Fri, 17 Jul 2015 16:11:17 +0000
X-Google-Sender-Auth: gtVyPayRRaYpKM8bwSEUs3uvGkw
Message-ID: <CAL8tG=nr8DGG+xad9t8dwPLJQ=jdYtZ=CSziN8kM_BTqEtrADg@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: Jeff Garzik <jgarzik@gmail.com>
Content-Type: multipart/alternative; boundary=001a1135f1a61606d5051b147052
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
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, 17 Jul 2015 16:11:18 -0000
--001a1135f1a61606d5051b147052
Content-Type: text/plain; charset=UTF-8
What are you trying to do? Break the ice with a hard fork so that later it
becomes easier to do so, with people more complacent towards it? There are
many solutions to the scaling problem that do not require a hard fork and
are quite simple to implement actually, and don't come with the
complications involved with a hard fork. I'm not a reputable developer on
this list, so my opinion probably doesn't matter much, but I watched and
analyzed this situation closely and I don't like this idea.
On Fri, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan to
> my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then this
> solution is at least available and a known quantity. A good backup plan.
>
> Benefits: conservative increase. proves network can upgrade. permits
> some added growth, while the community & market gathers data on how an
> increased block size impacts privacy, security, centralization, transaction
> throughput and other metrics. 2MB seems to be a Least Common Denominator
> on an increase.
>
> Costs: requires a hard fork. requires another hard fork down the road.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--001a1135f1a61606d5051b147052
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">What are you trying to do? Break the ice with a hard fork =
so that later it becomes easier to do so, with people more complacent towar=
ds it? There are many solutions to the scaling problem that do not require =
a hard fork and are quite simple to implement actually, and don't come =
with the complications involved with a hard fork. I'm not a reputable d=
eveloper on this list, so my opinion probably doesn't matter much, but =
I watched and analyzed this situation closely and I don't like this ide=
a.<br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fr=
i, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev <span dir=3D"ltr">&=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div>Opening a mailing list thread o=
n this BIP:</div><div><br></div>BIP PR:=C2=A0<a href=3D"https://github.com/=
bitcoin/bips/pull/173" target=3D"_blank">https://github.com/bitcoin/bips/pu=
ll/173</a><div>Code PR:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/=
pull/6451" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/6451</=
a></div><div><br></div><div>The general intent of this BIP is as a minimum =
viable alternative plan to my preferred proposal (BIP 100).</div><div><br><=
/div><div>If agreement is not reached on a more comprehensive solution, the=
n this solution is at least available and a known quantity.=C2=A0 A good ba=
ckup plan.</div><div><br></div><div>Benefits: =C2=A0conservative increase. =
=C2=A0proves network can upgrade. =C2=A0permits some added growth, while th=
e community & market gathers data on how an increased block size impact=
s privacy, security, centralization, transaction throughput and other metri=
cs. =C2=A02MB seems to be a Least Common Denominator on an increase.</div><=
div><br></div><div>Costs: =C2=A0requires a hard fork. =C2=A0requires anothe=
r hard fork down the road.</div><div><br></div><div><br></div></div>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">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>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</d=
iv>
</div>
--001a1135f1a61606d5051b147052--
|
