good morning!!!!

Skip to content
Snippets Groups Projects
  1. Jan 09, 2015
    • Viktor Trón's avatar
      major blockpool change · 5a9952c7
      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
      5a9952c7
    • Viktor Trón's avatar
      add ErrInsufficientChainInfo error · 8ecc9509
      Viktor Trón authored
      8ecc9509
    • Viktor Trón's avatar
      adapt unit tests to spec · f72cb28b
      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
      f72cb28b
    • Viktor Trón's avatar
    • Viktor Trón's avatar
      minor changes in integration tests · 69dfca2f
      Viktor Trón authored
      69dfca2f
    • Viktor Trón's avatar
  2. Jan 08, 2015
  3. Jan 07, 2015
  4. Jan 06, 2015
  5. Jan 05, 2015
Loading