<div dir="ltr">What would you do?<div><br></div><div>a. Double the block size</div><div>b. Reduce the block rate to a half (average 5 minute blocks)</div><div><br></div><div><div>Suppose this is a one time hard fork. There no drastic technical problems with any of them: &quot;SPV&quot; mining and the relay network has shown that block propagation is not an issue for such as small change. Mining centralization won&#39;t radically change for a 2x adjustment. </div><div><br></div><div>So what would be best for Bitcoin?</div></div><div><br></div><div>I suspect some (if not most of you) would choose b. Because reducing the block interval saves us real time. Waiting 30 minutes for a 3-block confirmation is... such a long time! Time that we value. Time that sometimes we waste waiting. Time that makes a difference for us. Doubling the block size does not change the user perception of Bitcoin in any way.</div><div><br></div><div>Then why most discussions go around doubling the block size?<br></div><div><br></div><div><div>Each change require less than 20 lines of code (*) in the reference code, and minimum change in other wallets. </div><div><br></div><div>Currently there is no idle mining hardware for hire, so the security of six 10-minute block confirmation is equivalent to the security of six 5-minute block confirmations, as described in Satoshi&#39;s paper (if there were 51% spare mining hardware for hire, then obviously hiring that hardware for 30 minutes would cost less than hiring it for 1 hour).</div></div><div><br></div><div>Why we discuss a 2x block size increase and not a 1/2 block interval reduction? Aren&#39;t we Bitcoin users after all?</div><div><br></div><div>Best regards,</div><div> Sergio.</div><div><br></div><div>(*) b requires increasing the transaction version number, to support the old nLockTime rate.<br></div><div><br></div><div><br></div></div>