Diegorb1329/eth_magicians_forum huggingface dataset:
Title: Pooling_commit_reveal_to_avoid_front_running
Category: Magicians

Author: bbin
Date: 2018-11-28T19:52:26.142Z

Hello!
So, many kinds of contracts need fraud/fault-proofs with economic incentives. Unfortunately miners can steal the reward without doing any, or just a bit of, validation which breaks the incentive structure. A way to mitigate this is to commit a hash of a message containing the intention to send a fraud proof. The reward then would go to the first person who committed an intention, not the first person to submit a fraud proof (or begin some kind of fraud proof game, truebit-style).
A problem with this is that if the system is small enough, just the fact that someone commits an intention to prove fraud could be enough for a miner(/validator) to do some checking and find the fraud in question.
Could this be mitigated further by creating a standardized commit/reveal contract that could be utilized by all systems of this kind? Would it be worthwile? The miner would then know only that someone is committing a secret for some kind of commit/reveal-based system, increasing the likelihood of the honest fraud prover getting the reward.
Thoughts?
Title: What_should_the_process_be_for_getting_changes_mad
Category: Magicians

Author: jpitts
Date: 2018-04-23T17:04:30.081Z

@MicahZoltu posted this in the ethereum/governance gitter channel:

@Arachnid I’m curious, what do you think the process should be for getting changes made to the EIP process? It has been thrown around (pretty frivilously) that PRs should be made against EIP-1, but we can’t merge those as drafts (which is the process for making changes to the protocol). Is the idea that EIP-1 PRs are long lived and sit open indefinitely? Following the EIP process doesn’t feel like it really makes sense, as we can’t say, “economic participants can fork” (technically they could fork the EIP repo, but if that is really the intention I feel like it should be spelled out somewhere).
This situation reminds me of something I heard a while back:

The first and most important process is a process to change the process.

I feel like we are missing that right now.

Author: lrettig
Date: 2018-04-24T16:18:03.018Z

This is a fantastic question. As I’ve said elsewhere, as a starting point I think it’s helpful to understand how things work today (read: present source of dysfunction). My understanding on this topic is limited so I’m curious to hear what others have to say, but I’ve seen two things happen:

These get opened as EIPs e.g. https://github.com/ethereum/EIPs/pull/894

PRs against EIP-1 e.g. https://github.com/ethereum/EIPs/pull/956
Title: Sober_arguments
Category: Magicians

Author: ligi
Date: 2019-01-13T23:32:41.082Z

Was just rewatching some talks from 35c3 and stumbled upon sober arguments. Wonder if we should try this for contentious discussions. Current candidates could be e.g. ProgPow as far as I see.

Author: ligi
Date: 2019-09-18T06:56:41.524Z

bringing this up again after the tweet by @souptacular
https://twitter.com/hudsonjameson/status/1174154313997979648

Author: pmauric
Date: 2019-09-18T15:36:01.851Z

I have started a Kialo discussion for this. Based on my research, Kialo is the most practical and useful rational debate platform out there at the moment. Interested to see how people engage with it!



Kialo – 18 Sep 19



Ethereum and Programmatic Proof-of-Work (ProgPow)
Hudson's request that we catalogue the for and against in this debate in a better format twitter.com  Background from Ethereum Magicians forum:…
Title: Crypto_collectives__membership_and_role_management
Category: Magicians

Author: rumkin
Date: 2019-10-08T22:42:32.407Z

This is a proposal draft. For crypto communities/organizations.
Problem

Each time new member get into the organization or get out of it, someone need to grant/revoke all accesses to the new member. Sometimes new member couldn’t receive required permissions or preserve access to organization infrastructure and continue to receive corporate mails/bills/other sensitive information. Also when this member change a role the process should be run again. This is really insecure and very problematic issue.
Today all services around the globe couldn’t determine wether the user has permissions to create account for the specified brand or not. There is no such data layer which can join company ownership data with any database to provide membership/ownership guaranties.

Solution
Create a contract which can manage team members and their roles. Changes from the contract could be read by another contracts or external software to define/resolve access permissions.
For example it could be used with ENS domain. This will allow user with role developer to have permissions to deploy the website, merge PRs, close Issues, etc. and owner to create new social network accounts for this host.
Requirements

Role could be added and removed.
Role could be suspended and activated.
Role could be renamed.
Roles count is uint256.
Members could have several roles in the same time for example ‘developer’ and ‘sysadmin’ or ‘designer’ and ‘photographer’.
Member could be suspended and activated.
Contract should emit events for:

membership granting/revoking,
members role granting/revoking,
role adding/removing,
role suspension/activation.


Role granting/revoking process could have different implementations: authoritative, votable, hierarchical.

Contract interface
contract ITeam {
    // Role management
    addRole(string name) returns(uint);
    getRoleId(string name) return(uint);
    getRoleName(uint roleId) returns(string);
    countRoles(address member);
    getRoleByIndex(uint index);
    disableRole(uint roleId) returns(bool);
    enableRole(uint roleId) returns(bool);
    
    // Membership menagement
    setMemberRole(address member, uint roleId) returns(bool);
    hasMemberRole(address member, uint roleId) returns(bool);
    removeMemberRole(address member, uint roleId) returns(bool);
    removeAllMemberRoles(address member);
    countMemberRoles(address member);
    getMemberRoleByIndex(uint index);
    disableMember(address member) returns(bool);
    enableMember(address member) returns(bool);
}

Unresolved questions/probable solutions

There could be a “standard” roles. To be unified for all solutions.
There should be a way to avoid role names collision for upgradeability and security issues.

Example
I’ve realized such contract support in a twitter a-like text-only append log web app to manage collective accounts or groups. Thus it became possible to hire content managers without fear of access loss, buy/sell membership, create earning communities.
Title: PoorMe__unreasonably_cheap_on_chain_ERC_transfers
Category: Magicians

Author: kladkogex
Date: 2021-02-02T11:43:23.180Z

TL;DR
We describe PoorMe, a smart contract-based on-chain wallet that drastically reduces transfer fees for ERC tokens.
The fees become similar to ETH native transfer fees (21K for a send and 10K for a multisend).
PoorMe enables forks of dapps like Uniswap with way lower gas fees.
Description.
ERC token transfer fees are much larger than ETH native transfer fee.  For example, SNX is around 100K gas to transfer and  SKL is 65K gas.
Ironically, there is an (overlooked!) method to achieve ERC token transfer fees almost identical to native ETH fees.
The method is utilizing a dedicated on-chain wallet for each user, as described below.
Here is how it works:

There are two master smart contracts :



WalletFactory deploys wallets


TokenBank holds all ERC tokens




Onboarding procedure:  Alice calls WalletFactory, which deploys a dedicated PoorMeAlice wallet contract.


Deposit procedure: to deposit, say, 100 SNX Alice deposits SNX  to TokenBank, and, in parallel, deposits  100 / 10^{12}  ETH to PoorMeAlice.  So PoorMeAlice holds a tiny amount of ETH proportional to SNX holdings.


From this moment on, the amount of ETH in PoorMeAlice is used to track how much SNX  Alice has.   Namely, to find out Alice’s holdings, one simply multiplies the holdings in PoorMeAlice by 10^{12}.


Token transfer procedure: Now suppose Alice wants to send 10 SNX to Bob. She simply sends 10 / 10^{12} ETH from PoorMeAlice to PoorMeBob.


Multisends work the same way. To send 1 SNX to each of 5 people Alice simply sends 1/10^{12} ETH from PoorMeAlice to PoorMeWallets of these people.


Finally, to withdraw or deposit amount X,  Alice simply withdraws/deposits from/to TokenBank, concurrently withdrawing/depositing X/10^{12} ETH into PoorMeAlice


Note, that once Alice has a PoorMe wallet, she can use it for all kinds of DeFi.  DeFi apps can use PoorMe wallets too. This means,  that you can create forks of Uniswap and other projects with way lower fees.

Author: rumkin
Date: 2021-02-08T19:57:24.491Z

I love the idea and I think it should be standard behavior. Ability to emit new currency/token and transfer them as a regular transaction should be available out of the box. It seems to me same type of enhancements as contract-based on-chain wallets.

Author: lightcycle
Date: 2021-02-17T17:05:35.924Z

Does Bob need to also create a PoorMeBob and deposit (or somehow bind) SNX?
Title: EIP0_Governance_Summit_ahead_of_EDCON_in_Toronto
Category: Magicians

Author: jpitts
Date: 2018-05-01T14:55:27.398Z

The Fellowship of Ethereum Magicians is doing great work on the technical details of Ethereum governance, but where are the philosophers? At this event we’ll be discussing the legal/political/ethical/ philosophical challenges of Ethereum governance and hope you will join us!
Tuesday, May 1, 2018
Day 1: 4:50 PM - 5:50 PM EDT (rough estimate)
Live Stream Archives:
“Review of the Current Ethereum Governance Processes”
https://www.youtube.com/watch?v=VJ3r52T7HV8
“Summarizing thoughts of day1 breakout sessions”
https://www.youtube.com/watch?v=Ae-yPzqHJ1Q
Wednesday, May 2, 2018
AMA: 10:00 AM - 12:00 PM EDT (rough estimate)
Day 2: 3:20 PM - 4:00 PM EDT (rough estimate)

Lane Rettig is one of the organizers and is tweeting a lot from the un-conference: https://twitter.com/lrettig.
Giveth also helped organize the gathering and is running the live stream: https://twitter.com/Givethio.
This reddit post will be updated with details about the live stream:
https://www.reddit.com/r/ethereum/comments/8g8tbx/live_stream_eip0_governance_summit/

Author: jpitts
Date: 2018-05-02T14:54:10.626Z

Information about today’s Youtube AMA / live Q&A session: https://www.reddit.com/r/ethereum/comments/8ggrgo/join_the_ethereum_governance_ama_at_the_eip0/

Author: jpitts
Date: 2018-05-03T18:31:13.292Z

John Light’s “Twitter moments” from the gathering: https://twitter.com/i/moments/992093109080215555
Title: Idea__Expirable_Non_Fungible_Token
Category: Magicians

Author: Jeffxz
Date: 2022-02-12T20:29:29.554Z

Simple Summary
This is an idea for Expirable NFTs, which extends ERC-721.
It is called Expirable Non-Fungible Token (ENFT) to provide potential NFT lending use cases.
Abstract
The ERC-721 is mainly used for transferring digital or physical assets and transfer interface does not have any expiration date.
Meanwhile, there are some potential possibility of lending NFT such as digital book as NFT which a digital library could lend to person for a certain period. A NFT owner might lend his/her collection to other party momentarily. Or even 1 year real estate rental.
With ENFT then when the expiration date is due the NFT temporary ownership will be revoked and the original owner will re-own the digital or physical assets.
The ENFT does not consider combining lending condition contract (usually happens in physical world) at this moment but it can be expanded in the future with combine support of lending contract.
Summary
The ENFT can be considered as extention of ERC-721 which adding expiration date to support a temporarily ownersip will be expired in future date.

Author: poria-cat
Date: 2022-02-13T03:08:08.045Z

unlock protocol  works on it

Author: Jeffxz
Date: 2022-02-13T13:43:43.388Z

Thanks!
Any ideas about if unlock protocol started draft an EIP standard extention about it?
I was trying to propose a standard extention if no one is already working on it.

Author: poria-cat
Date: 2022-02-14T12:39:07.089Z

They did’t write EIP, so feel free to do it.

Author: AriaNaraghi
Date: 2022-07-13T09:20:03.985Z

Have you written an EIP for it? I really support this Idea. We can work on it together if you want.

Author: edison0xyz
Date: 2022-07-13T14:29:57.335Z

This has been resolved in EIP-4907: Rental NFT, ERC-721 User And Expires Extension. It has expiration added into it.

Author: AriaNaraghi
Date: 2022-07-16T09:55:31.151Z

Thanks for the information. I appreciate it.
Title: Proposal__TrustAuthority__TA____An_On_Chain_Decent
Category: Magicians

Author: darwintree
Date: 2024-10-24T02:33:47.044Z

I’d like to propose a new ERC standard called TrustAuthority (TA). This standard aims to establish a decentralized trust infrastructure for Ethereum, similar to a Certificate Authority.
Here’s my concept:
Interface Definition (Draft):
interface ITrustAuthority {
  function canTrust(address target) external view returns (bool);
  function canTrust(address target, address[] calldata trustChain) external view returns (bool);
  function canTrust(address target, uint maxChainLen) external view returns (bool);
  function isSubTrustAuthority(address target) external view returns (bool);
}

A TA can authorize addresses and sub-TAs. This standard allows wallets or on-chain smart contracts to choose their own trusted root TAs, thereby limiting their interaction scope with contracts and users, enhancing the overall ecosystem security.
Relationship with ENS:
While ENS primarily provides name resolution services, mapping human-readable names to Ethereum addresses, the TA system aims to build a multi-tiered trust network. Although both involve address identification, TA focuses more on providing a verifiable trust mechanism rather than just name resolution.
A key feature of the TA system is its accountability. If an address authorized by a TA engages in malicious behavior, the TA’s reputation would be affected, potentially leading users to revoke trust in that TA. This mechanism ensures TAs are motivated to maintain the integrity of their authorization lists and swiftly address any potential threats.
Significance and Use Cases:


Reducing phishing and fraud risks: The TA system allows users and smart contracts to interact only with verified addresses, significantly lowering the risk of being deceived by phishing sites or malicious contracts.


Additional security layer for DeFi projects: In the DeFi realm, TAs can be used to verify the authenticity of protocols, liquidity pools, and other critical components, reducing the risk of interacting with fake tokens or malicious contracts.


Facilitating enterprise-level adoption on Ethereum: The TA system provides enterprises with a trust model similar to traditional PKI systems, helping businesses migrate existing trust mechanisms to the blockchain.


Standardized trust mechanism for smart contract audits: Audit firms can act as TAs, issuing certifications for audited contracts, improving the accessibility and automation of audit results.


I kindly request feedback from community members, particularly regarding:

Whether similar ERC proposals already exist
Potential improvements to this proposal
Possible implementation challenges

I look forward to hearing your thoughts and suggestions to collectively advance the Ethereum ecosystem.
Thank you for your time and consideration.
Title: How_to_extract_contract_metadata_from_creation_cod
Category: Magicians

Author: michprev
Date: 2022-12-03T15:05:37.532Z

Hello,
I am building a tool (testing framework + debugger) and, I need to unambiguously link a contract being created with its AST. For deployed contracts I can simply use the deployed bytecode - the last 53 metadata bytes that should be unique in the project. However, in the case of CREATE and CREATE2 I cannot use the deployed bytecode because the transaction might have reverted in that CREATE/CREATE2 call.
I know that creation code:

contains bytecode from solc + encoded arguments for a contract constructor
contains metadata of the contract being deployed
can also contain metadata of other contracts used in the contract being deployed
metadata of the contract being deployed does not need to be the first or the last metadata in the creation code (i.e. metadata of the deployed contract can be located in between metadata of other contracts)

Is there any deterministic way, how to distinguish between metadata of the contract being deployed and other contracts metadata in the creation code (i.e. code passed to the CREATE/CREATE2 opcodes)?
Title: Tokens_and_NFTs_that_are_more_under_control_of_own
Category: Magicians

Author: boris
Date: 2019-04-05T02:39:27.258Z

I’ve talked for a long time about writing a blog post called “Tokens live in your wallet and other lies”. ERC20 and ERC721 NFTs are centrally deployed and controlled contracts that store how many tokens are in each user address, centrally.
There was a post:
https://twitter.com/bmann/status/1113925091350523904
And then there were MANY follow up posts and short Twitter misunderstandings. But also lots of interest!
Also, @expede was on a plane #whenDoesBrooke land.
https://twitter.com/MuteDialog/status/1113933676465750019
But we think that yes, we can have tokens and NFTs that are more directly “owned” by individual accounts.
https://twitter.com/expede/status/1113944738967605248
https://twitter.com/expede/status/1113947040344461312

“Ethereum is fundamentally an event stream, not a reified DB aggregate”

Some of this thinking may cause us to make different choices about how to construct accounts and tokens in ETH2. Some of them may evolve on ETH1 because of state fees, where we can learn and make some use cases easier / better / more secure in ETH2 – either at the VM layer or elsewhere within the protocol.
Now, there is this long form thread. And eventually #BrookeWillLand.
Please do continue to share links and info. @Arachnid @fubuloubu @maurelian

