From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: Natanael <natanael.l@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 19:15:48 -0300 [thread overview]
Message-ID: <CAKzdR-qFXqPdRczxeQtmJVwBRx2QLNK1acAD1q1miLJthipsSA@mail.gmail.com> (raw)
In-Reply-To: <CAAt2M1-JC1CAkoYnEttaK_tKgGPFvm8f3-gQVvVm6EK4mKUz5g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]
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.
>
[-- Attachment #2: Type: text/html, Size: 2984 bytes --]
prev parent reply other threads:[~2017-05-08 22:16 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
2017-05-08 22:15 ` Sergio Demian Lerner [this message]
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=CAKzdR-qFXqPdRczxeQtmJVwBRx2QLNK1acAD1q1miLJthipsSA@mail.gmail.com \
--to=sergio.d.lerner@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@ciphrex$(echo .)com \
--cc=natanael.l@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