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

Author: ligi
Date: 2019-01-08T17:06:27.302Z

Is it possible to ping a ring from a post?
E.g. I think it would make sense to ping the wallet ring about this EIP: Temporal Replay Protection
But I do not see a way currently to do so - the only way I see is making a post linking to the post above with the category wallet ring. But this does not feel right.

Author: jpitts
Date: 2019-01-08T19:10:51.552Z

We may be able to do this via “user groups”, I will open it up when I get a chance. It may require someone to look after the group membership in this Discourse setup though.


github.com/ethereum-magicians/scrolls








Maintaining user groups for Rings on the FEM Forum



        opened 07:08PM - 08 Jan 19 UTC


          closed 11:35PM - 12 Mar 19 UTC




          jpitts
        




          forum
        




This is for a @ligi suggestion for messaging members of a particular ring inside… of FEM Forum messages.

https://ethereum-magicians.org/t/ping-a-ring-from-a-post/2356

Author: boris
Date: 2019-01-08T19:15:36.467Z

Group membership can be set so anyone can join or remove themselves.
The @council-volunteers is an example of a group that people can add / remove to on their own – and I’m actually pinging 22 people by @-mentioning that 
So @ligi just ask for what group you want created and it should solve what you want to do.

Author: ligi
Date: 2019-01-08T19:49:41.662Z

boris:

So @ligi just ask for what group you want created and it should solve what you want to do.


I wanted to ping all wallet-developers. So a group for the wallet developers ring would be nice. But perhaps we should make it more general and have groups for all rings.

Author: boris
Date: 2019-01-08T19:51:28.537Z

Yes, see Github issue #14 where I first suggested it
Title: Push_batch_payments_using_selfdestruct_opcode_for_
Category: Magicians

Author: etherportal
Date: 2021-06-05T22:38:53.719Z

etherportal/EtherPortal: Safely push batch ether transfers - immune to reentrancy/fallback shenanigans, lower gas costs, and untraceable from recipient address (github.com)
Hi hope you can take a look at my first github repository, I think it presents a novel method of pushing batch payments with real world utility for existing projects.
Transfers made through the selfdestruct opcode do not trigger the fallback() function guarding against reverts/reentrancy/unpredictable gas costs.
The transfers are also untraceable from the recipient address, for example see https://ropsten.etherscan.io/address/0x60756E15b55a6d5320cb28D1915925B45BE6ccd6, which has 1 wei but no transaction history.
I also found a method to get significant gas savings by repeatedly invoking selfdestruct at the same contract instance, instead of creating a contract instance for each transfer. Due to the nuance of the opcode implementation, the selfdestructing contract remains accessible within the same transaction call, and can repeatedly invoke selfdestruct to continue sending ether.
For batch transfers to 100 existing accounts, this results in ~30% gas savings over direct transfers from EOA.
Title: How_will_shards_interact_on_ETH_2_0_
Category: Magicians

Author: Hikari
Date: 2020-11-04T22:04:18.025Z

Hello. I had read about ETH 2.0, and am still unable to understand how shards will work.
I see that Beacon blocks will have a reference to latest known block of each shard and each shard blocks will have the same for Beacon. I suppose that’s used so that a Beacon block indicates the state it recognizes and uses on each shard.
But how exactly will shards interact?
In example. Say that somebody wanna create TokenA. Will he be able to choose on which shard the creation tx will be commited? And once it’s done, will TokenA balance on all address be stored to that shard, or will we be able to move some balance to other shards?
If we wanna swap TokenA which is on shard1 for TokenB that’s on shard3, how will that happen? Using atomic swap?
And how about features like liquidity pools. If a smartcontract deployed on shard5 wanna use a pool on shard11, how will it happen?
Sorry for so many questions and tnx for any answer

Author: alwintech
Date: 2020-11-12T11:56:09.598Z

Ethereum 2. 0 Shard Chain
Shard chain in ethereum 2.0 store and process transactions. These shard chains are an important part of increasing the number of transactions ethereum can handle per sec. As per official beacon chain statement, Ethereum 2.0 will support 1024 Ethereum shard chains, each of which will be secured by a committee size of 128 validators. It is also important to note that transactions are only executed and validated within a shard, and that state is only stored at the shard level. These beacon chains to make sure every shard has the most up-to-date data with the help of validators who communicate the state of shard chains to the beacon chain. Like, this shard chain helps the network enhance performance in transactions scalability and securities.
To know more about Ethereum 2.0 details, visit our blog now @ https://alwin.io/blog/ethereum-2.0-notes-for-beginners
Looking for start your own DeFi or staking platform in Ethereum visit us today!

Author: Hikari
Date: 2020-11-12T15:55:36.324Z

I think it was reduced from 1.024 to 128 shards.
Still, it doesn’t explain how shards will interact as I asked.



 Hikari:

In example. Say that somebody wanna create TokenA. Will he be able to choose on which shard the creation tx will be commited? And once it’s done, will TokenA balance on all address be stored to that shard, or will we be able to move some balance to other shards?
If we wanna swap TokenA which is on shard1 for TokenB that’s on shard3, how will that happen? Using atomic swap?
Title: Is_everyone_getting_their_emails__Post_issues_here
Category: Magicians

Author: jpitts
Date: 2018-02-22T07:58:13.330Z

In the gitter channel I got some feedback that email confirmations weren’t going through. It looks fixed, but I want to know if there are other cases of lost emails.

Author: jpitts
Date: 2018-03-02T18:28:58.664Z

