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
Corey Petty
@corpetty
yeah, waiting on verification from blockchain scans, wasn't sure what was the threshold of exploitability that pushes us to postpone/not-postpone
Michael - Blurpesec
@blurpesec
Its mostly just comparing risk. What risk is there to postponing at the last minute (network split, or worse - doublespends).
Jochem Brouwer
@jochem-brouwer
My two cents: if the attack is verified then the hard fork should be delayed. Many developers have assumed in the past that transfer and send are safe against re-entrancies. It is just time until contracts are found which can be attacked. This is not fair and will reduce trust in the Ethereum network. If it is implied (in many documents) that these functions are re-entrancy safe and that suddenly these are unsafe against these attacks this will reduce trust in the network a lot since the way how things work apparently can change over time.
Bruno Škvorc
@Swader
^ this. Never mind custom made multisigs by Bob or Alice, if things like Compound.Finance or MakerDAO's CDPs suffer because of this, these enormously successful and growing DeFi projects will be left with no choice than to say "Okay, guess the logic of the program can change, we can't make it work here, let's leave". (illustrative example, those are probably safe). We definitely don't want another DAO or several.
Danno Ferrin
@shemnon
Don’t most DeFi contracts have a pause button? how many have burned their pause keys?
Taylor Monahan
@tayvano
On the call there is talks of using a collaborative sheet for analysis of smart contracts so people aren't duplicating work. I’m not 100% of what the column headings should be but here’s the sheet that we can all use (feel free to be opinionated on what the headings should be): https://docs.google.com/spreadsheets/d/1GS98k8YosBsqV1UVq57vX-PTOUAcCCcRjJ847H8Y4hw/edit?usp=sharing
Jochem Brouwer
@jochem-brouwer
I have run the ChainSecurity tests on ropsten. They pass
Aron
@cobordism
@jochem-brouwer can you elaborate? What does that transaction show?
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.
Matthias Egli
@MatthiasEgli_twitter
This is finding tons of contracts
Nick Johnson
@Arachnid
That'll have lots of false positives, but it's a start.
@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.