rich1.0npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefhttps://nostr.ae/npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefnjumphttps://nostr.ae📅 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>