Proof of unique blockchain copy stored

[Sergio_Demian_Lerner]

In the thread https://bitcointalk.org/index.php?topic=310323.0 people are discussing how to prove to a peer that one has invested some expensive resource. I was researching on a topic that has some common applications that I think can be useful in cryptocurrencies.

How to prove that one have an unique copy of the blockchain?

This is important for several reasons:

1. It allows anyone to scan the network and check its health, measured by the number of distinct copies of the blockchain in existence.
2. It allows to give higher priority to peers which store the full blockchain (and penalize SPV).
3. It allows to establish a minimum resource consumption to prevent distributed DoS attacks.

The article is on my blog: http://bitslog.wordpress.com/2014/11/03/proof-of-local-blockchain-storage/

The core idea is to use asymmetric-time functions to store the blockchain in a transformed state (by applying f, which is slow), where the transformation depends on the peer IP address. The data is recovered by applying the inverse of f (which is fast).

[TierNolan]

2. It allows to give higher priority to peers which store the full blockchain (and penalize SPV).

SPV clients should not be considered leechers.  They add to the value of the currency.

Having said that it depends on what you mean by higher priority.  If they were forwarded (merkle)blocks after NETWORK_NODE connections, then it is not that big a deal.

[Skoupi]

2. It allows to give higher priority to peers which store the full blockchain (and penalize SPV).

SPV clients are not full nodes anyway. For all i know they don't relay any transactions... They only broadcast transactions initiated by the spv client.

[CIYAM]

Interesting - could not a simpler "hashcash" approach have been used (where x hashes are returned for x blocks each with a difficulty of y using the actual block hash and a nonce)?

[phink]

In the thread https://bitcointalk.org/index.php?topic=310323.0 people are discussing how to prove to a peer that one has invested some expensive resource. I was researching on a topic that has some common applications that I think can be useful in cryptocurrencies.

Proving to the network that you actually have a certain subset of blocks is an interesting problem, but I'm not sure that this scheme is that much of an improvement over being blind. If providing proofs for multiple IP addresses at once is seen as too taxing to be possible then it would make for a trivial denial of service vector, if it's not particularly difficult then it would be possible to expose a node with as many interfaces as you felt like same as before. To get anywhere near a decent picture of the network you're going to be asking a lot of peers for proofs at significant processing cost, and I'm not even sure if it's in their interests to supply them to you.

The non-listening portions of the network also make this a little unattractive. The bulk of all nodes don't expose listening ports at all, either by choice, lack of uPNP or by being behind a restrictive NAT. If you don't include them you lose a lot of the possible resources, if you do include them it's a mess of dynamic IP addresses and proofs that can only be obtained by the people they connect to.

I'm not convinced there is a solution to sybil nodes, isn't that what Bitcoin is an admission of in the first place?

[Sergio_Demian_Lerner]

To get anywhere near a decent picture of the network you're going to be asking a lot of peers for proofs at significant processing cost, and I'm not even sure if it's in their interests to supply them to you.

If you're honest and you're really storing the blockchain, it takes less resources (CPU/bandwidth) to compute a response to the proof-of-unique-copy challenge-response protocol than to send 10 random blocks asked via "getblocks". So providing this protocol does not increase the DoS risk.

Anyway, it's just an new idea. It's not something to rush to add to Bitcoin.

[TierNolan]

This would be a good system to have for archive nodes.  If there was a NODE_ARCHIVE bit, then it would be broadcast via the services bits in the addr message.

NETWORK_NODES are supposed to have all the blocks, but there was talk of having a bit to say you only have the last 2016 blocks.  Nodes that are less than 2 weeks behind could use those nodes for catchup, but they wouldn't keep the entire history. 

There is a graph somewhere which shows that almost all block requests are within the last 2016 blocks (except new nodes).