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&#39;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&#39;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">&lt;<a href=
=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a>=
&gt;</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"">&gt; =
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--