Re: [bitcoin-dev] Full node "tip" function

[Sergio Demian Lerner <sergio.d.lerner@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 --]