Jean-Paul Kogelman [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-31 📝 Original message:Forgot to include the ...
📅 Original date posted:2015-07-31
📝 Original message:Forgot to include the list.
> From: Jean-Paul Kogelman <jeanpaulkogelman at me.com>
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón <jtimon at jtimon.cc>
> Cc: milly at 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 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/b2113cb4/attachment-0001.html>;
📝 Original message:Forgot to include the list.
> From: Jean-Paul Kogelman <jeanpaulkogelman at me.com>
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón <jtimon at jtimon.cc>
> Cc: milly at 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 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/b2113cb4/attachment-0001.html>;