It turns out that the issue was not configuration but that I had not put in my CC at the email service! Emails should be going out more reliably now.
Ping me on the ethereum/governance gitter channel or here if you cannot log in or have not received a confirmation email.
Title: About_the_Magicians_category
Category: Magicians

Author: nicocsgy
Date: 2024-08-02T11:16:16.450Z

A place for casual discussions about Ethereum, site feedback, and topics that don’t fit into other categories use Primordial Soup
Title: Templated_contracts_Libs_in_Solidity_
Category: Magicians

Author: Amxx
Date: 2019-11-02T15:56:28.991Z

Hello,
While solidity native constructions like mapping and arrays are good enough for most use-cases, the inability to search an array in constant time, and the inability to traverse are mapping, are sometimes critical to smart contract developers. Combining the two into a richer structure trades compuation for storage. This trade might not be effective to everyone, but it is sometime necessary.
This thing is, many people are writting such structures, are re-use is limited by the specialisation of the type (are you considering structure containing bytes32? addresses? bytes4?). We could ask the devs to cast all inbound/outbound values, but that raises other issues.
In order to stop having duplicates of my structure in each an everyone of my projects, I made a dedicated package with code for sets (searchable list without duplicate) and map (traverseable key-value store). The “templating” is achieved using sed for text replacement … which is working but limited to natural types as it is not (yet?) smart enough to add memory/calldata where needed.
I’ll continue developping this repo, and everyone is free to contribute, but I think at some point this should be part of either the solidity langage or some recognised package like openzeppelin.
Is there any similar effort I might have missed? Have templated structs/contracts/libraries ever been considered in solidity?

Author: axic
Date: 2019-11-04T10:06:56.365Z

Is there any similar effort I might have missed? Have templated structs/contracts/libraries ever been considered in solidity?

I suggest to open one or more issues on GitHub - ethereum/solidity: Solidity, the Smart Contract Programming Language explaining what features you are missing. By searching open issues you may also find that some of them could be already under discussion. (There definitely is an issue about templates.)

Author: serapath
Date: 2019-11-12T13:27:47.620Z

Would you consider adding a README.md to your repository with an example and the rational behind it?
Maybe we can add you to https://smartcontract.codes  We are right now in the process of finishing our next release and that includes categories for popular libraries or contracts or generally just recommended ones so people can discover cool templates to re-use or at least learn from.

Author: Amxx
Date: 2019-11-15T17:38:03.744Z

I’m thinking of refactoring it … but I’ll push a readme next week anyway
Title: Targeting_Optimal_Staking_Percentage_and_Minimizin
Category: Magicians

Author: DB_1
Date: 2024-01-07T09:38:29.039Z

Currently we may have too many validators, creating challenges in aggregating signatures and overpaying for security. This is in part due to the Ethereum emission schedule. The proposed change adjusts the total emissions of Ethereum (ETH) to peak at 33% of ETH staked, decrease linearly to zero at 66% of ETH staked, and remain at zero emissions for any staking level beyond 66% up to 100%.
Motivation
The current Ethereum emissions increase schedule dictates an increase when more validators are joining, even when too many validators are participating. This modification aims more tightly control the  incentivization for staking, reinforcing Ethereum’s economic security and sustainability.
Specification

Emission Peak: Emissions go linearly from 0 to 33%, and peak when 33% of total ETH supply is staked. An APY of 10-20% at 10% staking and 3-4% at 33% staked can be targeted.
Linear Decrease: Emissions decrease linearly from the peak at 33% staking to zero emissions at 66% staking.
Zero Emissions Beyond 66%: Once 66% of ETH is staked, the emission rate stays flat at zero, regardless of additional staking up to 100%.

image1521×895 130 KB
Rationale
This emission schedule is designed to create a balance between incentivizing staking and controlling the inflation rate of ETH. By allowing the emissions APY to go to zero, we allow for better control over the number of validators. While the exact staking rate or APY, which also depended on unknown MEV rewards, cannot be predicted, this proposal guarantees both strong incentives for low double-digit staking percentage, and reduced cost to Ethereum when staking percentage becomes high. This can be further adjusted after restaking gains adoption, for peak emissions in the 10%-33% range.
By not going negative in any part of the curve, we ensure there is no incentive for vanilla (no MEV) stakers to leave.
Security Implications
This change is expected to enhance network stability by reducing the number of validators. It will reduce the economic guarantees of the network, however, these are arguably too high.  Additionally, the low/zero emission rate at higher staking levels reduces total ETH supply, contributing to economic stability.
Backward Compatibility
This change is backward compatible as it does not affect existing transactions or smart contracts. It only modifies the staking rewards calculation method and can be implemented with minimal disruption to the current Ethereum infrastructure.
Conclusion
The proposed modification to the Ethereum emission schedule aims to strike a balance between incentivizing staking, controlling inflation, and ensuring network security. This change is expected to have a positive impact on the Ethereum ecosystem’s long-term stability and sustainability.
Title: Ethereum_2_0_Upgrade_Process
Category: Magicians

Author: fubuloubu
Date: 2018-08-15T18:50:17.150Z

Shasper is coming, in whatever form it takes.
Things are changing daily, but I think the only thing that we can count on is that Ethereum 2.0 will be a separate chain or set of chains from the current Ethereum mainnet. I know there have been some proposals on how this upgrade process might look like, it’s been discussed before. I think the new innovation that has to come is a good plan for what the upgrade process looks like, and how that is communicated to the group.
Some parts of what I vaguely remember:

