rich1.0npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8https://nostr.ae/npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8njumphttps://nostr.ae📅 Original date posted:2015-07-31 📝 Original message:On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev <bitcoin-dev at 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.