Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Sep 02 2018 09:26
    @Arachnid banned @johnny_musk_twitter
  • Jun 06 2018 10:22
    @Arachnid banned @ethsupport1
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
  • Jun 05 2016 10:37
    @chriseth banned @adamskee
Bryant Eisenbach
@fubuloubu
perhaps, my point is simply that encoding all of this complex interactions into the EIP process is a bad idea
EIPs should be simple, technically-oriented, and limited in scope
Bob Summerwill
@bobsummerwill
I agree.
Brent Allsop
@BrentAllsop

What would happen if we could know that an EIP achieved something like all of the following?

Greater than 75% of voting core devs
Greater than 75% of voting miners.
Greater than 66% of voting quadratic ether [sqr(ether)]
Greater than 66% of voting popular consensus

How this is achieved, could be elsewhere, but such a simple specification could be done in EIP 1?

Bryant Eisenbach
@fubuloubu
I think any measurement of "consensus" needs to occur outside of the EIP process
What should happen is EIP -> { community } -> Core Devs -> Mainnet
of course there is some mixing, because for certain EIPs knowing the implementation process and ensuring technical consensus (aka consensus of the protocol) is important during the finalization of a standard, but politics is not helpful to technical standardization
politics is only helpful to inform client implementers of what they should push to mainnet
Brent Allsop
@BrentAllsop
The goal of all technical protocol specifications is getting everyone all that they want, or at least as much of that as possible. We’ll never be able to get that, technically or otherwise, unless we first know what that is.
Bryant Eisenbach
@fubuloubu
I definitely disagree with you there. The goal of technical specifications is to make sure we're all on the same page about a particular thing we might want, and how to make it work in practice. Human desire for change is endless.
Brent Allsop
@BrentAllsop
Very good, and valuable point. I’m wondering what I said to make you think I was implying anything different. This is what you want. Not only do I want what you want, I think it is the right thing (i.e. we could build a near unanimous consensus around this idea.) In other words, most people could eventually agree we should build some kind of hysteresis into the approval algorithms, which values some stability and “tradition” over change. The values I listed, above, to include in an approval algorithm are just intended to be a few examples of what could be used as input to any possible algorithms. Unanimous consensus means your valuable vote on important things like this is critically important.
Bryant Eisenbach
@fubuloubu
Well, what I was trying to say is that I don't want this sort of metric-based "consensus" definition in the EIP process. It doesn't belong here. It belongs in a governance process design group.
Tim Beiko
@timbeiko
Big +1 on separating both concerns out. That’s something @Arachnid mentionned a few times on Twitter over the past weeks. I think it will be quite the effort to try and write this. I don’t have the bandwidth to take a stab at it but happy to help review/give feedback/etc. on any proposal. We should probably bring this up on the EIPIP meetings too to see if anyone else would like to help
Hadrien Croubois
@Amxx
Hello,
Just had a quite discussion with James who told me I should ask here to get my ERC proposal merged into the ethereum/EIPs repository. Its PR 2525.
If anyone could merge it that would be great. I'm trying to get feedback and it not being merged limits the visibility of the proposal
Pooja Ranjan
@poojaranjan

@MadeofTin The more I think about it, the more looking at proposals that cement the hard fork process into the EIP process seems like a bad idea. Creating informational proposals that guide Ethereum implementers (aka Core Devs) in how to implement network upgrades are nice, but I'm not sure our ever-changing implementation process should be wrapped up so deeply into our technical standardization process. I will be thinking about this a lot more, but I just wanted to mention this as I look at proposals like EIP 233 and EIP 2378 which deeply ingrains the "how" of what implementers do, when really those processes can exist either as informational standards or completely outside the standardization process (allowing for continuous improvement of these processes). I think perhaps what is missing is that we should have an "Ethereum Implementers Manual" which encodes these processes as largely separate from technical standards that implementers use to change the configuration of Ethereum Mainnet (and other Ethereum-based networks)

