Chris Pacia [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-28 📝 Original message:When discussing this with ...
📅 Original date posted:2015-08-28
📝 Original message:When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
It may be in everyone's collective interest to raise the block size but not
their individual interest.
On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the
> miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
>
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
>
> --
> Gavin Andresen
>
>
> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > This is the best proposal I've seen yet. Allow me to summarize:
> >
> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> their block-size votes.
> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> trying to predict future market needs versus future technological
> capacities.
> > • It avoids a large step discontinuity in the block-size limit by
> starting with a 1-MB limit.
> > • It throttles changes to ±10% every 2016 blocks.
> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> raise the block-size limit.
> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >
> > However, this proposal currently fails to answer a very important
> question:
> >
> > • What is the mechanism for activation of the new consensus rule? It is
> when a certain percentage of the blocks mined in a 2016-block retargeting
> period contain valid block-size votes?
> >
> >
> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >
> >
> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> Pull request: https://github.com/bitcoin/bips/pull/187
> > _______________________________________________
> > 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/20150828/a44dfde3/attachment.html>;
📝 Original message:When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
It may be in everyone's collective interest to raise the block size but not
their individual interest.
On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the
> miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
>
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
>
> --
> Gavin Andresen
>
>
> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > This is the best proposal I've seen yet. Allow me to summarize:
> >
> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> their block-size votes.
> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> trying to predict future market needs versus future technological
> capacities.
> > • It avoids a large step discontinuity in the block-size limit by
> starting with a 1-MB limit.
> > • It throttles changes to ±10% every 2016 blocks.
> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> raise the block-size limit.
> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >
> > However, this proposal currently fails to answer a very important
> question:
> >
> > • What is the mechanism for activation of the new consensus rule? It is
> when a certain percentage of the blocks mined in a 2016-block retargeting
> period contain valid block-size votes?
> >
> >
> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >
> >
> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> Pull request: https://github.com/bitcoin/bips/pull/187
> > _______________________________________________
> > 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/20150828/a44dfde3/attachment.html>;