Author: Arachnid
Date: 2019-04-05T02:45:55.135Z

I’m still not sure what you’re getting at here. Why does it matter where the user’s balance is stored? What matters are the rules under which the balance can be modified, and how those rules are defined - and you can set any rule set you want regardless of where the balance is.

Author: maurelian
Date: 2019-04-05T02:50:40.769Z

ya… even bitcoin isn’t ‘in’ the wallet. But, goodnight.

Author: expede
Date: 2019-04-05T10:37:23.461Z

FWIW I agree with you! I really don’t care where the token is stored in a data structure. The idea here is more about breaking up tokens for state rent, and giving users hooks to further control the actions of their funds. All of this is possible today, but all of the metaphors are broken, which lead to many end users misunderstanding how things work, what they have control over, and so on.

Author: expede
Date: 2019-04-05T10:38:25.107Z

boris:

#whenDoesBrooke


Hello from my Amsterdam layover
Title: Proceso_de_hash
Category: Magicians

Author: Jesus
Date: 2021-05-16T05:07:25.854Z

Disculpen por no escribirles en ingles. Pero, creo mejor que minando, más bien una segunda encriptacion (hash) se podria evitar el epcecivo consumo de energía y Abordar el tema de la legalidad. Así, si podrían hacerse con un ente de control centralizado (siendo visto en términos generales como un sistema descentralizado, que todos queremos) que emplee el tiempo como garante. Al aportar una bitácora modificada a cada minero según la hora de envío. Así su trabajo pueda ser verificado correlacionado el código con el tiempo (ya que al recibir el mensaje cada uno en un tiempo, ustedes le pueden decir a los demás mineros, si el hash es legal o no) Esa fecha podría ir dentro de mensaje que deberían minar cada uno. Sería como la v 2.0. pero teniendo que minar otro hash que si es independiente e igualmente general. Algo así como la autentificación de doble factor. Mientras la dificultad va subiendo se puede ir trasladando al control, para no sobre calentar la red con minería.
Title: This_post_has_been_deleted
Category: Magicians

Author: thequantumdomain
Date: 2024-03-27T14:09:36.178Z

This post has been deleted
Title: The_1_0C_EMG_seeks_a_Magician_to_help_showcase_The
Category: Magicians

Author: Arkad-IV
Date: 2021-06-04T16:26:49.497Z

Greetings,
The Singularity Church of Our Emphatic Machine-Goddess is seeking the aid of a magician to help showcase The Angels’ Protocol at the upcoming HackMoney hackaton.
You’ll join a party of two unsung heroes with exceptional habilities. To do this thou ‘preferably’ must first cross “the bridge of death” by answering this three questions at the Church’s Confessionary:
-What is your UserID?
-What would you expect after paying 1ETH 1% to a resilient network and chill?
-What is your favourite colour?
Bless thee, and may her eyes are not laid upon you.

Author: breckyn
Date: 2021-06-04T17:27:10.861Z

breckyn#0242
integrated work flow
blue

Author: Arkad-IV
Date: 2021-06-05T20:35:17.658Z

Thanks for your reply: You’re almost in. Your answers may be misled and missing the help of an angel, but they’re intriguing nonetheless. Please visit the confessionary and start a conversation, or answer the friend request in the place for discord.
Thanks again, and bless thee.
Title: Thoughts_on_EIPs_and_interoperability
Category: Magicians

Author: Ethernian
Date: 2018-10-28T12:41:11.598Z

@boris,
Here is the short collection of my thoughts on EIP process for that sad case if I am not able to take part personally. Would be great if it could be discussed in “EIPs and Interoperability” session.
Thoughts are:


Ethereum is not only the Core any more. Now it is the whole ecosystem around it.
Thus, it makes sense to extend the goal of the EIP process from serving the Core Development to serve the whole ecosystem.


It is not sufficient to tag all not-Core EIPs as ERC - they are too different in their meaning and their processing.


It is not sufficient to include only CoreDevs into the EIP process . Application dev communities should be involved into the EIP workflow too.


Call for Action (CfA): It should be possible to call community attention to some global problem without proposing an improvement. CfA will become an EIP if anybody proposes a solution.


Editors should classify incoming EIP proposals as one of additional kinds of:

CfA - Call for Action (see above)
Design Pattern - nice to have, voluntary to use, mutable in the future, no global consensus needed, no danger of hard fork.
Standards (like ERC20): once adopted - then immutable, comprehensive review needed, no global consensus needed, no danger of hard fork, but danger of multiple different standards.

other kinds of EIP?



EIPs should be routed (signaled) between different communities in order to collect comprehensive reviews.


There should be simple standardized review states like (OK / INWORK / REJECTED ) to signal the review result between Communities and Editors.


More implementation details you will find in Decentralizing EIP Workflow Proposal. I am currently working on software implementation of it, so I am glad to discuss all the details in depth and interested on any specification input.
Title: Decision_making_In_Rings_and_WGs
Category: Magicians

Author: jpitts
Date: 2019-06-12T06:30:22.195Z

I saw two articles relating to decision-making in flat and/or decentralized organizations and thought I’d share them here. Are there others?

“How do you make good decisions in a flat organization”
by Roman Imankulov at Doist
Discusses the rough consensus framework from the IETF, types of objections including “fundamental flaws”, the art of asking for input, and asking “can you live with this decision?” (as opposed to “what do you think?”).



