Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 15F6BDE1 for ; 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 ; Fri, 8 Nov 2019 17:04:25 +0000 (UTC) Received: by mail-wm1-f51.google.com with SMTP id l17so6112885wmh.0 for ; 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 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: In-Reply-To: To: =?utf-8?Q?Joachim_Str=C3=B6mbergson?= , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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 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 NACK

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

= Alberto


E= l 8 nov 2019, a las 16:54, Joachim Str=C3=B6mbergson via bitcoin-dev <bit= coin-dev@lists.linuxfoundation.org> escribi=C3=B3:

=EF=BB=BF
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.


Sent with ProtonMail Secure Email.

= =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
On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:

<= blockquote class=3D"protonmail_quote" type=3D"cite">
N= ACK!
1. We have Lightning and SegWit so tha= nkfully we do not need to deal with blocksizes anymore really.
2. What if a reorg happens? Then it could generate huge proble= ms at the validation.

Correct me if I understood it wrong please.

=
Greetings,
Emil Engler

Trevo= r Groves via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> schrieb am Fr. 8. No= v. 2019 um 15:26:
= Dynamic MaxBlockSize  - 3 Byte Solution
"DMBS"
<= div>

If
(Last TOTAL Block Trans fees) = ; >  (AVG (Last 100 Blocks Trans Fees))
AND
<= div>current MaxBlockSize  =3D> 0.99 MB  
AND
=
MaxBlockSize has not changed in 10 Blocks
** see er= ror catch below
Then  
ON (Current Block # &= nbsp;+ 9)  Set MaxBlockSize  =3D (MaxBlockSize x 1.1)
ELSE  
AT (Current Block #  + 9)  Set MaxBloc= kSize  =3D (MaxBlockSize  / 1.1)
ELSEIF
(current MaxBlockSize  =3D< 0.99  or current MaxBlockSize &g= t; 6553.5 MB)
Null (no action taken)
**where 9 a= bove represents the ActivateONBlock (software side) Variable
&= nbsp;-------------
We add this 3 Byte Variable Factor to the w= hite space in the Current Block.

eg.  this= 3 byte HEX    19000A
the first bit "1"  can be= 1,2 or 0    
1  =3D  increase future bloc= k (9 blocks ahead)
2  decrease future block  (9 bloc= ks ahead)
0    No Action (rules evaluate to null)
**where 9 above represents the ActivateONBlock (software side) V= ariable
--------------
The Second bit is a Globa= l Variable "9" represents a countdown to the set value action, placed to syn= chronize network forward  changes in "x" blocks. software lowers value i= f evaluates to True a second time  and so on. 
("Cou= nt down" if you will)
the last 2 bytes represent  the glo= bally 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) represe= nts decimal value 10 being 1.0 MB block.
the decimal place is A= lways 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"
&= nbsp;** AND IF MaxBlockSize < 6553.5
---
Inc= reasing and decreasing
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.   I think we can agree, at pe= ak periods the system chokes itself off with fees and this is always only te= mporarily.  So we can have the block, analyse system demand dynamically= , and adjust on a globally agreed rule dynamically by market driven demand.<= br>
Considering the ruleset above also Decreases  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.
 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.
10 block sync window.  This, by design, also limits changes to o= ne change  every 3 hours (20 blocks), if there is a market pressure "ST= ATE" occurring.
My Question to the community is. Will our curr= ent Block accommodate the 3 Byte
Variable, Is solving the Sca= ling issue worth using the 3 Bytes of space?  
I believe i= t is.  
--
Software,  Will need  = to Evaluate MaxBlockSize Variable, and ActivateONBlock Variable from the mos= t recent distributed blocks DMBS  3 byte value.
Run the r= ules , 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 add= ress concerns in a dynamic fashion, without compromising  or changing &= nbsp;existing security.   
 Example= s 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 a= t 10000A var written becomes 
00000B when read from left t= o right,  0-no change, in 0 blocks current " DMBS" value 000B or 1.1MB&= nbsp; and stays that way  00000B until MaxBlockSize  evaluates to "True" under a market pressure/ relie= f situation. 
I hope this makes sense, I would appreciate= some feedback. 
TG
___________= ____________________________________
bitcoin-dev mailing list=
<= br>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundatio= n.org
https://lists.linuxfoundation.org/mailman/listinfo/bit= coin-dev
= --Apple-Mail-B42D1DA3-5568-4785-8C63-544616EEC85C--