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

Author: payoffmatrices
Date: 2023-09-05T20:03:52.503Z

Hi All, long-time Ethresear.cher, first time Magician here. I hit a wall on this issue and @EvanVanNessEth suggested I make a thread here to discuss.
Earlier this year I was researching re-staking and trying to figure out how validators are able commit to smart contract rules (as in re-staking and LST) when they can just change their withdrawal address later. Then I learned that Capella made it so validators are no longer allowed to switch their withdrawal addresses. It was previously specc’ed under 0x00 that they could change it multiple times.
This change allowed a sort of “protocol-enforced proposer commitment” (if you will) where now validators can set their withdrawal address to a smart contract and, since they can’t change it, thereby ~credibly commit to following the rules of that contract as enforced by slashing. The earlier 0x00 standard, with changeable withdrawal address, meant validators could not effectively commit to obey those additional rules. The reason for this is that validators, once “committed”, could rug the smart contract by changing their withdrawal address, leaving the contract with nothing to slash.
From discussions I’ve had with EF and EF adjacent folks, some people already knew this but it also seems that many do not. I personally don’t have a strong opinion on this stuff yet but, unless I’m missing something, it seems like this change should be more widely discussed given the prominent issues of the day.
Some open questions I have:

Are there viable near-term approaches to validator decentralization that operate fine under 0x00? Per the experts I’ve spoken to, DVT works just fine under 0x00.
Are there other cryptographic tricks that could re-create this commitment even under 0x00? If so, then this change is not so interesting. I’ve seen a few that could do something in this direction but nothing very general.
Title: FlyClient__Super_Light_Clients_for_Cryptocurrencie
Category: Magicians

Author: ligi
Date: 2019-03-07T15:45:28.376Z

@egalano just mentioned this in his talk at ethcc.


eprint.iacr.org



226.pdf
776.71 KB





this sounds quite good:
https://twitter.com/benediktbuenz/status/1101241113262776321
we should really build a matrix comparing:

Minimal verification client (INCUBED)
Super-Light Clients (FlyClient)
Light clients (geth/parity)
Ultra light client
…

will try to read the paper over the weekend. Just sharing it now to spare people wasted time searching for it.

Author: shazow
Date: 2019-03-08T21:53:15.684Z

This is great, thanks for sharing! I’ll take some time to read this paper. +1 on a comparison matrix.

Author: dominic
Date: 2019-03-27T07:21:01.254Z

+1 on a matrix, that would be really great. We’re working on a paper as well - anyone here who would like to review? - and it would be great to see what’s already there and which use cases are being addressed / can be covered using what methods.
Title: Using_ProofOfHumanity_and_neuralink_as_nodes
Category: Magicians

Author: Nachobr
Date: 2021-08-19T16:22:51.573Z

So given PoH as it is, I thought about a maybe “crazy” idea, would be possible with the current technology or future to use every person as a node/validator, so instead of PoW, PoS, it’s PoH, like a neurolink tech… That a chip is inserted in every registered Human of the poh registry, and this chip validates transactions, this is a long term idea, and lots of research should be done imo, and idk also if it will be a good idea, any thoughts?
Already asked to neuralink here: https://twitter.com/NachoBritos12/status/1428393406213107715?s=19
Using PoH as blockchain - Proof of Humanity - Proof of Humanity and UBI

Author: Nachobr
Date: 2021-08-26T05:59:11.082Z

humanode.io



Humanode-4Pitchdeck.pdf
10.01 MB





Someone is  already doing it
Title: Block_header_elements_should_be_well_known_and_eas
Category: Magicians

Author: alexbabits
Date: 2024-05-07T04:32:42.102Z

Every major update that effects the block headers should broadcast more clearly the exact current elements of the block header, so block hash verification is always straightforward.
What are the current block header elements post merge and today in 2024? I’ve searched a lot and tried a lot of things but have come up short, also see this post below:


ethereum.stackexchange.com






How to verify block.hash post-merge (block > 15.5M)?


rlp, blockhash


  asked by
  
  
    Babs
  
  on 04:29AM - 07 May 24 UTC

Author: alexbabits
Date: 2024-05-07T18:02:18.033Z

This post shows how to recreate the block hash for all 5 “eras” of different block headers: rlp - How to verify block.hash post-merge (block > 15.5M)? - Ethereum Stack Exchange
This should be easily accessible public knowledge, not esoteric and difficult to find.

Author: xrchz
Date: 2025-05-06T09:01:51.359Z

I agree - is there still not some canonical place to find the specification for RLP encoding of blocks as used in the current fork?

Author: bbjubjub
Date: 2025-05-06T09:14:58.893Z

There are the execution layer specs which have a Block dataclass for each fork.
Title: MetaSwap___An_approach_to_Cross_Chain_Swaps_using_
Category: Magicians

Author: hitchcott
Date: 2020-03-08T15:23:08.846Z

This idea combines submarine swaps with metatransactions. The key bit of innovation is requiring the signer of a metatransaction to deposit some collateral that would be burned if they attempt to cheat by signing too many transactions.
I think this premise could be expanded to do cross-chain contract execution and similar.
I’m not sure if this approach exists already. There seem to be limitations and potential solutions that I have outlined in the readme.


github.com




GitHub - web3masons/MetaSwap: Cross-chain swaps with metatransactions
Cross-chain swaps with metatransactions






If anyone has any feedback, it would be very much appreciated.
Title: New_RSS_feed__PR_for_editor_review_
Category: Magicians

