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

Author: cleanapp
Date: 2023-05-08T15:33:48.842Z

hi all, xposting this from ethresearch – curious if anyone can point us towards existing WGs on this topic … ty mucho

L2 Economics of Daily Airdrops (Arbitrary Amounts to Growing Base of Players)
Title: Ethereum_stratum_mining_protocol_as_a_standard
Category: Magicians

Author: jpitts
Date: 2018-08-12T02:52:25.618Z

Stratum is used for mining pools.
NiceHash’s specification for Ethereum stratum mining protocol v1.0.0: Specifications/EthereumStratum_NiceHash_v1.0.0.txt at master · nicehash/Specifications · GitHub

Ethereum does not have official stratum protocol. It supports only GetWork, which is very resource hoggy as miners need to constantly poll pool to obtain possible new work. GetWork thus affects performance of miners and pools. Due to demand for more professional Ethereum mining, several versions of “stratum” for Ethereum emerged. These “stratums” utilize GetWork on server side (pool side) to obtain work, which would be fine, if careful considerations and precautions were taken when creating such protocols.

NiceHash May 2016 announcement: Stratum mining protocol for Ethereum — Ethereum Community Forum
Bitcoin’s Stratum Protocol: Stratum mining protocol - Bitcoin Wiki
Bitcoin’s getwork Protocol: Getwork - Bitcoin Wiki

Author: chfast
Date: 2018-08-12T19:26:25.124Z

The EthereumStratum is not the one used the most, but is the only one with any documentation.
I proposed a change to the version 1.0.0: https://github.com/nicehash/Specifications/issues/5.
Title: Ethereum_Governance_Survey_Results
Category: Magicians

Author: evabeylin
Date: 2019-08-01T17:44:13.663Z

In case you missed it, check out the results of the Ethereum Governance Survey. A lot of interesting insights were derived from the 282 respondents. Thanks to all who participated! 

Survey Results & Recommendations
Raw Data & Analysis

A few fun facts:

94% identify as a member of the Ethereum community
70% are token holders
45% work at organizations building on Ethereum
39% were not “in Ethereum” when The DAO hack occurred
51% hold more than 100 ETH
89% have used Ethereum-based dapps


84% support PoS for Ethereum
57% have attended Ethereum meetups
41% have attended Devcon
73% use CT to learn about Ethereum
66% use Reddit to learn about Ethereum
61% use Week in Ethereum to learn more
36% believe CT best captures the ecosystem sentiment

Hope the results are useful for future decision making processes in the Ethereum community!

Author: rumkin
Date: 2019-08-05T22:47:38.217Z

Interesting digits, next time I would like to see number of people who mostly use decentralized technologies in their daily life. Who completely declined using centralized technologies, etc. And which technologies  in the current stack they wish to be decentralized at the first place.
And one question. What is CT?
P.S. And thanks for Week in Ethereum.

Author: anett
Date: 2019-08-07T10:20:14.891Z

CT means Crypto Twitter

Author: rumkin
Date: 2019-08-07T16:40:42.069Z

Someone is too lazy to open links 
Thanks
Title: What_factors_may_have_been_blocking_efforts_to_sca
Category: Magicians

Author: jpitts
Date: 2018-12-20T19:23:10.706Z

This is a discussion stemming from @lrettig’s Hypothetical maximum scale of Eth 1.x.
I would like to create a strategic postmortem of sorts to discuss what was potentially blocking investment in upgrades to the current Ethereum. I chatted about this briefly with @lrettig last week and we’re curious to get more views on it.



Hypothetical maximum scale of Eth 1.x

Another import caveat: as @karalabe and @AlexeyAkhunov eloquently explained in their Eth 1.x proposals, any attempt to scale today will immediately exacerbate the state and storage size issues, so any meaningful scaling (of Eth 1.x or 2.0) is still blocked on that.


In my own reading of the 1.x proposals and recent Ethereum dev/release history, I get the impression that certain clear pathways to scale Ethereum were held back by awareness that any major improvement on mainnet would lead to an unsustainable run-up in state size.
For “strategic postmortem” reasons, what I’d like to know is: was state size the primary blocking issue on moving forward? Was it a wish to improve development processes in 2018, rather than work on forking changes? Or was it “Ethereum 2.0 has this”?
I think that @cdetrio, @karalabe, and @5chdn might be able to shed the most light on this, but we’d all be interested in any relevant perspective!
Title: Things_we_really_want_smart_contracts_to_implement
Category: Magicians

Author: jpitts
Date: 2020-12-14T20:14:45.311Z

I saw a couple of Tweets from Dan Robinson and thought it was a good idea to try to get people to contribute more. This is “best practices coming from the frustrations of developers and data consumers”.
Smart contract systems which make building a local state / database possible from events.
https://twitter.com/danrobinson/status/1338566170140581889
Non-standard ERC-20 tokens (antipattern)


twitter.com



Dan Robinson (@danrobinson) on X
@danrobinson

Building a non-standard ERC-20 token (such as fee-on-transfer or inflationary/deflationary balances) is one of the nastiest things you can do to smart contract developers, wallet developers, and users
Title: The_Lisinski_Tesnet_is_live
Category: Magicians

Author: Swader
Date: 2019-02-27T17:17:47.555Z

Hi all,
I’d like to formally announce the launch of the Lisinski Testnet. Inspired by Goerli and with Constantinople and Istanbul activated, Lisinski is a PoA Clique chain focused on Croatia (all validators are from here) because we want to grow and support the local ecosystem of eth devs with a good playground and hackathon support.
In spite of this, we’ve opened the testnet globally along with a faucet, rudimentary explorer and more, so you can just as well join in via RPC or even power up a node of your own and start hacking. It works perfectly fine on something as weak as a raspberry pi while the chain is this small, so please join us and break things.
We also support whisper, and will soon open up IPFS and Swarm nodes.
More information on why, how, etc. available at https://lisinski.online/en and you can come chat to us via Gitter and on our forum.

