Ross Nicoll [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-07 📝 Original message:I'm presuming that ...
📅 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>
📝 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>