ETH on 1.0 can be upgraded to 2.0 via a locking contract to become a validator on the new chain.
a. There is some cool stuff we can do with that. Those wishing to be validators can offer a premium for buying the ETH over the current price to convince new people to join via some atomic swap mechanism.
b. Or that swap mechanism is just built into the protocol somehow
Dapp Developers will be asked to move over to the new chain at their conveinence up to some adoption date.
a. Does this mean some early dapps will have to support 2 different chains? How does this look for UX?
b. Some apps that have issues supporting hard forks (MakerDAO for example) will have to manage their process in whatever way makes sense to them e.g. liquidation of assets on the older chain and building assets on the new one.

I’m sure there are other things, but it would be nice to see a well thought out community plan for how this works next steps. Nothing would be worse than having the tech working and then having no plan to communicate to developers and users how to adopt to it.
Title: Announcing_the_First_EIPIP_Meeting
Category: Magicians

Author: souptacular
Date: 2020-01-13T22:20:01.448Z

The first EIPIP (EIP Improvement Proposals) Zoom meeting will be this upcoming Wednesday at 15:00 UTC (10:00AM EST). The EIPIP meetings are meant to spark discussion to streamline/improve the EIP process as well as finding ways to attract new EIP editors. I may stream the call, but will definitely upload it to YouTube after. I welcome anyone to join the call. To participate in the discussion and get the call information reach out to me on Telegram (@Souptacular) and I’ll share the Telegram chat link.

Author: jpitts
Date: 2020-01-29T02:54:18.792Z

The EIP improvement discussions are being facilitated by the Ethereum Cat Herders. Agendas and notes for the meetings are posted here:



github.com



ethereum-cat-herders/EIPIP
EIP Improvement Process. Contribute to ethereum-cat-herders/EIPIP development by creating an account on GitHub.





@anett and I also both know the Telegram chat link if anyone is interested in participating. This link is kept private for the time being due to problems with spam in Telegram  .
Title: Separate_Solidity_classes_from_contracts_
Category: Magicians

Author: Jules
Date: 2020-09-15T08:54:19.375Z

I’m suggesting that in a future version of Solidity, we explicitly separate classes from Solidity contracts.
That would mean that we could build a contract solution using 1 contract and a collection of classes.
I have written articles about Solidity class features and other Solidity foibles (in medium.com).
In conclusion, I think it would be very useful to have useable classes similar to non-blockchain languages:
class X [is Y] { // non-payable
    constants
    enums
    types (I wish!)
    functions
    blah
}

contract MyContract is Z { // payable
   X x;
   blah
}

Any helpful comments please.
Title: Suggested_structure_for_each_Working_Group_session
Category: Magicians

Author: jpitts
Date: 2018-07-12T15:15:07.665Z

Please use this format so that each working group can find its mission and follow through on that mission.
Initialize the work session

who champions this work?
who can facilitate the discussion? (please review How)
who can take notes? (please link to resources in a new thread on the Forum)

Describe what this group is focusing on
Take action by answering 6 questions

who are the stakeholders? (be specific)
what are the top concerns of the stakeholders?
how do we coordinate action?
how do we document?
how do we prototype?
what are the next actions?

Update the thread’s first post with the above information

add links to artifacts (Google Docs, HackMD pages, Telegram rooms, etc)
the notes-taker can present this at the end-of-day

Author: mattlock
Date: 2018-07-14T11:43:39.650Z

I made a photo album of the topics for archiving:
Here
Title: Edinburgh_Decentralization_Index___Invitation_to_C
Category: Magicians

Author: mtefagh
Date: 2023-11-27T12:04:16.891Z

Dear Ethereum Community,
The Edinburgh Decentralisation Index (EDI) is a project of the Blockchain Technology Laboratory (BTL) at the University of Edinburgh which will measure the decentralization of blockchain systems. The EDI will be used by regulators, developers, and blockchain users alike for different purposes. For instance, regulators can use it to help decide whether a cryptocurrency constitutes a security. Developers and users can use it to decide which chain is safer to build and use applications.
We are currently looking to extend the EDI by adding support for more blockchains. We would like to request your assistance in providing access to a full node as a data source, or to point us to someone in the community who might be interested in contributing. Other forms of contribution are also possible, see our GitHub repository.
Thank you for your time and consideration.
Best regards,
Mojtaba Tefagh
Blockchain Programme Manager
School of Informatics, University of Edinburgh
Title: ERC_Endowment_Discussion
Category: Magicians

Author: meknab
Date: 2019-04-23T21:37:16.277Z

Context: The concept for creating a ERC standard for endowments came out of recent discussions surrounding creating sustainable funding mechanisms for Ethereum development. By analyzing traditional funding mechanisms for public goods, there is a desire to explore if an endowment structure is adaptable to using tooling that has been developed by the Ethereum community for the benefit of the Ethereum community.
Preliminary conversations have suggested an experiment of a DAO structure that invests into a DeFi platform to accrue interest while also making regular distributions to projects.
Areas for further research include:

how would we go about selecting the DeFi platform? Suggestions have included Compound and Dharma.
Would these platforms allow a DAO onto their platform in the first place?
How long would we need to lock funds into the DeFi platform for?
Determine periods at which funders can enter and exit the DAO
There was discussion about forking the Moloch DAO code. What modifications would need to be made to ensure it meets whatever funding movement restrictions the DAO implements? Specifically the “ragequit” functionality
How would projects apply and be selected for funding? We would also need to compose standards to regular review/diligence of projects.
How regularly would funds be distributed to projects?
What is the target principle amount to get into the DAO and what should the target interest rate be?
How do we decentralize the power of the movement of funds and determine who should hold that power?
Does the DAO have any reporting requirements to its investors?

