<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Forgot to include the list.&nbsp;</div><div><br></div><div><br></div><blockquote type="cite"><div><b>From:</b> Jean-Paul Kogelman &lt;<a href="mailto:jeanpaulkogelman@me.com">jeanpaulkogelman@me.com</a>&gt;<br><b>Date:</b> July 31, 2015 at 4:02:20 PM PDT<br><b>To:</b> Jorge Timón &lt;<a href="mailto:jtimon@jtimon.cc">jtimon@jtimon.cc</a>&gt;<br><b>Cc:</b> <a href="mailto:milly@bitcoins.info">milly@bitcoins.info</a><br><b>Subject:</b> <b>Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't        temporary</b><br><br></div></blockquote><blockquote type="cite"><div><div><br></div><div>I wrote about this a earlier this month:&nbsp;<a href="http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00383.html">http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00383.html</a></div><div><br></div><div>You basically want 3 things:</div><div><br></div><div>- A Minimum Specification of hardware: This is the lowest hardware configuration Bitcoin Core will run on at maximum capacity.</div><div>- A theoretical model that takes into account all of the components in Bitcoin Core and how they affect Min Spec.</div><div>- A benchmark tool to measure how changes affect Min Spec (and for users to see how their hardware measures up to Min Spec).</div><div><br></div><div>jp</div><div><br>On Jul 31, 2015, at 02:31 PM, Jorge Timón via bitcoin-dev &lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><div><blockquote type="cite"><div class="msg-quote"><div class="_stretch"><span class="body-text-content"><span class="body-text-content">On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev<br>&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" data-mce-href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></span></span><blockquote class="quoted-plain-text" type="cite">These are the types of things I have been discussing in relation to a</blockquote><blockquote class="quoted-plain-text" type="cite">process:</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">-A list of metrics</blockquote><blockquote class="quoted-plain-text" type="cite">-A Risk analysis of the baseline system. Bitcoin as it is now.</blockquote><blockquote class="quoted-plain-text" type="cite">-Mitigation strategies for each risk.</blockquote><blockquote class="quoted-plain-text" type="cite">-A set of goals.</blockquote><blockquote class="quoted-plain-text" type="cite">-A Road map for each goal that lists the changes or possible avenues to</blockquote><blockquote class="quoted-plain-text" type="cite">achieve that goal.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">Proposed changes would be measured against the same metrics and a risk</blockquote><blockquote class="quoted-plain-text" type="cite">analysis done so it can be compared with the baseline.</blockquote><blockquote class="quoted-plain-text" type="cite"><br></blockquote><blockquote class="quoted-plain-text" type="cite">For example, the block size debate would be discussed in the context of a</blockquote><blockquote class="quoted-plain-text" type="cite">road map related to a goal of increase scaling. One of the metrics would be</blockquote><blockquote class="quoted-plain-text" type="cite">a decentralization metric. (A framework for a decentralization metric is at</blockquote><blockquote class="quoted-plain-text" type="cite"><a href="http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf" data-mce-href="http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf">http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf</a>).</blockquote><blockquote class="quoted-plain-text" type="cite">Cost would be one aspect of the decentralization metric.</blockquote><span class="body-text-content"><br>All this sounds very reasonable and useful.<br>And if a formal organization owns this "process", that's fine as well.<br>I still think hardforks need to be uncontroversial (using the vague "I<br>will know it when I see it" defintion) and no individual or<br>organization can be an "ultimate decider" or otherwise Bitcoin losses<br>all it's p2p nature (and this seems the point where you, Milly, and I<br>disagree).<br>But metrics and data tend to help when it comes to "I will know it<br>when I see it" and "evidences".<br>So, yes, by all means, let's have an imperfect decentralization metric<br>rather than not having anything to compare proposals. Competing<br>decentralization metrics can appear later: we need a first one first.<br>I would add that we should have sets of simulations being used to<br>calculate some of those metrics, but maybe I'm just going too deep<br>into details.<br>_______________________________________________<br>bitcoin-dev mailing list<br><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" data-mce-href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br><a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" data-mce-href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></span></div></div></blockquote></div></div></blockquote></body></html>