Author: boris
Date: 2019-02-27T17:22:54.900Z

Swader:

PoA Clique chain focused on Croatia (all validators are from here) because we want to grow and support the local ecosystem of eth devs with a good playground and hackathon support.


Super cool! Really fun to hear about this, thanks for sharing!

Author: Swader
Date: 2019-02-27T17:37:45.522Z

Thanks for the support!
Note that while validators are from Croatia and all our servers are (or will be) in Croatia (we don’t like cloud hosting and think it should be effectively blacklisted in the context of public blockchains), the testnet is intended to be used by all - we want “outsiders” because we want a rich ecosystem of smart contracts that can interact with each other, we want to test latency, etc. etc. All our documentation (forum posts, tutorials, website, etc.) will be bi-lingual, so there’s always going to be an English language version of everything, for practicality’s sake.
Next week we’re also launching an IBFT2.0 testnet, driven by Pantheon (the recently released Java client), so we can experiment with larger numbers of validators (20+ hopefully).
Lots of developments pending, so be sure to follow along!

Author: Alchemist33
Date: 2019-02-28T10:51:09.375Z

CRO ETH Community growing strong!

Author: ligi
Date: 2019-02-28T11:47:40.170Z

great! Please add your chain here: https://github.com/ethereum-lists/chains

Author: ligi
Date: 2019-02-28T11:54:32.005Z

does lisinski have a subway station?

Author: Swader
Date: 2019-02-28T11:59:45.050Z

Croatia is a 2.5th world country so no subways here at all, but we did name it Lisinski because it was formalized next to a public transit station (tram) that’s called Lisinski  Adding to chains
Title: Allowance___Unlimited__What_can_happen_
Category: Magicians

Author: Mr_Bamboo
Date: 2021-04-16T03:43:14.356Z

Hi,
let‘s say I approve via MetaMask that another address can spend an unlimited amount of ETH on my address.
What can happen? Can this address spend all my ETH without me approving it via my MetaMask?
Thanks!

Author: qizhou
Date: 2021-04-16T08:54:04.046Z

Yes, basically the address can spend your ETH (should be WETH since approve only applies to ERC20) as much as the address wants.
Title: Should_the_stake_value_of_32ETH_be_static_
Category: Magicians

Author: rkapka
Date: 2022-04-26T16:08:25.255Z

On December 1st 2020, the launch date of the Beacon Chain, the price of 1ETH was $582.44. This means that becoming a solo validator cost $18638.08. Right now the price sits at $2,861.09, which requires $91,554.88 to participate in the proof of stake mechanism. What’s the point of making it possible to run the blockchain on consumer hardware when nobody will do it at home anyway because they will be a part of a validator pool? Of course you can still run a node altruistically, but I doubt there are many such cases. What if the price of ETH reaches $10,000? $50,000?
I would like to understand why keeping the value at 32ETH is a good idea for the system.

Author: timbeiko
Date: 2022-04-26T16:24:16.289Z

The value is set based on how much overhead we can tolerate in the beacon chain. If the amount is lower, there are more cross-validator messages sent on the network. See here for an explainer.
Agreed we should keep trying to lower it, and some research efforts, such as Single Slot Finality might help here.
Title: A_idea_for_identify_contracts_in_the_private_chain
Category: Magicians

Author: xieyi1393
Date: 2021-05-01T06:45:38.065Z

When I was using the private chain, I have a idea that we can identify some contracts for special usage.
Such as identifying the ENS as “Private ENS”.
Then we can use the ENS without special configure it in wallet.
But for security,they can only use in the chain which using Proof-of-Authority.And the request should sent by the administrator of the chain.
I think we can allocate a pre-build contract.It did’t do anything in EVM but costs some ETH for gas to preventing attack.When we want to send a request to  identify a contract,we can send a transaction which  contains the address of the contract and its name to the pre-build contract.Then all nodes checks the permission of the sender of the transaction.If the check passed,then the node record the name of the contract.
What do you think?
Title: Interop_of_Digital_Assets_with_Residuals__L1_____L
Category: Magicians

Author: highlander
Date: 2022-03-04T23:12:32.095Z

The Layer 2 Working Group, an EEA - OASIS Community Project, would like to solicit feedback on one of its work items: Network interoperability of Digital Asset with Residuals.
Currently bridging digital assets such as ERC20 tokens or NFTs between networks (L1 ↔ L1, L1 ↔ L2, L2 ↔ L2, L1 ↔ sidechain), immobilizes the assets on the origin network and then instantiates them on the target network.
This approach works well if the digital asset has no associated business rules associated that infer rights or obligations to asset owners such as stable coins or simple NFTs. Examples of important digital assets that infer rights to the digital asset owner are residual payments/asset grants such as dividend-paying equities, bonds, annuities, asset-backed securities, digital assets with royalties, etc.
Unfortunately, such digital assets can currently not be transferred between networks because a transfer would break the connection between the asset, and the rights or obligations associated with it.
Given the importance of residual bearing digital assets in traditional finance and the emerging proliferation of DeFi assets that mimic traditional assets such as bonds or asset-backed securities while more and more value is locked in bridges and L2s, what would be possible solution approaches to this conundrum?
A first attempt has been made with the GPACT protocol and it is currently being standardized within the EEA Interop WG.
Very much looking forward to the communities feedback!
Andreas Freund on behalf of the EEA-OASIS Layer 2 Community Project.
P.S: If you are interested in the work of the Layer 2 WG, join our bi-weekly meetings, mailing list and slack channel.
Title: Discussion_about_the_technical_spec_of_the_EVM
Category: Magicians