Please feel free to add additional questions as well as answers to this discussion.
Title: Is_there_a_Mastodon_server_for_Eth_
Category: Magicians

Author: kladkogex
Date: 2022-12-16T23:01:58.950Z

With the latest Elon Musk stuff,  should the Eth community run a mastodon server?

Author: xinbenlv
Date: 2022-12-17T00:24:48.909Z

Not that I know of. Happy to see something being setup

Author: SamWilsn
Date: 2022-12-17T14:26:16.289Z

https://cryptodon.lol/ is probably the closest thing.

Author: tim-cotten
Date: 2022-12-17T14:43:21.037Z

I’d love this and would happily help set it up.

Author: edmundedgar
Date: 2022-12-18T09:28:28.561Z

Yup, cryptodon.lol is the place to be. Here are some accounts to get you started. I’ll put people’s affiliations from memory, apologies if I get some of them wrong:
phil (@phil@cryptodon.lol) - cryptodon.lol - MEV research, runs the server
lefterisjp (@lefteris@cryptodon.lol) - cryptodon.lol - Rotki and stewardship of lots of projects
nick.eth (@weka@cryptodon.lol) - cryptodon.lol - ENS
Vitalik Buterin (@vbuterin@cryptodon.lol) - cryptodon.lol - had some role in ethereum early on, I forget the details
barnabé (@barnabe@cryptodon.lol) - cryptodon.lol - EF researcher
fradamt (@fradamt@cryptodon.lol) - cryptodon.lol - EF researcher
Neiman (@neiman@cryptodon.lol) - cryptodon.lol - Esteroids
Phil’s doing a great job running the server so I’d suggest reaching out to him if you want to help, but more options also wouldn’t do any harm.
Title: EIP_3279__Transaction_fee_share_by_smart_contract_
Category: Magicians

Author: tarekskr
Date: 2021-02-24T18:19:59.691Z

A lot of smart contract developers are not able to capture any value from their widely used smart contracts, and are thus forced to deploy meaningless tokens in order to be able to do so. If developers get a small share of all the fees generated by users interacting with their smart contracts, it will potentially solve the aforementioned problem. In addition, it will provide huge incentives for developers to choose Ethereum over other platforms for their applications.
I’ve already submitted EIP-3279 here: eip-draft-smartcontract-fee-share: Transaction fee share by smart contract deployers by tarekskr · Pull Request #3279 · ethereum/EIPs · GitHub
Would really appreciate it if someone is able to help me formalize the technical side of this EIP (specification, security considerations, etc.)
Title: In_one_swoop_the_ETH2_0_devs_destroyed_staking
Category: Magicians

Author: CryptoBlockchainTech
Date: 2021-10-31T08:39:56.854Z

Someone had the bright idea to take a constant earnings banking APR like system that paid people in model based rates that could be easily calculated out X number of years and decided we would rather have a lottery system (Altair). I and many others will now be leaving 2.0 once it is available. We did not come here to play the lottery and gamble earnings. We do not play the poor mans game of the lottery or casinos. Do not feed us the song and dance about how in the long run it will even out.
With this many validators it could take 1000s of years before bad luck equals out. Understand that we provide a service and are paid for it. While nothing was ever guranteed, changing the payment curve while we are trapped and unable to leave is unethical. We are done, the mass exodus will begin as soon as we can leave!
Next time better understand your clients and how they got where they are. Definately not playing the lottery!

Author: twice-blinded
Date: 2021-11-11T05:02:13.306Z

I don’t know what I find more interesting, your concisely written and rather scathing commentary - or the lack of response.
This is the place to find solidarity; yet here is open, unaddressed discontent.
I come here to represent a working class minority which often do not speak for themselves. The magicians here depend on us, yet ignore our formal public pleas.
If you leave you wont just be hurting the richest magicians here, you will be putting a lot of working class out on their ass - globally. The creators of the scheme have long cashed out.
I agree that something can and should be done right now, as you observed. We (the working class) have nothing to lose and the magicians wont see us (working class) gain anything. The way the network operates now, most workers can’t even get paid.
We would rather serve those who have our best interests in mind (potentially the interests you serve) and right now, we control the network. Not the magicians, or the validators. We are making this massive pump possible. We are moving the shitcoins and dogetokens back and forth all day, everyday. We are the ones allowing people to call smart contracts to run up unethically high leverage amounts - and we dont question it.
We operate the network with the highest security, not the validators. We each individually own our own tools, they are not property of the magicians here. We dont plan on getting rid of our tools as the magicians seem to hope will happen, we will secure a stronger network the moment we can and not feel anything about abandoning Ethereum to the doges, as it were. You can lose it all in an instant. Something for them to consider as they move forward.

Author: gcolvin
Date: 2021-11-11T18:07:23.550Z

The Magicians provide forums for discussion, consensus building, and review of all things Ethereum.  As Magicians we do not control the decisions of the Core Developers.  Technical discussion is welcome here, including with the core devs.  Direct engagement with their decisions is best done elsewhere.
@CryptoBlockchainTech @twice-blinded.
Title: Executable_beacon_chain___integrating_Eth1__now___
Category: Magicians

Author: jpitts
Date: 2020-11-26T17:07:15.346Z

