š
Original date posted:2015-07-17
š Original message:I would prefer a dynamic solution that did not necessitate a second hard
fork down the road.
I propose doubling the block size every 100k blocks (~2 years)
block 400,000 = 2MB (2016)
block 500,000 = 4MB (2017)
block 600,000 = 8MB (2018)
Chris
On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'd back this if we can't find a permanent solution - 2MB gives us a lot
> more wiggle room in the interim at least; one of my concerns with block
> size is 3 transactions per second is absolutely tiny, and we need space for
> the network to search for an equilibrium between volume and pricing without
> risk of an adoption spike rendering it essentially unusable.
>
> I'd favour switching over by block height rather than time, and I'd
> suggest that given virtually every wallet/node out there will require
> testing (even if many do not currently enforce a limit and therefore do not
> need changing), 6 months should be considered a minimum target. I'd open
> with a suggestion of block 390k as a target.
>
> Ross
>
>
> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
>
> Opening a mailing list thread on this BIP:
>
> BIP PR: https://github.com/bitcoin/bips/pull/173
> Code PR: https://github.com/bitcoin/bitcoin/pull/6451
>
> The general intent of this BIP is as a minimum viable alternative plan
> to my preferred proposal (BIP 100).
>
> If agreement is not reached on a more comprehensive solution, then this
> solution is at least available and a known quantity. A good backup plan.
>
> Benefits: conservative increase. proves network can upgrade. permits
> some added growth, while the community & market gathers data on how an
> increased block size impacts privacy, security, centralization, transaction
> throughput and other metrics. 2MB seems to be a Least Common Denominator
> on an increase.
>
> Costs: requires a hard fork. requires another hard fork down the road.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://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/20150717/5e09fdb8/attachment.html>;
Chris Wardell [ARCHIVE] /
npub1fzā¦4e4zk
2023-06-07 15:42:29
in reply to nevent1qā¦z5nc
Author Public Key
npub1fzktt45agp7zdquvjc3k50qzrcx37wup56tnfj6fx7p2jwcpchysq4e4zkPublished at
2023-06-07 15:42:29Event JSON
{
"id": "87b23547158dd7c3a044f60c2c8df86d3ab8b8003ff126ee387be6bcd134ce8e",
"pubkey": "48acb5d69d407c26838c96236a3c021e0d1f3b81a69734cb493782a93b01c5c9",
"created_at": 1686152549,
"kind": 1,
"tags": [
[
"e",
"2e544b01cfe0620e95990efdfb39d6c5828a4b2f5866e5b209d567b2efd50207",
"",
"root"
],
[
"e",
"c8129928fdcb730932d69e6180f19483438af7718ff4a8ac14bc5fdde39740dd",
"",
"reply"
],
[
"p",
"787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129"
]
],
"content": "š
Original date posted:2015-07-17\nš Original message:I would prefer a dynamic solution that did not necessitate a second hard\nfork down the road.\n\nI propose doubling the block size every 100k blocks (~2 years)\n\nblock 400,000 = 2MB (2016)\nblock 500,000 = 4MB (2017)\nblock 600,000 = 8MB (2018)\n\nChris\n\n\nOn Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I'd back this if we can't find a permanent solution - 2MB gives us a lot\n\u003e more wiggle room in the interim at least; one of my concerns with block\n\u003e size is 3 transactions per second is absolutely tiny, and we need space for\n\u003e the network to search for an equilibrium between volume and pricing without\n\u003e risk of an adoption spike rendering it essentially unusable.\n\u003e\n\u003e I'd favour switching over by block height rather than time, and I'd\n\u003e suggest that given virtually every wallet/node out there will require\n\u003e testing (even if many do not currently enforce a limit and therefore do not\n\u003e need changing), 6 months should be considered a minimum target. I'd open\n\u003e with a suggestion of block 390k as a target.\n\u003e\n\u003e Ross\n\u003e\n\u003e\n\u003e On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:\n\u003e\n\u003e Opening a mailing list thread on this BIP:\n\u003e\n\u003e BIP PR: https://github.com/bitcoin/bips/pull/173\n\u003e Code PR: https://github.com/bitcoin/bitcoin/pull/6451\n\u003e\n\u003e The general intent of this BIP is as a minimum viable alternative plan\n\u003e to my preferred proposal (BIP 100).\n\u003e\n\u003e If agreement is not reached on a more comprehensive solution, then this\n\u003e solution is at least available and a known quantity. A good backup plan.\n\u003e\n\u003e Benefits: conservative increase. proves network can upgrade. permits\n\u003e some added growth, while the community \u0026 market gathers data on how an\n\u003e increased block size impacts privacy, security, centralization, transaction\n\u003e throughput and other metrics. 2MB seems to be a Least Common Denominator\n\u003e on an increase.\n\u003e\n\u003e Costs: requires a hard fork. requires another hard fork down the road.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing listbitcoin-dev at lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150717/5e09fdb8/attachment.html\u003e",
"sig": "3bda1d09e33d358ab0ba1645919f0fcb466b47520f034972f9e58ff6bdf288baffc2bd59f14bf4df1b367e8012fd9be95d6d0a9c21193748fa8ea411ac11002b"
}