Return-Path: <washington.sanchez@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 22EB1113F for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 8 Sep 2015 15:10:58 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f177.google.com (mail-ig0-f177.google.com [209.85.213.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A0FDD1F8 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 8 Sep 2015 15:10:57 +0000 (UTC) Received: by igcrk20 with SMTP id rk20so76619527igc.1 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 08 Sep 2015 08:10:57 -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=wEM7T3/JQ7Pd9iBNmbOKTdgU0gYH6al0VEkMP3bPKbA=; b=QbeKRNvG424xjnMXGiyoyQB/EgK6PFVt89G2EoQeuekeWGquxmcF4SCfB2FujIhvZH WmBYMxCFA/nJ2dRt0Q81IUbyAC2Trp3HPMXBh6IkAx+r4yXyEznozc5FQOMN6kkdQn7o IOeMOtoyZdjReXKZwuKscps/kuZvA8MFC0fGXaK57FYBK7JkvwsF1T7dt0deE+zLrh2S 7pnd4Rt5LxrFYEUFD29sMUpeyO6EqDkh7GIEhMNXHuzTQRhToPSExrL4JsKN/8NpJddL 6cJoXCZ8UKn24ZiO+y8LQyGf0aE6pYSn7mj72deQGngSlclujfzUDbwFzr6edshgpuy9 YqUw== MIME-Version: 1.0 X-Received: by 10.50.39.80 with SMTP id n16mr22323117igk.44.1441725054983; Tue, 08 Sep 2015 08:10:54 -0700 (PDT) Received: by 10.107.178.12 with HTTP; Tue, 8 Sep 2015 08:10:54 -0700 (PDT) In-Reply-To: <CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com> References: <CAG0bcYzzg4yeQvd27PZu5Fqv1ULS3cKeQHaRZ2zPcM3OASw1cg@mail.gmail.com> <CADJgMztJx1cBFhNOwMgBHJGPmBNPqsTdQbCCjFBmDBSBfTMMUg@mail.gmail.com> <CAAre=yRawFU_WMdE+ReemscYD33ez1PF6VhU2FmWo2fAEcw_Xw@mail.gmail.com> <CALqxMTERUFEFgJ4quz2dWLRw9fD3DkBp-6RO4cuvdBGV2MSyhw@mail.gmail.com> <CAG0bcYzBCsg9xNLGmu4S=PEPjtbd2iBLH52ryswbkRM23OqquA@mail.gmail.com> <CALqxMTFQhFusR5jkEMvRdxDVLZPzWSW5hUHpXoON-K-+xJjpNA@mail.gmail.com> Date: Wed, 9 Sep 2015 01:10:54 +1000 Message-ID: <CAG0bcYw=k_z82buUQ_kApmPgSenNy6FEsdXotLaS4Gn-kZbrKg@mail.gmail.com> From: Washington Sanchez <washington.sanchez@gmail.com> To: Adam Back <adam@cypherspace.org> Content-Type: multipart/alternative; boundary=e89a8f83a259c42c01051f3dc53a 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 <bitcoin-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Tue, 08 Sep 2015 15:10:58 -0000 --e89a8f83a259c42c01051f3dc53a Content-Type: text/plain; charset=UTF-8 1) It's not really clear to me how that would work, but assuming it does then it will go into a basket of attacks that are possible but unlikely due to the economic disincentives to do so. 2) That said, is the Achilles heal of this proposal the lack of a mechanism to lower the block size? 3) Let me put it another way, I've read that both Gavin and yourself are favorable to a dynamic limit on the block size. In your view, what is missing from this proposal, or what variables should be adjusted, to get the rules to a place where you and other Core developers would seriously consider it? On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <adam@cypherspace.org> wrote: > > A selfish mining attack would have to be performed for at least 2000 > blocks over a period of 4 weeks in order to achieve a meager 10% increase > in the block size. > > You seem to be analysing a different attack - I mean that if someone > has enough hashrate to do a selfish mining attack, then setting up a > system that has no means to reduce block-size risks that at a point > where there is excess block-size they can use that free transaction > space to amplify selfish mining instead of collecting transaction > fees. > > Adam > -- ------------------------------------------- *Dr Washington Y. Sanchez <http://onename.com/drwasho>* Co-founder, OB1 <http://ob1.io> Core developer of OpenBazaar <https://openbazaar.org> @drwasho <https://twitter.com/drwasho> --e89a8f83a259c42c01051f3dc53a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div><br></div>1) It's not really clear to me how that= would work, but assuming it does then it will go into a basket of attacks = that are possible but unlikely due to the economic disincentives to do so.<= div><br></div><div>2) That said, is the Achilles heal of this proposal the = lack of a mechanism to lower the block size?=C2=A0</div><div><br></div><div= >3) Let me put it another way, I've read that both Gavin and yourself a= re favorable to a dynamic limit on the block size. In your view, what is mi= ssing from this proposal, or what variables should be adjusted, to get the = rules to a place where you and other Core developers would seriously consid= er it?</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"= >On Wed, Sep 9, 2015 at 12:18 AM, Adam Back <span dir=3D"ltr"><<a href= =3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>= ></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">> = A selfish mining attack would have to be performed for at least 2000 blocks= over a period of 4 weeks in order to achieve a meager 10% increase in the = block size.<br> <br> </span>You seem to be analysing a different attack - I mean that if someone= <br> has enough hashrate to do a selfish mining attack, then setting up a<br> system that has no means to reduce block-size risks that at a point<br> where there is excess block-size they can use that free transaction<br> space to amplify selfish mining instead of collecting transaction<br> fees.<br> <span class=3D"HOEnZb"><font color=3D"#888888"><br> Adam<br> </font></span></blockquote></div><br><br clear=3D"all"><div><br></div>-- <b= r><div class=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><di= v><div>-------------------------------------------</div><div><b><a href=3D"= http://onename.com/drwasho" target=3D"_blank">Dr Washington Y. Sanchez</a><= /b></div><div>Co-founder, <a href=3D"http://ob1.io" target=3D"_blank">OB1</= a></div><div>Core developer of <a href=3D"https://openbazaar.org" target=3D= "_blank">OpenBazaar</a></div><div><a href=3D"https://twitter.com/drwasho" t= arget=3D"_blank">@drwasho</a></div></div><div><br></div></div></div></div><= /div> </div> --e89a8f83a259c42c01051f3dc53a--