Author: fulldecent
Date: 2019-02-06T17:11:25.003Z

Editors, please help to review and approve this update to the RSS feed


github.com/ethereum/EIPs








Generating /feed.xml with all EIPs


master ← spadebuilders:feed-improvements



          opened 09:04PM - 12 Jan 19 UTC




            bmann
          



+89
-27






Partially addresses #1688 

Global ```feed.xml``` that includes all EIPs. You …can see a preview here https://5c3a52345d52e7000834b647--ethereum-eips-refactor.netlify.com/ --> and the direct link to feed.xml is here --> https://5c3a52345d52e7000834b647--ethereum-eips-refactor.netlify.com/feed.xml

[W3C Validator passed as valid RSS](https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2F5c3a52345d52e7000834b647--ethereum-eips-refactor.netlify.com%2Ffeed.xml) -- with caveats about wrong link (since link is set to the live EIPS url), including author emails that look like tags, and use of relative URLs (which works in Atom).

Last Call metadata of ```review-end-date```  is done (previously merged in).

A couple of notes:
* refactored eipcontent generation into an include so all feeds can have the same internal content
* created is a manual data by the EIP author -- this is what pubDate is set to
* for the feed lastPubDate I am using the build date -- so every time the site is built, this field will change (since it usually gets built when EIPs are merged, this is OK)
* on Github Pages, you can't easily run a last-modified-date plugin -- we may want to encourage EIP authors to add / edit this manually as they majorly refactor Drafts
* to make more changes to the site -- like adding feeds to All/Core/Networking/etc -- the minima theme that is used needs to have files brought in; I brought in default.html for starters, which has /feed.xml hardcoded in the header by default
Title: Context_Linking_Token
Category: Magicians

Author: ajax0
Date: 2021-08-26T13:13:15.925Z

Magicians one and all,
I’m exploring an application of ethereum tokens to track the context of any dataset, or document/file, or news article, personal information etc.
I’ve written a short article to explain my thinking here:
medium.com/codex/context-linking-tokens
Would any of you be able to give me some feedback on whether you think this idea has merit, and/or if there are any pitfalls I should consider before I make a formal EIP application.
Many thanks!
Ajax0
Title: ERC_and_EIP_Specific_Groupchats
Category: Magicians

Author: anett
Date: 2022-11-03T17:39:25.328Z

Groupchats, yeah, I know, something that’s very away from the vision of what Ethereum Magicians purpose is - create noise-free discussion to discuss technical difficulties on Ethereum.
Unfortunately, no matter how much we try - people still end up creating group chats to relevant EIPs and have discussion outside of Ethereum Magicians Forum. Which is not bad as some discussion may want to be more private. Although the nature is try to keep things open. But not everyone has time to open Magicians forum daily and so groupchats are more effective way to collaborate.
I’m sharing here some of the ERC related groupchats which I’m aware of that are topic specific.
PLEASE don’t spam them, these channels don’t have good moderation and are created purposefully for specific topic discussions. Join them if you want to contribute, introduce yourself and be active in the discussion.

General NFT Standards
Telegram: Join Group Chat - groupchat made as WG to NFT Standards Wiki

EIP-4973 Account-bound tokens
Telegram: Contact @eip4973 - groupchat made by @TimDaub for SBT relevant discussion

Music NFT Metadata Standards Working group
Telegram: Join Group Chat - This fork of initial NFT Standards WG, working on Music NFT Metadata

Wallet JSON-RPC
Ethereum Wallets - and anything related to URLs
Any others that should be on the list ? Please link them bellow
Title: _Impromptu_technical_AMA_on_history_expiry____redd
Category: Magicians

Author: jpitts
Date: 2021-11-26T16:10:27.619Z

https://www.reddit.com/r/ethereum/comments/qzvsfq/impromptu_technical_ama_on_history_expiry/
Title: BlockQuick___Secure_super_light_client_for_Ethereu
Category: Magicians

Author: dominic
Date: 2019-05-31T04:32:35.749Z

We released our research results earlier this week. A new super light client protocol, decentralized and eclipse resistant. Needing just 20kb to sync to Ethereum.
Here is the paper: BlockQuick: Super-Light Client Protocol for Blockchain Validation on Constrained Devices
and the announcement: Redirecting…
The first use case we’re addressing is to use decentralized PKI (DPKI) from those small IoT devices.
Title: ERC1271_versioning_to_maintain_signature_validity
Category: Magicians

Author: kylekaplan
Date: 2024-04-16T19:03:55.670Z

Intro
Off-chain ERC1271 Signatures are not guaranteed to be valid in the future, because the isValidSignature function can be changed.
Problem
This creates a problem for any application that would like to use signatures to prove validity of statements and also support smart accounts.
Simple example of signers changing causing the validity of a signature to change:
image1898×818 148 KB
From Peter Robinson’s Ethereum Engineering Group presentation
Proposal
Standard way of updating isValidSignature function
I propose we create a standard way for updating the isValidSignature function so that we can keep track of previous versions.
One possible solution is to store in state previous ERC1271 verifiers and timestamps, which can be updated by calling an updateIsValidSignature function. Then a wasValidSignature function can be called and reference previous verifiers, when determining if a signature was valid.
The way state is stored can be external to this standard, but could look something like this:
State:
// create a VerifierStruct which includes a timestamp and ERC1271 verifier
// keep an array of VerifierStructs that updateIsValidSignature will push to

struct VerifierStruct {
  timestamp: uint64;
  verifier: ERC1271; // ERC1271 contract address
}

