Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 98BC941C for ; Fri, 17 Jul 2015 16:11:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E808E63 for ; Fri, 17 Jul 2015 16:11:17 +0000 (UTC) Received: by ieik3 with SMTP id k3so80773307iei.3 for ; Fri, 17 Jul 2015 09:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mTV9zYroF+gLQ3CMSpvza24bnQfq8lLcYHaha2hzOMM=; b=HyjPCQ8klKKlBWrlM/6kyPNQofHayMAtNJAwi63U1eVEboSwZh9uw5OR+/X/tHEpaF dyjOIh+WXZ8sx/unDAuaizwrMvuUFhsK7hhYXEoQf1U3nUmPZi4gOED6J23o66DwcOV1 Tx5dAxop1AC62YoU56ZFhdbNmmthLvy4SYhuTeakKyLfqIqfX+NyyoyDalKPhhqDkU7f OxxMbZa28qZfxTZxeebI4jH6+/GYdZbQ2PJ8RpyUVbTWqb2it/z54oMI8amjl0qWuZhY J+NdAvppPPuYWHCglTU8Zjk/ipiCGyJBB4X/+mNnwt5B1y9o5smNXE5TrmoFMbRl7MMU hOvA== MIME-Version: 1.0 X-Received: by 10.50.143.104 with SMTP id sd8mr11807777igb.34.1437149477326; Fri, 17 Jul 2015 09:11:17 -0700 (PDT) Sender: akaramaoun@gmail.com Received: by 10.107.134.196 with HTTP; Fri, 17 Jul 2015 09:11:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2015 16:11:17 +0000 X-Google-Sender-Auth: gtVyPayRRaYpKM8bwSEUs3uvGkw Message-ID: From: Andrew To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a1135f1a61606d5051b147052 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham 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] BIP 102 - kick the can down the road to 2MB 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: Fri, 17 Jul 2015 16:11:18 -0000 --001a1135f1a61606d5051b147052 Content-Type: text/plain; charset=UTF-8 What are you trying to do? Break the ice with a hard fork so that later it becomes easier to do so, with people more complacent towards it? There are many solutions to the scaling problem that do not require a hard fork and are quite simple to implement actually, and don't come with the complications involved with a hard fork. I'm not a reputable developer on this list, so my opinion probably doesn't matter much, but I watched and analyzed this situation closely and I don't like this idea. On Fri, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to > my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 --001a1135f1a61606d5051b147052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What are you trying to do? Break the ice with a hard fork = so that later it becomes easier to do so, with people more complacent towar= ds it? There are many solutions to the scaling problem that do not require = a hard fork and are quite simple to implement actually, and don't come = with the complications involved with a hard fork. I'm not a reputable d= eveloper on this list, so my opinion probably doesn't matter much, but = I watched and analyzed this situation closely and I don't like this ide= a.

On Fr= i, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:
Opening a mailing list thread o= n this BIP:

BIP PR:=C2=A0https://github.com/bitcoin/bips/pu= ll/173




_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev




--
PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647
--001a1135f1a61606d5051b147052--