Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Nick Johnson
@Arachnid
That'll have lots of false positives, but it's a start.
Matthias Egli
@MatthiasEgli_twitter
This is finding tons of contracts
Nick Johnson
@Arachnid
@MicahZoltu Fair enough.
Taylor Monahan
@tayvano
@hayesgm which compound address(es) did you check? I'll add them to the working list
Geoff Hayes
@hayesgm
@tayvano 0x3fda67f7583380e67ef93072294a7fac882fd7e7 is our core Money Market contract. I can list out the rest, though not a single contract of ours uses send() or transfer()
Taylor Monahan
@tayvano
Thanks
Jochem Brouwer
@jochem-brouwer
What about an auction contract where the price of an auction is updated /after/ the transfer? This would be attackable
Geoff Hayes
@hayesgm
This would be a great use for Certora (http://www.certora.com/). The team hooked up an SMT-solver which can easily run a test over EVM byte-code and verify a property (such as a check for these unsafe transfers under Constantinople). Given a few days, we could automatically verify a mass of contracts and authoritatively decide if each is vulnerable or not.
Jochem Brouwer
@jochem-brouwer
https://etherscan.io/address/0xf4a3679eb0a3d9e8af9824a29bd32dd98d1e7127#code this looks attackable too (but might use too much storage slots)
The sell price is updated after transfering. So you can sell it twice for the same price
And might even have unintended side effects
Nick Johnson
@Arachnid
@jochem-brouwer Got a line number?
Jochem Brouwer
@jochem-brouwer
917
Look I'm not really checking this but I'm mainly pointing out that there are many OTHER effects which are also possible here
Contracts might not be drainable but there suddenly might be problems updating prices or things, or hence small errors in prices
Main point is, what if due to general consensus like "transfer/send is ok against re-entrancy" you have a non-drainable contract. Now with the fork it suddenly is drainable. This makes Ethereum much less decentralized because you now have to trust that changes in those semantics are not going to hurt contracts which you deployed.
Main point is, what if due to general consensus like "transfer/send is ok against re-entrancy" you have a non-drainable contract. Now with the fork it suddenly is drainable. This makes Ethereum much less decentralized because you now have to trust that changes in those semantics are not going to hurt contracts which you deployed.
Nick Johnson
@Arachnid
I'm reluctantly forced to agree that the odds of that being the case here just seem far too high. I'm in favor of postponing the HF.
Corey Petty
@corpetty
it seems as though looking at potential risk of both decisions, postponement seems like the right choice.
Nick Johnson
@Arachnid
I agree that not introducing new bugs into previously secure contracts - even if they arguably used bad practice - should be at the absolute top of our priority list.
Jochem Brouwer
@jochem-brouwer
It is just time before a vulnerable contract is found, and my gut says there are many which have unintended side effects with the HF
I would love to quickly find one on etherscan but no luck so far
Danny Ryan
@djrtwo
@Arachnid join call https://zoom.us/j/924091368 if you can
Jochem Brouwer
@jochem-brouwer
It is just time before a vulnerable contract is found, and my gut says there are many which have unintended side effects with the HF
Martin Holst Swende
@holiman

This makes Ethereum much less decentralized because you now have to trust that changes in those semantics are not going to hurt contracts which you deployed.

That's always been the case, nothing new. But let's not digress...

Jason Carver
@carver
I am hearing postponement as the rough consensus on the Zoom call, too. People are starting to evaluate the risks of postponement, and how to mitigate them.
Nick Johnson
@Arachnid
I agree that that should be a showstopper. Not introducing new bugs into previously secure contracts should be right at the top of our priority list.
Alex Beregszaszi
@axic
Is the call still ongoing?
Martin Holst Swende
@holiman
yes
coming to a decision
Alex Beregszaszi
@axic
Can somebody put a short summary here?
Corey Petty
@corpetty
drafting one now
ifdefelse
@ifdefelse

Now, after some reading (specifically this: https://github.com/mimblewimble/grin/blob/master/doc/pow/pow.md#progress-freeness), I want to check out how do EtHash and ProgPOW fare in terms of progress freeness

@AlexeyAkhunov : both Ethash and ProgPOW find millions of solutions per second, compared to ETH's 15 second block times. This type of fairness issue is a problem for more complex algorithms like grin where solutions take a second, or zhash where it's finding just 10s of solutions per second

Lefteris Karapetsas
@LefterisJP

Guys I can't join the call atm but just to echo @Arachnid

not introducing new bugs into previously secure contracts - even if they arguably used bad practice - should be at the absolute top of our priority list.

If that means postponing that's fine.

Nick Johnson
@Arachnid
The consensus on the call is to postpone.
Micah Zoltu
@MicahZoltu
:cry:
Chase Wright
@MysticRyuujin
So do we start the notification campaign?
Nick Johnson
@Arachnid
Let's wait for the comms team to write something up first.
Corey Petty
@corpetty
we're drafting a notification blog right now
Martin Holst Swende
@holiman
@karalabe it'll be postponed -- new client should be released, which does not have a constantinople number in it. This will later be followed by a new release, with (most likely) a new constantinople-definition (lacking that EIP) and a new number.
Adrian Sutton
@ajsutton
When the dust settles we’ll need to work out what to do with Ropsten (and other test networks) where Constantinople has already shipped.
Micah Zoltu
@MicahZoltu
@holiman I think we should have a more extended discussion on that EIP before cutting it entirely, and more impact analysis.
Péter Szilágyi
@karalabe
Martin Holst Swende
@holiman
@MicahZoltu yeah, I agree. I was just summarizing the general discussion in the call
Micah Zoltu
@MicahZoltu
:thumbsup: To echo what @Arachnid alluded to earlier before I told him to be quiet, we can't forever be stuck with high gas costs because some people write bad code.
Péter Szilágyi
@karalabe
I think we need to murder the gas stipend
Micah Zoltu
@MicahZoltu
My personal vote on next steps would be to simply delay Constantinople to give people time to upgrade their contracts, withdraw their ETH, etc. given the upcoming change, as well as time for people to do some EVM analysis to find potentially broken contracts with lower false-positives. However, I don't think that we should not implement this EIP, and I don't think we should delay this EIP by another HF (6 months).
Taylor Monahan
@tayvano

Moving information from ZOOM chat to here for posterity

From Yoav Weiss to Everyone: (12:15 PM)

Since we're delaying the fork and have time to fix it now, I'd like to re-propose the fix I brought up earlier: Accept the EIP to lower the SSTORE fee, but add a condition that reverts storage access if gasleft < 2300. This preserves the original intention of the EIP (lowering the fees) while preventing exploitation. It is unlikely that a legit transaction will need to access storage while gasleft < 2300.


From Yoav Weiss to Everyone: (12:15 PM)

So when we apply the fork again, maybe we could do that and keep it as close as possible to the original fork.


From Nick Johnson to Everyone: (12:18 PM)

Yoav, that’s an excellent idea for a fix.

Vitalik (audio)
(expresses some hesitance around not being certain about full extent of vuln? more analysis would need to be done)

Nick Johnson
@Arachnid
I really like Yoav's idea; in my mind it's the purest expression of the current invariant (that 2300 gas is not enough to make a state change).
Alex Beregszaszi
@axic
I think it is a reasonable workaround to fix it, but we also need to keep in mind it is another tiny condition introduced into the design. Will this limit us even further in the future?