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

Author: jpitts
Date: 2018-06-26T06:26:45.341Z

Below is a link-fest relevant to Ethereum UX. Also, this effort is a good example of standards work in action:
https://medium.com/coil/standardizing-payments-with-the-payment-handler-api-1bb8cefa702d

Here is the implementation overview for Chrome:



web.dev


Web-based payment apps overview  |  Articles  |  web.dev
Learn how to adapt your web-based payment app to work with Web Payments and provide a better user experience for customers.






This is a discussion on “Mozilla standards positions” regarding cryptocurrency support with Payment Request API. Provides some insight into how other dev communities regard cryptocurrencies.

github.com/mozilla/standards-positions








Cryptocurrency support with Payment Request API



        opened 05:13AM - 26 Mar 18 UTC


          closed 10:28AM - 03 Apr 18 UTC




          marcoscaceres
        







## Request for Mozilla Position on an Emerging Web Specification

* Specificat…ion Title: Payment Request
* Specification or proposal URL: https://github.com/w3c/payment-request/pull/694

### Other information
The Payment Request API currently only checks that monetary values passed into it adhere to the ISO4217 currency format: ASCII 3-alpha (e.g., "USD", "EUR", etc.). However, the spec doesn't ask the browser to check if those are "real" (fiat) currencies - which would be possible by checking against ISO4217 itself (maintained and updated by ISO). 

There is a proverbial elephant in the room around cryptocurrencies, such as "BTC", which, although they conform to the ISO4217 "currency format", may or may not be "real" currencies. 

