{"type":"rich","version":"1.0","author_name":"npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef","author_url":"https://nostr.ae/npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaef","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-07\n📝 Original message:Can I just add my own support for this - as has been stated elsewhere in \nthis discussion, hard forks are difficult, and risky. The earlier we \nhave a decision, and the earlier the change goes into the code, the \neasier that is.\n\nEven if the decision was the actual block size change is fine to leave \nuntil 2020, I'd like to see the code committed ASAP so that every new \ninstall, and every upgrade from there on gets the new version.\n\nMy personal opinion only is that 7 transactions a second is insanely \nlimited even if the main chain does nothing but act as a backbone \nbetween other chains and transaction networks. I don't think that's \noverly controversial. I think 2016 is too early for a 20mb block size, \nthough. I'm inclined to suggest a schedule of expansion, say to 2mb in \n2016, 4mb in 2018, 8mb in 2020 and 20mb in 2022 where it stops. The \nintent would be to provide enough size pressure to motivate scaling \nwork, while not limiting Bitcoin overly.\n\nFurther, I think this highlights that we need more work on fees. Right \nnow fees and transactions included are fairly naive, but I'd like to see \nthe absolute block size limit as a hard upper bound, with miners \nimposing soft limits based on a balance cost of storage, number of \noutputs vs inputs (and therefore impact on the UTXOs), and risk of \norphan blocks to determine which transactions are actually worth \nincluding in each block. If anyone has numbers on block size vs orphan \nrate that would be really useful, BTW.\n\nRoss\n\nOn 07/05/2015 19:06, Mike Hearn wrote:\n\u003e\n\u003e     I think you are rubbing against your own presupposition that\n\u003e     people must find and alternative right now. Quite a lot here do\n\u003e     not believe there is any urgency, nor that there is an immanent\n\u003e     problem that has to be solved before the sky falls in.\n\u003e\n\u003e\n\u003e I have explained why I believe there is some urgency, whereby \"some \n\u003e urgency\" I mean, assuming it takes months to implement, merge, test, \n\u003e release and for people to upgrade.\n\u003e\n\u003e But if it makes you happy, imagine that this discussion happens all \n\u003e over again next year and I ask the same question.\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/11ec6034/attachment.html\u003e"}