t. khan [ARCHIVE] on Nostr: 📅 Original date posted:2017-02-06 📝 Original message:>My BIP draft didn't make ...
📅 Original date posted:2017-02-06
📝 Original message:>My BIP draft didn't make progress because the community opposes any block
size
>increase hardfork ever.
Luke, how do you know the community opposes that? Specifically, how did you
come to this conclusion?
>Your version doesn't address the current block size
>issues (ie, the blocks being too large).
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.
- t.k.
On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My BIP draft didn't make progress because the community opposes any block
> size
> increase hardfork ever. Your version doesn't address the current block size
> issues (ie, the blocks being too large). So you've retained the only
> certain-
> DOA parts of my proposal, and removed the most useful part... I'm not sure
> the
> point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no
> sense
> to keep the BIP 9 deployment at all - either it gets consensus or it
> doesn't,
> but miners have no part in deployment of it.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
> > Hello all,
> >
> > Many people have expressed discontent with Luke-jr's proposed block size
> > BIP, in particular with the decrease in size that would occur if it were
> > to be activated prior to 2024.
> >
> > I have decided to modify the proposal to instead begin the increase
> > steps at the current 1000000 byte limit. The increases and the time spam
> > of each increase will remain the same, just that the increase begins
> > from 1000000 bytes instead of 300000 bytes.
> >
> > Furthermore, instead of a fixed schedule from a fixed point in time, the
> > increases will instead be calculated off of the MTP of the activation
> > block (the first block to be in the active state for this fork).
> >
> > While this proposal shares many of the same issues with the one it
> > modifies, I hope that it will be slightly less controversial and can
> > allow us to move forward with scaling Bitcoin.
> >
> > The full text of the proposal can be found at
> > https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
> > My implementation of it is available at
> > https://github.com/achow101/bitcoin/tree/bip-blksize
> >
> >
> > Andrew
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170206/fcf1d14b/attachment.html>;
📝 Original message:>My BIP draft didn't make progress because the community opposes any block
size
>increase hardfork ever.
Luke, how do you know the community opposes that? Specifically, how did you
come to this conclusion?
>Your version doesn't address the current block size
>issues (ie, the blocks being too large).
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.
- t.k.
On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My BIP draft didn't make progress because the community opposes any block
> size
> increase hardfork ever. Your version doesn't address the current block size
> issues (ie, the blocks being too large). So you've retained the only
> certain-
> DOA parts of my proposal, and removed the most useful part... I'm not sure
> the
> point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no
> sense
> to keep the BIP 9 deployment at all - either it gets consensus or it
> doesn't,
> but miners have no part in deployment of it.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
> > Hello all,
> >
> > Many people have expressed discontent with Luke-jr's proposed block size
> > BIP, in particular with the decrease in size that would occur if it were
> > to be activated prior to 2024.
> >
> > I have decided to modify the proposal to instead begin the increase
> > steps at the current 1000000 byte limit. The increases and the time spam
> > of each increase will remain the same, just that the increase begins
> > from 1000000 bytes instead of 300000 bytes.
> >
> > Furthermore, instead of a fixed schedule from a fixed point in time, the
> > increases will instead be calculated off of the MTP of the activation
> > block (the first block to be in the active state for this fork).
> >
> > While this proposal shares many of the same issues with the one it
> > modifies, I hope that it will be slightly less controversial and can
> > allow us to move forward with scaling Bitcoin.
> >
> > The full text of the proposal can be found at
> > https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
> > My implementation of it is available at
> > https://github.com/achow101/bitcoin/tree/bip-blksize
> >
> >
> > Andrew
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170206/fcf1d14b/attachment.html>;