{"type":"rich","version":"1.0","author_name":"npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","author_url":"https://nostr.ae/npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krq","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-07-31\n📝 Original message:I generally agree with this as well. I think it is crucial we avoid\ncontroversial hardforks. The risks greatly outweigh the benefits.\n\nThis is a good start to making it less controversial.\n\n- Eric\nOn Jul 31, 2015 2:31 PM, \"Jorge Timón\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e These are the types of things I have been discussing in relation to a\n\u003e \u003e process:\n\u003e \u003e\n\u003e \u003e -A list of metrics\n\u003e \u003e -A Risk analysis of the baseline system.  Bitcoin as it is now.\n\u003e \u003e -Mitigation strategies for each risk.\n\u003e \u003e -A set of goals.\n\u003e \u003e -A Road map for each goal that lists the changes or possible avenues to\n\u003e \u003e achieve that goal.\n\u003e \u003e\n\u003e \u003e Proposed changes would be measured against the same metrics and a risk\n\u003e \u003e analysis done so it can be compared with the baseline.\n\u003e \u003e\n\u003e \u003e For example, the block size debate would be discussed in the context of a\n\u003e \u003e road map related to a goal of increase scaling.  One of the metrics\n\u003e would be\n\u003e \u003e a decentralization metric.  (A framework for a decentralization metric\n\u003e is at\n\u003e \u003e\n\u003e http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf\n\u003e ).\n\u003e \u003e Cost would be one aspect of the decentralization metric.\n\u003e\n\u003e All this sounds very reasonable and useful.\n\u003e And if a formal organization owns this \"process\", that's fine as well.\n\u003e I still think hardforks need to be uncontroversial (using the vague \"I\n\u003e will know it when I see it\" defintion) and no individual or\n\u003e organization can be an \"ultimate decider\" or otherwise Bitcoin losses\n\u003e all it's p2p nature (and this seems the point where you, Milly, and I\n\u003e disagree).\n\u003e But metrics and data tend to help when it comes to \"I will know it\n\u003e when I see it\" and \"evidences\".\n\u003e So, yes, by all means, let's have an imperfect decentralization metric\n\u003e rather than not having anything to compare proposals. Competing\n\u003e decentralization metrics can appear later: we need a first one first.\n\u003e I would add that we should have sets of simulations being used to\n\u003e calculate some of those metrics, but maybe I'm just going too deep\n\u003e into details.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/632e7277/attachment.html\u003e"}