VerifierStruct[] public verifiers = [];

OR
// Keep a mapping of timestamps and ERC1271 verifiers that updateIsValidSignature will add to

mapping(uint64 => ERC1271) public verifiers;

Functions:
updateIsValidSignature:
@dev pushes to the array a new contract address with a current timestamp
@param _contract An ERC1271 contract address
function updateIsValidSignature(address _contract) external;

wasValidSignature:
@dev looks up which contract to use based on timestamp, and calls appropriate function
@return The bytes4 magic value 0x1626ba7e when function passes
@param _timestamp Timestamp to check for
@param _hash Hash of the data to be signed
@param _signature Signature byte array associated with _hash
@param _data arbitrary extra data used for verification
function wasValidSignature(
    unit64 _timestamp,
    bytes32 _hash,
    bytes memory _signature,
    bytes _data
) public view returns(bytes4);

Events:
event ERC1271CheckerUpdated(address indexed newChecker)


I would love feedback and suggestions on this and other possible solutions for this problem. Thanks @sina for your help on this design so far.

Author: sina
Date: 2024-05-28T21:14:34.495Z

Gm, we have a draft for a standard proposal @ [EXTERNAL] DRAFT-EIP-1271T - HackMD, would love feedback from anyone interested
Title: Offchain_computation_standard
Category: Magicians

Author: npasquie
Date: 2022-01-27T10:12:21.526Z

Hello Magicians ,
This is a pre-PR discussion for the EIP : Offchain computation standard. You can find a first version here : EIPs/eip-xxxx.md at master · npasquie/EIPs · GitHub

Simple Summary
Standard to request & access offchain computed data while preserving composability

Abstract
A standard API is proposed to request & access offchain-computed data in smart-contracts in a composable way. It includes a smart-contract on chain and specifications for clients.

Motivation
Off-chain computation checked on-chain has become a common pattern in Dapps, virtually enabling usage of large data sets or complex computations in smart contracts within their limited resources. This is usually achieved through a script in a front-end app generating the correct parameters required by a contract call for a transaction signature. This pattern is by nature non-composable, any protocol that needs to be integrated by other protocols must resolve to implement those costly operations on chain.
The proposed new standards would greatly broaden the possibilities of smart-contract developers, especially in the interactions accross protocols. L2-scaling alone can’t provide this kind of application-specific optimisations.
Any reflexion/feedback is greatly appreciated
Title: Post_EIP_ERC_Split__Represent_each_side_as_Camps_i
Category: Magicians

Author: 0xMawuko
Date: 2023-10-26T05:08:03.490Z

The EIP/ERC Split, a.k.a. the ‘reverse merge,’ has finally been completed and thus has kick-started the dawn of a new era where core protocol and application layer improvements can grow and be managed independently. There is no doubt that we will experience the Cambrian explosion on both sides.
However, one of the key objections that was highlighted in the proposal was the concern that this change would split the Ethereum community, especially with respect to Ethereum Magicians. I think this isn’t necessarily the case. Instead, this change has created an opportunity for various magicians in the fellowship to appropriately recognize their areas of interest and expertise and fully unlock their potential and contributions accordingly.
‘We are all of us Ethereum Magicians.’
The goal of this post is to make a meta-suggestion of something similar to Houses/Camps (as seen in some fantasy literature, including LOTR, Harry Potter, and the Percy Jackson series) in how various members affiliate themselves, all under the Ethereum Magicians community, and gather feedback and discussions on the best ways to proceed and achieve agreement. I think there’s good inspiration to be taken from the Optimism Collective, for example.
I’m particularly leaning closer to Camps and from the looks of it, we already have two Great Camps under the Fellowship, working together to grow the Infinite Garden:

Camp EIP - core protocol improvements
Camp ERC - app-level improvements

Where each Camp has Cabins, so for example:


Camp EIP

Execution Cabin
Consensus Cabin



Camp ERC

Wallet Cabin
Interface Cabin
Standards Cabin
etc.



Would really appreciate some thoughts and discussions around this, and hope fully get some support for this on Magicians.
‘We are all of us Ethereum Magicians.’

Author: Mani-T
Date: 2023-10-26T06:14:38.729Z

Separating discussions based on topics can reduce noise and make it easier for community members to find relevant information.
Title: ERC20_with_built_in_fee_structure_
Category: Magicians

Author: Bschuster3434
Date: 2022-03-02T23:40:29.972Z

Hey folks,
I’m looking to see if there are any standards or proposals around a token that upon sending pays a fee to another address? An example would be a token that automatically pays 1% of the total transaction amount to a predetermined contract or wallet.
I did some searching through the EIP standards but didn’t see much.
As a reference, here is my solidity code with an early implementation of this idea: GitHub - Bschuster3434/Comrade-Token: Open Source Repository for the Automatically Redistributing Comrade Token
Here’s an example of what this looks like on Polygon: Contract Address 0x70e4a39e46695c42f5dd7821b3c32af4b4a8253a | PolygonScan
Any thoughts for feedback would be appreciated.

Author: auryn
Date: 2022-03-03T16:40:44.633Z

The CULT token does this.
I’m not aware of any standard for this type of fee collection though.
Worth pointing out that it’s trivial to circumvent this type of fee, simply by wrapping the token. If the token gains any kind of traction, there will almost certainly emerge a market for a wrapped version of this token that circumvents the fee.

Author: wjmelements
Date: 2022-03-04T15:51:38.800Z

Bschuster3434:

Any thoughts for feedback would be appreciated.


