path: root/09/bbb582c952bf57959148fd25f9c2e777e21d01

Return-Path: <realemilengler@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 02EB4D8B
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 14:37:06 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com
	[209.85.160.179])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E470E196
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 14:37:04 +0000 (UTC)
Received: by mail-qt1-f179.google.com with SMTP id p20so6706394qtq.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 08 Nov 2019 06:37:04 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=fAzs9KLklXBbBXC3npQ3wSmDQXOgRUnQSt/x26hS2n8=;
	b=R5MRqOhQhy7TwSbVsVOveqdEPPgCt18PqQY6Qhtir3XzAcCtUsJt6UstZ29hMOlid0
	yqut4QxXKU7qURYZgGFzZrOfq+DnIr41w2/t4347rvLGQyjx1vmNuzBHqG23TRrbwhFv
	tsl4on/56ieoF09KvOAoCsoVGWKByLfClS8FRY7dV6Xzd0sK+eTNeJu6rQJqGYu5eM4l
	NCXMNivwhW/VwW/jvm+5E7Ft2FWCBekNe2n2VSQcWRBq8WgXwuGvpvqlJZqeffbdEHw7
	FdwSm6XMT42p11BecnJjqihl62hhgCB3nues0NqPfON4fpOfNVtuC+5qIrB5PtGHLsK0
	cRSg==
X-Gm-Message-State: APjAAAUguRmu2zqpiS9bCb/t0cGIzO/QBUOeH8x2BdCIso97s0sDj0Di
	adyljngszohydg/IvXgzsG7E4qRMAbjr5Q==
X-Google-Smtp-Source: APXvYqy6CsBpqiOiiyCSGgMJLCZvOh/tEyFZuWI8I1/8kM9Hib4noc87/ifoleBj3LKBy3wIxeA/7w==
X-Received: by 2002:ac8:2dbd:: with SMTP id p58mr10765160qta.281.1573223823948;
	Fri, 08 Nov 2019 06:37:03 -0800 (PST)
