Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 585EAC7A for ; Tue, 7 Nov 2017 03:56:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f170.google.com (mail-wr0-f170.google.com [209.85.128.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BED4D3DB for ; Tue, 7 Nov 2017 03:56:01 +0000 (UTC) Received: by mail-wr0-f170.google.com with SMTP id y9so10589435wrb.2 for ; Mon, 06 Nov 2017 19:56:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=it38HF5Z3qUWDuEMH+aJYk6rcV/vae2J4rQ2nYGjkDg=; b=QZBDA1Q2puoat6wOqDKa3o/rq6uMoi8q9LhimH8Z4A5w1Z/bb4MZgKSlzQH4EAUW9B FZo7X4SH8JIdiotvs9F2fOdK4/iueP+b0QkyLvHt5heq2WKuc3o1BChXAZb2wvojKXZH YX6M7s7AhZReIOPKQWeT0+Iz+aiqAxXZeKQa948+vT9pwAidnM2kLxASCoOJXvwBp6ZV GhcCxROZWUTsrg7gslkwPuq0g03yVZAr1uZ3s1syobOWp5/i/OfCPsxtJJgBy4PtBt9Q 7GCPHl6aWORmZMRyiAXZxA/6BFfNYlkJwG3hq/8bD0LckYvuA8eVWiI0k3rtkGn+1UB0 G0Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=it38HF5Z3qUWDuEMH+aJYk6rcV/vae2J4rQ2nYGjkDg=; b=ikWzxo95bCKAI0565eGactLS1KUVzCN3JTwXABwqI/DdqeEZWoKeAq2VAIOsN371Om n0hNmkuM+ErYH9R13GUBWzmsU8aR4i3fl1GwM0JELR1TQCPB51Uj54VJ3KU9UCdJrKg2 /G6ndhMuPmq8AHDTLb0rh/Ydv+xjjxSM8h12SNfl11nd7ha9f+IA+BEauZmhJcsoHW2o JpH3WqLmGpDXp3IDr3/3jg7zGTWX9M2NUOwwUCXeLPXuVHEnfNAYC43rPpak/2YM0R7U 7Y7MMYmZMqfGwGqRMePatRgNenFUeTagROyDIc7roTog781p3J4vtYSafo5ZzsLlcZsV k6uA== X-Gm-Message-State: AJaThX5W/JHM/4XvgJsumhGyDiryZfsVM5ju2IXmqU8Mmk/0j3MDx440 M6X4UWMxaD644bdzJFoC2epXUWxBt9VklWo5tajikcjsMrM= X-Google-Smtp-Source: ABhQp+TllEVzU/SIVRtOJSwuGF/NFfp5wnAX1QEetrfz6RxQ7wIExsEivRwSjQHqoy3vId0EzCL3JZukVDC2ZHybCOM= X-Received: by 10.223.171.85 with SMTP id r21mr3627858wrc.182.1510026960241; Mon, 06 Nov 2017 19:56:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.149.139 with HTTP; Mon, 6 Nov 2017 19:55:59 -0800 (PST) From: Robert Taylor Date: Tue, 7 Nov 2017 10:55:59 +0700 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="94eb2c1cb8f0910786055d5c8c12" X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: Tue, 07 Nov 2017 04:32:24 +0000 Subject: [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: Tue, 07 Nov 2017 03:56:02 -0000 --94eb2c1cb8f0910786055d5c8c12 Content-Type: text/plain; charset="UTF-8" Forgive me if this has been asked elsewhere before, but I am trying to understand a potential failure mode of Bitcoin mining. A majority of miners can decide which valid blocks extend the chain. But what 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 example, they could soft fork a new rule where the block number is signed by set of keys known only to the cartel, and that signature placed in the coinbase. Miners outside of the cartel would not be able to extend the chain. It would be immediately obvious but still valid under the consensus rules. What are the disincentives for such behavior and what countermeasures could 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 gain a majority of hash alone, it is certainly possible with collusion. Robert --94eb2c1cb8f0910786055d5c8c12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Forgive me if this has been asked elsewhere before, but I = am trying to understand a potential failure mode of Bitcoin mining.
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 t= o validly orphan any blocks made by miners outside of their group? For exam= ple, they could soft fork a new rule where the block number is signed by se= t of keys known only to the cartel, and that signature placed in the coinba= se. Miners outside of the cartel would not be able to extend the chain.
=
It would be immediately obvious but still valid under the consensus rul= es. What are the disincentives for such behavior and what countermeasures c= ould 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 gain a majority of hash alone, it is certainly possible with collusion.<= /div>

Robert
--94eb2c1cb8f0910786055d5c8c12--