Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 6902D40D for ; Sun, 11 Dec 2016 05:29:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg0-f45.google.com (mail-pg0-f45.google.com [74.125.83.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADA9E130 for ; Sun, 11 Dec 2016 05:29:10 +0000 (UTC) Received: by mail-pg0-f45.google.com with SMTP id 3so23050865pgd.0 for ; Sat, 10 Dec 2016 21:29:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ePyfoSwbZznEtpdVlyGz6LX4ki+UHlg07z2mzAu9OZI=; b=jxG1VAtpoa8aPxQbjIMR3gM0HjVDaWUCxls8iFAoYWZE/L4PURH3kWpK+IegfMKc70 lwY0Ugj+c3SrZF6fzbUwASIg1c4D0LDKQ/wyuaZE09vv/a70DK/zzA/Su0Nar18EKcN2 yJjBgbeP7QKN608Ukq7z1i6uis6Qdex1Bv4LwY8DgaQHoyKG/rSsyys/oBUYb9EqzS7w 08bzBT+o77Zo3/WfbCrQWJXQjzy3lF06lz3EP2GXgY2gEN/NmjxWxwIycpiFyH1gS1lT c0aLpwTANVfPWSE58fD/bJTDZUv/+frQT1qQ+tlDUL9uZ9XGTguUujYLR1VKPvBvNrMe OmJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ePyfoSwbZznEtpdVlyGz6LX4ki+UHlg07z2mzAu9OZI=; b=j7agyMERpt3ESrE1NjfjxzuIOHXzi2O1eHj2+vEMk44Ex0gasVXYyuGVxcWtc0VMPB fgZ/RGHUaikx0EtWvwPYhjznpWHcJjL8LNL5WrSLu1LKesgbWCtpr6VIQ0OqDvSgvyla qr0r/hhRsi4ZavHQ9vBKxioYjEZQo1BhpXUArT2gL5E9xzv4qPIkq5ZhDPP7wbzc3Qa9 fOZMAdmRgcaYnLot27N6jVPMc9W16Kfh7YI2oWmrYl3/3dosKbmea9yXetBrDqRtxShM b+og0LjP1mXhJnqlur5kl66KdDF3ZZ/GeSAYKBTnUiFaoqeAxEWtWM51lfyKK7aWCmKe 522w== X-Gm-Message-State: AKaTC01oHKu9eKsNiicfXn71xatnDbjfFCgONmCOm8SYT1BqtCXqEMRW8YWmW3jv+JhgQw== X-Received: by 10.84.176.100 with SMTP id u91mr170980227plb.7.1481434150267; Sat, 10 Dec 2016 21:29:10 -0800 (PST) Received: from ?IPv6:2601:600:9000:d69e:401e:9c01:84f9:85ce? ([2601:600:9000:d69e:401e:9c01:84f9:85ce]) by smtp.gmail.com with ESMTPSA id d197sm67590895pfd.38.2016.12.10.21.29.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Dec 2016 21:29:09 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Sat, 10 Dec 2016 21:29:08 -0800 Content-Transfer-Encoding: 7bit Message-Id: <2C3BEC33-BAD0-4CFB-8FE1-BBB18020E3D8@voskuil.org> References: To: Daniele Pinna , Bitcoin Protocol Discussion X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 11 Dec 2016 07:04:11 +0000 Subject: Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 05:29:11 -0000 --Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The presumption of the mining aspect of the Bitcoin security model is that t= he mining majority is a broadly distributed set of independent people, not o= ne person who controls a majority of the hash power.=20 You seem to have overlooked a qualifier in your Satoshi quote: "...by nodes t= hat are not cooperating to attack the network". A single miner with majority= hash power is of course cooperating with himself. At that point the questio= n of whether he is attacking the network is moot, it's his network. I believe that Pieter's point is that a system optimized for orphan rate may= in effect be optimized for a single entity providing all double spend prote= ction. That works directly against the central principle of Bitcoin security= . The security of the money is a function of the number of independent miner= s and sellers. e > On Dec 10, 2016, at 7:17 PM, Daniele Pinna via bitcoin-dev wrote: >=20 > How is the adverse scenario you describe different from a plain old 51% at= tack? Each proposed protocol change where 51% or more of the network can p= otentially game the rules and break the system should be considered just as a= cceptable/unacceptable as another.=20 >=20 > There comes a point where some form of basic honesty must be assumed on be= half of participants benefiting from the system working properly and reliabl= y.=20 >=20 > Afterall, what magic line of code prohibits all miners from simultaneously= turning all their equipment off... just because?=20 >=20 > Maybe this 'one': >=20 > "As long as a majority of CPU power is controlled by nodes that are not co= operating to attack the network, they'll generate the longest chain and outp= ace attackers. The network itself requires minimal structure." >=20 > Is there such a thing as an unrecognizable 51% attack? One where the rema= ining 49% get dragged in against their will?=20 >=20 > Daniele=20 >=20 >> On Dec 10, 2016 6:39 PM, "Pieter Wuille" wrote:= >>> On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev wrote: >>> We have models for estimating the probability that a block is orphaned g= iven average network bandwidth and block size.=20 >>>=20 >>> The question is, do we have objective measures of these two quantities? C= ouldn't we target an orphan_rate < max_rate?=20 >>=20 >> Models can predict orphan rate given block size and network/hashrate topo= logy, but you can't control the topology (and things like FIBRE hide the eff= ect of block size on this as well). The result is that if you're purely opti= mizing for minimal orphan rate, you can end up with a single (conglomerate o= f) pools producing all the blocks. Such a setup has no propagation delay at a= ll, and as a result can always achieve 0 orphans. >>=20 >> Cheers, >>=20 >> --=20 >> Pieter >>=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The presumption of the mini= ng aspect of the Bitcoin security model is that the mining majority is a bro= adly distributed set of independent people, not one person who controls a ma= jority of the hash power. 

You seem to have ov= erlooked a qualifier in your Satoshi quote: "...by nodes that are not cooperating to attack th= e network". A single miner with majority hash power is of course cooperating= with himself. At that point the question of whether he is attacking the net= work is moot, it's his network.

I believe th= at Pieter's point is that a system optimized for orphan rate may in effect b= e optimized for a single entity providing all double spend protection. That w= orks directly against the central principle of Bitcoin security. The security of the money is a= function of the number of independent miners and sellers.
=
e

On Dec 10, 2016, at 7:17 PM, Daniele Pinna vi= a bitcoin-dev <b= itcoin-dev@lists.linuxfoundation.org> wrote:

How is the adverse scenario you descri= be different from a plain old 51% attack? Each proposed protocol change &nbs= p;where 51% or more  of the network can potentially game the rules and b= reak the system should be considered just as acceptable/unacceptable as anot= her. 

There comes a point w= here some form of basic honesty must be assumed on behalf of participants be= nefiting from the system working properly and reliably. 

Afterall, what magic line of code prohibi= ts all miners from simultaneously turning all their equipment off...  j= ust because? 

Maybe t= his 'one':

"As long as a m= ajority of CPU power is controlled by nodes that are not cooperating to atta= ck the network, they'll generate the longest chain and outpace attackers. Th= e network itself requires minimal structure."

Is there such a thing as an unrecognizable 51% attack?&= nbsp; One where the remaining 49% get dragged in against their will? 

Daniele 
<= div class=3D"gmail_extra">
On Dec 10, 2016 6:3= 9 PM, "Pieter Wuille" <pieter.= wuille@gmail.com> wrote:
On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna vi= a bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:
We have models for esti= mating the probability that a block is orphaned given average network bandwi= dth and block size. 

The question is, d= o we have objective measures of these two quantities? Couldn't we target an o= rphan_rate < max_rate? 

= Models can predict orphan rate given block size and network/hashrate topolog= y, but you can't control the topology (and things like FIBRE hide the effect= of block size on this as well). The result is that if you're purely optimiz= ing for minimal orphan rate, you can end up with a single (conglomerate of) p= ools producing all the blocks. Such a setup has no propagation delay at all,= and as a result can always achieve 0 orphans.

Cheers,
=
--
Pieter

____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-E34852DE-636F-49E5-BDAB-EE0C1CDF457C--