Author: odinn 2015-06-18 23:25:57
Published on: 2015-06-18T23:25:57+00:00
In this context, Jeff Garzik talks about getting out in front of the need to prevent significant negative impacts on users when blocks are consistently full. He suggests possible approaches to this issue, namely Adam Back's simplified soft-fork one-way peg, BIP 100 by Jeff Garzik and Gavin Andresen, developing an 8 MB block size limit adjustment within Core, with one or more of the above authors instead of focusing on XT. However, it is assumed that developers are willing to abandon intentionally contentious proposals such as the hard fork to XT with 20MB and remain within the context of Core. Jeff also points out that not raising the block size limit does not mean doing nothing to solve the problem. He brings up the subject of "developers going off the deep end," which started the thread. Jeff raises questions about what technical mechanisms exist to keep developers from going rogue and doing exactly what has been described, if they have full commit access. Is there a process whereby that can't happen unless another developer provides a signature? If nothing does, how would you change that?
Updated on: 2023-06-09T23:29:33.099496+00:00