Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9E09A8DC for ; 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 ; Thu, 9 Nov 2017 18:18:19 +0000 (UTC) Received: by mail-pg0-f46.google.com with SMTP id j3so5353224pga.1 for ; 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 X-Mailer: iPhone Mail (14G60) In-Reply-To: Date: Thu, 9 Nov 2017 10:18:17 -0800 Content-Transfer-Encoding: 7bit Message-Id: <2C582743-F143-4778-970F-ED934A0706A0@voskuil.org> References: To: Marc Bevand , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
I= t is not the case = in practice 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.

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.

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.

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.

e

On Nov 7, 2017,= at 21:04, Marc Bevand via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:=

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.

-Marc


On Mon, Nov 6, 2017, 22:32 R= obert Taylor via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Forgive me if this has been a= sked elsewhere before, but I am trying to understand a potential failure mod= e of Bitcoin mining.

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.

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.

Robert
_______________________________________________
bitcoin-dev mailing list
b= itcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailma= n/listinfo/bitcoin-dev
____________________= ___________________________
bitcoin-dev mailing list<= br>bitcoin-de= v@lists.linuxfoundation.org
https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
= --Apple-Mail-0DCDCB11-35AB-4C61-B746-5132C8294E51--