- Jan 15, 2015
-
-
Felix Lange authored
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.
-
- Jan 13, 2015
-
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
* Whisper protocol wasn't properly suppling envelope slices * Message history wasn't properly propagated * Added 'Messages' method, filtering any current envelope with the supplied filter.
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
- Jan 12, 2015
-
-
Jeffrey Wilcke authored
JitVm struct stub. Forwards calls to DebugVm.
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Paweł Bylica authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
- Jan 10, 2015
-
-
Jeffrey Wilcke authored
-
- Jan 09, 2015
-
-
Jeffrey Wilcke authored
* proper 0xhex * filters fixed * start of filter manager * accounts for ws. Closes #246
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Jeffrey Wilcke authored
-
Viktor Trón authored
-
Viktor Trón authored
- 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
-
Viktor Trón authored
-
Viktor Trón authored
- 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
-
Viktor Trón authored
-
Viktor Trón authored
-
Viktor Trón authored
-