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