📅 Original date posted:2019-11-11
📝 Original message:> 1. We have Lightning and SegWit so thankfully we do not need to deal with
blocksizes anymore really.
Regardless of the current proposal in this email thread, just because we
have Lightning doesn't mean we don't ever have to increase the blocksize
again.
Even with Lightning there would be too many channel open and closes to be
able to handle million users without transaction fees going through the
roof.
I am advocating to keep the blocksize low right now, but I don't leave out
in increasing it in the future when we have a need for it, preferably via
an extension block (softfork).
Hampus
Den fre 8 nov. 2019 kl 15:44 skrev Emil Engler via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org>:
> 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/20191111/01e64494/attachment.html>;
Hampus Sjöberg [ARCHIVE] /
npub10u…hln8t
2023-06-07 18:21:33
in reply to nevent1q…78zc
Author Public Key
npub10uzud4rf4636awmfgvarmcfndcmdnv8rfd2y3rx2sqgckv9zur4qahln8tPublished at
2023-06-07 18:21:33Event JSON
{
"id": "64b56c6b84852fc85251d690e189cd3f10c989af15305103360f0b5377302651",
"pubkey": "7f05c6d469aea3aebb69433a3de1336e36d9b0e34b54488cca80118b30a2e0ea",
"created_at": 1686162093,
"kind": 1,
"tags": [
[
"e",
"5d418eaec984b9cdcaa5c550d5a78bddb4dd725422b96ba9619ac570ce29f436",
"",
"root"
],
[
"e",
"c8673aec784f28aeffd76160b1306d054ce7746871bc2b1a9a6de0f6357604e7",
"",
"reply"
],
[
"p",
"152f0d4ce7d420d9246b380f08432d1341256a7802c0761aa5dd05df29335fe8"
]
],
"content": "📅 Original date posted:2019-11-11\n📝 Original message:\u003e 1. We have Lightning and SegWit so thankfully we do not need to deal with\nblocksizes anymore really.\n\nRegardless of the current proposal in this email thread, just because we\nhave Lightning doesn't mean we don't ever have to increase the blocksize\nagain.\nEven with Lightning there would be too many channel open and closes to be\nable to handle million users without transaction fees going through the\nroof.\nI am advocating to keep the blocksize low right now, but I don't leave out\nin increasing it in the future when we have a need for it, preferably via\nan extension block (softfork).\n\nHampus\n\nDen fre 8 nov. 2019 kl 15:44 skrev Emil Engler via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e:\n\n\u003e NACK!\n\u003e 1. We have Lightning and SegWit so thankfully we do not need to deal with\n\u003e blocksizes anymore really.\n\u003e 2. What if a reorg happens? Then it could generate huge problems at the\n\u003e validation.\n\u003e\n\u003e Correct me if I understood it wrong please.\n\u003e\n\u003e Greetings,\n\u003e Emil Engler\n\u003e\n\u003e Trevor Groves via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e schrieb am Fr. 8. Nov. 2019 um 15:26:\n\u003e\n\u003e\u003e Dynamic MaxBlockSize - 3 Byte Solution\n\u003e\u003e \"DMBS\"\n\u003e\u003e\n\u003e\u003e If\n\u003e\u003e (Last TOTAL Block Trans fees) \u003e (AVG (Last 100 Blocks Trans Fees))\n\u003e\u003e AND\n\u003e\u003e current MaxBlockSize =\u003e 0.99 MB\n\u003e\u003e AND\n\u003e\u003e MaxBlockSize has not changed in 10 Blocks\n\u003e\u003e ** see error catch below\n\u003e\u003e Then\n\u003e\u003e ON (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize x 1.1)\n\u003e\u003e ELSE\n\u003e\u003e AT (Current Block # + 9) Set MaxBlockSize = (MaxBlockSize / 1.1)\n\u003e\u003e ELSEIF\n\u003e\u003e (current MaxBlockSize =\u003c 0.99 or current MaxBlockSize \u003e 6553.5 MB)\n\u003e\u003e Null (no action taken)\n\u003e\u003e **where 9 above represents the ActivateONBlock (software side) Variable\n\u003e\u003e -------------\n\u003e\u003e We add this 3 Byte Variable Factor to the white space in the Current\n\u003e\u003e Block.\n\u003e\u003e\n\u003e\u003e eg. this 3 byte HEX 19000A\n\u003e\u003e the first bit \"1\" can be 1,2 or 0\n\u003e\u003e 1 = increase future block (9 blocks ahead)\n\u003e\u003e 2 decrease future block (9 blocks ahead)\n\u003e\u003e 0 No Action (rules evaluate to null)\n\u003e\u003e **where 9 above represents the ActivateONBlock (software side) Variable\n\u003e\u003e --------------\n\u003e\u003e The Second bit is a Global Variable \"9\" represents a countdown to the set\n\u003e\u003e value action, placed to synchronize network forward changes in \"x\" blocks.\n\u003e\u003e software lowers value if evaluates to True a second time and so on.\n\u003e\u003e (\"Count down\" if you will)\n\u003e\u003e the last 2 bytes represent the globally accepted \"MaxBlockSize\"\n\u003e\u003e Variable, and is distributed within each block moving forward in this\n\u003e\u003e rightmost (2 byte) factor. In this case above,\n\u003e\u003e The variable portion \"000A\" (32 Bit value) represents decimal value 10\n\u003e\u003e being 1.0 MB block.\n\u003e\u003e the decimal place is Always Assumed, and must be hard coded\n\u003e\u003e Because this presents a theoretical Max limit of \"FFFF\" or 6553.5 MB,\n\u003e\u003e We would\n\u003e\u003e have to add a last rule \"only as a error catch\"\n\u003e\u003e ** AND IF MaxBlockSize \u003c 6553.5\n\u003e\u003e ---\n\u003e\u003e Increasing and decreasing\n\u003e\u003e On Every Block mined or distributed, the software can run the above rule\n\u003e\u003e set, Change the Variable and Distribute the next block \" In Synchronized\n\u003e\u003e fashion\". The above rules when combined evaluate to a YES or NO, This\n\u003e\u003e translates to a market reflection of increased system pressure or decreased\n\u003e\u003e market pressure. I think we can agree, at peak periods the system chokes\n\u003e\u003e itself off with fees and this is always only temporarily. So we can have\n\u003e\u003e the block, analyse system demand dynamically, and adjust on a globally\n\u003e\u003e agreed rule dynamically by market driven demand.\n\u003e\u003e Considering the ruleset above also Decreases the Block ONLY if its\n\u003e\u003e greater than 0.99mb this brings size back to a competitive state /and size\n\u003e\u003e once market demand pressures subside, yet achieves the smallest market\n\u003e\u003e feasible block size while also maintaining all current rule sets.\n\u003e\u003e An attacker would have to affect all block fees over the last 16 hours\n\u003e\u003e worth of transactions to affect a 10% max block size increase but then only\n\u003e\u003e after waiting 1.5 hours, so long as nothing has changed in the last 1.5\n\u003e\u003e hours and only for a limited amount of time. This approach also limits\n\u003e\u003e bloat. This safety block window of 9 blocks provides a look forward and\n\u003e\u003e look behind value, in turn provides the network time to synchronize.\n\u003e\u003e 10 block sync window. This, by design, also limits changes to one\n\u003e\u003e change every 3 hours (20 blocks), if there is a market pressure \"STATE\"\n\u003e\u003e occurring.\n\u003e\u003e My Question to the community is. Will our current Block accommodate the 3\n\u003e\u003e Byte\n\u003e\u003e Variable, Is solving the Scaling issue worth using the 3 Bytes of space?\n\u003e\u003e I believe it is.\n\u003e\u003e --\n\u003e\u003e Software, Will need to Evaluate MaxBlockSize Variable, and\n\u003e\u003e ActivateONBlock Variable from the most recent distributed blocks DMBS 3\n\u003e\u003e byte value.\n\u003e\u003e Run the rules , get the answer set the now known MaxBlockSize Var and\n\u003e\u003e Propegate the \"DMBS\" value.\n\u003e\u003e\n\u003e\u003e As capacity limits are breached, I think the majority agree \"we need to\n\u003e\u003e agree\".\n\u003e\u003e\n\u003e\u003e MaxBlockSize would provide a suitable middle ground and address concerns\n\u003e\u003e in a dynamic fashion, without compromising or changing existing\n\u003e\u003e security.\n\u003e\u003e Examples reflected in the blockchain 19000A rules has evaluates to\n\u003e\u003e true, increase expected in 9 blocks.1.0mb increases to 1.1mb\n\u003e\u003e if true for 9 more blocks MaxBlockSize Var becomes 18000A..\n\u003e\u003e 17000A..,16000A ..and so on if still true at 10000A var written becomes\n\u003e\u003e 00000B when read from left to right, 0-no change, in 0 blocks current \"\n\u003e\u003e DMBS\" value 000B or 1.1MB and stays that way 00000B until MaxBlockSize\n\u003e\u003e evaluates to \"True\" under a market pressure/ relief situation.\n\u003e\u003e I hope this makes sense, I would appreciate some feedback.\n\u003e\u003e TG\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191111/01e64494/attachment.html\u003e",
"sig": "f1fd75330f104623482af42b955b39c37dc72cbcd0a4ea44658f82361825e923aef1267a317a67b72df330de83a8f9d1080378608947177ceb2346fcc4656185"
}