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.
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
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.
This fixes an issue where it's theoretical possible to cause a consensus
failure when hitting the lower end of the difficulty, though pratically
impossible it's worth a fix.
Shutting down geth prints hundreds of annoying error messages in some
cases. The errors appear because the Stop method of eth.ProtocolManager,
miner.Miner and core.TxPool is asynchronous. Left over peer sessions
generate events which are processed after Stop even though the database
has already been closed.
The fix is to make Stop synchronous using sync.WaitGroup.
For eth.ProtocolManager, in order to make use of WaitGroup safe, we need
a way to stop new peer sessions from being added while waiting on the
WaitGroup. The eth protocol Run function now selects on a signaling
channel and adds to the WaitGroup only if ProtocolManager is not
shutting down.
For miner.worker and core.TxPool the number of goroutines is static,
WaitGroup can be used in the usual way without additional
synchronisation.
This is necessary for external users of the go-ethereum code who want to, for instance, build a custom node that plays back transactions, as core.ApplyTransaction requires a ChainConfig as a parameter.
According to our own instructions the genesis config attribute should be
"config". The genesis definition in the go code, however, has a field
called `ChainConfig`. This field now has a `json:"config"` struct tag so
that the json is properly unmarshalled.
This fixes#2482
Exposes some core methods to transition and compute new state
information and adds an additional return value to the transition db
method to fetch required gas for that particular message (excluding gas
refunds from any SSTORE[X] = 0 and SUICIDE.
Fixes#2395
The chain maker and the simulated backend now run with a homestead phase
beginning at block 0 (i.e. there's no frontier).
This commit also fixes up #2388
Added chain configuration options and write out during genesis database
insertion. If no "config" was found, nothing is written to the database.
Configurations are written on a per genesis base. This means
that any chain (which is identified by it's genesis hash) can have their
own chain settings.
The EVM was previously initialised and created for every CALL, CALLCODE,
DELEGATECALL and CREATE. This PR changes this behaviour so that the same
EVM can be used through the session and beyond as long as the
Environment sticks around.
Added a future lock which prevents the anything being added or removed
from or to the set when looping over the set of blocks. This fixes a nil
pointer in the range loop when trying to retrieve a block from the set
which was previously available but removed due to regular chain
processing.
Fixes#2305
Previously all blocks that were already in our chain were never re
announced as potential uncle block (e.g. ChainSideEvent). This is
problematic during mining where you want to gather as much possible
uncles as possible increasing the profit. This is now addressed in this
PR where during reorganisations of chains the old chain is regarded as
uncles.
Fixed#2298
