rich1.0npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6https://nostr.ae/npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6njumphttps://nostr.ae📅 Original date posted:2015-05-06 📝 Original message:I don't have strong opinion @ block size topic. But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE ( https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All developers of lightweight (blockchain-less) clients will adore you! slush On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list at bluematt.me> wrote: > Recently there has been a flurry of posts by Gavin at > http://gavinandresen.svbtle.com/ which advocate strongly for increasing > the maximum block size. However, there hasnt been any discussion on this > mailing list in several years as far as I can tell. > > Block size is a question to which there is no answer, but which > certainly has a LOT of technical tradeoffs to consider. I know a lot of > people here have varying levels of strong or very strong opinions about > this, and the fact that it is not being discussed in a technical > community publicly anywhere is rather disappointing. > > So, at the risk of starting a flamewar, I'll provide a little bait to > get some responses and hope the discussion opens up into an honest > comparison of the tradeoffs here. Certainly a consensus in this kind of > technical community should be a basic requirement for any serious > commitment to blocksize increase. > > Personally, I'm rather strongly against any commitment to a block size > increase in the near future. Long-term incentive compatibility requires > that there be some fee pressure, and that blocks be relatively > consistently full or very nearly full. What we see today are > transactions enjoying next-block confirmations with nearly zero pressure > to include any fee at all (though many do because it makes wallet code > simpler). > > This allows the well-funded Bitcoin ecosystem to continue building > systems which rely on transactions moving quickly into blocks while > pretending these systems scale. Thus, instead of working on technologies > which bring Bitcoin's trustlessness to systems which scale beyond a > blockchain's necessarily slow and (compared to updating numbers in a > database) expensive settlement, the ecosystem as a whole continues to > focus on building centralized platforms and advocate for changes to > Bitcoin which allow them to maintain the status quo[1]. > > Matt > > [1] https://twitter.com/coinbase/status/595741967759335426 > > > ------------------------------------------------------------------------------ > 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/6bdab3de/attachment.html>