* oneshot channels instead of custom promises
* Future instead of handle_dispatch
* Even less copying
* Those explicit waits were a mistake, thanks, @tomusdrw
* No more unsafe polling
* Test for the new `is_done()` method
* Mark Futures as `#[must_use]`
* Solve most compilation warnings
* `try_ready!` is more ideomatic
* Turn spaces into tabs
* Documentation and visibility improvements
* Minor code style improvements
* Make Futures run on an explisit reactor
* Another round of code style issues
* Simplify ConfirmationReceiver type
* Flatten ConfirmationOutcome into a plain Result type
* Get rid of a separate `pending` set, it was a stupid idea
* Clarify `add_request` docs
* No need to reduce the scope of the mutex here
* rpc: transaction/receipt requests made async
* rpc: light client fetches transaction and uncle by hash/index
* on_demand: request type for transaction index
* serve transaction index requests in light protocol
* add a test for transaction index serving
* fetch transaction and receipts by hash on light client
* fix decoding tests
* light: more lenient cost table parsing (backwards compatible)
* fix tests and warnings
* LES -> PIP
* Update provider.rs
* proper doc comments for public functions
* Optional offset and count added on client level
* Rpc interface extended
* Tests corrected
* Filtering code refactored a little bit
* Offset type was changed to usize
* Handling of block hash in offset added
* Offset reworked to number
* Trailing comma removed
* Import for Quantity type added
* Offset and count moved into filter object
* Lost comma removed
* Return empty vec instead of None in case of incorrect range
* Add RPC eth_chainId for querying the current blockchain chain ID
Currently although we can use `net_version` RPC call to get the
current network ID, there's no RPC for querying the chain ID. This
makes it impossible to determine the current actual blockchain using
the RPC. An ETH/ETC client can accidentally connect to an ETC/ETH RPC
endpoint without knowing it unless it tries to sign a transaction or
it fetch a transaction that is known to have signed with a chain
ID. This has since caused trouble for application developers, such as
MetaMask, to add multi-chain support.
The same RPC endpoint is also about to be merged for ETC's
go-ethereum: https://github.com/ethereumproject/go-ethereum/pull/336
* Add eth_chainId to js's web3 interface
* Add a mocked test for eth_chainId
* Add chainId in js's jsonrpc interfaces
* Change return type for eth_chainId to `Option<u64>`
* Change name eth_chainId to parity_chainId
* Wrong test name and missed var for rpc_parity_chain_id test
* Use U256 to return chainId and fix for master
u64 returns decimal integer, and there seems to be no type called
U64. So here I use U256 to return the hex integer.
* Fix chainID test
Before EIP155 fork number, chainID should be null.
* Change both parity_chainId and transaction::chainId to use U64
This makes it consistent that all chain ids returned are hex string.
* Fix wrong U64 serialization
This is a huge change, which includes some changes to replace code that
originally cloned to reuse allocations instead. The updated
`elastic-array` crate renames its consuming `Vec`-conversion method to
`into_vec`, which means that I can do a simple
`sed -i 's/to_vec/into_vec/'` and then fix the compilation errors.
This commit is probably a minor performance win and definitely a
significant readability win.
Tomasz Drwięga
Svyatoslav Nikolsky
Jaco Greeff
Kirill Pimenov
debris
Robert Habermeier
Arkadiy Paronyan
Anton Gavrilov
Wei Tang
Hawstein
Fredrik
Gav Wood
Tomasz Drwięga
Nikolay Volf
Vurich
maciejhirsz
keorn