MIME-Version: 1.0
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
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 0.8.1 ideas
Precedence: list

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