Date: Mon, 11 Nov 2019 13:52:49 +0000
To: Trevor Groves <gurvy51@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <P-TJrrShiuEPOOWqGpb2iLL9reReXD_IYPzSM5hB_brQfQORYgo-ALqTTf6aKAqUQimcFU-tpYBVQBlgkRDscJ3OxM43Z-LEsctoaD-gjIk=@protonmail.com>
In-Reply-To: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
References: <CAN+Of7A9pmrhEma49cQ0eP7vn50WxFemAEvztFxhgX2om_8Dpw@mail.gmail.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution
Precedence: list

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 economi=
cally is that miners are paid for confirming transactions, thus side fees a=
re 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 ta=
kes up space that cannot be used for actually-paying transactions.
  * However, by computing only using the explicit fees on the block (and no=
t the actual fees that miners actually get), various additional games can b=
e 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, includi=
ng encouraging miners to pad blocks with faked transactions (which otherwis=
e 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*** res=
ource consumption, thus not scaling.


> Dynamic MaxBlockSize =C2=A0- 3 Byte Solution
> "DMBS"
>
> If
> (Last TOTAL Block Trans fees)=C2=A0 > =C2=A0(AVG (Last 100 Blocks Trans F=
ees))
> AND
> current MaxBlockSize =C2=A0=3D> 0.99 MB =C2=A0
> AND
> MaxBlockSize has not changed in 10 Blocks
> ** see error catch below
> Then =C2=A0
> ON (Current Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlock=
Size x 1.1)
> ELSE =C2=A0
> AT (Current Block # =C2=A0+ 9) =C2=A0Set MaxBlockSize =C2=A0=3D (MaxBlock=
Size =C2=A0/ 1.1)
> ELSEIF
> (current MaxBlockSize =C2=A0=3D< 0.99 =C2=A0or current MaxBlockSize > 655=
3.5 MB)
> Null (no action taken)
> **where 9 above represents the ActivateONBlock (software side) Variable
> =C2=A0-------------
> We add this 3 Byte Variable Factor to the white space in the Current Bloc=
k.
>
> eg. =C2=A0this 3 byte HEX=C2=A0 =C2=A0 19000A
> the first bit "1" =C2=A0can be 1,2 or 0 =C2=A0 =C2=A0
> 1 =C2=A0=3D =C2=A0increase future block (9 blocks ahead)
> 2 =C2=A0decrease future block =C2=A0(9 blocks ahead)
> 0 =C2=A0 =C2=A0No 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 =C2=A0changes in "x" b=
locks. software lowers value if evaluates to True a second time=C2=A0 and s=
o on.=C2=A0
> ("Count down" if you will)
> the last 2 bytes represent =C2=A0the globally accepted "MaxBlockSize" Var=
iable, and is distributed within each block moving forward in this rightmos=
t (2 byte) factor.=C2=A0 In this case above,
> The variable portion =C2=A0"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 =C2=A0theoretical =C2=A0Max limit of "FFFF" =
=C2=A0or 6553.5 MB, We would
> have to add a last rule "only as a error catch"
> =C2=A0** 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 fa=
shion". The above rules when combined evaluate to a YES or NO, This transla=
tes to a market reflection of increased system pressure or decreased market=
 pressure. =C2=A0 I think we can agree, at peak periods the system chokes i=
tself off with fees and this is always only temporarily.=C2=A0 So we can ha=
ve the block, analyse system demand dynamically, and adjust on a globally a=
greed rule dynamically by market driven demand.
> Considering the ruleset above also Decreases =C2=A0the 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 feas=
ible block size while also maintaining all current rule sets.
> =C2=A0An attacker would have to affect all block fees over the last 16 ho=
urs 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 bl=
oat. 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.=C2=A0 This, by design, also limits changes to one c=
hange=C2=A0 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? =
=C2=A0
> I believe it is. =C2=A0
> --
> Software, =C2=A0Will need =C2=A0to Evaluate MaxBlockSize Variable, and Ac=
tivateONBlock Variable from the most recent distributed blocks DMBS =C2=
=A03 byte value.
> Run the rules , get the answer set the now known MaxBlockSize Var and Pro=
pegate the "DMBS" value.
>
> As capacity limits are breached, I think the majority agree "we need to a=
gree". =C2=A0
>
> MaxBlockSize would provide a suitable middle ground and address concerns =
in a dynamic fashion, without compromising =C2=A0or changing =C2=A0existing=
 security.=C2=A0 =C2=A0
> =C2=A0Examples reflected in the blockchain 19000A=C2=A0 =C2=A0rules has e=
valuates to=C2=A0 true, increase expected in 9 blocks.1.0mb increases to 1.=
1mb
> if true for 9 more blocks=C2=A0 MaxBlockSize Var becomes=C2=A0 18000A.. 1=
7000A..,16000A ..and so on if=C2=A0 still true at 10000A var written become=
s=C2=A0
> 00000B when read from left to right,=C2=A0 0-no change, in 0 blocks curre=
nt " DMBS" value 000B or 1.1MB=C2=A0 and stays that way=C2=A0 00000B until =
MaxBlockSize=C2=A0 evaluates to "True" under a market pressure/ relief situ=
ation.=C2=A0
> I hope this makes sense, I would appreciate some feedback.=C2=A0
> TG