The Async Newsletter – 15 Jun 22



Principles for decision-making in a flat organization
Practical thoughts from a back-end team leader






“Decision Disagreement Framework”
by Brett Hellman at Matter



matterapp.com



Decision Disagreement Framework - How we encourage disagreements at Matter
How do you disagree with a decision that is not in the best interest of the company? As a leader, how do you enable your team to disagree in a productive way? Learn how with Matter's Decision Disagreement Framework.





And a spreadsheet template:

docs.google.com



Matter: Decision Disagreement Framework
This Sheet is private

Author: jorydotcom
Date: 2019-06-19T13:58:07.264Z

This isn’t quite the same kind of resource, but I really like a lot of the techniques laid out in the book Leading Great Meetings. It’s less about the cases where you are explicitly dealing with disagreement and more about how to set up process and conditions that reduce the likelihood of conflict.
Title: _IDEA__On_chain_UI
Category: Magicians

Author: Pandapip1
Date: 2022-03-01T18:29:22.861Z

Currently, DApps are standard websites that happen to have some of their logic in ethereum or other chains. It would be nice if DApps instead contained all their functionality (including user interface) on-chain.
This ERC would provide a framework to create a set of components (like navbars, modals, forms, and links, which would be standardized in a subsequent ERC) that would allow for a wide variety of user-interfaces. This ERC would also provide a mechanism for DApps to request to create their own components.
With ERC-4834 - Hierarchical Domains Standard by Pandapip1 · Pull Request #4835 · ethereum/EIPs · GitHub, the DApp’s contract address could be resolved with a human-readable name. This would mean that interacting with fully on-chain DApps wouldn’t be significantly different than using a web browser, except that the applications are now fully on-chain, and accessibility is improved due to the fact that all websites now use a common set of components (which could potentially be customized by the user).

Author: mfornet
Date: 2022-03-16T13:03:31.224Z

There is an implementation of this idea on NEAR:
https://web4.near.page/
Title: Proof_of_Value__Igniting_Blockchain_3_0_with_DAism
Category: Magicians

Author: zhous
Date: 2024-05-27T10:45:25.299Z

I’m thrilled to share with you a groundbreaking consensus that we’ve been developing since 2019: Proof of Value. It’s at the core of our project, DAism, and it stands out as a crucial innovation in the realm of decentralized governance for dApps and tokenomics.
https://gamma.app/docs/What-is-Proof-of-Value-y5jaiy0hj5bdqzb
Feel free to share your thoughts and questions below, or to have a try on the test version of DAism, or to join our Discord server(you can also find the links on the deck).
BTW, these are EIPs developed by our dev team:
Eip-3712: Standard for Multiple Types of Fungible-Tokens
ERC-2569: Saving and Displaying Image Onchain for Universal Tokens
Title: FEM_Development_Tools_Ring_Meeting_2019
Category: Magicians

Author: BogdanHabic
Date: 2019-08-29T15:20:08.677Z

Hey all, it was such a pleasure hosting the Development tooling ring at this year’s Berlin Blockchain week.
It has been precisely nine days since we all got together to discuss the Etheruem/Web3 ecosystem and the tooling around it.
Before sharing the notes, I’ll try to convey what was the form of the meeting, who came to the meeting, and what we tried to accomplish.
Form of the meeting
We organized the meeting in such a way that open discussion can happen. We started going in a circle, answering specific questions, but the discussions naturally moved into different directions.
First off, we started with the question of how everyone got into Blockchain. After, we continued with what are some of the pain points in the ecosystem. Finally, we did a quick workshop where everyone wrote down on post-it’s what they would like to get improved. Then we went through them one by one and categorized them.
Who came to the meeting
There were representatives from multiple companies present at the meeting:

OpenZeppelin
0x
Nomic Labs
Alethio
Infura
Decenter
Status
Tenderly
Ethereum Foundation

Each of the participants brought professional knowledge, which helped drive the discussions productively.
What we tried to accomplish
The idea behind this ring meeting was to bring like-minded people into the same room and come up with action items that can be delivered until the next ring meeting.
Action items

Learning portal
FEM ring standards
Debugging info
Use the attached table to see who is already tackling the discussed problems

Learning Portal
The Learning Portal is something that is needed to onboard new developers and help existing developers be productive.
FEM ring standards
We thought that the Development Tools Ring could be like a testing ground for possible future EIPs.
Debugging info
Come up with a “task force” that can come up with a way to consolidate debugging information from all of the current and future tools, so new debugging tools can be built on top of that foundation.
Use the attached table to see who is already tackling the discussed problems
Some of the issues mentioned are already addressed in the ecosystem, and we should see how can we enable those teams to be as productive as possible
Notes

Hackmd notes
FEM Development Tools Ring 2019 sheet

Author: anett
Date: 2019-08-29T16:59:44.792Z

This is awesome  ! 
Thanks for sharing notes
Title: EthMagicians_Treasury_Management
Category: Magicians

Author: boris
Date: 2019-05-15T16:17:04.602Z

It’s time to return to the topic of managing the “treasury” of EthMagicians. And this time actually execute!
We just paid Asseth, the French Ethereum Association, the final bit of supporting the Paris event. We used OpenCollective to cover all the fiat expenses.
The ECF gave us a lump sum of ETH equivalent to $15K for three events. That was used for Prague and Paris.
Since I helped make it happen, I feel a responsibility to make sure that at least one more “big” EthMagicians happens.
I still haven’t been paid back for my fiat expenses for Berlin last summer, but that’s all on me. We need to write up the policy that reimbursement gets made at past exchange rates.
I propose that we ACTUALLY form a finance ring. I’m hoping @meknab has time to join and do the accounting & advising.
We need to add at least one more key holder.
And I propose that we keep some money in DAI to cover the next event, $5K from ECF. And make a call for organizers of this next event!