Received: from mail-qt1-f182.google.com (mail-qt1-f182.google.com.
	[209.85.160.182]) by smtp.gmail.com with ESMTPSA id
	y24sm2720344qki.104.2019.11.08.06.37.03
	for <bitcoin-dev@lists.linuxfoundation.org>
	(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
	Fri, 08 Nov 2019 06:37:03 -0800 (PST)
Received: by mail-qt1-f182.google.com with SMTP id p20so6706360qtq.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 08 Nov 2019 06:37:03 -0800 (PST)
X-Received: by 2002:ac8:2dfd:: with SMTP id q58mr9324500qta.283.1573223823481; 
	Fri, 08 Nov 2019 06:37:03 -0800 (PST)
MIME-Version: 1.0
References: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
In-Reply-To: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
From: Emil Engler <me@emilengler.com>
Date: Fri, 8 Nov 2019 15:36:52 +0100
X-Gmail-Original-Message-ID: <CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com>
Message-ID: <CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, 
	Trevor Groves <gurvy51@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000269ef70596d6b7f6"
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 08 Nov 2019 14:44:12 +0000
Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Nov 2019 14:37:06 -0000

--000000000000269ef70596d6b7f6
Content-Type: text/plain; charset="UTF-8"

NACK!
1. We have Lightning and SegWit so thankfully we do not need to deal with
blocksizes anymore really.
2. What if a reorg happens? Then it could generate huge problems at the
validation.

Correct me if I understood it wrong please.

Greetings,
Emil Engler

Trevor Groves via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
schrieb am Fr. 8. Nov. 2019 um 15:26:

> Dynamic MaxBlockSize  - 3 Byte Solution
> "DMBS"
>
> If
> (Last TOTAL Block Trans fees)  >  (AVG (Last 100 Blocks Trans Fees))
> AND
> current MaxBlockSize  => 0.99 MB
> AND
> MaxBlockSize has not changed in 10 Blocks
> ** see error catch below
> Then
> ON (Current Block #  + 9)  Set MaxBlockSize  = (MaxBlockSize x 1.1)
> ELSE
> AT (Current Block #  + 9)  Set MaxBlockSize  = (MaxBlockSize  / 1.1)
> ELSEIF
> (current MaxBlockSize  =< 0.99  or current MaxBlockSize > 6553.5 MB)
> Null (no action taken)
> **where 9 above represents the ActivateONBlock (software side) Variable
>  -------------
> We add this 3 Byte Variable Factor to the white space in the Current Block.
>
> eg.  this 3 byte HEX    19000A
> the first bit "1"  can be 1,2 or 0
> 1  =  increase future block (9 blocks ahead)
> 2  decrease future block  (9 blocks ahead)
> 0    No Action (rules evaluate to null)
> **where 9 above represents the ActivateONBlock (software side) Variable
> --------------
> The Second bit is a Global Variable "9" represents a countdown to the set
> value action, placed to synchronize network forward  changes in "x" blocks.
> software lowers value if evaluates to True a second time  and so on.
> ("Count down" if you will)
> the last 2 bytes represent  the globally accepted "MaxBlockSize" Variable,
> and is distributed within each block moving forward in this rightmost (2
> byte) factor.  In this case above,
> The variable portion  "000A" (32 Bit value) represents decimal value 10
> being 1.0 MB block.
> the decimal place is Always Assumed, and must be hard coded
> Because this presents a  theoretical  Max limit of "FFFF"  or 6553.5 MB,
> We would
> have to add a last rule "only as a error catch"
>  ** AND IF MaxBlockSize < 6553.5
> ---
> Increasing and decreasing
> On Every Block mined or distributed, the software can run the above rule
> set, Change the Variable and Distribute the next block " In Synchronized
> fashion". The above rules when combined evaluate to a YES or NO, This
> translates to a market reflection of increased system pressure or decreased
> market pressure.   I think we can agree, at peak periods the system chokes
> itself off with fees and this is always only temporarily.  So we can have
> the block, analyse system demand dynamically, and adjust on a globally
> agreed rule dynamically by market driven demand.
> Considering the ruleset above also Decreases  the Block ONLY if its
> greater than 0.99mb this brings size back to a competitive state /and size
> once market demand pressures subside, yet achieves the smallest market
> feasible block size while also maintaining all current rule sets.
>  An attacker would have to affect all block fees over the last 16 hours
> worth of transactions to affect a 10% max block size increase but then only
> after waiting 1.5 hours, so long as nothing has changed in the last 1.5
> hours and only for a limited amount of time. This approach also limits
> bloat. This safety block window of 9 blocks provides a look forward and
> look behind value, in turn provides the network time to synchronize.
> 10 block sync window.  This, by design, also limits changes to one change
> every 3 hours (20 blocks), if there is a market pressure "STATE" occurring.
> My Question to the community is. Will our current Block accommodate the 3
> Byte
> Variable, Is solving the Scaling issue worth using the 3 Bytes of space?
> I believe it is.
> --
> Software,  Will need  to Evaluate MaxBlockSize Variable, and
> ActivateONBlock Variable from the most recent distributed blocks DMBS  3
> byte value.
> Run the rules , get the answer set the now known MaxBlockSize Var and
> Propegate the "DMBS" value.
>
> As capacity limits are breached, I think the majority agree "we need to
> agree".
>
> MaxBlockSize would provide a suitable middle ground and address concerns
> in a dynamic fashion, without compromising  or changing  existing
> security.
>  Examples reflected in the blockchain 19000A   rules has evaluates to
> true, increase expected in 9 blocks.1.0mb increases to 1.1mb
> if true for 9 more blocks  MaxBlockSize Var becomes  18000A..
> 17000A..,16000A ..and so on if  still true at 10000A var written becomes
> 00000B when read from left to right,  0-no change, in 0 blocks current "
> DMBS" value 000B or 1.1MB  and stays that way  00000B until MaxBlockSize
> evaluates to "True" under a market pressure/ relief situation.
> I hope this makes sense, I would appreciate some feedback.
> TG
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000269ef70596d6b7f6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">NACK!</div></div><div dir=3D"auto">1. We have Lightn=
ing and SegWit so thankfully we do not need to deal with blocksizes anymore=
 really.</div><div dir=3D"auto">2. What if a reorg happens? Then it could g=
enerate huge problems at the validation.</div><div dir=3D"auto"><br></div><=
div dir=3D"auto">Correct me if I understood it wrong please.</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Greetings,</div><div dir=3D"auto">Emi=
l Engler</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D=
"gmail_attr">Trevor Groves via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; =
schrieb am Fr. 8. Nov. 2019 um 15:26:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr">Dynamic MaxBlockSize =C2=A0- 3 Byte Solution<br>&quot;D=
MBS&quot;<div><br>If <br>(Last TOTAL Block Trans fees)=C2=A0 &gt; =C2=A0(AV=
G (Last 100 Blocks Trans Fees))<br>AND<br>current MaxBlockSize =C2=A0=3D&gt=
; 0.99 MB =C2=A0<br>AND <br>MaxBlockSize has not changed in 10 Blocks<br>**=
 see error catch below<br>Then =C2=A0<br>ON (Current Block # =C2=A0+ 9) =C2=
=A0Set MaxBlockSize =C2=A0=3D (MaxBlockSize x 1.1)<br>ELSE =C2=A0<br>AT (Cu=
rrent Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlockSize =C2=
=A0/ 1.1)<br>ELSEIF <br>(current MaxBlockSize =C2=A0=3D&lt; 0.99 =C2=A0or c=
urrent MaxBlockSize &gt; 6553.5 MB)<br>Null (no action taken)<br>**where 9 =
above represents the ActivateONBlock (software side) Variable<br>=C2=A0----=
---------<br>We add this 3 Byte Variable Factor to the white space in the C=
urrent Block.<br><br>eg. =C2=A0this 3 byte HEX=C2=A0 =C2=A0 19000A<br>the f=
irst bit &quot;1&quot; =C2=A0can be 1,2 or 0 =C2=A0 =C2=A0<br>1 =C2=A0=3D =
=C2=A0increase future block (9 blocks ahead)<br>2 =C2=A0decrease future blo=
ck =C2=A0(9 blocks ahead)<br>0 =C2=A0 =C2=A0No Action (rules evaluate to nu=
ll)<br>**where 9 above represents the ActivateONBlock (software side) Varia=
ble<br>--------------<br>The Second bit is a Global Variable &quot;9&quot; =
represents a countdown to the set value action, placed to synchronize netwo=
rk forward =C2=A0changes in &quot;x&quot; blocks. software lowers value if =
evaluates to True a second time=C2=A0 and so on.=C2=A0<br>(&quot;Count down=
&quot; if you will)<br>the last 2 bytes represent =C2=A0the globally accept=
ed &quot;MaxBlockSize&quot; Variable, and is distributed within each block =
moving forward in this rightmost (2 byte) factor.=C2=A0 In this case above,=
<div>The variable portion =C2=A0&quot;000A&quot; (32 Bit value) represents =
decimal value 10 being 1.0 MB block.<br>the decimal place is Always Assumed=
, and must be hard coded <br>Because this presents a =C2=A0theoretical =C2=
=A0Max limit of &quot;FFFF&quot; =C2=A0or 6553.5 MB, We would <br>have to a=
dd a last rule &quot;only as a error catch&quot;<br>=C2=A0** AND IF MaxBloc=
kSize &lt; 6553.5 <br>---<br>Increasing and decreasing<br>On Every Block mi=
ned or distributed, the software can run the above rule set, Change the Var=
iable and Distribute the next block &quot; In Synchronized fashion&quot;. T=
he above rules when combined evaluate to a YES or NO, This translates to a =
market reflection of increased system pressure or decreased market pressure=
. =C2=A0 I think we can agree, at peak periods the system chokes itself off=
 with fees and this is always only temporarily.=C2=A0 So we can have the bl=
ock, analyse system demand dynamically, and adjust on a globally agreed rul=
e dynamically by market driven demand.<div>Considering the ruleset above al=
so Decreases =C2=A0the Block ONLY if its greater than 0.99mb this brings si=
ze back to a competitive state /and size once market demand pressures subsi=
de, yet achieves the smallest market feasible block size while also maintai=
ning all current rule sets.</div><div>=C2=A0An attacker would have to affec=
t all block fees over the last 16 hours worth of transactions to affect a 1=
0% max block size increase but then only after waiting 1.5 hours, so long a=
s nothing has changed in the last 1.5 hours and only for a limited amount o=
f time. This approach also limits bloat. This safety block window of 9 bloc=
ks provides a look forward and look behind value, in turn provides the netw=
ork time to synchronize. <br>10 block sync window.=C2=A0 This, by design, a=
lso limits changes to one change=C2=A0 every 3 hours (20 blocks), if there =
is a market pressure &quot;STATE&quot; occurring.<br>My Question to the com=
munity is. Will our current Block accommodate the 3 Byte <br>Variable, Is s=
olving the Scaling issue worth using the 3 Bytes of space? =C2=A0<br>I beli=
eve it is. =C2=A0<br>--<br>Software, =C2=A0Will need =C2=A0to Evaluate MaxB=
lockSize Variable, and ActivateONBlock Variable from the most recent distri=
buted blocks DMBS =C2=A03 byte value. <br>Run the rules , get the answer se=
t the now known MaxBlockSize Var and Propegate the &quot;DMBS&quot; value. =
<br><br>As capacity limits are breached, I think the majority agree &quot;w=
e need to agree&quot;. =C2=A0</div><div><br>MaxBlockSize would provide a su=
itable middle ground and address concerns in a dynamic fashion, without com=
promising =C2=A0or changing =C2=A0existing security.=C2=A0 =C2=A0<br></div>=
</div><div>=C2=A0Examples reflected in the blockchain 19000A=C2=A0 =C2=A0ru=
les has evaluates to=C2=A0 true, increase expected in 9 blocks.1.0mb increa=
ses to 1.1mb<br></div><div>if true for 9 more blocks=C2=A0

MaxBlockSize

 Var becomes=C2=A0 18000A.. 17000A..,16000A ..and so on if=C2=A0 still true=
 at 10000A var written becomes=C2=A0</div><div>00000B when read from left t=
o right,=C2=A0 0-no change, in 0 blocks current &quot; DMBS&quot; value 000=
B or 1.1MB=C2=A0

and stays that way=C2=A0

00000B

 until MaxBlockSize=C2=A0 evaluates to &quot;True&quot; under a market pres=
sure/ relief situation.=C2=A0</div><div>I hope this makes sense, I would ap=
preciate some feedback.=C2=A0</div></div><div>TG</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>

--000000000000269ef70596d6b7f6--