Ross Nicoll [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-07 📝 Original message:Can I just add my own ...
📅 Original date posted:2015-05-07
📝 Original message:Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to leave
until 2020, I'd like to see the code committed ASAP so that every new
install, and every upgrade from there on gets the new version.
My personal opinion only is that 7 transactions a second is insanely
limited even if the main chain does nothing but act as a backbone
between other chains and transaction networks. I don't think that's
overly controversial. I think 2016 is too early for a 20mb block size,
though. I'm inclined to suggest a schedule of expansion, say to 2mb in
2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The
intent would be to provide enough size pressure to motivate scaling
work, while not limiting Bitcoin overly.
Further, I think this highlights that we need more work on fees. Right
now fees and transactions included are fairly naive, but I'd like to see
the absolute block size limit as a hard upper bound, with miners
imposing soft limits based on a balance cost of storage, number of
outputs vs inputs (and therefore impact on the UTXOs), and risk of
orphan blocks to determine which transactions are actually worth
including in each block. If anyone has numbers on block size vs orphan
rate that would be really useful, BTW.
Ross
On 07/05/2015 19:06, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> 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/11ec6034/attachment.html>;
📝 Original message:Can I just add my own support for this - as has been stated elsewhere in
this discussion, hard forks are difficult, and risky. The earlier we
have a decision, and the earlier the change goes into the code, the
easier that is.
Even if the decision was the actual block size change is fine to leave
until 2020, I'd like to see the code committed ASAP so that every new
install, and every upgrade from there on gets the new version.
My personal opinion only is that 7 transactions a second is insanely
limited even if the main chain does nothing but act as a backbone
between other chains and transaction networks. I don't think that's
overly controversial. I think 2016 is too early for a 20mb block size,
though. I'm inclined to suggest a schedule of expansion, say to 2mb in
2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The
intent would be to provide enough size pressure to motivate scaling
work, while not limiting Bitcoin overly.
Further, I think this highlights that we need more work on fees. Right
now fees and transactions included are fairly naive, but I'd like to see
the absolute block size limit as a hard upper bound, with miners
imposing soft limits based on a balance cost of storage, number of
outputs vs inputs (and therefore impact on the UTXOs), and risk of
orphan blocks to determine which transactions are actually worth
including in each block. If anyone has numbers on block size vs orphan
rate that would be really useful, BTW.
Ross
On 07/05/2015 19:06, Mike Hearn wrote:
>
> I think you are rubbing against your own presupposition that
> people must find and alternative right now. Quite a lot here do
> not believe there is any urgency, nor that there is an immanent
> problem that has to be solved before the sky falls in.
>
>
> I have explained why I believe there is some urgency, whereby "some
> urgency" I mean, assuming it takes months to implement, merge, test,
> release and for people to upgrade.
>
> But if it makes you happy, imagine that this discussion happens all
> over again next year and I ask the same question.
>
>
>
> ------------------------------------------------------------------------------
> 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/11ec6034/attachment.html>;