MIME-Version: 1.0
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
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
Precedence: list

--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, &quot;Jorge Tim=C3=B3n&=
quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a>&gt; 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>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; These are the types of things I have been discussing in relation to a<=
br>
&gt; process:<br>
&gt;<br>
&gt; -A list of metrics<br>
&gt; -A Risk analysis of the baseline system.=C2=A0 Bitcoin as it is now.<b=
r>
&gt; -Mitigation strategies for each risk.<br>
&gt; -A set of goals.<br>
&gt; -A Road map for each goal that lists the changes or possible avenues t=
o<br>
&gt; achieve that goal.<br>
&gt;<br>
&gt; Proposed changes would be measured against the same metrics and a risk=
<br>
&gt; analysis done so it can be compared with the baseline.<br>
&gt;<br>
&gt; For example, the block size debate would be discussed in the context o=
f a<br>
&gt; road map related to a goal of increase scaling.=C2=A0 One of the metri=
cs would be<br>
&gt; a decentralization metric.=C2=A0 (A framework for a decentralization m=
etric is at<br>
&gt; <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>
&gt; 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 &quot;process&quot;, that&#39;s fine=
 as well.<br>
I still think hardforks need to be uncontroversial (using the vague &quot;I=
<br>
will know it when I see it&quot; defintion) and no individual or<br>
organization can be an &quot;ultimate decider&quot; or otherwise Bitcoin lo=
sses<br>
all it&#39;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 &quot;I will know it<br>
when I see it&quot; and &quot;evidences&quot;.<br>
So, yes, by all means, let&#39;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&#39;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--