ethereum/go-ethereum

Please use https://discord.gg/nthXNEv instead

Luca Zeug

@luclu

Or even use some simple crypto scheme..

So basically it is not possible to determine if the address is used until the codes get executed up to the point that reveals the address/hash.

Nick Savers

@nicksavers

Oh right, you could waste all the gas before you reach the contract with that hash

Luca Zeug

@luclu

Yes, this is called the https://en.wikipedia.org/wiki/Halting_problem

So one way around this would be to only allow transactions where the receipients are „whitelisted“ in some extra field next to the byte code, but that would completelly undermine the current design and introduce undesired side effects.

Nick Savers

@nicksavers

No I mean that I assumed that the attack would happen in a contract after calling a DAO contract... but you can also do it before it reaches that contract

Luca Zeug

@luclu

No I mean that I assumed that the attack would happen in a contract after calling a DAO contract... but you can also do it before it reaches that contract

Yes, but there is another problem with that..

1 . Miners can’t know if the transaction is „invalid“ respective to the SF rules - which are not allowing those specific recipients, etc. So they have to compute the complex spam code up to the point where the bad hashes are revealed.

2 . According to the SF rules they can’t collect the gas for that, because stoping this transaction and just collecting the gas violates the EVM protocol and thus isn’t accepted by any other nodes.

Luca Zeug

@luclu

So in the case of this attack vector being used. The attacker can easily create limes->infinity transactions as he doesn’t have to pay for anything. And miners can’t differentiate between those and valid ones . This means most blocks will be mostly empty. Only giving the basic reward to the miner.

And the network is in DoS.

Nick Savers

@nicksavers

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.

9600-

@9600-

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

Right now I'm piping out to bash, but there has to be a simple flag to log to file?

9600-

@9600-

Will just use bash and screenlog for the time being.

Maschine

@JokerMashine_twitter

i guess somewhere exist the trading channel

9600-

@9600-

#2747 has been updated with full stack trace failures from multiple pool nodes.

Geographically and vendor disparate systems seeing the same fatal error: concurrent map read and map write error.

clintar

@clintar

ew, that sounds bad. don't want to run that on my pool

9600-

@9600-

I thought it was related to soft fork voting, is not.

Same failure on about 5 nodes.

Geographically disparate systems, different hardware.

Same host OS and deployment template.

Seeing crashes as frequent as every hour. Thinking about shutting down for a few days, but that'll kill me.

clintar

@clintar

why not go back to old ver?

9600-

@9600-

I will. It wasnt crashing as frequently, and i've got a process watcher thats restarting the daemon.

But this is getting bad.

Bob Summerwill

@bobsummerwill

@JokerMashine_twitter There isn't a Gitter channel for trading, but there is this sub-Reddit: https://reddit.com/r/ethtrader. Best wishes!

Tim Coulter

@tcoulter

Does this error message represent an issue with my version of go-ethereum or simply bad data sent from a peer:

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)

Another similar one:

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

infamousrev

@infamousrev

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 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

infamousrev

@infamousrev

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.

This a about it: miners already have to verify if a transaction is made by the real owner of the private key,

And only the people with the attackers private key can execute the blackhat attack

Why dont we interfere in that stage of the process, and say, attacker private key != valid, from the softforked miner point of view, it should not introduce additional ddos problems

infamousrev

@infamousrev

Sorry for double posting, my browser did not show the first post

infamousrev

@infamousrev

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.

infamousrev

@infamousrev

This solution assumes we can implement the softfork while the darkdao and whitehatdao is still in the creationfase, meaning they cannot move the tokens to a different address just before the softfork activates because they are frozen (that is my understanding)

infamousrev

@infamousrev

@/all Any idea when most ethereum devs wake up? It would be nice to receive a reply if this solution would be viable or if I should try and think of something else

Nick Johnson

@Arachnid

@infamousrev Please don't try and ping all in this channel.

We looked into that, but unfortunately the attacker's tokens are controlled by a contract, and the contract is configured such that it can be called from more than just a short whitelist of addresses.

infamousrev

@infamousrev

yes, but the attacker will need to send a call-transaction to the contract signed by the wallet owning the tokens to be able to use them right? So if that fails, then the attacker has just as much control over the darkdao as a random individual, which is none

Nick Johnson

@Arachnid

No, because it's not just a wallet. He can potentially send it instructions from any address.

infamousrev

@infamousrev

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

Nick Johnson

@Arachnid

No, only the attacker can control the dark DAO

But he can do it from any source address he likes.

I haven't examined the attacker's code myself, but I imagine it verifies signed instructions against an embedded public key. Which means that the origin address does not have to be the attacker's known wallet address.

(There are other schemes that would provide similar functionality to the attacker, allowing him to send instructions but nobody else, without forcing him to use a particular account)

infamousrev

@infamousrev

but the darkdao will only accept the split instructions from an address that contains darkdao-tokens right?

Nick Johnson

@Arachnid

Yes, but the address that contains the tokens is a contract, not an external account.

Where communities thrive

People

Repo info

Activity