path: root/0d/78ac5d981acf0a784f0e8796a6caa01510251b

Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 3F5E9B61
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Apr 2017 13:28:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f180.google.com (mail-qt0-f180.google.com
	[209.85.216.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9E33D10A
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  7 Apr 2017 13:28:15 +0000 (UTC)
Received: by mail-qt0-f180.google.com with SMTP id v3so10820347qtd.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 07 Apr 2017 06:28:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to; bh=bnzyxOK3+StvuuG2gccOWGvAxc58U0AkGbYbOxQd+1I=;
	b=cBloHKLm7mNzTbFRWkL+YSdfmvVpjWji3iWx1JRhsDB36lil1JR2PhREbSdrAwIsyn
	Ve/DpuKevD5PwhwPak73xryO9WPOSv/hOeMin7wYDVojtLi4ahup58T4taMCCR6rZDXU
	ZXSnonhXCnOP9fx90P6A57tmo23mr0uy2xFkDESnfpcoqfaK3gw5sWELJ6FJYcuRW26a
	gop+9jFXwn/KcRoaIolJJmd4ID5aCmHpmsnRmQib9HZPaO/5hlpGLAgbi5JiqV6KJY6+
	POrd48A9zjvoAZR14iNHPf/zuc1LgGJiNMIfPclRd5l8vQAyLZv2a7u12EGJtE7g6DEy
	GPpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to;
	bh=bnzyxOK3+StvuuG2gccOWGvAxc58U0AkGbYbOxQd+1I=;
	b=Hx/qkCujelDz6P8O5dZu159i/MYTmeQVc3SrKpPAfGmPK+KB6n1u6EWAYdypqVe77I
	WXXnCn2NqPzx6+zUii1hZu7k9WZucXuYIjNUq+z2fx/ncJ222kxK/AaZHib3UEsuL7pO
	fmIKQ6hoJi6mMv2glwn2My8dKCBtrWiXGQ4a3zZDwvx8HphyCa78Kh3WWkak55aXizrj
	latGwIxrPrmKIGqnd4gkJZ5svpjWqRQ5cIZcIhonrzAJ2hTi9/Y55sjwZpourJEnAO6j
	ANNOnVZePcKtC1RHK/Olk3pl/NYupLnQKxYFP6KyO4X/nF84tEEywnc0defl6ScHc/Hk
	fH1Q==
X-Gm-Message-State: AFeK/H2+UMC675vWfzgtb0osmDNr3wn3vkTB3STCIhplBK1kyQZo6SXug/Fd7FvO56iXNseI+NW3PXljj+u0qA==
X-Received: by 10.200.50.92 with SMTP id y28mr44552416qta.289.1491571694504;
	Fri, 07 Apr 2017 06:28:14 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.200.55.113 with HTTP; Fri, 7 Apr 2017 06:28:13 -0700 (PDT)
In-Reply-To: <CABeL=0hv3=Ak6soja8Am0+OOg6a8MUeHPi=YJnMdMsHNMG6HKQ@mail.gmail.com>
References: <CAAS2fgR84898xD0nyq7ykJnB7qkdoCJYnFg6z5WZEUu0+-=mMA@mail.gmail.com>
	<20170406023123.GA1071@savin.petertodd.org>
	<CA+KqGkqSxeAUZFVFqM_QkEWcGFHgZXwGuOE==7HpXp1+D_Tj3Q@mail.gmail.com>
	<20170406024910.GA1271@savin.petertodd.org>
	<CAFVRnyrqiNY_JOqhv2ysm2WsBMYsU3tTAASAtHzMbA68_9Yx8g@mail.gmail.com>
	<F5F02B94-E094-4C16-80B6-8B0876E423E4@toom.im>
	<CAE28kUQ4ebyo1WrMJTq658u4CZnLmnw40oZrNwRGHG+oW3UYbA@mail.gmail.com>
	<CABeL=0hv3=Ak6soja8Am0+OOg6a8MUeHPi=YJnMdMsHNMG6HKQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Fri, 7 Apr 2017 09:28:13 -0400
X-Google-Sender-Auth: 4zsUIgGzYne4QK7qZ7o1NInsAPw
Message-ID: <CAJowKgLG-MimT5pmS5FYhh=rA2oBc0wScoWGGa7hsQdQq_BU_A@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1137ba420211fa054c939990
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW,
	RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 07 Apr 2017 14:40:16 +0000
Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the
 Bitcoin POW function
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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, 07 Apr 2017 13:28:16 -0000

--001a1137ba420211fa054c939990
Content-Type: text/plain; charset=UTF-8

It is *not proof of stake.* when:

a) burn happens regardless of whether you successfully mine.
b) miner cannot know which tx are burns
c) the majority of burns cannot be used for mining and are simply lost
(poisson discovery distribution)
d) burn involves real risk: *every bit as much at stake *

