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
|
Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 302FC416
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2017 21:44:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f178.google.com (mail-yw0-f178.google.com
[209.85.161.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 989E5185
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 May 2017 21:44:43 +0000 (UTC)
Received: by mail-yw0-f178.google.com with SMTP id l14so14677909ywk.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 08 May 2017 14:44:43 -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=Q6ooQFHUq8yxSfdIMxOmmbFdgokmxKFDJRGW31AbQAI=;
b=u+olzEHasDhiMFMI1JBPyCMjK8slm+NGbe+l9ZUFJbWss3wVJPgGWdPM80t+6qpSGH
2Tkz6XpyLGiSyziVLl4MklvEyDesrjM4CxaudXXBW9j6RYWQXqMsLJYiKC5QiBC7otBz
KYSJrl0j1NMPgie5QSvNRvzsSuC9OnCp2O8MuLXj/G0GrV7Hr9Sgp55ArDlwiwxeDBc6
yOH1xv3+lYuh/aLdbvTkWYAsESXEI0ZZrh/a2C1aNZvbb3TMbwbMqafx//pajVWUP0W7
EAtSpM9IerHTFkNGFvsSckIcAzNcg8e5Mb1rnHIHYQeDDCt15oqwAzdATO6OzHSPNH4d
tK/g==
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=Q6ooQFHUq8yxSfdIMxOmmbFdgokmxKFDJRGW31AbQAI=;
b=nUIKE7pzR0dEkEg03pvqIqIRsx0bUCOK+cn0QJA/dIBlJsCszrgfsZddhhO88h2txm
1AFrbBYWG8EWj3ZATmbzcycE6yrrZBAqd0a7IsNTkgL5se/8M+1ZOBmPneqrrqiNS7Ae
LIfgYG0YY7Jk0uZ+QuXzeNmbFaOfNXDZynoE+v7q7+CsLpvaHpIgIKH7FY13zMdnoxwi
zkFLBqOh9Kmt1vk+Us02gZ8asazMQHshQbDXAB+QoiMT6DvjGzKDes9whkB8zp4tmGR0
KSJO3mMtogrZYS5Tw7ufXF3Zwq3k8JfDlVjGHyFnojYpg8qLaHwitZ+J0Uws1rAwjmoC
hC7Q==
X-Gm-Message-State: AODbwcDwTF3TDJomeGBwaSb82eNiJNHdrnQ2B/GGEOwjtc57Sv5U1vWv
d09x6Vi3wb6RuBaH7hWRCVPiRr0qLQ==
X-Received: by 10.129.116.85 with SMTP id p82mr3429359ywc.38.1494279882821;
Mon, 08 May 2017 14:44:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.35.88 with HTTP; Mon, 8 May 2017 14:44:41 -0700 (PDT)
Received: by 10.37.35.88 with HTTP; Mon, 8 May 2017 14:44:41 -0700 (PDT)
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
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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 21:44:44 -0000
--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 "Sergio Demian Lerner via bit=
coin-dev" <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>>:<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'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're h=
olding your own copy of the blockchain, not shared with other nodes? I don&=
#39;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.=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'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--
|