Author: jpitts
Date: 2018-10-18T07:24:13.535Z

@CJentzsch tweeted about this important issue, and several people commented.

twitter.com



Christoph Jentzsch (@ChrJentzsch) on X
@ChrJentzsch

One of the strong safeguards of #Ethereum was/is one complete technical specification: The yellow paper. This virtue should be upheld and it should always be updated *first*. Every consensus relevant EIP should have a PR to the yellow paper including the full specification of it.









Initially the discussion focused on barriers to participation due to lack of formal background required to work on the Yellow Paper. @Arachnid commented:
https://twitter.com/nicksdjohnson/status/1052519469782880256
At one point @cdetrio mentioned the Jello Paper., “Human Readable Semantics of EVM in K”:


twitter.com



Casey Detrio (@cdetrio) on X
@cdetrio

@ChrJentzsch @nicksdjohnson The Jello paper is quite readable. Its generated from KEVM, which is an executable spec with comments. It can execute the consensus test suite, so just hit enter to cross-check for correctness. https://t.co/lS28XH20Fj









Do I hear the sound of a a ring forming?
https://twitter.com/greg_colvin/status/1052698448217235456

Author: jpitts
Date: 2018-10-19T09:06:05.026Z

Here is a related comment on reddit. I am interested in why @maciej believes the spec is “from EF”.

This is not a quality issue, it’s a communications issue. Parity is a 3rd party following technical specification from EF, we are less involved in writing it than Geth team is. The end result is that there might be hidden assumptions in the spec that not everyone outside of people involved in writing it are aware of. That’s just the nature of things, writing complex software is hard, writing technical specification for complex software is hard. That’s why we have a test net.

https://www.reddit.com/r/ethereum/comments/9onsei/parity_208stable_critical_constantinople_bug_fix/e7x6p96/

Author: maciej
Date: 2018-10-19T10:02:46.969Z

I honestly haven’t looked into the Ropsten issue much, and based my response there over a casual conversation I had over lunch. Thanks for clarifying things on Reddit!
Title: Global_NFT_URIs
Category: Magicians

Author: davux
Date: 2022-10-21T19:13:31.721Z

Hello,
TLDR:

urn:nft:<method>:<method_specific_identifier>

urn:nft:erc721:<chain_id>:<contract_address>:<token_id>



Longer version:
On the offchain-wide web, there is sometimes a need to refer to NFTs through a unique URI.
An NFT does have a uniqueish ID but that is normally very namespaced, typically internal to a smart contract for ERC721-based tokens. There is not a globally unique way to refer to NFTs, so people end up describing them or configuring them through multiple pieces of information (“the NFT of type ERC721 with ID xxx on contract 0xabc on the mainnet”) or, worse, through a centralized marketplace URL (no example here, out of decency).
To address that gap, a simple and standard approach would be to introduce URNs with an nft namespace, as described in TLDR#1 above. Basically, it’s urn:nft:<method>:<identifier>, where <method> is the type of NFT you’re working with, and <identifier> is an identifier that makes sense for that type of NFT.
As both an illustration and a serious proposal, ERC721 NFTs would be described as urn:nft:erc721:<identifier>, where identifier is <chain_id>:<contract_address>:<token_id>. See spec URL in TLDR#2 above.
Of course, it would be great to see proposals for the other types of NFTs out there.
Such URIs would be useful to improve interoperability in the NFT world, including marketplaces and wallets. Imagine copying your NFT URI from a marketplace and just pasting it quickly in your wallet to have it appear there.
Bold CTA:
I would really like to know your thoughts, here and/or in the repos’ issues.

Author: lambdalf-dev
Date: 2022-12-01T20:07:55.612Z

I like this idea a lot, one point of concern would be about maintaining uris and how to pay for the storage of the data that is referenced. This comes at a cost that oftentimes is not a one-time payment
Title: Why_not_just_use_AR_or_filecoin_to_solve_data_avil
Category: Magicians

Author: xiaolese1
Date: 2022-09-25T08:04:31.629Z

Since ethereum wants to be the data layer for Rollup, why not just build rollup in AR or Filecoin？
These two programs are focus on data aviliability. Every one can cheaply store data on AR or Filecoin.

Author: fewwwww
Date: 2022-09-26T01:49:10.590Z

Data availbility is not the same as data storage.
In my understanding, data storage solutions like them cannot make sure the data are available, and the checking of whether the data is available is not efficient, cause you need to download all data to see if they are stored.

Author: xiaolese1
Date: 2022-09-26T02:02:41.177Z

As I know, storage program will check that for you,  see if nodes stores your data as you wish, that’s the key point of Filecoin or AR or Crust. Filecoin use zk to prove and crust use TEE to sample check. I mean this looks like data aviliability check to me
Title: Regional_gatherings__templates__and_more
Category: Magicians

Author: boris
Date: 2018-11-01T13:49:17.188Z

At the Meta Magicians we had a number of people interested in having more regional events, creating a template, and in general ensuring that people can be successful in hosting more decentralized EthMagicians gatherings.
@tjayrush said he might look at doing something regional, talking to @fubuloubu & others.
I think we should create some action items, where the top one is “create an event template” as the high level item. Budgets, sponsorship, venue, etc etc. I’d like to suggest GitHub Issues to show who is taking ownership of items and sub items.
For fun — let’s see if we can pick a name?




Congress
Conclave
Camp
Coven
We don’t need one name
All of these are bad




0
voters

