From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D4B2DBC2 for ; Tue, 30 Jun 2015 16:03:31 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D7C219E for ; Tue, 30 Jun 2015 16:03:05 +0000 (UTC) Received: by iebmu5 with SMTP id mu5so15561905ieb.1 for ; Tue, 30 Jun 2015 09:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ricmoo.com; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=e/NIbklC/nY1+Gc6MKjiaiv4W4raUfl6i7FnwC9TlZk=; b=gcsaZ+hX3O1Uln+f+L68y9lKZAa351edLEAMvDV6sLKBoi6UKPIily0yd0BE3E3ll8 uu1R5DwY3CbgVIJUZrjJggqTBx6YcLaDpHl25cq18c5mbIs/s7Th3lg8GMjJSr4J4ozN TJsQ56OzvXnv3WvDtDOnJE36jfURf+rIwdaes= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=e/NIbklC/nY1+Gc6MKjiaiv4W4raUfl6i7FnwC9TlZk=; b=CynPzXeQzkEkjbyOzKAkLf6g9sV42XZyVjO0yUcpCrEFeC0S929cSCRUTNarE7BzVd 9q4ILlFQor/+ZfksEnhoP53avB8m6oV5I0C1iw2msE8l6SJTBo2ZJLKKsRZdd9Y4uLRx TEzrJH9uXkSDLi19U3w6bEbM5qtbZrrCva9LRSV+fx42I+A8aiOWUHIx1Qf3f/mem/Nm ZvptW6ml9Sp1KAZ7iG5ga/weFMrXj2gJJiqWgzqZntBR2Tbs7gb4tzXjHAGtZImnhij2 ZSVICMImjn5TK3U+hOHJkhxLi8AqIdJms6dkthcd/aZtaXR5ORfVJqg7JgWSOxKFmtXD Dkrg== X-Gm-Message-State: ALoCoQmRwfgBC0e3yJclh1/0aPReYBmLHXUddJv3dAHUbSCaAo3uFBpIwysGxxJQlJurCtgJFeb7 X-Received: by 10.50.7.68 with SMTP id h4mr26358474iga.40.1435680184757; Tue, 30 Jun 2015 09:03:04 -0700 (PDT) Received: from [192.168.2.79] (65-110-212-240.cpe.pppoe.ca. [65.110.212.240]) by mx.google.com with ESMTPSA id h7sm8013417igt.3.2015.06.30.09.03.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jun 2015 09:03:02 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_60150D31-74EB-44BB-B11E-A92CEB2FF2CF" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Richard Moore In-Reply-To: Date: Tue, 30 Jun 2015 12:03:02 -0400 Message-Id: <8F54D4D6-A2FE-4F20-9927-712187B2B03A@ricmoo.com> References: To: Michael Naber X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_LOW autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Block size increase oppositionists: please clearly define what you need done to increase block size to a static 8MB, and help do it X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2015 16:03:31 -0000 --Apple-Mail=_60150D31-74EB-44BB-B11E-A92CEB2FF2CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not planning to take a firm stance against or for, but one = problem with your analogy is that airplanes [currently] are not elastic = (until we get TARDIS technology, or semi-TARDIS-like technology); they = take up space and resources proportional to their capacity. It is not the block size that is increasing, it is the *maximum* block = size=E2=80=A6 So, it=E2=80=99s more like saying the *maximum* airplane = size is increasing, which I think may be somewhat true (although, I = agree, probably not exponentially). It would be more like an airplane = whose capacity was doubling every two years, but would shrink when that = extra capacity was not needed and only consume the maintenance, fuel, et = cetera needed for its current size. My semi-firm-ish stance is that kicking the can down the road with a = static increase is less better. We can always soft-fork the limit down = if the *actual* block size is growing too fast. When (and/or if) we need = to. I also think 8MB is a rather large jump, for either static or = dynamic. *shrug* RicMoo > On Jun 30, 2015, at 11:34 AM, Michael Naber = wrote: >=20 > As you know I'm trying to lobby for a block size increase to a static = 8MB.=20 >=20 > I'm happy to try to get the testing done that people want done for = this, but I think the real crux of this issue is that we need to get = consensus that we intend to continually push the block size upward as = bounded only by technology. >=20 > Imagine an engineer (Gavin) at Boeing (Bitcoin Core) said he was going = to build an airplane (block) that was going to move 8x as many people = (transactions) as today=E2=80=99s planes (blocks), all while costing = about the same amount to operate. Imagine he then went on to tell you = that he expects to double the plane=E2=80=99s (block's) capacity every = two years!=20 >=20 > Without full planes (blocks), will the airlines (miners) go out of = business, since planes (blocks) will never be full and the cost to add = people (transactions) to a plane (block) will approach zero? Probably = not. Airlines (miners) still have to pay for pilots, security screening = staff, fuel, etc (engineers, hash rate, electricity, etc) so even if = their airplanes (blocks) can hold limitless people (transactions), they = would still have to charge sufficient fees to stay in business. >=20 > What tests do you need done to move to 8MB? Pitch in and help get = those tests done; agree that we'll run more tests next year or the year = after when technology might allow for 16 MB blocks. Do you really want = to be the guy holding back bigger planes? Do you really want to = artificially constrain block size below what technology allows?=20 >=20 > In the face of such strong market demand for increased capacity in = globally aware global consensus, do you really think you can prevent = supply from meeting demand when the technology exists to deliver it? Do = you really want to force a fork because you and others won't agree to a = simple raise to a static 8MB?=20 >=20 > Do what's best for Bitcoin and define what needs to get done to agree = to a simple block size increase to a static 8MB. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = .=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2= =B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8=C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8= =C2=B8.=C2=B7=C2=B4=C2=AF`=C2=B7.=C2=B8><(((=C2=BA> Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ricmoo@geneticmistakes.com www: http://GeneticMistakes.com --Apple-Mail=_60150D31-74EB-44BB-B11E-A92CEB2FF2CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I=E2=80=99m not planning to take a firm = stance against or for, but one problem with your analogy is that = airplanes [currently] are not elastic (until we get TARDIS technology, = or semi-TARDIS-like technology); they take up space and resources = proportional to their capacity.

