Talk:Block size limit controversy: Difference between revisions
forgot signature |
No edit summary |
||
Line 5: | Line 5: | ||
: 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 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. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:05, 12 August 2015 (UTC) | : 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. --[[User:Lapp0|Lapp0]] ([[User talk: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. --[[User:Lapp0|Lapp0]] ([[User talk:Lapp0|talk]]) 05:08, 12 August 2015 (UTC) |
Revision as of 05:08, 12 August 2015
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)