<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Further to that - please disregard what I said about using block
height. Had failed to realise that in using contextual information
(block height) it complicates block validation (i.e. it would be
impossible to tell if a block is too big, without having all
previous blocks first). Block time is in fact the better option.<br>
<br>
Ross<br>
<br>
<div class="moz-cite-prefix">On 17/07/2015 18:57, Ross Nicoll via
bitcoin-dev wrote:<br>
</div>
<blockquote cite="mid:55A9421B.6040605@jrn.me.uk" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
I'd back this if we can't find a permanent solution - 2MB gives us
a lot more wiggle room in the interim at least; one of my concerns
with block size is 3 transactions per second is absolutely tiny,
and we need space for the network to search for an equilibrium
between volume and pricing without risk of an adoption spike
rendering it essentially unusable.<br>
<br>
I'd favour switching over by block height rather than time, and
I'd suggest that given virtually every wallet/node out there will
require testing (even if many do not currently enforce a limit and
therefore do not need changing), 6 months should be considered a
minimum target. I'd open with a suggestion of block 390k as a
target.<br>
<br>
Ross<br>
<br>
<div class="moz-cite-prefix">On 17/07/2015 16:55, Jeff Garzik via
bitcoin-dev wrote:<br>
</div>
<blockquote
cite="mid:CADm_WcZKoMAhYvXbFMbE+5K9HOD75YkQu8_qTW4S6YN6ZMrfjA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Opening a mailing list thread on this BIP:</div>
<div><br>
</div>
BIP PR: <a moz-do-not-send="true"
href="https://github.com/bitcoin/bips/pull/173">https://github.com/bitcoin/bips/pull/173</a>
<div>Code PR: <a moz-do-not-send="true"
href="https://github.com/bitcoin/bitcoin/pull/6451">https://github.com/bitcoin/bitcoin/pull/6451</a></div>
<div><br>
</div>
<div>The general intent of this BIP is as a minimum viable
alternative plan to my preferred proposal (BIP 100).</div>
<div><br>
</div>
<div>If agreement is not reached on a more comprehensive
solution, then this solution is at least available and a
known quantity. A good backup plan.</div>
<div><br>
</div>
<div>Benefits: conservative increase. proves network can
upgrade. permits some added growth, while the community
& market gathers data on how an increased block size
impacts privacy, security, centralization, transaction
throughput and other metrics. 2MB seems to be a Least
Common Denominator on an increase.</div>
<div><br>
</div>
<div>Costs: requires a hard fork. requires another hard fork
down the road.</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>