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
118
|
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 4814067
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 09:57:57 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.197])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C17317C
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 5 Aug 2015 09:57:56 +0000 (UTC)
Received: from mail-qg0-f48.google.com ([209.85.192.48]) by mrelay.perfora.net
(mreueus002) with ESMTPSA (Nemesis) id 0Lm5DD-1YnJis3jrF-00ZheT for
<bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 11:57:56 +0200
Received: by qged69 with SMTP id d69so25710467qge.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 05 Aug 2015 02:57:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.141.28.11 with SMTP id f11mr16290113qhe.78.1438768674891;
Wed, 05 Aug 2015 02:57:54 -0700 (PDT)
Received: by 10.96.226.68 with HTTP; Wed, 5 Aug 2015 02:57:54 -0700 (PDT)
In-Reply-To: <CAAO2FKGPeBnpB0X3fvqkX+Wy6wOO+m1ZPhEup0Hvv4_nhcRUKA@mail.gmail.com>
References: <CABsx9T1E1s=4h-SxLTOAXK4GniZrUekcEb6zDdTDFG+h7X98MA@mail.gmail.com>
<1438640036.2828.0.camel@auspira.com>
<CABsx9T2A-Mz9z=TTifbL2_sKCDvy8coRpNse+0vff6EbXbp8cg@mail.gmail.com>
<BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com>
<CAOoPuRb=wDKOoRXuqktDypyJ_gs1w5WORx4+LH84AOEv_PY1ZQ@mail.gmail.com>
<CAAO2FKGPeBnpB0X3fvqkX+Wy6wOO+m1ZPhEup0Hvv4_nhcRUKA@mail.gmail.com>
Date: Wed, 5 Aug 2015 11:57:54 +0200
Message-ID: <CALqxMTGiSdh64G9LVLoCCio3fLNaXUY9v0BeMZV+ZiN6ShY0Ew@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Hector Chu <hectorchu@gmail.com>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:tO4FfUinjaBi1G7yHPsgNI2InOQv+0knko6Xk5WPmFS0j5TOwdZ
Q9P87K0X2nIB+SSt9aWInE5fD52hVVPpxwjGlgvqsC3D2Dcl7MtEtOSQ5ngAMwHtb/JfWWT
tulnKlcHu0QsGOkHtXicicRLTguQ4oy9pfEWMrzGgugWXIHOmeW2n/w9UHTevU+KaK9e9IJ
Np5Ssts5FBeTz8REQtmsg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:vQiworOb6HA=:xlf7YvOG87GWE8aWmFq1+z
619k49x/sKSNf1//Gdw+boHMyv1/MPrmCUIgytgPaoJYUooYRISq4w/X3/OHa2OL0vccMO1oc
N0P6CWNhGE65+I35Eh3xsHPp4OJ+3zqeP9k5JCOBTHyAyLpQ+yXy970EKXC8LtfClj06/royG
uhQfa+e9IMNyGsCDtjWvikFhwPETOm2EQa7Gbb+mLj+7vQEW5qHZdn5xiU3Hkp39VihgjikN3
OLvfeBnCBRppSNzFxU6zW3mAQcnGgchXmRlmwtbTIV5rO6iNoYAmZkyOApzDJQbD4XXXDQ+Rn
M0SNG3EP/it7Iunz5iVyw0Yq36Ctfd1Tr6vnr3Vti2qWoq8j5HY8y8XSMAdlXPVY9L9GBHhqP
AhkMBsP+70rC9QUF72Av4tu+Oydj7Jn5x5aTymp8DW6ZVKES4U7L57V+82wL/6Ov4N11RAsjp
JeaUlTzeTQ9biDE7UJ/Hcz2T6JBIxD2/LrE5cuELhtyi/SYebemU+5HNl/8Rw3K+MitmLHdkr
+3V/Q8a79jdMe1GLv1c4W9Z9lfRMigrlBh2evA2MTsb6XUSSiH8XaYOIXrDUoIhVpoSS4pakw
5c5GNGVdeVGEVSahpcpHbprAw5C6TDrOIj9VPMdIZJT0WydCQkgrayBE3nwnbUQ51w9pP2D8z
zdvowZrD09ZNduTB+qlrd4CwaCriq6f09HgEyDjTvSRhlzA==
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block
Size Limit"--new research paper suggests
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: Wed, 05 Aug 2015 09:57:57 -0000
On 5 August 2015 at 11:18, Hector Chu via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Miners would be uniquely placed to know how best to vary the block size to maximize their
> profit resulting from these two prices. [...]
> In that respect a dynamic block size voted on by miners periodically would
> go some way to rectify this inefficiency.
This kind of thing has been discussed here, even recently. It is not
without problems.
You may find the flexcap idea summarised in outline by Greg Maxwell
and Mark Friedenbach a month or so back interesting in showing that
one can achieve such effects without handing over a free vote to
miners and hence avoid many (though probably not all) of the
side-effects inherent in giving miners control.
About side-effects, I think we can make argument that there are limits
because other than in an extremis sense, miners are not necessarily in
alignment with security, nor maximising user utility and value
delivered.
For example switching cost economics are common in networks (cell
phone service pricing), maybe Bitcoin would have a really high
switching cost if miners would cartelise.
Also miners are in a complex game competing with each other, and this
degree of control risks selfish mining issues or other cartel attacks
or bandwidth/verification/latency related attacks being made worse.
eg see the recent paper by Aviv Zohar.
Generally speaking economically dependent full nodes are holding
miners honest by design. Changing that dynamic by shifting influence
can have security and control impacting side-effects, and needs to be
thought about carefully.
About security to try to make those comparisons a bit more formal I
posted this taxonomy of types of security that proposals could be
compared against, in order of security:
1. consensus rule (your block is invalid if you attack)
2. economic incentive alignment (you tend to lose money if you attack)
3. overt (attack possible but detectable, hence probably less likely
to happen for reputation or market signal reasons even if possible
anonymously)
4. meta incentive (assume people would not attack if they have an
investment or interest in seeing Bitcoin continue to succeed)
Adam
|
