Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id CAD4893E for ; Tue, 23 Jun 2015 19:42:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31EA3156 for ; Tue, 23 Jun 2015 19:42:40 +0000 (UTC) Received: from mail-qc0-f181.google.com ([209.85.216.181]) by mrelay.perfora.net (mreueus003) with ESMTPSA (Nemesis) id 0LgXZb-1Ym7Mh0zRt-00nvgx for ; Tue, 23 Jun 2015 21:42:38 +0200 Received: by qcbcf1 with SMTP id cf1so6095294qcb.0 for ; Tue, 23 Jun 2015 12:42:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.97.230 with SMTP id m93mr5298200qge.32.1435088557416; Tue, 23 Jun 2015 12:42:37 -0700 (PDT) Received: by 10.96.28.39 with HTTP; Tue, 23 Jun 2015 12:42:37 -0700 (PDT) Date: Tue, 23 Jun 2015 21:42:37 +0200 Message-ID: From: Adam Back To: Ross Nicoll Content-Type: text/plain; charset=UTF-8 X-Provags-ID: V03:K0:oeeXehMl+cQjiKX41HYAWxg1eOfO/PpY2rz674yiDX2Oua2yWn0 jx3ZeRjrjMsCdq6Va9/WoeMEmXWqXaUMn68O43vn0KWG638f+3WjF/YGCA2vYsJ1Cgt5cfr EctwD4p4NrhfE/nF65ywibgNcVBrj17YvsZB1H4+ZN2PEXAox97RjLCLRmi76NWxv3gaPbR KNh4fEB0HtHZP8EO0bpAA== X-UI-Out-Filterresults: notjunk:1;V01:K0:pmat0vJ5VJ8=:JDpUrYMCl+lbDF/ls/Waxy MMqinqabujqv6A+JxKvIOhQAlyPR1NUzfzdFwHqrxy5g9i9yvzGPjw8VIcE3aO+jIy/Grt3mR 66ivF3WyBCtdG20KlCnFwk2FpH+iqfzBw3lVEe4GofrLpTZI7zTNI1HjiejPwy3ywzgF7jy2d a6Veyh9pHU+EH3G4+hDJBsnHMRb5yfiBjViZywIyDHbp60jj4Fnqo1xnr3I3XauO2XQqXUGgs +ac1Y3+BjsaCiamrMlJR3SfaHoQiH5g4qk+s5GXqaOw4PubYhYlAbQ122g5Ljucejc44nmbNF xCrfObwouK9X54eXJ4G1VNsUKz6Ib9PzTsw6oor1E8IDu5lJNqWW9OAdkqRtI9F8lNHfsPrfG 54v52cAIP+MeydjxFoHQxhlGADFchT21yeRXp1Dtjw3I/o8Y7wElLTauev6S/mwc7NcImTUGS fY6cQnGYDsH+oxJrf5N3ibBqO2wBXRcVko994er4Coga0h+zE0GIdeyr+sTBXAcdhGPAylmZJ UiM2IZVh2VGTNua5vnCtF+oLc7e6DtO63yFtIbiMA6dXqpjc2zqS09lekXUqajUBdZOm9pbYj rHp/crT32C+uGYhKsIxzTlntuCU9Z8SLDDv9ThvPjaCTFV7lKeHD+dKd8AftQ7wMVxnOPExoc WmLk= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: [bitcoin-dev] game-theory, miner incentive alignment vs current proposals X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2015 19:42:40 -0000 We shouldnt lose track of the aspect that miner's interests are not directly aligned with user interests. Users want security, decentralisation properties and reasonably cheap fees, miners profit from fees. Particular miners may profit from centralisation. Miners are in competition with each other in a complex game. We could do with some analysis on Jeff's BIP and Greg Maxwell's flexcap (or Meni Rosenfeld's somewhat similar pay for size variant) -- and Gavin's proposal of what miner game-theory is anticipated and how the proposals hold up under those attacks. In Gavin's proposal why would we assume that 8MB wont be used? Or the huge 8GB later. It is free even for a miner to create blocks of any size up to the cap (zero fees or fees paid to himself). The stale rate of propagation delay maybe hidden by the relay-network or by collusion, or advantage of a miner already knowing its own block. Will a group of network topology close miners try to create big blocks that disadvantage other miners? Or will miners keep blocks small to extract switching-cost fees from users. (Regardless of cap). Jeff's proposal has a cost free miner vote for cap increase with a 25%-ile and 90% threshold. But in the second attack (keeping blocks small) it alternatively becomes easy for an advantaged 10% to force the block to stay small, in order to extract switching cost fees from users. Maybe users really love the decentralised features of bitcoin and are willing to pay a lot! Of course overlaid as Jeff observes by meta-incentive that miners need to sell mined bitcoin to pay electricity bills, and want Bitcoin to be in demand and therefore indirectly to satisfy user demand. But that may still result in a fair bit of switching cost. Switching cost economics is common in many networks. I submit that in terms of robustness of mechanism assuring security, it be ordered something like: 1. consensus rule 2. aligned economic interest 3. attack requires miner collusion 4. meta-incentive Then we could evaluate proposals for how robustly they can enforce user interests vs miner game-theory attack or collusion scenarios. Adam On 23 June 2015 at 09:59, Ross Nicoll wrote: > Also, before that's turned into "8MB blocks are infeasible", my presumption is that blocks are not expected to jump suddenly to 8MB, and that most will have time to ramp up storage and bandwidth. > > The point about not outright replacing existing test data is the more critical one, anyway, although in retrospect we could simply add spam transactions on top of existing transactions.