📅 Original date posted:2015-08-18
📝 Original message:I agree with the simplicity of this approach and with removing the
reduction step... it's unlikely the block size would ever need to be
reduced, only increased with demand?
I like this solution better than either kicking the can, or raising the
block size based on chain height (another dynamic solution).
-Chris
On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I like the simplicity of this approach. Demand driven response.
>
> Is there really a need to reduce the max block size at all? It is just a
> maximum limit, not a required size for every block. If a seasonal
> transaction surge bumps the max block size limit up a notch, what harm is
> there in leaving the max block size limit at the "high water mark"
> indefinitely, even though periods of decreased transaction volume?
>
> I'd argue to remove the reduction step, making the max block size
> calculation a monotonic increasing function. Cut the complexity in half.
>
> -Danny
>
> On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Regarding:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>>
>>
>> I am arguing with the following statement here...
>>
>> *I see problems to this approach. The biggest one I see is that a miner
>>> with 11% of hash power could sabotage block size increases by only ever
>>> mining empty blocks.*
>>
>>
>>
>> First, I would like to argue from economics' point of view. If someone
>> wants to hold back the block size increase with 11% hash power by mining
>> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
>> hash power will most likely be a pool and pool miners will find out soon
>> that they are losing Tx fees because of pool owner's intention. Hence,
>> they'll switch pool and pool owner will lose out. This is the same reason
>> why 51% attack will never happen, even if a pool gets more than 51% hash
>> power.
>>
>>
>> Next, I would like to propose a slightly modified technical solution to
>> this problem in algorithmic format...
>>
>> If more than 50% of block's size, found in the first 2000 of the last
>> difficulty period, is more than 90% MaxBlockSize
>> Double MaxBlockSize
>> Else if more than 90% of block's size, found in the first 2000 of the
>> last difficulty period, is less than 50% MaxBlockSize
>> Half MaxBlockSize
>> Else
>> Keep the same MaxBlockSize
>>
>> This is how, those who want to stop increase, need to have more than 50%
>> hash power. Those who want to stop decrease, need to have more than 10%
>> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
>> this approach, not only miners, but also the end user have their say.
>> Because, end users will fill up the mempool, from where miners will take Tx
>> to fill up the blocks. Please note that, taking first 2000 of the last 2016
>> blocks is important to avoid data discrepancy among different nodes due to
>> orphan blocks. It is assumed that a chain can not be orphaned after having
>> 16 confirmation.
>>
>> Looking for comments.
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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/20150818/30234398/attachment.html>;
Chris Wardell [ARCHIVE] /
npub1fz…4e4zk
2023-06-07 17:36:26
in reply to nevent1q…xad3
Author Public Key
npub1fzktt45agp7zdquvjc3k50qzrcx37wup56tnfj6fx7p2jwcpchysq4e4zkPublished at
2023-06-07 17:36:26Event JSON
{
"id": "dc845d9a8a13818fb4fa6edfb7d63574dc936e11a6c6ac7fbaf214466ffbad0d",
"pubkey": "48acb5d69d407c26838c96236a3c021e0d1f3b81a69734cb493782a93b01c5c9",
"created_at": 1686159386,
"kind": 1,
"tags": [
[
"e",
"7ed22d6d4b773f63b7d7a74d45f8a3ef2ee47a84961e7f380d598c1822de0b82",
"",
"root"
],
[
"e",
"9e2327f63acfe4dd5d6f5da5bdfce3032d22c0385db54a776f0b9cb6cdca55b9",
"",
"reply"
],
[
"p",
"05208c76c935dd1274b15b261067b86262a0ebeef3ef6cd223b4a692feee2b8f"
]
],
"content": "📅 Original date posted:2015-08-18\n📝 Original message:I agree with the simplicity of this approach and with removing the\nreduction step... it's unlikely the block size would ever need to be\nreduced, only increased with demand?\n\nI like this solution better than either kicking the can, or raising the\nblock size based on chain height (another dynamic solution).\n\n-Chris\n\n\nOn Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I like the simplicity of this approach. Demand driven response.\n\u003e\n\u003e Is there really a need to reduce the max block size at all? It is just a\n\u003e maximum limit, not a required size for every block. If a seasonal\n\u003e transaction surge bumps the max block size limit up a notch, what harm is\n\u003e there in leaving the max block size limit at the \"high water mark\"\n\u003e indefinitely, even though periods of decreased transaction volume?\n\u003e\n\u003e I'd argue to remove the reduction step, making the max block size\n\u003e calculation a monotonic increasing function. Cut the complexity in half.\n\u003e\n\u003e -Danny\n\u003e\n\u003e On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Regarding:\n\u003e\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e I am arguing with the following statement here...\n\u003e\u003e\n\u003e\u003e *I see problems to this approach. The biggest one I see is that a miner\n\u003e\u003e\u003e with 11% of hash power could sabotage block size increases by only ever\n\u003e\u003e\u003e mining empty blocks.*\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e First, I would like to argue from economics' point of view. If someone\n\u003e\u003e wants to hold back the block size increase with 11% hash power by mining\n\u003e\u003e empty blocks, he has to sacrifice Tx fees, which is not economical. 11%\n\u003e\u003e hash power will most likely be a pool and pool miners will find out soon\n\u003e\u003e that they are losing Tx fees because of pool owner's intention. Hence,\n\u003e\u003e they'll switch pool and pool owner will lose out. This is the same reason\n\u003e\u003e why 51% attack will never happen, even if a pool gets more than 51% hash\n\u003e\u003e power.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Next, I would like to propose a slightly modified technical solution to\n\u003e\u003e this problem in algorithmic format...\n\u003e\u003e\n\u003e\u003e If more than 50% of block's size, found in the first 2000 of the last\n\u003e\u003e difficulty period, is more than 90% MaxBlockSize\n\u003e\u003e Double MaxBlockSize\n\u003e\u003e Else if more than 90% of block's size, found in the first 2000 of the\n\u003e\u003e last difficulty period, is less than 50% MaxBlockSize\n\u003e\u003e Half MaxBlockSize\n\u003e\u003e Else\n\u003e\u003e Keep the same MaxBlockSize\n\u003e\u003e\n\u003e\u003e This is how, those who want to stop increase, need to have more than 50%\n\u003e\u003e hash power. Those who want to stop decrease, need to have more than 10%\n\u003e\u003e hash power, but must mine more than 50% of MaxBlockSize in all blocks. In\n\u003e\u003e this approach, not only miners, but also the end user have their say.\n\u003e\u003e Because, end users will fill up the mempool, from where miners will take Tx\n\u003e\u003e to fill up the blocks. Please note that, taking first 2000 of the last 2016\n\u003e\u003e blocks is important to avoid data discrepancy among different nodes due to\n\u003e\u003e orphan blocks. It is assumed that a chain can not be orphaned after having\n\u003e\u003e 16 confirmation.\n\u003e\u003e\n\u003e\u003e Looking for comments.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\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\u003e\n\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/30234398/attachment.html\u003e",
"sig": "35200565eda27acc48ff56fe2c148b042f9a2facf157be9100ccaf743b6122dfcda1f7a843bc6951b40e1d9667970639afe67f01da534e4d0eef5edecb9c52e2"
}