path: root/22/651c010099ef7bd628fdbc773b0a547ec75cbb

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E09A8DC
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  9 Nov 2017 18:18:20 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg0-f46.google.com (mail-pg0-f46.google.com [74.125.83.46])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E2228A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  9 Nov 2017 18:18:19 +0000 (UTC)
Received: by mail-pg0-f46.google.com with SMTP id j3so5353224pga.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 09 Nov 2017 10:18:19 -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=Kwc0JcWs/j9KdLutUzn/0ue6Rxh2mqkaajmJV/JajrE=;
	b=iLj2ocOKARzAa6iCVy6jNxSutjaqomBgTG0gQq2anJC1zXHdxcliHh1KHhgp2X944z
	4/KMpgQSauP7s1iu1z91X2alwwKqc12ic3wXYK2Dd10o2T9jZ61he43v8G7E3pLH0Lhh
	7Oj4lWyCVc4CMG55oZHIzH7cYb8dpYb7CYS3kcyoniKB4z+BbRHuObWYv7GpjnIMvyKr
	Z+OBlXNwWtKNGKUcV9KepSFQT15xzLbqv8EnBOwkCliQXrREp0FvrpJfBL8VFMEYQyC2
	H8Q+vg1c77qFwkgXNaWO/JO8mh/PUzKIjuR47rM8xMxw0UeRiV8TDZ2SZNjBA6GHEuWw
	9cWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=Kwc0JcWs/j9KdLutUzn/0ue6Rxh2mqkaajmJV/JajrE=;
	b=PXd//lCe6QEi7YUDsT4NU78wOiDG2plrOnmWVUVJZpI6A7pKG3NTXNcO2aDfAk/ynt
	2dZBshcmUdSRuGMM8S3LoYSqnMaZMvTe19RnHfP1KuJyxxcbEI2hBuYarWVbVw7LVab9
	80PxSC4Nfo5MIHFitig73V9tu5ibS+Ulms1is2O0i+p7wJu/2wx5+mnTezP1LcQEzCfs
	x+gRpo227a8MmuJy3pZHmnrlsgeyEpkUnVi5h5sh8GeQEgIUk2JxxPr6aD5u7cVK1W3c
	2fNZAiqk6BR4RcjwXLWOgAr2PeyUxEZ3u9mipceoNJG9zFqFKitpz9/6gdgIEopxssd1
	YdgQ==
X-Gm-Message-State: AJaThX6cyUO5xYIYjFIOSlht61yFe2Fy6LLM0ZE+RY15pJCRkH0qieNh
	WxlB/OQfA4w7+GKsbjv0l8KqR6lQNkk=
X-Google-Smtp-Source: ABhQp+QsSKGm98nhQJGFVHdQ3QGVcqxcpgeV+U+M7CV9jnk/G7KcHLFhoqH2ytNgydqvvBndLd+S/A==
X-Received: by 10.98.61.85 with SMTP id k82mr1357910pfa.84.1510251499595;
	Thu, 09 Nov 2017 10:18:19 -0800 (PST)
Received: from [192.168.1.166] ([47.154.226.113])
	by smtp.gmail.com with ESMTPSA id
	n29sm13074696pgd.74.2017.11.09.10.18.18
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 09 Nov 2017 10:18:18 -0800 (PST)
Content-Type: multipart/alternative;
	boundary=Apple-Mail-0DCDCB11-35AB-4C61-B746-5132C8294E51
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <CADH-5r3YqvO4rbS5PEc86LB-CGsrMnARUj7Vbfi0opBB_EuMQA@mail.gmail.com>
Date: Thu, 9 Nov 2017 10:18:17 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <2C582743-F143-4778-970F-ED934A0706A0@voskuil.org>
References: <CAArA6tURLo0yiM+js=KJEo8i1FTwOKV7V+qjC8yGd8q2PgvewQ@mail.gmail.com>
	<CADH-5r3YqvO4rbS5PEc86LB-CGsrMnARUj7Vbfi0opBB_EuMQA@mail.gmail.com>
To: Marc Bevand <m.bevand@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
X-Spam-Status: No, score=0.0 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	HTML_MESSAGE,MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE autolearn=disabled
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 09 Nov 2017 18:23:22 +0000
Subject: Re: [bitcoin-dev] Centralizing mining by force
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: Thu, 09 Nov 2017 18:18:20 -0000


--Apple-Mail-0DCDCB11-35AB-4C61-B746-5132C8294E51
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable

It is not the case in practice that there exists no incentive to disrupt the=
 market for transaction confirmation. Statism is profitable, and a primary s=
ource of revenue is seigniorage. Given Bitcoin's threat to that privilege, i=
ts destruction presents a hefty incentive.

The security model of Bitcoin is not based on balancing power between miners=
 (those who confirm) and merchants (those who validate). It is based on thes=
e parties defending their mutually-beneficial market from the state.

Neither technology nor incentives resolve this conflict. People must be will=
ing to defend their mines and their economic nodes. This requires personal r=
isk. The risk to each individual is mitigated by broad decentralization, but=
 remains nonetheless.

