1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
|
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 CAD4893E
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 23 Jun 2015 21:42:38 +0200
Received: by qcbcf1 with SMTP id cf1so6095294qcb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CALqxMTFu6DRVMSLsGDa6AgVX1Xamj_X4HhJaTKNTZCAgj6hXNg@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Ross Nicoll <jrn@jrn.me.uk>
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 <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: 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 <jrn@jrn.me.uk> 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.
|
