Alberto Aldave [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-08 📝 Original message:NACK 1.- At some point in ...
📅 Original date posted:2019-11-08
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/f6739b1b/attachment.html>;
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191108/f6739b1b/attachment.html>;