There were multiple synchronization issues in the disconnect handling,
all caused by the odd special-casing of Peer.readLoop errors. Remove the
special handling of read errors and make readLoop part of the Peer
WaitGroup.
Thanks to @Gustav-Simonsson for pointing at arrows in a diagram
and playing rubber-duck.
* Add initial go wrapping for TransactionTests with some tests
disabled in lieu of consistent HEX encodings and a few other
pending bugfixes
* TODO: Consider better way of perhaps modelling each test in
the JSON files as a single Go test, instead of one Go test per
JSON file
Fetching the recipient address from a transaction was changed to return nil
instead of a zero-address, but this code path was not updated, so whenever
a contract was created, a nil panic occured.
- add peer switch channel arg to activateChain - no peer locking within
- proper locking in AddBlock - fixes deadlock issue
- comment out TD check and skip incorrect TD test again for hotfix
- queued bool // flag for blockpool to skip TD check
- set to true when future block queued
- in checkTD: skip check if queued
- TODO: add test (insertchain sets future block)
- TestPeerPromotionByTdOnBlock renamed and skipped for now test should pass iff
if TD is updated based on an agreement
- senders register in AddBlock, flag records if they are coming from newblock
message (and therefore advertise their TD with the block) or block message
(TODO: latter are stored on the cache and updated by checkTD call;
protocol should also call AddBlock on newblock messages by non-best peers)
- remove TD update from optional TD field in addBlock: this is no longer part of
the eth protocol spec -> TODO: reflect in wiki
- only initialise peer map if at least two
- do not break from headsection on error
[remove peer after protocol quit will close switchC, until then head block can arrive and block on channel while keeping peers lock causing a deadlock.]
- more careful locking in AddBlock
Removed the from as a requiremet from the RPC eth_call. Xeth#Call now
also default values to:
1. Supplied account
2. First account if any
3. No managed account => 000000..00
The transaction pool will now some easily be able to pre determine the
validity of a transaction by checking the following:
* Account existst
* gas limit higher than the instrinsic gas
* enough funds to pay upfront costs
* nonce check