From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yq8F8-0004ys-Oc for bitcoin-development@lists.sourceforge.net; Wed, 06 May 2015 22:56:42 +0000 X-ACL-Warn: Received: from mail-yk0-f177.google.com ([209.85.160.177]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yq8F6-00070M-SV for bitcoin-development@lists.sourceforge.net; Wed, 06 May 2015 22:56:42 +0000 Received: by ykeo186 with SMTP id o186so6814717yke.0 for ; Wed, 06 May 2015 15:56:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=OsDA9dDM4GM8Xe1Yg0z7+/kPIxoGC/OHn1bTthk7OFQ=; b=PyFSHvKEFQyQxVIkvpdAsTa8HZSj1CEYSnmANbKMgIP8mZrNrW6jtjOCH0AoxawL0J 7TAxa+z+KozjBkSMY3gAabe70OtmZCGOfO0Utv3/F+vjWtpZCWdLmGcrU8hA5ZVKaSLj Cc88uvwZmazVc3iK5BfHZ0L3cRikJEDM2yAue1XEl1tuGh1vPI4A9u5BK4ScXEewvCIp xRw9DzxYLzyonyGNfXN2Y9JxYqjle2DCrljBkCPSldHlu7IJSb8kDpiD/1dhdgzGQuOO w++7N6NZNkaHnRA/PmJXru+N7zRbOVRD0hE/C12hr53Dtkufl6uPo41GphlFJQoA0aY2 4WGw== X-Gm-Message-State: ALoCoQmMB+ZXORNmVv393SGY4EDpDBrC/6hnPNmTYZRmOKW2e+hpzBOn7QM64b7L1o83EpTxOv54 X-Received: by 10.170.168.133 with SMTP id k127mr896794ykd.66.1430951442691; Wed, 06 May 2015 15:30:42 -0700 (PDT) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.129.52.213 with HTTP; Wed, 6 May 2015 15:30:12 -0700 (PDT) In-Reply-To: <554A91BE.6060105@bluematt.me> References: <554A91BE.6060105@bluematt.me> From: slush Date: Thu, 7 May 2015 00:30:12 +0200 X-Google-Sender-Auth: UVDpGic6-r2B8aBpSNk_A-buVrY Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary=001a113967be6eca8d051571589c X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Yq8F6-00070M-SV Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2015 22:56:42 -0000 --001a113967be6eca8d051571589c Content-Type: text/plain; charset=ISO-8859-1 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 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a113967be6eca8d051571589c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't have strong opinion @ block size topic.
But if there'll be a fork, PLEASE, include=A0SIGHASH_WITHI= NPUTVALUE (h= ttps://bitcointalk.org/index.php?topic=3D181734.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@bluematt.me> wrote:
Recently there has been a flurry of posts by Gavin at
http://gavin= andresen.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<= br> 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-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a113967be6eca8d051571589c--