📅 Original date posted:2015-08-28
📝 Original message:But that's not what this proposal does. They have to pay the difficulty penalty merely for a *chance* at later being able to mine larger blocks.
Maybe this could be fixed by allowing miners to produce a larger-than-limit block *immediately* by paying a difficulty penalty. Then we can simply take the 80th-percentile block size in each 2016-block period as the nominal block-size limit in the next period.
On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote:
> 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
> >
> >
Matt Whitlock [ARCHIVE] /
npub17q…upwet
2023-06-07 17:37:52
in reply to nevent1q…466n
Author Public Key
npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetSeen on
wss://relay.nostr.bandPublished at
2023-06-07 17:37:52Event JSON
{
"id": "511663a0b5a6aab353478d08785fbbf6ecaab26dc89729b8cae603244cab1c88",
"pubkey": "f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91",
"created_at": 1686159472,
"kind": 1,
"tags": [
[
"e",
"89feefa8fe3dbd95b7d3a6c8b355b09f064e01d014925a52bfb3842ed0275076",
"",
"root"
],
[
"e",
"ecf3c0940698548fa6cb213e2888bebb58019d280179c9cd4fb5fc5aeb9b4fd4",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2015-08-28\n📝 Original message:But that's not what this proposal does. They have to pay the difficulty penalty merely for a *chance* at later being able to mine larger blocks.\n\nMaybe this could be fixed by allowing miners to produce a larger-than-limit block *immediately* by paying a difficulty penalty. Then we can simply take the 80th-percentile block size in each 2016-block period as the nominal block-size limit in the next period.\n\n\nOn Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote:\n\u003e It is in their individual interests when the larger block that is allowed\n\u003e for them grants them more fees.\n\u003e \n\u003e On Aug 28, 2015 4:35 PM, \"Chris Pacia via bitcoin-dev\" \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e \u003e When discussing this with Matt Whitlock earlier we basically concluded the\n\u003e \u003e block size will never increase under this proposal do to a collective\n\u003e \u003e action problem. If a miner votes for an increase and nobody else does, the\n\u003e \u003e blocksize will not increase yet he will still have to pay the difficulty\n\u003e \u003e penalty.\n\u003e \u003e\n\u003e \u003e It may be in everyone's collective interest to raise the block size but\n\u003e \u003e not their individual interest.\n\u003e \u003e On Aug 28, 2015 6:24 PM, \"Gavin via bitcoin-dev\" \u003c\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e\u003e With this proposal, how much would it cost a miner to include an 'extra'\n\u003e \u003e\u003e 500-byte transaction if the average block size is 900K and it costs the\n\u003e \u003e\u003e 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\n\u003e \u003e\u003e bitcoin-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 selling\n\u003e \u003e\u003e their block-size votes.\n\u003e \u003e\u003e \u003e • It addresses the problem, in Gavin Andresen's BIP 101, of blindly\n\u003e \u003e\u003e trying to predict future market needs versus future technological\n\u003e \u003e\u003e capacities.\n\u003e \u003e\u003e \u003e • It avoids a large step discontinuity in the block-size limit by\n\u003e \u003e\u003e starting 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 to\n\u003e \u003e\u003e raise the block-size limit.\n\u003e \u003e\u003e \u003e • It avoids incentivizing miners to vote to lower the block-size limit.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e However, this proposal currently fails to answer a very important\n\u003e \u003e\u003e question:\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e • What is the mechanism for activation of the new consensus rule? It is\n\u003e \u003e\u003e when a certain percentage of the blocks mined in a 2016-block retargeting\n\u003e \u003e\u003e 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 wrote:\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\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\u003e \u003e",
"sig": "760c97c2e0253913b5d950cfe2498e35bcdbcf81f4a478a2a726e75d5eac43d2200d148d1a2d698de06dfa70f27c768bfb31e06bb89d023eea655c0de4a5d564"
}