From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C7F84488 for ; Fri, 31 Jul 2015 23:05:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from st11p02im-asmtp002.me.com (st11p02im-asmtp002.me.com [17.172.220.114]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DF33BED for ; Fri, 31 Jul 2015 23:05:50 +0000 (UTC) Received: from [192.168.4.223] (unknown [159.153.136.65]) by st11p02im-asmtp002.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NSD002H8K5OR340@st11p02im-asmtp002.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 31 Jul 2015 23:05:50 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151,1.0.33,0.0.0000 definitions=2015-08-01_01:2015-07-31, 2015-07-31, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=3 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1412110000 definitions=main-1507310379 From: Jean-Paul Kogelman Content-type: multipart/alternative; boundary=Apple-Mail-BD83A250-2FBC-4055-A48F-046D8E9C4E13 Content-transfer-encoding: 7bit MIME-version: 1.0 (1.0) Message-id: <96620811-9D4E-4509-8885-42549D0B49A7@me.com> Date: Fri, 31 Jul 2015 16:05:47 -0700 References: To: Jean-Paul Kogelman via bitcoin-dev X-Mailer: iPhone Mail (12H143) X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't temporary X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 23:05:51 -0000 --Apple-Mail-BD83A250-2FBC-4055-A48F-046D8E9C4E13 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable Forgot to include the list.=20 > From: Jean-Paul Kogelman > Date: July 31, 2015 at 4:02:20 PM PDT > To: Jorge Tim=A8=AEn > Cc: milly@bitcoins.info > Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't= temporary >=20 >=20 > I wrote about this a earlier this month: http://www.mail-archive.com/bitco= in-dev@lists.linuxfoundation.org/msg00383.html >=20 > You basically want 3 things: >=20 > - A Minimum Specification of hardware: This is the lowest hardware configu= ration Bitcoin Core will run on at maximum capacity. > - A theoretical model that takes into account all of the components in Bit= coin Core and how they affect Min Spec. > - A benchmark tool to measure how changes affect Min Spec (and for users t= o see how their hardware measures up to Min Spec). >=20 > jp >=20 >> On Jul 31, 2015, at 02:31 PM, Jorge Tim=A8=AEn via bitcoin-dev wrote: >>=20 >=20 >> On Fri, Jul 31, 2015 at 2:15 AM, Milly Bitcoin via bitcoin-dev >> wrote: >>> These are the types of things I have been discussing in relation to a >>> process: >>>=20 >>> -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. >>>=20 >>> Proposed changes would be measured against the same metrics and a risk >>> analysis done so it can be compared with the baseline. >>>=20 >>> 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/Schneide= r_Decentralization.pdf). >>> Cost would be one aspect of the decentralization metric. >>=20 >> 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 --Apple-Mail-BD83A250-2FBC-4055-A48F-046D8E9C4E13 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Forgot to include the list. 


From: J= ean-Paul Kogelman <jeanpaulkog= elman@me.com>
Date: July 31, 2015 at 4:02:20 PM PDT
T= o: Jorge Tim=C3=B3n <jtimon@jtimo= n.cc>
Cc: milly@bitc= oins.info
Subject: Re: [bitcoin-dev] Why Satoshi's temporar= y anti-spam measure isn't temporary



You basic= ally want 3 things:

- A Minimum Specification of ha= rdware: This is the lowest hardware configuration Bitcoin Core will run on a= t maximum capacity.
- A theoretical model that takes into account a= ll 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).

j= p

On Jul 31, 2015, at 02:31 PM, Jorge Tim=C3=B3n via bitcoin-d= ev <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 type= s of things I have been discussing in relation to a
process:

-A list of metrics
-A Risk analysis of the baseline s= ystem. Bitcoin as it is now.
-Mitigation strategies for each risk.
-A set of goals.=
-A Road map for each g= oal that lists the changes or possible avenues to
achieve that goal.

Proposed changes would be measur= ed against the same metrics and a risk
analysis done so it can be compared with the ba= seline.
For exa= mple, 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/s= tm103%20articles/Schneider_Decentralization.pdf).
Cost would be one aspect of the d= ecentralization metric.
Al= l this sounds very reasonable and useful.
And if a formal organization ow= ns this "process", that's fine as well.
I still think hardforks need to b= e uncontroversial (using the vague "I
will know it when I see it" definti= on) and no individual or
organization can be an "ultimate decider" or oth= erwise 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 i= t 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 n= ot having anything to compare proposals. Competing
decentralization metri= cs can appear later: we need a first one first.
I would add that we shoul= d 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
h= ttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
=
= --Apple-Mail-BD83A250-2FBC-4055-A48F-046D8E9C4E13--