@fubuloubu We discussed this a little bit, in EIPIP3. I do agree that we should keep it out of EIP 1 because the upgrade process keeps changing and we don't want to edit EIP1 very often. At the same time, we need to point the community towards the current process being followed (probably via EIP1). So, I propose to add the "Motivation" section in Meta EIP for an upgrade. (This is missing from almost all of the previous Upgrade Meta EIP. However, it was added in the Muir Glacier upgrade Meta EIP.) In this section, say for Berlin EIP 2070 , we can add a reference to EIP 2378 that lists the EFI EIPs to be included. About EIP 233, I think that may be added to EIP 1 as a template (with small changes) for upgrade Meta EIP, where Meta EIP is defined. However, I think it should not be added until it's state is changed to 'Final/Accepted'. I also agree that both EIPs seem closer to Informational EIP than Meta EIP.

Bryant Eisenbach
@fubuloubu
Yeah, I think turning them into Informational would do a good deal to assuage my issues with their structure
Pooja Ranjan
@poojaranjan

Big +1 on separating both concerns out. That’s something @Arachnid mentionned a few times on Twitter over the past weeks. I think it will be quite the effort to try and write this. I don’t have the bandwidth to take a stab at it but happy to help review/give feedback/etc. on any proposal. We should probably bring this up on the EIPIP meetings too to see if anyone else would like to help

Yeah, that's a good point.

Bryant Eisenbach
@fubuloubu
It's basically active advice for how to use the process, not a mandate
Pooja Ranjan
@poojaranjan

Yes, I completely agree with it.

It's basically active advice for how to use the process, not a mandate

Kaden Zipfel
@KadenZipfel
Hey guys, does anyone know of an EIP for a futures trading contract standard? I'd like to implement one if it doesn't already exist.
James Hancock
@MadeofTin
Not that I am aware of, but I am also not sure I would be if there was one. The status of ERCs is much more difficult to get a sense of. I’d recommend searching Ethmagicians.
Bryant Eisenbach
@fubuloubu
Yeah, sometimes I really wish they were just a separate process. Le sigh
Kaden Zipfel
@KadenZipfel
Thanks for the input, James.
Micah Zoltu
@MicahZoltu
@KadenZipfel Why would you need an EIP for that?
Sounds like what you want is to build an app, which anyone can do.
Kaden Zipfel
@KadenZipfel
@MicahZoltu Would there not be value in having a futures contract standard?
Bryant Eisenbach
@fubuloubu
There might be, but it depends on whether other people would get value out of it, in terms of integrating it into their own contracts and infrastructure
The best bet is just to build the thing first, and see if it makes sense to go the route of standardization afterwards. It's a long difficult path to becoming a standard.
Micah Zoltu
@MicahZoltu
@KadenZipfel Standards are useful when there is a many-to-many relationship between consumers and providers.
Twitter API doesn't need a standard because there is a single producer (Twitter) and many consumers.
HTTP needs a standard because there are many producers (HTTP servers) and many consumers (HTTP clients).
If you are building a futures contract that others can interact with that doesn't need a standard, anyone can just integrate with your thing. If you build a special purpose wallet and want many tools to integrate with it you similarly don't need a standard, tools can just integrate with you directly.
If you think that there will be many producers and many consumers, then the first step is showing that.
courtney e boyle
@corkywithac1_twitter
hello
ohh and why is that
Brent Allsop
@BrentAllsop
Hello Courtney, and Welcome. I'm not sure I understand your question.
Brent Allsop
@BrentAllsop
Is there an agenda for today's meeting, in 2 hours, right?
Ah, found the agenda:
Brent Allsop
@BrentAllsop
Does anyone have a zoom link for the meeting in 10 minuts?
coolcryptomaniac
@coolcryptomaniac
EI
my eip - All the revenue generated from all community funded smart contract applications , 2-3%(or whatever fair) of transactions goes back to ethereum community sustainaibility , which then invests this amount to further new projects.
Sam Richards
@samajammin
Heya folks, I just put together a proposal for the EIP website (not suggesting any changes to the EIP process) & will be joining the EIPIP call tomorrow to discuss. I welcome any feedback you folks may have, no matter how critical :) https://www.notion.so/efdn/Migrate-EIP-content-to-ethereum-org-b50f198d8c254e2eb89790658e9079a8
Thanks in advance
Ricardo Guilherme Schmidt
@3esmit
Can I have ethereum/EIPs#2470 merged? Its not a very complicated EIP, but its a dependency for others I am writing.
Greg Colvin
@gcolvin
@3esmit Merged.
Ricardo Guilherme Schmidt
@3esmit
thank you!!!!!!
Greg Colvin
@gcolvin
I’m not sure why the auto-merger didn’t handle it @Arachnid ?