Forgot to include the list.
> From: Jean-Paul Kogelman <jeanpaulkogel...@me.com> > Date: July 31, 2015 at 4:02:20 PM PDT > To: Jorge Timón <jti...@jtimon.cc> > Cc: mi...@bitcoins.info > Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't > temporary > > > I wrote about this a earlier this month: > http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00383.html > > You basically want 3 things: > > - A Minimum Specification of hardware: This is the lowest hardware > configuration Bitcoin Core will run on at maximum capacity. > - A theoretical model that takes into account all of the components in > Bitcoin Core and how they affect Min Spec. > - A benchmark tool to measure how changes affect Min Spec (and for users to > see how their hardware measures up to Min Spec). > > jp > >> On Jul 31, 2015, at 02:31 PM, Jorge Timón via bitcoin-dev >> <bitcoin-dev@lists.linuxfoundation.org> wrote: >> > >> 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. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