“We propose to get rid of this complexity by embedding eth1 data (transactions, state root, etc) into beacon blocks and obligating beacon proposers to produce executable eth1 data. This enshrines eth1 execution and validity as a first class citizen at the core of the consensus.”



Ethereum Research – 26 Nov 20




Executable beacon chain




The Merge




Special thanks to @vbuterin for the original idea, @djrtwo, @zilm and others for review and useful inputs.  TL; DR an eth2 execution model alternative to executable shards with support of single execution thread enshrined in the beacon chain. ...

Reading time: 11 mins 🕑
Likes: 43 ❤
Title: Are_block_timestamp_and_block_number_still_problem
Category: Magicians

Author: Yleisnero1
Date: 2023-11-08T14:19:31.586Z

As stated in the SWC116 (SWC-116 - Smart Contract Weakness Classification (SWC)) using block.timestamp and block.number in Smart Contracts under Proof of Work was problematic.

Block.timestamp could be influenced by the miners up to 15s
Using block.number as proxy for time is inaccurate since the time between block depended on the difficulty i.e. was not fixed.

Do those two issues still exists under Proof of Stake? If not, are there any other/new concerns about using block values as a proxy for time?

Author: sullof
Date: 2023-11-10T01:57:03.860Z

The issue is still there, and as long as Miner Extractable Value (MEV) attacks are possible, will continue to be an issue. Just don’t use block.timestamp for anything critical.
Title: Documenting_data_transformation_implementations
Category: Magicians

Author: MidnightLightning
Date: 2024-11-18T14:44:38.782Z

Within solidity smart contracts, I’ve seen a few repetitions of different data-formatting algorithms like base64 encoding/decoding, JSON, and SVG. Rather than having smart contracts re-implement this logic over and over, I think it would be helpful to document any smart contracts that already exist as standalone Library implementations for any other contract to use (and smart contracts that have some algorithm’s logic baked in that would be good candidates for someone to refactor into a standalone library), so starting here with the few I know of:
Standalone Libraries

AVL tree (self-balancing binary search tree): Grove 0xD07cE4329B27Eb8896c51458468d98a0e4C0394C

Examples

SVG: MoonCatSVGs 0xB39C61fe6281324A23e079464f7E697F8Ba6968f
PNG (cyclic redundancy check (CRC) checksums): MoonCatAccessoryImages 0x91CF36c92fEb5c11D3F5fe3e8b9e212f7472Ec14
Base64: MoonCatAccessoryImages 0x91CF36c92fEb5c11D3F5fe3e8b9e212f7472Ec14


What others exist out there? A key algorithm that I’ve been thinking about trying to implement in Solidity is the DEFLATE (RFC-1951) decoder/decompression algorithm. This would allow data to be saved into a contract’s memory compressed, and then allow view functions to still be able to parse it. Does that exist anywhere out there on-chain already?

Author: MidnightLightning
Date: 2024-12-28T05:28:02.574Z

The Moonbirds project created an AssetStorageManager contract at 0xEDe24B4988cb64cC07fB72fF8AE71Bd8bB031b70, which includes in its source code an InflateLib.sol library that is a solidity implementation of inflating a DEFLATE-compressed stream, and is annotated as Apache-2.0 licensed.
https://etherscan.io/address/0xEDe24B4988cb64cC07fB72fF8AE71Bd8bB031b70#code#F3#L1
There is a standalone version deployed to 0x8d69408205dEc1F1Eb5A2250C8638017Ef6069b6 that has a single inflate function that accepts a tuple (uncompressed size, followed by the compressed data).

Author: MidnightLightning
Date: 2025-01-01T21:59:31.650Z

Merkle Tree: Murky project has standalone implementations of “full” and “complete” binary tree Merkle tree parsing. Unsure if these have been deployed to any blockchains as standalone libraries.
Title: An_open_source_Ethereum_block_explorer
Category: Magicians

Author: stev
Date: 2019-11-19T21:52:36.046Z

Hello everyone. ETC Core has built an open-source block explorer for the EthereumStack. We’d love to know what you think about this tool and how it can be improved.  https://expedition.dev/
dd1900×925 78.3 KB

Author: tay
Date: 2019-11-20T20:35:27.540Z

GitHub or docs available? would love to see the magic and stack behind it.
Thanks always for open sourcing.

Author: ligi
Date: 2019-11-21T03:27:41.657Z

Love the dark theme



 tay:

GitHub or docs available? would love to see the magic and stack behind it.


seems to be here: GitHub - etclabscore/expedition: 🧭 A block explorer for the Ethereum stack.
Title: Ethereum_PM_Calendar
Category: Magicians

Author: MadeofTin
Date: 2020-05-21T15:10:36.993Z

I created a calendar for Ethereum/PM



Google Workspace



Deelbare online agenda en planning - Google Agenda
Gebruik Google Agenda om vergaderingen te delen en afspraken te plannen. Zo kunt u beheren wat er echt toe doet, zowel op het werk als privé, met Google Workspace.





It will track the meeting that is listed in:


GitHub



ethereum/pm
Project Management: Meeting notes and agenda items - ethereum/pm





This includes the Stateless Ethereum Calls, and other EIP sync calls as they come up.
If you would like to be added to the invite list for the recurring ACDs call let me know here or in DM and I will add you to the list. It is a public calendar and should be accessible by multiple clients. If there are any suggestions on better tools to use let us discuss! I am happy to migrate to what is best for the group.
Cheers,
James
Title: Discussion__2_hop_Blockchain__Combining_PoW_and_Po
Category: Magicians

