danoctavian
commented
9 years ago @jbenet remembering some points that Alexis made when he was proposing changes that would benefit ethereum and weren't super clear at that point, but that i understood post-meeting as i was pondering over my work.
He was making a request for some of way representing the merkle tree of the transactions (the merkle root of the bitcoin header is the root of this tree). the leaves of it are the actual transactions and the other nodes are hashes concatenated together (so it's the classical merkle tree as we know it).
This is how the transactions are hashed as descrbied in the bitcoin paper and i'm guessing this is what he wants for ethereum as well.
Summary for the work I did with bitcoin on IPFS. @jbenet @whyrusleeping @krl @diasdavid @lgierth
the btcd fork is here:
https://github.com/danoctavian/btcd
Most relevant file is
https://github.com/danoctavian/btcd/blob/ipfs/database/ipfs/ipfschain.go
It passes all btcd unit tests with current implementation. I haven't hacked the network protocol yet, only the storage, because see "shortest path to The Dream" below.
Current state
I basically wrapped bitcoin data in the DAG nodes, adding an IPFS link for every bitcoin link. this preserves the data as is, but the links are deduplicated and the hashes of the IPFS nodes containing the bitcoin nodes don't match the bitcoin ones.
Each bitcoin header is contained in a DAG node and all transactions belonging to that header are concatenated together and stored in the data section of a single DAG node linked to by the header DAG node.
The Dream
Ideally, we would want to be able represent the bitcoin blocks as they are described by the Bitcoin protocol in IPFS.
The dream is to reduce the blockchain sync operation to fetching a pointer to the head of the blockchain (from multiple random peers potentially to gain confidence in its authenticity) and the perform a "pin recursively" IPFS operation which will seamlessly fetch the entire chain, in a p2p fashion while validating it implicitly (given content addressing). This GREATLY simplifies the protocol (which took up until 2015 to get proper p2p download in bitcoin 0.10)
shortest path to The Dream
Hack IPFS to have a special case for custom blocks (serialization and hashing of content) and an implementation for bitcoin headers, transactions and maybe merkle nodes (the ones that lead down to the transaction leaves).
Having browsed through the codebase i think the previous is actually pretty easily doable (given abstractions don't leak anywhere like for eg. no other upper layer assumes protobuf). One thing we might actually want to work towards is to make it really easily doable to cater for this usecase (handling bitcoin, git etc.) through how we structure our code.