From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id DDBEDB5E for ; 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 ; Mon, 8 May 2017 22:16:29 +0000 (UTC) Received: by mail-qk0-f180.google.com with SMTP id a72so48574193qkj.2 for ; 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: References: <201705032321.14356.luke@dashjr.org> <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com> From: Sergio Demian Lerner Date: Mon, 8 May 2017 19:15:48 -0300 Message-ID: To: Natanael 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 , Eric Lombrozo 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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.=C2=A0 That's = why it will be fully controlled by a RSK smart-contract, with no user inter= vention.
I'm will post about this soon.



On Mon, May 8, 2017 at 6:44 PM, Natanael <nata= nael.l@gmail.com> wrote:
Den 8 maj 2017 23:01 skrev "Sergio Demian= Lerner via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.or= g>:
I'll soon present a solution to encour= age full nodes to store the blockchain based on Proof-of-Unique-Blockchain-= Storage (PoUBS)

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

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

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

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

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

--001a1148b41e38556e054f0a97e4--