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 302FC416 for ; 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 ; Mon, 8 May 2017 21:44:43 +0000 (UTC) Received: by mail-yw0-f178.google.com with SMTP id l14so14677909ywk.1 for ; 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: References: <201705032321.14356.luke@dashjr.org> <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com> From: Natanael Date: Mon, 8 May 2017 23:44:41 +0200 Message-ID: To: Sergio Demian Lerner 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 , 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 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

Den 8 maj 2017 23:01 skrev "Sergio Demian Lerner via bit= coin-dev" <bitcoin-dev@lists.linuxfoundation.org>:
I'll soon present a so= lution to encourage full nodes to store the blockchain based on Proof-of-Un= ique-Blockchain-Storage (PoUBS)

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

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

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

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
=

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
--001a11473d2c9c55b3054f0a2524--