rich1.0npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqhttps://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqnjumphttps://nostr.ae📅 Original date posted:2015-05-06 📝 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. - Eric Lombrozo > On May 6, 2015, at 3:30 PM, slush <slush at centrum.cz> wrote: > > 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 <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 <mailto:bitcoin-list at bluematt.me>> wrote: > Recently there has been a flurry of posts by Gavin at > http://gavinandresen.svbtle.com/ <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 <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 <http://ad.doubleclick.net/ddm/clk/290420510;117567292;y> > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development at lists.sourceforge.net <mailto:Bitcoin-development at lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development> > > ------------------------------------------------------------------------------ > 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/20150506/a8deea31/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150506/a8deea31/attachment.sig>