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
|
Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 8E93C9FB
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 18:50:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f46.google.com (mail-la0-f46.google.com
[209.85.215.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CE180A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 18:50:25 +0000 (UTC)
Received: by lagh6 with SMTP id h6so131458145lag.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 11:50:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type; bh=KCiCyC68OwOQkVTdrRvLzm13D8Cz6ruSJscGjBt24ws=;
b=K/ezVj1PcYuFwcLjoYEdqMio1hQH1pmHbDJRw9RssayLstnBy2enClIUnu0ObZR6O2
4qrnuIEz2SAltLjt/zoSIJcF29Ogt57/JgLdhvhT1yO1CBIZVyr39iK8o9c5NjLwF1Lp
Un4X7Lyl7ZOnoCkQyl7FgkwIrLj5Ka9QJGHxUQllmiYpQ9I+r7XLrIulb0LvAeQ3PuD+
wt+9YX8IUtFbxT+kkLo1cg6lZcOBKtUTn3CGeJN5pRkz6jg6DGdJwVteSu1DweV8b4wQ
hEo7rAPyn+N8Pe/qDG1PrbwWcV334ABchZ3b0fVQfJfhDstV/EqO1EEszfNvKiZUE+vz
I9EQ==
MIME-Version: 1.0
X-Received: by 10.152.5.65 with SMTP id q1mr45406784laq.110.1436122223667;
Sun, 05 Jul 2015 11:50:23 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 11:50:23 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 11:50:23 -0700 (PDT)
In-Reply-To: <CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
References: <CABr1YTf72fdQmTDEHAWVKqvTCLSpJZyiiw4g3ifrY8x5RZ=shQ@mail.gmail.com>
<CABr1YTfwcOQuNyqO57=jdghTnqt56u6pBvK6+dWbED-4OMh+Ug@mail.gmail.com>
<CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
Date: Sun, 5 Jul 2015 11:50:23 -0700
Message-ID: <CABr1YTfiCx6igG9s6NbdD7pWLuoYSJ1QFcX_RnhbdtX5r=Z5Xg@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e013d1754fef2e9051a2542d8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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
Subject: [bitcoin-dev] Thoughts on Forks, Scalability,
and other Bitcoin inconveniences.
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: Sun, 05 Jul 2015 18:50:26 -0000
--089e013d1754fef2e9051a2542d8
Content-Type: text/plain; charset=UTF-8
Blockchain validation has become too expensive to properly secure the
network as per our original security model. The level of validation
required to comply with our security model has become completely
impractical for most use cases. Block space is still cheap only because of
block reward subsidy (which decreases exponentially with time). The
economics are already completely jacked - larger blocks will only worsen
this disparity.
The only practical way for the network to function at present (and what has
essentially ended up happening, if often tacitly) is by introducing trust,
in validators, miners, relayers, explorer websites, online wallets,
etc...which in and of itself wouldn't be the end of the world were it not
for the fact that the raison d'etre of bitcoin is trustlessness - and the
security model is very much based on this idea. Because of this, there's
been a tendency to deny that bitcoin cannot presently scale without trust.
This is horrible because our entire security model has gone out the
window...and has been replaced with something that isn't specified at all!
We don't really know the boundaries of our model, as the fork a couple of
days ago demonstrated. Right now we're basically trusting a few devs and
some mining pool operators that until now have been willing to cooperate
for the benefit of the network. It is dangerous to assume this will
continue perpetually. Even assuming the best intentions, an incident might
occur that this cooperation cannot easily repair.
We need to either solve the validation cost/bottleneck issue...or we need
to construct a new security model that takes these trust assumptions into
account.
- Eric Lombrozo
--089e013d1754fef2e9051a2542d8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Blockchain validation has become too expensive to properly s=
ecure the network as per our original security model. The level of validati=
on required to comply with our security model has become completely impract=
ical for most use cases. Block space is still cheap only because of block r=
eward subsidy (which decreases exponentially with time). The economics are =
already completely jacked - larger blocks will only worsen this disparity.<=
/p>
<p dir=3D"ltr">The only practical way for the network to function at presen=
t (and what has essentially ended up happening, if often tacitly) is by int=
roducing trust, in validators, miners, relayers, explorer websites, online =
wallets, etc...which in and of itself wouldn't be the end of the world =
were it not for the fact that the raison d'etre of bitcoin is trustless=
ness - and the security model is very much based on this idea. Because of t=
his, there's been a tendency to deny that bitcoin cannot presently scal=
e without trust. This is horrible because our entire security model has gon=
e out the window...and has been replaced with something that isn't spec=
ified at all!</p>
<p dir=3D"ltr">We don't really know the boundaries of our model, as the=
fork a couple of days ago demonstrated. Right now we're basically trus=
ting a few devs and some mining pool operators that until now have been wil=
ling to cooperate for the benefit of the network. It is dangerous to assume=
this will continue perpetually. Even assuming the best intentions, an inci=
dent might occur that this cooperation cannot easily repair.</p>
<p dir=3D"ltr">We need to either solve the validation cost/bottleneck issue=
...or we need to construct a new security model that takes these trust assu=
mptions into account.</p>
<p dir=3D"ltr">- Eric Lombrozo</p>
--089e013d1754fef2e9051a2542d8--
|
