Bitcoin Forum

Bitcoin => Development & Technical Discussion => Topic started by: Vitalik Kuliev on October 17, 2016, 03:59:45 PM



Title: IPFS as blockchain storage.
Post by: Vitalik Kuliev on October 17, 2016, 03:59:45 PM
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?


Title: Re: IPFS as blockchain storage.
Post by: Vitalik Kuliev on October 17, 2016, 04:13:13 PM
Any solution?
Yes. I propose to use IPFS.
https://ipfs.io/


Title: Re: IPFS as blockchain storage.
Post by: TransaDox on October 18, 2016, 12:18:48 AM
Problem.......Who has write permissions on the blocks?

A modified S/Kademlia solution is viable though.


Title: Re: IPFS as blockchain storage.
Post by: Vitalik Kuliev on October 18, 2016, 05:16:16 AM
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.


Title: Re: IPFS as blockchain storage.
Post by: TransaDox on October 18, 2016, 09:02:20 AM
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.


Title: Re: IPFS as blockchain storage.
Post by: Vitalik Kuliev on October 18, 2016, 09:31:15 AM
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)?

Quote
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.


Title: Re: IPFS as blockchain storage.
Post by: buhrmi on October 18, 2016, 05:56:47 PM
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


Title: Re: IPFS as blockchain storage.
Post by: Vitalik Kuliev on October 19, 2016, 02:38:31 PM
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


Title: Re: IPFS as blockchain storage.
Post by: TransaDox on October 19, 2016, 10:10:12 PM
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

Quote
  • 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 (http://www.tm.uka.de/doc/SKademlia_2007.pdf).

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).