1 Aug 01:05 2015
Why Satoshi's temporary anti-spam measure isn't temporary
Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev <at> lists.linuxfoundation.org>
2015-07-31 23:05:47 GMT
2015-07-31 23:05:47 GMT
Forgot to include the list.
I wrote about this a earlier this month: http://www.mail-archive.com/bitcoin-dev <at> lists.linuxfoundation.org/msg00383.htmlYou 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 <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 aprocess:-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 toachieve that goal.Proposed changes would be measured against the same metrics and a riskanalysis done so it can be compared with the baseline.For example, the block size debate would be discussed in the context of aroad map related to a goal of increase scaling. One of the metrics would bea decentralization metric. (A framework for a decentralization metric is atCost 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
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
bitcoin-dev mailing list
bitcoin-dev <at> lists.linuxfoundation.org
_______________________________________________ bitcoin-dev mailing list bitcoin-dev <at> lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev