Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 809474A5 for ; Sun, 11 Dec 2016 09:26:06 +0000 (UTC) X-Greylist: delayed 00:05:02 by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 972AC135 for ; Sun, 11 Dec 2016 09:26:05 +0000 (UTC) Received: from mail-qk0-f178.google.com ([209.85.220.178]) by mrelay.perfora.net (mreueus002 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MEEAQ-1cR0n03mZM-00FRlD for ; Sun, 11 Dec 2016 10:21:03 +0100 Received: by mail-qk0-f178.google.com with SMTP id n204so57707737qke.2 for ; Sun, 11 Dec 2016 01:21:02 -0800 (PST) X-Gm-Message-State: AKaTC034WtcbHPk0JPsJhBlRU+dMFqQhOckLooFCY4Xw/l3g5PozwahMUkjX/EAgkg+jP9vz+yjQTsjoSZXF4A== X-Received: by 10.55.4.134 with SMTP id 128mr75259399qke.281.1481448061845; Sun, 11 Dec 2016 01:21:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.144.130 with HTTP; Sun, 11 Dec 2016 01:21:01 -0800 (PST) Received: by 10.12.144.130 with HTTP; Sun, 11 Dec 2016 01:21:01 -0800 (PST) In-Reply-To: References: From: Adam Back Date: Sun, 11 Dec 2016 10:21:01 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Dev , Daniele Pinna Content-Type: multipart/alternative; boundary=001a114c89467af99205435e8110 X-Provags-ID: V03:K0:5EmXJ0f9AVW2F4gJULfRoRr5AB4bwPzr6hFYOvVRNlNElyf2r22 Z5d/oLAbCmKf/R0meOzYMzju2bs79hDgl7JmnqyG5alGX7wzkRbIXMyRb/6eqf9oC/kFSyT JXQtgAM+f5SmJWY2XAC0QIc7LzBUEp3BGbpholIyVeKE11iDyRAuRCOqxeXcWjSyDQ4KfWM b+jDNqsl+VxknPt45VRUg== X-UI-Out-Filterresults: notjunk:1;V01:K0:G8nmpT3u298=:6a60DTc3upM3ZuP6OP2swv DiobCY0Mxb0lf1vkVZykucAU5AIESqyrdi0zKYWS17AOUzOsUoxg9efv8k70i3VTRZw9OiU9Q DW97GUHnTpg6yKcs1iVyKLOwroBlfwLjWVADZYh/eEAdjET4P7+x8wJdFgsd2ZnhgCLxQ7d7n D/oD6lGszsx9yeKdymLbnkjHRJYcKrXaQZ6qAXgHV0ZgtQB6uKA6eVsBRR4BRLXRfmI9XZhH3 fLq+S3AaItLh/epiEwXBLn1GRqwXaNWn7uzuUXh0zqtcMUVzCC2jvQSe6iodjMrmbYsvI3Vqb R1n/c2XmUCgqHKjCKBvs0HIFzmlNZXkKnV56FI0c0zrs3T38/EK01QTg2tGknALgEx/SV2iWv wSK7yFBo45OffZK+TPvbVnJlP8/4t4ys7372KrjxRUAolUExMr2SkIiHmUWSjcbfKLyWBKUFb 5fFl3jHxwKw7XmyVJaFPVsM22pdY/du/i5N4y8OcwekXZ9GB2USIbAxPtvxGo+6OVu2Yeo+JW btTMKFqtFspKC4dmdzzEOroidmigErSlZGE7pxAATvAzNr0h90G9pr/zCOz20LgIXsdoaWd64 XPncq0pkchUjLYldeEDTNFRKYb8eAuzZB6E7avT+KpHz9K8QXV4hqbQkEuxQmKOUv0Rr8mnht VWuaL59nVAYCJtSyrsdIPL+7UbJcZnoHjhGIZiwQ76y/X7slyFZ5wKdn+BNn++pfkxshblX8x y/aFMwcCunJc0zgv X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no 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 12:06:51 +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 09:26:06 -0000 --001a114c89467af99205435e8110 Content-Type: text/plain; charset=UTF-8 Well I think empirical game-theory observed on the network involves more types of strategy than honest vs dishonest. At least 4, maybe 5 types of strategy and I would argue lumping the strategies together results in incorrect game theory conclusions and predictions. A) altruistic players (protocol following by principle to be good network citizens, will forgo incremental profits to aid network health) eg aim to decentralize hashrate, will mine stuck transactions for free, run pools with zero fee, put more effort into custom spam filtering, tend to be power users, or long term invested etc. B) honest players (protocol following but non-altruistic or just lazy/asleep run default software, but still leaving some dishonest profit untaken). Eg reject spy mining, but no charitable actions, will not retaliate in kind to semi-honest zero sum attacks that reduce their profits. C) semi-honest (will violate protocol if their attack can be plausibly deniable or argued to be not hugely damaging to network security). Eg spy mining, centralised pools increasing other miners orphan rates. D) rational players (will violate the protocol for profit: will not overtly steal from users via double spends, but anything short particularly disadvantaging other miners even if it results in centralisation is treated as fair game) eg selfish mining. Would increase block size by filling with pay to self transactions, if it increased orphans for others. E) dishonest players (aka hyper-rational: will actually steal from users probabilistically if possible, not as worried about detection). Eg double spend and probabilistic double spends (against onchain gambling games). Would DDoS competing pools. In part the strategies depend on investment horizon, it is long term rational for altruistic behavior to forgo incremental short term profit to improve user experience. Hyper-rational to buy votes in a "ends justify means" mentality though fortunately most network players are not dishonest. So called meta-incentive (unwillingness to risk hurting bitcoin due to intended long term ho dling coins or ASICs) can also explain bias towards honest or altruistic strategies. Renting too much hashrate is risky as it can avoid the meta-incentive and increase rational or dishonest strategies. In particular re differentiating from 51% attack so long as > 50% are semi-honest, honest or altruistic it won't happen. It would seem actually that > 66-75% are because we have not seen selfish mining on the network. Though I think conveniently slow block publication by some players in the 60% spy mining semi-honest cartel was seen for a while, the claim has been it was short-lived and due to technical issue. It would be interesting to try to categorise and estimate the network % engaging in each strategy. I think the information is mostly known. Adam On Dec 11, 2016 03:22, "Daniele Pinna via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > How is the adverse scenario you describe different from a plain old 51% > attack? Each proposed protocol change where 51% or more of the network > can potentially game the rules and break the system should be considered > just as acceptable/unacceptable as another. > > There comes a point where some form of basic honesty must be assumed on > behalf of participants benefiting from the system working properly and > reliably. > > Afterall, what magic line of code prohibits all miners from simultaneously > turning all their equipment off... just because? > > Maybe this 'one': > > "As long as a majority of CPU power is controlled by nodes that are not > cooperating to attack the network, they'll generate the longest chain and > outpace attackers. The network itself requires minimal structure." > > Is there such a thing as an unrecognizable 51% attack? One where the > remaining 49% get dragged in against their will? > > Daniele > > On Dec 10, 2016 6:39 PM, "Pieter Wuille" wrote: > >> On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev < >> bitcoin-dev@lists.linuxfoundation.org> wrote: >> >>> We have models for estimating the probability that a block is orphaned >>> given average network bandwidth and block size. >>> >>> The question is, do we have objective measures of these two quantities? >>> Couldn't we target an orphan_rate < max_rate? >>> >> >> Models can predict orphan rate given block size and network/hashrate >> topology, 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 optimizing for minimal orphan rate, you can end up with a single >> (conglomerate of) pools 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 > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a114c89467af99205435e8110 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Well I think empirical game-theory observed on the network i= nvolves more types of strategy than honest vs dishonest.=C2=A0 At least 4, = maybe 5 types of strategy and I would argue lumping the strategies together= results in incorrect game theory conclusions and predictions.

