Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 585E725A for ; Fri, 31 Jul 2015 20:57:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f46.google.com (mail-la0-f46.google.com [209.85.215.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5BDAC266 for ; Fri, 31 Jul 2015 20:57:16 +0000 (UTC) Received: by lacct8 with SMTP id ct8so18260726lac.2 for ; Fri, 31 Jul 2015 13:57:14 -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=LsEvjGzT5zYs6nTzwLArpBjk9ZBqsn4P9RFv29RPfyg=; b=xugSe1tLyc8MQCJWw3aVzmyL05rkf3Xre97cVEbEPYjx/FaeUnCexQQ6HOkib4oLkL noxu0fgTOek8V8PsoRWdVHw44VT5dyYtZ52kToA7SbwA4Z7GVure2bcjyrmwz/UiW4u8 X7W0RAGK4G9iGcjkr55Mmk1TGj2LMYRV38+hqfk3/MmzUvlPuxJ5s81fOkhPcMx+7j+7 KI7964HNfv1+FNWdaVFw8HbWfqZGre5Bw+5/+msgcXtvZmplLmwqwBxs+5WaSiWkwpBI ajNO9UIQa78hFNNbxV35K+ZJqPiBejTBCNhiTLcrIQW43vRloSu+VTSOqF3+3d4PiLZV zMyg== MIME-Version: 1.0 X-Received: by 10.152.28.73 with SMTP id z9mr5252948lag.93.1438376234706; Fri, 31 Jul 2015 13:57:14 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:57:14 -0700 (PDT) Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 13:57:14 -0700 (PDT) In-Reply-To: References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com> <25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com> <4608887.aSM42bDkNk@coldstorage> Date: Fri, 31 Jul 2015 13:57:14 -0700 Message-ID: From: Eric Lombrozo To: Thomas Zander Content-Type: multipart/alternative; boundary=089e0158c02685ed46051c32101b 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:57:17 -0000 --089e0158c02685ed46051c32101b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Having said that, I must admit that the complex filtering mechanisms are pretty clever...they almost make it practical to use SPV...now if only we were committint to structures that can prove the validity of returned datasets and miners actually validated stuff, it might also offer some level of security. On Jul 31, 2015 1:45 PM, "Eric Lombrozo" wrote: > 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 bigge= r > 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 increas= e > the limit. But other things have seemed more important, like specifying t= he > 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 agre= e 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 >> > --089e0158c02685ed46051c32101b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Having said that, I must admit that the complex filtering me= chanisms are pretty clever...they almost make it practical to use SPV...now= if only we were committint to structures that can prove the validity of re= turned datasets and miners actually validated stuff, it might also offer so= me level of security.

On Jul 31, 2015 1:45 PM, "Eric Lombrozo&quo= t; <elombrozo@gmail.com> w= rote:

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 kno= w about the Bitcoin network. And I'm pretty sure I'm not alone in t= his 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. Ju= ly 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
--089e0158c02685ed46051c32101b--