ð
Original date posted:2015-08-18
ð Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/c93d1eff/attachment.html>;
Upal Chakraborty [ARCHIVE] /
npub1x6âŠ66806
2023-06-07 15:47:55
in reply to nevent1qâŠpn9a
Author Public Key
npub1x6pz2er3cuzy78kamnlqr77p55kvegxyupc99ylrgpknqj2t527s766806Published at
2023-06-07 15:47:55Event JSON
{
"id": "007ba39869d4458f663ce6353a7901a34058e2af9a53fa8b4a8c083a6c44d51a",
"pubkey": "3682256471c7044f1edddcfe01fbc1a52ccca0c4e0705293e3406d30494ba2bd",
"created_at": 1686152875,
"kind": 1,
"tags": [
[
"e",
"04c055baa2674526726a622bd1bd37944209de47bcb89f54cba6db6abf55701c",
"",
"root"
],
[
"e",
"beb51b530b71d5fb082ef02d5f226f9a56e99e63d14d014bdca30ec8b583be3f",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "ð
Original date posted:2015-08-18\nð Original message:Regarding:\nhttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html\n\n\nI am arguing with the following statement here...\n\n*I see problems to this approach. The biggest one I see is that a miner\n\u003e with 11% of hash power could sabotage block size increases by only ever\n\u003e mining empty blocks.*\n\n\n\nFirst, I would like to argue from economics' point of view. If someone\nwants to hold back the block size increase with 11% hash power by mining\nempty blocks, he has to sacrifice Tx fees, which is not economical. 11%\nhash power will most likely be a pool and pool miners will find out soon\nthat they are losing Tx fees because of pool owner's intention. Hence,\nthey'll switch pool and pool owner will lose out. This is the same reason\nwhy 51% attack will never happen, even if a pool gets more than 51% hash\npower.\n\n\nNext, I would like to propose a slightly modified technical solution to\nthis problem in algorithmic format...\n\nIf more than 50% of block's size, found in the first 2000 of the last\ndifficulty period, is more than 90% MaxBlockSize\n Double MaxBlockSize\nElse if more than 90% of block's size, found in the first 2000 of the last\ndifficulty period, is less than 50% MaxBlockSize\n Half MaxBlockSize\nElse\n Keep the same MaxBlockSize\n\nThis is how, those who want to stop increase, need to have more than 50%\nhash power. Those who want to stop decrease, need to have more than 10%\nhash power, but must mine more than 50% of MaxBlockSize in all blocks. In\nthis approach, not only miners, but also the end user have their say.\nBecause, end users will fill up the mempool, from where miners will take Tx\nto fill up the blocks. Please note that, taking first 2000 of the last 2016\nblocks is important to avoid data discrepancy among different nodes due to\norphan blocks. It is assumed that a chain can not be orphaned after having\n16 confirmation.\n\nLooking for comments.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150818/c93d1eff/attachment.html\u003e",
"sig": "a02667fbcf76269be9bb595758ad8424bdebd10f5b5fdedaf7d58358be42b2fee1a0e26caaa02c9ceca4616ac79260c0b7fd71590c12714e6c67ebfb45a4cbcd"
}