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
borovan
@borovan

Since leaving the US, renouncing my citizenship, and refusing to return my life has become much less complicated. 😁

challenge accepted

Micah Zoltu
@MicahZoltu
😬
Greg Colvin
@gcolvin
I hear you, @borovan and @MicahZoltu, but I’m the oldest of six siblings, and lose count of my cousins, neices, nephews, grandnieces, grandnephews, and even a greatgrandniece. Plus inlaws, outlaws, and over sixty years worth of friends. I’m not leaving.
Vittorio Minacori
@vittominacori

Hello guys, what do you think about the idea of having an onchain Ethereum Package Repository and Registry where people could publish their contracts with versions and then those contracts can be cloned using eip-1167

Each Repository will be a package linking to an already deployed contract with different versions and Registry will list all of them.

I’m considering to write an EIP but I would like to have a quick feedback before. Thanks

Micah Zoltu
@MicahZoltu
I recommend asking on ethereum-magicians. My gut feeling is that there is no reason for that sort of thing to be on-chain.
Vittorio Minacori
@vittominacori
The goal is to have a preset of contracts already deployed, in order to be able to clone and deploy cheaper.
Imagine you can call Repository.clone(“v1.1", initData) instead of depoying in a classic way
Micah Zoltu
@MicahZoltu
Runtime costs for that contract would likely be higher.
Vittorio Minacori
@vittominacori
So do you think that it couldn’t be helpful in any case? It seems that Minimal proxy adds 700 gas per call.
Micah Zoltu
@MicahZoltu
In most cases, the cost of contract deployment is insignificant compared to runtime costs of contracts. There are of course exceptions, but that is the common case.
corkywithac
@corkywithac
So
jtakalai
@jtakalai
Hi, a question on the different token standards: ERC667 is a non-EIP but nevertheless well defined and used by LINK at least. It's not even mentioned in some lists like https://codepen.io/jarraddenzel/pen/VoKJgN or https://eips.ethereum.org/all . Is there a reason ERC667 never made it into a standard despite seeing some use?
Micah Zoltu
@MicahZoltu
Sometimes people just abandon their EIPs.
jtakalai
@jtakalai
it's interesting though to see transferAndCall in 4 tokens in top 100, and yet not enough interest (e.g. from those token devs) to promote it. By contrast, the only ERC-777 token I found in Etherscan is https://etherscan.io/token/0x89Ab32156e46F46D02ade3FEcbe5Fc4243B9AAeD and it's not in top 100.
Do you happen to know other projects that use ERC-777? Seems Aragon is at least interested aragon/aragonOS#163 but it's not clear how widely used "all tokens Aragon generates" really is
Micah Zoltu
@MicahZoltu
🤷‍♂️
ashrowz
@ashrowz
Hello, I have created an EIP for an interface that wraps NFTs with ERC20 tokens: ethereum/EIPs#3384. Would anyone mind reviewing it?
axel simon
@axelsimon
Hi everyone, i work at Red Hat on the sigstore project, which you may have heard of recently: it's a public good system to help make it possible to verify provenance of software, using signatures and a shared root of trust
it's heavily inspired by Let's Encrypt, but for signing code, containers, software artifacts in general
i'm curious as to whether the Ethereum community would be interested in using it to provide higher guarantees of provenance on the various downloads (geth, besu, etc.)
anyway, i'm asking here as it sounds like an improvement that would go into an EIP, but given i'm not really active in the Ethereum community (i have run a node :)), i thought it made more sense to gauge interest here first!
Haz Æ 41
@hazae41
Hey, I made an ERC for an antitoken, a negative token that can be used to represent debt.
Check this out: ethereum/EIPs#3477
Ricardo Chacón
@RicardoChacon
Hi everyone, I'm gauging interest in standardizing Metadata for ERC-721 Tokens to make an EIP so any feedback on this post would be greatly appreciated: https://ethereum-magicians.org/t/request-for-feedback-standardizing-location-metadata-and-other-metadata-in-erc-721-tokens/5985?u=ricardochacon
Brent Allsop
@BrentAllsop
Hello @RicardoChacon,
If you’d like to more definitively track how much consensus you have achieved with an active petition system, along with tracking anyone that may be against the idea (with great ways of getting them onboard), I’d be happy to help you get a canonizer topic set up where people could “support” camps both for and against the idea, as we have started to do with other issues in the Ethereum Consensus Project (https://canonizer.com/topic/210-Ethereum-Consensus-Project/1). I’d be willing to support your proposal, and I know others who would also.
KaiRo
@kairo:mozilla.org
[m]
@RicardoChacon: if you want to standardize anything, you probably should start with the most common properties and there follow what is already established - it sounds like you're trying to start with something that is a pretty uncommon property there...
Ricardo Chacón
@RicardoChacon
@kairo:mozilla.org oh ok will do that. Yeah right now location is the one field that would be useful and have already thought about an implementation for but I'd be happy to start with something far more common. Do you have any suggestions or resources so I can start looking? Thanks again
KaiRo
@kairo:mozilla.org
[m]
@RicardoChacon: I would start at those that OpenSea is using - see https://docs.opensea.io/docs/metadata-standards - as that is mostly a de-facto standard but none that is an official EIP from all I know
Ricardo Chacón
@RicardoChacon
Perfect, will do thanks :D
Vesa-Ville
@vvp
Hi everyone, I think I found an underspecification issue in a final EIP, which may however fall into category of "non-normative clarification" depending on how people interpret it :slight_smile: what is the correct forum to bring the issue up, in the GH issue discussion or somewhere else?
Brent Allsop
@BrentAllsop
Hi @vvp if it is a problem with a specific EIP, I'd think you could contact the sponsors of the EIP. Which EIP?
Vesa-Ville
@vvp
@BrentAllsop are sponsors the same as authors? it's EIP-1155
KaiRo
@kairo:mozilla.org
[m]
Given how popular 1155 is, it has been looked at by many people, so I wonder what you may have found there
Vesa-Ville
@vvp
@kairo:mozilla.org shortly, balanceOfBatch-function does not specify the order of the returned array - for inputs [owner1, owner2], [id1, id2], should it be a) [balanceOf(owner1, id1), balanceOf(owner1, id2), ...] or b) [balanceOf(owner1, id1), balanceOf(owner2, id1), ... ]? this underspec is unfortunate because all 4 ERC-1155 implementations I could find seem to implement the balanceOfBatch quite ... unintuitively :slight_smile:
1 reply
KaiRo
@kairo:mozilla.org
[m]
that's how I read balance for each (owner, id) pair and that's also how all the batch functions I have seen anywhere do work
but yes, maybe that could be specified more exactly
Vesa-Ville
@vvp
yep, exactly because of these different ways to interpret it, the order should be specified
KaiRo
@kairo:mozilla.org
[m]
but anything else than having the result be the same length as the input arrays would IMHO be quite dangerous and a pattern that should never appear in code like that
Vesa-Ville
@vvp
that sounds like another clarification for the balanceOfBatch spec, a casual reader don't realize the danger there :slight_smile:
KaiRo
@kairo:mozilla.org
[m]
I mean "dangerous" in terms of both how to relate the results to the input and in explosion of data in the result
Also, in terms of 1155, if Enjin (the original proposers of the EIP) and OpenZeppelin (the probably most widely used base implementation) implement something the same way, I would guess that this is how it was intended to be
Vesa-Ville
@vvp
yeah, tbh I intuitively thought "oh, balanceOfBatch seems to map balanceOf over a Cartesian product of inputs" when reading the interface definition, which is why those existing implementations seemed so unintuitive to me at first - but you're right, the Enjin's reference implementation is probably the strongest evidence of the original intent, so I guess there's a good chance for this spec improvement to be a "non-normative clarification"
Simon Fremaux
@dievardump

Hello there! I've just opened a new discussion issue about an idea for an EIP extensions to the NFT (erc721 and erc1155) specifications

if anyone is interested to talk about it, hit me up