IPFS as blockchain storage.

[Vitalik Kuliev]

Bitcoin and other blockchain projects has its own data transmission protocols. Block completely downloaded with a single node. Block downloading can be accelerated through p2p protocols.

Are there any problems with using IPFS as block data storage?

[Vitalik Kuliev]

Any solution?

Yes. I propose to use IPFS.
https://ipfs.io/

[TransaDox]

Problem.......Who has write permissions on the blocks?

A modified S/Kademlia solution is viable though.

[Vitalik Kuliev]

Problem.......Who has write permissions on the blocks?

Block header should be transmitted by http protocol. Block data can be transmitted with IPFS.
Only miner can create valid block header and write valid block data.

[TransaDox]

Block header should be transmitted by http protocol. Block data can be transmitted with IPFS.
Only miner can create valid block header and write valid block data.

If you are using IPFS why do you need HTTP at all? What failing of IPFS is HTTP addressing in this use case?
How do you enforce that only a Miner can create (and delete/modify) a block. There is no mechanism in IPFS to ascertain who is and isn't a Miner. It's a file system with permissions just like a network share except the data is distributed.

[Vitalik Kuliev]

If you are using IPFS why do you need HTTP at all? What failing of IPFS is HTTP addressing in this use case?

IPFS is good for static content. HTTP required for transmission of dynamic content between nodes. Is it possible with IPFS get dynamic data from specific node (analogue http request)?

How do you enforce that only a Miner can create (and delete/modify) a block. There is no mechanism in IPFS to ascertain who is and isn't a Miner.

This mechanism is not needed. Everyone can create a block and write it in the IPFS. IPFS is used only for data storage. Each node selects a particular block because of its hash, complexity, etc.

[buhrmi]

I've actually started to work on this. Code here: http://github.com/buhrmi/hashgraph ... Blog post here: http://buhrmi.de/post/150898157364/quest-for-consensus-part-2-virtual-consensus

[Vitalik Kuliev]

I've actually started to work on this. Code here: http://github.com/buhrmi/hashgraph ... Blog post here: http://buhrmi.de/post/150898157364/quest-for-consensus-part-2-virtual-consensus

Sadly, the library is still in development.

That is another ipfs p2p library:
https://github.com/libp2p/libp2p

[TransaDox]

I've actually started to work on this. Code here: http://github.com/buhrmi/hashgraph ... Blog post here: http://buhrmi.de/post/150898157364/quest-for-consensus-part-2-virtual-consensus

• Publicly accessible
• Impossible to tamper with.
• Replicated among several nodes with the ability for external nodes to join without manually reconfiguring the system
• No central authority (no “main” node, or authorization server)
• Free and efficient (no mining, no native currency)

S/Kademlia.

If one uses a quad instead of a triple then the block can be stored in the routing table.
The sorting algorithm needs slight tweaking since it favours persistent nodes rather than persistent data.
There is also the possibility of bootstrapping and transacting before the full chain has been downloaded and verified (with high a very confidence) and if one uses the distance function to link the merkle hashes to the node ID then the cached blocks act as pre-verified checkpoints.
Each node would probably only need about 1G of persistent data (size is dependent on hash and K bins).