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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <elombrozo@gmail.com>) id 1Yz049-0007gc-D9
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 10:02:01 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.181 as permitted sender)
client-ip=209.85.217.181; envelope-from=elombrozo@gmail.com;
helo=mail-lb0-f181.google.com;
Received: from mail-lb0-f181.google.com ([209.85.217.181])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Yz048-0006bF-F5
for bitcoin-development@lists.sourceforge.net;
Sun, 31 May 2015 10:02:01 +0000
Received: by lbbuc2 with SMTP id uc2so69438501lbb.2
for <bitcoin-development@lists.sourceforge.net>;
Sun, 31 May 2015 03:01:54 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.182.4 with SMTP id ea4mr10792909lbc.35.1433066514029;
Sun, 31 May 2015 03:01:54 -0700 (PDT)
Received: by 10.112.201.137 with HTTP; Sun, 31 May 2015 03:01:53 -0700 (PDT)
Received: by 10.112.201.137 with HTTP; Sun, 31 May 2015 03:01:53 -0700 (PDT)
In-Reply-To: <CADJgMztZuqt1BM8S2W1nOOBET=na+L+SZe4RRPdLU4tnbA-7cA@mail.gmail.com>
References: <3698747.VeHb3lFFLZ@crushinator>
<CADJgMztZuqt1BM8S2W1nOOBET=na+L+SZe4RRPdLU4tnbA-7cA@mail.gmail.com>
Date: Sun, 31 May 2015 03:01:53 -0700
Message-ID: <CABr1YTcSPcJBb-ZFQ59cYuywix4bfKpic_KjBProiAZ47o8fPg@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Btc Drak <btcdrak@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c3728e8228fc05175dcc16
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(elombrozo[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Yz048-0006bF-F5
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposal: A measured response to save
Bitcoin Core
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Sun, 31 May 2015 10:02:01 -0000
--001a11c3728e8228fc05175dcc16
Content-Type: text/plain; charset=UTF-8
Drak,
I mostly agree with your assessment...except for your last claim.
Not that I wouldn't like to find a way to avoid politics, but like I've
argued before, it is inevitable that sooner or later any consensus protocol
that seeks dynamism will encounter politics.
The block size discussion, while ultimately necessary, for now is in the
best case merely serving as an example of the kind of political issues we
*really* need to be finding some solution for...and in the worst case is a
distraction and evasion.
Some protocol updates will be merely technical optimizations or feature
enhancements that are fairly uncontroversial...but some will inevitably be
highly controversial with real-world economic consequences, winners and
losers. We lack a process for deciding these issues. No matter how
sophistocated we make the protocol, somethings will inevitably require
external input to make these issues decidable...it is a Goedelian
implication. This external input could be some sort of vote (of which
hashing power is a particular kind) or perhaps something else.
There's something to be said for building the dynamics of hard forks *into*
our model rather than avoiding it at all costs. However, forks are the
easy part. The difficulty is in merging different branches. Perhaps we
should learn a thing or two from git. Perhaps the question we should be
asking is not "how do we avoid hard forks" but "how can we design the
network to allow for merging?"
- Eric Lombrozo
--001a11c3728e8228fc05175dcc16
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Drak,</p>
<p dir=3D"ltr">I mostly agree with your assessment...except for your last c=
laim.</p>
<p dir=3D"ltr">Not that I wouldn't like to find a way to avoid politics=
, but like I've argued before, it is inevitable that sooner or later an=
y consensus protocol that seeks dynamism will encounter politics.</p>
<p dir=3D"ltr">The block size discussion, while ultimately necessary, for n=
ow is in the best case merely serving as an example of the kind of politica=
l issues we *really* need to be finding some solution for...and in the wors=
t case is a distraction and evasion.</p>
<p dir=3D"ltr">Some protocol updates will be merely technical optimizations=
or feature enhancements that are fairly uncontroversial...but some will in=
evitably be highly controversial with real-world economic consequences, win=
ners and losers. We lack a process for deciding these issues. No matter how=
sophistocated we make the protocol, somethings will inevitably require ext=
ernal input to make these issues decidable...it is a Goedelian implication.=
This external input could be some sort of vote (of which hashing power is =
a particular kind) or perhaps something else.</p>
<p dir=3D"ltr">There's something to be said for building the dynamics o=
f hard forks *into* our model rather than avoiding it at all costs.=C2=A0 H=
owever, forks are the easy part. The difficulty is in merging different bra=
nches. Perhaps we should learn a thing or two from git. Perhaps the questio=
n we should be asking is not "how do we avoid hard forks" but &qu=
ot;how can we design the network to allow for merging?"</p>
<p dir=3D"ltr">- Eric Lombrozo</p>
--001a11c3728e8228fc05175dcc16--
|
