path: root/6a/6f615a77eadf4bef0f8b9d614a303909337783

Return-Path: <adam@cypherspace.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 809474A5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Sun, 11 Dec 2016 10:21:03 +0100
Received: by mail-qk0-f178.google.com with SMTP id n204so57707737qke.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAEgR2PEuZBZqUJ-qehBpk8dL8U-F5z9mZAn-UuRwUXiUSOcXRQ@mail.gmail.com>
References: <CAEgR2PEMPo3veqJat7OAps1DzTSNFJmJiRbkFgYKvYfxqdbUiw@mail.gmail.com>
	<CAEgR2PELB1_s+o0Bj4Kj9vS27eoqP7gV_VS_6QHQtTUAOnMORg@mail.gmail.com>
	<CAEgR2PFpGWxngq=fKGi7CC_d+=5YWzWwbEEsQNEifCuHAAPAHw@mail.gmail.com>
	<CAEgR2PHnrsdaBiDgywvE9amK8_yPE_hBo0yYOYwUk4T8n7wnAQ@mail.gmail.com>
	<CAEgR2PEgPkRe76hW0Jj7_Z1EdmmNTpTAOKGm_of2dG=XXUOtnA@mail.gmail.com>
	<CAEgR2PHew+fcJWnAt+t8umcwKu4TkshH=AFJ-8MeYysud2MkBQ@mail.gmail.com>
	<CAEgR2PEVwt_shiqwGjK6dPscRUTHayis0PaQO5Dj_fVEGGgaCQ@mail.gmail.com>
	<CAEgR2PEvpEwv=a0syn43negEnvGcoQ8LBxKRp4-JpnxCNORJSg@mail.gmail.com>
	<CAPg+sBiZmRdLOgG9iN2hOWVr_eCLTwDrbuETd_w9-bUJOfTjgw@mail.gmail.com>
	<CAEgR2PEuZBZqUJ-qehBpk8dL8U-F5z9mZAn-UuRwUXiUSOcXRQ@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
Date: Sun, 11 Dec 2016 10:21:01 +0100
X-Gmail-Original-Message-ID: <CALqxMTGHBhyBMPfdUid_W9tYafk5pGbKPP6LTdQbCmbAHLSURQ@mail.gmail.com>
Message-ID: <CALqxMTGHBhyBMPfdUid_W9tYafk5pGbKPP6LTdQbCmbAHLSURQ@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>, 
	Daniele Pinna <daniele.pinna@gmail.com>
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 <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: 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" <pieter.wuille@gmail.com> 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

<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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.</=
p>
<p dir=3D"ltr">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.</=
p>
<p dir=3D"ltr">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. </p=
>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">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&quot; mentality though fortunately most network play=
ers are not dishonest.</p>
<p dir=3D"ltr">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 </p>
<p dir=3D"ltr">Renting too much hashrate is risky as it can avoid the meta-=
incentive and increase rational or dishonest strategies.</p>
<p dir=3D"ltr">In particular re differentiating from 51% attack so long as =
&gt; 50% are semi-honest, honest or altruistic it won&#39;t happen.=C2=A0 I=
t would seem actually that &gt; 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.=
</p>
<p dir=3D"ltr">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.</p>
<p dir=3D"ltr">Adam<br>
</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Dec 11, 2016 0=
3:22, &quot;Daniele Pinna via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitco=
in-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>=
&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"auto">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<div dir=3D"a=
uto"><br></div><div dir=3D"auto">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</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto">Afterall, what magic line of code prohibits all miners fr=
om simultaneously turning all their equipment off... =C2=A0just because?=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Maybe this &#39;one&=
#39;:</div><div dir=3D"auto"><br></div><div dir=3D"auto">&quot;As long as a=
 majority of CPU power is controlled by nodes that are not cooperating to a=
ttack the network, they&#39;ll generate the longest chain and outpace attac=
kers. The network itself requires minimal structure.&quot;</div><div dir=3D=
"auto"><br></div><div dir=3D"auto">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</div><div dir=3D"auto"><br></div><div dir=3D"auto">Daniele=
=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"=
>On Dec 10, 2016 6:39 PM, &quot;Pieter Wuille&quot; &lt;<a href=3D"mailto:p=
ieter.wuille@gmail.com" target=3D"_blank">pieter.wuille@gmail.com</a>&gt; w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <span dir=
=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" targe=
t=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span> wrot=
e:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-siz=
e:13.696px;font-family:sans-serif">We have models for estimating the probab=
ility that a block is orphaned given average network bandwidth and block si=
ze.=C2=A0</span><br></div><div dir=3D"auto"><span style=3D"font-size:13.696=
px;font-family:sans-serif"><br></span></div><div dir=3D"auto"><span style=
=3D"font-family:sans-serif;font-size:13.696px">The question is, do we have =
objective measures of these two quantities? Couldn&#39;t we target an orpha=
n_rate &lt; max_rate?=C2=A0</span><span style=3D"font-size:13.696px;font-fa=
mily:sans-serif"><br></span></div></div></blockquote><div><br></div><div>Mo=
dels can predict orphan rate given block size and network/hashrate topology=
, but you can&#39;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&#39;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.<br><br></div><di=
v>Cheers,<br><br>-- <br></div><div>Pieter<br><br></div></div></div></div>
</blockquote></div></div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div></div>

--001a114c89467af99205435e8110--