From mboxrd@z Thu Jan  1 00:00:00 1970
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&#39;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&#39=
;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 (&gt;&gt;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 &#39;compatibility fork&#39;.<br>
<br>4) At some point in the future once we&#39;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&#39;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">&lt;<a href=3D"mailto:l=
uke@dashjr.org" target=3D"_blank">luke@dashjr.org</a>&gt;</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&#39;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--