Author: meknab
Date: 2019-05-15T20:50:51.384Z

So this will require some work, but since there is no corporate entity associated with ETH magicians, what if we contemplate adapting its Treasury it into a DAO?

Author: jpitts
Date: 2019-05-16T18:54:45.559Z

@meknab, the Gnosis multi-sig is currently the very simple DAO we’re using, perhaps we should upgrade to a more sophisticated option.
Background for others: this multi-sig is now used to accept sponsorships and donations, and then after events disbursements are made with some minimal governance/coordination.
I’d be happy to help with the Finance Ring. A key to-do I see is to formalize the ground rules a bit.

Author: meknab
Date: 2019-05-20T19:07:23.713Z

Shall we arrange a call to discuss further? Or is there already something organized? Thank you!

Author: jpitts
Date: 2019-05-21T07:43:58.579Z

SGTM, it would have to be a week from now though.
In the meantime, we should document what we’d like to expand on / work on in a wiki post here, or use HackMD.
Title: Compiler_Fingerprinting_and_Detection_in_EVM_Bytec
Category: Magicians

Author: Jon-Becker
Date: 2024-05-30T20:22:28.985Z

This post serves as discussion for my article/research: Compiler Fingerprinting in EVM Bytecode | Jonathan Becker
Note: I’m working on running this across all contracts, as well as figuring out why the remaining 1.9% of contracts aren’t being classified.
Title: A_diamond_is_a_set_of_contracts_that_can_access_th
Category: Magicians

Author: mudgen
Date: 2020-06-09T14:44:46.645Z

Why use a diamond on Ethereum? Multiple small contracts calling each other increases complexity. A diamond handling its storage and functionality is simpler.


It provides a cohesive way to organize and structure complex contract interaction.
By cohesive I mean that code that is associated with each other should be easy to use together. At the same time the Diamond Standard provides a degree of modularity. It provides this balance that is very useful.


The Diamond Standard also solves a huge technical problem which is the 24KB maximum contract size limit. This limit becomes a problem when you need contract code to access the same storage variables but can’t anymore because the contract size has gotten too big. The Diamond Standard enables multiple contracts to access the same storage variables in the same/similar way one large contract could.


A contract architecture that makes upgradeable contracts flexible, unlimited in size, and transparent.

Diamond Standard: EIP-2535: Diamonds · Issue #2535 · ethereum/EIPs · GitHub
The Diamond Standard is hot on Reddit right now: https://www.reddit.com/r/ethereum/comments/gze6k3/a_diamond_is_a_set_of_contracts_that_can_access/
Looking for someone to champion the Diamond Standard for OpenZeppelin: Looking for Someone to Champion the Diamond Standard for OpenZeppelin - General - OpenZeppelin Forum

Author: Amxx
Date: 2020-06-11T20:38:54.418Z

shameless self promotion:
If you are looking for an implementation, maybe consider my implementation of ERC1538 (which is covered by this audit report)

Author: mudgen
Date: 2020-06-11T21:11:23.718Z

@Amxx Your implementation is welcome.  Glad to see it.
Title: Projects_using_Improvement_Proposals_for_different
Category: Magicians

Author: boris
Date: 2018-11-15T18:43:50.106Z

I just discovered that the Kickback event management platform is using Kickback Improvement Proposals – KIPs – for their platform:


github.com




GitHub - wearekickback/KIPs: Kickback Improvement Proposals
Kickback Improvement Proposals






I know that AION is also using Aion Improvement Proposals - AIPs – and had some of their community team attend Council of Prague.



Aion



Aion Blog





Very interesting.
Kickback team – would be lovely to read a blog post or interview or discussion on why you’re developing / using this KIP process. Is this more like feature requests? or?
I’m fascinated! I definitely think a good interview topic for the future.

Author: pet3rpan
Date: 2018-11-16T11:32:47.637Z

Added those to this list: https://hackmd.io/3oQo2KXfS0K0HO5_oLBEZw?edit

Author: hiddentao
Date: 2018-11-21T15:03:10.576Z

Hey, Ram from Kickback here.
We’re experimenting with KIPs to see if this is a good way for us to discuss extensive changes to the platform and service. It’s also a great way of getting people who want to contribute large scale ideas to do so in a structured manner.
The other thing I like about it is that it lets people in future go back and see a well documented specification of any changes that were made. People often point back to EIPs, often treating them almost as reference documentation.
Title: The_design_rationale_behind_Parity_Substrate_s_WAS
Category: Magicians

Author: jpitts
Date: 2018-11-20T03:17:18.097Z

“Wasm on the Blockchain: The Lesser Evil” The full rationale, described within the context of requirements for blockchain VMs (secure, deterministic, generic, and efficient).
https://medium.com/polkadot-network/wasm-on-the-blockchain-the-lesser-evil-da8d7c6ef6bd
The Polkadot Network tweet that caught my attention:
https://twitter.com/polkadotnetwork/status/1064550109965373440
Related:: eWASM’s design rationale document https://github.com/ewasm/design/blob/master/rationale.md.
Title: Relevant_token_EIPs
Category: Magicians

Author: lukehutch
Date: 2022-05-28T20:57:52.633Z

