public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

      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 [bitcoin-dev] Full node "tip" function 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.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@ciphrex.com \
    --cc=natanael.l@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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