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
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
|
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 E14F0484
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 21:43:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f48.google.com (mail-la0-f48.google.com
[209.85.215.48])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD9DB169
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 21:43:45 +0000 (UTC)
Received: by lafd3 with SMTP id d3so52050832laf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jul 2015 14:43:44 -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
:cc:content-type;
bh=1eX/N8WwM6+xwoueUAChbUnlq7hHg5p+gBs7FvZYdfc=;
b=wj4DDMJNjVFjuJqgsol+7UuPyJFH0tcebeRDGwL36rL68clrqCcHBD0c6LOfqStTmM
eBu3jUzPF9y8ecpRE5JvGqeMenAxgG+2OWIMUplza0imXF0xW4S6DRUoIz6ldALVgPmh
/3M9CEBy/SkkYJafN+yEs8KhaQTkMM2AScptWiVf0xuE/zUp7B5er+AwTNXxvA4BiYpH
aUyQg2VDHaTDaGFvBD7G2wHnEg+0zUbEHMZeKDjLUgEK6KZSqaEKg/0eBIFdaqNePYxn
r5Bv1d/r5cRrW8GX6DBUDhJyacUPf/qeaPNfjdobrgcUKhWAugmcZTCyDE7Kkn/X83k2
vhIw==
MIME-Version: 1.0
X-Received: by 10.152.5.65 with SMTP id q1mr5486065laq.110.1438379024183; Fri,
31 Jul 2015 14:43:44 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 14:43:43 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 31 Jul 2015 14:43:43 -0700 (PDT)
In-Reply-To: <CABm2gDppLdB5SSQrN1TW-EOBogARpgOXQR4F0ZY0Nn7oWGB5EQ@mail.gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
<CA+w+GKTZV5sgXNU_xoBby1_X6eae=5_vhENmyKY0yxWHcBiU5g@mail.gmail.com>
<37D282C2-EF9C-4B8B-91E8-7D613B381824@phauna.org>
<CAAS2fgSaRqxi3X0J3F05nA-tyRRikY1whkpAOuGJJpFSAR017w@mail.gmail.com>
<COL131-DS222F0D512C6A5B47BF62C2CD8C0@phx.gbl>
<55B94FAD.7040205@mail.bihthai.net>
<COL131-DS95F86B1D5B93CE1275911CD8C0@phx.gbl>
<CALqxMTEUAtNxkYMQwA9g9xH_LiX98yYOooGjUho1T3fMY2J5jQ@mail.gmail.com>
<CAEX2NSc6FXsDLEpRq7YOxQErpBxS7tW8Afk-T9VUyeb2qS2brQ@mail.gmail.com>
<74767203-7F7A-4848-9923-DE1DE60A28B4@gmail.com>
<F7601CF2-2B89-4D11-8B56-8FFF63A4063C@gmail.com>
<25FD9AAD-99F5-4322-AF34-243F75AE82C4@gmail.com>
<55BABE17.7050900@bitcoins.info>
<CABm2gDppLdB5SSQrN1TW-EOBogARpgOXQR4F0ZY0Nn7oWGB5EQ@mail.gmail.com>
Date: Fri, 31 Jul 2015 14:43:43 -0700
Message-ID: <CABr1YTfJX+fPMxC4+c-OPLM6du5NUJ6dO9zNtm5EvaGfe+65Wg@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: multipart/alternative; boundary=089e013d1754c9f764051c32b61f
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
Cc: Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
temporary
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: Fri, 31 Jul 2015 21:43:47 -0000
--089e013d1754c9f764051c32b61f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
I generally agree with this as well. I think it is crucial we avoid
controversial hardforks. The risks greatly outweigh the benefits.
This is a good start to making it less controversial.
- Eric
On Jul 31, 2015 2:31 PM, "Jorge Tim=C3=B3n" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > These are the types of things I have been discussing in relation to a
> > process:
> >
> > -A list of metrics
> > -A Risk analysis of the baseline system. Bitcoin as it is now.
> > -Mitigation strategies for each risk.
> > -A set of goals.
> > -A Road map for each goal that lists the changes or possible avenues to
> > achieve that goal.
> >
> > Proposed changes would be measured against the same metrics and a risk
> > analysis done so it can be compared with the baseline.
> >
> > For example, the block size debate would be discussed in the context of=
a
> > road map related to a goal of increase scaling. One of the metrics
> would be
> > a decentralization metric. (A framework for a decentralization metric
> is at
> >
> http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider=
_Decentralization.pdf
> ).
> > Cost would be one aspect of the decentralization metric.
>
> All this sounds very reasonable and useful.
> And if a formal organization owns this "process", that's fine as well.
> I still think hardforks need to be uncontroversial (using the vague "I
> will know it when I see it" defintion) and no individual or
> organization can be an "ultimate decider" or otherwise Bitcoin losses
> all it's p2p nature (and this seems the point where you, Milly, and I
> disagree).
> But metrics and data tend to help when it comes to "I will know it
> when I see it" and "evidences".
> So, yes, by all means, let's have an imperfect decentralization metric
> rather than not having anything to compare proposals. Competing
> decentralization metrics can appear later: we need a first one first.
> I would add that we should have sets of simulations being used to
> calculate some of those metrics, but maybe I'm just going too deep
> into details.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--089e013d1754c9f764051c32b61f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I generally agree with this as well. I think it is crucial w=
e avoid controversial hardforks. The risks greatly outweigh the benefits.</=
p>
<p dir=3D"ltr">This is a good start to making it less controversial.</p>
<p dir=3D"ltr">- Eric</p>
<div class=3D"gmail_quote">On Jul 31, 2015 2:31 PM, "Jorge Tim=C3=B3n&=
quot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex">On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via=
bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> These are the types of things I have been discussing in relation to a<=
br>
> process:<br>
><br>
> -A list of metrics<br>
> -A Risk analysis of the baseline system.=C2=A0 Bitcoin as it is now.<b=
r>
> -Mitigation strategies for each risk.<br>
> -A set of goals.<br>
> -A Road map for each goal that lists the changes or possible avenues t=
o<br>
> achieve that goal.<br>
><br>
> Proposed changes would be measured against the same metrics and a risk=
<br>
> analysis done so it can be compared with the baseline.<br>
><br>
> For example, the block size debate would be discussed in the context o=
f a<br>
> road map related to a goal of increase scaling.=C2=A0 One of the metri=
cs would be<br>
> a decentralization metric.=C2=A0 (A framework for a decentralization m=
etric is at<br>
> <a href=3D"http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20arti=
cles/Schneider_Decentralization.pdf" rel=3D"noreferrer" target=3D"_blank">h=
ttp://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_De=
centralization.pdf</a>).<br>
> Cost would be one aspect of the decentralization metric.<br>
<br>
All this sounds very reasonable and useful.<br>
And if a formal organization owns this "process", that's fine=
as well.<br>
I still think hardforks need to be uncontroversial (using the vague "I=
<br>
will know it when I see it" defintion) and no individual or<br>
organization can be an "ultimate decider" or otherwise Bitcoin lo=
sses<br>
all it's p2p nature (and this seems the point where you, Milly, and I<b=
r>
disagree).<br>
But metrics and data tend to help when it comes to "I will know it<br>
when I see it" and "evidences".<br>
So, yes, by all means, let's have an imperfect decentralization metric<=
br>
rather than not having anything to compare proposals. Competing<br>
decentralization metrics can appear later: we need a first one first.<br>
I would add that we should have sets of simulations being used to<br>
calculate some of those metrics, but maybe I'm just going too deep<br>
into details.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--089e013d1754c9f764051c32b61f--
|
