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
Tomasz Kajetan Stańczak
@tkstanczak
with the proofs mechanism for specific topic requests
Micah Zoltu
@MicahZoltu
No? Have a link?
Tomasz Kajetan Stańczak
@tkstanczak
trying to find a link...
either not on reddit or he deleted it after finding some issues with the design...
maybe on ethresear.ch
here you go @MicahZoltu
Micah Zoltu
@MicahZoltu
Thanks.
Tim Beiko
@timbeiko
Danno and I had a proposal at devcon about how we can change the network upgrade process. It’s based on a lot of the things that have been discussed over the past year. I wrote up a rough transcript for it to share with this group prior to Friday’s call, where we’ll likely be discussing Berlin. EthMagicians link: https://ethereum-magicians.org/t/a-train-station-model-for-network-upgrades/3721
Pooja Ranjan
@poojaranjan
Nice write up @timbeiko
Tim Beiko
@timbeiko
Thanks Pooja!
ledgerwatch
@AlexeyAkhunov
Great stuff, thank you!
Danny Ryan
@djrtwo
Hudson Jameson
@Souptacular
For anyone who hasn't seen: "Recently Executed Contracts with Issues in EIP 1884" https://gist.github.com/ritzdorf/1c6bd72955391e831f8a397d3152b4e0
Tim Beiko
@timbeiko
Given that there was talk about helping to fix broken contracts due to 1884 post-Istanbul, what would happen if any of these identified contracts did not upgrade prior to Istanbul?
Personally, I’m a bit uneasy about making such a promise to the community when the reality is that there may/will be several edge cases and there is no clean way to determine whether something got enough warning to fix their contracts pre-upgrade.
Wei Tang
@sorpaas

What’s wrong with just accepting the reality that some contracts will be broken by 1884? Fix may be coming, or it may not, or it is possible but will be controversial. That will be up to the community, not AllCoreDevs to decide.

Given that most core developers are okay with moving forward with 1884 in Istanbul, I don’t understand why we can’t simply state the fact, and stop drawing fancy pictures about things that may or may not happen.

Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Hudson Jameson (souptacular)> @sorpaas can you elaborate on the "drawing fancy pictures about things that may or may not happen". I don't follow what you are saying.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Hudson Jameson (souptacular)> And when you say "the community will decide" do you mean that the community will decide if things are broken and ask the core devs to fix?
Hudson Jameson
@Souptacular

@/all meeting in 11 hours

Agenda: ethereum/pm#133

Wei Tang
@sorpaas
@Souptacular I’m saying the same thing I said last time. AllCoreDevs should not promise things it cannot promise.
Also EIP editors please merge ethereum/EIPs#2200
Otherwise I believe you’re violating EIP rules by ignoring multiple requests to merge (for months), after reviews are addressed by the author.
Martin Holst Swende
@holiman

I agree that ACD should not make promises, nobody can do that. So let's not use the word "promise" too much.

However, IMO we have an internal consensus, explicitly stated, that if 1884 screws something up really bad, we'd be open to trying to "fix" that.

Now, what 'screws something up' means is up for debase. I personally would say if funds become irrecovably stuck, that'd be screwed. But if some set of contracts become "unusable", then I'd say it's time to redesign and redeploy.

So what does "fix" mean? Imo the simplest thing that resolves the screwiness. Could e.g. be a dramatically reduced cost of LOG during an interval of blocks. Or something completely different.

There's a liveness check here that I think is good. I, and many like me, have deployed shitty experimental contracts ever since Frontier. There's a graveyard of failed experiments on the chain, let's not make it into a shrine. Contracts and services that still are "live" and are affected can be helped, we don't need to solve every contract on chain.

