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
Jochem Brouwer
@jochem-brouwer
I'm trying to verify the contracts
This is the test from the ChainSecurity truffle
Geoff Hayes
@hayesgm
FYI, Compound Finance avoids transfer and send and opts for wrapped ERC-20 instead, so we're safe there. That said, I agree it could be difficult for contracts that did depend on the limited gas stipend.
Jochem Brouwer
@jochem-brouwer
@hayesgm I agree that even with transfer and send people should not have re-entrancy attacks available even if that doesnt work due to gas. But, I think most people have always had in the back in their heads that it is never possible to change storage using transfer or send which is hence now possible
I guess it's not even limited to one slot but actually multiple since every storage slot write which is dirty is 200 gas
I am pretty sure that if we check etherscan we can find some contracts which hold a small amount of eth which are now suddenly drainable due to the hard fork
Nick Johnson
@Arachnid
Well bugger. It's worth thinking about the larger implications here; do we really want to be stuck with requiring all state modifying operations to cost more than the gas stipend? That puts a serious crimp in any optimisation effort, not just this one.
It's definitely something people use at least as a safety net, though, if not more than that.
Micah Zoltu
@MicahZoltu
@Arachnid The current plan is to avoid that conversation right now.
Aron
@cobordism
@jochem-brouwer I was just confused about what does it mean for the test to "pass".
Jochem Brouwer
@jochem-brouwer
I strongly suggest that the fork is delayed because this would honestly raise a lot of confusion in the development community. If it is strongly implied some things are not possible but due to a hard fork it is suddenly possible that is really discomforting and reduces a lot of trust. Still want to mention the Core Dev team has done an amazing job but I also want to thank ChainSecurity for raising this point now (although its really short notice) - there now is some time to fix this.
@homotopycolimit it confirms that a re-entrancy attack is possible on constantinople using transfer/send
Micah Zoltu
@MicahZoltu
We don't have enough time to make a decision other than "to Constantinople or not" right now, not enough time to discuss the long-term ramifications and solutions.
Nick Johnson
@Arachnid
One simple analysis to find potentially vulnerable contracts is just to look for anything that makes a transfer or send and then changes state or makes a less-gas-constrained external call.
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.