MIME-Version: 1.0
In-Reply-To: <CAKzdR-qbVAiXpuzAa+4VcBrq=h=65A-8ANTN3vOrVCV6fJ7yqQ@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>
From: Natanael <natanael.l@gmail.com>
Date: Mon, 8 May 2017 23:44:41 +0200
Message-ID: <CAAt2M1-JC1CAkoYnEttaK_tKgGPFvm8f3-gQVvVm6EK4mKUz5g@mail.gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>
Content-Type: multipart/alternative; boundary=001a11473d2c9c55b3054f0a2524
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Eric Lombrozo <eric@ciphrex.com>
Subject: Re: [bitcoin-dev] Full node "tip" function
Precedence: list

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

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.

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

<div dir=3D"auto"><div class=3D"gmail_extra" dir=3D"auto"><br><div class=3D=
"gmail_quote">Den 8 maj 2017 23:01 skrev &quot;Sergio Demian Lerner via bit=
coin-dev&quot; &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>&gt;:<br type=3D"attribution"><bl=
ockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><div>I&#39;ll soon present a so=
lution to encourage full nodes to store the blockchain based on Proof-of-Un=
ique-Blockchain-<wbr>Storage (PoUBS)</div></div></div></blockquote></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">Proving that you&#39;re h=
olding your own copy of the blockchain, not shared with other nodes? I don&=
#39;t think that&#39;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.=C2=A0</div><div dir=3D"auto"=
><br></div><div dir=3D"auto">All you can do with a challenge-response proto=
col is to prevent honest nodes from being unwitting backends to dishonest t=
ransparent proxy nodes (by binding the challenge to cryptographic node iden=
tities).=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">Even late=
ncy bounding protocols can&#39;t stop you from putting multiple *seemingly =
independent* nodes in front of the same backend with one single copy of the=
 blockchain.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">I bel=
ieve best you can do is to force somebody to hold multiple copies locally o=
n 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 pr=
oof of storage, forcing quick random access. However somebody willing to pu=
t enough RAM in a server rack to hold the full blockchain could still easil=
y pretend 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 forcin=
g the full copy of the blockchain to be in memory close to the CPU will eit=
her rule out most nodes from passing or will be cheatable.=C2=A0</div><div =
class=3D"gmail_extra" dir=3D"auto"></div></div>

--001a11473d2c9c55b3054f0a2524--