📅 Original date posted:2015-08-18
📝 Original message:Sounds like a much better approach than arbitrary deciding what the
block size should be
BR
Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/5fb19624/attachment.html>;
cedric perronnet [ARCHIVE] /
npub1rv…25dh7
2023-06-07 17:36:26
in reply to nevent1q…fcqf
Author Public Key
npub1rvad7sp90uj9377308xhuaf6hx6y22yrnnwvzaq6n04nfu4sqe0q525dh7Published at
2023-06-07 17:36:26Event JSON
{
"id": "81b03605520efa98f4819c50be6f798fdd494ae54e34b0d934641a7b10c10765",
"pubkey": "1b3adf40257f2458fbd179cd7e753ab9b44528839cdcc1741a9beb34f2b0065e",
"created_at": 1686159386,
"kind": 1,
"tags": [
[
"e",
"7ed22d6d4b773f63b7d7a74d45f8a3ef2ee47a84961e7f380d598c1822de0b82",
"",
"root"
],
[
"e",
"39d850625d5aa233be117b0522ecd2741d6d0378781b614c37b6cf87971327ac",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-08-18\n📝 Original message:Sounds like a much better approach than arbitrary deciding what the \nblock size should be\nBR\n\nLe 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :\n\u003e Regarding: \n\u003e http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html \n\u003e\n\u003e\n\u003e\n\u003e I am arguing with the following statement here...\n\u003e\n\u003e /I see problems to this approach. The biggest one I see is that a\n\u003e miner with 11% of hash power could sabotage block size increases\n\u003e by only ever mining empty blocks./\n\u003e\n\u003e\n\u003e\n\u003e First, I would like to argue from economics' point of view. If someone \n\u003e wants to hold back the block size increase with 11% hash power by \n\u003e mining empty blocks, he has to sacrifice Tx fees, which is not \n\u003e economical. 11% hash power will most likely be a pool and pool miners \n\u003e will find out soon that they are losing Tx fees because of pool \n\u003e owner's intention. Hence, they'll switch pool and pool owner will lose \n\u003e out. This is the same reason why 51% attack will never happen, even if \n\u003e a pool gets more than 51% hash power.\n\u003e\n\u003e\n\u003e Next, I would like to propose a slightly modified technical solution \n\u003e to this problem in algorithmic format...\n\u003e\n\u003e If more than 50% of block's size, found in the first 2000 of the last \n\u003e difficulty period, is more than 90% MaxBlockSize\n\u003e Double MaxBlockSize\n\u003e Else if more than 90% of block's size, found in the first 2000 of the \n\u003e last difficulty period, is less than 50% MaxBlockSize\n\u003e Half MaxBlockSize\n\u003e Else\n\u003e Keep the same MaxBlockSize\n\u003e\n\u003e This is how, those who want to stop increase, need to have more than \n\u003e 50% hash power. Those who want to stop decrease, need to have more \n\u003e than 10% hash power, but must mine more than 50% of MaxBlockSize in \n\u003e all blocks. In this approach, not only miners, but also the end user \n\u003e have their say. Because, end users will fill up the mempool, from \n\u003e where miners will take Tx to fill up the blocks. Please note that, \n\u003e taking first 2000 of the last 2016 blocks is important to avoid data \n\u003e discrepancy among different nodes due to orphan blocks. It is assumed \n\u003e that a chain can not be orphaned after having 16 confirmation.\n\u003e\n\u003e Looking for comments.\n\u003e\n\u003e\n\u003e\n\u003e\n\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/5fb19624/attachment.html\u003e",
"sig": "366f095b0eaafad88bf4c3a8c7df3c15d094891e41b858526796763bd4050dcca552887bd78a9ee12a84fa28526a6823dccb6cb001bb012458e622df9cf1e8dd"
}