Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary

["Jorge Timón" <jtimon@jtimon.cc>]

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.