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 ) 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 ; 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: From: Mark Friedenbach To: Luke-Jr 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" 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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.
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 sh= ows 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 c= ount limit. A larger block would still be accepted as valid, however, if it= is on the longest chain.

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'.

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.
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 t= o 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<= br> over 4500 transaction modifications.
- Reject any block that includes more than 4500 transaction modifications o= n
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 transactio= n
modifications on its own (this *should* be equivalent to 1 MB)
- (this rules can make older client backports safe unless a reorg is more t= han
6 blocks deep)

FROM block 393216 onward (hard fork #2):
- Never make, and reject any block that includes more than 48781 transactio= n
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.s= f.net/sfu/appdyn_d2d_mar
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--f46d0438ee617f16a004d7d1eaab--