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

Author: srarcharles
Date: 2024-08-20T03:13:08.934Z

Background

using PQC in the Blockchain mitigates risk of Quantum Computers’ attacks.
signature verification should be happened on on-chain code(solidity)
Clarify its possibility is a problem of realizability.

What I did

used SPHINCS+ as a post-quantum signature scheme

This is selected because NIST selected SPHINCS+ as a final candidate of PQC scheme

FIPS 205, Stateless Hash-Based Digital Signature Standard | CSRC





Result

I couldn’t realize verification on-chain, because it needs massive gas costs over block gas limit. (30,000,000gas)
So, it is impossible to use SPHINCS+ as a verification method.

Working Code

Abount SPHINCS+

https://sphincs.org/


GitHub - kasperdi/SPHINCSPLUS-golang: Implementation of the SPHINCS+ signature framework.
migrated from Golang code to solidity code
GitHub - blocq-inc/sphincsplus-verify-sol: solidity code for verify sphincs+ signature
Title: Bijective_Mnemonic_Phrases_for_addresses__hashes__
Category: Magicians

Author: osolmaz
Date: 2018-10-06T19:17:53.417Z

I hope this is not off-topic.
When doing data analysis on the blockchain, I have to deal with a lot of addresses. Trying to remember and discern them gives me headaches. I tried to offer a solution here:
https://osolmaz.com/bijective-mnemonics/
I need your feedback on this.
There is also an issue: The first word of most mnemonics start with the letter ‘a’, which kind of defeats the purpose. This is not due to an error, 20 byte addresses fall into a range where the base conversion results in this accumulation for the first word. I have a few solutions in mind, but first would like to hear your opinion.
Title: Discussion_about_proposed_Security_Model_for_EVM_C
Category: Magicians

Author: latrasis
Date: 2018-11-04T19:46:55.473Z

Hello, we’re currently working on an alternative security model and framework for smart contracts. Compared to existing alternatives such as AragonOS and Zeppelin it enforces permissions on-chain and can prevent privilege escalation at any point in the lifetime of a contract.
To read more please see our website and whitepaper.
If anyone is interested, we’re looking to get help on both the EVM implementation and EWASM implementation. Our current work is done here: repo link.
Title: Ethereum_state_trie_format_change_using_an_overlay
Category: Magicians

Author: jpitts
Date: 2020-03-26T23:38:37.767Z

This is a proposal by @gballet, articles and resources collected here for convenience.
“During the 1.x workshop in Paris last weekend, a couple ideas have been discussed for the transition from hexary tries to binary tries. It has been agreed that each proposal should be published on ethresearch for comparison and further discussion.”
Overview article
“The proposed process introduces a transition period during which two trees are maintained. This has the advantage that the main chain can keep operating while the tree is being converted, and it also ensures that all accounts will be translated to a binary format.”
https://medium.com/@gballet/ethereum-state-tree-format-change-using-an-overlay-e0862d1bf201
The main discussion for @gballet’s proposed is on ethresear.ch
“A hexary to binary conversion method in which new values are stored directly in a binary tree sitting ‘on top’ of the hexary, while the ‘historical’ hexary tree is converted in the background. When the process is finished, both layers are merged.”



Ethereum Research – 12 Mar 20




Overlay method for hex -> bin tree conversion




Execution Layer Research




During the 1.x workshop in Paris last weekend, a couple ideas have been discussed for the transition from hexary tries to binary tries. It has been agreed that each proposal should be published on ethresearch for comparison and further discussion....

Reading time: 5 mins 🕑
Likes: 13 ❤






“Quick and Dirty” prototype implementation in geth (a pull request)


github.com/holiman/go-ethereum








[PoC] Snapshot to bintrie


trie_gen ← gballet:snapshot-to-bintrie



          opened 03:20PM - 23 Mar 20 UTC




            gballet
          



+1010
-1






Quick and Dirty prototype to build a binary trie from the snapshot, aimed at pro…ducing initial data for [1]. It doesn't do any caching, it doesn't do any parallelism, doesn't try to save memory and it stores branches very inefficiently.

@holiman it's also based on a pre-rebase version of `trie_gen`, I'll rebase if it helps/makes sense.

### Refs
 1. https://ethresear.ch/t/overlay-method-for-hex-bin-tree-conversion/7104/3

### TODO

 - [x] rebase
 - [x] pruning
 - [x] extensions
 - [x] parallelize generation and db writes
 - [x] rework storage format
 - [x] benchmark tests

### Running

This adds a `bintrie` subcommand to `geth` that takes the current snapshot and performs the conversion based on that, so conversion can be started with:

```
geth --snapshot bintrie
```







Background
Understanding Trie Databases in Ethereum
https://medium.com/shyft-network-media/understanding-trie-databases-in-ethereum-9f03d2c3325d
Modified Merkle Patricia Trie Specification



GitHub



Patricia Tree
The Ethereum Wiki. Contribute to ethereum/wiki development by creating an account on GitHub.
Title: Post_Quantum_Proxy_Contract_Pattern
Category: Magicians

Author: srarcharles
Date: 2024-06-29T01:44:56.412Z

I want you all to check out my idea.
New “Proxy Pattern Smart Contract with Quantum-Resistance Ability”
I’m concerning about quantum-computer’s attacks on Proxy contract. It may become single point of failure(SPOF) for many smart contract(DApps like LIDO, DEFIs, etc…) because malicious quantum attacker can upgrade proxy’s embedded address to any address they want without users knowing it have happened.

