zelig 5a9952c7b4 major blockpool change ... - the spec says response to getBlockHashes(from, max) should return all hashes starting from PARENT of from. This required major changes and results in much hackier code. - Introduced a first round block request after peer introduces with current head, so that hashes can be linked to the head - peerInfo records currentBlockHash, currentBlock, parentHash and headSection - AddBlockHashes checks header section and creates the top node from the peerInfo of the best peer - AddBlock checks peerInfo and updates the block there rather than in a node - request further hashes once a section is created but then no more until the root block is found (so that we know when to stop asking) - in processSection, when root node is checked and receives a block, we need to check if the section has a parent known to blockchain or blockPool - when peers are switched, new peer launches a new requestHeadSection loop or activates its actual head section, i.e., the section for it currentBlockHash - all tests pass		2015-01-09 06:03:45 +00:00
..
test	minor changes in integration tests	2015-01-09 05:04:32 +00:00
backend.go	Refactored ethutil.Config.Db out	2015-01-07 13:17:48 +01:00
block_pool_test.go	adapt unit tests to spec	2015-01-09 05:57:09 +00:00
block_pool.go	major blockpool change	2015-01-09 06:03:45 +00:00
error.go	add ErrInsufficientChainInfo error	2015-01-09 06:03:32 +00:00
peer_util.go	made mist in a compilable, workable state using the new refactored packages	2014-12-15 13:00:29 +01:00
protocol_test.go	eth, p2p: remove EncodeMsg from p2p.MsgWriter	2015-01-06 12:23:38 +01:00
protocol.go	no need to call AddBlockHashes when receiving new block	2015-01-09 05:06:04 +00:00
wallet.go	BlockManager => BlockProcessor	2015-01-05 00:18:44 +01:00