Author: pet3rpan
Date: 2018-11-02T08:33:25.735Z

Ethereum Magicians Sidechain
Ethereum Magicians Warcamp
Ethereum Magicians Rally
Ethereum Magicians Summit

Author: boris
Date: 2018-11-02T15:35:14.333Z

From the Stewart Brand talk - Jamboree! image4032×3024 987 KB
Title: Why_can_t_the_miners_pay_for_my_transaction_fee_
Category: Magicians

Author: ERC20s
Date: 2023-02-08T00:56:45.873Z

Let’s say I only want to sell 2200 DAI for 1 ETH.
Let’s say that the transaction will give a miner $100 in profit via MEV.
Why can’t I just put 0 gwei and let the miner find the transaction, pay my gweis and take the profit from the top?

Author: Alex-Klasma
Date: 2023-02-08T16:06:34.133Z

Already possible with some gas-less exchanges, like some 0x routes, CoW Swap, etc.

Author: matt
Date: 2023-02-08T23:20:47.658Z

To add on, since EIP-1559 started requiring txs to burn an amount of eth, it isn’t possible to move tx inclusion payment to another layer.

Author: ERC20s
Date: 2023-02-08T23:59:06.891Z

ERC20s:

Why can’t I just put 0 gwei and let the miner find the transaction, pay my gweis and take the profit from the top?


I guess I’m more just speculating on why this element isn’t implemented on the mainchain as a new EIP… I don’t see a downside for end-users…
It would make invaluable transactions like NFTs more expensive to transfer… And ERC20s more desirable…
Title: How_to_get_the_historical_floor_price_data__minute
Category: Magicians

Author: BabyBluez
Date: 2022-09-29T09:07:03.462Z

Through an NFT contract address and a timestamp in minutes, the historical floor price at that moment can be returned.
This floor price is the floor price listed in the market (like the floor price displayed by gem.xyz), not the sale floor price.
For example, the function of nftscoring.com is very good, and you can also capture its api address for querying historical floor prices, but it can only display historical floor price data within 30 days, and it does not have 1-minute precision.
nftscoring_fp893×624 65.5 KB
Many platforms have this function, but unfortunately, when querying historical floor prices for all time periods, the time interval for returning data is often hours or even days.
I have been trying for a few days to solve this problem. Happy to be able to ask questions here. I hope you can give me some pointers on what I should do, thank you very much.
Title: RC__Shout_Message_Hub
Category: Magicians

Author: trigun0x2
Date: 2018-07-23T22:19:34.657Z

Hello everyone,
I’m here to propose what I believe should be a primitive in the Ethereum ecosystem. Please note this is an still in ideation phase and I’d love constructive feedback from other smart people like yourselves.
Shout: a proposal for an open standard for smart contract to user notifications.
You can read the description here: Google Doc
Tldr: smart contract message send a message to the Shout smart contract. Off-chain services can poll from the smart contract for messages.
Here are my main areas of concern/discussion:

Events vs Storage
I chose to persist message so services like MetaMask do not have to replay previous blocks.
When to delete messages?
How can current smart contracts adapt to this standard?
Message schema: How can a smart contract pass dynamic data to the Shout contract?
Does this even belong as an EIP?

Author: boris
Date: 2018-07-24T13:03:12.900Z

Might be useful to look at @expede ‘s ERC  1066 as being related. In fact, you might support the message format in shout ERC-1066: Ethereum Status Codes (ESC)
Recent presentation here Lightning Talk: Ethereum Status Codes ERC 1066
ERCs for standardization “above” the token level are totally appropriate.
Welcome, thanks for contributing!

Author: trigun0x2
Date: 2018-07-24T17:00:15.088Z

Thanks a lot! ERC-1066 is something I’d love to incorporate into the contract! I’ve reached out to @expede to get her opinions on the idea.
Title: Vyper_fun__Chapter_1__Create_your_first_Pokemon
Category: Magicians

Author: vasa
Date: 2020-09-21T03:11:52.669Z

Vyper.fun is CryptoZombies+Ethernaut for Vyper where you can learn Vyper by building a Pokemon Game.
Chapter 1 goes through topics like:

Structure of a contract
State Variables & Integers
Math operations
Structs, Mappings
Function Declarations
External / Internal Functions
Public / Private Variables
Return values in Functions
Keccak256 and Typecasting
Events

Feel free to check it out and give us your feedback here: https://gitter.im/vyper-fun/lobby
Title: Sharding_format_blob_carrying_transactions
Category: Magicians

Author: vbuterin
Date: 2022-02-14T16:41:27.295Z

This thread is to discuss the sharding-format blob-carrying transactions pre-EIP:
https://notes.ethereum.org/@vbuterin/blob_transactions

Author: tynes
Date: 2022-02-28T04:19:11.292Z

During ETHDenver, there was some good progress made on implementing this. See

twitter.com



proto.eth (@protolambda) on X
@protolambda

At @EthereumDenver we hacked together a full data-blob-transaction prototype! (a.k.a. mini-danksharding)

Data blobs are the first milestone towards full ethereum sharding, enabling rollups like @optimismPBC to grow 100x in capacity.

Here's a tweet thread about the prototype 🧵









The code contains a file that is responsible for creating a trusted setup, see go-ethereum/cmd/kzg_dummy_setup/main.go at a922276f31f130a83493a0406bae345ec1e19324 · protolambda/go-ethereum · GitHub
The implementation of the code that generates the trusted setup is here - _github.com/protolambda/go-kzg/blob/master/setup.go (can only post 2 links per post so evading the linking). Its not super complex code, but I am curious about how this trusted setup could be expanded to be multiparty and also have a 1 of n security model, where there only needs to be 1 participant that doesn’t defect for the trusted setup to be secure. Is that possible and what does the math look like for that?
Title: Proposal_for_a_new_decentralised_Layer_2_rollup_pr
Category: Magicians

