Return-Path: <sergio.d.lerner@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id DDBEDB5E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 May 2017 22:16:30 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com
	[209.85.220.180])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A157EF0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  8 May 2017 22:16:29 +0000 (UTC)
Received: by mail-qk0-f180.google.com with SMTP id a72so48574193qkj.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 08 May 2017 15:16:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=KBIaDJzEyyhotxTAYeBODoPqD2JNBkYDSaZVk4Fvzkg=;
	b=CtRcvE4W3z0ircM96/iJwbRboBpeL8RePdta4lDCfcpfx3UmhSHTwJUHvDpe1XZU07
	K2wxENX5C/3BfO4MwnmlNaRgYlMx8F5wleIqTOOIEI9Sy0o5aGN0tX3hucwuXicbDrKd
	wxVX8tPVNZOGMtioji2PuahuxVqcFMOW1G/dk1dvG9yjKe+juZXHOC7nxUnCkpeiv7qu
	yBhQWVhD3urZij+zPmk3yQ1pmCZTCfj7rCgsWcPF2WzN9NVVOwVXhCj9VIGbf80AjR2l
	rPOB59pjrVkNe/wb4gHhDHbVZ4uV8si1OH27LHD+EyHjf7R9JaPUGgyd9YyfLzmJ1l6U
	dJCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=KBIaDJzEyyhotxTAYeBODoPqD2JNBkYDSaZVk4Fvzkg=;
	b=YU4PqkLSycImWqEpFMhiY2cG1ejWT2JVjemOZsZXrF4Bh5zBObYgpeTxH1ZEe1L+AS
	mBDBhDYI3HHiWWkVci9erRdUZ3rxNWlxiHGHJMOCL5fJYu2vtSIYvF17bV6iUlLVubkU
	QLx53emn4RCxm0EC85BeutgeR8VF4u/BgpZWSk/7FFKuu854925GGNTeku8aorQvqJ4g
	ohxc22vKxXIyYiE1oi/CyUjiyTfOLEZICS3ITAJ3S5PMLuv5cKlNgUEfm9FXdoxodAfh
	ou/20O/hUZHiuwqJqmw18L5HQ6+z36gkUbhIzfXvm/B2WKcM2oYTNeito6YHWVd89iLy
	T2eg==
X-Gm-Message-State: AN3rC/4C2wYyQCvkjBXbKoKpwc/R3gxMOFuMvQEPJkM8V9tZqEY+1kGE
	iRE01nDH7fIcTVTsLrCPkNmYspJmZg==
X-Received: by 10.55.64.83 with SMTP id n80mr28350575qka.268.1494281788865;
	Mon, 08 May 2017 15:16:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.165.132 with HTTP; Mon, 8 May 2017 15:15:48 -0700 (PDT)
In-Reply-To: <CAAt2M1-JC1CAkoYnEttaK_tKgGPFvm8f3-gQVvVm6EK4mKUz5g@mail.gmail.com>
References: <CAJowKg+snAUjbCFkTybNqiJCy=d_M3s5k376y1B=rVqD8WCOXA@mail.gmail.com>
	<201705032321.14356.luke@dashjr.org>
	<9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com>
	<CAJowKgLzMZe1RcAW+FYsUZkvdZ5ZFf6cS5oJdZ=0apM0wMXc+g@mail.gmail.com>
	<CAKzdR-qbVAiXpuzAa+4VcBrq=h=65A-8ANTN3vOrVCV6fJ7yqQ@mail.gmail.com>
	<CAAt2M1-JC1CAkoYnEttaK_tKgGPFvm8f3-gQVvVm6EK4mKUz5g@mail.gmail.com>
From: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Date: Mon, 8 May 2017 19:15:48 -0300
Message-ID: <CAKzdR-qFXqPdRczxeQtmJVwBRx2QLNK1acAD1q1miLJthipsSA@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: multipart/alternative; boundary=001a1148b41e38556e054f0a97e4
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Eric Lombrozo <eric@ciphrex.com>
Subject: Re: [bitcoin-dev] Full node "tip" 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: Mon, 08 May 2017 22:16:31 -0000

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

Yes you practically can. No proxy can defeat the protocol investing less
money than buying storage space to store the blockchain.

