Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yq8OI-0003B3-No for bitcoin-development@lists.sourceforge.net; Wed, 06 May 2015 23:06:10 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.171 as permitted sender) client-ip=209.85.192.171; envelope-from=elombrozo@gmail.com; helo=mail-pd0-f171.google.com; Received: from mail-pd0-f171.google.com ([209.85.192.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yq8OH-0005hp-2m for bitcoin-development@lists.sourceforge.net; Wed, 06 May 2015 23:06:10 +0000 Received: by pdea3 with SMTP id a3so22969494pde.3 for ; Wed, 06 May 2015 16:06:03 -0700 (PDT) X-Received: by 10.70.35.6 with SMTP id d6mr1732918pdj.166.1430953563419; Wed, 06 May 2015 16:06:03 -0700 (PDT) Received: from [192.168.1.101] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by mx.google.com with ESMTPSA id gj9sm104450pbc.77.2015.05.06.16.06.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 May 2015 16:06:02 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Wed, 6 May 2015 16:06:00 -0700 Message-Id: <0F6580B4-8BB5-4287-94DE-5F625AC1BBA3@gmail.com> References: <554A91BE.6060105@bluematt.me> To: slush X-Mailer: Apple Mail (2.2098) X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (elombrozo[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Yq8OH-0005hp-2m 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 23:06:10 -0000 --Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E Content-Type: multipart/alternative; boundary="Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045" --Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I don=92t really have a strong opinion on block size either=85but if = we=92re going to do a hard fork, let=92s use this as an opportunity to = create a good process for hard forks (which we=92ll 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=92s not just do a one-off ad-hoc = thing. - Eric Lombrozo > On May 6, 2015, at 3:30 PM, slush wrote: >=20 > I don't have strong opinion @ block size topic. >=20 > But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE = (https://bitcointalk.org/index.php?topic=3D181734.0 = ) or its = alternative. All developers of lightweight (blockchain-less) clients = will adore you! >=20 > slush >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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). >=20 > 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]. >=20 > Matt >=20 > [1] https://twitter.com/coinbase/status/595741967759335426 = >=20 > = --------------------------------------------------------------------------= ---- > 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 = >=20 > = --------------------------------------------------------------------------= ---- > 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 --Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I don=92t really have a strong opinion on block size = either=85but if we=92re going to do a hard fork, let=92s use this as an = opportunity to create a good process for hard forks (which we=92ll = 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=92s not just do = a one-off ad-hoc thing.

- Eric Lombrozo

On = May 6, 2015, at 3:30 PM, slush <slush@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=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://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-developmen= t

= --------------------------------------------------------------------------= ----
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-developmen= t

= --Apple-Mail=_DBE70104-695C-402C-9D5B-D4F063AE4045-- --Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVSp5YAAoJEJNAI64YFENUhUgQAKiDsn5VU/60D8xyGxQ6G+bM AG8Z5Qkyp8kfoz6UM6Em0MkXeEaaawt4QH1hWZo6x0B/yCKzD1oR8Yhq2Uw9plOZ qeEesjsLjWaZUULWdNhtJidGXw2ntsyg8OGsETEzOMRx64+52Gx+1yz9IRzhVey5 21JvGKYBzbTmCX2nWmptjqjY5aAOZrhidTWDMkD/d60XsHktWz8DDHlpxVp1/1j7 /tzNb3hVfNQg9dAOhQQSyMCavaQ0IlqC/7oV2Pr/tQIUN0gTKMYZKFhk53tPxcqK 8KteGQ5WqGYhXZr2mMXV1stNV0eEctYgTAdHo1mjfhJIJUOnVupIpQTM3V+0RH0+ Bi7Jd8MgbZVlVQk2Xu9IFag1EPQGfBWEPyy3vWswnSa5woZB9fZNDjGDAHbyg5M4 lRXy31JHaseDsiJf1L5rglUl8LKoXgYKAiCReEtApcPVsgfMDvYRxSDUDDVbtGbn aAPRBPGu00fn8tnfjjF55YVsU1rMf/LchzoiXO/RWwJUuxPJ39KyyzcPVmtGNc6t 9eWApSqa96Qp1T2g41lfLxYWSM91zk1dbc1R+oI0ROGYK4mobOK3H49jmrvdMHCv DQ36Yy1w+wTC9fO37Yw9uVXLjpR7MfEua+Dkv9IWl/0nsWIm75TIC5k7SlShHTC1 1A+df3+5zdgeTnUq1DPg =Kfjc -----END PGP SIGNATURE----- --Apple-Mail=_74CBEB40-D60B-4837-B32F-8AF89A46794E--