Author: Obscuro
Date: 2021-12-06T19:44:57.653Z

Hi all,
I’m Cais, a member of a team of engineers who have been working on decentralised systems for the past few years.
We propose a new Ethereum Layer 2 Rollup protocol designed to achieve data confidentiality and prevent MEV by leveraging hardware-based Trusted Execution Environments.
We call it Obscuro.
Below, you will find the Abstract of the paper.
The full draft whitepaper, including the pdf, can be found at https://whitepaper.obscu.ro/ .

The design of Obscuro ensures that hardware manufacturers do not have to be trusted for the safety of the ledger. If one manufacturer turns malicious or there is a breach in the TEE technology, the protocol falls back to the behaviour of a public blockchain that preserves the ledger’s integrity but makes the transactions public. This situation will lead to a partial liveness failure because the withdrawal function will be suspended.
The design also focuses on preserving privacy for the limited period when it matters most, which removes the need for a privacy technique that is robust against all adversaries in perpetuity.
Obscuro sits in what we believe is a sweet spot between the existing rollup-based L2 offerings: Optimistic and ZK Rollups. The use of confidential computing techniques coupled with economic incentives allows Obscuro to retain the performance and programming model simplicity of Optimistic rollups, and on top of that attain confidentiality, short withdrawal periods, and address MEV.

Other notable differentiators introduced by Obscuro:

a new decentralised fair sequencing protocol called: “Proof of block inclusion” (POBI).
a dependency mechanism between L2 rollup blocks and L1 blocks to achieve quick deposit periods.
reasonable withdrawal delays, limited only by censorship resistance concerns.
a transaction reveal mechanism configurable per smart-contract.
support for the EVM.
a novel incentive and fee mechanism.

We are very keen to get feedback from the Ethereum community.
I’d welcome any questions or discussion here.
Title: Discourse_features_and_configuration
Category: Magicians

Author: boris
Date: 2018-07-22T11:58:57.918Z

I was having a discussion on Twitter with @Ethernian about how we may very well need some form of “moderation” here at some point. I put that in quotes because it could mean a number of things.
https://twitter.com/Ethernian/status/1020992398837547008
This site runs Discourse. It has lots of features — some through configuration, some through plugins.
I have suggested that we use the Scrolls rep issues to file requested changes or updates.
This #site-feedback category can of course be used for general discussion, but issues can help us keep a log of major changes.
Title: Review_the_Pull_Request_for_the_EthMagicians_Donat
Category: Magicians

Author: boris
Date: 2018-09-28T17:07:42.554Z

Hey all –
Brendan Asselstine pushed a Pull Request to the EthMagicians donations page
The preview is here: https://zen-shirley-5f0272.netlify.com/
Please leave comments on the Github thread https://github.com/ethereum-magicians/donation-leaderboard/pull/2
We can have extended discussion here on messaging / content and create additional issues. @caspar @pet3rpan @mariapaulafn @jpitts in particular to have some eyes on this.
Thanks Brendan!
Also: @jpitts at some point my write access got revoked (with EthMag organization?), so I can’t approve the PR. I would suggest that if it’s you, me @ligi then 2 of 3 should review PRs. And that goes into larger governance discussion too, of course.

Author: jpitts
Date: 2018-09-28T19:12:48.880Z

@boris, I have re-invited you. It seems as if there may have been some kind of reset in which you dropped all of the Fellowship “teams” on GitHub in which you were a member.

Author: boris
Date: 2018-09-28T20:30:10.370Z

Thanks. Maybe GitHub like Twitter thought I was a scammer too!

Author: pet3rpan
Date: 2018-09-28T21:11:55.337Z

Will take a look over the weekend.
Title: Ideas_about_anonymous_meta_transactions
Category: Magicians

Author: suenchunhui
Date: 2018-11-23T01:41:30.225Z

I would like to seek opinions on good ideas for doing meta transactions while maintaining privacy on the identity of the user?
Main reason is to allow B2B activities where buyers, sellers and possibly financiers can move tokens around or interact with smart contracts, but do so using ephemeral addresses that are one-time use to protect privacy, and known only for the duration these parties are interacting with each other. This is particularly important because leakage of identity can create unfair advantage in an open buy/sell market.
How can we keep privacy, while bringing in the UX conveniences of meta-tx?
My current idea involves embedded meta methods directly into the ERC20 token, but i’m not sure if that’s a good approach?

Author: pet3rpan
Date: 2018-11-23T04:30:12.508Z

You might benefit from watching the recent metacartel community call. We talked quite a bit about anonymous meta transactions https://www.youtube.com/watch?v=x8RPeH0OjCc

Author: suenchunhui
Date: 2018-11-23T12:50:00.535Z

hi @pet3rpan, Thanks for the video link.
I’m not sure of the username of Ali who presented about anonymous meta tx, but I do have a question on that…
Does it mean that the technique have a similar semi-privacy guarantee to UTXOs in bitcoin? Since the origin address will be revealed during a coin transfer, so all spent transaction can be traced to form a transaction graph (but not future unspent ones)?
Its an interesting technique nonetheless.
Title: Active_Banking_Project___P2P_Lending
Category: Magicians

Author: dbernardis
Date: 2019-04-03T11:40:10.681Z

Hello Everybody,
Davide from Berlin here. I am a creative director with experience in multimedia communication.
I wrote this concept inspired by an experience volunteering at Tunapanda Institute in Kibera, Nairobi. The project aims at building a P2P landing platform running on ethereum to support individuals and communities in developing countries by granting them access to financial opportunties and a tokenised reputation system. I am completely independent and my only interest with regard to this initiative is to reach out to who could highly benefit from this- especially individuals and communities in developing countries.
As I am not a developer (or know any); I am not backed by any institution; and I am definitely not rich - I am facing obvious limitations to move out of concept phase. After talking to Ken from ETH Foundation who told me about The Fellowship- I thought about getting in touch with you directly to see if there’s anybody out there kind enough to give me feedback on this.
I apologise in advance for my lack of tech literacy and I sincerely hope to hear from some of you soon.
Best,
D

Author: jpitts
Date: 2019-04-03T16:01:04.199Z

Thank you for posting @dbernardis! Could you please update your post and summarize your PDF as best as you can?
Many people will not click on the link without more information, so a summary will help.

Author: dbernardis
Date: 2019-04-03T16:39:08.908Z

Thanks! Just edited a short description in the post
Title: On_chain_contract_metadata_registry
Category: Magicians

Author: ligi
Date: 2019-09-11T12:27:14.295Z

anyone knows about a on-chain contract metadata registry? I imagine a registry contract where deployment keys of other contracts can publish metadata. The registry should support swarm and ipfs hashes. With metadata I mean ABI, contract source, icons, contact options,  …
I really do not want to start another project currently - so asking if perhaps already people working on such a thing. Could really use it now and think I am not the only one.
Perhaps leveraging dType (cc @loredanacirstea)

Author: rumkin
Date: 2019-09-13T11:15:19.008Z

https://www.ethpm.com/
Don’t know much about this project. Only know they are working on a solution.

Author: ligi
Date: 2019-09-15T16:15:36.163Z

Thanks for the hint! I knew about the ethpm manifest part - was not aware of the on-chain part. Looks like this is going in the right direction - just not sure about the “multiple registry” part - with this (as far as I see) we would need a registry of registries …

Author: rumkin
Date: 2019-09-16T05:38:41.251Z

Why IPFS and Swarm? It increases technical debt on management. Not sure if regular users are ready to support both networks. For me Swarm is not an option at all. It requires to have an Ethereum node to setup, what makes the whole process overcomplicated. In the same time IPFS requires no setup, just download and run.
Am I missing something? I’m planning to build a package system into a browser and decided to refuse Swarm and to use IPFS instead.

Author: ligi
Date: 2019-09-16T16:13:29.108Z

swarm would be nice for availability guarantees in the future. Currently e.g. I could not retrieve some IPFS links in some of the ethpm registries. If noone pins them then this is a problem.
Also swarm would be great as e.g. some links in evm bytecode are swarm-hashes. Another reason is that one would not have to run 2 different p2p networks. A lot of reasons to (also) support swarm - but I agree practically IPFS seems to work a (bit) better currently…

Author: rumkin
Date: 2019-09-16T16:52:06.931Z

Guarantees? Could you elaborate? Does it mean that EVM code will be able to check hash existence, or write data directly to swarm?

Author: gh1dra
Date: 2019-11-21T02:51:15.275Z

@ligi After iterating on a few different approaches for an on-chain registry, I just wrapped up hacking together this: https://github.com/gh1dra/eth-metadata-registry.
Should have the functionality you’ve specified, would love any feedback/suggestions you may have! Also interested in how dType could leverage this as well. Next steps would probably be to create a dapp to present everything nicely

Author: ctzurcanu
Date: 2020-02-04T14:56:11.529Z

@ligi  dType has this covered since March - April 2019: EIP-1921: dType Functions Extension
With this, we can call any registered function while inside the EVM (just by knowing the dType id of the function and providing the correct input). Many other features (including function search) will be demoed soon  .
Title: EIP0_Summit___Statement_of_intent_to_support_Ether
Category: Magicians

Author: jpitts
Date: 2018-05-09T17:15:00.676Z

https://medium.com/eip0-summit/eip0-summit-statement-of-intent-to-support-ethereum-governance-initiatives-e54ff782933

The signers of this public statement commit to supporting one or more of the following next steps:

Work on a statement of shared values of Ethereum
Support and build open source tools to collect key signals and metrics
Host a monthly governance call
Organize a second #EIP0 Summit
Title: Notifying_members_of_a_ring_and_ring_colors
Category: Magicians

Author: ligi
Date: 2018-07-25T08:42:16.841Z

#1 Is it possible to notify members of a ring - e.g. of an upcoming event/gathering/video call?
#2 Currently all rings have the same color (brown) - is it possible to assign colors to the different rings?
Selection_100658×244 18.7 KB
Would be happy with black or red or green for the wallet ring.

Author: boris
Date: 2018-07-25T13:04:48.364Z

It’s a category not really a group. People can set preferences and “watch” a category in their email preferences but that’s not really the same thing as being a member.
There IS a groups ability, too, but that would mean Ring Makers have to actively manage group membership. We may want to do that to show Wallet Ring members, AND you can @-mention groups which notifies all the users. This probably needs a tracking Github issue if we want to go this direction.
Yes, colours are possible.
Title: Istanbul_Hard_Fork_Community_Call
Category: Magicians

Author: anett
Date: 2019-11-29T13:49:27.052Z

Istanbul%20HF%20CC%20thumbnail%201280×720 984 KB
Istanbul Hard Fork is about to happen. Magicians decided to call it out and invite Ethereum Cat Herders and Community to join the community call about Istanbul Hard Fork.
We would like to let the community know how Istanbul Hard Fork will affect the Ethereum ecosystem. Let the community ask questions and chat about Hard forks that happened in the past.
Moderator @anettrolikova
Hosts @souptacular @poojaranjan @MadeofTin and more
 Date and Time
