yangzhe1990

From @ChenxingLi: log is user defined, so it's rational with or without log for balance withdrawal. I think for our defined behavior, such as contract destruction refund and in internal...

Let's say if confluxscan displays more information for a contract destruction, and so it need to make some queries, I think the blockreceipt/log is still the place for such information....

Here are some useful but missing rpc functions implemented in Parity https://wiki.parity.io/JSONRPC-parity-module#network-information We should consider add some of them.

We also need an rpc to let client know the rpc protocol version. I think the status() rpc call is a good place.

Actually can we use some tool to detect all potential arithmetic overflow?

The particular place has very low severity since It's not likely to happen outside testing environment, as nobody could spend extremely high gas fee. But how about other places?

BTW, "charge_all" actually means to charge_75_percent in the code.

> The gas used in a transaction can not exceed the maximum gas allowed in one block, which is must less than 2^256 3*gas_left may overflow in theory. But unlikely...

I have encountered this when running long-lasting ethereum replay tests. In some python tests there is an argument set to Conflux node to make the status wait to be extremely...

A clear formulation of 2) is, for each get_tx_receipt request, the request should mention the epoch hash range (root_now, epoch_range_back). We first check if root_now is on our pivot chain....