About commonly used “Proxy Pattern”
Proxy Upgrade Pattern - OpenZeppelin Docs

But, I find out new smart contract to protect it to be attacked when secret keys of smart contract owner of proxy contract is stollen.
ProxyWallet-eng2071×1930 275 KB
Above is new scheme of smart contract with ability to prevent the attack to Proxy contract.
Main Point is…

Proxy contract’s implementation addresses can only be upgraded through the authentication by post-quantum signature scheme(like Lamport Signature).

So, malicious attacker can not upgrade Proxy contracts’ implementation addresses with Alice(Owner)'s secret key.
I also have written minimum implementation with tests of this idea although authentication part is not implemented(because any Post-quantum signature scheme can be embedded there like Pauli Group’s Lamport Signature Authentication)

This repository includes minimum implementation of quantum-resistant proxy contract. (I called it ProxyWallet)



github.com/starcharles/quantum-resistant-proxy-contract


test/ProxyWallet.spec.ts

main

import {
  time,
  loadFixture,
} from "@nomicfoundation/hardhat-toolbox-viem/network-helpers";
import { expect } from "chai";
import hre from "hardhat";
import "@nomicfoundation/hardhat-ethers";
import {
  getAddress,
  keccak256,
  Abi,
  parseGwei,
  getContract,
  TransactionExecutionError,
} from "viem";
import { AbiCoder } from "ethers";

