<div dir="ltr">>My BIP draft didn't make progress because the community opposes any block size<br>>increase hardfork ever.<div><br></div><div>Luke, how do you know the community opposes that? Specifically, how did you come to this conclusion?</div><div><br></div><div>>Your version doesn't address the current block size<br>>issues (ie, the blocks being too large).<br></div><div><br></div><div>Why do you think blocks are "too large"? Please cite some evidence. I've asked this before and you ignored it, but an answer would be helpful to the discussion.</div><div><br></div><div>- t.k.<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">My BIP draft didn't make progress because the community opposes any block size<br>
increase hardfork ever. Your version doesn't address the current block size<br>
issues (ie, the blocks being too large). So you've retained the only certain-<br>
DOA parts of my proposal, and removed the most useful part... I'm not sure the<br>
point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense<br>
to keep the BIP 9 deployment at all - either it gets consensus or it doesn't,<br>
but miners have no part in deployment of it.<br>
<div class="m_5478911187313260324gmail-HOEnZb"><div class="m_5478911187313260324gmail-h5"><br>
On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:<br>
> Hello all,<br>
><br>
> Many people have expressed discontent with Luke-jr's proposed block size<br>
> BIP, in particular with the decrease in size that would occur if it were<br>
> to be activated prior to 2024.<br>
><br>
> I have decided to modify the proposal to instead begin the increase<br>
> steps at the current 1000000 byte limit. The increases and the time spam<br>
> of each increase will remain the same, just that the increase begins<br>
> from 1000000 bytes instead of 300000 bytes.<br>
><br>
> Furthermore, instead of a fixed schedule from a fixed point in time, the<br>
> increases will instead be calculated off of the MTP of the activation<br>
> block (the first block to be in the active state for this fork).<br>
><br>
> While this proposal shares many of the same issues with the one it<br>
> modifies, I hope that it will be slightly less controversial and can<br>
> allow us to move forward with scaling Bitcoin.<br>
><br>
> The full text of the proposal can be found at<br>
> <a href="https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki" rel="noreferrer" target="_blank">https://github.com/achow101/bi<wbr>ps/blob/bip-blksize/bip-blksiz<wbr>e.mediawiki</a>.<br>
> My implementation of it is available at<br>
> <a href="https://github.com/achow101/bitcoin/tree/bip-blksize" rel="noreferrer" target="_blank">https://github.com/achow101/bi<wbr>tcoin/tree/bip-blksize</a><br>
><br>
><br>
> Andrew<br>
><br>
> ______________________________<wbr>_________________<br>
> bitcoin-dev mailing list<br>
> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div></div></div>