Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Nick Johnson
@Arachnid
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)
Richard Moore
@ricmoo
Bitcoins header isn't plain text though... It intentionally contains the non-printable character.
Nick Johnson
@Arachnid
Does it? What non-printable character?
Richard Moore
@ricmoo
\18
Nick Johnson
@Arachnid
I didn't realise that
It's still ugly :P
Richard Moore
@ricmoo
:)
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...
Nick Johnson
@Arachnid
I'm not sure a header with "Bitcoin signature" and one unprintable byte is quite a standard. :P
Yup, I agree
It would have debunked that pastebin a lot faster, for a start :)
Richard Moore
@ricmoo
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?
Nick Johnson
@Arachnid
Yes, the raw message is definitely problematic
Richard Moore
@ricmoo
I'll be sure to check over the HMAC wiki anyways to look for those sort of gotchas....
Nick Johnson
@Arachnid
Since it can cause users to be tricked into signing transactions and other things they don't intend.
Richard Moore
@ricmoo
Oh, interesting thing to think about... Right.
Paweł Bylica
@chfast

@karalabe You probably right it is about

Disable transaction processing during initial sync cycle #2574, #2649

How to end this initial sync cycle?

Nick Savers
@nicksavers
Regarding the Soft Fork: Why is the balance check + rejection done after the transaction and not just check if the trx to that codeHash does any CALL to a non-whitelisted address? That would take away the ability to DoS by using a malicous contract.
Paweł Bylica
@chfast
@nicksavers The call target may not be statically known.
Luca Zeug
@luclu
@nicksavers As Ethereum is turing complete you can easily hide it.
Nick Savers
@nicksavers
The CALL method in the EVM needs a TO address
Luca Zeug
@luclu
For example split the hash in several string and parse them in the contract.
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?