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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
