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
146
147
|
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 C39F3B5A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 19:55:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f52.google.com (mail-la0-f52.google.com
[209.85.215.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0CCBA1C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jul 2015 19:55:49 +0000 (UTC)
Received: by lagx9 with SMTP id x9so132334523lag.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 12:55:47 -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=zPixkD4eWykL13ew7nBxLtmcs+2oL8aa4jBVuwcjtYM=;
b=nWNWBptGdl5A8fmSDPoPhVhwQneYQqa9Aepdm4XAAesSVNFmMvZj+MFQuAGCKyCBqI
tKkKqm0JWaCt+3y1UYa7ONz44Z2h1Nhdq6sxq+dSfvHLCjAjz/SciqgJTuM+ZVulbON7
NGCHKXSHhlpZXCiNYN3anKI+LcrDfLxcdaxOSC1sKhOEkCr5K7PJbVkiiOGiIXgle/2P
t4AsyaqhOMAHNGZc7i/Aa9dM/easGn45c53HBqGFWpv+OLasSYzyLu3UK0s2PhUpzwyj
NwWFeTCOwz/X3nzW49li3hDDrlrZ2wG5lUMURRHhcZ+7ZlERAFktzbWhAiU7k8WjNw4R
OYew==
MIME-Version: 1.0
X-Received: by 10.152.28.194 with SMTP id d2mr46445839lah.122.1436126147436;
Sun, 05 Jul 2015 12:55:47 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 12:55:47 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Sun, 5 Jul 2015 12:55:47 -0700 (PDT)
In-Reply-To: <CABr1YTfiCx6igG9s6NbdD7pWLuoYSJ1QFcX_RnhbdtX5r=Z5Xg@mail.gmail.com>
References: <CABr1YTf72fdQmTDEHAWVKqvTCLSpJZyiiw4g3ifrY8x5RZ=shQ@mail.gmail.com>
<CABr1YTfwcOQuNyqO57=jdghTnqt56u6pBvK6+dWbED-4OMh+Ug@mail.gmail.com>
<CABr1YTfEEXoQJ4SUtrUki9_WetWbGV7TEB+3usJGQqu-P55kSA@mail.gmail.com>
<CABr1YTfiCx6igG9s6NbdD7pWLuoYSJ1QFcX_RnhbdtX5r=Z5Xg@mail.gmail.com>
Date: Sun, 5 Jul 2015 12:55:47 -0700
Message-ID: <CABr1YTdBEUCT2AONBMD-aEh=Opu80H4U0H-4ZFFMg6+jECpCPw@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=089e0160b420dee7a1051a262cc0
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: Re: [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 19:55:49 -0000
--089e0160b420dee7a1051a262cc0
Content-Type: text/plain; charset=UTF-8
I should clarify that by "most use cases" I'm not envisioning a bunch of
cryptogeeks [us, or at least myself and a few of us] happily buying up hard
disks, waiting hours, days, weeks to spawn up new full nodes. I'm
envisioning a world where every person has access to this technology and
finds it practical, convenient, and safe ti use.
- Eric Lombrozo
On Jul 5, 2015 11:50 AM, "Eric Lombrozo" <elombrozo@gmail.com> wrote:
> 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
>
--089e0160b420dee7a1051a262cc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I should clarify that by "most use cases" I'm =
not envisioning a bunch of cryptogeeks [us, or at least myself and a few of=
us] happily buying up hard disks, waiting hours, days, weeks to spawn up n=
ew full nodes. I'm envisioning a world where every person has access to=
this technology and finds it practical, convenient, and safe ti use.</p>
<p dir=3D"ltr">- Eric Lombrozo</p>
<div class=3D"gmail_quote">On Jul 5, 2015 11:50 AM, "Eric Lombrozo&quo=
t; <<a href=3D"mailto:elombrozo@gmail.com">elombrozo@gmail.com</a>> w=
rote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr"=
>Blockchain validation has become too expensive to properly secure the netw=
ork 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 comple=
tely 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>
</blockquote></div>
--089e0160b420dee7a1051a262cc0--
|
