[bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

[bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution

[Trevor Groves]

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

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

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

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

[Emil Engler]

[-- 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 --]

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

[Joachim Strömbergson]

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

While I agree on NACKing the proposal as it does not add anything new and fundamentally misunderstands what scaling is (or is not in this case), I disagree 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 advanced offchain constructions such as channel factories are enough. At this moment to claim that would be very bold and hardly justified.

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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: 8049 bytes --]

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

[Alberto Aldave]

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

NACK

1.- At some point in 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 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ömbergson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escribió:
> 
> 
> While I agree on NACKing the proposal as it does not add anything new and fundamentally misunderstands what scaling is (or is not in this case), I disagree 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 advanced offchain constructions such as channel factories are enough. At this moment to claim that would be very bold and hardly justified.
> 
> 
> Sent with ProtonMail Secure Email.
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Friday, November 8, 2019 2:36 PM, Emil Engler via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> 
>> 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
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

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

[Hampus Sjöberg]

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

> 1. We have Lightning and SegWit so thankfully we do not need to deal with
blocksizes anymore really.

Regardless of the current proposal in this email thread, just because we
have Lightning doesn't mean we don't ever have to increase the blocksize
again.
Even with Lightning there would be too many channel open and closes to be
able to handle million users without transaction fees going through the
roof.
I am advocating to keep the blocksize low right now, but I don't leave out
in increasing it in the future when we have a need for it, preferably via
an extension block (softfork).

Hampus

Den fre 8 nov. 2019 kl 15:44 skrev Emil Engler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:

> 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
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

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

[Luke Dashjr]

On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote:
> I am advocating to keep the blocksize low right now, 

It ISN'T low right now...

> but I don't leave out 
> in increasing it in the future when we have a need for it, preferably via
> an extension block (softfork).

Extension blocks are not softforks, and are unreasonably convoluted for no 
real gain. When the time comes, the block size should be increased only using 
a hardfork.

Luke

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

[Hampus Sjöberg]

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

> It ISN'T low right now...

I agree, but I don't think it's a good idea to softfork it to lower than 4M
WU though, and I don't think we need to;
hopefully when exchanges start using Lightning or Liquid, avg blocksize
will go down.

> Extension blocks are not softforks, and are unreasonably convoluted for
no
real gain. When the time comes, the block size should be increased only
using
a hardfork.

It depends on how you define soft and hardforks, I suspect you don't see
extension blocks as a softforks because old nodes won't maintain a correct
UTXO set.
I think an extension block is a softfork because old nodes will still be
able to follow the mainchain.

I don't know if a blocksize increase hardfork will get consensus as the
idea has been ruined by all malicious hijack attempts we've seen over the
years.

Hampus

Den mån 11 nov. 2019 kl 17:47 skrev Luke Dashjr <luke@dashjr.org>:

> On Monday 11 November 2019 16:08:43 Hampus Sjöberg via bitcoin-dev wrote:
> > I am advocating to keep the blocksize low right now,
>
> It ISN'T low right now...
>
> > but I don't leave out
> > in increasing it in the future when we have a need for it, preferably via
> > an extension block (softfork).
>
> Extension blocks are not softforks, and are unreasonably convoluted for no
> real gain. When the time comes, the block size should be increased only
> using
> a hardfork.
>
> Luke
>

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

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

[Luke Dashjr]

On Monday 11 November 2019 17:10:16 Hampus Sjöberg wrote:
> > It ISN'T low right now...
>
> I agree, but I don't think it's a good idea to softfork it to lower than 4M
> WU though, and I don't think we need to;
> hopefully when exchanges start using Lightning or Liquid, avg blocksize
> will go down.

Not likely, so long as spam continues to pad blocks full.

> > Extension blocks are not softforks, and are unreasonably convoluted for
> no
> real gain. When the time comes, the block size should be increased only
> using
> a hardfork.
>
> It depends on how you define soft and hardforks, I suspect you don't see
> extension blocks as a softforks because old nodes won't maintain a correct
> UTXO set.
> I think an extension block is a softfork because old nodes will still be
> able to follow the mainchain.

Softforks leave old nodes *working*, so yes, maintaining the correct UTXO 
state.

Simply "following" is meaningless, as even soft-hardforks are "followed".

> I don't know if a blocksize increase hardfork will get consensus as the
> idea has been ruined by all malicious hijack attempts we've seen over the
> years.

If there isn't consensus, then it shouldn't be done, period.

Luke

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

[ZmnSCPxj]

Several days late, I would like to add my NACK here.

* The actual fees paid to miners are not in fact known.
  Miners may accept side fees that are not explicitly visible on the block, and miners may pad their blocks with faked self-paying transactions.
  Further, such side fees and faked transactions do not modify the economic assumptions of Bitcoin.
  * Mining fees are simply an anonymity technique: what is material economically is that miners are paid for confirming transactions, thus side fees are perfectly fine when considering economic incentives of Bitcoin mining.
  * Without this proposed mechanism, padding blocks with faked self-paying transactions is self-destructive behavior for miners, as the transaction takes up space that cannot be used for actually-paying transactions.
  * However, by computing only using the explicit fees on the block (and not the actual fees that miners actually get), various additional games can be played by miners.
    Such games make considering the overall security of mining much harder and we may end up with worse security due to misaligned incentives, including encouraging miners to pad blocks with faked transactions (which otherwise is discouraged by the current protocol).
* Scaling means getting more impact for less resource consumption.
  ***All*** block size increases are getting more impact for ***more*** resource consumption, thus not scaling.


> 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