📅 Original date posted:2015-05-07
📝 Original message:I'm presuming that schedule is just an example, as you'd end up with
insanely large block sizes in a few years.
Absolutely, yes, an increase schedule is an option if people agree on
it, and I think the better option, as the current limit too low, but
jumping straight to a value big enough for "indefinitely" is a huge jump.
Gave some thought to scaling block size based on transaction fees, but
suspect it would end up with miners sending huge fees to themselves with
transactions that aren't relayed (so they only are actioned if they make
it into a block that miner mines) to make the network allow bigger blocks.
Ross
On 07/05/2015 19:38, Chris Wardell wrote:
> Instead of raising the block size to another static number like 20MB,
> can we raise it dynamically?
>
> Make the max block size something like:
> pow(2, nHeight/100000) * 1MB; //double every ~2 years
>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/bcea0e35/attachment.html>;
Ross Nicoll [ARCHIVE] /
npub10p…pfaef
2023-06-07 17:33:22
in reply to nevent1q…fr6z
Author Public Key
npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefPublished at
2023-06-07 17:33:22Event JSON
{
"id": "b1268bcae32de9e39ef6bef8edda0e6307abc4f3a2a7acc9717768fe90eaec9f",
"pubkey": "787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129",
"created_at": 1686152002,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"4bb72f231fdbf76e265d4734098da927912207b6f786f5bdc216341dd4bad059",
"",
"reply"
],
[
"p",
"83939e4391e74ab1f02f783131a30a24db681188b72b90da8bce3dcaa763c8b4"
]
],
"content": "📅 Original date posted:2015-05-07\n📝 Original message:I'm presuming that schedule is just an example, as you'd end up with \ninsanely large block sizes in a few years.\n\nAbsolutely, yes, an increase schedule is an option if people agree on \nit, and I think the better option, as the current limit too low, but \njumping straight to a value big enough for \"indefinitely\" is a huge jump.\n\nGave some thought to scaling block size based on transaction fees, but \nsuspect it would end up with miners sending huge fees to themselves with \ntransactions that aren't relayed (so they only are actioned if they make \nit into a block that miner mines) to make the network allow bigger blocks.\n\nRoss\n\nOn 07/05/2015 19:38, Chris Wardell wrote:\n\u003e Instead of raising the block size to another static number like 20MB, \n\u003e can we raise it dynamically?\n\u003e\n\u003e Make the max block size something like:\n\u003e pow(2, nHeight/100000) * 1MB; //double every ~2 years\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e One dashboard for servers and applications across Physical-Virtual-Cloud\n\u003e Widest out-of-the-box monitoring support with 50+ applications\n\u003e Performance metrics, stats and reports that give you Actionable Insights\n\u003e Deep dive visibility with transaction tracing using APM Insight.\n\u003e http://ad.doubleclick.net/ddm/clk/290420510;117567292;y\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/bcea0e35/attachment.html\u003e",
"sig": "3ae1fc963815afda83902b2b35ae23bbe666d5cf5e8f04473655286ff48f5e705df069c99310785579b649f1626e0ad5cfe282f56a6a55da6c06abfd60b2a5b6"
}