Recently, [Facebook](http://www.bbc.com/news/technology-42881892), [Google](https://www.cnbc.com/2018/03/13/google-bans-crypto-ads.html), and soon [possibly Twitter](https://www.theverge.com/2018/3/18/17136556/twitter-cryptocurrency-ads-bitcoin-ban-report), have banned advertising crypto currencies in their platform due to high levels of fraud. 

When using the Payment Request API, I personally fear that by not checking if a currency is registered with ISO (as a "real" currency), we might subject Firefox users to fraud. For instance, a website might insist that you can only buy things with a particular crypto currency (or [similar scams already seen](https://www.theverge.com/2018/3/8/17096128/twitter-vitalik-buterin-elon-musk-cryptocurrency-scams)).  

What I'd like to propose is that, at a minimum, all currencies (including cryptocurrencies) be first blessed by ISO before they can be used with the Payment Request API. Coincidently, [ISO is exploring](https://en.wikipedia.org/wiki/ISO_4217#Cryptocurrencies) the possibility of formally registering cryptocurrencies. This would be a minimum level of due diligence that would be required to use a currency.

Opinions? Is this something we (Mozilla) should push for in the spec (e.g., "if it's not in ISO4227, throw a RangeError." )? Or maybe just an assurance we implement into Firefox? 

Opinions would be appreciated.
Title: Yellow_paper_corresponds_to_wasm_IL__and_execution
Category: Magicians

Author: u59149403
Date: 2025-04-24T22:19:02.400Z

Yellow paper corresponds to wasm IL, and execution spec to wasm AL
Webassembly recently adopted SpecTec: SpecTec has been adopted - WebAssembly . In short, this is machine readable description of wasm, which is used to generate all other artifacts: human-readable spec, reference interpreter and definitions for Coq/Rocq! (Note: “reference interpreter” part is not finished yet.) Here is an analogy: this is as if we had single machine readable text, which is used to generate both yellow paper and python execution layer spec !!!  From that news article: “it [SpecTec] takes Wasm to a new level of rigor and assurance that is unprecedented when it comes to language standards… One feature that sets Wasm apart from other mainstream programming technologies is that it comes with a complete formalization… it enabled the soundness of the language — i.e., the fact that it has no undefined behavior and no runtime type errors can occur — to be machine-verified before the first version of the standard was published”.
We definitely can learn a lot from Wasm approach.
Note that SpecTec is declarative, similarly to Yellow paper. During processing, it is converted to so-called IL (see diagram at SpecTec has been adopted - WebAssembly ), which is declarative, too. But then this IL translates to AL (again, see diagram). And this AL is algorithmic/executable as opposed to declatative. I. e. this AL is similar to our execution specs. Again: IL is yellow paper, and AL is execution specs.
Thus, if we adopt wasm approach to bytecode specification, then we can generate both (declarative) yellow paper and (algorithmic) execution specs from same source!

Author: u59149403
Date: 2025-04-24T22:23:34.534Z

ping @RenanSouza2 , @pldespaigne , @shemnon
Title: Constrained_Resource_Clients__Next_Ring_Meeting
Category: Magicians

Author: dominic
Date: 2019-07-10T07:30:09.092Z

Hi Guys,
it has been some time since the last quarterly update on constrained resource clients. It would be great to get together again and check on progress and discuss the different topics. In this Augusts ETHBerlin there might be a venue to do that in person.  I’ll be there on 24th and 25th. Let me know if anyone of you is there.
Best

Author: anett
Date: 2019-07-10T10:43:42.159Z

you guys can gather together during hacking on ETH Berlin Zwei
@ChainSafe @tvanepps @rossbulat @shazow @zsfelfoldi any thoughts on this ?

Author: shazow
Date: 2019-07-14T15:23:47.303Z

Good call, we should definitely get another update thread.
I won’t be at ETHBerlin alas. I might be at DevCon though!
If you do hold a meeting, would you be up for taking notes and sharing it here?
If that doesn’t happen, then I’ll setup a fresh update thread on September 3rd or so.

Author: dominic
Date: 2019-07-15T05:02:53.396Z

I would b happy to take notes. Let’s see whom we can find to join. I think slock.it got an office in Berlin, so @CJentzsch might join?

Author: anett
Date: 2019-07-15T17:23:40.461Z

We will be organising Council around Devcon 5 too 
Yes, we will be taking notes and share therem

Author: rossbulat
Date: 2019-07-16T13:51:29.440Z

Thanks for suggesting anettrolikova, I will be around Osaka for Dev Con 5, although I will not be in Berlin. I am not sure how I can contribute here.

Author: ligi
Date: 2019-07-16T23:22:46.314Z

also won’t make it to the Berlin council (too bad as I usually live there - but it collides with chaos communication camp) - but hope to make it to the osaka council.

Author: shazow
Date: 2019-08-13T17:11:31.794Z

Unfortunately my travel plans had to change last minute, so I won’t be around during the main DevCon days in Osaka, but I will be in Japan for 2 weeks preceding it! If people are around before, I’d be happy to plan around meeting before the conference.

Author: anett
Date: 2019-08-14T12:30:02.010Z

@shazow What about organising a remote meeting ? setup a call session, make a notes… remotely, without need to meet as it’s very hard to coordinate people to one location

Author: shazow
Date: 2019-08-14T15:49:34.326Z

We have done that in the past, can certainly do it again.

Author: smcsicardi
Date: 2019-08-15T13:56:05.455Z

We are not going to Berlin or Tokio, so we would love to join to the remote meeting!

Author: shazow
Date: 2019-09-05T18:57:16.324Z

I started a fresh update thread, please post updates or any recent advancements that are relevant.  Constrained Resource Clients: September 2019 Update
Title: How_to_get_community_involvement_in_your_Magicians
Category: Magicians

Author: jpitts
Date: 2018-12-14T06:38:00.627Z

I wanted to get some feedback on this idea I had, what do you think about having a single page on the wiki which can help volunteers find tasks and mini-projects they can work on?
This list would be broken down by Ring or upcoming Gathering, and indicate who to contact, plus allow an indicator of when a task has been picked up by someone.
Example:

 Wonderful Things You Can Do To Help Out 
Operations Ring Tasks
Contact: @jpitts
Mini Project: “Gather Rings and Contacts from Prague”
In a HackMD, list out all Rings and other groups who gathered in Prague, see if any are not listed in the Scrolls or in the Forum under Working Groups. Reach out to those involved in unrepresented Rings from Prague and see if they want to keep it going here on the Forum or organize in upcoming events. Help these Rings get formed.
Council of Paris Tasks
Contact: @tomislavmamic
Mini Project: “Rings In Paris”
Reach out to each of the Ring contacts listed in the wiki and see who is likely to gather in Paris, and what they might need. Create a wiki topic on the Forum listing these Rings and Contacts out.
See notes from a recent call: Council of Paris meeting notes - HackMD

Author: AtLeastSignificant
Date: 2018-12-14T18:29:38.509Z

Would be nice if we could integrate it with this: Community list of "shit-to-do" - Google doc of chores, tasks, things to be done

Author: jpitts
Date: 2018-12-14T18:55:53.080Z

Yeah I should start with updating this doc, get the Rings to update it too, then find ways to promote/position it prominently.
I am finding that there is a general issue with “findability” of key resources, so also thinking about how to improve that.

Author: boris
Date: 2018-12-14T20:08:23.893Z

I still think teaching people how to use Github Issues is the right way to go. We need flow and movement on issues – not another list.

Author: jpitts
Date: 2018-12-14T20:33:39.222Z

That is a good point, and we can encourage a nice feedback loop. A lot of it is visibility I think, and forming habits.

Author: pet3rpan
Date: 2018-12-15T10:39:39.838Z

It definitely requires some pushing and poking + communications (@jpitts good to see that you have picked up the github issue on a welcoming post into the magicians)

Author: jpitts
Date: 2018-12-18T08:47:40.614Z

I created a larger project for energizing the Rings.
https://github.com/ethereum-magicians/scrolls/projects/5
Much of the project involve reaching out to Ring contacts, helping RIngs use the Issues, and bringing attention to “pickup tasks” with a special GH page which is promoted.
Title: Idea___minting_one_billion_NFTs_or_2_256
Category: Magicians

Author: sciNFTist.eth
Date: 2022-11-04T20:00:06.280Z

Abstract
minting arbitrary number of NFT can be done in one transaction using efficient data structures.
quoted from EIP-2309:

This allows for the original Transfer event to be emitted for one token at a time, which in turn gives us O(n) time complexity. Minting one billion NFTs can be done in one transaction using efficient data structures, but in order to emit the Transfer event - according to the original spec - one would need a loop with one billion iterations which is bound to run out of gas, or exceed transaction timeout limits. This cannot be accomplished with the current spec. This extension solves that problem.

Motivation
Since EIP-2309 provide more scalability of the ERC-721 specification, It is possible to create, transfer, and burn 2^256 non-fungible tokens in one transaction.
this changes provide a pragmatic way to mint arbitrary number of token in constructor with O(1) time complexity.
Specification
for in depth implementation see the eip-draft_ERC721FancyMint

preOwner is the creator/receiver  address
maxSupply is desired(<= 2^256) number of token to create .

solution

assign maxSupply to preOwner _balances in constuctor().

_balances[preOwner] = maxSupply ;


emit ConsecutiveTransfer for maxSupply token creation in constructor()

emit ConsecutiveTransfer(0, maxSupply -1, address(0), toAddress);


consider ownerOf() implementation as described bellow


/**
     * @dev See {IERC721-ownerOf}.
     *openZeppelin V 4.7.0
     */
    function ownerOf(uint256 tokenId) public view virtual override returns (address) {
        address owner = _ownerOf(tokenId);
        require(owner != address(0), "ERC721: invalid token ID");
        return owner;
    }

define _ownerOf() as
function _ownerOf(uint256 tokenId) internal view virtual returns (address) {
        address owner = _owners[tokenId];
        if (owner == address(0) && (tokenId < _maxSupply)) {
            return _preOwner;
        }
        return owner;
    }


Rationale


this standard considers tokenIds from 0 to (maxSupply - 1)
and _ownerOf() handles owners for every tokenId in this range.


if a tokenId in this range has default value in _owners mapping that is 0x0 (i.e. address(0)) it returns preOwner address.


since we have populated _balances[preOwner] with maxSupply at first blanceOf(preOwner) returns maxSupply and as the tokens keep transferring it reduces _balances accordingly. so the behavior of balanceOf() doesn’t change.


as tokens keep transferring from preOwner the _owners default value changes to new address instead of 0x0 so _ownerOf() returns the new address.



EIP-2309 introduces the ConsecutiveTransfer event that make this possible.



Batch token creation
emit ConsecutiveTransfer(1, 100000, address(0), toAddress);

EIP draft
eip draft is proposed at ethereum-magicians here. and you can see reference implementation for more details. I wish to hear your thoughts.
Title: EIP_improvement_survey
Category: Magicians

Author: edsonayllon
Date: 2020-04-24T00:33:26.459Z

Hello. If you have been currently or previously involved in the EIP process, please make sure to fill out the EIPIP survey if you haven’t already. The survey can be found here.
Edson Ayllon
Ethereum Cat Herders
Title: Adding_StateRoot_OP_to_EVM
Category: Magicians

Author: adamskrodzki
Date: 2018-09-30T07:36:32.212Z

Hi everyone,
below is thing I found missing in EVM
Like Now there exist
BLOCKHASH
Geting the hash of one of the 256 most recent complete blocks
there should be:
BLOCKSTATEHASH
returning stateRoot same way BLOCKHASH returns hash
That would allows for much easier on-Chain merkle proofs of former state of a blockchain
Example usecase On-Chain Voting that do not require token locking and still prevent multiple votes with same tokens
Title: _IDEA__Upkeep_Extension_for_EIP_1155_Tokens
Category: Magicians

Author: Pandapip1
Date: 2022-03-02T16:23:24.370Z

Currently, all existing token standards have no upkeep cost. This ERC would provide an extension to ERC1155 that introduces an upkeep cost (that can be paid in any number of ways - potentially even more NFTs!). If it isn’t paid, ownership of the token will change to a particular address. This could allow for a greater commission for creating NFTs, or fun concepts such as a “pet” that needs “food.”

Author: Bschuster3434
Date: 2022-03-02T23:50:55.807Z

That’s an interesting idea. Perhaps it can be revoked if the maintenance isn’t paid, kind of like a forfeiture. Or if someone else pays the maintenance it can be owned by them.
I can see a loan structure working like that.

Author: Pandapip1
Date: 2022-03-04T13:04:04.829Z

Perhaps it can be revoked if the maintenance isn’t paid

I was thinking that it could just be sent to the null address if it is to be burned, or the contract owner if it is to be re-sold.
This could be implemented by having the balanceOf function take the latest block’s timestamp (or number) into account.

Author: ravachol70
Date: 2022-03-08T15:45:50.305Z

That’s not dissimilar to basic demurrage. I fully support this concept; in fact, I think the principle should apply to the base token, i.e. ETH itself.

Author: mukas
Date: 2022-04-12T02:41:11.666Z

What a simple yet interesting idea!
And what if we expand it and make the maintenance of the token or asset can be between several?
For example, the purchase of a property between partners or sharing an account on an online content platform such as Spotify or Netflix…
Greetings
Title: Standard_For_Specific_NFT_Owned_Smart_Contracts
Category: Magicians

Author: mnkhod
Date: 2022-06-14T10:34:07.883Z

This idea has been formed around NFT’s having more utility. I truly believe more utility would come forth to the NFT ecosystem if Smart Contract ownerships can be enhanced with Specific NFT’s.
Instead of having Address Ownership like the one we use from OpenZeppelin’s Ownable contract , i believe there should be a standard for Smart Contract NFT Ownership.
Allowing smart contracts to be only accessible by certain NFT holders will bring more utility to the NFT Ecosystem. Truly bringing more innovation to Smart Contract Wallets or Business Logic related smart contracts & allowing NFT holders to have more utility rather than flipping all day long
NFT holders are incentivized to hold their NFT than flipping them.
Having this standard will incentivize developers to create more innovative smart contracts that utilizes NFT’s
I believe this can be achieve & i will also be including an implementation soon on this thread.


github.com


OpenZeppelin/openzeppelin-contracts/blob/v4.6.0/contracts/access/Ownable.sol
// SPDX-License-Identifier: MIT
// OpenZeppelin Contracts v4.4.1 (access/Ownable.sol)

pragma solidity ^0.8.0;

import "../utils/Context.sol";

/**
 * @dev Contract module which provides a basic access control mechanism, where
 * there is an account (an owner) that can be granted exclusive access to
 * specific functions.
 *
 * By default, the owner account will be the one that deploys the contract. This
 * can later be changed with {transferOwnership}.
 *
 * This module is used through inheritance. It will make available the modifier
 * `onlyOwner`, which can be applied to your functions to restrict their use to
 * the owner.
 */
abstract contract Ownable is Context {




  This file has been truncated. show original

Author: riksucks
Date: 2022-08-04T21:28:19.528Z

Hello @mnkhod !
I am new here, so pardon me if I do anything out of place. I think this indeed is a good idea. Right now the stuff that are being done when it comes to “membership” stuff using NFT is tokengating. Which is mostly frontend/backend. But not on chain.
I believe, an upgradation of AccessControl by openzeppelin can be made that is based around owning a certain kind of NFT or any sort of FT. Maybe even generalize it and make it for ERC-1155.

Author: urataps
Date: 2023-05-05T07:30:34.732Z

Hello this idea looks interesting and I’ve been thinking about it for a long time. I’m glad somebody else also thought about it.
But, the whole idea behind NFTs is that they are unique, so if a smart contract is an NFT then there should not be allowed any delegatecall to it, since that would copy the smart contract entirely.
Also another problem, NFTs are controlled by the ERC721 specification, therefore NFT owned smart contracts should be deployed via a Factory that is ERC721, so at each NFT mint a new contract is deployed. But again, how the Factory gets this implementation and how unique it is at each mint.
Title: Ephemery_project__An_ephemeral_testnet
Category: Magicians

Author: remyroy
Date: 2022-11-30T22:35:51.030Z

Ephemery is a new Ethereum testnet project with the goal of creating a testnet that is ephemeral and that resets every few days or weeks. Our goal is to create a testnet that is well suited for testing a staking setup before going on Mainnet but also for any use case that does not need long-lived and durable storage.
We are looking for genesis node operators, testers who want to setup different client pairs, people to create and help with documentation and developers who want to start implementing this in Ethereum clients, wallets and all the tools generally used with an Ethereum network.
This is somewhat related to the https://ethereum-magicians.org/t/testnet-workgroup-paths-out-of-the-goerli-supply-mess as being one solution to the staking use case.
You can get a glimpse of the current iteration of the Ephemery testnet on https://ephemery.pk910.de/.
If you want to setup a node to connect to that testnet, we have the genesis state being published on GitHub - pk910/test-testnet-repo with some scripts to help with the reset step.
Get in touch to get involved in the project. We have a chat room on https://matrix.to/#/#staker-testnet:matrix.org to reach us.

Author: remyroy
Date: 2023-02-28T01:05:21.579Z

The main repository for this is on GitHub - taxmeifyoucan/ephemeral-testnet: Resources and project management of Ethereum ephemeral testnet
Title: A_new_Ethereum_address_Avatar
Category: Magicians

Author: tyevlag
Date: 2021-07-04T01:38:13.000Z

At present, I know that the existing address avatars are based on certain random rules
For example, two different addresses A and B may have completely different avatars, which are random
When people see a avatar, it’s easy not to know the address of the avatar
Based on this, I think of a more intuitive way to understand the head image information:
0xe626E8ca82603e3B44751f8562B5ED126d345140128×128 883 Bytes
The image is divided into three parts


The upper left corner is the text area, showing the first two characters of the address


The lower right corner is the text area, showing the end of the address 2 characters


The red part is the random area


There are some considerations:


The text area may also have random components, but the text content can be clearly seen


The random region can be in any way


As for ens, there may be more special display methods (for example, the top left corner is the first three characters of the ENS address, and the bottom right corner is a special picture)


Benefits:
Can intuitively know which wallet belongs to from the picture
There may be a ready-made solution, but I don’t know? Please let me know. Thank you

Author: wighawag
Date: 2021-07-10T06:35:19.833Z

I like the idea of adding the first and last 2 characters of an address as part of the address icon.
By the way I built an alternative to the blockie for ethereum address : https://mandalas.eth.link/
Instead of using randomness, it use the address value itself to populate the bitmap, making each mandala completely specified by the address, ensuring no 2 mandalas can be same.
On top of that it repeats the values 8 fold, making easier to visually differentiate 2 mandalas.
The shape of mandalas would accomodate the corner well too.
But blockie while not flawless, are part of ethereum it seems and not sure how to go about using an alternative
Title: Sub_categories_in_Boxes
Category: Magicians

Author: boris
Date: 2019-01-10T05:49:34.814Z

I was searching for something else and came across a Discourse option to display sub-categories in boxes.



Discourse Meta – 17 Mar 17




Display boxes for subcategories above topic list




Documentation





Site Management






how-to





🔖 This guide explains how to display boxes for subcategories above the topic list in Discourse.  🙋 Required user level: Administrator (or moderator if the moderators manage categories and groups setting is enabled)   There are two ways to display...

Reading time: 1 mins 🕑
Likes: 41 ❤






Might be something to consider for Working Groups / Rings.
cc @pet3rpan
Title: ProgPoW_Benchmarked__by_a_Ethereum_Miner_
Category: Magicians

Author: xazax310
Date: 2019-03-27T23:14:09.279Z

Please read and discuss. I hope I brought some facts into the ProgPoW debate that we can make informed decisions from.
https://medium.com/@infantry1337/comprehensive-progpow-benchmark-715126798476?source=friends_link&sk=8acbe3fb45ef704a20dc09c87a5890a8
Title: Expedition_now_shows_top_miners_stats__block_gas_u
Category: Magicians

Author: stev
Date: 2020-01-09T20:56:25.440Z

Expedition, the open-source EthereumStack block explorer, has new features!

Top miner stats for Ethereum Classic https://expedition.dev/stats/miners?network=mainnet and Ethereum https://expedition.dev/stats/miners?network=ethereum

block gas usage meters
paginated transaction list on address view
https://twitter.com/shanejonas/status/1215341463535439872?s=20
Title: Updating_Ethereum_Magicians_Categories___Late_2022
Category: Magicians

Author: jpitts
Date: 2022-11-17T18:13:44.573Z

@matt has some ideas about improving our categorization to better separate core EIPs from ERCs, this topic is to track this set of changes for late 2022.
Also, for reference, this is similar work done in 2021: Updating Ethereum Magicians Categories - 2021

Author: abcoathup
Date: 2022-11-18T00:47:22.138Z

I think it would be good to split EIPs and ERCs.
A subcategory for linking from EIPs in the repo to discuss would be good, with templates suggesting what to post.

Core EIPs

EIP discussion


ERCs

ERC discussion
Ideas
Title: Krypton___P2P_solution_for_accessing_mobile_wallet
Category: Magicians

Author: per1odical
Date: 2024-07-31T13:44:10.947Z

Krypton is an open-source solution for allowing DApps to have a “wallet connection” but instead of relying on a 3rd party for the whole communication it uses libp2p and WebRTC to have the Wallet connect directly to the DApp.
There is a basic “protocol” for getting identities, exchanging metadata about both peers and requesting a signature which could really become a community EIP for methods that a wallet should support for an open standard.
Please feel free to give any feedback you have and contributions are more than welcome 


github.com




GitHub - per1odical/krypton: P2P solution for accessing mobile wallets from...
P2P solution for accessing mobile wallets from desktop applications.
Title: Vyper_fun__CryptoZombies_like_interactive_learning
Category: Magicians

Author: vasa
Date: 2020-09-02T15:18:43.741Z

Hey everyone!
Recently I started learning/exploring Vyper. As the Vyper community is still growing, we can benefit from some interactive learning resources.
A famous learning resource for solidity which has trained a lot of solidity developers is Cryptozombies. So, it would be a good idea to have a similar resource for Vyper.
Hence I started https://vyper.fun.
I’m looking for:

Contributors

Suggestions on Chapter topics. Right now my plan is to start with a Pokemon game: collect, breed, upgrade, battle, and trade pokemon.

Author: vasa
Date: 2020-09-02T15:19:21.089Z

You can also hop on our gitter.
Title: Single_Signed_Approval_Flow_Using_ApprovalTarget
Category: Magicians

Author: Bakuchi
Date: 2022-03-28T06:23:07.127Z

Here is a draft proposal for monkeypatching EIP-2612 support on ERC-20. This is by no means a complete proposal.
Summary
ApprovalTarget is an immutable contract that accepts token approvals from users across various ERC-20s, then enables anyone with a valid user signature to transfer those tokens. You can think of it like monkeypatching EIP-2612 support on all ERC-20 compliant tokens.
Abstract
To use ERC-20 tokens in dApps, approving is needed, which is expensive.
Design a ApprovalTarget contract to create a single signed approval flow for ERC-20 tokens. This allows users to send approval transaction only once.
Motivation
EIP-2612 allows abstraction in the ERC-20 approve method. But some of ERC-20 tokens do not have a permit function. Introducing ApprovalTarget indirectly allows approval by signature for all ERC-20 compliant tokens.
In addition ApprovalTarget replaces approve transaction with a signed approve and will improves UX.
Specification
ApprovalTarget has three functions.
function nonces(address owner) external view returns (uint)

function PERMIT_AND_TRANSFER_FROM_TYPEHASH() external view returns (bytes32)

function permitAndTransferFrom(address erc20, address owner, address recipient, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s) external

The semantics of which are as follows:
For all addresses erc20, owner, recipient, uint256s value, deadline and nonce, uint8 v, bytes32 r and s, a call to permitAndTransferFrom(erc20, owner, recipient, value, deadline, v, r, s) will call transferFrom(owner, recipient, value), increment nonces[owner] by 1. If and only if the following conditions are met:

The current blocktime is less than or equal to deadline.
erc20 is not the zero address. this address must be ERC-20 compliant token address.
owner is not the zero address.
nonces[owner] (before the state update) is equal to nonce.
r, s and v is a valid secp256k1 signature from owner of the message:

NOTE: spender in the provided signature must be the same as msg.sender. recipient isn’t attested by a signature from owner, and is instead chosen by msg.sender, attested in the signature as spender.
If any of these conditions are not met, the permitAndTransferFrom call must revert.
keccak256(abi.encodePacked(
   hex"1901",
   DOMAIN_SEPARATOR,
   keccak256(abi.encode(
            keccak256("PermitAndTransferFrom(address erc20,address owner,address spender,value,uint256 nonce,uint256 deadline)"),
            erc20,
            owner,
            msg.sender, // NOTE: spender
            value,
            nonce,
            deadline))
))

where DOMAIN_SEPARATOR is defined according to EIP-712.
In summary the caller of the permitAndTransferFrom function must be spender. spender can choose recipient.
Rationale
The spender is not provided in permitAndTransferFrom paramters. If spender is not msg.sender, the transaction will revert.
The recipient is provided by not the owner but the spender. So, the recipient isn’t attested by a signature.
More details here GitHub - massun-onibakuchi/approval-target
Title: F_star_name_for_Consensus_Layer_upgrade_after_Elec
Category: Magicians

Author: abcoathup
Date: 2024-06-13T02:14:41.458Z

Update:  All Core Devs - Consensus (ACDC) #140, August 22 2024 decided on Fulu as name for consensus layer upgrade after Electra with the combined Fulu + Osaka upgrade named as Fusaka (suggested by @bbusa)
ACDC naming discussion recording : https://www.youtube.com/live/hSNJ6vURfmE?t=3555s

An F-star name is needed for the Consensus Layer upgrade after Electra.
Assumes a cross layer upgrade combined with  Osaka having Verkle as the main feature.

Ethereum Improvement Proposals


EIP-7607: Hardfork Meta - Fusaka
EIPs included in the Fulu/Osaka Ethereum network upgrade.





The consensus layer uses star names for upgrades whilst the execution layer uses Devcon cities.
See: Post-Merge Network Upgrade Naming Schemes
Recent upgrade names:

 Shapella (Shanghai + Capella)
 Dencun (Cancun + Deneb)
 Pectra (Prague + Electra)

@protolambda has already suggested Fosa (Felis  + Osaka)
@hwwang advised that Fulu & Felis received support in the ACDC zoom chat (yet another reason why ACD chats need to be exported) and offered ChatGPT-generated proposals
Assuming a cross layer upgrade, any F-star name will be combined with the execution layer name Osaka in a portmanteau (Portmanteau generator), so any name choice should also consider this.
https://portmanteaur.com/?words=Fulu+Osaka
Fulu Osaka
fusaka, fosaka, fuka, faka, fulusaka, fulosaka, fuluka, fulaka, fula, fulka, fsaka, fka, fulsaka, fuaka, fua, fuluaka, fulua, fuosaka
Osaka Fulu
olu, osalu, osulu, osu, osakalu, osakulu, osaku, oslu, osaklu, osfulu, osakfulu, osau, osakau, oulu, osaulu, ofulu, osafulu
https://portmanteaur.com/?words=Felis+Osaka
Felis Osaka
fesaka, fosaka, feka, faka, felisaka, felosaka, felika, felaka, fela, felka, fsaka, fka, feliska, felsaka, felissaka, feaka, fea, feliaka, felia, feosaka, felisa
Osaka Felis
olis, osalis, oselis, osas, osis, osakalis, osakelis, osakas, osakis, oslis, oss, osaklis, osfelis, osaks, osakfelis, ois, osais, osakais, oelis, osaelis, ofelis, osafelis
(Apologies if I am stepping on the process for selecting star upgrade names as I’m not a core dev)

F Star names
From: List of proper names of stars - Wikipedia

Fafnir
Fang
Fawaris
Felis
Felixvarela
Filetdor
Flegetonte
Fomalhaut
Formosa
Franz
Fulu
Fumalsamakah
Funi
Furud
Fuyue


Poll
Poll is for signaling purposes only.


Preferred star name

Fafnir
Fang
Fawaris
Felis
Felixvarela
Filetdor
Flegetonte
Fomalhaut
Formosa
Franz
Fulu
Fumalsamakah
Funi
Furud
Fuyue





0
voters

Author: gorondan
Date: 2024-06-13T15:32:30.223Z

voted for Fulu.
as for the star name, since you mentioned it, Fusaka has a nice resonance.
edit: or Fosaka, considering Fusaka is a branded font type.
Title: ERC_190_and_the_Ethereum_Package_Registry
Category: Magicians

Author: jpitts
Date: 2018-09-13T16:18:12.417Z

I wanted to point out that EthPM registry does not have very many smart contracts registered. It is on Ropsten, perhaps this has something to do with the low adoption, but it may also be a lack of awareness. Is there a way we can increase visibility, or better promote the use of package management?
https://github.com/ethpm/ethpm-spec
EthPM Integration Guide:
https://www.ethpm.com/docs/integration-guide
Title: Is_it_ERC_20__ERC20_or_ERC_20_
Category: Magicians

Author: fulldecent
Date: 2019-03-24T17:51:15.871Z

Let us canonicalize the references for EIPs. They are inconsistently referred to as EIP-123 and EIP123 in the EIP documentation as well as the EIPs themselves. Another option is EIP 123.
Original issue: https://github.com/ethereum/EIPs/issues/1464
The end-user public is increasingly exposed to technical details like EIP numbers. I hope we can please come to a consensus on this issue and use it consistently in the EIP repo. This is the same process we went through to standardize on using the eips.ethereum.org URLs instead of the GitHubs URLs (see https://github.com/ethereum/EIPs#preferred-citation-format).
I’m not asking you to do any work. Just please confirm if there is appetite here to make this change, and if we can be happy with one consistent format. I will then use this mandate to:

Make a PR which fixes the EIPs repository (other than the actual EIPs) this requires EIP editor signoff
Make PRs against individual EIPs to use this consistent format, and request they accept the change

Author: jpitts
Date: 2019-03-24T18:55:13.646Z

I believe that it should have a dash in the name, for accuracy, readability, and for convenient tagging. Typically when I see a post in this forum that appertains to an ERC or EIP I will add EIP-XXX / ERC-XXX in front of the title, as well as tag it with the same, but lower-cased.
Title: ETH_2_0_Report_on_Dev_teams_from_Moloch___Kyokan
Category: Magicians

Author: tvanepps
Date: 2019-02-02T23:46:45.681Z

Ameen asked me to remove for now. Will add back once full report is released to public.
Title: Gossipsub_Tests
Category: Magicians

Author: cdili
Date: 2019-11-13T20:35:40.729Z

The discussion has been on another forum
https://community.whiteblock.io/t/gossipsub-tests/17
But it’s important that the wider community is aware of this, and relevant expertise can participate, especially networking experts that are new to the community.
(If anyone knows how to migrate the other post to over here, that would probably be helpful.)
Title: Enabling_tags_on_this_Forum
Category: Magicians

Author: jpitts
Date: 2018-08-08T21:31:51.717Z

I am enabling tabs on the website as per Issue #11 at https://github.com/ethereum-magicians/scrolls/issues/11.
Please comment below about best practices for tags (this is also opened up as a wiki post). Here are my thoughts:


How tags fit in:

Let’s keep using categories, and use tags for interesting sub-categories, cross-referencing, and commentary.



Main conventions:

Use singular tags where possible
Keep them lower-cased
Dashes replace spaces, within reason (favoring readability)



When referencing an EIP category, use the following conventions:

“core-eip” for Core EIPs, “meta-eip” for Meta EIPs, etc.
“eip-1066” for a specific EIP



When referencing another category, use the following conventions:

“xyz-ring” for XYZ Ring
“eip-last-call” for the “EIPs: Last Call” subcategory, etc



Humor is fine, within reason.

Author: boris
Date: 2018-08-08T22:16:40.907Z

Yay!
Also, EIPs/ERCs directly — eg #erc1066
Events - #councilofberlin #devcon4
BTW — as a user, you can subscribe / watch tags in the same as top level categories. So maybe you don’t care about all EIPs, but just the token ones, you can subscribe to #tokens
You can also mute tags.
Read the Discourse blog post:



Discourse Blog



It’s Time We Talked About Tags
Consider the typical sections of a daily newspaper: Arts, Sports, Business, Travel, Local, and World. Any given article belongs to just one of those sections, and the content in each section is quite different, such that some people, for example, may...

Author: boris
Date: 2018-08-10T14:45:28.571Z

@jpitts looks like permissions are set so that regular users can’t do tags. At least, I can’t create any

Author: jpitts
Date: 2018-08-10T14:59:53.053Z

Ok, this needed an adjustment of the minimum trust level in order to create new tags. It should work now for users who have been participating here on the Forum.

Author: boris
Date: 2018-08-10T15:01:39.735Z

Not working for me yet.

Author: boris
Date: 2018-08-10T15:11:34.637Z

Works now! We have tags you can link #council-of-prague
Title: Confuse_about_revert_error
Category: Magicians

Author: GalaxySciTech
Date: 2023-09-22T07:55:06.159Z

i have a question is that we can not seen the specifics error log in etherscan if you use revert error
it will make someone confuse
how to solve this case
Title: Introducing__eth2_package___a_tool_for_spinning_up
Category: Magicians

Author: leeederek
Date: 2023-08-09T12:03:58.249Z

Hey everyone, I’m Derek from Kurtosis & I wanted to share the Kurtosis eth2-package, which is an environment definition for spinning up ephemeral, reproducible, private Ethereum testnets. This package comes out-of-the-box with Grafana & Prometheus and supports multi-node testnets in the cloud with any client combination you need.
This was written by the Ethereum Foundation to address the need for a private but full-feature testnet where protocol-level simulations could be run and tested. The Ethereum Foundation (EF) DevOps team has been using this for over a year now to simulate and test behavior at the network level ahead of hard forks like the Merge, Shapella, and now for Dencun (EIP4844). If folks are heading to ProtocolBerg in Sept, the EF team will be presenting their work on Kurtosis in a workshop!
Spinning up the network requires only the installed Kurtosis CLI, Docker, and a single command: kurtosis run github.com/kurtosis-tech/eth2-package. By default, this will bring up a network with Geth and Lighthouse clients, but this package natively supports all major EL and CL clients, including Reth!
Our roadmap includes adding Full MEV support via the Flashbots suite of products, the addition of more validator health monitoring tools, and extending support for longer-lived private testnets. For folks who want to build-their-own testnet using the composable pieces, check out our guide here on how to do so!
We welcome any and all questions and feedback & hope that this tool is useful for people in the community!
Title: High_Level_Overview_of_the_Diamond_Contract_Patter
Category: Magicians

Author: mudgen
Date: 2020-12-07T14:38:16.020Z

Here is a good overview of EIP-2535 Diamond Standard and the diamond contract pattern:


docs.aavegotchi.com



About EIP-2535 Diamonds | Aavegotchi Docs
High-level overview of EIP-2535 Diamonds






The diamond pattern is a code implementation and organization strategy. The diamond pattern makes it possible to implement a lot of contract functionality that is compartmented into separate areas of functionality, but still using the same Ethereum address. The code is further simplified and saves gas because state variables are shared between facets.


The diamond pattern is a contract that uses a fallback function to delegate function calls to multiple other contracts called facets. Conceptually a diamond can be thought of as a contract that gets its external functions from other contracts. A diamond has four standard functions (called the loupe) that report what functions and facets a diamond has. A diamond has a DiamondCut event that reports all functions/facets that are added/replaced/removed on a diamond, making upgrades on diamonds transparent.


Diamonds are not limited by the maximum contract size which is 24KB.


Facets can be deployed once and reused by any number of diamonds.


Diamonds can be upgradeable or immutable. They can be upgradeable and at a later date become immutable. Diamonds support fine-grained upgrades which means it is possible to add/replace/remove only the parts desired. Everything does not have to be redeployed in order to make a change. A diamond does not solve all upgrade issues and problems but makes some things easier and better.

See the standard and the standard’s reference section for more information about diamonds.
Title: Manipulation_resistant_instant_dex_proposal
Category: Magicians

Author: svechinsky
Date: 2019-02-22T13:44:43.948Z

Over the past 2 years with the surge in open finance solutions and tokens, a problem that has been constantly bugging me is the lack of a proper decentralized exchange for them. Despite the recent proliferation and advancement in the dex space, all defi apps use either an oracle or a centralized on chain exchange as a pricing source due to front running concerns.
In this post I would like to present a new dex architecture called Ping-Pong.
I’m posting here to get comments, opinions, and thoughts to know if this is something that should be polished and brought to a more usable level or dropped down at this point.
This new dex, created with the help of  Oliver & the twitterless Alon Pluda:

Is fully on chain, supporting uncensorable exchange of all ERC20 tokens
Is manipulation/ front-running resistant
Easily enables limit orders and aggregates liquidity
Instantly settles trades

Outline
Let’s consider an exchange with fixed price order book where ETH is traded against TOKEN at fixed prices. For example, prices are pre-fixed at S percent intervals. Meaning that starting from a 1:1 ratio (1 TOKEN for 1ETH) all the pricing levels are:
P_n = (1 + S)^n
This kind of exchange allows us to aggregate large amounts of liquidity in those fixed price levels. This lowers gas costs enough to enable an on chain order book. On the downside it does force an artificial spread on price levels in the market, creating worse prices for smaller orders.
With the ping pong dex however we combine this order model with an automated market (x*y=k). Any time the price of the market-maker DEX hits one of the limit order fixed price walls it starts buying from it, either filling it completely and passing it or bouncing back (like ping pong between two walls).
In my opinion this kind of exchange could be ideal as a pricing source for dapps due to the manipulation resistance and replace pricing oracles.
A more detailed overview can be found here:



cardo.gitbook.io



Intro & Motivation | cardo
Ping Pong is a fully on-chain DEX enabling instant trade execution, limit orders while being resistant to front running.





The code for an initial version of the smart contracts lives here:
https://github.com/kreator/ping-pong-dex
Title: Should_there_be_a_standard_algorithm_for_calculati
Category: Magicians

Author: jpitts
Date: 2020-08-14T17:30:24.590Z

Setting aside the (kind of made-up) controversy, I ask the following questions:

Should there be a standard algo for calculating ETH supply in clients?
What would be the best approach to deal with the generation and storage of this measure?
Who are the users of a supply measurement?
Are there different kinds of supply which would be useful or relevant?


A response by JΞFF to “Crypto’s Weirdest Cognitive Dissonance” on Twitter https://twitter.com/jeffehh/status/1294289745292546049:

It’s not as dry cut as it may seem. BTC for example allow for a simple algorithm to calculate the current amount of coins. For ethereum it’s slightly different because it allows for ether to be burned (as in it doesn’t exists anymore). Without iterating over all of the accounts
in the trie you’ll never have a definitive answer. I’m not saying it’s impossible, but it would take an insane amount of time. The other solution is to create a separate log that records changes to the total supply (I.e. block rewards, suicide calls + pre-minted coins). Bear in
mind that this will only ever be possible when running a full node (I.e. start execution from genesis) and I have no idea what kind of overhead this may cause plus it’s slightly tricky because you’d need to record only SUICIDE ADDRESS
and SUICIDE <the address of the to be suicided contract>. Also I wouldn’t want to mess with the VM unless absolutely necessary and certainly not, imo, for a nice gimmick.

Author: jpitts
Date: 2020-08-16T10:00:40.821Z

Posted by @tjayrush on reddit:

Here’s two articles I wrote:
Ethereum’s Issuance: blockReward | Coinmonks
Ethereum’s Issuance: uncleReward. This the second in a series of two… | by Thomas Jay Rush | Coinmonks | Medium
and a code base implementing the discussion in the articles:
https://github.com/Great-Hill-Corporation/trueblocks-core/blob/develop/src/other/issuance/README.md
I’d love feedback on them if anyone’s interested.

Author: CryptoBlockchainTech
Date: 2020-08-16T22:42:54.719Z

Confusing article, can’t tell which is original and which is new code. You talk about how confusing the yellow paper is, but when you write the article it is confusing as well as to which lines of code you are wanting to change. Maybe you can put them side by side?

Author: jpitts
Date: 2020-08-19T17:59:08.771Z

Jordan Last has created scripts for the “total issued ETH” methodology.


github.com




GitHub - lastmjs/eth-total-supply: Information and some implementation for...
Information and some implementation for calculating the total supply of ETH






Twitter discussion:


twitter.com



lastmjs ∞ (@lastmjs) on X
@lastmjs

1/ #supplygate

I can say beyond reasonable doubt, that the total amount of ETH issued up to and including block 9193265 (the last block in 2019) is 109,094,014.21823.

Three independent scripts attest to this number: https://t.co/SK0CWhwLGI
Title: solidity_template__a_modern_Solidity_contract_temp
Category: Magicians

Author: mattstam
Date: 2022-11-01T14:03:26.149Z

Introducing solidity-template, a Solidity template for Ethereum smart contracts. It optimally combines two extremely powerful frameworks:

Foundry
Hardhat

Most contract repositories out there in the wild choose either one or the other. Both offer powerful tools for contract development, and although there is some overlap in their functionality, there is a multitude of reasons that you should be utilizing both:


Complete test coverage using Forge to cover the raw contract logic and basic scenarios, and Hardhat the complex user interactions.


Maximum suite of tools for contract debugging, deployment, gas measurements, etc.


Reference for on-chain developers writing contracts that call these contracts in your Unit Test files to see the expected usage in Solidity.


Reference for off-chain developers writing clients that call these contracts in your Integration Test files to see the expected usage in JavaScript (TypeScript) and Ethers.js.


The latter case has already proven to be extremely useful for a new project Git Consensus, where just pushing integration test code gave examples for the frontend devs concurrently to know how they need to prepare input parameters for the contract functions. This will only be more relevant as the community shifts to patterns that encourage loaded input parameters for gas savings.
Of the repositories that do combine try to combine both Foundry and Hardhat, none are optimized together in a way that makes them convenient to develop in. This is due to the split between how Foundry handles dependencies (git submodules located in /lib) and Hardhat handles dependencies (managed with NPM). Nothing felt up-to-date with contract development best practices in 2022.
This gap in a fully-featured, modern Solidity template that utilizes both frameworks inspired me to publish solidity-template - not only is it optimized for using both, but it also offers a lot of the boilerplate a project will be able to utilize to streamline development: GitHub Actions, interactive CLI, linting, doc generation, deployment address tracking, contributor guides, etc.
This template includes an easy-to-follow example Counter.sol, with its interface ICounter.sol, Unit Test file Counter.t.sol, and Integration Test file counter.test.ts.
If you like it, definitely give it a  so you can remember to use it for your next project!
Title: Has_an_adopted_EIP___hard_fork__ever_broken_transa
Category: Magicians

Author: cyrus
Date: 2022-12-21T01:20:06.959Z

If I signed (but did not submit) a transaction on July 30, 2015, would it still be valid today (assuming I didn’t advance the nonce)?
If not, which changes broke this backwards compatibility?