1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
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's =
why it will be fully controlled by a RSK smart-contract, with no user inter=
vention.</div><div>I'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"><<a href=3D"mailto:natanael.l@gmail.com" target=3D"_blank">nata=
nael.l@gmail.com</a>></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 "Sergio Demian=
Lerner via bitcoin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.or=
g</a>>:<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'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're holding yo=
ur own copy of the blockchain, not shared with other nodes? I don't thi=
nk that'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'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--
|
