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 97BE0596 for ; Fri, 31 Jul 2015 20:45:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f41.google.com (mail-la0-f41.google.com [209.85.215.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DE00E1BE for ; Fri, 31 Jul 2015 20:45:40 +0000 (UTC) Received: by labiq1 with SMTP id iq1so16592161lab.3 for ; Fri, 31 Jul 2015 13:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kWFvXFg5t2U8D2NgSCogNFDV9a+hKHi7WjePTK+jPXw=; b=owa0f6OXuRFzTLdSEZ2WG+nSjY6zDRtRh6kXwy2cnqXE8o55lHgBq43kgwvZy8n2Jk GLe+un/4wcf/QE8EXdZ4M4qa+DhIIhc2z4DNdlhu0C6hfWsd4UeU+cu9jYvt6EWLzMDp lIG16/z1gw3tWxK4FQB4/bubPAze8P/I2DTgn81lkOlQsZ7pn4uOduq3/scjcnDZcSUh xzz8XkqhViXn7SSKzeofv/pTCuKngrrUpKWJTE58YwB41LyU+P79aWcl7QlJx+yJ/uLe M+CnTAWF4O32yb7J7CoVPswMwMu03txiwwJcuu2uZcapeMs6kVnS/VrNO9/6VwCDmJkL lrBg== MIME-Version: 1.0 X-Received: by 10.152.5.65 with SMTP id q1mr5252571laq.110.1438375538974; Fri, 31 Jul 2015 13:45:38 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:45:38 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:45:38 -0700 (PDT) In-Reply-To: <4608887.aSM42bDkNk@coldstorage> References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com> <4608887.aSM42bDkNk@coldstorage> Date: Fri, 31 Jul 2015 13:45:38 -0700 Message-ID: From: Eric Lombrozo To: Thomas Zander Content-Type: multipart/alternative; boundary=089e013d17540de984051c31e798 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: Jean-Paul Kogelman via bitcoin-dev Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary 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, 31 Jul 2015 20:45:42 -0000 --089e013d17540de984051c31e798 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would love to be able to increase block size. But I have serious doubts about being able to do this safely at this time given what we presently know about the Bitcoin network. And I'm pretty sure I'm not alone in this sentiment. Had we been working on fixing the known issues that most complicate bigger blocks in the last six years, or even in the last three years after many issues had already been well-identified, perhaps we'd be ready to increase the limit. But other things have seemed more important, like specifying the use of X.509 overlay protocols or adding complex filtering mechanisms to the p2p protocol to make it practical to use tx merkle trees...and as a result we're not ready for safely allowing larger blocks. - Eric On Jul 30, 2015 11:43 PM, "Thomas Zander via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Thursday 30. July 2015 16.33.16 Eric Lombrozo via bitcoin-dev wrote: > > I don=E2=80=99t think it=E2=80=99s really a matter of whether we agree= on whether it=E2=80=99s > good > > to raise the block size limit, Gavin. I think it=E2=80=99s a matter of = a > difference > > in priorities. > > Having different priorities is fine, using your time to block peoples > attempts > to increase block size is not showing different priorities, it shows > conflicting > priorities. > Different priorities means you can trust someone else to do things they > care > about while you do things you care about. > -- > Thomas Zander > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --089e013d17540de984051c31e798 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would love to be able to increase block size. But I have s= erious doubts about being able to do this safely at this time given what we= presently know about the Bitcoin network. And I'm pretty sure I'm = not alone in this sentiment.

Had we been working on fixing the known issues that most com= plicate bigger blocks in the last six years, or even in the last three year= s after many issues had already been well-identified, perhaps we'd be r= eady to increase the limit. But other things have seemed more important, li= ke specifying the use of X.509 overlay protocols or adding complex filterin= g mechanisms to the p2p protocol to make it practical to use tx merkle tree= s...and as a result we're not ready for safely allowing larger blocks.<= /p>

- Eric

On Jul 30, 2015 11:43 PM, "Thomas Zander vi= a bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Thursday 30. July 2015 16.33.16 Eric Lombrozo via= bitcoin-dev wrote:
>=C2=A0 I don=E2=80=99t think it=E2=80=99s really a matter of whether we= agree on whether it=E2=80=99s good
> to raise the block size limit, Gavin. I think it=E2=80=99s a matter of= a difference
> in priorities.

Having different priorities is fine, using your time to block peoples attem= pts
to increase block size is not showing different priorities, it shows confli= cting
priorities.
Different priorities means you can trust someone else to do things they car= e
about while you do things you care about.
--
Thomas Zander
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--089e013d17540de984051c31e798--