{"type":"rich","version":"1.0","author_name":"npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6","author_url":"https://nostr.ae/npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-06\n📝 Original message:I don't have strong opinion @ block size topic.\n\nBut if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (\nhttps://bitcointalk.org/index.php?topic=181734.0) or its alternative. All\ndevelopers of lightweight (blockchain-less) clients will adore you!\n\nslush\n\nOn Thu, May 7, 2015 at 12:12 AM, Matt Corallo \u003cbitcoin-list at bluematt.me\u003e\nwrote:\n\n\u003e Recently there has been a flurry of posts by Gavin at\n\u003e http://gavinandresen.svbtle.com/ 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\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 Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/6bdab3de/attachment.html\u003e"}