rich1.0npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqhttps://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqnjumphttps://nostr.ae📅 Original date posted:2015-07-31 📝 Original message: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ón" < bitcoin-dev at lists.linuxfoundation.org> wrote: > 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. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/632e7277/attachment.html>