What is Nostr?
Mark Friedenbach [ARCHIVE] /
npub1r3sā€¦8d0u
2023-06-07 15:49:16
in reply to nevent1qā€¦z2lf

Mark Friedenbach [ARCHIVE] on Nostr: šŸ“… Original date posted:2015-08-28 šŸ“ Original message:It is in their individual ...

šŸ“… Original date posted:2015-08-28
šŸ“ Original message:It is in their individual interests when the larger block that is allowed
for them grants them more fees.
On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> 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
>>
>
> _______________________________________________
> 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/78c1fdf0/attachment-0001.html>;
Author Public Key
npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u