Talk:Block size limit controversy

WikiProject Events

	This page is within the scope of WikiProject Events, a collaborative effort to improve the coverage of events on the Bitcoin Wiki. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start	This page has been rated as Start-class on the quality scale.
High	This page has been rated as high-importance on the importance scale.

WikiProject Protocol

	This page is within the scope of WikiProject Protocol, a collaborative effort to improve the coverage of Bitcoin protocol documentation on the Bitcoin Wiki. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start	This page has been rated as Start-class on the quality scale.
Mid	This page has been rated as mid-importance on the importance scale.

I think the article needs a revision from the ground up since I think there is consensus that the limit should be increased, it is just unclear when to do that and by how much. Also, the "A hard fork requires waiting for sufficient consensus." argument is actually very unclear because there is no measure of consensus short of the longest blockchain. Bitcoin core dev consensus is arbitrary and also represents a centralisation. ---Unsigned comment by User:Chaosgrid

(1) I agree there is widespread consensus that the limit should eventually be increased. (2) I don't think the inability to independently measure consensus is a barrier to determining when a proposal does or does not have consensus. When there are several important members of our community objecting to a proposal, it is safe to say that consensus has not been obtained. ---Harding (talk) 23:26, 10 August 2015 (UTC)

I think the positions can still be split, but not between never increase and increase now as it appears to be split at the moment. A more representative question to debate would be "should the blocksize be increased in the near future". Near future may be defined as the next year and a half. Longest blockchain isn't guaranteed to be the consensus blockchain and the consensus required isn't between core devs, rather Bitcoin users. I think saying "sufficient consensus" is fine because there isn't a line between damage happening due to insufficient consensus and no damage happening. There are degrees of damage, with a 50% split being the worst and one small transaction being reversed due to someones broken consensus being the least bad, and 100% agreement being the perfect result. --Lapp0 (talk) 05:05, 12 August 2015 (UTC)

I removed the congestion and failing client arguments. The failing argument in particular has nothing to do with block size and everything to do with spam prevention. The congestion argument doesn't apply when replace by fee and child pays for parent exist. I left the high fee argument because it is the out of solving these two argued problems that were removed. --Lapp0 (talk) 05:08, 12 August 2015 (UTC)

I also merged your feerate argument with its section in undecided arguments since it is already covered there partially, let me know if this isn't satisfactory. --Lapp0 (talk) 05:21, 12 August 2015 (UTC)