This needs to be supported because []someInterface does occur sometimes.
Funny enough, the fix involves changes to the decoder. makeDecoder
cannot return an error for non-empty interfaces anymore because the type
cache builds both decoder and writer. Do the check at 'runtime' instead.
* Remove flags field from key struct
* Change JSON struct fields from string to []byte
* Change GenerateNewKey API to take io.Reader for random source
* Remove mixing entropy source function
* Use testing Fatal in tests
* Simplify scrypt constants with const block
* Add key store constructors and make their types private
* Simplify key store and file namings to be less Java Enterprise™
* Change test error logging to use t.Error(err)
* Reduce number of naked returns (just like my ex-gf)
* Simplify file reading path code
* Add new generic key_store interface
* Add new plaintext key store storing unprotected keys on disk
* Add new encrypted key store storing encrypted keys on disk
* Add new entropy mixing function using OS and go runtime sources
I'm reasonably confident that the encoding matches the output of
ethutil.Encode for values that it supports. Some of the tests have been
adpated from the Ethereum testing repository.
There are still TODOs in the code.
- 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
- AddBlockHashes ignores the first hash (just used to match getBlockHashes query) sends the rest as blocksMsg
- new test TestPeerWithKnownParentBlock
- new test TestChainConnectingWithParentHash
- adapt all other tests to the new scheme
