the recent version of geth has depreciated the use of --genesis genesis.json.. And it is prompting me to use init path/file name.. In my genesis.json i have allocated money for my account.. It worked when i used --genesis.. using init my balance is not getting set to the balance specified in the genesis.json file..
Can anyone help me out with this?
E0629 11:55:46.617669 core/blockchain.go:1128] Bad block #1788997 (0x4b30a68d9fadc5e11cdb7ef38ab5871b211bce7ec66d81aa15b972955c78c0d4)
E0629 11:55:46.617689 core/blockchain.go:1129] invalid receipt root hash. received=8d02eb49065de266dec43a0c279c6902db8c13c896d8a12c05bd0128229e3adf calculated=d28d156461295ada771c34b7c651e0bf4cc124a8436bb0b8f4564f658b746927
E0629 11:55:46.617689 core/blockchain.go:1129] invalid receipt root hash. received=8d02eb49065de266dec43a0c279c6902db8c13c896d8a12c05bd0128229e3adf calculated=d28d156461295ada771c34b7c651e0bf4cc124a8436bb0b8f4564f658b746927
oO wtf?)))
If you check etherchain, that block number has a different hash
i restart node manually
please in a console do
debug.vmodule("downloader=6")
the downloader should drop malicious nodes who try to feed junk
curious why it didn't drop this peer in your case
geth 1.4.8 with softwork enabled.
Geth is usually designed to handle the Ethereum mainnet requirements. This sometimes can lead to some unfortunate breakages in scenarios we didn't consider (e.g. a blockchain with no blocks being mined, or @guillv 's reported issue with a single miner). People relying on non-canonical behavior report it and we fix it. Simple as that. No need to get angry because we broke an unusual corner case.
The requirements are either to complete a sync cycle with a remote node (i.e. the other node has to have a heavyer chain), or to receive a new block that's relatively close to the current chain head (e.g. -7 or perhaps -32 is the limit, not sure)
The scenario where a network is live but no blocks are being minted is a bit unorthodox
will need to think about that one
From what Ive understood the Dao attacker controls the dao-tokens using a proxy contract like pointed out to me earlier today, that sort of invalidates my earlier idea of censoring based on wallet address/private address, however I can still see the feasability if combined with my earlier idea. so basically blacklisting for 24-hours tx.origin JUST in case of a successful call to the DarkDao by the attacker wallet address. This will limit the attack surface of the ddos attack from every dao-holder to just the dao-attacker. It will also cause the attacker to have to spend about 200.000 gas to be able to burden the miner with GASLIMIT amount of gas of extra load, because he will have to whitelist an new address in his proxy contract (as to my understanding), and then try to ddos with this new address, and repeat this every time he wants to put ddos pressure on the network. This will allow the attacker to put CPU load on the network about 20x cheaper then normal, but not for free. If we were to lower the gas limit to 2.000.000 his multiplier would be reduced to only 10x. This will force the attacker to spend resources to be able to sustain the attack (which he might not have a lot of), and if the miners prioritize low gas transactions it might be possible for the network to operate normal even while under attack. We could also limit the duration of the censoring to just the time needed for the whitehats to use the same exploit to drain the darkdao without the attacker being able to join the split
so attackerwallet1.origin->proxycontract->dao if called blacklist/censor attackerwallet1.origin.
Attacker will have to add attackerwallet2 to the proxy contract and then try again.
and then attackerwallet2.origin->proxycontract->dao if called blacklist/censor attackerwallet2.origin.
if all else fails and a hardfork is necessary then I would suggest locking up the funds for a decent amount of time (a few months) in the refund contract. I am worried it might be much harder to get miners (and users) to agree to violating their principles about immutability and allowing a huge supply shock of 14M ETH added to the market instantly, endangering their investment, then it is to get them to agree to a softfork
maybe release the funds spaced out around the time of the run-up to the metropolis release
One more crazy idea that might work: If there is no softfork and no hardfork it will be sort of like a race between the attacker and the whitehats who will call split and splitdao+exploit first (if I understand it correctly). But could we not make sure we always win this race by preparing the transaction ahead of time, and coding the ethereum client of the miner to include the whitehat transaction in the first possible block, always before a possible blackhat one. That way the attackers funds are basically just as frozen as in the original softfork scenario right? We could even have miner reject blocks (in the unlikely event) that included the blackhat transaction before the whitehat transaction. Its like a stalker attack, and the attacker might give up, and it will give us a lot of time to have community discussion about the hardfork.
The issue mentioned in 1.4.9 release notes will occur even if --dao-soft-fork is not used
@tymat Please update, there's a data race in the soft fork detection code
puzzling