Even with challenge-response delays of minutes.  That's why it will be
fully controlled by a RSK smart-contract, with no user intervention.
I'm will post about this soon.




On Mon, May 8, 2017 at 6:44 PM, Natanael <natanael.l@gmail.com> wrote:

>
> Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org>:
>
> I'll soon present a solution to encourage full nodes to store the
> blockchain based on Proof-of-Unique-Blockchain-Storage (PoUBS)
>
>
> Proving that you're holding your own copy of the blockchain, not shared
> with other nodes? I don't think that's possible to do securely. It falls on
> that the whole blockchain is both public and static, while any such proof
> of independence needs to rely on unique capabilities per node.
>
> All you can do with a challenge-response protocol is to prevent honest
> nodes from being unwitting backends to dishonest transparent proxy nodes
> (by binding the challenge to cryptographic node identities).
>
> Even latency bounding protocols can't stop you from putting multiple
> *seemingly independent* nodes in front of the same backend with one single
> copy of the blockchain.
>
> I believe best you can do is to force somebody to hold multiple copies
> locally on multiple hardware units to not run out of memory I/O when
> creating proofs for multiple remote nodes, through using memory heavy
> functions for the proof of storage, forcing quick random access. However
> somebody willing to put enough RAM in a server rack to hold the full
> blockchain could still easily pretend to be multiple regular nodes with
> independent copies.
>
> Any kind of attempt at forcing the full copy of the blockchain to be in
> memory close to the CPU will either rule out most nodes from passing or
> will be cheatable.
>

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

<div dir=3D"ltr">Yes you practically can. No proxy can defeat the protocol =
investing less money than buying storage space to store the blockchain.<div=
><br><div>Even with challenge-response delays of minutes.=C2=A0 That&#39;s =
why it will be fully controlled by a RSK smart-contract, with no user inter=
vention.</div><div>I&#39;m will post about this soon.<div><br></div><div><b=
r></div><div><br></div></div></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Mon, May 8, 2017 at 6:44 PM, Natanael <span dir=
=3D"ltr">&lt;<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank">nata=
nael.l@gmail.com</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"><d=
iv dir=3D"auto"><span class=3D""><div class=3D"gmail_extra" dir=3D"auto"><b=
r><div class=3D"gmail_quote">Den 8 maj 2017 23:01 skrev &quot;Sergio Demian=
 Lerner via bitcoin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.or=
g</a>&gt;:<br type=3D"attribution"><blockquote class=3D"m_67384626744989422=
30quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div><div>I&#39;ll soon present a solution to encour=
age full nodes to store the blockchain based on Proof-of-Unique-Blockchain-=
Sto<wbr>rage (PoUBS)</div></div></div></blockquote></div></div><div dir=3D"=
auto"><br></div></span><div dir=3D"auto">Proving that you&#39;re holding yo=
ur own copy of the blockchain, not shared with other nodes? I don&#39;t thi=
nk that&#39;s possible to do securely. It falls on that the whole blockchai=
n is both public and static, while any such proof of independence needs to =
rely on unique capabilities per node.=C2=A0</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">All you can do with a challenge-response protocol is to=
 prevent honest nodes from being unwitting backends to dishonest transparen=
t proxy nodes (by binding the challenge to cryptographic node identities).=
=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Even latency boun=
ding protocols can&#39;t stop you from putting multiple *seemingly independ=
ent* nodes in front of the same backend with one single copy of the blockch=
ain.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">I believe bes=
t you can do is to force somebody to hold multiple copies locally on multip=
le hardware units to not run out of memory I/O when creating proofs for mul=
tiple remote nodes, through using memory heavy functions for the proof of s=
torage, forcing quick random access. However somebody willing to put enough=
 RAM in a server rack to hold the full blockchain could still easily preten=
d to be multiple regular nodes with independent copies.=C2=A0</div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Any kind of attempt at forcing the fu=
ll copy of the blockchain to be in memory close to the CPU will either rule=
 out most nodes from passing or will be cheatable.=C2=A0</div><div class=3D=
"gmail_extra" dir=3D"auto"></div></div>
</blockquote></div><br></div>

--001a1148b41e38556e054f0a97e4--