This implements a generic approach to enabling soft forks by allowing
anyone to put in hashes of contracts that should not be interacted from.
This will help "The DAO" in their endevour to stop any whithdrawals from
any DAO contract by convincing the mining community to accept their code
hash.
(cherry picked from commit 7a5b571c671e70e0e4807cf971c15e2d1e09d33d)
This fixes an issue if you wanted to test out code deployment rather
than running a piece of code with an argument. This solves it by adding
a --create flag that indicates the Create function should be used rather
than the Call function.
This also adds a statedb.commit call so that the proper state can be
dumped when requested using the --dump flag.
(cherry picked from commit e5165aeb277b1f1ae8d5bf60c22716ccd874a8e6)
Consensus rules dictate that objects can only be removed during the
finalisation of the transaction (i.e. after all calls have finished).
Thus calling a suicided contract twice from the same transaction:
A->B(S)->ret(A)->B(S) results in 2 suicides. Calling the suicided
object twice from two transactions: A->B(S), A->B, results in only one
suicide and a call to an empty object.
Our current debug tracing functionality replays all transaction that
were executed prior to the targetted transaction in order to provide
the user with an accurate trace.
As a side effect to calling StateDB.IntermediateRoot it also deletes any
suicides objects. Our tracing code never calls this function because it
isn't interested in the intermediate root. Becasue of this it caused a
bug in the tracing code where transactions that were send to priviously
deleted objects resulted in two suicides rather than one suicide and a
call to an empty object.
Fixes#2542
(cherry picked from commit bb3651abc865c6f6babec0d357afa85f5a539d83)
When converting a negative number e.g., -2, the resulting ABI encoding
should look as follows:
fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe.
However, since the check of the type is for an uint instead of an
int, it results in the following ABI encoding:
0101010101010101010101010101010101010101010101010101010101010102. The
Ethereum ABI
(https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI) says,
that signed integers are stored in two's complement which should be
of the form ffffff.... and not 01010101..... for e.g. -1. Thus, I
removed the type check in numbers.go as well as the function S256
as I don't think they are correct. Or maybe I'm missing something?
(cherry picked from commit 89c6c5bb85ff24c152218f245fa366e733c951a7)
* use --port 0 to avoid p2p port conflicts
* use --maxpeers 0 so it doesn't connect to bootstrap nodes
* use geth.expectExit() to wait for termination
(cherry picked from commit b57b6e341e3865de3b3a5aa108e642d1a6a5b590)
We used to have reporting of bad blocks, but it was disabled
before the Frontier release. We need it back because users
are usually unable to provide the full RLP data of a bad
block when it occurs.
A shortcoming of this particular implementation is that the
origin peer is not tracked for blocks received during eth/63
sync. No origin peer info is still better than no report at
all though.
(cherry picked from commit ca18202eb9a94de1d4b51c1572fa74edfa2773bf)
