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>
Subject: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
	isn't	temporary
Precedence: list


--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--