It doesn’t make sense to take a fee on all transfers. It breaks the assumptions of ERC20 users. Don’t ever do it.
And, 1% is a lot. I will wrap your token.

Author: Bschuster3434
Date: 2022-03-04T16:17:40.059Z

Very new to this platform, so sorry if I just double messaged you. Here’s what I replied:
“It breaks the assumptions of ERC20 users”
Yes, I agree. My preference would be that your wallet would let you know what exactly you’re paying up front before the fee is sent. We don’t have anything that resembles this today, which is why a standard on how fees are paid would be a logical first step to allow for transparency.
“And, 1% is a lot”
The fee, of course, is arbitrary. It can be a flat fee on all transactions. It can be progressive, regressive or flat. But I have to imagine if you’re using this token (given how many choices you have in payment), you would only be using this token if you had some reason to want to support the community these funds are being distributed to.
Thank you for your feedback!

Author: wjmelements
Date: 2022-03-24T21:09:47.930Z

@Bschuster3434 I don’t think you understood one part of my reply:

I will wrap your token.

You cannot charge a fee on transfer because I don’t have to use your contract directly. I can deposit it into a wrapper token contract and use that instead. Fees on transfer therefore cannot be your business model.

Author: Bschuster3434
Date: 2022-03-25T10:54:28.301Z

No, I did understand your response. That’s a threat to this particular model, I agree.
Title: Long_stagnant_EIP
Category: Magicians

Author: RenanSouza2
Date: 2023-04-26T13:23:48.748Z

Hey everyone
Has there been a discussion on what to do with EIPs that are stagnant for a long period?
What if after a given time an EIP migrates from ‘stagnant’ to 'withdrawn’or even a new state?
What are you opinions on this?

Author: abcoathup
Date: 2023-04-27T00:59:35.885Z

I see withdrawn as the authors have explicitly decided to withdraw the EIP/ERC, so wouldn’t want to see it reused for abandoned EIP/ERCs.
abandoned could be an automated state after say 6 months of being stagnant but I am not sure if there is a need.

Author: RenanSouza2
Date: 2023-04-27T10:15:24.632Z

I was reading some of the stagnant EIPs and some of them don’t even make sense anymore by either being surpassed by another EIP or porposing something no longer relevant.
So I wondered what of those EIPs could still be revived and if there was a better way of classifying them.
About the abandoned state, maybe we can change EIP-1 flux so a stagnant EIP that was in review state can return to review state but an abandoned one has to return to draft
Do you think those changes are relevant? The last thing I wanna do is increase the amount of work to the editors

Author: abcoathup
Date: 2023-04-28T04:13:23.288Z

stagnant is a catch all, I am not sure there is a need for additional states.  See if any EIP editors chime in.

Author: RenanSouza2
Date: 2023-04-28T16:51:08.290Z

Makes sense, it doesn’t need to classify what stagnant EIPs are more likely to return because the stagnant itself does that.
Adding another state would not add anything to the process

Author: poojaranjan
Date: 2023-05-03T21:52:31.498Z

An EIP can be resurrected from Stagnant. It can go back to the last status it was in. If the proposal does not make sense after coming back to active status,  it can’t be promoted anymore. The author may move it to Withdrawn or let the proposal live in Stagnant status forever.
Just a note Abandoned isn’t a valid status anymore as per EIP-1.
Title: Interesting_question___idea___allowing_a_tx_to_onl
Category: Magicians

Author: jpitts
Date: 2021-01-31T02:32:39.245Z

Posted by @mhluongo on a Twitter thread:

Pretty sure this was discarded years ago in the annals of Ethereum L1 design, but have we totally given up on allowing a tx to only lock part of the state trie, and pay for how much each locks?
It’s crazy to me that every tx gets a global lock by default. Being familiar with a UTXO model, I remember I was shocked. No wonder gas is high — you should have to pay out the nose for that privilege.
Paying for the scope of a tx’s state lock would open up more parallelizable verification, etc, but it’d also be more fair to folks who are just pushing tokens around and are only touching a single contract.
It’d also be satisfying to see our flash loan arb friends pay for the superpower.

@prestwich responded:

there’s some movement in this direction with eip 2930. But it’s not sufficient. Stateless eth had some shakeups lately and I wouldn’t count on it being a thing for several years
Title: EIP_13377__Simple_futures_contract__loop__between_
Category: Magicians

Author: M8loss
Date: 2021-09-01T16:49:00.132Z

Abstract: EIP-13377: A futures contract “future loop” between buyer and seller ensures price security when buying, for example, a digital tattoo motif. The “loop” of the transaction is only fully executed when the processing time of around 1-2 weeks or freely definable has been completed. The time of the order (transaction execution) up to the completion or handover of the product (transaction confirmation), with a suitable correction between the fiat price and the ether value, is located.
Motivation: In trading, we would say “futures” are for professionals, but in principle they are a “futures contract” with the oldest financial instrument there is. This is because farmers were able to sell their crops in advance and then had a certain degree of planning security. As already mentioned, futures contracts are standardized and therefore very transparent. Each contract stipulates which goods must be delivered when and at what price.
Implementation: This mechanism would have to be built into the interface of, for example Ledger or MetaMask???
Example: Let us assume that a digital artist would like to secure works of art by means of an appointment transfer to his cover-up in order to secure prices. He intends to hedge EUR 50. How could such a contract look like ??? At the beginning, as with all “derivatives”, we need the base value. This is derived from the underlying basic product, the tattoo template. In addition, it must be stipulated in the contract which delivery quantity and templates the “future” includes. If the futures contract contains an amount of 100 EUR and 2 tattoo templates, the digital artist must sell 2 futures to the buyer in order to achieve the desired price hedging. There must be no minimal price change in this appointment transfer. When closing, the execution date must be recorded. This could be set to two weeks for the tattoo template, for example.
You can also look at the german forum, for german discussion.
If there is already some kind of this idea or is technically feasible, I apologize.
Best regards,
M8loss
Title: Naming_Conventions
Category: Magicians