Author: samsam380
Date: 2022-01-21T15:51:42.170Z

Instead of moving ETH entirely from PoW to PoS Consensus mechanism, would it be possible to merge both PoW and PoS in parallel on 2-hop Blockchain like the one theorized here https://eprint.iacr.org/2016/716.pdf (2-hop Blockchain:
Combining Proof-of-Work and Proof-of-Stake Securely).
“From 1-hop to 2-hop blockchain. Nakamoto’s system is powered by physical computing resources, and the
blockchain is maintained by PoW-miners; there, each winning PoW-miner can extend the blockchain with a
new block. In our design, as argued above, we (intend to) use both physical resources and virtual resources.
That means, in addition to PoW-miners, a new type of players — PoS-holder (stakeholder) — is introduced
in our system. Now a winning PoW-miner cannot extend the blockchain immediately. Instead, the winning
PoW-miner provides a base which enables a PoS-holder to be “selected” to extend the blockchain. In short,
in our system, a PoW-miner and then a PoS-holder jointly extend the blockchain with a new block. If
Nakamoto’s consensus can be viewed as a 1-hop protocol, then ours is a 2-hop protocol.”
Merging PoW and PoS would prevent possibility of another hardfork by PoW miners after ETH moves to PoS, also it supports the PoW miners who had been supporting the network since its infancy, instead of ditching miners entirely wouldn’t it be better to integrate them into a new system where PoS and PoW can work in parallel, supporting each other.
2016-716.pdf
Title: Parallel_EVM_claim
Category: Magicians

Author: rakita
Date: 2023-07-09T18:42:16.849Z

Wrote something that could be of interest. If you have a DAG of transaction this post will explain how to verify that the claim of parallel execution is correct: Parallel EVM claim | draganrakita
Title: Discourse_Solidity_syntax_highlighting
Category: Magicians

Author: abcoathup
Date: 2019-07-05T07:48:11.994Z

Is Ethereum Magicians using Solidity syntax highlighting?
What did you use?
If not, then on the Zeppelin community forum we are using the following:


OpenZeppelin Forum – 27 Jun 19




Discourse Solidity syntax highlighting




General





Meta




I have installed the custom theme-component and enabled on the Light and Dark Theme.    We now have Solidity syntax highlighting.  pragma solidity ^0.5.0;  import "openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol"; import...





pragma solidity ^0.5.0;

import "openzeppelin-solidity/contracts/token/ERC721/ERC721Full.sol";
import "openzeppelin-solidity/contracts/drafts/Counters.sol";

contract GameItem is ERC721Full {
    using Counters for Counters.Counter;
    Counters.Counter private _tokenIds;

    constructor() ERC721Full("GameItem", "ITM") public {
    }

    function awardItem(address player, string memory tokenURI) public returns (uint256) {
        _tokenIds.increment();

        uint256 newItemId = _tokenIds.current();
        _mint(player, newItemId);
        _setTokenURI(newItemId, tokenURI);

        return newItemId;
    }
}
Title: An_offline_transaction_and_message_signer_for_the_
Category: Magicians

Author: stev
Date: 2020-02-06T16:40:16.239Z

Signatory is finally released! It’s an offline transaction and message signer for the EthereumStack. It can be used for any EVM-based network, interactive API docs, deployed as a stand-alone server, sign offline, and can be implemented in nodejs projects.
https://twitter.com/etc_core/status/1225174646724624394?s=20
Title: Gas_for_contract_code_length_on_creation
Category: Magicians

Author: efn
Date: 2019-11-13T13:52:09.622Z

Hello,
I was working on recreating contracts in multiple shards and measuring gas by the operations when I observed that a transaction pays for gas based on the contract’s length even when the contract code already exists.
When contract code exist nothing is really altered in the db so the costs are very inflated, that’s it if you don’t save the code in the transaction.
Instead of passing code in a transaction one could pass the hash under which the code already exists, saving a lot of gas in the process.

Author: Agusx1211
Date: 2019-11-22T10:30:26.379Z

A version of this already exists, using a MinimalProxies to delegate all calls to a “source” contract, is worth noticing that this “proxy” solution has two drawbacks, it has to write each contract to the database and also it has to load two contracts (and that adds an additional gas cost on each call).
How does the contract code storage “pruning” currently works? What happen if you selfdestruct a contract that has a “duplicated” one? does the db keeps a counter with how many accounts are using that code? does the database never deletes the code of selfdestruct contracts?
Title: Account_based_private_transaction_engine
Category: Magicians

Author: snjax
Date: 2020-10-15T14:08:40.304Z

Account-based private transaction engine
Prior work
Sapling is a well-known privacy engine, supporting N-to-M join-split transactions. For each spent note we should publish a separate nullifier. There could be the following issues:

Nullifiers take space onchain and require onchain computations.
Number of nullifiers of the transaction is known and it is a potential data leak.