Greg Colvin
@gcolvin
@sorpaas I went to merge and noticed just a few unresolved comments. Since this is still a Draft and none of the comments address the form of the proposal I merged it, and you can deal with the comments later.
Wei Tang
@sorpaas
@gcolvin Thank you!
Wei Tang
@sorpaas
@holiman That’s a bad idea. By that action you’ll make AllCoreDevs take political side on the issue “what should we do when funds got stuck”. We can argue all days about the differences of “funds stuck” by EIP-1884, EIP-999 and theDAO, but by taking a position for the funds stuck issue on 1884, you will inevitably put EIP-1884 into the same category of EIP-999 and theDAO.
Martin Holst Swende
@holiman
I'm not talking about generic funds stuck. I'm talking about specific instances of eip-1884 causing e.g. a wallet, hardcoded to only send to a particular receiver, which can no longer do so after 1884. So if there are such cases, then I'm on board with trying to fix that, but not throw 1884 out the window just because of the theoretical existence of such cases @sorpaas
Wei Tang
@sorpaas

@holiman As I said before, we can argue all day about if “funds stuck” by 1884, 999 or theDAO are the same. But just talking about recovering funds stuck is a bad idea. You’re inevitably making things political.

What I’m saying is that a sane approach should be that we accept the reality that it may break something, and just tell everyone “check your contract otherwise there’s a small chance your funds will stuck”.

And on a side note, while I support Istanbul as it is, I really don’t like any of these. My personal opinion is that we should adopt backward compatibility solutions soon so this situation can be avoided altogether.

@gcolvin It’s still not merged. ethereum/EIPs#2200
Martin Holst Swende
@holiman

I don't see what's political, tbh, if we say already, before it has happened. It'd be more political if we say "we'll break it and not fix anything", and it later turns out that 500 kraken-users got their funds stuck in some relayer contract which starts failing, and only then starts talking about remedies.

we can argue all day about if

Yeah, ok, so let's not. I'm done for now

Wei Tang
@sorpaas

I don't see what's political

Talking about fund recovery is already political. That’s why I say let’s just accept the fact that “funds may stuck” and move on.

Tim Beiko
@timbeiko

What’s wrong with just accepting the reality that some contracts will be broken by 1884? Fix may be coming, or it may not, or it is possible but will be controversial. That will be up to the community, not AllCoreDevs to decide.

Given that most core developers are okay with moving forward with 1884 in Istanbul, I don’t understand why we can’t simply state the fact, and stop drawing fancy pictures about things that may or may not happen.

That was my initial point :sweat_smile: You phrased it better than I did. I think accepting that some things may break, and not setting the expectation of a fix in that case, is probably the best incentive we can provide for dapp developers to actually upgrade their code.

Wei Tang
@sorpaas
:thumbsup:
Micah Zoltu
@MicahZoltu
@timbeiko Not all dapp developers can upgrade their code. Not all dapp developers are paying attention to Ethereum, but in some cases people are still using those apps. This can lead to regular users who don't know any better getting burned, without any reasonable ability to realize it.
That being said, I agree with making no promises and moving forward under the tentative assumption that nothing will be fixed.
I am against drawing a hard line in the sand and saying "absolutely will not" as well.
Tim Beiko
@timbeiko

I am against drawing a hard line in the sand and saying "absolutely will not" as well.

+1 on that. I’d rather just set lower expectations here and then exceed them rather than the other way around.

James Hancock
@MadeofTin

There's a graveyard of failed experiments on the chain, let's not make it into a shrine.

 - Holiman

This is my Gitter highlight of the week.

Hudson Jameson
@Souptacular
Had to restart laptop. Posting links soon
@/all meeting in 10 min
Tomasz Kajetan Stańczak
@tkstanczak
oh? I thought it was next week, let me join
Danno Ferrin
@shemnon
It’s next week too.
Tim Beiko
@timbeiko
It is? To move them off the Eth2 schedule?
Danno Ferrin
@shemnon
Yes.
Tomasz Kajetan Stańczak
@tkstanczak
Ah I thought we were alraedy moving off eth2 schedule, that is why I assumed there was none today.
Can we link the fork id EIP here?
Alex Beregszaszi
@axic
Here are the outstanding networking EIPs: https://eips.ethereum.org/networking