Author: dtedesco1
Date: 2022-04-08T02:02:30.717Z

EIP-1 doesn’t specify how naming conventions are developed and propagated. Discussions are bubbling about naming upgrades and branches. And EIPs, like this one, run into issues of how much to align with existing standards.
Should there be a broader, systemic way to address these questions? How important or unimportant is it?
Title: Wait___see_protection_to_reduce_risk_of_justifying
Category: Magicians

Author: mxs
Date: 2025-02-26T01:53:52.302Z

Wait and see
Thanks to ralexstokes & ManuNLP for reviews & feedback.
This post describes an approach to minimize the risk during Ethereum upgrades to avoid the Pectra/Holesky scenario where the wrong chain was justified due to a bug present in 3 implementations of execution clients.
It does not imply changes to the specs or the Ethereum protocol, but it requires all beacon nodes to play this game. A parallel to this approach would be the Doppelgänger protection, which isn’t bullet-proof but somewhat easy to implement and can save the day.
Overview
At the transition moment of the fork, beacons enter a wait-and-see mode where they arbitrarily mute 40% of their validators: muted validators continue to propose blocks but do not attest. Knowing 40% of the network is not attesting, observe what the 60% voting ones are doing and act depending on it.
Smooth upgrade
If the 60% agree on the same view, the beacon unmutes its validators and the chain finalizes. 40% of the validators lose 1 attestation during this process.

Upgrade with bugs
If the 60% don’t agree on the same chain, the beacon continues in muted mode for 40% of its validators and waits for manual clarification. In this mode, the validators won’t cast a vote for a source higher than the one of the fork, because they don’t see 2/3 of the network vote on something (40% is down). The two sides are stuck.
Network enters inactivity leak but there is time for client teams to investigate what is going on and provide a fix. Once the fix lands, the bogus clients are upgraded and agree on the same view.

They key point is that, as long as a consensus client doesn’t see 2/3 of the network voting on the same target, its source vote will stay at a stuck position. When the network upgrades in the right fork, it will be able to see a target with 2/3 and increase its source vote. There is no surrounding involved so no slashing.

Examples
Assuming a coordinated bug on 80% of the network (3/4), beacon knows 40% is randomly down, on the 60% up statistically it sees:

3/4 vote for 1 thing (~45% of the network), side A,
1/4 the other (~15% of the network), side B.

Bug is identifed on side A and fixed, everyone upgrades and moves to side B, beacons see 60% agree on the same target there, accept to vote on it as you see it the same, 2/3 is reached and the network continues.
Downsides

It only works during specific periods where a beacon “knows 40% of validators is randomly down”, it won’t prevent such bugs during normal operations,
It costs some attestation misses (likely 1-2 or so if it everything goes fine, but it’s ridiculously small compared to the risks),
An attacker not playing by the rules can lure the network into believing there is 60% agreement, this would defeat this protection: this is not a bullet-proof protection, and is more to prevent bug scenarios.
Title: On_chain_images_in_AVIF_
Category: Magicians

Author: MidnightLightning
Date: 2024-01-22T15:22:02.634Z

When contracts wish to save/generate image data on-chain, I’ve typically seen contracts generate SVG (vector) or PNG images (raster) as the output. For raster-style graphics, the AVIF image format is making some headway as an updated and more flexible (can be lossy or loss-less, still or animated) means to save graphics. General guides I’ve read indicate it can be smaller in filesize than JPEG or PNG, but that it’s more CPU-intensive to achieve that.
The CPU-intensity seems to be from finding the most optimized way to compress arbitrary image data, so smart contracts may not be able to do the most optimum compression of a dynamic image (since “more CPU” would equate to “more gas cost”), but if the resulting file (if an off-chain process generated it) is a smaller filesize, saving that directly on-chain would be more cost-effective.
Has anyone else attempted generating AVIF files from a smart contract? With many NFT imagery consisting of different graphics for different traits being layered on top of each other, AVIF’s ability to create spatial layers may be an effective way to present dynamic content of that type?
Title: Vlad_Zamfir_s_Dilemma__Autonomous_Software_vs__Cry
Category: Magicians

Author: Ethernian
Date: 2019-01-29T00:24:38.496Z

Vlad Zamfir has started a new discussion about Crypto Law as opposite to “autonomous software” and  “wiling to die on that hill”.
Despite of that fact that Vlad is well known troll and uses too much ad hominem argumentation (for my taste), the topic he started is important.
Vlad’s central message is:
"Our shared reality that we need fully autonomous software to escape state control is insecure and aggressive And it 100% isn’t true" and should be replaced by Crypto Law (whatever he means by that). Otherwise crypto will become illegal.
I disagree with Vlad, because …


On sovereign Crypto Law

