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