From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
To: Jean-Paul Kogelman via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary
Date: Fri, 31 Jul 2015 16:05:47 -0700 [thread overview]
Message-ID: <96620811-9D4E-4509-8885-42549D0B49A7@me.com> (raw)
In-Reply-To: f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com
[-- Attachment #1: Type: text/plain, Size: 3090 bytes --]
Forgot to include the list.
> From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Timón <jtimon@jtimon.cc>
> Cc: milly@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
[-- Attachment #2: Type: text/html, Size: 5636 bytes --]
next parent reply other threads:[~2015-07-31 23:05 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com>
2015-07-31 23:05 ` Jean-Paul Kogelman [this message]
2015-07-31 1:25 [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Raystonn
2015-07-31 3:18 ` Milly Bitcoin
-- strict thread matches above, loose matches on Subject: below --
2015-07-28 22:25 Eric Lombrozo
2015-07-29 0:43 ` Jean-Paul Kogelman
2015-07-29 0:44 ` Eric Lombrozo
2015-07-29 0:46 ` Mark Friedenbach
2015-07-29 0:55 ` Eric Lombrozo
2015-07-29 2:40 ` Eric Lombrozo
2015-07-29 3:37 ` Eric Lombrozo
2015-07-29 3:46 ` Milly Bitcoin
2015-07-29 5:17 ` Eric Lombrozo
2015-07-29 11:18 ` Thomas Zander
2015-07-29 9:59 ` Mike Hearn
2015-07-29 10:43 ` Eric Lombrozo
2015-07-29 11:15 ` Mike Hearn
2015-07-29 12:03 ` Eric Lombrozo
2015-07-29 12:13 ` Thomas Zander
2015-07-29 19:56 ` Owen
2015-07-29 20:09 ` Gregory Maxwell
2015-07-29 21:28 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Raystonn .
2015-07-29 22:11 ` Venzen Khaosan
2015-07-29 23:10 ` Raystonn .
2015-07-30 3:49 ` Adam Back
2015-07-30 4:51 ` Andrew LeCody
2015-07-30 8:21 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
2015-07-30 9:15 ` Eric Lombrozo
2015-07-30 12:29 ` Gavin
2015-07-30 12:50 ` Pieter Wuille
2015-07-30 14:03 ` Thomas Zander
2015-07-30 14:05 ` Gavin Andresen
2015-07-30 14:28 ` Pieter Wuille
2015-07-30 15:36 ` Jorge Timón
2015-07-30 23:33 ` Eric Lombrozo
2015-07-31 0:15 ` Milly Bitcoin
2015-07-31 21:30 ` Jorge Timón
2015-07-31 21:43 ` Eric Lombrozo
2015-07-31 6:42 ` Thomas Zander
2015-07-31 20:45 ` Eric Lombrozo
2015-07-31 20:57 ` Eric Lombrozo
2015-08-01 20:22 ` John T. Winslow
2015-08-01 21:05 ` Pieter Wuille
2015-07-29 11:29 ` Thomas Zander
2015-07-29 18:00 ` Jorge Timón
2015-07-30 7:08 ` Thomas Zander
2015-07-29 16:53 ` Gregory Maxwell
2015-07-29 17:30 ` Sriram Karra
2015-07-29 18:03 ` Mike Hearn
2015-07-29 19:53 ` Gregory Maxwell
2015-07-30 14:15 ` Thomas Zander
2015-07-30 9:05 ` odinn
2015-07-30 15:24 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary Bryan Bishop
2015-07-30 16:07 ` Thomas Zander
2015-07-30 17:42 ` Thomas Zander
2015-07-30 18:02 ` Mark Friedenbach
2015-07-31 0:22 ` [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary Eric Lombrozo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=96620811-9D4E-4509-8885-42549D0B49A7@me.com \
--to=jeanpaulkogelman@me.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox