public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2019-11-08 14:37 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-07  3:33 [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution Trevor Groves
2019-11-08 14:36 ` Emil Engler [this message]
2019-11-08 15:19   ` Joachim Strömbergson
2019-11-08 17:04     ` Alberto Aldave
2019-11-11 16:08   ` Hampus Sjöberg
2019-11-11 16:47     ` Luke Dashjr
2019-11-11 17:10       ` Hampus Sjöberg
2019-11-11 19:56         ` Luke Dashjr
2019-11-11 13:52 ` ZmnSCPxj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL6iL8VwYVpFkZuExpk=7LKGTLxVdQODtZmHnaK4MR0J9McdVQ@mail.gmail.com' \
    --to=me@emilengler.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gurvy51@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox