It's still ugly :P
Not as elegant as the PNG magic header, but something.
I do like sticking with existing standards. But will mull it over and get some feedback from others, and put something together for next week probably.
I'm getting ready to launch my Ethereum development environment, and think that a sign/verify option in the wallet portion is super useful...
Yup, I agree
It would have debunked that pastebin a lot faster, for a start :)
I think it's some random thing electrum did. The raw message isn't necessarily a good idea either though. I think they were modelling it after how GIT creates signatures, however, a part of that method (I think) has to do with preventing hash-extension, which isn't a problem with signed messages, maybe?
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.
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.
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.
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.
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
Right now I'm piping out to bash, but there has to be a simple flag to log to file?
Geographically and vendor disparate systems seeing the same fatal error: concurrent map read and map write error.
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.
But this is getting bad.
@JokerMashine_twitter There isn't a Gitter channel for trading, but there is this sub-Reddit: https://reddit.com/r/ethtrader. Best wishes!
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)