đź“… Original date posted:2015-08-06
đź“ť Original message:I think the key is comity and humility in terms of being honest about our inability to predict future trends in a meaningful way while passing through scrutiny coming from divergent perspectives. Â 8MB + 40% annually (at whatever increase frequency is preferred, at coinbase halvings seems most ideal) is the proposal to use.
What if 40% is too fast? Â Â
If 40% turns out to be excessive, miners have a built in incentive to cap their blocks at a lower amount that meets the supply / demand equilibrium vs. the price of bitcoin trading on the free market.  The key here is to understand “price of bitcoin on the free market”.  Most developers don’t understand free market economics beyond gambling, which is a good bit of the problem here. Â
Bottom line is, miners directly benefit from higher bitcoin prices when denominated in other currencies.  This fact will naturally limit excessive growth of blk*.dat. size, because if the storage requirements for bitcoin grow out of reach of amateurs, it will lead to excessive centralization and capture by powerful interests, which would threaten to convert bitcoin to a form of sovereign currency and kill free demand for bitcoin (and tank the price).  Miners don’t want that without some other body paying them to make econonically distorted decisions.  They will limit the size themselves if they see this as an emerging threat.  It’s in their best interests and will keep them in business longer.
Now, is there a risk that some excessively well funded entity could artificially inflate the price of bitcoin while this bribing miners to let blk*.dat size grow out of hand (distorting miner economics) in some sort of “subsidies for increased liquidity” corruption scheme?  No there isn’t, because we are going to have a cap on the size that is reasonable enough that we know it won’t force out any amateurs for at least 5 years, and likely longer.
What if 40% is too slow?
That’s a problem anyone who actually owns bitcoin would like to have.  We’ll gladly support an increase in the rate if demand supports it later with a subsequent change.  We’ll have to do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, or some other non-self imposed existential threat rears its head.
Long game
Now, this entire scheme is predicated on the price going higher over the extended term.  I would argue that if we are doing a good job, the price should go higher.  Isn’t that the best barometer of performance?  Demand for the scarce units inside the protocol denominated in other currencies?
8MB is 1MB + 40% a year from January 2009 to today.  40% a year is as good as we are going to get in terms of our extrapolated estimation of future ability to host full nodes.  Anything else is overengineering something we can’t predict anyway.  Any arguments against this setting and rate of growth that aren’t exclusively focused on the computer science side of the debate are misguided at best, and corrupted by competing incentives at worst.  This is because it’s not possible to predict the future any better than using an extrapolation of the past, which is exactly what 8MB + 40% represents.
So TLDR? Â Go with 8MB + 40% annually and we will cross any (likely imaginary) bridges when we come to them down the road.
Will
From:Â Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
Reply:Â Pieter Wuille <pieter.wuille at gmail.com>>
Date:Â August 6, 2015 at 5:32:20 PM
To:Â Dave Scotese <dscotese at litmocracy.com>>
Cc:Â Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>>
Subject:Â Re: [bitcoin-dev] Wrapping up the block size debate with voting
On Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
"Miners can do this unilaterally" maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding.
They don't need to use full nodes for propagation. Miners don't care when other full nodes hear about their blocks, only whether they (eventually) accept them.
And yes, full nodes can change what blocks they accept. That's called a hard fork :)
--
Pieter
Â
_______________________________________________
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/20150806/862f7099/attachment.html>;
Will [ARCHIVE] /
npub1xe…zrjrx
2023-06-07 15:45:13
in reply to nevent1q…cftx
Author Public Key
npub1xe4sg9zgsm90v8ge3r0h29jmwjuudcldxfwczaazuph5y5020jvqpzrjrxPublished at
2023-06-07 15:45:13Event JSON
{
"id": "0a380c2b65bb8ed219ea97096d9ef1ec0236b387dfcd0a95954850ea94faed94",
"pubkey": "366b04144886caf61d1988df75165b74b9c6e3ed325d8177a2e06f4251ea7c98",
"created_at": 1686152713,
"kind": 1,
"tags": [
[
"e",
"37db21c1d9def528e9399e6fbbd8279c30b90088530ac52221b26e4bfa4cc2df",
"",
"root"
],
[
"e",
"ed6f2387cb605a47d7b1f15b4532927e5b8f21c846cffced643251a9bc0d05fe",
"",
"reply"
],
[
"p",
"5cb21bf5d7f25a9d46879713cbd32433bbc10e40ef813a3c28fe7355f49854d6"
]
],
"content": "📅 Original date posted:2015-08-06\n📝 Original message:I think the key is comity and humility in terms of being honest about our inability to predict future trends in a meaningful way while passing through scrutiny coming from divergent perspectives.  8MB + 40% annually (at whatever increase frequency is preferred, at coinbase halvings seems most ideal) is the proposal to use.\n\nWhat if 40% is too fast?   \nIf 40% turns out to be excessive, miners have a built in incentive to cap their blocks at a lower amount that meets the supply / demand equilibrium vs. the price of bitcoin trading on the free market.  The key here is to understand “price of bitcoin on the free market”.  Most developers don’t understand free market economics beyond gambling, which is a good bit of the problem here.  \n\nBottom line is, miners directly benefit from higher bitcoin prices when denominated in other currencies.  This fact will naturally limit excessive growth of blk*.dat. size, because if the storage requirements for bitcoin grow out of reach of amateurs, it will lead to excessive centralization and capture by powerful interests, which would threaten to convert bitcoin to a form of sovereign currency and kill free demand for bitcoin (and tank the price).  Miners don’t want that without some other body paying them to make econonically distorted decisions.  They will limit the size themselves if they see this as an emerging threat.  It’s in their best interests and will keep them in business longer.\n\nNow, is there a risk that some excessively well funded entity could artificially inflate the price of bitcoin while this bribing miners to let blk*.dat size grow out of hand (distorting miner economics) in some sort of “subsidies for increased liquidity” corruption scheme?  No there isn’t, because we are going to have a cap on the size that is reasonable enough that we know it won’t force out any amateurs for at least 5 years, and likely longer.\n\nWhat if 40% is too slow?\nThat’s a problem anyone who actually owns bitcoin would like to have.  We’ll gladly support an increase in the rate if demand supports it later with a subsequent change.  We’ll have to do this eventually anyway when SHA256 and RIPEMD160 exhibit collisions, or some other non-self imposed existential threat rears its head.\n\nLong game\nNow, this entire scheme is predicated on the price going higher over the extended term.  I would argue that if we are doing a good job, the price should go higher.  Isn’t that the best barometer of performance?  Demand for the scarce units inside the protocol denominated in other currencies?\n\n8MB is 1MB + 40% a year from January 2009 to today.  40% a year is as good as we are going to get in terms of our extrapolated estimation of future ability to host full nodes.  Anything else is overengineering something we can’t predict anyway.  Any arguments against this setting and rate of growth that aren’t exclusively focused on the computer science side of the debate are misguided at best, and corrupted by competing incentives at worst.  This is because it’s not possible to predict the future any better than using an extrapolation of the past, which is exactly what 8MB + 40% represents.\n\nSo TLDR?  Go with 8MB + 40% annually and we will cross any (likely imaginary) bridges when we come to them down the road.\n\nWill\n\nFrom: Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nReply: Pieter Wuille \u003cpieter.wuille at gmail.com\u003e\u003e\nDate: August 6, 2015 at 5:32:20 PM\nTo: Dave Scotese \u003cdscotese at litmocracy.com\u003e\u003e\nCc: Bitcoin Dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\u003e\nSubject: Re: [bitcoin-dev] Wrapping up the block size debate with voting \n\nOn Fri, Aug 7, 2015 at 1:26 AM, Dave Scotese via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\"Miners can do this unilaterally\" maybe, if they are a closed group, based on the 51% rule. But aren't they using full nodes for propagation? In this sense, anyone can vote by coding.\n\nThey don't need to use full nodes for propagation. Miners don't care when other full nodes hear about their blocks, only whether they (eventually) accept them.\n\nAnd yes, full nodes can change what blocks they accept. That's called a hard fork :)\n\n--\nPieter\n \n\n_______________________________________________ \nbitcoin-dev mailing list \nbitcoin-dev at lists.linuxfoundation.org \nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev \n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150806/862f7099/attachment.html\u003e",
"sig": "d6cb22673b38657906233a12db246d0c0b9d49f3fd8fa0c25bc2ba09348a20a7f921c996262032c2e4eb91e54282d8c89466057301bcee8505416ffb3d94f389"
}