A) altruistic players (protocol following by principle to be= good network citizens, will forgo incremental profits to aid network healt= h) eg aim to decentralize hashrate, will mine stuck transactions for free, = run pools with zero fee, put more effort into custom spam filtering, tend t= o be power users, or long term invested etc.

B) honest players (protocol following but non-altruistic or = just lazy/asleep run default software, but still leaving some dishonest pro= fit untaken). Eg reject spy mining, but no charitable actions, will not ret= aliate in kind to semi-honest zero sum attacks that reduce their profits.

C) semi-honest (will violate protocol if their attack can be= plausibly deniable or argued to be not hugely damaging to network security= ). Eg spy mining, centralised pools increasing other miners orphan rates.

D) rational players (will violate the protocol for profit: w= ill not overtly steal from users via double spends, but anything short part= icularly disadvantaging other miners even if it results in centralisation i= s treated as fair game) eg selfish mining. Would increase block size by fil= ling with pay to self transactions, if it increased orphans for others.

E) dishonest players (aka hyper-rational: will actually stea= l from users probabilistically if possible, not as worried about detection)= . Eg double spend and probabilistic double spends (against onchain gambling= games).=C2=A0 Would DDoS competing pools.

In part the strategies depend on investment horizon, it is l= ong term rational for altruistic behavior to forgo incremental short term p= rofit to improve user experience.=C2=A0 Hyper-rational to buy votes in a &q= uot;ends justify means" mentality though fortunately most network play= ers are not dishonest.

