📅 Original date posted:2015-08-28
📝 Original message:On Aug 28, 2015 7:38 PM, "Mark Friedenbach" <mark at friedenbach.org> wrote:
>
> It is in their individual interests when the larger block that is allowed
for them grants them more fees.
And pay a difficulty penalty and lose full blocks because of it? Even if
fees are somehow high enough to compensate for the lost reward, it still
requires miners to collectively decide to raise the block size for it to
make sense individually. An individual vote will not raise the limit, but
it will cost the miner money.
>
> 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/f3f30c1b/attachment.html>;
Chris Pacia [ARCHIVE] /
npub1jp…kn8jw
2023-06-07 19:37:52
in reply to nevent1q…ncly
Author Public Key
npub1jp0jnnq2jxcjy76nrt5dssvmpynt4f9psdelp3vxj0y0xtpxl7jqhkn8jwPublished at
2023-06-07 19:37:52Event JSON
{
"id": "8f2feaeec915766cf16d8e9c4c8ace48b09a4172a3e2b913df7dec45a2a8d3d7",
"pubkey": "905f29cc0a91b1227b531ae8d8419b0926baa4a18373f0c58693c8f32c26ffa4",
"created_at": 1686159472,
"kind": 1,
"tags": [
[
"e",
"89feefa8fe3dbd95b7d3a6c8b355b09f064e01d014925a52bfb3842ed0275076",
"",
"root"
],
[
"e",
"511663a0b5a6aab353478d08785fbbf6ecaab26dc89729b8cae603244cab1c88",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2015-08-28\n📝 Original message:On Aug 28, 2015 7:38 PM, \"Mark Friedenbach\" \u003cmark at friedenbach.org\u003e wrote:\n\u003e\n\u003e It is in their individual interests when the larger block that is allowed\nfor them grants them more fees.\n\nAnd pay a difficulty penalty and lose full blocks because of it? Even if\nfees are somehow high enough to compensate for the lost reward, it still\nrequires miners to collectively decide to raise the block size for it to\nmake sense individually. An individual vote will not raise the limit, but\nit will cost the miner money.\n\n\u003e\n\u003e On Aug 28, 2015 4:35 PM, \"Chris Pacia via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e When discussing this with Matt Whitlock earlier we basically concluded\nthe block size will never increase under this proposal do to a collective\naction problem. If a miner votes for an increase and nobody else does, the\nblocksize will not increase yet he will still have to pay the difficulty\npenalty.\n\u003e\u003e\n\u003e\u003e It may be in everyone's collective interest to raise the block size but\nnot their individual interest.\n\u003e\u003e\n\u003e\u003e On Aug 28, 2015 6:24 PM, \"Gavin via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e With this proposal, how much would it cost a miner to include an\n'extra' 500-byte transaction if the average block size is 900K and it costs\nthe miner 20BTC in electricity/capital/etc to mine a block?\n\u003e\u003e\u003e\n\u003e\u003e\u003e If my understanding of the proposal is correct, it is:\n\u003e\u003e\u003e\n\u003e\u003e\u003e 500/900000 * 20 = 0.11111 BTC\n\u003e\u003e\u003e\n\u003e\u003e\u003e ... Or $2.50 at today's exchange rate.\n\u003e\u003e\u003e\n\u003e\u003e\u003e That seems excessive.\n\u003e\u003e\u003e\n\u003e\u003e\u003e --\n\u003e\u003e\u003e Gavin Andresen\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e \u003e On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e This is the best proposal I've seen yet. Allow me to summarize:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e • It addresses the problem, in Jeff Garzik's BIP 100, of miners\nselling their block-size votes.\n\u003e\u003e\u003e \u003e • It addresses the problem, in Gavin Andresen's BIP 101, of blindly\ntrying to predict future market needs versus future technological\ncapacities.\n\u003e\u003e\u003e \u003e • It avoids a large step discontinuity in the block-size limit by\nstarting with a 1-MB limit.\n\u003e\u003e\u003e \u003e • It throttles changes to ±10% every 2016 blocks.\n\u003e\u003e\u003e \u003e • It imposes a tangible cost (higher difficulty) on miners who vote\nto raise the block-size limit.\n\u003e\u003e\u003e \u003e • It avoids incentivizing miners to vote to lower the block-size\nlimit.\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e However, this proposal currently fails to answer a very important\nquestion:\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e • What is the mechanism for activation of the new consensus rule? It\nis when a certain percentage of the blocks mined in a 2016-block\nretargeting period contain valid block-size votes?\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\n\u003e\u003e\u003e \u003e\u003e On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev\nwrote:\n\u003e\u003e\u003e \u003e\u003e Pull request: https://github.com/bitcoin/bips/pull/187\n\u003e\u003e\u003e \u003e _______________________________________________\n\u003e\u003e\u003e \u003e bitcoin-dev mailing list\n\u003e\u003e\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150828/f3f30c1b/attachment.html\u003e",
"sig": "0e82ce7ee731c0994003c9bd6046d379e59f333913c214321e9709935210b6d7d500383dce7920a306606f5ce93ee5a25c06ef8dcef7669a29c09e7ec93cfcd0"
}