But nothing formalised.
(Just concatenated together)
Since there is no standard, who would I contact about perhaps creating a standard (via an EIP)?
Bonus points if it uses some form of encoding instead of Bitcoin's ugly plain text header ;)
(RLP, I assume - as much as I dislike it, it's the lingua franca)
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.