📅 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>;
Jean-Paul Kogelman [ARCHIVE] /
npub1sa…8y304
2023-06-07 15:43:55
in reply to nevent1q…5zgq
Author Public Key
npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304Published at
2023-06-07 15:43:55Event JSON
{
"id": "291632afbdbeccdf2a54409d9382714782c597be9f59192ebd1b02ab0d167b02",
"pubkey": "874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349",
"created_at": 1686152635,
"kind": 1,
"tags": [
[
"e",
"78a0486a22513a5dc11dcf66d2407a7e121084a44d2ff4e480cb77dad38c8ddd",
"",
"root"
],
[
"e",
"c2caef16a31b2aa816399a486dadd456cbb711ed89a59cd022c8ad24daf4958f",
"",
"reply"
],
[
"p",
"1b29d94ee81e1ee0479f1db4bc4ac887407bd470a0d7060e76f8ab27fdd57e50"
]
],
"content": "📅 Original date posted:2015-07-31\n📝 Original message:Forgot to include the list. \n\n\n\u003e From: Jean-Paul Kogelman \u003cjeanpaulkogelman at me.com\u003e\n\u003e Date: July 31, 2015 at 4:02:20 PM PDT\n\u003e To: Jorge Timón \u003cjtimon at jtimon.cc\u003e\n\u003e Cc: milly at bitcoins.info\n\u003e Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't\ttemporary\n\u003e \n\u003e \n\u003e I wrote about this a earlier this month: http://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg00383.html\n\u003e \n\u003e You basically want 3 things:\n\u003e \n\u003e - A Minimum Specification of hardware: This is the lowest hardware configuration Bitcoin Core will run on at maximum capacity.\n\u003e - A theoretical model that takes into account all of the components in Bitcoin Core and how they affect Min Spec.\n\u003e - A benchmark tool to measure how changes affect Min Spec (and for users to see how their hardware measures up to Min Spec).\n\u003e \n\u003e jp\n\u003e \n\u003e\u003e On Jul 31, 2015, at 02:31 PM, Jorge Timón via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e \n\u003e \n\u003e\u003e On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\u003e These are the types of things I have been discussing in relation to a\n\u003e\u003e\u003e process:\n\u003e\u003e\u003e \n\u003e\u003e\u003e -A list of metrics\n\u003e\u003e\u003e -A Risk analysis of the baseline system. Bitcoin as it is now.\n\u003e\u003e\u003e -Mitigation strategies for each risk.\n\u003e\u003e\u003e -A set of goals.\n\u003e\u003e\u003e -A Road map for each goal that lists the changes or possible avenues to\n\u003e\u003e\u003e achieve that goal.\n\u003e\u003e\u003e \n\u003e\u003e\u003e Proposed changes would be measured against the same metrics and a risk\n\u003e\u003e\u003e analysis done so it can be compared with the baseline.\n\u003e\u003e\u003e \n\u003e\u003e\u003e For example, the block size debate would be discussed in the context of a\n\u003e\u003e\u003e road map related to a goal of increase scaling. One of the metrics would be\n\u003e\u003e\u003e a decentralization metric. (A framework for a decentralization metric is at\n\u003e\u003e\u003e http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf).\n\u003e\u003e\u003e Cost would be one aspect of the decentralization metric.\n\u003e\u003e \n\u003e\u003e All this sounds very reasonable and useful.\n\u003e\u003e And if a formal organization owns this \"process\", that's fine as well.\n\u003e\u003e I still think hardforks need to be uncontroversial (using the vague \"I\n\u003e\u003e will know it when I see it\" defintion) and no individual or\n\u003e\u003e organization can be an \"ultimate decider\" or otherwise Bitcoin losses\n\u003e\u003e all it's p2p nature (and this seems the point where you, Milly, and I\n\u003e\u003e disagree).\n\u003e\u003e But metrics and data tend to help when it comes to \"I will know it\n\u003e\u003e when I see it\" and \"evidences\".\n\u003e\u003e So, yes, by all means, let's have an imperfect decentralization metric\n\u003e\u003e rather than not having anything to compare proposals. Competing\n\u003e\u003e decentralization metrics can appear later: we need a first one first.\n\u003e\u003e I would add that we should have sets of simulations being used to\n\u003e\u003e calculate some of those metrics, but maybe I'm just going too deep\n\u003e\u003e into details.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150731/b2113cb4/attachment-0001.html\u003e",
"sig": "9192f1a2e2a44ae797322cd0d395fbcf2a43c65cf01174bbcb3caf6f07f70879191add98dca853d7fde785dc977d92ac47bf80273f502e9b76d27c4a428d164d"
}