(It's the difference between a computer secured by not being connected to
the internet, and a computer secured by re-imaging from a computer that
was, in the past, not connected to the internet.)

It is possible to craft a burn-network such that the only way for a miner
to prevent a burn is to prevent all transactions other than his own.

This is still a weakness, and I can't see a way around it though.


On Fri, Apr 7, 2017 at 8:59 AM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <bitcoin-dev@lists.
> linuxfoundation.org> wrote:
>
>>
>> Ethically, this situation has some similarities to the DAO fork.
>>
>>
>> Much better analogy:
>>
>> 1. An ISV make software which makes use of an undocumented OS feature.
>> 2. That feature is no longer present in the next OS release.
>> 3. ISV suffers losses because its software cannot work under new OS, and
>> thus people stop buying it.
>>
>> I think 99% of programmers would agree that this loss was inflicted by a
>> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
>> undocumented features is something you do on your own risk.
>>
>
> Right. And in this case, code still is law: if the code specifies a
> version number field and some miner finds an optimization that only works
> when the version number == 1 then it's his own problem once the network
> upgrades to version 2. In no way is there anything ethical about blocking
> the upgrade.
>
> History is not an indicator of the possible values any field can hold in
> the future. Limiting your operation to some arbitrary subset is at your own
> risk.
>
> Regarding the comparison: I haven't heard anyone even suggest rolling back
> the last year of the blockchain to undo the damage already done, any
> comparison can end there. If Jonathan wants to persist with this comparison
> it would be more like people deciding to stop further funding of the hacked
> contract. Yeah, that evil.
>
> --
> Jannes Faber
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--001a1137ba420211fa054c939990
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>It is *not proof of stake.* when:<br><=
br>a) <span class=3D"gmail-il">burn</span> happens regardless of whether yo=
u successfully mine.<br></div>b) miner cannot know which tx are <span class=
=3D"gmail-il">burns</span><br></div><div>c) the majority of <span class=3D"=
gmail-il">burns</span> cannot be used for mining and are simply lost (poiss=
on discovery distribution)<br></div><div>d) burn involves real risk: <i>eve=
ry bit as much at stake </i><br></div><div><br></div><i></i></div>(It&#39;s
 the difference between a computer secured by not being connected to the
 internet, and a computer secured by re-imaging from a computer that=20
was, in the past, not connected to the internet.)<br><br>It is possible to =
craft a burn-network such that the only way for a miner to prevent a <span =
class=3D"gmail-il">burn</span> is to prevent all transactions other than hi=
s own.=C2=A0 <br></div><div></div><div><br></div><div>This is still a weakn=
ess, and I can&#39;t see a way around it though.<br></div><div><br></div></=
div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 7=
, 2017 at 8:59 AM, Jannes Faber via bitcoin-dev <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote"><span class=3D"">On 6 April 2017 at 19:13, Alex Mizrahi via b=
itcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxf=
oundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><=
div class=3D"gmail_extra"><div class=3D"gmail_quote"><span><br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">Ethically, this situation has some similarities to the D=
AO fork.=C2=A0</blockquote><div><br></div></span><div>Much better analogy:<=
/div><div><br></div><div>1. An ISV make software which makes use of an undo=
cumented OS feature.</div><div>2. That feature is no longer present in the =
next OS release.</div><div>3. ISV suffers losses because its software canno=
t work under new OS, and thus people stop buying it.</div><div><br></div><d=
iv>I think 99% of programmers would agree that this loss was inflicted by a=
 bad decision of ISV, and not by OS vendor changing OS internals. Relying o=
n undocumented features is something you do on your own risk.</div></div></=
div></div></blockquote><div><br></div></span><div>Right. And in this case, =
code still is law: if the code specifies a version number field and some mi=
ner finds an optimization that only works when the version number =3D=3D 1 =
then it&#39;s his own problem once the network upgrades to version 2. In no=
 way is there anything ethical about blocking the upgrade.</div><div><br></=
div><div>History is not an indicator of the possible values any field can h=
old in the future. Limiting your operation to some arbitrary subset is at y=
our own risk.</div><div><br></div><div>Regarding the comparison: I haven&#3=
9;t heard anyone even suggest rolling back the last year of the blockchain =
to undo the damage already done, any comparison can end there. If Jonathan =
wants to persist with this comparison it would be more like people deciding=
 to stop further funding of the hacked contract. Yeah, that evil.</div><div=
><br></div><div>--</div><div>Jannes Faber</div><div><br></div></div></div><=
/div>
<br>______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a1137ba420211fa054c939990--