summaryrefslogtreecommitdiff
path: root/b6/9d0a5bbb0052b6df74493b3a313c04ee0c4cfb
blob: f29a15d771b7d91fcedfab23652141dc158f9af4 (plain)
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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1YyJZZ-0000gv-Nk
	for bitcoin-development@lists.sourceforge.net;
	Fri, 29 May 2015 12:39:37 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.181 as permitted sender)
	client-ip=209.85.217.181; envelope-from=gavinandresen@gmail.com;
	helo=mail-lb0-f181.google.com; 
Received: from mail-lb0-f181.google.com ([209.85.217.181])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YyJZY-0007zE-Ln
	for bitcoin-development@lists.sourceforge.net;
	Fri, 29 May 2015 12:39:37 +0000
Received: by lbbqq2 with SMTP id qq2so47535681lbb.3
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 29 May 2015 05:39:30 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.6.196 with SMTP id d4mr7802254laa.40.1432903170271; Fri,
	29 May 2015 05:39:30 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Fri, 29 May 2015 05:39:30 -0700 (PDT)
In-Reply-To: <CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
	<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
	<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
	<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
	<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
	<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
	<CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
	<CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
Date: Fri, 29 May 2015 08:39:30 -0400
Message-ID: <CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=089e0141a718763318051737c480
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YyJZY-0007zE-Ln
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 29 May 2015 12:39:37 -0000

--089e0141a718763318051737c480
Content-Type: text/plain; charset=UTF-8

What do other people think?


If we can't come to an agreement soon, then I'll ask for help
reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
big increase now that grows over time so we may never have to go through
all this rancor and debate again.

I'll then ask for help lobbying the merchant services and exchanges and
hosted wallet companies and other bitcoind-using-infrastructure companies
(and anybody who agrees with me that we need bigger blocks sooner rather
than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
are running it. We'll be able to see uptake on the network by monitoring
client versions.

Perhaps by the time that happens there will be consensus bigger blocks are
needed sooner rather than later; if so, great! The early deployment will
just serve as early testing, and all of the software already deployed will
ready for bigger blocks.

But if there is still no consensus among developers but the "bigger blocks
now" movement is successful, I'll ask for help getting big miners to do the
same, and use the soft-fork block version voting mechanism to (hopefully)
get a majority and then a super-majority willing to produce bigger blocks.
The purpose of that process is to prove to any doubters that they'd better
start supporting bigger blocks or they'll be left behind, and to give them
a chance to upgrade before that happens.


Because if we can't come to consensus here, the ultimate authority for
determining consensus is what code the majority of merchants and exchanges
and miners are running.


-- 
--
Gavin Andresen

--089e0141a718763318051737c480
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">What do other people think?<div><br></div><div><br></div><=
div>If we can&#39;t come to an agreement soon, then I&#39;ll ask for help r=
eviewing/submitting patches to Mike&#39;s Bitcoin-Xt project that implement=
 a big increase now that grows over time so we may never have to go through=
 all this rancor and debate again.</div><div><br></div><div>I&#39;ll then a=
sk for help lobbying the merchant services and exchanges and hosted wallet =
companies and other bitcoind-using-infrastructure companies (and anybody wh=
o agrees with me that we need bigger blocks sooner rather than later) to ru=
n Bitcoin-Xt instead of Bitcoin Core, and state that they are running it. W=
e&#39;ll be able to see uptake on the network by monitoring client versions=
.</div><div><br></div><div>Perhaps by the time that happens there will be c=
onsensus bigger blocks are needed sooner rather than later; if so, great! T=
he early deployment will just serve as early testing, and all of the softwa=
re already deployed will ready for bigger blocks.</div><div><br></div><div>=
But if there is still no consensus among developers but the &quot;bigger bl=
ocks now&quot; movement is successful, I&#39;ll ask for help getting big mi=
ners to do the same, and use the soft-fork block version voting mechanism t=
o (hopefully) get a majority and then a super-majority willing to produce b=
igger blocks. The purpose of that process is to prove to any doubters that =
they&#39;d better start supporting bigger blocks or they&#39;ll be left beh=
ind, and to give them a chance to upgrade before that happens.</div><div><b=
r></div><div><br></div><div>Because if we can&#39;t come to consensus here,=
 the ultimate authority for determining consensus is what code the majority=
 of merchants and exchanges and miners are running.</div><div class=3D"gmai=
l_extra"><div><br></div><div><br></div>-- <br><div class=3D"gmail_signature=
">--<br>Gavin Andresen<br></div>
</div></div>

--089e0141a718763318051737c480--