This work
Let’s represent new object Account = (dk, pos, amount, salt), where dk is the decryption key or another private identity of the account, pos is the biggest position of the spent leaf inside the Merkle tree, amount is current currency balance of the account, and salt is a random blinding parameter.
The UTXO=(d, pk_d, amount, salt) will be the same as in Sapling. To reduce the number of circuit inputs we will store both UTXOs and accounts inside one Merkle tree. For example, for the N-to-2 case, even leaves will be accounts and odd leaves will be UTXOs.
To initialize accounts, let’s suppose, that there are any accounts with form (dk, 0, 0, 0) inside our privacy set. So, when we make the first transaction, we should publish the nullifier for the initial state of our account and we will never initialize any account with the same dk in the future.
To transfer, we put Merkle root, old account nullifier and output_note = hash(new_account_hash, new_utxo_hash) to zkSNARK’s public inputs, and data and Merkle proofs to private inputs.
The SNARK checks, that sum of output equals to the sum of input, the nullifier is valid, the user is the owner of the notes, the new account’s pos is greater or equals the previous one, and all nonzero UTXOs spent has a position between old and new accounts.
Advantages
We can spend any big number of UTXOs in one transaction without onchain overhead (and in-circuit overhead will not be so huge due to snark-friendly functions and novel proving systems) and data leaks.
So, it’s enough to publish 10 bytes per nullifier, 20 bytes per output note, and 4 bytes to link the Merkle root. 34 bytes total.
Disadvantages
The user should spend the UTXOs only one by one. So, the user cannot skip any number of dust UTXOs without burning them.
Author
Igor Gulamov, zeropool.network.
Title: Ethereum_Distribution_System
Category: Magicians

Author: peersky
Date: 2025-03-20T07:11:22.691Z

We’re seeking feedback on the Ethereum Distribution System (EDS), a project aimed at generalizing smart contract factory interfaces. You can find the code on GitHub: https://github.com/peeramid-labs/eds
Core Concept: Generalized Smart Contract Factories
EDS introduces the concept of Distribution and versioned Repository smart contracts, offering a standardized alternative to custom factory solutions. Developers can leverage these pre-built packages instead of reinventing the wheel.
Key Features and Benefits:

Generalized Factory Interfaces:

Create Distribution or versioned Repository packages, eliminating the need for custom factory solutions.


Decentralized Listing:

Anyone can list packages by implementing the Distributor contract, fostering an open and permissionless ecosystem.


Monetization and Control:

Distributors can monetize instantiation, manage package listings, and control version requirements, providing a flexible and sustainable model.


Enhanced Security and Interoperability:

ERC7746 (O(1) Vulnerability Management): Distributors can efficiently manage vulnerabilities.
ER7744 (Immutable Distributed Sources): Ensure trust and transparency by enshrining immutable source code.
Versioned Repositories (SemVer): Developers and users benefit from industry-standard semantic versioning for seamless upgrades.
Trusted Ecosystems: Contracts within the same distribution can leverage ERC-7746 hooks for robust authorization management.
Reusability and Modular Design: Enables the creation of complex applications by packaging and reusing different projects within the EDS framework.


User-Driven Upgradability:

EDS shifts the paradigm from developer-centric to user-centric upgrades.
Distributors and developers collaborate on new versions, making them available through the Distributor contract.
Users have the autonomy to disable trusted distributor checks and manage their instantiated infrastructure at their own risk.
When the normal upgrade path is followed, dApps can display a simple “Upgrade to Latest” call to action.


Storage Migrations:

Planned support for storage migrations (see milestone 2).



We have also added basic support to our  SDK which includes client library using viem & CLI:
peeramid distributions --help
Usage: peeramid distributions [options] [command]

Manage distributions

Options:
  -h, --help        display help for command

Commands:
  list [options]    List all distributions
  add [options]     Add a new distribution
  state [options]   Get the state of a distribution
  remove [options]  Remove a distribution
  help [command]    display help for command

Request for “Yay”
This project is driven by passion and a vision for a more efficient and secure Ethereum ecosystem. As an unfunded initiative, your support is crucial.
We’re seeking your feedback and “yay” to demonstrate community interest and traction, which will be invaluable when seeking funding from organizations like the Ethereum Foundation and Gitcoin.
Title: Providing_asorted_versions_of_solidity_compilers__
Category: Magicians

Author: hellwolf
Date: 2023-04-08T12:17:14.059Z

TLDR; get started in few steps:

Install the “Nix: the package manager” if you haven’t or not using NixOS.
Enable Nix Flake following the instruction in the link, e.g.:
add experimental-features = nix-command flakes to your ~/.config/nix/nix.conf.
Have any solc version available in your shell by running e.g.:
nix shell github:hellwolf/solc.nix#solc_0_4_26 github:hellwolf/solc.nix#solc_0_8_19

Full readme & repository
https://github.com/hellwolf/solc.nix/
Title: Gas_estimate_error_in_token_deployment_in_remix
Category: Magicians

Author: solomoney
Date: 2023-09-27T17:33:19.462Z

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
import “@openzeppelin/contracts/token/ERC20/ERC20.sol”;
import “@openzeppelin/contracts/access/Ownable.sol”;
contract FishTokenCoin is ERC20, Ownable {
constructor() ERC20(“Fish Token Coin”, “FTC”) {
uint256 initialSupply = 236700008000 * (10 ** decimals());
_mint(msg.sender, initialSupply);
}
// Mint new tokens and add them to the total supply
function mint(uint256 amount) public onlyOwner {
    _mint(msg.sender, amount);
}

// Burn tokens and subtract them from the total supply
function burn(uint256 amount) public {
    _burn(msg.sender, amount);
}

// Overrides the transfer function to check for valid transfers
function _transfer(
    address sender,
    address recipient,
    uint256 amount
) internal virtual override {
    require(sender != address(0), "ERC20: transfer from the zero address");
    require(recipient != address(0), "ERC20: transfer to the zero address");

    super._transfer(sender, recipient, amount);
}

// Overrides the transferFrom function to check for valid transfers
function transferFrom(
    address sender,
    address recipient,
    uint256 amount
) public virtual override returns (bool) {
    _transfer(sender, recipient, amount);
    _approve(
        sender,
        _msgSender(),
        allowance(sender, _msgSender()) - amount
    );
    return true;
}

}
the coding is correct but gas estimate error
Title: Addressing_Badge_Transferability__A_Proposal_for_T
Category: Magicians

