From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 02EB4D8B for ; 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 ; Fri, 8 Nov 2019 14:37:04 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id p20so6706394qtq.5 for ; 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 (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 ; 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: In-Reply-To: From: Emil Engler Date: Fri, 8 Nov 2019 15:36:52 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion , Trevor Groves 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
NACK!
1. We have Lightn= ing and SegWit so thankfully we do not need to deal with blocksizes anymore= really.
2. What if a reorg happens? Then it could g= enerate huge problems at the validation.

<= div dir=3D"auto">Correct me if I understood it wrong please.

Greetings,
Emi= l Engler

Trevor Groves via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = schrieb am Fr. 8. Nov. 2019 um 15:26:
Dynamic MaxBlockSize =C2=A0- 3 Byte Solution
"D= MBS"

If
(Last TOTAL Block Trans fees)=C2=A0 > =C2=A0(AV= G (Last 100 Blocks Trans Fees))
AND
current MaxBlockSize =C2=A0=3D>= ; 0.99 MB =C2=A0
AND
MaxBlockSize has not changed in 10 Blocks
**= see error catch below
Then =C2=A0
ON (Current Block # =C2=A0+ 9) =C2= =A0Set MaxBlockSize =C2=A0=3D (MaxBlockSize x 1.1)
ELSE =C2=A0
AT (Cu= rrent Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlockSize =C2= =A0/ 1.1)
ELSEIF
(current MaxBlockSize =C2=A0=3D< 0.99 =C2=A0or c= urrent MaxBlockSize > 6553.5 MB)
Null (no action taken)
**where 9 = above represents the ActivateONBlock (software side) Variable
=C2=A0----= ---------
We add this 3 Byte Variable Factor to the white space in the C= urrent Block.

eg. =C2=A0this 3 byte HEX=C2=A0 =C2=A0 19000A
the f= irst bit "1" =C2=A0can be 1,2 or 0 =C2=A0 =C2=A0
1 =C2=A0=3D = =C2=A0increase future block (9 blocks ahead)
2 =C2=A0decrease future blo= ck =C2=A0(9 blocks ahead)
0 =C2=A0 =C2=A0No Action (rules evaluate to nu= ll)
**where 9 above represents the ActivateONBlock (software side) Varia= ble
--------------
The Second bit is a Global Variable "9" = represents a countdown to the set value action, placed to synchronize netwo= rk forward =C2=A0changes in "x" blocks. software lowers value if = evaluates to True a second time=C2=A0 and so on.=C2=A0
("Count down= " if you will)
the last 2 bytes represent =C2=A0the globally accept= ed "MaxBlockSize" Variable, and is distributed within each block = moving forward in this rightmost (2 byte) factor.=C2=A0 In this case above,=
The variable portion =C2=A0"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 =C2=A0theoretical =C2= =A0Max limit of "FFFF" =C2=A0or 6553.5 MB, We would
have to a= dd a last rule "only as a error catch"
=C2=A0** AND IF MaxBloc= kSize < 6553.5
---
Increasing and decreasing
On Every Block mi= ned or distributed, the software can run the above rule set, Change the Var= iable and Distribute the next block " In Synchronized fashion". 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.
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.
=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.
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 "STATE" occurring.
My Question to the com= munity is. Will our current Block accommodate the 3 Byte
Variable, Is s= olving the Scaling issue worth using the 3 Bytes of space? =C2=A0
I beli= eve it is. =C2=A0
--
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.
Run the rules , get the answer se= t the now known MaxBlockSize Var and Propegate the "DMBS" value. =

As capacity limits are breached, I think the majority agree "w= e need to agree". =C2=A0

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
=
=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
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
00000B when read from left t= o right,=C2=A0 0-no change, in 0 blocks current " DMBS" value 000= B or 1.1MB=C2=A0 and stays that way=C2=A0 00000B until MaxBlockSize=C2=A0 evaluates to "True" under a market pres= sure/ relief situation.=C2=A0
I hope this makes sense, I would ap= preciate some feedback.=C2=A0
TG
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000269ef70596d6b7f6--