DATE: Wednesday 4th of December
TIME : 2pm UTC 
 Location
Zoom: Available only to hosts
YouTube Livestream Link
Agenda:

Welcome
intro into Hard Forks - what are they, effects of HF on the ecosystem … (briefly)
Previous HF - briefly recap the HF that happened and how they affected & changed the ecosystem
Istanbul HF - what EIPs are included (mention EIP-1884), how this update will affect the ecosystem, what changes it will bring

Post your questions to this thread, they will be most likely answered on a call.

Author: MadeofTin
Date: 2019-11-29T13:52:35.637Z

Would it be a good idea to post this on the reddit to ask for questions people would like answered?

Author: souptacular
Date: 2019-11-29T14:04:53.173Z

Yes that’s the plan

Author: anett
Date: 2019-11-29T14:41:42.302Z

Oh, I’m not a fan of Reddit so I don’t have enough karma to post it on Reddit.
Can someone please post it on Reddit and post link to this thread please

Author: tjayrush
Date: 2019-12-02T22:19:51.534Z

I didn’t know who to contact otherwise, but I was looking at this page Ethereum Istanbul Upgrade Announcement | Ethereum Foundation Blog which announces the coming hard fork, and I thought this question:

What happens if I am a miner or node operator and I do not participate in the upgrade?

With this answer:

If you are using an Ethereum client that is not updated to the latest version (listed above), your client will sync to the pre-fork blockchain once the upgrade occurs. You will be stuck on an incompatible chain following the old rules and you will be unable to send ether or operate on the post-upgrade Ethereum network.

Could be expanded to explain how to recover from this situation. I don’t think it’s that hard (someone can correct me). I think they just have to upgrade even if they missed the fork, so perhaps a sentence something like:

If you do get stuck on the incompatible chain, you can simply upgrade your client and it will catch back up to the correct chain eventually.

A little mini EIP.

Author: poojaranjan
Date: 2019-12-03T15:10:37.154Z

I think it is visible on Reddit, at least I can see it. https://www.reddit.com/r/ethereum/comments/e3fa42/istanbul_hard_fork_community_call/

Author: anett
Date: 2019-12-13T12:02:11.441Z

Thank you all for an amazing call  !
We are looking forward to do more similar calls in the future 
For those who missed this call, it was recorded. The recording is available on YouTube
Title: Requesting_feedback_on_Yellow_Paper_Shangai_update
Category: Magicians

Author: pldespaigne
Date: 2024-05-25T14:36:54.024Z

Hi everyone!
I’ve created a PR to update the Yellow Paper to Shanghai, unfortunately it has been stuck for more than 3 weeks now, because maintainers currently don’t have the bandwidth to review it.
If you have some time and are used to the YP formalism, I would really appreciate that you give me some feedback on the PR.
In a more general subject, and because I’m panning to implement Cancun update next, it could be great to also discuss of ways to better maintain that repo.
PS: I’m not blaming the maintainers here, they are probably understaffed and have many other things to handle.
Title: Fork_safe_tokens
Category: Magicians

Author: Pandapip1
Date: 2023-02-24T20:33:50.149Z

This is an extremely rough draft of an idea I recently had.
Since the CHAINID opcode exists, tokens can store the balance per chain ID. Before a hard fork, users can transfer their assets to the new (un)forked network. This would be different than bridging the tokens, as the new network doesn’t exist yet. Instead, when the new network is formed, the balance is split so that the total supply across all chains remains unchanged.
This would be particularly useful for stablecoins like DAI, because it would get around the problem of “we can only support one network since the supply doubles every hard fork.”
Prototype interfaces:
contract ERC20ForkSafe is ERC20 {
    event TransferFork(uint256 fromChainId, uint256 toChainId, address indexed from, address indexed to, uint256 amount);
    function transferToFork(uint256 fromChainId, uint256 toChainId, address to, uint256 amount) external;
    function transferFromToFork(uint256 fromChainId, uint256 toChainId, address from, address to, uint256 amount) external;
    function isTransferAvailable(uint256 fromChainId, uint256 toChainId) external view returns (bool);
}

contract ERC721ForkSafe is ERC721 {
    event TransferFork(uint256 fromChainId, uint256 toChainId, address indexed from, address indexed to, uint256 tokenId);
    function transferToFork(uint256 fromChainId, uint256 toChainId, address to, uint256 tokenId) external;
    function transferFromToFork(uint256 fromChainId, uint256 toChainId, address from, address to, uint256 tokenId) external;
    function isTransferAvailable(uint256 fromChainId, uint256 toChainId) external view returns (bool);
}

contract ERC1155ForkSafe is ERC1155 {
    event TransferFork(uint256 fromChainId, uint256 toChainId, address indexed from, address indexed to, uint256 tokenId, uint256 amount);
    function transferToFork(uint256 fromChainId, uint256 toChainId, address to, uint256 tokenId, uint256 amount) external;
    function transferFromToFork(uint256 fromChainId, uint256 toChainId, address from, address to, uint256 tokenId, uint256 amount) external;
    function isTransferAvailable(uint256 fromChainId, uint256 toChainId) external view returns (bool);
}
Title: Universal_CREATE2_wrapper
Category: Magicians

Author: fare
Date: 2021-03-07T19:16:30.262Z

I have some use cases, including generalized state channels and verification challenges, where any of many users may want to create the contract to be verified, in the same spirit as Bitcoin MAST. CREATE2 almost gets us there, but annoyingly includes the creator address as part of the data getting hashes, which runs against the “the same contract binds everyone principle”. Lo and behold, this can be worked around by a contract that has this runtime code:
GETPC DUP1 CALLDATALOAD 32 CALLDATASIZE SUB DUP1 32 DUP5 CALLDATACOPY DUP3 CALLVALUE CREATE2 STOP

