[Bitcoin-development] Block Size Increase

Eric Lombrozo elombrozo at gmail.com
Wed May 6 23:06:00 UTC 2015


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>


More information about the bitcoin-dev mailing list