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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
|
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 31D805AE
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 23:03:35 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 090A9142
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 5 Nov 2015 23:03:33 +0000 (UTC)
Received: from mail-ig0-f177.google.com ([209.85.213.177]) by
mrelay.perfora.net (mreueus001) with ESMTPSA (Nemesis) id
0LjtQF-1aR4Um1Nc1-00bgvx for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 Nov 2015 00:03:33 +0100
Received: by igbhv6 with SMTP id hv6so22406220igb.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 05 Nov 2015 15:03:32 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.50.66.210 with SMTP id h18mr6260673igt.55.1446764612594;
Thu, 05 Nov 2015 15:03:32 -0800 (PST)
Received: by 10.50.180.199 with HTTP; Thu, 5 Nov 2015 15:03:32 -0800 (PST)
Date: Fri, 6 Nov 2015 00:03:32 +0100
X-Gmail-Original-Message-ID: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com>
Message-ID: <CALqxMTE1JDsT8fSoDZVTUWfnw4Cmb9LkDa+B-XUyXGPxAYernA@mail.gmail.com>
From: Adam Back <adam@cypherspace.org>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Provags-ID: V03:K0:stvmRCpXXWFloujvYOrUGLjw1Qlm3igDeMLPBDSfbNMfl4FcTQ1
Y4NiUhkWw4Nm0CB/TBFe2h1zS1OqiwXPhUybt9d3b7sEJPlyYyfKkZH6IPS4qL1WvBYlRq/
s6EZAnwlGBYzv9Uw9C0+v5AYOsB9b3VO50EKmHOvF8rVb971uumQvwfxhGWkvWm7GwXHDYT
8S9f7ewJzJnhh8JQLM9wA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:kkfYt7vYthg=:lFpdIG+L59EQrTLdayY6u2
eZoGUc6hSGtbch9kfd1b03/1H7VhLCTdDLSJMrocgGGvDskgPLSUBvMYywAlCtPGGVySeOqFA
xzEFAFJ2XdpJSMC+6aQd+f8+d16a1uf/5U1K/BlVrRwlc67tSxfJ8BUmKSkJfpSql1wCXkcpD
j3nT04lq2MmgqyEdlxgb6JaCAK60lEzE249ImTJiqguyOknW4fz5MzEkqG0K96yjFnVXMASOL
H5NCfqj1zOxbkRgXsAW5zjcLpkP3Q6PVD0g6BU6UQyx/NeNQoW7G0vftxeJjLq7F6VEcSkGPA
deW38fODDLtTqjAx0crL+SmukdtQ1cpmj2pFnwAAs1G7LeVvLcKWQLpHWj14IIsPsasguzyKT
AAodNP6EH6gMHxUteud5atq3EY3wyKEjUra1D1AlL87NMt9X0MQLj0Cp+N5WNXUGaT7cmBr1k
Pc5GUnot4Z4XpKcRpIx6nX5emp+OgnIsGlUd8q8CylgOpd7togwY+hGyQPjtqsVgaumaTN/J4
8DptoJlClHgXP7SFheJuSdxTRaka+wgRDh+Snf7P8UEzZZ9U24KkLHs8DX/hygABtXtvHnWGH
tSy0sd3AzjyHRdP3OK4Tke1e740ek64ApiolBTbAghWCiRJb8ytpNxIsmTE8D+ROb7AkCDE5C
R8R4jazEF25sd2LadlGhXVORfDj77W49IjSXSwF3UqGcsJprd9RaP0C1QxROIYk6ewQ6/k//e
+ZAauo162uW6OpfU
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
Subject: [bitcoin-dev] summarising security assumptions (re cost metrics)
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: Thu, 05 Nov 2015 23:03:35 -0000
Some thoughts, hope this is not off-topic.
Maybe we should summarise the security assumptions and design
requirements. It is often easier to have clear design discussions by
first articulating assumptions and requirements.
Validators: Economically dependent full nodes are an important part of
Bitcoin's security model because they assure Bitcoin security by
enforcing consensus rules. While full nodes do not have orphan
risk, we also dont want maliciously crafted blocks with pathological
validation cost to erode security by knocking reasonable spec full
nodes off the network on CPU (or bandwidth grounds).
Miners: Miners are in a commodity economics competitive environment
where various types of attacks and collusion, even with small
advantage, may see actual use due to the advantage being significant
relative to the at times low profit margin
It is quite important for bitcoin decentralisation security that small
miners not be significantly disadvantaged vs large miners. Similarly
it is important that there not be significant collusion advantages
that create policy centralisation as a side-effect (for example what
happened with "SPV mining" or validationless mining during BIP66
deployment). Examples of attacks include selfish-mining and
amplifying that kind of attack via artificially large or
pathologically expensive to validate blocks. Or elevating orphan risk
for others (a miner or collusion of miners is not at orphan risk for a
block they created).
Validators vs Miner decentralisation balance:
There is a tradeoff where we can tolerate weak miner decentralisation
if we can rely on good validator decentralisation or vice versa. But
both being weak is risky. Currently given mining centralisation
itself is weak, that makes validator decentralisation a critical
remaining defence - ie security depends more on validator
decentralisation than it would if mining decentralisation was in a
better shape.
Security:
We should consider the pathological case not average or default behaviour
because we can not assume people will follow the defaults, only the
consensus-enforced rules.
We should not discount attacks that have not seen exploitation to
date. We have maybe benefitted from universal good-will (everybody
thinks Bitcoin is cool, particularly people with skills to find and
exploit attacks).
We can consider a hierarchy of defences most secure to least:
1. consensus rule enforced (attacker loses block reward)
2. economic alignment (attacker loses money)
3. overt (profitable, but overt attacks are less likely to be exploited)
4. meta-incentive (relying on meta-incentive to not damage the ecosystem only)
Best practices:
We might want to list some best practices that are important for the
health and security of the Bitcoin network.
Rule of thumb KISS stuff:
We should aim to keep things simple in general and to avoid creating
complex optimisation problems for transaction processors, wallets,
miners.
We may want to consider an incremental approach (shorter-time frame or
less technically ambitious) in the interests of simplifying and
getting something easier to arrive at consensus, and thus faster to
deploy.
We should not let the perfect be the enemy of the good. But we should
not store new problems for the future, costs are stacked in favour of
getting it right vs A/B testing on the live network.
Not everything maybe fixable in one go for complexity reasons or for
the reason that there is no clear solution for some issues. We should
work incrementally.
Adam
|