Any off-chain law needs a law enforcement officers.
Law enforcement officers will need a sovereign space where they can operate. Otherwise they will enforce third party’s law (the legacy state law).
Sovereign territory and sovereign law need to be defended. Declaration of sovereign Crypto Law means Declaration of Independence. This (if taken seriously) will provoke the state powers and lead to war (or some kind of).
Neither I see any reason to provoke a war against state’s legal systems (it is just unnecessary - now we can still work perfectly legal), nor I see how Crypto can win it. May be Vlad is “willing to die on this hill” - I am not.
Any radicalization of Crypto will make the space evil because majority becomes smaller but radicalized.
1-5: Declaration of Sovereign Crypto Law will create more damage. Nevertheless it makes sense to talk about rules we a trying to follow.



On autonomous software execution

I agree with Vlad, that autonomous (and anonymous) software execution can’t shield actors in crypto space fully.
Nevertheless it shields us enough to make a political process more feasible than blind law enforcement.
If we give up our shields, the will be no need for political process at all.



Synthesis: Autonomous software meets Crypto Law

Modern society is a construct of “checks and balances” of different kinds of power.
An institution can only sustain as one of these “checks and balances” if it is strong enough to resist a pressure of other institutions, but at the same time flexible enough to cooperate with them.
Crypto should try to become a new institution among existing “checks and balances”.
It will be only possible if it keeps both its "automation and anonymity" for sustainability and creates a new “Crypto Law” interface for cooperation with other institutions.
It is only the way how it can keep self-sovereign features in long term, like anonymity, self-sovereign money and settlement. Otherwise either Crypto will lose its “crypto” or it will become illegal.



Any thoughts?

Author: jpitts
Date: 2019-01-29T20:01:36.840Z

X-Posting this to the Etherians Forum:
https://forum.etherean.org/t/vlad-zamfir-s-dilemma-autonomous-software-vs-crypto-law-x-post-from-fem/217
Title: Potential_options_for_a_hard_burn_removal_of_untra
Category: Magicians

Author: Spirit
Date: 2022-01-29T13:23:11.227Z

Hello!
I want to discuss potential options to remove untransferrable, scam (honeypot) ERC20 tokens from a wallet: tokens that have their contract locked or paused specifically to steal users funds through UniSwap etc.
https://info.etherscan.com/what-happens-when-erc-20-token-transfer-might-have-failed/
Is it possible, in theory, to remove or ‘hard burn’ untransferrable tokens from a wallet?
I know most think it’s probably not an important issue, and you could just start fresh with a new wallet – but with the growth of ENS, I would argue having sovereigny over the contents of our wallets is more important than ever.
Is it technically feasible to propose an update that could implement a way to ‘hard burn’ anything in your wallet, overriding the locked or paused ERC20 contract?
Could obvoious scam tokens ever be dropped with The Purge?
I’d love to hear your thoughts, and explore possibilities and hopefully learn some valuable info in the process. Thank you

Author: davidc
Date: 2022-01-31T08:03:14.745Z

Do you mean to extend ERC20 with some sort of a user-initiated burn function, so that it is no longer  associated with your wallet?
Couldn’t a scam token just decide not to implement this functionality correctly?
Title: Ethcode___the_vscode_plugin_for_Ethereum
Category: Magicians

Author: 0mkara
Date: 2020-07-28T03:41:14.805Z

Hello everyone,
We are a small team building Ethcode a vscode plugin for ethereum smart contract development. We have been working on this tool for many months now.
Ethcode has some amazing abilities that vscode users might have been missing:

Compile solidity, Vyper
Deploy compiled contracts
Call functions, create transactions
Sign transactions locally with your keys
Deploy transactions to Test and Main network

Screenshot from 2020-07-28 07-20-431920×1080 237 KB
Please install our plugin from Visual Studio Marketplace
Join our Discord channel for any help or questions. If you find any issues using our plugin feel free to report.
Title: First_User_Interface_for_Ethereum_Diamonds
Category: Magicians

Author: mudgen
Date: 2021-02-19T05:00:57.580Z

Check it out: https://louper.dev/

Author: Auguries
Date: 2021-02-21T23:11:54.965Z

Awesome. Still learning through Solidity, but I like seeing through your posts.
Title: Solidity_Libraries_Can_Now_Have_State_Variables
Category: Magicians

Author: mudgen
Date: 2020-08-11T22:35:35.058Z

Solidity libraries can now have/create/use/modify state variables using Diamond Storage.
See this article about it: https://dev.to/mudgen/solidity-libraries-can-t-have-state-variables-oh-yes-they-can-3ke9

Author: Jules
Date: 2020-09-15T08:45:57.794Z

Brilliant!
This is so useful, I think it needs its own Informational EIP.
I have raised a topic about that.
Title: A_token_aggregattor_to_develop_standard_agnositc_t
Category: Magicians

Author: DanielAbalde
Date: 2023-01-26T12:50:15.501Z

Hi there!
I want to share with you a non-commercial project to receive any feedback. I will make a short introduction here and if you are interested please visit the following link for more information.


github.com




GitHub - DanielAbalde/Token-Client: A token aggregattor to develop standard-agnositc...
A token aggregattor to develop standard-agnositc token operations in EVM smart contracts.






