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 >