Emil Engler [ARCHIVE] on Nostr: š Original date posted:2019-11-08 š Original message:NACK! 1. We have Lightning ...
š
Original date posted:2019-11-08
š Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/788a634f/attachment.html>;
š Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/788a634f/attachment.html>;