After several projects that operate with tokens (like a swapper or a marketplace) I decided to focus on generalizing or abstracting the shared functionality between token standards: isOwner, balanceOf, isApproved and transfer (for the moment), which is sufficient for many use cases and complex operators. Instead of calling the standard methods directly, you call the client using the same function name independently of the standard, and the client calls it for you.
This gives many advantages: you separate the decision of what standards to support in your dapp from the implementation itself; it allows you to support or stop supporting any standard token at any time using proxies; you make code more elegant by eliminating redundancy and making algorithms token-agnostic; it is faster to develop and you can focus on the logic of your mechanisms instead of on protocol specifications; among other advantages.
But a fundamental reason for doing this, which I would like to put up for debate, is that I think ERC20 or ERC721 or ERC1155, even if they are supported forever, are not going to be the main token standards in 5 or 10 years. So it’s a good idea to create dapps with easy token support to future-proof them. I think the standardisation of Account Abstractions or contract based accounts (with signature capability) will allow much better designs that were not possible before. I imagine that the future of token management will go towards plugins for contract-based accounts, just as there will be plugins that handle permissions, privacy or security policies, intellectual property records, identity records, ownership records, and so on, that any dapp can interact with. So the question is, can such design change (moving from EOA to AA) to keep as main standards for tokens the current EOA-based protocols (ERC20, ERC721 and ERC1155)?
I personally don’t think so and that is why I think it is important to make token agnostic mechanisms as suggested using TokenClient.sol, to transition smoothly to better standards in the future.
What do you think about this vision and about TokenClient?
Thank you!
Title: How_can_zk_rollups_with_danksharding_fix_fractured
Category: Magicians

Author: PradhumnaPancholi
Date: 2023-01-05T11:01:29.134Z

Recently, on a Bankless Shows’ Podcast, Justin Drake mentioned that zk-rollups with danksharding will help fix the problem of fractional liquidity. Given the nuance off an “opt-in” option, where can I find more information about this ?

Author: Pandapip1
Date: 2023-01-05T12:37:08.540Z

This statement is lacking most of the context needed to explain it. I suspect it has to do with one of Vitalik’s proposals for a “can’t be evil” yet privacy-preserving CEX:
https://vitalik.ca/general/2022/11/19/proof_of_solvency.html

Author: PradhumnaPancholi
Date: 2023-01-06T10:20:02.027Z

The statement is lacking, as in my question ? I can provided more context.
Title: Token_Ring_Meetup__ETHBerlin
Category: Magicians

Author: dekz
Date: 2018-08-31T00:21:02.545Z

Hey Token Magicians,
We are organising a Token Ring Meetup around the time of ETHBerlin.
Here are the event details and location: 0x Token Ring Meetup Tickets, Sun, Sep 9, 2018 at 1:00 PM | Eventbrite
Time: Sun, September 9, 2018 1:00 PM – 3:00 PM CEST
Location: Bar Hopfenreich Sorauer Str. 31 10997 Berlin Germany
Please post your name if you can attend and any agenda items you wish to propose. Hope to see you there and have a productive discussion on the future of Token Standards.
Attendees:

Remco Bloemen (0x Project) @recmo
Jacob Evans (0x Project) @dekz

Agenda:

TBD

Author: ligi
Date: 2018-08-31T10:45:17.023Z

My name is ligi and I would love to talk about token deprecation and updates. This is a common problem I see as a maintainer of ethereum-lists/tokens - would be super nice to have a way to have a token-contract interface to deprecate tokens and link to the newly deployed ones. Something like this - but on-chain as part of the token contract.

Author: ligi
Date: 2018-09-09T10:47:05.777Z

Hey - is this meetup still happening? If so I will be a bit late unfortunately - will have to demo 13:20

Author: p0s
Date: 2018-09-10T08:25:24.646Z

@dekz  Hey Jacob. I missed it. If you had it, it would be nice if you share the discussion/output here!

Author: dekz
Date: 2018-09-28T01:33:46.349Z

Will do, apologies for the delay. We attempted to video record but the Go Pro ran out of battery! I do have audio which I will transcribe and post shortly.
Title: Hybrid_POW_Pre_Proposal
Category: Magicians

Author: jpitts
Date: 2020-02-27T16:42:52.673Z

@karalabe proposed an interesting compromise on Twitter. Read his Tweet storm for the rationale, and other comments on that thread.

Shower thought: ProgPoW is nice, but it runs the risk of a net split. How about a hybrid PoW?
A HF would enable an Ethash/ProgPoW mix (initially 100% Ethash / 0% ProgPoW). Each block could move the ratio by 0.1% in either way. The ratio defines what PoW the next block has.

https://twitter.com/peter_szilagyi/status/1232979860513005569

Author: greerso
Date: 2020-02-28T02:15:20.684Z

Is this just about protecting investment in E3’s and A10’s?
It would be useful if those invested were honest about what they have at stake. E3’s are are dead either way and if no ProgPoW A10’s pushed out in weeks.
Title: NFT_Minimum_Sales_Price_Standard
Category: Magicians

Author: marco
Date: 2022-06-28T14:04:44.684Z

My team and I would like to introduce a new ERC standard to set a minimum price for an NFT.
Example:


Company releases collection A and user mint token B at a price chosen by A.


User wants to resell token B through a NFT marketplace.


The marketplace, however, must (as works for royalties with ERC-2981) check whether the NFT has a minimum selling price imposed by the creator of the contract. If it does, the user will not be able to list it for less.


This ERC can be used to sell real objects whose value can never drop in price but only increase over time.
Feedback, discussions, and comments are welcome.
Title: Good_first_issue_BUIDL_Explorer
Category: Magicians

Author: boris
Date: 2019-04-05T14:42:20.456Z

I found BUIDL Explorer on Product Hunt https://www.producthunt.com/posts/buidl-explorer
It’s a tool that links different Ethereum projects on GitHub, especially highlighting issues that are “good first issue”.
I’ve had this challenge myself in promoting EthMagicians issues.
This seems like a good way to promote how to get started, especially for non-code tasks.
Also, diving into Product Hunt again inspired me to put more time into that community to surface Ethereum related projects and services — and makers!
I’m going to mention this to Eth Cat Herders too, as they are the source of a lot of issues that are non-code.
Also this definitely is for developers, too! I want to see us onboard more open source contributors.