Even in a highly-decentralized system, overpowering taxpayer-funded disrupti=
on of the confirmation market will require that merchants pay aggregate fees=
 exceeding the mining subsidy expended by the taxpayer to disrupt it. Who pr=
evails in that tug of war is unclear, but working on Bitcoin implies one bel=
ieves it is possible for individuals to do so.

e

> On Nov 7, 2017, at 21:04, Marc Bevand via bitcoin-dev <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
>=20
> What you describe is an example of a majority attack ("51% attack"). No te=
chnical mechanism in Bitcoin prevents this. However in practice, miners are n=
ot incentivized to perform this attack as it would destroy confidence in Bit=
coin, and would ultimately impact their revenues.
>=20
> -Marc
>=20
>=20
>> On Mon, Nov 6, 2017, 22:32 Robert Taylor via bitcoin-dev <bitcoin-dev@lis=
ts.linuxfoundation.org> wrote:
>> Forgive me if this has been asked elsewhere before, but I am trying to un=
derstand a potential failure mode of Bitcoin mining.
>>=20
>> A majority of miners can decide which valid blocks extend the chain. But w=
hat would happen if a majority of miners, in the form of a cartel decided to=
 validly orphan any blocks made by miners outside of their group? For exampl=
e, they could soft fork a new rule where the block number is signed by set o=
f keys known only to the cartel, and that signature placed in the coinbase. M=
iners outside of the cartel would not be able to extend the chain.
>>=20
>> It would be immediately obvious but still valid under the consensus rules=
. What are the disincentives for such behavior and what countermeasures coul=
d be done to stop it and ensure mining remained permissionless? I think this=
 is a valid concern because while it may not be feasible for one actor to ga=
in a majority of hash alone, it is certainly possible with collusion.
>>=20
>> Robert
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

--Apple-Mail-0DCDCB11-35AB-4C61-B746-5132C8294E51
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div><span></span></div><div><meta http-equ=
iv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div></div><div>I=
t is not the case <span style=3D"background-color: rgba(255, 255, 255, 0);">=
in practice</span>&nbsp;that there exists no incentive to disrupt the market=
 for transaction confirmation. Statism is profitable, and a primary source o=
f revenue is seigniorage. Given Bitcoin's threat to that privilege, its dest=
ruction presents a hefty incentive.</div><div><br></div><div>The security mo=
del of Bitcoin is not based on balancing power between miners (those who con=
firm) and merchants (those who validate). It is based on these parties defen=
ding their mutually-beneficial market from the state.</div><div><br></div><d=
iv>Neither technology nor incentives resolve this conflict. People must be w=
illing to defend their mines and their economic nodes. This requires persona=
l risk. The risk to each individual is mitigated by broad decentralization, b=
ut remains nonetheless.</div><div><br></div><div>Even in a highly-decentrali=
zed system, overpowering taxpayer-funded disruption of the confirmation mark=
et will require that merchants pay aggregate fees exceeding the mining subsi=
dy expended by the taxpayer to disrupt it. Who prevails in that tug of war i=
s unclear, but working on Bitcoin implies one believes it is possible for in=
dividuals to do so.</div><div><br></div><div>e</div><div><br>On Nov 7, 2017,=
 at 21:04, Marc Bevand via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:=
<br><br></div><blockquote type=3D"cite"><div><p dir=3D"ltr">What you describ=
e is an example of a majority attack ("51% attack"). No technical mechanism i=
n Bitcoin prevents this. However in practice, miners are not incentivized to=
 perform this attack as it would destroy confidence in Bitcoin, and would ul=
timately impact their revenues.</p>
<p dir=3D"ltr">-Marc</p>
<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Nov 6, 2017, 22:32 R=
obert Taylor via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex"><div dir=3D"ltr">Forgive me if this has been a=
sked elsewhere before, but I am trying to understand a potential failure mod=
e of Bitcoin mining.<div><br>A majority of miners can decide which valid blo=
cks extend the chain. But what would happen if a majority of miners, in the f=
orm of a cartel decided to validly orphan any blocks made by miners outside o=
f their group? For example, they could soft fork a new rule where the block n=
umber is signed by set of keys known only to the cartel, and that signature p=
laced in the coinbase. Miners outside of the cartel would not be able to ext=
end the chain.<br><br>It would be immediately obvious but still valid under t=
he consensus rules. What are the disincentives for such behavior and what co=
untermeasures could be done to stop it and ensure mining remained permission=
less? I think this is a valid concern because while it may not be feasible f=
or one actor to gain a majority of hash alone, it is certainly possible with=
 collusion.</div><div><br></div><div>Robert</div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b=
itcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" r=
el=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mailma=
n/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</div></blockquote><blockquote type=3D"cite"><div><span>____________________=
___________________________</span><br><span>bitcoin-dev mailing list</span><=
br><span><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de=
v@lists.linuxfoundation.org</a></span><br><span><a href=3D"https://lists.lin=
uxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation=
.org/mailman/listinfo/bitcoin-dev</a></span><br></div></blockquote></div></b=
ody></html>=

--Apple-Mail-0DCDCB11-35AB-4C61-B746-5132C8294E51--