describe("ProxyWallet contract", function () {
  async function deployFixture() {
    const [owner, addr1, addr2] = await hre.viem.getWalletClients();




  This file has been truncated. show original





This includes

Contract code to realize my concept.
Tests to confirm desirable behavior of the contract.

Please feel free to give me any comments and further implovement idea.
And If this idea make sense or valuable for Ethereum Community, I want to propose this as new ERC.
Thanks for reading.
Naoto Sato (Blocq, Inc)
Title: Discussion__A_token_standard_for_Authentication_Au
Category: Magicians

Author: 3braheem
Date: 2022-12-17T02:12:12.367Z

Related: ERC-644 Proposal
I wanted to bring up a discussion on proposing a standard for a token with properties specific to use as a tool for authentication/authorization, because in my opinion, this could be key to integrating web3 into the greater internet further.
There are benefits to the use of on-chain assets for auth, namely streamlining the onboarding process for access permissions by associating a wallet with those permissions. Companies/organizations could benefit from a faster, reliable process to hand out permissions through company wallets, which would likely see more use as web3 protocols develop further and offer more productivity value.
An issue I see with trying to implement something like this is the nature of our current ERC token standards, they are simply not made for this type of functionality. ERC20/721/1155 etc. do not have the features necessary to implement this well, for example, I think its pretty clear a company wouldn’t want its employees to be able to trade permissions online.
Let me know what you think on the usefulness of a standard like this, because I see many possible applications for web3 auth tokens that could have a lasting impact on software.

Author: vaumoney
Date: 2022-12-17T22:44:56.309Z

Think of an (a) open source service token and an (b) ISP wallet, authority.
I think upgradeContract permissionToken permission balance is useful for an RLP NodeList Open Source Authority for (A) programmatic minting (“gateway”…) or (B) wallet recovery and generation. The custody differs for the service, like Digital Ocean, who does provision (a) deployment logs for their buildpack apps (i.e. ex-droplet). Phone Authentication, the app developer, and the Identity Provider can (b) begin the chain track implementation, or recover any publicId balances (using a dashboard like Firebase/Identity Platform, and setting allowed domains), not mint.
This recoverable open source layer I want to use in front of USDC tbills or even better, capital currency stock; I’m not sure why ACH reconciliation and card issuers won’t allow nonfinancial banks unless we use blockchain (i.e. Mastercard, potentially non-U.S.), but the Ummah can only take introspectively equal and full measure, as ability makes need and takes from market, and I agree bond-purchases are stolen from an in balanced market towards the right to ownership. So here is either a coincidental or compelled use case need, but I’m not forfeiting my desire to use ACH even without Ethereum in this statement; this use case is important - as we likely all know - for wallet custody recovery, generally.
Title: A_simple_design_for_algorithmic_quasistable_curren
Category: Magicians

Author: kladkogex
Date: 2022-06-23T19:40:44.185Z

Arguably the latest events have shown that algorithmic stable currencies are hardly possible, and the best is just to have 1:1 fiat in the bank.
For many transactional purposes, though, it would be OK to have a quasistable currency that has a slow varying exchange curve vs USD.
If I want to send money to a friend, I care that the exchange rate of this currency does not change much during the transfer.
The question, is then, what is the best design for an algorithmic quasi stable currency
A Uniswap like AMM with a large reserve does smooth out the curve, if the reserve is much larger than the daily exchange volume.
The question is how to stimulate people to put lots of money into AMM for a long time.
One possibility would be to pay staking rewards for depositing funds into AMM (in addition to AMM fees) and then require staking  for a long period of time (say 3 months)
Then the higher is the staking reward rate, the more money is in the AMM and arguably, the smoother is the exchange curve.
An added benefit of this design is that it creates an incentive to use AMM vs centralized exchanges

Author: 0xcacti
Date: 2022-06-23T20:21:43.142Z

This was the idea behind olympus no?  That did not work extremely well, although I am sure there is some contention over the way that it failed.
I think the problem with quasi/algo stables is that they all seem to require a constant inflow of cash/backing to be sustainable.  See bean, ohm, ust, etc.

Author: kladkogex
Date: 2022-06-24T12:30:07.841Z

Interesting
Thank you for the reference

That did not work extremely well, although I am sure there is some contention over the way that it failed.

May be the time was wrong …

I think the problem with quasi/algo stables is that they all seem to require a constant inflow of cash/backing to be sustainable. See bean, ohm, ust, etc.

Arguably one of the reasons fiat currencies are stable is central banks provide infinite liquidity to
national banks at low interest rates …
Title: Whats_the_best_way_to_add_timer_transactions_to_EV
Category: Magicians

Author: kladkogex
Date: 2022-01-17T14:00:48.437Z

At our project we are looking to add timer transactions to EVM, so one could, say, do something 10 years in the future. Essentially you want to call a smart contract at a given date.
My question is how to do it in a simple way that would not incur too much performance loss.
Title: Standardizing_marketplace__view__of_an_NFT_while_a
Category: Magicians

Author: tim-cotten
Date: 2021-12-12T17:29:16.643Z

Example Use Case: NFTs based on 3D Models
Benefit: Standardize the way marketplaces present the NFT (scene, lighting, orientation, camera) while allowing the user to provide their own presentation view definition.
Example:
A player in a popular MMO has an NFT representing their +10 Sword of Fire that has a translucent edge. They also have the ability to show it on their in-game character at a chosen orientation with the backlighting that shows it off (in their eyes) in the best way to other players.
However, when they move it onto a marketplace for an auction sale, the sword might be up against several other swords from the same game. Rather than have them all be in willy nilly orientations the NFT creator instead declared that all swords of this class have a default “view” so that they can be easily compared/contrasted visually.
This would make item preview windows in marketplaces be able to enforce consistency between iterations of similar objects.
In my case, I’m working on a fun Christmas project for jewels, and I want to give users the ability to assign their own custom JSON metadata to represent their proposed view (and also allow this to be rendered on my website) while also keeping a consistent system default view for sales/comparisons.
That way a blue diamond looks blue by default regardless of the user’s chosen lighting.
I envision this to be an interface similar to ERC721Metadata that exposes two functions: “canonical” and “custom”; each, like ERC721Metadata, pointing to a URI with a JSON file. The “canonical” will NOT be updateable, but custom will have a method to update it by the NFT owner.
The JSON file format is not fleshed out yet; it’d be good to discuss scene definition (for 3D), or background images/CSS effects (for 2D).
Title: Quadratic_Mempool_Service
Category: Magicians

Author: EdPantal
Date: 2021-04-30T00:40:26.822Z

Quadratic resource management is so powerful, fair and trustless, in combination with reflective L1 mempool modeling perhaps with oracles, service fee challenges could be tamed. There should be native L1 mempool algorithmic governance graced with a quadratic view of the demand.
I’m not an Ethereum expert, but I cannot believe that the L1 mempool is a free-for-all for miners.
Title: Community_guidelines_or_rules
Category: Magicians

Author: adamschmideg
Date: 2019-03-20T10:21:34.565Z

This is my take on it: 5 strategies of contribution · ethereum/wiki. If you know a better category to post it to, please, tell it.

Author: jpitts
Date: 2019-03-20T19:57:28.377Z

A good point to clarify on is that this is intended for written proposals and longer-form commentary, if I am understanding this correctly.
Title: Proposed__step_by_step_roadmap_for_scaling_rollups
Category: Magicians

Author: jpitts
Date: 2021-11-26T03:34:25.516Z

https://notes.ethereum.org/@vbuterin/data_sharding_roadmap
Proposed Roadmap
 Step 1: tx calldata expansion
 Step 2: a few shards
Step 3: N shards, committee-secured
Step 4: data availability sampling (DAS)
Related issues and questions
Optimistic and ZK rollups under sharding
 Who would store historical data under sharding?

Author: jpitts
Date: 2021-12-02T16:05:52.342Z

Also, there is this recent roadmap visualization.
image1196×1322 145 KB
Source: https://twitter.com/VitalikButerin/status/1466411377107558402
Title: Ethereum_Network_Upgrade_Process
Category: Magicians

Author: poojaranjan
Date: 2020-11-12T20:46:25.200Z

After spending a few months collecting feedbacks, questions/concerns, and evaluating the current process of the Ethereum mainnet upgrade, the EIPIP group recommended some changes to improve the Network Upgrade Process.
I’ve drafted a blog explaining the new process. This will be shared on the Ethereum Cat Herders Medium to make it more accessible.
@MadeofTin and I will be joining the All Core Devs meeting #100 to give a walkthrough (if time permits) and answer any questions.

Author: ryanschneider
Date: 2020-11-19T22:25:44.495Z

This looks awesome, thanks @poojaranjan!  I really like that the mainnet block number isn’t set until after the successful fork on the testnets, it makes the mainnet fork less a “fait accompli” and more something everyone can actually feel confident in.
Title: Ethereum_Magicians_EPICs_for_2019
Category: Magicians

Author: ligi
Date: 2018-12-08T11:51:26.529Z

The end of 2018 is near and triggered by this comment by @pet3rpan


github.com/ethereum-magicians/scrolls








Application to be an interim github maintainer



        opened 02:06AM - 04 Dec 18 UTC


          closed 12:27AM - 11 Dec 18 UTC




          pet3r-pan
        







I believe my 24/7 online internet presence along with my burning desire to clean… up the issues backlog may potentially be an welcome spiritual addition to the hallways of the often-quiet and echoy halls of the scrolls repository.

Officially as of today, AEST Tuesday 4th of December: 1:04pm - Aye, Pet3rpan of house Ethereum would like to announce an formal expression of interest to become an interim github maintainer. This was enacted upon the comment of recommendation from none other than the dark and mysterious fellow known as @bmann.






I thought it makes sense to think about plans and direction of the Fellowship in 2019. I would really love to see moving away from github and discord to decentralized solutions like pando for dogfooding and decentralisation reasons.
What are your ideas for the fellowship in 2019?

Author: Ethernian
Date: 2018-12-09T01:43:58.819Z

ligi:

moving away from github and discord to decentralized solutions like pando


is there any suggestions for decentralized googledocs?
Creating and maintaining document with tables, cross-links, TOCs is a nightmare in markdown. A decentralized wiki with a good visual editor would be great.
Title: Increasing_Crypto_Market_Liquidity_with_a_Market_M
Category: Magicians

Author: NicolaBernini
Date: 2019-02-05T15:13:46.091Z

Hi guys,
this is my first post and I’d like just to share the following idea
Introduction:

we all know the financial aspects of cryptocurrencies are important to make them work properly
for example in a PoW based consensus scenario, if crypto price gets too low for too long the miners would be hit economically as it mining would become unprofitable so they would eventually quit mining for that specific crypto making it more vulnerable to 51% attacks
this a structural, unavoidable issue related to PoW systems

Financial Workaround : Market Maker

improving market liquidity could be a way to make the price more stable over time so to “guarantee” miners (in PoW scenario) a fair reward over time
what about achieving this by implementing a “Market Maker Smart Contract” which autonomously trade according to some “Market Maker Policy” ?
Title: EVM_Evolution_Project_Outline___Dinner
Category: Magicians

Author: expede
Date: 2018-10-30T21:21:58.696Z

Plan
Following on from EVM Evolution Notes (Council of Prague), a few of us have been working on an plan for a first phase of EVM Evolution. This is really about getting EIP 615 (static jumps) and EIP 616 (SIMD) formalized, implemented, tested, and integrated into the various main net EVMs.
We’d love to get broad feedback, hear from any interested parties, and EVM maintainers. Feel free to comment in the thread here, or directly on the doc.


docs.google.com



EVM Evolution Project Outline
EVM Evolution This is a high level outline and proposal for funded work to support further evolution and improvements of the EVM. Extended discussions are taking place in the EVM Evolution mailing list: https://groups.google.com/d/forum/evm-evolution...





Devcon 4 Dinner
We’d also like to get some folks together in Prague while so many people are in town. This is a fully open invite, and we’ll post more information in this thread as details get firmed up. It will be the evening of Nov 1 or 2, after conference sessions. Opinions on which day are welcome in the thread below 
461×357 34.9 KB

Author: boris
Date: 2018-10-31T10:14:40.774Z

Also we have a curated EVM Evolution mailing list we’re just kicking off.
See https://groups.google.com/forum/m/#!forum/evm-evolution to sign up — you’ll need a Google account OR let us know your email address and I’ll add you.

Author: lrettig
Date: 2018-10-31T10:23:48.460Z

There’s been quite a lot of conversation the past few days among various core folks, both at the eth 2.0 workshop and at DevCon, about a more aggressive roadmap for eth 1.0 and EVM. There seems to be quite a bit of appetite and support for the idea. I’ll write up a summary of these ideas from my perspective as soon as I get a chance.

Author: boris
Date: 2018-10-31T10:42:49.725Z

We have consensus for November 1st.
@lrettig is hosting an EWASM breakout 2-4pm in Radiant Orchid.
We’ll meet there at 4pm (and encourage people to come to EWASM breakout), can use the room, and will then migrate to a restaurant somewhere offsite.
Spread the word!

Author: axic
Date: 2018-10-31T10:46:19.043Z

Note that we have an EVM Panel right after the ewasm breakout.

Author: boris
Date: 2018-10-31T10:59:54.852Z

@axic perfect - that’s where we’ll meet and AFTER that panel we’ll continue.
Title: Funding_and_ETH1x
Category: Magicians

Author: boris
Date: 2019-07-23T03:25:57.210Z

I sort of let myself get dragged into some Twitter threads today, and we’re just covering ground that I feel like I’ve already talked about many times.
I updated my Funding Experiments page on the EthWiki. It is editable by anyone, but it right now mainly is just me / my point of view. Meaning: please do edit / annotate / add links & resources etc – and we can use this thread more for discussion.
I think the Ethereum Stack is still the best, most adopted, most shipping blockchain stack there is. And I wish the ecosystem could improve more and more quickly. This mainly requires an investment of dedicated people time, and to get those dedicated people they’re going to have to get funded to work on various aspects full time. Or not, and things will improve more slowly or not at all.

Author: boris
Date: 2019-07-24T06:16:31.890Z

I posted this here precisely to not have to re-answer the same questions multiple times on Twitter.

Author: neozaru
Date: 2022-08-18T23:34:18.119Z

Hi. This currently redirects to Home | ethereum.org which I am not sure if the original was this one Ethereum Foundation & community grant programs | ethereum.org ?
Title: Do_you_think__should_EIP_website_support_LaTeX_
Category: Magicians

Author: chiro-hiro
Date: 2023-03-10T05:28:55.437Z

https://github.com/ethereum/EIPs/pull/4686
Apparently it didn’t work, so do you think enable LaTeX is a good thing?
Title: Deep_dive_into_Current_PoW_Difficulty_Adjustment_A
Category: Magicians

Author: jpitts
Date: 2019-04-06T07:29:07.287Z

Deep dive into Current PoW Difficulty Adjustment Algorithm and a Possible Alternative by @MadeofTin, with some previous research performed with @tjayrush
Title: Directory_of_rings
Category: Magicians

Author: MaxSemenchuk
Date: 2018-07-15T16:30:05.021Z

Just to keep up to date lets put a list of rings, their purposes and people behind. Please provide ideas, edits and feedback to this. Thanks!
Wallet Developers – improve UX, interoperability by @ligi
SecurEth – improve smart contract and dapp security by discourse.secureth.org
Signaling Ring – research and identify relevant signals, develop resources to consolidate signals and news in a trusted community forum, develop EIP(s) to integrate signaling with the technical governance process + Core Devs decision making. We’re chatting on Riot at the moment: #ethsignaling:matrix.org @GriffGreen @phillux @MaxSemenchuk https://riot.im/app/#/room/#ethsignaling:matrix.org
Fund Recovery Ring – research and develop technical frameworks for the recovery of stuck funds in cases where the “‘rightful owner’ of the assets is obvious and mathematically provable, and no user is being deprived of any assets” (EIPs 156, 999, 867/ERPs) @5chdn

Author: fubuloubu
Date: 2018-07-15T16:35:44.567Z

SecurEth - improve smart contract and dapp security discourse.secureth.org

Author: pmauric
Date: 2018-07-16T15:23:23.184Z

Looking forward to forging these Rings together!
Signaling Ring - research and identify relevant signals, develop resources to consolidate signals and news in a trusted community forum, develop EIP(s) to integrate signaling with the technical governance process + Core Devs decision making. We’re chatting on Riot at the moment: #ethsignaling:matrix.org @GriffGreen @phillux @MaxSemenchuk
Fund Recovery Ring - research and develop technical frameworks for the recovery of stuck funds in cases where the “‘rightful owner’ of the assets is obvious and mathematically provable, and no user is being deprived of any assets” (EIPs 156, 999, 867/ERPs) @5chdn
EDIT/Clarification: The signaling conversation that has lead to the site build and this pending Signaling Ring emerged at EIP0 Summit and continued at FEM Berlin, more recently in regard to how a Shasper EIP could go. The technical FEM group noted that even if non-binding signals were to be a part core dev conversations, they should be clarified and EIP’d.

Author: ligi
Date: 2018-07-17T09:15:59.385Z

Added the rings mentioned here in the github wiki now: https://github.com/ethereum-magicians/scrolls/wiki

Author: decanus
Date: 2018-07-24T19:55:27.885Z

pmauric:

develop EIP(s) to integrate signaling with the technical governance process + Core Devs decision making.


Doesn’t this kind of defeat the purpose that is the difficulty of ethereums governance, if we know suddenly bind all the non-binding signals we have?
Title: Payment_Splitter_2_0
Category: Magicians

Author: Garito
Date: 2023-11-30T12:30:25.863Z

Hi
I’m trying to develop a version 2.0 of payment splitter since v1.0 has been deprecated
in that version, I would like to use an ERC20 as shares and make it dynamic (on v1.0 the share distribution is static at deployment time)
I have the naive algorithm looping all stakeholders when a payment arrives. This should be unacceptable since will be O(n)
Can you help me develop the O(1) withdraw algorithm?
Thanks

Author: matejfalat
Date: 2023-11-30T15:39:53.025Z

Hi, maybe take a look at this. It’s called staking but it’s the same thing, ERC20 as shares and O(1) withdrawals and ETH deposits.
Title: Controlling_what_you_see__what_you_get_notified_by
Category: Magicians

Author: boris
Date: 2018-08-23T14:24:13.973Z

There are a ton of different ways to view the forums, which are specific to the person logged in. The default view is “latest” – so whatever topic has last been posted to will show up, which perhaps looks cluttered to you 
You can also view by categories: Categories - Fellowship of Ethereum Magicians
Also, per category, you can choose whether or not it shows up for you in Latest. The circle in the top right hand corner defaults to “Normal” I believe. You can mute it, get an email for every single new topic and new reply and various things in between.
Now that we have tags, the same can be applied to tags. So maybe you want to follow #browserextension everywhere, regardless of category, you can set your notification settings for that tag alone.
If anyone else has tips, screenshots, or other ideas on how to tune your Discourse forum experience, please share!

Author: AtLeastSignificant
Date: 2018-08-23T16:25:51.928Z

For me, there are a lot of topics on here that I’m not interested in / qualified to participate in.  I like seeing the latest stuff so that I can at least see the titles of everything, but I rely on the notification menu on my profile icon to actually keep me updated on changes in threads I am interested in.  I don’t like relying on tags to filter what I may or may not want to see because they are historically unreliable.

Author: boris
Date: 2018-08-23T16:52:58.870Z

Just documenting it for people who are new to Discourse. It puts most of the control in user hands in a very good way.
I also forgot to mention that many of the items I mention have RSS feeds which may work better for some people than email notifications.
Title: Community_Discourse_inspiration
Category: Magicians

Author: boris
Date: 2019-04-03T06:31:52.723Z

What Discourse or other forum sites that run open communities can we take inspiration from?
wiki mode, please add your own
https://npm.community/
Title: Short_mnemonics_for_addresses
Category: Magicians

Author: superlouis.eth
Date: 2024-10-06T14:15:39.058Z

Hello!
I have been working on a protocol to map addresses to short mnemonic phrases, to make it easier and safer to handle them. The concept is simple: every address that “appears” on the chain (sends/receive a transaction, smart contract creation, etc…) is assigned a position number. This number is then converted to a mnemonic as BIP39 does it for seed phrases.
Since the number is still rather small (less than 300M addresses have been witnessed on mainnet), the resulting phrase is short. With 11 bits per word, 8 billion addresses could be “encoded” on 3 words.
A demo can be tested here. It also shows how this can be integrated with ENS and used on any wallet/explorer that supports ENS offchain resolution:


addr.id



Monique
Monique is an Ethereum address naming service





This demo reserves 4 bits for a checksum. I thought it would help lowering the risk of typing a wrong word and getting a different address. However, every bit of checksum divides the number of possible addresses by 2.
I considered using less bits for the checksum, and I’m wondering if I should use a checksum at all: most of the addresses are garbage (old wallets, spam…) and the risk of generating a close mnemonic to trick a user into sending funds to an attacker was low. Especially since the attacker must detect the address at its creation.
A bigger address space would help integrate Layer-2 addresses without overflowing to 4 words.
Note: mnemonics for 3 or more words are immutable, they will always point to the same address. I reserved the 2-words mnemonics for ENS-like registration that will be mutable and transferrable.
I would be happy to hear any feedback regarding this idea. Also, what would be your opinion on the checksum ?
Thank you!

Author: Hugo0
Date: 2024-10-10T11:28:21.899Z

I think this is a great idea! I tweeted about this a while ago here. Maybe the discussion is helpful
I don’t think having 2 words for special addresses helps, what3words doesn’t do that for a good reason.

Author: wjmelements
Date: 2024-10-10T20:42:58.645Z

As for the phrase itself, a sentence would be most memorable, and this can be done by restricting the 3 words to Subject Verb Object.

Author: Hugo0
Date: 2024-10-10T21:00:01.432Z

Alice: “what’s your address?”
Bob: “I love d**k”
Idk if Subject Verb Object is a good idea honestly

Author: wjmelements
Date: 2024-10-10T21:13:30.908Z

There are sufficiently many english nouns that profanity can be avoided. However I do see a few grammatical issues for this unique to English so I agree it’s not great.

Author: superlouis.eth
Date: 2024-10-11T09:06:15.294Z

Thanks for the feedback! You’d be surprised to see how many 3-word combinations (from the default BIP39 list) make interesting (understand: funny and/or inappropriate) sentences. I thought I’d leave as little rules as possible and let randomness do its thing.
@Hugo0 I originally named the project “eth3words” because it started from the exact same idea
Title: IETF_105___EIP_process___Request_for_Conversation
Category: Magicians

Author: shayan
Date: 2019-07-11T16:09:26.920Z

Hi all Ethereum Magicians,
I’ve been talking about EIP process with @tintinweb for a while, mainly on the security consideration requirements. Also I have been passively reading on EntEthAlliance, OASIS progress https://notes.ethereum.org/Domx9MXtQNGjK_RIQPBMNg, and other similar initiatives. I applied for a HotRFC (https://www.ietf.org/how/meetings/105/hotrfc/) session in IETF 105 Montreal meeting and got in.
The session will only be for 4 minutes intro talk and hopefully get some interest to get IETF participants to discuss further on this subject in a side meeting (BarBof). I would like to get as much feedback as possible before this talk, mainly on what aspects of the EIP process could use input from IETF giants. But feel free to comment on anything related here.
Here’s our proposal:
11. Democratic Improvement Proposals for decentralization projects

Shayan Eskandari

Blockchain and DLT* based systems are waiting in the wings to join the
potpourri of core technology that makes up our future digital
lives. Both core internet infrastructure technology and many DLT
solutions have one thing in common: They are developed with a diverse
open source developer community and carry significant security
risk. To manage software change related risks both Bitcoin and
Ethereum - the second ranked cryptocurrency market - have derived
their own process of managing change proposals. For Ethereum changes
are discussed and agreed upon in the Ethereum Improvement Proposal
(EIP) process. However given the non-hierarchy management model, there
have been many approaches and obstacles to make this process as close
to a democratic procedure as possible. It is working, but far from
perfect and there are many good approaches and lessons learnt. EIP
requires input from experts at IETF to shape up and standardize.

This proposal is to introduce the EIP process to IETF participants and
possibly spring up a BarBof session. For now please feel free to email
us to discuss this further, we will create a mailing list when the
scope is more defined.

Shayan Eskandari: shayan.eskandari@consensys.net
Martin Ortner: martin.ortner@consensys.net

Previous discussions regarding Security in EIP process:
https://youtu.be/Au1Qll-86v0?t=18029

* Distributed Ledger Technology

Author: shayan
Date: 2019-07-21T23:07:27.253Z

You can find the slides for this talk at IETF 105 Montreal here:
https://datatracker.ietf.org/meeting/105/materials/slides-105-hotrfc-11-democratic-improvement-proposals-for-decentralization-projects-01
Title: E_star_name_for_Consensus_Layer_upgrade_after_Dene
Category: Magicians

Author: abcoathup
Date: 2023-03-10T08:00:14.946Z

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 that likely to be Prague + E star name.
@protolambda has already suggested Practra (Prague + Electra)

Electra would then be a great follow-up star name: Electra is a star in the Taurus constellation (bull after bear  )

(Apologies if I am stepping on the process for selecting star upgrade names as I’m not a core dev)

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

Ebla
Edasich
Electra
Elgafar
Elkurud
Elnath
Eltanin
Emiw
Enif
Errai


Poll
Poll is for signaling purposes only.


Preferred star name

Ebla
Edasich
Electra
Elgafar
Elkurud
Elnath
Eltanin
Emiw
Enif
Errai





0
voters

Author: gballet
Date: 2023-03-10T08:46:36.373Z

Pari suggested that the name for Eletra + Prague should be “Petra”, which sounds much nicer and pronounceable than Practra.

Author: abcoathup
Date: 2023-03-10T23:41:33.441Z

Enif + Prague could be Pranif

Author: hwwang
Date: 2023-03-23T14:38:02.485Z

Although Electra sounds good in pronunciation, I voted for Enif because Electra complex was on page 1 when I googled Electra.  It’s not the meme I’d want to play…
On the other hand, Enif: the brightest star in the northern constellation of Pegasus. ꒰ঌ ໒꒱

Author: abcoathup
Date: 2023-03-24T22:09:23.795Z

@timbeiko’s poll showed (some) community support for merged names (CL star + EL city)
https://twitter.com/TimBeiko/status/1638971921168756736

Author: abcoathup
Date: 2023-07-04T21:04:02.081Z

@EvanVanNessEth suggests Errai




Tackling the hard problems in Ethereum: what to name the CL fork after Deneb Primordial Soup


    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-14T00:05:18.975Z

Next CL upgrade named Electra on ACDC call 113
Title: Scheme_for_off_chain_signatures_and_encoding_for_o
Category: Magicians

Author: dekz
Date: 2018-08-09T23:30:57.277Z

Overview
There are discrepancies and nuances to encoding signatures for usage and verification on-chain.
ECDSA is the dominant form of proof and is comprised of v, r and s fields. Signers often return this v,r,s as an encoded hex string where the components are concatenated. In many EIPS and documentation the order is either v,r,s or r,s,v. In many signers the order is r,s,v.
As the order of these components is ambiguous it is often difficult to predict the signer behaviour and this is usually checked/fixed in library wrappers.
Formalising on a standard encoding will reduce library code bloat, reduce developer overhead and increase contract interoperability.
The case for v,r,s

The Ethereum yellowpaper often describes these parameters in the order v,r,s.
Ethereum Transactions signatures are encoded as v,r,s

ecrecover in solidity ecrecover(bytes32 hash, uint8 v, bytes32 r, bytes32 s) returns (address)

EIPs: 86, 155, 232 all use the order v,r,s.
ethereumjs-utils returns {v,r,s} object to avoid ambiguity.

The case for r,s,v

JSONRPC eth_sign returns r,s,v. First occurence seems to be here with no justification. This has propagated to many signer implementations.

Proposals

Off-chain always use v,r,s, so transactions and signing is the same order. On-chain expect v,r,s.
Return a v,r,s object from eth_sign so there is less ambiguity. On-chain expect v,r,s.

Future discussion:

v=v-27 vs v=27|28
A standard way to represent the signature type
Title: Today_is_a_proud_day_for_Ethereum
Category: Magicians

Author: CryptoBlockchainTech
Date: 2021-08-05T04:17:59.521Z

Congratulations to all that made this possible.
Title: How_the_Ethereum_community_could_begin_making_mean
Category: Magicians

Author: jpitts
Date: 2018-07-10T16:46:54.181Z

The issue is that it is incredibly difficult to coordinate large, diverse groups in order to produce compelling signals. In the absence of clear aggregate signals only the most prestigious voices or the voices which are able to most effectively astro-turf social media are heard.
…
Regardless of an organization’s formal governance process, improving the ability of the organization’s stakeholders to produce clear signals will improve governance outcomes.

https://blog.aragon.one/on-signaling-and-social-pressure-3d97afbea355

Author: fubuloubu
Date: 2018-07-12T00:23:45.956Z

Great article and very important topic.
Acknowledging your subgroup I think is very important to interpreting your signal. I like the idea of organizing by opt-in subgroups for voting purposes.

Author: Jackdurose
Date: 2018-08-17T15:04:42.374Z

This is I guess a bit old now, but I’ll weigh in anyway.
Signaling by coinvote is one of the worst ideas being promulgated in the space. Not only are token holdings an incredibly poor proxy for the expertise of the voter, but the very fact of conducting an open vote with a running tally to provide a signal biases the outcome.
It’s very much harder to harness the wisdom of crowds than the madness of crowds, and we risk prejudicing outcomes, and optimising for multifarious cognitive biases by taking such naive approaches.
I would instead advocate for a system with forced anonymity, where influence is distributed from some finite rate of reputation issuance, and allocated to those with the most meritorious proposals/arguments (with influence over that allocation of that reputation, being proportional to reputation). Critically, it would be important to hide the reputation of the poster, in order to allow such proposals to be considered on their merits, rather than their provenance.

Author: Ethernian
Date: 2018-08-17T16:17:54.550Z

@Jackdurose , thank you for picking the topic once again.



 Jackdurose:

I would instead advocate for a system with forced anonymity,
…
Critically, it would be important to hide the reputation of the poster, in order to allow such proposals to be considered on their merits, rather than their provenance.


There should be a way to sharp own focus by filtering out undesired posts. Otherwise we ends up in spam.
Do you know any other metric to build a personalized filter on?

How the Ethereum community … making … decision.

I am strong against to let community make any decisions. Community is not and have no governance body.
Anybody makes own decisions based on signalled decisions of others.
For example a core developer makes OWN decisions to implement/drop some EIP, based on signals from community.
Title: Understanding_delegatecall_And_How_to_Use_It_Safel
Category: Magicians

Author: mudgen
Date: 2021-07-24T13:07:02.191Z

eip2535diamonds.substack.com



Understanding delegatecall And How to Use It Safely
Some developers are afraid of ‘delegatecall’ because they have been told it is “dangerous”. Fear and danger come from not understanding how something works and how to use it safely. For example most of us are not afraid to drive a car because we...

Author: jdspugh
Date: 2023-03-06T05:51:42.975Z

DELEGATECALL by and large prevents users from being able to audit smart contracts and trust their execution. This is hazardous for the crypto ecosystem.
Title: Documentations_or_guidance_on_selecting_an_ERC_num
Category: Magicians

Author: jsonsivar
Date: 2023-03-02T21:04:53.385Z

Hello, just posting on behalf of the NFA team. We were wondering if there is more documentation or guidance on picking the ERC number.  We read EIP-1 and it says it’s picked by us but wanted to see if there is specific rules we should follow on the number.

Author: abcoathup
Date: 2023-03-03T03:23:45.480Z

EIP/ERC editors assign the EIP/ERC number.  Generally it is the (first) PR number.
Number gaming (e.g. creating issues/PRs to increase the number) will likely result in a different number being assigned.

From: EIP-1:

Once the EIP is ready for the repository, the EIP editor will:

Assign an EIP number (generally the PR number, but the decision is with the editors)

Author: stoicdev0
Date: 2023-03-03T21:30:37.879Z

I wish this was cleaner. We’re on 6 thousand something now and there are actually less than 600 EIPs. From my team we’ve proposed 5 EIPs and it would be much easier to remember (and maybe even consecutive) if they weren’t 4 digits each.
It’s small annoyance, but annoyance nevertheless.

Author: abcoathup
Date: 2023-03-03T21:52:12.975Z

There have been discussions previously of selling unused EIP numbers.
In my opinion, only a few EIP/ERC #s have strong name recognition: ERC20, ERC721, EIP1559, EIP4844, some of which are 4 digit #s.

Author: poojaranjan
Date: 2023-04-05T23:24:18.865Z

Every proposal needs a number but not all of them reach Final status.
We use a common repo to promote EIPs and this has to be done via Pull Request.
Allocating a different number to an EIP after getting merged to maintain the consecutive order is a bit complicated if looked at for maintenance purposes.
I suppose it’s a process decision made at the time which turned out to be working well so far.
Title: Smart_contract_properties_and_metadata__what_struc
Category: Magicians

Author: MidnightLightning
Date: 2023-05-04T03:06:34.668Z

Thinking through the different ways smart contracts present properties/metadata about themselves, I realized there’s a few different styles/standards:

ERC20-style
The symbol, name, and decimals properties of an ERC20 token are revealed as functions that are just their names (i.e. not getSymbol), and return a string.


Pros: Can be static strings, can be read by other smart contracts

Cons: Cannot be extended (must choose all the properties at the deploy of the contract)


ENS-style
ERC634 defines a text(bytes32 node, string key) view returns (string text) function. This allows any key to be input and receive a value back.


Pros: Infinitely expandable, can be read by other smart contracts

Cons: No built-in iteration/enumeration, need Events to know what custom properties have been set


JSON
The ERC72 Metadata standard indicates a JSON structure that could be returned from the tokenURI function.


Pros: Relatively human-friendly to read

Cons: No native builder in solidity, other smart contracts cannot use this data


In my experience, the “ERC20-style” is good for simple implementations that will only have a fixed set of properties (and in general, don’t put a get prefix on the name of the function when building this style).
For future-proofing, and allowing user customization, the “ERC634-style” seems strongest. However, it seems many projects gravitate toward the JSON-style output. For contracts that want to generate that JSON on-chain, it becomes more complicated, and the result cannot be read by other smart contracts.
Instead of JSON, why not something even easier for solidity to do (CSV or other text-delimited style)? Or why not more compact format (Protocol Buffers, or EVM ABI-encoded format)?
ERC634 could be aided by multi-call functions:
function text(bytes32 node, string[] keys) view returns (string[] values)

To return multiple values for a single node), and optional “enumeration” extension (like ERC721, to iterate by index through the key/value pairs for a node:
function textOfNodeByIndex(bytes32 node, uint256 index) view returns (string key, string value)

Or a “get all” function:
function textsOfNode(bytes32 node) view returns (string[] key, string[] value)


These example “metadata” structures have been built into other standards. Should there be an EIP for generalized property storage? Or an overall “best practices” set of guidelines contract authors should generally adhere to (similar to how Java programming typically has “getters” and “setters” on classes, that by convention start with “get” and “set”)?