path: root/68/d4411a04f71e14f0373dda2475d94197469765

Return-Path: <aaldave@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 15F6BDE1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 17:04:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com
	[209.85.128.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 57D378CA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  8 Nov 2019 17:04:25 +0000 (UTC)
Received: by mail-wm1-f51.google.com with SMTP id l17so6112885wmh.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 08 Nov 2019 09:04:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=content-transfer-encoding:from:mime-version:subject:date:message-id
	:references:cc:in-reply-to:to;
	bh=Pmj9/AigKdc2+MihmB2Yl2b/Z48R8bvFH7NMBs+J0bg=;
	b=QeG3nW9O1XAyIzcnWIaun3YnKlI3oDX3v9n7/uv308ktVKxMCvwjOzhHfejjGj3Lum
	N04cFxxXvMWiXUbE978266X4itiVO3z9YRQeYAKBXEJtahT0vEnJ8hc/RUKnVVsWebij
	kSgIEbO0lOaBvyY6HX4F9vqJp+sFOcdx3IDkxUUWmAoW5DAZ80yoTkl+EUR0zpDYXS24
	F+QfwlS7tC1htcwm3BG4czTQ7AJ/Z2hZcpLLk87KQoqjt/MRRInztfuVo1f1WsPl2K3l
	FHqfG2gQbpQOrkAY892RM5ejUHm2kfa3357rRNG6lfF9XXJBH24ipA2tGIm000wAoB25
	yaCA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:content-transfer-encoding:from:mime-version
	:subject:date:message-id:references:cc:in-reply-to:to;
	bh=Pmj9/AigKdc2+MihmB2Yl2b/Z48R8bvFH7NMBs+J0bg=;
	b=a+C4uA5m3E0bdktet+2strHQWXBbSYz1iBVA6QNa8/F436KU9dej72fKPAZ8v15hTq
	JhxamzavDyk1Fv54IgsxWZK52QD13RDP2XBMGKzjSrj2loy3i1t1X8ZbG7OxcEQ3NG39
	NdziGiPFipguTYGfglTlP78PnxWBwepYuvBYmjdO573G4gru5KgcWSi+Ynw+2PBZ2QoB
	L480EVRdpOYfNNxKVsjN74a7VoDx9a3p9oGBPwDTreQ5LUT9A7vJdAiVykZprFB8LWop
	1NowYFQZzMbOpB8HqXSlP+0TCxpNvkcFEOjSllfHkXIbwx0CeaNyAJ1TTe4sB5tVvcfl
	bWew==
X-Gm-Message-State: APjAAAX16v0VPk43Fu/a1RetYR7yBBAOZKo42YjITw8uHuvwEh3vCh3z
	tK0KfTjrfaw/yPxyA6bnHd4=
X-Google-Smtp-Source: APXvYqzOL0FQvuJH1rr0oqI5PmdoafaAsuNoPzMIIJgM06HwOnkSRebX65bZiel2k2NkczUXuK5cCw==
X-Received: by 2002:a1c:7c18:: with SMTP id x24mr9438095wmc.130.1573232663889; 
	Fri, 08 Nov 2019 09:04:23 -0800 (PST)
Received: from [172.20.10.3] (114.red-176-82-68.dynamicip.rima-tde.net.
	[176.82.68.114]) by smtp.gmail.com with ESMTPSA id
	n13sm5795567wmi.25.2019.11.08.09.04.21
	(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
	Fri, 08 Nov 2019 09:04:22 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-B42D1DA3-5568-4785-8C63-544616EEC85C
Content-Transfer-Encoding: 7bit
From: Alberto Aldave <aaldave@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Fri, 8 Nov 2019 18:04:20 +0100
Message-Id: <8C273BE4-CF45-46D5-97F6-7E7AD0C9D365@gmail.com>
References: <gL39Si8vPw6SjouvjkN016eQD9ZybpO1Yf2kvaF11SKU3ECl9JFBr_RXR_BVDiqEu3yVnwKzgxlathhoMg5khGQQbiM0ExasjQQ3QYkOugw=@protonmail.com>
In-Reply-To: <gL39Si8vPw6SjouvjkN016eQD9ZybpO1Yf2kvaF11SKU3ECl9JFBr_RXR_BVDiqEu3yVnwKzgxlathhoMg5khGQQbiM0ExasjQQ3QYkOugw=@protonmail.com>
To: =?utf-8?Q?Joachim_Str=C3=B6mbergson?= <joachimstr@protonmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: iPad Mail (17A860)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	MIME_QP_LONG_LINE, 
	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 17:06:03 +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 17:04:27 -0000


--Apple-Mail-B42D1DA3-5568-4785-8C63-544616EEC85C
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

NACK

1.- At some point in time, fees will need to be the the main part of the rew=
ard of miners, so, I do not see any need to lower them. If we keep them fore=
ver low, the network will be less and less secure because of the halvings.
2.- I think this change involves a Hard Fork (please correct me if I am wron=
g). In my opinion, the risk of a HF is not worth it.
3.- And more important for me, If blocks get bigger and bigger it would hurt=
 decentralization which is absolutely key for Bitcoin to be valuable.

Alberto


> El 8 nov 2019, a las 16:54, Joachim Str=C3=B6mbergson via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org> escribi=C3=B3:
>=20
> =EF=BB=BF
> While I agree on NACKing the proposal as it does not add anything new and f=
undamentally misunderstands what scaling is (or is not in this case), I disa=
gree with the claim that we do not need to deal with block size issue in the=
 future any more. Segwit increased our possibilities on how to use the space=
 more efficiently, but so far it did not completely. It's yet to be seen if a=
dvanced offchain constructions such as channel factories are enough. At this=
 moment to claim that would be very bold and hardly justified.
>=20
>=20
> Sent with ProtonMail Secure Email.
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>> On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev <bitcoin=
-dev@lists.linuxfoundation.org> wrote:
>>=20
>> 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 v=
alidation.
>>=20
>> Correct me if I understood it wrong please.
>>=20
>> Greetings,
>> Emil Engler
>>=20
>> Trevor Groves via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> sch=
rieb am Fr. 8. Nov. 2019 um 15:26:
>>> Dynamic MaxBlockSize  - 3 Byte Solution
>>> "DMBS"
>>>=20
>>> If=20
>>> (Last TOTAL Block Trans fees)  >  (AVG (Last 100 Blocks Trans Fees))
>>> AND
>>> current MaxBlockSize  =3D> 0.99 MB =20
>>> AND=20
>>> MaxBlockSize has not changed in 10 Blocks
>>> ** see error catch below
>>> Then =20
>>> ON (Current Block #  + 9)  Set MaxBlockSize  =3D (MaxBlockSize x 1.1)
>>> ELSE =20
>>> AT (Current Block #  + 9)  Set MaxBlockSize  =3D (MaxBlockSize  / 1.1)
>>> ELSEIF=20
>>> (current MaxBlockSize  =3D< 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 Blo=
ck.
>>>=20
>>> eg.  this 3 byte HEX    19000A
>>> the first bit "1"  can be 1,2 or 0   =20
>>> 1  =3D  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 se=
t value action, placed to synchronize network forward  changes in "x" blocks=
. software lowers value if evaluates to True a second time  and so on.=20
>>> ("Count down" if you will)
>>> the last 2 bytes represent  the globally accepted "MaxBlockSize" Variabl=
e, and is distributed within each block moving forward in this rightmost (2 b=
yte) factor.  In this case above,
>>> The variable portion  "000A" (32 Bit value) represents decimal value 10 b=
eing 1.0 MB block.
>>> the decimal place is Always Assumed, and must be hard coded=20
>>> Because this presents a  theoretical  Max limit of "FFFF"  or 6553.5 MB,=
 We would=20
>>> have to add a last rule "only as a error catch"
>>>  ** AND IF MaxBlockSize < 6553.5=20
>>> ---
>>> 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 fa=
shion". The above rules when combined evaluate to a YES or NO, This translat=
es to a market reflection of increased system pressure or decreased market p=
ressure.   I think we can agree, at peak periods the system chokes itself of=
f with fees and this is always only temporarily.  So we can have the block, a=
nalyse system demand dynamically, and adjust on a globally agreed rule dynam=
ically by market driven demand.
>>> Considering the ruleset above also Decreases  the Block ONLY if its grea=
ter than 0.99mb this brings size back to a competitive state /and size once m=
arket demand pressures subside, yet achieves the smallest market feasible bl=
ock size while also maintaining all current rule sets.
>>>  An attacker would have to affect all block fees over the last 16 hours w=
orth of transactions to affect a 10% max block size increase but then only a=
fter 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. Thi=
s safety block window of 9 blocks provides a look forward and look behind va=
lue, in turn provides the network time to synchronize.=20
>>> 10 block sync window.  This, by design, also limits changes to one chang=
e  every 3 hours (20 blocks), if there is a market pressure "STATE" occurrin=
g.
>>> My Question to the community is. Will our current Block accommodate the 3=
 Byte=20
>>> Variable, Is solving the Scaling issue worth using the 3 Bytes of space?=
 =20
>>> I believe it is. =20
>>> --
>>> Software,  Will need  to Evaluate MaxBlockSize Variable, and ActivateONB=
lock Variable from the most recent distributed blocks DMBS  3 byte value.=20=

>>> Run the rules , get the answer set the now known MaxBlockSize Var and Pr=
opegate the "DMBS" value.=20
>>>=20
>>> As capacity limits are breached, I think the majority agree "we need to a=
gree". =20
>>>=20
>>> MaxBlockSize would provide a suitable middle ground and address concerns=
 in a dynamic fashion, without compromising  or changing  existing security.=
  =20
>>>  Examples reflected in the blockchain 19000A   rules has evaluates to  t=
rue, increase expected in 9 blocks.1.0mb increases to 1.1mb
>>> if true for 9 more blocks  MaxBlockSize Var becomes  18000A.. 17000A..,1=
6000A ..and so on if  still true at 10000A var written becomes=20
>>> 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  e=
valuates to "True" under a market pressure/ relief situation.=20
>>> I hope this makes sense, I would appreciate some feedback.=20
>>> TG
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-B42D1DA3-5568-4785-8C63-544616EEC85C
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto">NACK<div><br></div><div>1.- At some point i=
n time, fees will need to be the the main part of the reward of miners, so, I=
 do not see any need to lower them. If we keep them forever low, the network=
 will be less and less secure because of the halvings.</div><div>2.- I think=
 this change involves a Hard Fork (please correct me if I am wrong). In my o=
pinion, the risk of a HF is not worth it.</div><div>3.- And more important f=
or me, If blocks get bigger and bigger it would hurt decentralization which i=
s absolutely key for Bitcoin to be valuable.</div><div><br><div dir=3D"ltr">=
Alberto<div><br></div></div><div dir=3D"ltr"><br><blockquote type=3D"cite">E=
l 8 nov 2019, a las 16:54, Joachim Str=C3=B6mbergson via bitcoin-dev &lt;bit=
coin-dev@lists.linuxfoundation.org&gt; escribi=C3=B3:<br><br></blockquote></=
div><blockquote type=3D"cite"><div dir=3D"ltr">=EF=BB=BF<div>While I agree o=
n NACKing the proposal as it does not add anything new and fundamentally mis=
understands what scaling is (or is not in this case), I disagree with the cl=
aim that we do not need to deal with block size issue in the future any more=
. Segwit increased our possibilities on how to use the space more efficientl=
y, but so far it did not completely. It's yet to be seen if advanced offchai=
n constructions such as channel factories are enough. At this moment to clai=
m that would be very bold and hardly justified.<br></div><div><br></div><div=
 class=3D"protonmail_signature_block"><div class=3D"protonmail_signature_blo=
ck-user protonmail_signature_block-empty"><br></div><div class=3D"protonmail=
_signature_block-proton">Sent with <a href=3D"https://protonmail.com" target=
=3D"_blank">ProtonMail</a> Secure Email.<br></div></div><div><br></div><div>=
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Mes=
sage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90<br></di=
v><div> On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev &lt=
;bitcoin-dev@lists.linuxfoundation.org&gt; wrote:<br></div><div> <br></div><=
blockquote class=3D"protonmail_quote" type=3D"cite"><div><div dir=3D"auto">N=
ACK!<br></div></div><div dir=3D"auto">1. We have Lightning and SegWit so tha=
nkfully we do not need to deal with blocksizes anymore really.<br></div><div=
 dir=3D"auto">2. What if a reorg happens? Then it could generate huge proble=
ms at the validation.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Correct me if I understood it wrong please.<br></div><div dir=3D"auto"><br>=
</div><div dir=3D"auto">Greetings,<br></div><div dir=3D"auto">Emil Engler<br=
></div><div><div><br></div><div class=3D"gmail_quote"><div dir=3D"ltr">Trevo=
r Groves via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; schrieb am Fr. 8. No=
v. 2019 um 15:26:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204=
); border-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>=
Dynamic MaxBlockSize &nbsp;- 3 Byte Solution<br></div><div>"DMBS"<br></div><=
div><div><br></div><div>If <br></div><div>(Last TOTAL Block Trans fees)&nbsp=
; &gt; &nbsp;(AVG (Last 100 Blocks Trans Fees))<br></div><div>AND<br></div><=
div>current MaxBlockSize &nbsp;=3D&gt; 0.99 MB &nbsp;<br></div><div>AND <br>=
</div><div>MaxBlockSize has not changed in 10 Blocks<br></div><div>** see er=
ror catch below<br></div><div>Then &nbsp;<br></div><div>ON (Current Block # &=
nbsp;+ 9) &nbsp;Set MaxBlockSize &nbsp;=3D (MaxBlockSize x 1.1)<br></div><di=
v>ELSE &nbsp;<br></div><div>AT (Current Block # &nbsp;+ 9) &nbsp;Set MaxBloc=
kSize &nbsp;=3D (MaxBlockSize &nbsp;/ 1.1)<br></div><div>ELSEIF <br></div><d=
iv>(current MaxBlockSize &nbsp;=3D&lt; 0.99 &nbsp;or current MaxBlockSize &g=
t; 6553.5 MB)<br></div><div>Null (no action taken)<br></div><div>**where 9 a=
bove represents the ActivateONBlock (software side) Variable<br></div><div>&=
nbsp;-------------<br></div><div>We add this 3 Byte Variable Factor to the w=
hite space in the Current Block.<br></div><div><br></div><div>eg. &nbsp;this=
 3 byte HEX&nbsp; &nbsp; 19000A<br></div><div>the first bit "1" &nbsp;can be=
 1,2 or 0 &nbsp; &nbsp;<br></div><div>1 &nbsp;=3D &nbsp;increase future bloc=
k (9 blocks ahead)<br></div><div>2 &nbsp;decrease future block &nbsp;(9 bloc=
ks ahead)<br></div><div>0 &nbsp; &nbsp;No Action (rules evaluate to null)<br=
></div><div>**where 9 above represents the ActivateONBlock (software side) V=
ariable<br></div><div>--------------<br></div><div>The Second bit is a Globa=
l Variable "9" represents a countdown to the set value action, placed to syn=
chronize network forward &nbsp;changes in "x" blocks. software lowers value i=
f evaluates to True a second time&nbsp; and so on.&nbsp;<br></div><div>("Cou=
nt down" if you will)<br></div><div>the last 2 bytes represent &nbsp;the glo=
bally accepted "MaxBlockSize" Variable, and is distributed within each block=
 moving forward in this rightmost (2 byte) factor.&nbsp; In this case above,=
<br></div><div><div>The variable portion &nbsp;"000A" (32 Bit value) represe=
nts decimal value 10 being 1.0 MB block.<br></div><div>the decimal place is A=
lways Assumed, and must be hard coded <br></div><div>Because this presents a=
 &nbsp;theoretical &nbsp;Max limit of "FFFF" &nbsp;or 6553.5 MB, We would <b=
r></div><div>have to add a last rule "only as a error catch"<br></div><div>&=
nbsp;** AND IF MaxBlockSize &lt; 6553.5 <br></div><div>---<br></div><div>Inc=
reasing and decreasing<br></div><div>On Every Block mined or distributed, th=
e software can run the above rule set, Change the Variable and Distribute th=
e next block " In Synchronized fashion". The above rules when combined evalu=
ate to a YES or NO, This translates to a market reflection of increased syst=
em pressure or decreased market pressure. &nbsp; I think we can agree, at pe=
ak periods the system chokes itself off with fees and this is always only te=
mporarily.&nbsp; So we can have the block, analyse system demand dynamically=
, and adjust on a globally agreed rule dynamically by market driven demand.<=
br></div><div>Considering the ruleset above also Decreases &nbsp;the Block O=
NLY 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 mar=
ket feasible block size while also maintaining all current rule sets.<br></d=
iv><div><div>&nbsp;An attacker would have to affect all block fees over the l=
ast 16 hours worth of transactions to affect a 10% max block size increase b=
ut then only after waiting 1.5 hours, so long as nothing has changed in the l=
ast 1.5 hours and only for a limited amount of time. This approach also limi=
ts bloat. This safety block window of 9 blocks provides a look forward and l=
ook behind value, in turn provides the network time to synchronize. <br></di=
v><div>10 block sync window.&nbsp; This, by design, also limits changes to o=
ne change&nbsp; every 3 hours (20 blocks), if there is a market pressure "ST=
ATE" occurring.<br></div><div>My Question to the community is. Will our curr=
ent Block accommodate the 3 Byte <br></div><div>Variable, Is solving the Sca=
ling issue worth using the 3 Bytes of space? &nbsp;<br></div><div>I believe i=
t is. &nbsp;<br></div><div>--<br></div><div>Software, &nbsp;Will need &nbsp;=
to Evaluate MaxBlockSize Variable, and ActivateONBlock Variable from the mos=
t recent distributed blocks DMBS &nbsp;3 byte value. <br></div><div>Run the r=
ules , get the answer set the now known MaxBlockSize Var and Propegate the "=
DMBS" value. <br></div><div><br></div><div>As capacity limits are breached, I=
 think the majority agree "we need to agree". &nbsp;<br></div></div><div><di=
v><br></div><div>MaxBlockSize would provide a suitable middle ground and add=
ress concerns in a dynamic fashion, without compromising &nbsp;or changing &=
nbsp;existing security.&nbsp; &nbsp;<br></div></div></div><div>&nbsp;Example=
s reflected in the blockchain 19000A&nbsp; &nbsp;rules has evaluates to&nbsp=
; true, increase expected in 9 blocks.1.0mb increases to 1.1mb<br></div><div=
>if true for 9 more blocks&nbsp;

MaxBlockSize

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

and stays that way&nbsp;

00000B

 until MaxBlockSize&nbsp; evaluates to "True" under a market pressure/ relie=
f situation.&nbsp;<br></div><div>I hope this makes sense, I would appreciate=
 some feedback.&nbsp;<br></div></div><div>TG<br></div></div><div>___________=
____________________________________<br></div><div> bitcoin-dev mailing list=
<br></div><div> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" tar=
get=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br></div><div> <a h=
ref=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" targe=
t=3D"_blank" rel=3D"noreferrer">https://lists.linuxfoundation.org/mailman/li=
stinfo/bitcoin-dev</a><br></div></blockquote></div></div></blockquote><div><=
br></div><span>_______________________________________________</span><br><sp=
an>bitcoin-dev mailing list</span><br><span>bitcoin-dev@lists.linuxfoundatio=
n.org</span><br><span>https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev</span><br></div></blockquote></div></body></html>=

--Apple-Mail-B42D1DA3-5568-4785-8C63-544616EEC85C--