Author: burrrata
Date: 2019-04-17T17:18:00.671Z

This is cool. Thanks for sharing
Title: Paying_rent_with_deposits___Cross_post_from_ethres
Category: Magicians

Author: jpitts
Date: 2018-07-05T03:21:14.265Z

Posted by @Arachnid on http://ethresearh.ch:



Ethereum Research – 12 Jun 18




Paying rent with deposits




Sharding






storage-fee-rent





Thinking about storage rent - what about requiring a deposit for all storage used, instead of a rental fee? The deposit can be refunded in its entirety when storage is freed up, and provides a direct financial incentive to free up unused storage,...

Reading time: 4 mins 🕑
Likes: 14 ❤

Author: fubuloubu
Date: 2018-07-05T03:28:01.168Z

Isn’t this pretty much what happens now? We could increase the gas cost of SSTORE and have a more direct withdrawal when it’s reset.
Title: _POLL__PoS_durability
Category: Magicians

Author: Ethernian
Date: 2018-12-07T11:23:30.874Z

Are you believe in long-term economical durability of PoS?




Yes
No




0
voters

Author: Ethernian
Date: 2018-12-13T03:42:24.049Z

Ok, guys!
I like to see so many optimists here!
PoS requires working SoV (storage of value) function of the money on stake.
How can a PoS defend the SoV function of the money on stake while being attacked economically?
Is there any in-depth discussion of PoS durability against an economically superior adversary (a state with money press)?
Title: Tackling_the_hard_problems_in_Ethereum__what_to_na
Category: Magicians

Author: EvanVanNessEth
Date: 2023-07-04T18:06:39.891Z

I propose that the CL fork after Deneb be named Errai
Two reasons:


Errai is the future north pole star of the Earth, and will remain so for the next couple thousand years when it becomes so.  Perfect for Ethereum.


Prague will be the EL fork, and i like the combos of Errai and Prague better than I liked the combos of other E named stars.


Errague or (my preferred) Prarrai both sound decent, imho.

Author: abcoathup
Date: 2023-07-04T21:01:46.493Z

Also see discussion from March:



E-star name for Consensus Layer upgrade after Deneb Process Improvement


    Update July 14, 2023: Next CL upgrade named Electra on ACDC call 113 

An E-star name is likely needed for the Consensus Layer upgrade after Deneb, 
(e.g. Electra) upgrade could possibly be for the Verge + other features. 
The consensus layer uses star names for upgrades whilst the execution layer uses Devcon cities. 
See: Post-Merge Network Upgrade Naming Schemes 
Upcoming upgrade names: 


 Shapella (Shanghai + Capella)

 Dencun (Cancun + Deneb)

Making the next upgrade after th…

Author: abcoathup
Date: 2023-07-14T00:05:51.933Z

Next CL upgrade named Electra on ACDC call 113
https://github.com/ethereum/pm/issues/823#issuecomment-1635053770
Title: How_do_u_prevent_what_could_be_considered_double_s
Category: Magicians

Author: Shymaa-Arafat
Date: 2021-06-20T06:19:55.865Z

Let me start first by checking whether this site
https://blog.erratasec.com/2021/03/deconstructing-that-69million-nft.html?m=1
is a trusted source of information?
Then it’s written there
IMG_20210620_011356720×1600 224 KB
So what prevent the auctioneer from resell it again?
( make a new token  pointing to the same file?)

He used the example of a receipt, if a marchant signed 2 receipts for the same item u could press charges against him, what about NFT?

-I mean other than tampering or making a slight change, does the “create” or “transfer” functions check if the hash already exists, ie have been minted before? or they just verify it?
(A marchant could sign & seal 2 manual receipts to be only discovered in court, but a computerized system wouldn’t print a 2nd receipt from the beginning)
In one sentence
How does NFTs prevent double spending?or they just don’t?
Title: Advancing_EVM_Decompilation__Enhancing_Output_via_
Category: Magicians

Author: Jon-Becker
Date: 2024-12-12T21:18:16.379Z

This paper presents advancements in EVM decompilation techniques, combining traditional static analysis and symbolic execution methods with post-processing driven by Large Language Models (LLMs).
https://jbecker.dev/pdf/llm-postprocessing.pdf
Title: Solidity_related_proposal_re_opened__make_copy___r
Category: Magicians

Author: jpitts
Date: 2018-11-09T15:09:18.729Z

Solidity team lead Dr. Christian Reitwiessner originally opened the issue in June, 2017 but wishes for the discussion to begin again.


github.com/ethereum/solidity








Make copy / reference semantics more explicit



        opened 05:06PM - 21 Jun 17 UTC




          chriseth
        




          breaking change 


          language design :rage4:
        

          selected for development
        

          high effort
        

          high impact
        

          needs design
        




Implicit copy operations from storage to memory, from calldata to memory, from m…emory to external function arguments, etc is not possible anymore except for value types.

To make an ordinary value copyable, use the `copyof` operator: `x` cannot be copied, but `copyof x` can be copied. Using `copyof` twice is invalid. Storing a copyable type somewhere erases the copyable property again, i.e. `uint[] memory x = copyof y; c.f(x);` is invalid.






Related tweet: https://twitter.com/ethchris/status/1060829055556206592