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
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?
Nick Johnson
@Arachnid
I personally think it's the reverse - it makes an existing invariant self-contained instead of depending on other factors.
Martin Holst Swende
@holiman
It's a patchy patch, might work but adds tech debt IMO
Nick Johnson
@Arachnid
If we'd had that condition to start, this would never have been an issue - it's only an issue because the conditions required aren't local.
Micah Zoltu
@MicahZoltu
Would the proposed change mean that if the last instruction of a contract is a storage update, then that transaction will always demand excess gas?
Nick Johnson
@Arachnid
It would, which isn't a problem on its own (anything that offers a refund also requires 'excess' gas) but it would complicate gas estimation code a little.
Actually, that last bit isn't true - current gas estimators do a binary search until the execution succeeds.
Micah Zoltu
@MicahZoltu
Also, we would need to have this not apply to simple ETH transfers I'm guessing, since they currently use exactly 21,000 gas (and there is a lot of tooling that depends on this). I doubt this is a problem since I'm guessing this logic would be part of EVM execution, not simple value transfers.
Nick Johnson
@Arachnid
@MicahZoltu Simple ETH transfers don't get the gas stipend (Which is irritating; I've been meaning to propose an EIP to change that).
Ghost
@ghost~55c3ed250fc9f982beac84b3
I would say this - it is likely that we will be changing the cost of SSTORE again soon - to manage the state size growth. I do not exactly know how. So I would not rush re-introducing this EIP unless it is really critical for something. Like REVERT in Constantinople, it makes the gas pricing fairer, but it does accelerate the state growth, unfortunately (because by saving gas on SSTORE, more state expansions can be done in one block)
Nick Johnson
@Arachnid
@AlexeyAkhunov It doesn't accelerate state growth - with this EIP, the cost of a SSTORE that actually enlarges storage remains the same. Only SSTOREs that result in no net change are cheaper.
Wei Tang
@sorpaas
@MicahZoltu @Arachnid I think it wouldn't, given that it's applied with net metering together. Anything that previously doesn't revert, won't revert.