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
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mark@monetize.io>) id 1UFpms-0000S5-Tc
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 17:48:26 +0000
Received: from mail-wg0-f42.google.com ([74.125.82.42])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UFpmn-0006aN-84
for bitcoin-development@lists.sourceforge.net;
Wed, 13 Mar 2013 17:48:26 +0000
Received: by mail-wg0-f42.google.com with SMTP id 12so209806wgh.5
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Mar 2013 10:48:15 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=google.com; s=20120113;
h=mime-version:x-received:x-originating-ip:in-reply-to:references
:date:message-id:subject:from:to:cc:content-type:x-gm-message-state;
bh=riSUtqRPYiaEQ97yEweN6uSZUq72Xdu5JRiFLxL83JM=;
b=iVmKj3GPASD8UJmHmDoQXom2s2hnu3fEILhSKpA5QWSu+R79sdyRQ29i0b3hL9Tf7u
GmmZwo7pYconK0BTfMP4VSSU8WFaMn7mr5lHtuzR4OCKlAohm9exR96LPEkkN64Aa7a6
e1emehlaplYE3IczkPRVXw3700pZV6LB43Q57Tb/RNo8+og0+PFsPn/VuKPDmVPIGdj4
21TsQj06asUoVKJgc/Udn+pwFkvsmxQN6/7Bcepy8UjCjYvULaqGxNuMFihzjCnRe4H/
uG02zQmEzp1gq1EP1p92Iutbx58FHZxEO3QplhgEjE3q40De1BSte+6kE3MuguCc65jJ
uq/w==
MIME-Version: 1.0
X-Received: by 10.180.73.212 with SMTP id n20mr28686321wiv.11.1363196489164;
Wed, 13 Mar 2013 10:41:29 -0700 (PDT)
Received: by 10.194.30.38 with HTTP; Wed, 13 Mar 2013 10:41:29 -0700 (PDT)
X-Originating-IP: [128.102.238.116]
In-Reply-To: <201303131256.30144.luke@dashjr.org>
References: <201303131256.30144.luke@dashjr.org>
Date: Wed, 13 Mar 2013 10:41:29 -0700
Message-ID: <CACh7GpE09hqCPL6rtdC6EZzohM5QHb+0SdFoD8MzPSqf7=6hOA@mail.gmail.com>
From: Mark Friedenbach <mark@monetize.io>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=f46d0438ee617f16a004d7d1eaab
X-Gm-Message-State: ALoCoQkNIEcZaQR5NypTpEMx0u+fe5VztxWXSroux8skMLzdhQ73Q4ZJCAQFILK6FJxNGkTNMS2z
X-Spam-Score: 1.0 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
X-Headers-End: 1UFpmn-0006aN-84
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0.8.1 ideas
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: Wed, 13 Mar 2013 17:48:27 -0000
--f46d0438ee617f16a004d7d1eaab
Content-Type: text/plain; charset=UTF-8
I'm not sure I understand the need for hard forks. We can get through this
crisis by mining pool collusion to prevent forking blocks until there is
widespread adoption of patched clients.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever
number is required to make sure that this problem never shows up again at
the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).
2) Patch all branches to not *generate* blocks which trigger the lock count
limit. A larger block would still be accepted as valid, however, if it is
on the longest chain.
3) Simultaneously, provide an additional non-standard patch to mining pool
operators (>>50% network hash) *rejecting* blocks that trigger the lock
count limit. This keeps miners in collusion with each other to stay on a
'compatibility fork'.
4) At some point in the future once we've crossed an acceptable adoption
threshold, the miners remove the above patch in a coordinated way.
Does that not get us past this crisis without a hard-fork?
Mark
(Aside: I'm for BOTH raising the block-size limit and off-chain
transactions, but like it or not there are political sides to that debate
and we should keep politics out of crisis management.)
On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr <luke@dashjr.org> wrote:
> Here's a simple proposal to start discussion from...
>
> BEFORE block 262144:
> - Never make a block that, combined with the previous 4 blocks, results in
> over 4500 transaction modifications.
> - Reject any block that includes more than 4500 transaction modifications
> on
> its own (slight soft-fork)
> - (these rules should make older clients safe under most circumstances)
>
> FROM block 262144 to block 393216 (hard fork #1):
> - Never make, and reject any block that includes more than 24391
> transaction
> modifications on its own (this *should* be equivalent to 1 MB)
> - (this rules can make older client backports safe unless a reorg is more
> than
> 6 blocks deep)
>
> FROM block 393216 onward (hard fork #2):
> - Never make, and reject any block that includes more than 48781
> transaction
> modifications on its own (this *should* be equivalent to 2 MB)
> - Accept blocks up to 2 MB in data size
> - Discontinue support for clients prior to 0.8.1
>
> I intentionally set the block numbers conservatively to try to account for
> the
> yet-unseen ASIC upgrade.
>
> Thoughts?
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d0438ee617f16a004d7d1eaab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>I'm not sure I understand the need for hard =
forks. We can get through this crisis by mining pool collusion to prevent f=
orking blocks until there is widespread adoption of patched clients.<br><br=
>
Proposal:<br><br>1) Patch the pre-0.8 branches to support an increased lock=
count, whatever number is required to make sure that this problem never sh=
ows up again at the current block size (I defer to Luke-Jr and gmaxwell'=
;s numbers on this).<br>
<br>2) Patch all branches to not *generate* blocks which trigger the lock c=
ount limit. A larger block would still be accepted as valid, however, if it=
is on the longest chain.<br><br>3) Simultaneously, provide an additional n=
on-standard patch to mining pool operators (>>50% network hash) *reje=
cting* blocks that trigger the lock count limit. This keeps miners in collu=
sion with each other to stay on a 'compatibility fork'.<br>
<br>4) At some point in the future once we've crossed an acceptable ado=
ption threshold, the miners remove the above patch in a coordinated way.<br=
><br></div>Does that not get us past this crisis without a hard-fork?<br>
<br></div>Mark<br><br>(Aside: I'm for BOTH raising the block-size limit=
and off-chain transactions, but like it or not there are political sides t=
o that debate and we should keep politics out of crisis management.)<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed,=
Mar 13, 2013 at 5:56 AM, Luke-Jr <span dir=3D"ltr"><<a href=3D"mailto:l=
uke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Here's a simple proposal to start discussion from...<br>
<br>
BEFORE block 262144:<br>
- Never make a block that, combined with the previous 4 blocks, results in<=
br>
over 4500 transaction modifications.<br>
- Reject any block that includes more than 4500 transaction modifications o=
n<br>
its own (slight soft-fork)<br>
- (these rules should make older clients safe under most circumstances)<br>
<br>
FROM block 262144 to block 393216 (hard fork #1):<br>
- Never make, and reject any block that includes more than 24391 transactio=
n<br>
modifications on its own (this *should* be equivalent to 1 MB)<br>
- (this rules can make older client backports safe unless a reorg is more t=
han<br>
6 blocks deep)<br>
<br>
FROM block 393216 onward (hard fork #2):<br>
- Never make, and reject any block that includes more than 48781 transactio=
n<br>
modifications on its own (this *should* be equivalent to 2 MB)<br>
- Accept blocks up to 2 MB in data size<br>
- Discontinue support for clients prior to 0.8.1<br>
<br>
I intentionally set the block numbers conservatively to try to account for =
the<br>
yet-unseen ASIC upgrade.<br>
<br>
Thoughts?<br>
<br>
---------------------------------------------------------------------------=
---<br>
Everyone hates slow websites. So do we.<br>
Make your web apps faster with AppDynamics<br>
Download AppDynamics Lite for free today:<br>
<a href=3D"http://p.sf.net/sfu/appdyn_d2d_mar" target=3D"_blank">http://p.s=
f.net/sfu/appdyn_d2d_mar</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</blockquote></div><br></div>
--f46d0438ee617f16a004d7d1eaab--
|
