From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 73139B6C for ; Mon, 11 Nov 2019 13:52:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5E28F8D4 for ; Mon, 11 Nov 2019 13:52:57 +0000 (UTC) Date: Mon, 11 Nov 2019 13:52:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1573480374; bh=5xsSM+DaNYzPN35ssVgCqlM6Wx2fRRB1FFBTbZfHBtY=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=OcptXCucxwKWUhYURDMliR4FYetZJH8G/QIvURkm/qX2yzxiMi1sjSKUOAiqviEQe peuvR+stWQjAb/dWxGu/qKNPy1UqtzfIF0sHYmHxErFMUxMWUn+kXC7YEwrutYNAnb rOPH9ESUBEUS6uCPEUcRsvRBYvdR+SGnQXIwaL+Q= To: Trevor Groves , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Dynamic MaxBlockSize - 3 Byte Solution X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2019 13:52:58 -0000 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