So called meta-incentive (unwillingness to risk hurting bitc= oin due to intended long term ho dling coins or ASICs) can also explain bia= s towards honest or altruistic strategies.=C2=A0

Renting too much hashrate is risky as it can avoid the meta-= incentive and increase rational or dishonest strategies.

In particular re differentiating from 51% attack so long as = > 50% are semi-honest, honest or altruistic it won't happen.=C2=A0 I= t would seem actually that > 66-75% are because we have not seen selfish= mining on the network.=C2=A0 Though I think conveniently slow block public= ation by some players in the 60% spy mining semi-honest cartel was seen for= a while, the claim has been it was short-lived and due to technical issue.=

It would be interesting to try to categorise and estimate th= e network % engaging in each strategy.=C2=A0 I think the information is mos= tly known.

Adam


On Dec 11, 2016 0= 3:22, "Daniele Pinna via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org= > wrote:
How is the adverse scenario you describe different from a plain o= ld 51% attack? Each proposed protocol change =C2=A0where 51% or more =C2=A0= of the network can potentially game the rules and break the system should b= e considered just as acceptable/unacceptable as another.=C2=A0

There comes a point where some form of bas= ic honesty must be assumed on behalf of participants benefiting from the sy= stem working properly and reliably.=C2=A0

=
Afterall, what magic line of code prohibits all miners fr= om simultaneously turning all their equipment off... =C2=A0just because?=C2= =A0

Maybe this 'one&= #39;:

"As long as a= majority of CPU power is controlled by nodes that are not cooperating to a= ttack the network, they'll generate the longest chain and outpace attac= kers. The network itself requires minimal structure."

Is there such a thing as an unrecognizab= le 51% attack?=C2=A0 One where the remaining 49% get dragged in against the= ir will?=C2=A0

Daniele= =C2=A0

On Dec 10, 2016 6:39 PM, "Pieter Wuille" <pieter.wuille@gmail.com> w= rote:
On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrot= e:
We have models for estimating the probab= ility that a block is orphaned given average network bandwidth and block si= ze.=C2=A0

The question is, do we have = objective measures of these two quantities? Couldn't we target an orpha= n_rate < max_rate?=C2=A0

Mo= dels can predict orphan rate given block size and network/hashrate topology= , but you can't control the topology (and things like FIBRE hide the ef= fect of block size on this as well). The result is that if you're purel= y optimizing for minimal orphan rate, you can end up with a single (conglom= erate of) pools producing all the blocks. Such a setup has no propagation d= elay at all, and as a result can always achieve 0 orphans.

Cheers,

--
Pieter


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev

--001a114c89467af99205435e8110--