So they have to compute the complex spam code up to the point where the bad hashes are revealed.
That's because the malicous code can be executed before reaching the DAO codeHash, where I assumed the malicious code would be executed after calling to a malicious contract from within the DAO.
Hey guys, you mind if I ask for a little bit of help here? I'm trying to log the output from a non-interactive geth session, and can't seem to find a simple way to log.
I need a full trace to fully diagnose the constant geth daemon crashes im experiencing in 1.4.8 across my pools. Issue #2747
E0628 23:59:49.976830 core/blockchain.go:1128] Bad block #1789821 (0x32f861ad6119f74212ea75b9f3979d306792195d114c02a1857beb257c51a03d) E0628 23:59:49.976864 core/blockchain.go:1129] Transaction w/ invalid nonce. tx=357 state=358)
E0628 23:49:42.059413 core/blockchain.go:1128] Bad block #1788997 (0x4b30a68d9fadc5e11cdb7ef38ab5871b211bce7ec66d81aa15b972955c78c0d4) E0628 23:49:42.059439 core/blockchain.go:1129] invalid receipt root hash. received=8d02eb49065de266dec43a0c279c6902db8c13c896d8a12c05bd0128229e3adf calculated=d28d156461295ada771c34b7c651e0bf4cc124a8436bb0b8f4564f658b746927
Hello, thinking about it I think the best fix for the soft-fork ddos problem is: instead of filtering based on code analysis we should simply blacklist/censor the wallet addresses of the known malicious actors in the darkdao's and whitehatDao, this will allow the whitehats to do a exploit-drain-split without the attackers being able to join the split
This method will not create the ddos problem, is still a softfork and still allow us to secure the dao funds.