Author: sullof
Date: 2023-06-30T21:20:09.283Z

The topic of soul-bound tokens, badges, and identity tokens has been a subject of discussion for some time, particularly the question of whether or not a soul-bound token should be transferable. If so, how should this be accomplished and who should be authorized to do it (the issuer, for example)?
We’ve made substantial progress in addressing the fundamental issues related to lockability, thanks to several EIPs that have explored the problem from different angles (EIP-5192, EIP-6892, EIP-6454).
However, one issue remains unresolved: the significance of a badge. If a badge is transferred, the recipient is not the original assignee. As a result, badges and soul-bound tokens are often viewed as inherently non-transferable.
After speaking with numerous people about this, Roy Liu and I devised a minimalistic solution that may already exist. If that’s the case, I haven’t come across it and would appreciate if someone could point it out to me.
Our proposition centers on the importance of the assignee - that is, the first wallet to receive the badge. To address this, we propose a minimalistic interface as follows:
interface ERC721Assigned {
    event AssignedTo(uint tokenId, address assignee);
    function assignee(uint tokenId) external view returns (address);
}

This interface tracks the original recipient of each token, irrespective of any subsequent transfers.
We’d love to hear your thoughts on this solution.
Title: EIP_Reader_s_Guide
Category: Magicians

Author: Pandapip1
Date: 2023-01-09T17:27:58.203Z

We have a guide for editors, and a guide for authors is WIP. How about a guide for people that read EIPs? It would contain stuff like “only final EIPs should be used”, and brief descriptions of each of the sections.

Author: xinbenlv
Date: 2023-01-09T18:47:01.729Z

I think this is a good idea.
Another thing: while reading an EIP, check the discussion thread for debate that leads to this final version for more awareness
Title: Proposal_for_zk_rollups_ensuring_data_availability
Category: Magicians

Author: HCP
Date: 2024-03-14T05:08:09.711Z

We propose new techniques for zk-Rollups in Layer 2 blockchain networks to ensure data availability and decentralization. Below, you will find the abstract of our paper.
The scalability limitations of public blockchains have hindered their widespread adoption in real-world applications. While the Ethereum community is pushing forward in zk-rollup (zero-knowledge rollup) solutions, such as introducing the "blob transaction’’ in EIP-4844, Layer 2 networks encounter a data availability problem: storing transactions completely off-chain poses a risk of data loss, particularly when Layer 2 nodes are untrusted. Additionally, building Layer 2 blocks requires significant computational power, compromising the decentralization aspect of Layer 2 networks.
We introduce new techniques to address the data availability and decentralization challenges in Layer 2 networks. To ensure data availability, we introduce the concept of "proof of download’‘, which ensures that Layer 2 nodes cannot aggregate transactions without downloading historical data. Additionally, we design a "proof of existence’’ scheme that punishes nodes who maliciously delete historical data. For decentralization, we introduce a new role separation for Layer 2, allowing nodes with limited hardware to participate. To avoid collusion among Layer 2 nodes, we design a ``proof of luck’’ scheme, which also provides robust protection against maximal extractable value (MEV) attacks.
The full version of our paper can be found at ([2403.10828] Data Availability and Decentralization: New Techniques for zk-Rollups in Layer 2 Blockchain Networks).
We are very keen to get feedback from the Ethereum community.
I’d welcome any questions or discussion here.
Title: Sharing_Common_Data_between_Solidity_Smart_Contrac
Category: Magicians

Author: Jules
Date: 2020-09-04T12:59:03.565Z

I’m aiming to create an Informational EIP about Sharing Common Data between Solidity Smart Contracts.
It’s similar to the Diamond Storage part of the Diamond Standard (EIP-2535).
I would like to check whether that will adversely affect anything that anyone else is working on.
Any comments gratefully received.

Author: jpitts
Date: 2020-09-04T21:11:57.599Z

It is great to have more Informational EIPs coming in!
This thread would be a good place to start collecting needs and impacts, and explore the general idea (this is why I labeled it primordial soup for now). Definitely expand on the basic idea here, and when you’re close to writing up an EIP more formally you can create a new thread within the category EIPs.

Author: Jules
Date: 2020-09-05T08:47:25.196Z

I am working on a Medium article about Smart Contracts Sharing Common Data.
Here is an illustration from that article, for a hypothetical example multi-contract solution, with a Router contract, a Producer contract and a Consumer contract:
800×450 65.2 KB
The Router must contain the data for all smart contracts.
The subordinate contract functions are invoked by Router using delegateCall.
Each data struct is located in the Router contract, but is located at a random slot along these lines:
contract QueueDataLocation {
    function queueData() internal pure returns (QueueData storage qds) {
        uint location = uint(keccak256("queue.data.location"));
        assembly { qds.slot := location }
    }
}

This contract may be used as a base contract by all the contracts which need to access the data.
In the example, that is the Producer and the Consumer.
I think that this pattern for sharing common data will be very useful for many multi-contract types. That certainly includes EIP-2535: Diamond Standard which specifies this way of sharing data amongst the facets of a Diamond.
But I think that this technique is more general than that and deserves its own EIP.
Any comments gratefully received.