path: root/52/ebbd51cedd6eae284b0abfdcb83ad3e34cfbdf

Return-Path: <jeanpaulkogelman@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C7F84488
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <jeanpaulkogelman@me.com>
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: <f9e27b28-f967-45f7-bd1b-c427534ade9c@me.com>
To: Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <jeanpaulkogelman@me.com>
> Date: July 31, 2015 at 4:02:20 PM PDT
> To: Jorge Tim=A8=AEn <jtimon@jtimon.cc>
> 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 <bitcoin-d=
ev@lists.linuxfoundation.org> wrote:
>>=20
>=20
>> 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:
>>>=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

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div>Forgot to include the list.&nbsp;</div=
><div><br></div><div><br></div><blockquote type=3D"cite"><div><b>From:</b> J=
ean-Paul Kogelman &lt;<a href=3D"mailto:jeanpaulkogelman@me.com">jeanpaulkog=
elman@me.com</a>&gt;<br><b>Date:</b> July 31, 2015 at 4:02:20 PM PDT<br><b>T=
o:</b> Jorge Tim=C3=B3n &lt;<a href=3D"mailto:jtimon@jtimon.cc">jtimon@jtimo=
n.cc</a>&gt;<br><b>Cc:</b> <a href=3D"mailto:milly@bitcoins.info">milly@bitc=
oins.info</a><br><b>Subject:</b> <b>Re: [bitcoin-dev] Why Satoshi's temporar=
y anti-spam measure isn't	temporary</b><br><br></div></blockquote><bl=
ockquote type=3D"cite"><div><div><br></div><div>I wrote about this a earlier=
 this month:&nbsp;<a href=3D"http://www.mail-archive.com/bitcoin-dev@lists.l=
inuxfoundation.org/msg00383.html">http://www.mail-archive.com/bitcoin-dev@li=
sts.linuxfoundation.org/msg00383.html</a></div><div><br></div><div>You basic=
ally want 3 things:</div><div><br></div><div>- A Minimum Specification of ha=
rdware: This is the lowest hardware configuration Bitcoin Core will run on a=
t maximum capacity.</div><div>- A theoretical model that takes into account a=
ll of the components in Bitcoin Core and how they affect Min Spec.</div><div=
>- A benchmark tool to measure how changes affect Min Spec (and for users to=
 see how their hardware measures up to Min Spec).</div><div><br></div><div>j=
p</div><div><br>On Jul 31, 2015, at 02:31 PM, Jorge Tim=C3=B3n via bitcoin-d=
ev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br><br></div><div><blockquote type=3D=
"cite"><div class=3D"msg-quote"><div class=3D"_stretch"><span class=3D"body-=
text-content"><span class=3D"body-text-content">On Fri, Jul 31, 2015 at 2:15=
 AM, Milly Bitcoin via bitcoin-dev<br>&lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" data-mce-href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></span></s=
pan><blockquote class=3D"quoted-plain-text" type=3D"cite">These are the type=
s of things I have been discussing in relation to a</blockquote><blockquote c=
lass=3D"quoted-plain-text" type=3D"cite">process:</blockquote><blockquote cl=
ass=3D"quoted-plain-text" type=3D"cite"><br></blockquote><blockquote class=3D=
"quoted-plain-text" type=3D"cite">-A list of metrics</blockquote><blockquote=
 class=3D"quoted-plain-text" type=3D"cite">-A Risk analysis of the baseline s=
ystem. Bitcoin as it is now.</blockquote><blockquote class=3D"quoted-plain-t=
ext" type=3D"cite">-Mitigation strategies for each risk.</blockquote><blockq=
uote class=3D"quoted-plain-text" type=3D"cite">-A set of goals.</blockquote>=
<blockquote class=3D"quoted-plain-text" type=3D"cite">-A Road map for each g=
oal that lists the changes or possible avenues to</blockquote><blockquote cl=
ass=3D"quoted-plain-text" type=3D"cite">achieve that goal.</blockquote><bloc=
kquote class=3D"quoted-plain-text" type=3D"cite"><br></blockquote><blockquot=
e class=3D"quoted-plain-text" type=3D"cite">Proposed changes would be measur=
ed against the same metrics and a risk</blockquote><blockquote class=3D"quot=
ed-plain-text" type=3D"cite">analysis done so it can be compared with the ba=
seline.</blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite"><b=
r></blockquote><blockquote class=3D"quoted-plain-text" type=3D"cite">For exa=
mple, the block size debate would be discussed in the context of a</blockquo=
te><blockquote class=3D"quoted-plain-text" type=3D"cite">road map related to=
 a goal of increase scaling. One of the metrics would be</blockquote><blockq=
uote class=3D"quoted-plain-text" type=3D"cite">a decentralization metric. (A=
 framework for a decentralization metric is at</blockquote><blockquote class=
=3D"quoted-plain-text" type=3D"cite"><a href=3D"http://www.hks.harvard.edu/f=
s/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf" data-mce=
-href=3D"http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Sch=
neider_Decentralization.pdf">http://www.hks.harvard.edu/fs/pnorris/Acrobat/s=
tm103%20articles/Schneider_Decentralization.pdf</a>).</blockquote><blockquot=
e class=3D"quoted-plain-text" type=3D"cite">Cost would be one aspect of the d=
ecentralization metric.</blockquote><span class=3D"body-text-content"><br>Al=
l this sounds very reasonable and useful.<br>And if a formal organization ow=
ns this "process", that's fine as well.<br>I still think hardforks need to b=
e uncontroversial (using the vague "I<br>will know it when I see it" definti=
on) and no individual or<br>organization can be an "ultimate decider" or oth=
erwise Bitcoin losses<br>all it's p2p nature (and this seems the point where=
 you, Milly, and I<br>disagree).<br>But metrics and data tend to help when i=
t comes to "I will know it<br>when I see it" and "evidences".<br>So, yes, by=
 all means, let's have an imperfect decentralization metric<br>rather than n=
ot having anything to compare proposals. Competing<br>decentralization metri=
cs can appear later: we need a first one first.<br>I would add that we shoul=
d have sets of simulations being used to<br>calculate some of those metrics,=
 but maybe I'm just going too deep<br>into details.<br>_____________________=
__________________________<br>bitcoin-dev mailing list<br><a href=3D"mailto:=
bitcoin-dev@lists.linuxfoundation.org" data-mce-href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a><br><a hr=
ef=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" data-m=
ce-href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">h=
ttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></span>=
</div></div></blockquote></div></div></blockquote></body></html>=

--Apple-Mail-BD83A250-2FBC-4055-A48F-046D8E9C4E13--