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
Micah Zoltu
@MicahZoltu
@Arachnid Yeah, I'm not a fan of it, but I think it is what people want (people often want things that are bad for them).
Nick Johnson
@Arachnid
@Vendoreth_gitlab Unless you need help updating an Ethereum client implementation you maintain to support Constantinople, this is not the appropriate place.
@MicahZoltu Right now what we need to do is preserve what people have.
Micah Zoltu
@MicahZoltu
While I am a fan of backward compatibility, I'm not a fan of getting locked in to decisions forever either beacuse people wrote code that makes assumptions it shouldn't have made. I can appreciate delaying a change like this for some amount of time to give people time to deal with it, but I'm not a fan of asserting that "we will always have this debt because one or more people may have made an inappropriate assumption while writing code". Knowing that the stipend value was set at the EVM layer may be enough to gain my support in delaying this EIP for a whole HF cycle, but I'm not convinced that we should permanently hack around it or indefinitely support the idea that < stipend means no storage changes.
Nick Johnson
@Arachnid
I mean, I'm not a fan of that either. But I don't think breaking existing code like this is an option we have. Part of the point of deploying on Ethereum is that your code will keep functioning the same way tomorrow as it does today.
It'd be particularly nasty to make non-backwards-compatible changes in an environment where there's no built in mechanism for upgrading code.
One of the big selling points of using Ethereum is that if I want, I can eliminate all trusted parties from my code: no owner, no trusted upgrade mechanism, nothing. We break that if we start introducing changes that retroactively make secure contracts insecure.
Micah Zoltu
@MicahZoltu
I have always suspected that Ethereum will eventually need to fall into that sort of mode (I call it Enterprise mode), where there are strong guarantees of no breaking changes. I guess I had hoped that we weren't there yet because I think Ethereum still has a lot of improvement necessary that won't be possible under that sort of constraint.
Perhaps the saving grace is Ethereum 2.0? We can run Ethereum 1.x in Enterprise mode indefinitely, yet gain benefits from lessons learned in Ethereum 2.0 where we can make all sorts of breaking changes.
Nick Johnson
@Arachnid
I think we've always been in "no breaking changes" mode, personally, ever since mainnet launch.
People use the network to do real things with real stakes.
And yes, 2.0 gives us lots of opportunity to make things better.
Brian Cloutier
@lithp
Is there anything stopping evm behavior from depending on when a contract was deployed? Contracts deployed before-Istanbul are always safe from this kind of attack, and contracts deployed after-Istanbul should know better than to rely on SSTORE having a high gas price, because it'll have a lower price. Contracts would inherit their era from the creating contract, so a before-Istanbul contract calling CREATE would create another before-Istanbul contract, but a transaction creating a brand new contract would result in something following the new rules.
Tomasz Kolinko
@kolinko
Brian, this wouldn't help in many cases
Nick Johnson
@Arachnid
@lithp There's no protocol field for when an account was created, no.
Brian Cloutier
@lithp
I bet there are reasons this wouldn't work but that doesn't sound like one of them, if you're hard-forking anyway you could add a field recording the era
Tomasz Kolinko
@kolinko
Because if you make an assumption in an earlier fork that a given function will only do such and such based on how much gas you give to it, this will obviously change when you are able to run a contract running on a new EVM
Evgeny
@eMarchenko
Maybe we can just increase cost for dirty SSTORE to about 2000 gas? that would prevent transfer-reentrancy, but is still quite an improvement and requires very little code changes and testing (hopefully)
Nick Johnson
@Arachnid
@lithp That's way harder than it sounds. Changing the consensus fields for accounts would require a stop-the-world upgrade to all existing ones.
@eMarchenko It's a solution, but it also makes net gas metering a lot less useful.
Brian Cloutier
@lithp
@kolinko Sure, I can see how it could get very confusing when you have contracts from different eras calling each other
Martin Holst Swende
@holiman
This is a good discussion, but could we please postpone the discussion a bit, and keep this room focused on the constantinople non-fork for the next couple of days?
Nick Johnson
@Arachnid
:+1:
Brian Cloutier
@lithp
:thumbsup:
Péter Szilágyi
@karalabe
Builds will be dripping in within the hour
5chdn
@5chdn
Rust pipelines still running ;-)
Micah Zoltu
@MicahZoltu
Are we tracking anywhere who all has been contacted?
H
@409H
Hudson is afaik
Hex Capital
@Hex-Capital
Will we be able to disable the fork on 2.2.6 via the CLI or definitely need to upgrade version?
Péter Szilágyi
@karalabe
Geth Homebrew updated to v1.8.21
Micah Zoltu
@MicahZoltu
@Hex-Capital :point_up: January 16, 2019 2:43 AM
Hex Capital
@Hex-Capital
@MicahZoltu sorry meant parity 2.2.6
Micah Zoltu
@MicahZoltu
According to @5chdn you will need to upgrade or downgrade.
They are prepping an upgrade release right now, will probably be available within a few hours.
Hudson Jameson
@Souptacular
I will keep up with who I contact as best I can
I have Ethfans China standing by to translate and send out
Micah Zoltu
@MicahZoltu
The spreadsheet linked previously has a tab for contacts it appears.
Kirill Pimenov
@kirushik

Yes; you either downgrade to pre-Constantinople versions (2.1.9-stable, 2.2.4-beta) — this is probably a worse idea, since you will lose some important improvements.
Or you wait for paritytech/parity-ethereum#10163 and paritytech/parity-ethereum#10164 to be released — will happen ASAP.

We're also going to push this update as critical again — which means that all mainnet parity nodes in default configuration will try to fetch this update via auto-updater.

Hudson Jameson
@Souptacular
Thanks @MicahZoltu
Kirill Pimenov
@kirushik
(Damn, local markdown ate version numbers in links — it's 2.2.7-stable and 2.3.0-beta)
ajlopez
@ajlopez
A new field to accounts giving the creation era could be added in a HF, previous ones have no such field, RLP encoding is untouched, no major problem
Kirill Pimenov
@kirushik
I want to restate — downgrading Parity to pre-Constantinople versions is a bad idea, we don't recommend that to anyone.
Theoretically it should even work, but we don't want to deal with that mess.
Just wait for your release and upgrade to the new release in your release track (stable/beta)
Matthew Halpern
@Matthalp
@Souptacular How often are EIPs audited by a third party before being selected for inclusion in a hard forks? If not, it may be a good idea to consider doing this in the future.
Péter Szilágyi
@karalabe
To be fair, this EIP was out in the open for almost a year
Micah Zoltu
@MicahZoltu
Yeah, this EIP had a lot of discussion from a lot of people.
Péter Szilágyi
@karalabe
That said, maybe it's not a bad idea to do some grants for more focused eyes
Martin Holst Swende
@holiman
There are no third parties which can audit eips. I mean, there's no outside person not already deep into ethereum that can audit an eip based on some general body of knowledge. It's quirks upon quirks
Péter Szilágyi
@karalabe
fair point