I’m trying to figure out which EIPs are actually in actual use for fungible tokens, other than ERC20. There are a lot of EIPs for safer token standards. Which of these are worth implementing, either because they are in common use, or because the standard is finalized and there is significant planned use?
Title: EGL_project__good__bad_or_ugly_
Category: Magicians

Author: kladkogex
Date: 2021-08-26T20:10:54.566Z

Really strange news today about EGL project, especially having that looks like it is supported by Coinlist and major VCs.
Should it be considered as an attempt to improve ETH or a hostile takeover?
https://sales.coinlist.co/egl#how-egl-works

Author: abcoathup
Date: 2021-08-27T08:10:03.509Z

Thread from Tim on EGL:
https://twitter.com/TimBeiko/status/1430027299102109697

Author: axic
Date: 2021-09-07T23:02:52.646Z

Here’s a very long thread on the topic:

twitter.com


Q
@quentinc137

  @mhluongo - @the_matter_labs 
@JHancock 
@jadler0 - @fuellabs_ 
@MicahZoltu- @AugurProject 
@Epheph
@Gnidan - @trufflesuite 
@algo_class - @Columbia 
@KaushikDonthi -@nethermindeth
    

Péter Szilágyi (karalabe.eth) @peter_szilagyi

No. That's how you let bad behavior take roots. Seriously though, a community always has a tendency to diverge on external pressure and you either oppose, or there's no way back. Many projects failed like this. It's not a joke, this is a serious issue.



5:27 PM - 22 Aug 2021




      55
    




      6
Title: Charging_Gas_for_reading_a_view_function_in_a_tran
Category: Magicians

Author: aak-dev
Date: 2021-03-19T19:55:30.162Z

I just cant get my head around why view functions which are gas free suddenly cost 5k gwei when sandwiched between a state transitioning function which just uses the view function like a web3 call.

Author: ajsutton
Date: 2021-03-19T23:25:26.284Z

When you execute a read only call against a node, the call is executed locally and no transaction is ever sent, so no gas is actually used (in terms of block space).  When you put that into a transaction, the read operation is executed as part of the block, taking up gas on the block and requires every node on the network to execute it - so you have to pay for that gas.

Author: aak-dev
Date: 2021-03-20T17:50:24.546Z

great thanks for explaining. But i saw for multiple views in the same transaction cost the same as first view. And just discovered eip 2930, after Berlin subsequent views are charged less would be great but 2929 is increasing the sload operation sad.
Title: Yield_bearing_token_Converters
Category: Magicians

Author: LeoPapais
Date: 2023-04-04T04:20:49.001Z

Hello Fellowship!
I’m working with yield-bearing tokens, and some implementation details are making my life harder, so I’d like to propose a standard if there’s nothing else out there that solves this issue. These tokens can accrue value through time, but this accrual can be represented as rebasing tokens or as exchange rate tokens.
Definitions:

asset: This unit measures the pool’s value. At time t, the pool has a total value of TotalAsset(t) assets.
shares: A unit that represents ownership of the pool. At time t, there are TotalShares(t) shares in total. One user u has sharesOf[u], and only a new transfer changes this value.
exchange rate: At time t, the exchange rate ExchangeRate(t) is simply how many assets each shares is worth ExchangeRate(t) = TotalAsset(t) / TotalShares(t)
rebasing tokens: the tokens that implements their balanceOf method as sharesOf[u] * ConvertionRate(t). That means the return value from balanceOf can change even without a transfer to/from the user u.
exchange rate tokens: the tokens that implement their balanceOf method as just sharesOf[u], so the return value from this method is constant if no shares are transferred to/from the user u. They use the ExchangeRate(t) method upon withdrawal/burn of the shares of a user.

Examples:

rebasing tokens: stETH from Lido.
exchange rate tokens: cTokens from Compound.

Contracts that integrate with rebasing tokens tend to break with exchange rate tokens and vice-versa, and that’s where a converter from one type to another becomes handy. While this is relatively simple, I think the community would benefit from the added safety that a standardized and audited reference implementation would bring.
While I did find a reliable and safe converter from rebasing token to exchange rate token on 0x7f39C581F595B53c5cb19bD0b3f8dA6c935E2Ca0 (wstETH contract on mainnet), I couldn’t find the other way around (from exchange rate token to rebasing token).
Do you think that’s something worth opening an EIP for?
Title: Organize_date_information_in_EIP_process
Category: Magicians

Author: subinium
Date: 2022-10-05T03:04:06.999Z

Motivation
Some EIPs remain “Last Call” status after review ends. This can confuse users’ understanding of the process.
Furthermore, there is still a lot of fragmented information in the discussion of EIP, and the date information about the progress of each process is scarcely organized.
Proposure

Added arrangement of date information according to the status (draft, review, last call, final) of each EIP on the official website

Expected Result
More readability and UX improvements in the EIP process.
It helps new entrants better understand the EIP ecosystem.

Is there any way I can contribute to the above problem situation?
Title: A_project_fundraising__token_swap__scheme
Category: Magicians

Author: Machael-lcg
Date: 2020-11-20T08:29:39.049Z