Now, I could create this contract on the Ethereum network, but wouldn’t it be nice if it had the very same address on every EVM network, so we could have universal MAST addresses? Well, that’s possible, thanks to presigned transactions: I generated an address, had it sign transactions to create the above contract with all possible values of gas on an geometric sequence of ratio sqrt(2), then threw the address away, so the same addresses can be used everywhere. It would be much nicer of course, if a precompiled contract did the same, but this is good enough for now.
https://gitlab.com/mukn/glow/-/wikis/|Universal-CREATE2-wrapper

Author: fare
Date: 2023-02-28T00:05:33.093Z

This is very useful for State Channels, wherein you know the terms of the contract, but don’t want to publish it in advance (for both scaling and privacy reasons), and especially do not know which of the participants will have to publish it because the other one fails to cooperate. Can we make it happen?
Title: Question__multi_token_economies
Category: Magicians

Author: Ethernian
Date: 2019-08-05T23:12:03.904Z

Hello Magicians,
Is there any patterns how to create a workflows spawning many projects with multiple independent tokens effectively?
we all have to pay gas with eth while sending tokens (2 token economy), which is already a pain.
But (just for example) what if I would like to create a transaction paying referrals with BAT which should send some other tokens like (MKR+DAI) to close a CDP?
Any convenient patterns known?
UX friendly, atomic, flexible to combine…
Thanks!
Title: Standards_for_a_consent_token
Category: Magicians

Author: EricForgy
Date: 2022-04-23T18:49:39.098Z

Hi everyone,
I did a cursory search and didn’t find a discussion on this topic, but if I missed anything, references would be appreciated 
I was inspired by Evin’s ETHDenver talk:





I’ve been busy working on something else, but this has been running in the back of my head since ETHDenver.
ERC-20, ERC-721 and ERC-1155 all contain some form of approval in order to allow the transfer of tokens out of an owner’s account.
After listening to Evin’s talk, I was wondering if a new “Consent” standard might make sense.
Consent would be dual to approval. In a consent model, you would need to give consent before anyone can transfer a token to you. The idea is that a token transfer can, in some circumstances, be a form of harassment. I think this is more of an issue for women and under-represented demographics. I know I had never even thought of this problem that some people face until Evin’s talk. I think a consent standard would make sense and am curious what others might think.
I’d be happy to help draft a more formal proposal if there was interest.
Take care,
Eric

Author: mukas
Date: 2022-04-23T21:53:22.916Z

I think it’s a good idea!
It solves a problem that at least has happened to me and my acquaintances, which is having the wallet full of a lot of advertising or misleading tokens in which if you try to claim them they crack you, so it seems like a good idea to me.
Greetings

Author: ra-phael
Date: 2022-04-25T17:01:15.939Z

Yes!
This notion of requiring consent is part of my proposal for non-transferable ERC1238 tokens: EIP-1238: Non-Transferable Tokens
For an EOA, the issuer would ask for a signature from the recipient which could be displayed in a nice way, using EIP-712. It’s one small extra step affecting UX but a reasonable price to pay to avoid harm to someone’s reputation.

Author: streamerd
Date: 2022-06-12T10:19:15.022Z

Hey @EricForgy  and @ra-phael , I was also thinking of the same one, part of the standard.
Also would like to see that development in multi-signature wallets, so incoming transactions can be collectively approved/rejected before them landing to the account.
haven’t yet finished reading them all however, would u consider also elaborate and contemplate further on this aspect on your proposals as well?
maybe in terms of account types, along with the various asset type 
in case there are works in progress around this, and as well for collaboration, please let me know.
I’d start another EIP, but would join another work group if such efforts already placed somewhere else rn.

Author: TimDaub
Date: 2022-06-13T10:24:31.075Z

In EIP-4973, we’re also working on a function mintWithPermit that shall allow collecting the consent of both the from and to accounts via signatures. We’re exploring how EIP-712 can help us with that and @ra-phael’s ERC1238Approval has been helpful. More details here in the “Right to Mint” section: Addressing the most common misconceptions about Account-bound tokens
Title: So__Is_this_really_a_part_of_eth_
Category: Magicians

Author: criminalteddy
Date: 2023-01-02T01:16:19.862Z

Okinami token, okinamitoken on Twitter claims to be a token connected to the Ethereum Surge. It has characteristic traits like connection to Genesis & Russell Verbeeten on Etherscan. Theories are it could be a zk rollup. Is this real or yet another scam rug?
Thank you.
@vbuterin @timbeiko

Author: abcoathup
Date: 2023-01-02T23:43:31.522Z

Ethereum Research – 2 Jan 23




So. Is this really part of eth?

Anyone can claim that they are building a rollup, they may also deliver or not deliver on their claims.  Their website doesn’t appear to make any claims and is just a link to their token with an unspecified purpose.
Title: Potential_EIP__Dynamic_target_gas
Category: Magicians

Author: SirSpudlington
Date: 2025-05-02T22:14:58.332Z

Instead of having a blocks target gas fixed to be exactly 1/2 of the gas limit of a block. What would happen if every 8192 epochs we take the average gas price for the last 8192 epochs and if it’s below (with some margin) a certain constant g we decrease the gas target by 1/1024 if it’s above, we increase it. This will prevent gas prices being too high/low for extended periods but keep them able to react short term. Maybe also adding a hard max limit of 3/4 of the gas limit.
Edit: After doing some math, it appears that this has the opposite effect, making it 10x more unstable.