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-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzSEL-0008Na-JL for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 16:06:25 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.172 as permitted sender) client-ip=209.85.223.172; envelope-from=ajriesgo@gmail.com; helo=mail-ie0-f172.google.com; Received: from mail-ie0-f172.google.com ([209.85.223.172]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzSEF-0004dW-Ty for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 16:06:25 +0000 Received: by ieczm2 with SMTP id zm2so112702157iec.1 for ; Mon, 01 Jun 2015 09:06:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.56.104 with SMTP id z8mr14603538igp.45.1433174774566; Mon, 01 Jun 2015 09:06:14 -0700 (PDT) Received: by 10.107.129.226 with HTTP; Mon, 1 Jun 2015 09:06:14 -0700 (PDT) In-Reply-To: References: <554BE0E1.5030001@bluematt.me> Date: Mon, 1 Jun 2015 18:06:14 +0200 Message-ID: From: =?UTF-8?Q?=C3=81ngel_Jos=C3=A9_Riesgo?= To: Mike Hearn Content-Type: multipart/alternative; boundary=089e0158a84256db330517770199 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 (ajriesgo[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: 1YzSEF-0004dW-Ty Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements 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: Mon, 01 Jun 2015 16:06:25 -0000 --089e0158a84256db330517770199 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi everyone, I'm a long-time lurker of this mailing list but it's the first time I post here, so first of all I'd like to thank all of the usual contributors for the great insights and technical discussions that can be found here. As this is such a momentous point in the history of Bitcoin, I'd just like to throw in my opinion too. First, I agree with Oliver Egginger's message that it's much more elegant to keep the numbers as powers of 2 rather than introducing somewhat arbitrary numbers like 20. This also makes it easier to count the level of support for what would be a clear spectrum of discrete levels (1, 2, 4, ... 32, 64, ..., infinite). If a temporary peace accord can be reached with a value like 8 or 16, this will buy us some time for both the user base to continue growing without hitting the limit and for newer technologies like the lightning network to be developed and tested. We will also see whether the relatively small increase causes any unexpected harm or whether (as I expect) everything continues to run smoothly. Personally, I'd like to see Bitcoin grow and become what I think most Bitcoin users like myself expect from it: that it should be a payment network directly accessible to people all over the world. In my opinion, it is the proposition of Bitcoin as a form of electronic money that additionally makes it a good store of value. I don't believe in the idea that it can exist as just some sort of digital gold for a geeky financial elite. And I haven't been persuaded by those who claim the scarcity of block space is an economic fundamental of Bitcoin either. It seems to me there's a lot of batty economic ideas being bandied about regarding the supposed long-term value of the cap without much justification. In this sense, my sympathies are with those who want to remove the maximum block size cap. This was after all the original idea, so it's not fair for the 1MB camp to claim that they're the ones preserving the essences of Bitcoin. But, anyway, I also think that a consensus at this point would be much better than a head-on confrontation between two incompatible pieces of software competing to gain the favour of a majority of exchanges and merchants. With this in mind, can't we accept the consensus that raising the hard-coded limit to a value like 8MB buys us a bit of time and should be at least palatable to everyone? This may not be what the staunch supporters of the 1MB limit want, but it's also not what I and others would want, so we're talking about finding some common ground here, and not about one side getting their way to the detriment or humiliation of the other. The problem with a compromise based on a one-off maximum-size increase, of course, is that we're just kicking the can down the road and the discussion will continue. It's not a solution I like, but how can we get people like say Greg Maxwell or Pieter Wuille to accept something more drastic? If they find a new maximum-size cap acceptable, then it could be a reasonable compromise. A new cap will let us test the situation and see how the Bitcoin environment reacts. The next time the discussion crops up (probably very soon, I know...), we may all have a better understanding of the implications. =C3=81ngel Jos=C3=A9 Riesgo --089e0158a84256db330517770199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi everyone,

I'm a long-= time lurker of this mailing list but it's the first time I post here, s= o first of all I'd like to thank all of the usual contributors for the = great insights and technical discussions that can be found here. As this is= such a momentous point in the history of Bitcoin, I'd just like to thr= ow in my opinion too.

First, I agree with Oliver E= gginger's message that it's much more elegant to keep the numbers a= s powers of 2 rather than introducing somewhat arbitrary numbers like 20. T= his also makes it easier to count the level of support for what would be a = clear spectrum of discrete levels (1, 2, 4, ... 32, 64, ..., infinite). If = a temporary peace accord can be reached with a value like 8 or 16, this wil= l buy us some time for both the user base to continue growing without hitti= ng the limit and for newer technologies like the lightning network to be de= veloped and tested. We will also see whether the relatively small increase = causes any unexpected harm or whether (as I expect) everything continues to= run smoothly.

Personally, I'd like to see Bit= coin grow and become what I think most Bitcoin users like myself expect fro= m it: that it should be a payment network directly accessible to people all= over the world. In my opinion, it is the proposition of Bitcoin as a form = of electronic money that additionally makes it a good store of value. I don= 't believe in the idea that it can exist as just some sort of digital g= old for a geeky financial elite. And I haven't been persuaded by those = who claim the scarcity of block space is an economic fundamental of Bitcoin= either. It seems to me there's a lot of batty economic ideas being ban= died about regarding the supposed long-term value of the cap without much j= ustification. In this sense, my sympathies are with those who want to remov= e the maximum block size cap. This was after all the original idea, so it&#= 39;s not fair for the 1MB camp to claim that they're the ones preservin= g the essences of Bitcoin.

But, anyway, I also thi= nk that a consensus at this point would be much better than a head-on confr= ontation between two incompatible pieces of software competing to gain the = favour of a majority of exchanges and merchants. With this in mind, can'= ;t we accept the consensus that raising the hard-coded limit to a value lik= e 8MB buys us a bit of time and should be at least palatable to everyone? T= his may not be what the staunch supporters of the 1MB limit want, but it= 9;s also not what I and others would want, so we're talking about findi= ng some common ground here, and not about one side getting their way to the= detriment or humiliation of the other.

The proble= m with a compromise based on a one-off maximum-size increase, of course, is= that we're just kicking the can down the road and the discussion will = continue. It's not a solution I like, but how can we get people like sa= y Greg Maxwell or Pieter Wuille to accept something more drastic? If they f= ind a new maximum-size cap acceptable, then it could be a reasonable compro= mise. A new cap will let us test the situation and see how the Bitcoin envi= ronment reacts. The next time the discussion crops up (probably very soon, = I know...), we may all have a better understanding of the implications.

=C3=81ngel Jos=C3=A9 Riesgo

--089e0158a84256db330517770199--