Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Ricardo Guilherme Schmidt
@3esmit
Regarding the potential DoS vector in soft fork tx block. Could we, instead of blocking, make the tx need a huge amount of gas, so it will always fail due out of gas? Or if is a blocked tx, just throw out of gas? (or this would'nt be possible in soft fork?)
Péter Szilágyi
@karalabe
though tbh I'd rather run 1.4.7 to avoid all the crap this soft fork put it
@3esmit that's already a hard fork
as everyone would need to agree that those txs should be penalized monetarily
the current protocol doesn't allow that
if not everyone agrees, then those not agreeing would consider such blocks invalid as they violate the protocol
Ricardo Guilherme Schmidt
@3esmit
Understood
clintar
@clintar
i don't even understand how, as a miner, one would even set these rules
Paweł Bylica
@chfast
@karalabe I've installed version 1.4.5 and it started working as before. It looks like a regression in 1.4.6. I can't see anything in the logs (verbosity 6) that indicates the transaction has been received and why it was dropped.
Richard Moore
@ricmoo
I couldn't find a general Ethereum room, but figured someone here would know... Is there a standard format and method for signing/verifying arbitrary messages in Ethereum?
Nick Johnson
@Arachnid
There's a defacto one, of just hashing the raw text and signing it with your key, then encoding the sig as a recoverable ECDSA sig
But nothing formalised.
Richard Moore
@ricmoo
@Arachnid But what is the encoding of the (r, s)? And so no prefix in the message payload? For example, bitcoin prefixes '\x18Bitcoin Signed Message:\n', I also believe they encode the v with the output format.
Nick Johnson
@Arachnid
There's no standard prefix (again, this is ad-hoc, nobody's formalized it yet). Signatures are encoded as r, s, v as 256 bit, 256 bit, and 1 byte, respectively.
(Just concatenated together)
Richard Moore
@ricmoo
Awesome thanks. Also, do you add 27 to the v?
Since there is no standard, who would I contact about perhaps creating a standard (via an EIP)?
Nick Johnson
@Arachnid
27 isn't added to the V in the encoded signature
Richard Moore
@ricmoo
Coolio. Thanks again. :)
Nick Johnson
@Arachnid
For an EIP, just write an informational one and submit it per the process defined in EIP 1. :)
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
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.