Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

From: Emil Engler <me@emilengler•com>
To: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	 Trevor Groves <gurvy51@gmail•com>
Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
Date: Fri, 8 Nov 2019 15:36:52 +0100	[thread overview]
Message-ID: <CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com> (raw)
In-Reply-To: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5030 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6060 bytes --]