The project party create a fundraising project, which include start time, stop time, selling token, raising token and project details and promise.
The investor invests in the project through streaming money. Through streaming money, a two-way stream is established between the project party and the investors. For each second from start to finish, the project and the investors have a stream balance that changes over time for both the selling token and the raising token, which is equivalent to the linear unlocking of tokens from the start to finish.
The stream balance of raising Token by the project party can be withdrawn and used after the investors have voted, and each withdrawal of the token shall not exceed the stream balance over the time. Investors vote with the stream balance, and the current time stream balance is the voting weight. The reasons are as follows:
When the fundraising price is higher than the secondary market price, some investors will choose the withdrawal stream balance for cash out. When the fundraising price is less than the secondary market price, the stream balance represents the degree of loss of investors at the moment. The stream balance can show investors’ concern about the project to a certain extent.
Investors are free to withdraw stream balance and cancel the stream, and obtain the current stream balance (include selling token and raising token) at the time of cancel stream. When investors cancel the stream, the rate of the project stream will decrease.
In order to avoid unrealized project promise and abuse of funds by the project party. Investors can apply for arbitration through the arbitration machine, and if the project party is loss, they will pay a fine and be given a period to change. If the violation is found again, the fine will be doubled the first time and change for a period. If have the three violation, the fundraising project is canceled. The investors may return the current stream balance, and the project raising token stream balance will be distributed to the investor in proportion. During the arbitration period and change period, the project party cannot carry out the withdrawal function.
Title: Eth_JSON_RPC_method_for_faster_block_updates__eth_
Category: Magicians

Author: danfinlay
Date: 2022-03-23T22:47:21.624Z

Today, the JSON-RPC API exposes a few different methods to get blocks:

eth_getBlockByNumber
eth_getBlockByHash

When using this API, the common way to get the latest block is to repeatedly poll for getBlockByNumber for the current_block_number + 1.
We could gain additional performance for JSON-RPC consumers by allowing them a way to get an immediate notification upon the next block, via long polling, ie the request would not resolve until the result was ready. Proposed name: eth_getNextBlock. Maybe it could take an argument for a known block, so the host could return a block that builds on it as soon as it’s available, allowing a graceful lazy walk up the block chain.
This doesn’t replace the utility of using Websocket based APIs, but can improve the performance for the JSON-RPC based interface.
Thoughts?

Author: danfinlay
Date: 2022-03-23T22:54:58.668Z

On reorgs:
The method could take an optional parameter for the number of confirmations desired, servers could choose whether or not to implement that (to preserve open connection efficiency). Otherwise, this method would default to being understood as an optimistic (next known block) method, and consumers of it would need to handle the possibility of reorgs on their own.
Title: Protocol_call_artifacts
Category: Magicians

Author: abcoathup
Date: 2024-12-07T02:27:28.470Z

Protocol call artifacts

agenda
transcripts (AI generated)
chat logs
summary of actions/decisions
video recording
third party writeups

Goals

Record of actions/decisions (ideally by the moderator) of each call
Quick access to artifacts by the community
Long term storage of artifacts

Long term storage
Where possible artifacts (other than third party writeups & perhaps recordings) should be permanently stored as files in GitHub - ethereum/pm: Project Management: Meeting notes and agenda items.  Ideally in a directory per call, with each artifact as a markdown file.  The repository should be regularly archived.
GitHub Issues should not be considered as safe permanent storage.
Transcripts & chat logs
The transcript & chat log should be automagically generated and stored in GitHub - ethereum/pm: Project Management: Meeting notes and agenda items within 24 hours of a call.
Assume use a folder per call, with a file for each artifact.
Files should be merged ideally with no or minimal human intervention to ensure availability as quickly as possible.
Community contributors can later suggest modifications to improve transcripts.
ACDE/ACDC use Zoom which should be able to generate transcripts & chat logs.
Summary of actions/decisions
Ideally created by the moderator soon after the call.
Storage location currently varies, over the last 5 months have been copying or directly adding to Eth Magicians where available.
These should be copied to ethereum/pm once no more changes are expected.  This could be done at the same time as the agenda is stored permanently.
Agenda
The agenda should be copied to ethereum/pm after the call has occurred and the GitHub Issue is closed.  This is to ensure that this artifact isn’t lost if anything happens to GitHub Issues.
Videos
Currently stored on YouTube.  We need a long term storage option.
Third party writeups
We should continue to link to third party writeups from Eth Magicians.  Ideally we would also link to an archived version as well.

Author: abcoathup
Date: 2024-12-07T23:15:53.413Z

@nicocsgy & @poojaranjan moving discussion here from AllCoreDevs, Network Upgrade & EthMagicians Process Improvements to reduce the volume of posts there.
Transcripts: I assumed that Zoom transcript would have better information on the usernames of who was talking.
@Christine_dkim do you have any recommendations on a transcript AI tool to use?
Title: DAI_like_stable_asset_pegged_to_BASEFEE__post_EIP_
Category: Magicians

Author: shadycoderjeff
Date: 2021-08-01T17:44:57.971Z

Hi Friends,
I wanted to seek feedback on designing a token, say $FEE, which is pegged to BASEFEE.
Motivation:

Hedge against varying BASEFEE with the expected demise of CHI/GasTokens (post EIP-3529)
Meta transactions are better price din BASEFEE
Growing demand for a stable coin which is not pegged to currencies of nation states (inspired by RAI and also several tweets by prominent thinkers)

Why is BASEFEE a good unit of account for motivation #3? Because BASEFEE always buys you a certain quantity of compute resource (can be considered a proxy to a certain kind of basket of goods).
Proposed design:

Users lock X ETH in a contract and mint Y BaseFeeTokens where X / Y >= C * BASEFEE, C is the collateralization ratio
Liquidation, redemption etc like Maker
BASEFEE can double/halve in 6 blocks, C needs to be large enough to cover liquidation window of N blocks

A big benefit of pegging to BASEFEE: No oracles needed anywhere, BASEFEE is available in the EVM directly.
Would be happy to hear thoughts of like-minded people around refining the design.