It is not the block size that is = increasing, it is the *maximum* block size=E2=80=A6 So, it=E2=80=99s = more like saying the *maximum* airplane size is increasing, which I = think may be somewhat true (although, I agree, probably not = exponentially). It would be more like an airplane whose capacity was = doubling every two years, but would shrink when that extra capacity was = not needed and only consume the maintenance, fuel, et cetera needed for = its current size.

My semi-firm-ish stance is that kicking the can down the road = with a static increase is less better. We can always soft-fork the limit = down if the *actual* block size is growing too fast. When (and/or if) we = need to. I also think 8MB is a rather large jump, for either static or = dynamic.

*shrug*

RicMoo


On = Jun 30, 2015, at 11:34 AM, Michael Naber <mickeybob@gmail.com>= wrote:

As you know I'm trying to lobby for a block size = increase to a static 8MB. 

I'm happy to try to get the testing done that people want = done for this, but I think the real crux of this issue is that we need = to get consensus that we intend to continually push the block size = upward as bounded only by technology.

Imagine an engineer = (Gavin) at Boeing (Bitcoin Core) said he was going to build an airplane = (block) that was going to move 8x as many people (transactions) as = today=E2=80=99s planes (blocks), all while costing about the same amount = to operate. Imagine he then went on to tell you that he expects to = double the plane=E2=80=99s (block's) capacity every two = years! 

Without full planes (blocks), will the airlines (miners) go = out of business, since planes (blocks) will never be full and the cost = to add people (transactions) to a plane (block) will approach zero? = Probably not. Airlines (miners) still have to pay for pilots, security = screening staff, fuel, etc (engineers, hash rate, electricity, etc) so = even if their airplanes (blocks) can hold limitless people = (transactions), they would still have to charge sufficient fees to stay = in business.

What tests do you need done to move to 8MB? Pitch in and help = get those tests done; agree that we'll run more tests next year or the = year after when technology might allow for 16 MB blocks. Do you really = want to be the guy holding back bigger planes? Do you really want to = artificially constrain block size below what technology = allows? 

In= the face of such strong market demand for increased capacity in = globally aware global consensus, do you really think you can prevent = supply from meeting demand when the technology exists to deliver it? Do = you really want to force a fork because you and others won't agree to a = simple raise to a static 8MB? 

Do what's best for Bitcoin and define = what needs to get done to agree to a simple block size increase to a = static 8MB.
_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= br class=3D"">


Richard Moore ~ Founder
Genetic = Mistakes Software inc.
phone: (778) 882-6125
email: ricmoo@geneticmistakes.com
www: http://GeneticMistakes.com

= --Apple-Mail=_60150D31-74EB-44BB-B11E-A92CEB2FF2CF--