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.
They can only execute a DAO operation from the address that currently holds their DAO tokens.
The whole reason the dao attacker can steal the funds, but not some random bystander, is because the Dao attacker has the privatekey to the wallet address controlling the dao tokens in the darkdao. If we make a softfork that temporarily ignores all transactions made by this wallet address it prevents them from doing the attack. And the whitehats can now use the same exploit against them to recover the funds (Because the whitehats also have dao tokens in those daos).
This will not introduce the same ddos attack vector because it does not require the validator to parse the code before rejecting the signature. It will have the same result as when a transaction with a genuinely invalid signature is broadcasted, such a transaction also removes no gas from any wallet.
so your basically saying that anyone can control the darkdao, no matter if they have access to his private key or not?
That does not sound right,
My proposal is to patch the code, so that the validly signed transaction is rejected IF is one of the known attacker wallets public-key hash