{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-06\n📝 Original message:I don’t really have a strong opinion on block size either…but if we’re going to do a hard fork, let’s use this as an opportunity to create a good process for hard forks (which we’ll inevitably need to do again in the future). The change in block size is a very simple change that still allows us to explore all the complexities involved with deployment of hard forks. Let’s not just do a one-off ad-hoc thing.\n\n- Eric Lombrozo\n\n\u003e On May 6, 2015, at 3:30 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\u003e \n\u003e I don't have strong opinion @ block size topic.\n\u003e \n\u003e But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (https://bitcointalk.org/index.php?topic=181734.0 \u003chttps://bitcointalk.org/index.php?topic=181734.0\u003e) or its alternative. All developers of lightweight (blockchain-less) clients will adore you!\n\u003e \n\u003e slush\n\u003e \n\u003e On Thu, May 7, 2015 at 12:12 AM, Matt Corallo \u003cbitcoin-list at bluematt.me \u003cmailto:bitcoin-list at bluematt.me\u003e\u003e wrote:\n\u003e Recently there has been a flurry of posts by Gavin at\n\u003e http://gavinandresen.svbtle.com/ \u003chttp://gavinandresen.svbtle.com/\u003e which advocate strongly for increasing\n\u003e the maximum block size. However, there hasnt been any discussion on this\n\u003e mailing list in several years as far as I can tell.\n\u003e \n\u003e Block size is a question to which there is no answer, but which\n\u003e certainly has a LOT of technical tradeoffs to consider. I know a lot of\n\u003e people here have varying levels of strong or very strong opinions about\n\u003e this, and the fact that it is not being discussed in a technical\n\u003e community publicly anywhere is rather disappointing.\n\u003e \n\u003e So, at the risk of starting a flamewar, I'll provide a little bait to\n\u003e get some responses and hope the discussion opens up into an honest\n\u003e comparison of the tradeoffs here. Certainly a consensus in this kind of\n\u003e technical community should be a basic requirement for any serious\n\u003e commitment to blocksize increase.\n\u003e \n\u003e Personally, I'm rather strongly against any commitment to a block size\n\u003e increase in the near future. Long-term incentive compatibility requires\n\u003e that there be some fee pressure, and that blocks be relatively\n\u003e consistently full or very nearly full. What we see today are\n\u003e transactions enjoying next-block confirmations with nearly zero pressure\n\u003e to include any fee at all (though many do because it makes wallet code\n\u003e simpler).\n\u003e \n\u003e This allows the well-funded Bitcoin ecosystem to continue building\n\u003e systems which rely on transactions moving quickly into blocks while\n\u003e pretending these systems scale. Thus, instead of working on technologies\n\u003e which bring Bitcoin's trustlessness to systems which scale beyond a\n\u003e blockchain's necessarily slow and (compared to updating numbers in a\n\u003e database) expensive settlement, the ecosystem as a whole continues to\n\u003e focus on building centralized platforms and advocate for changes to\n\u003e Bitcoin which allow them to maintain the status quo[1].\n\u003e \n\u003e Matt\n\u003e \n\u003e [1] https://twitter.com/coinbase/status/595741967759335426 \u003chttps://twitter.com/coinbase/status/595741967759335426\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 \u003chttp://ad.doubleclick.net/ddm/clk/290420510;117567292;y\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net \u003cmailto:Bitcoin-development at lists.sourceforge.net\u003e\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development \u003chttps://lists.sourceforge.net/lists/listinfo/bitcoin-development\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 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/20150506/a8deea31/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150506/a8deea31/attachment.sig\u003e"}