From: Natanael <natanael.l@gmail•com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>,
Eric Lombrozo <eric@ciphrex•com>
Subject: Re: [bitcoin-dev] Full node "tip" function
Date: Mon, 8 May 2017 23:44:41 +0200 [thread overview]
Message-ID: <CAAt2M1-JC1CAkoYnEttaK_tKgGPFvm8f3-gQVvVm6EK4mKUz5g@mail.gmail.com> (raw)
In-Reply-To: <CAKzdR-qbVAiXpuzAa+4VcBrq=h=65A-8ANTN3vOrVCV6fJ7yqQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2162 bytes --]
next prev parent reply other threads:[~2017-05-08 21:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-03 21:08 Erik Aronesty
2017-05-03 21:43 ` Ben Thompson
2017-05-04 10:38 ` Tomas
2017-05-04 13:37 ` Aymeric Vitte
2017-05-04 13:47 ` Erik Aronesty
2017-05-04 14:31 ` Aymeric Vitte
2017-05-03 21:53 ` Gregory Maxwell
2017-05-03 22:03 ` Matt Corallo
2017-05-04 13:15 ` Erik Aronesty
2017-05-04 14:57 ` Tom Zander
2017-05-03 23:21 ` Luke Dashjr
[not found] ` <9335E0E0-F9D6-41AD-9FF9-5CDF2B1AF1F7@gmail.com>
2017-05-04 19:28 ` Erik Aronesty
2017-05-08 21:00 ` Sergio Demian Lerner
2017-05-08 21:44 ` Natanael [this message]
2017-05-08 22:15 ` Sergio Demian Lerner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAt2M1-JC1CAkoYnEttaK_tKgGPFvm8f3-gQVvVm6EK4mKUz5g@mail.gmail.com \
--to=natanael.l@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@ciphrex$(echo .)com \
--cc=sergio.d.lerner@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox