Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-31 📝 Original message:I generally agree with ...
📅 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>;
📝 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>;