Diegorb1329/eth_magicians_forum huggingface dataset:
Title: Help_with_old_smart_contracts_when_we_are_moving_t
Category: Protocol_Calls___happenings

Author: philipjonsen
Date: 2022-08-09T20:49:41.103Z

Hello my fellow magicans! So let’s start with some background information about me,I got intrested in blockchain around 2012-13 but back then bitcoin was still a little bit wishy washy, but then came Ethereum. So I really got into eth and loved all the talk about DAO’s, Dapps and all the functionallity the ethereum could bring to the blockchain techonolgy. So I started Investing in eth and other projects like many DAO’s, the original for example, databrokerDAO, DGD DAO, and also stuff like ENS, Blockchain diploma, BUSD, CRO, Cryptopunks, Cryptokitties,  EOS and many more, I helped crowfund these projects back in the days, also wrote some papers for bitshares around 2016 and much more.
But I have this problem that these contracts after my reasearch are outdated and need upgrading ethier trough proxys or the the other ways you can interact with old contracts. But the thing is that im no smart contract dev. So I basicllly asking my former community for some help and guidance on where  to turn or what to do with these old contracts? Can anyone help me or point me in a direction where I can get help with these? I will of course pay a certain % for the one or ones who can help me.
It’s been a long journey and I have basiclly just hold these contracts and never interacted with them, just let them run on the blockchain.
So not it’s 8 years later and things need to be upgraded, I’ve watched Vitaliks pod with Lex fridman many times about eth 2.0 and loved it. But im also a bit concerned about my old contracts. Where can i turn for help or can someone here help me? I would really appricate it.
Best regards Philip Jonsén from Sweden.

Author: philipjonsen
Date: 2022-08-10T11:59:41.262Z

Can someone answer me please? This is basically the last way I will turn to get help, I’ve tried with everything. Contacting wallets, different projects even ethereum.org and many more places but now one seems to be able to help? Where should i turn if not the core eth devs? I’m willing to talk about this very open and transparent I can show some pics of the contracts im holding. I can prove who I am, I can give conseunsus and everything is on the blockchain. I’m just pretty tired of being ignored. These four pictures are from myetherwallet(I had the beta version also back in the days, it was my first wallet). I also have contracts in mycrypto wallet. What should I do?
BCD-BUSD1920×1080 182 KB
ConsensusMultiSig-Cryptokittens1618×1059 177 KB
CryptoPunks-DGD1596×1076 164 KB
ENS-EtherDelta1617×1075 173 KB

Author: dylan
Date: 2022-08-16T03:34:26.221Z

Hi Philip,
Maybe if you can clarify some things it will improve your chances of getting help.
“I have basiclly just hold these contracts and never interacted with them” – what does this mean exactly? Have you deployed smart contracts on mainnet? Can you share an example of one of their addresses? …Or do you simply mean you own certain coins and NFTs?
Title: PeerDAS_breakout__16__February_4__2025
Category: Protocol_Calls___happenings

Author: abcoathup
Date: 2025-01-28T23:51:31.586Z

Agenda
PeerDAS Breakout Room #16 · Issue #1259 · ethereum/pm · GitHub
Title: Will_post_merge_ETH_clients_provide_better_interna
Category: Working_Groups

Author: cyrus
Date: 2022-05-23T20:19:11.878Z

I’m working with some extremely old contracts that have no event emissions, so I run daemons that watch for changes there instead.
If there are txs to my contracts I can detect potential changes; I grab the latest block and look at the hydrated tx list for “to” values matching my contracts.
Unfortunately I can’t easily detect internal transactions that alter the state of my contact. To my knowledge there is no easy way to do this; neither the “to” nor “from” values are addresses I can predict.
Will eth 2 clients and their http/ws endpoints allow easier “watching” of contracts in this manner? i.e. for changes in smart contract state, no matter the source, initial tx target or manner?

Author: wminshew
Date: 2022-05-24T17:21:29.443Z

v keen for the answer to your question, but in the meantime perhaps this is something a subgraph with callHandlers could help with?

Author: daniellehrner
Date: 2022-05-27T09:27:16.378Z

Most clients offer API endpoints to create the traces, with all of the details, of a transaction. For Hyperledger Besu you can find some examples of these traces in the docs: Trace types
If you search for tracing you should find the same for other clients.
Title: Fee_Market_Change_Working_Group_formation__and_my_
Category: Working_Groups

Author: AlexeyAkhunov
Date: 2019-04-25T12:55:58.765Z

There is already a great discussion thread going here
Vitalik has made a presentation on the 18th of April 2019: https://youtu.be/HaT-BIzWSew?t=4708
If you watch after the presentation, there is a short discussion.
Since then, @AFDudley agreed to become the leader of a working group who will be working on this change, and see it through the research, reference implementation (prototype), and test generation. Please message DM him or post here if you would like to join the group, with the thought of what you can contribute and how much of your time you would like to commit.
I would like to propose an amendment to the original proposal (which you can watch in the video link above). Instead of changing the meaning of some of the fields on a transaction, I suggest introducing a new transaction type, which will be used for the transactions following the new fee rules. The old, pre-existing transaction format would still exist (at least for some time). However, the initial gas limit increase will be created only for the new transaction type, and the old-style transactions will have to fit into the 8M gas like today. We make 8M a hard limit for the old-style transaction, and move the upward flexibility to the new-style.
Why?
Firstly, because it would allow introducing this change earlier. We would not need to coordinate the change with the wallet providers. The old-style transactions will continue working as is, and wallet providers will introduce the new one on their own schedule.
Secondly, if the theory behind this change turns out to be flawed, and the new fees will be costlier than the old one, it will not cripple the system because the old-style transactions will provide safety net. If, however, the new style proves to be successful, and the wallet providers are ready, then in the subsequent hard forks we can reduce the gas limit for old-style and increase gas-limit for the new-style based on the data.

Author: ligi
Date: 2019-04-25T13:03:19.046Z

happy to join this working group from the wallet side and implement this new transaction type in WallETH. Really think this is a good idea and could improve UX alongside the other benefits this change has. Thanks @AFDudley for taking the lead and @AlexeyAkhunov for your idea with the new transaction type - I think this can really help rolling this change out. Very much hope the fee market change makes it into the next HF.

Author: MadeofTin
Date: 2019-05-31T16:51:53.311Z

I didn’t see this cross post! Thank you for this Ligi!
Title: DevP2P_modular_layer_stack_proposal
Category: Working_Groups

Author: ferranbt
Date: 2019-03-20T10:06:35.671Z

https://github.com/ethereum/devp2p/issues/71
I made a proposal for a new devp2p stack. This approach follows the abstraction layers model where each layer of the stack is independent from each other. Each layer provides a transparent input without any specific format. An example of this approach would be the TCP layer. Many applications with different logic like SSH, FTP or TLS are built on top TCP without much friction.
Right now, the devp2p stack provides applications with a fixed message format  (code, message). This limits the functionality the protocols can have. This proposal provides a transparent interface for the applications so that they can build any type of communication mechanism they find suitable for each use case. This would make it easy to build new protocols and iterate fast on their design.
Title: Learning_from_latest_Bitcoin_Bug__Make_better_patc
Category: Working_Groups

Author: Ethernian
Date: 2018-09-23T01:30:23.827Z

Houston, we have a problem
Look at this tweet from Emin Gün Sirer ( @el33th4xor ):
The Latest Bitcoin Bug Was So Bad, Developers Kept Its Full Details a Secret
How concerning is the information on your scale?
I am VERY concerned. And not because of the bug, but because nobody in the world has ever noticed, that the patch did not fit to the bug description. Nobody has noticed, that the patch does MORE than promised. It is an evidence of very low security.
How many more patches do we have, that do not fit to patch description? Were there any backdoors or similar infiltrated with patches and nobody noticed? We just do not know.
What can we do? I would suggest to play a validation game.
The Auditor Game
The rules are not ideal, but it can be improved.

The released patch should be published for public review for a while before build release.
The patch MAY have some intentional bugs. They are submitted in hidden bug list.
Anybody may file a public statement about irregularities in the patch under review among with hidden statement whether the public statement made is (intentionally) valid or fake.
Other people can support or refute the review.
Correct answers are rewarded, wrong answers are punished.
Hidden bugs (if any) get revealed.
If there were any bugs found/revealed, go to (1)

Rules are not optimal and should be improved.
Any thoughts?
Title: Ethereum_Roadmap_on_the_Ethereum_Wiki
Category: Working_Groups

Author: boris
Date: 2018-12-04T20:33:59.316Z

I couldn’t find an #ethereum-roadmap anywhere, so I put up a new Roadmap page on the Ethereum wiki:
https://en.ethereum.wiki/roadmap
I also noticed, and left comments, that the EIP 1052 and EIP 1014 are both still in Draft state – they should go through Last Call / Accepted if they are going to go into a hard fork.
Lastly, anyone know rough dates for Constantinople other than Q1 2019? @5chdn?

Author: owocki
Date: 2018-12-05T14:27:15.837Z

This is awesome… Thanks Boris

Author: 5chdn
Date: 2018-12-06T18:44:59.889Z

boris:

Lastly, anyone know rough dates for Constantinople other than Q1 2019? @5chdn?


January 16th, 2019, 12:00pm UTC

Author: 5chdn
Date: 2019-01-02T11:43:21.207Z

Added “Istanbul.” (20 characters)

Author: boris
Date: 2019-01-02T15:16:36.822Z

@5chdn I had heard about a potential June / July 2019 hardfork (aka the first 6 month fork), and then 3 months.
Where did Istanbul timing come from? EDIT: saw your proposal. Will respond there.

Author: boris
Date: 2019-01-07T05:29:49.971Z

I created a page for Istanbul on the wiki:
https://en.ethereum.wiki/roadmap/istanbul
@5chdn it looks like 1052 and 1014 that are going into Constantinople never went through Last Call / Accepted. Clearly they are going in and are implemented, I’m just trying to see if they should get updated. Should I do a PR to show they are Accepted?
Title: What_are_the_most_important_topic_to_get_the_commu
Category: Working_Groups

Author: MaxSemenchuk
Date: 2019-09-01T15:18:07.030Z

After we’ve developed the https://tennagraph.com/ it was quite easy to go with EIP-1057 (ProgPow) for signal collection. But after that, we felt a bit stuck. We added EIP-2025, but it seemed it was hugely criticized, not sure if we (as the community) want to collect more signals on it.
Overall, one of the biggest issues right now is in the engagement of people to learn, care and signal. We can dig stances in twitter and reddit, or approach people directly in dm’s or surveys at the Devcon. Even use some resource like ethereum website or week in ethereum newsletter. We’re keen to experiment with it.
But as I’m not full head in the Ethereum politics, it’s not easy to understand what needs signalling. There’s not a lot of EIPs that need public discussion as it seems. We’re trying out things like "The Ethereum Ecosystem be funded through ecosystem would benefit from funding via some form of taxation" for wider political debate, but i’d like you to advise/recommend topics we want to learn more about. Please HEPL 
@jpitts maybe you can advise something

Author: jpitts
Date: 2019-09-02T13:35:01.478Z

It is hard to know exactly what kinds of feedback mechanisms would help core devs make decisions. One helpful thing to do would be to listen to the core devs calls, on Twitter, and elsewhere and determine when they discuss community sentiment, what their attitudes are about that.
Something I’ve believed for a long time is that general sentiment is a false signal. I believe that understanding the impact on stakeholder groups is essential to how decisions are made by groups such as core devs. And one thing to know is that the core devs themselves are an important stakeholder group.
Stakeholder groups in Eth1 protocol decisions:

protocol developers
miners
node operators for: exchanges, data services, etc.
dapp developers for: games, DeFi, DAOs, etc
early adopter users
traders
holders / investors

A person forms their beliefs about an issue or EIP and make decisions according to how they think the outcome would affect one or more of these groups. Signaling may have higher fidelity and impact if it follows the lines of stakeholder groups.
The challenge is to get the key people in the various groups to actually see the signaling mechanism as legitimate, and to use it.
Title: Security_Review_Period_for_Hardfork_Roadmap
Category: Working_Groups

Author: boris
Date: 2019-02-22T17:45:21.936Z

I’ve added a section to the Istanbul Roadmap page on the Ethereum wiki proposing a security review period for proposed Core EIPs.
This means having some people do security reviews – which might mean engaging external auditors. But it also means communication around the Core EIP proposals that are effectively Last Call, but focused on security issues. Pay attention, have a look, does this impact your current or future use cases.
I’ve suggested 2019-06-21 (June 21st), this is half way between the hard deadline for proposals, and the soft deadline for major client implementations.

Author: AlexeyAkhunov
Date: 2019-02-24T01:22:48.713Z

It is a very good idea. However, I would invite to think about this a bit more. Giving extra time will not necessarily result in more reviews, as we have seen historically.
As I suggested in my final part of Eth1x workshop blog posts, we may need to more “formally” appoint a reviewer (or two) for each change. Otherwise the time will drag on, and review will only happen just before the hard fork (and it does nowadays).

Author: boris
Date: 2019-02-24T06:57:35.520Z

I’m not suggesting more time.
Rather - a defined review period time where the specific purpose is security.
I also think we have to find funding to pay people for reviews. If people volunteer to do reviews as well — great! But I don’t think we can count on it.
Having people sign up to focus on reviewing all aspects of a change is definitely a good idea.

Author: maurelian
Date: 2019-03-05T14:45:48.036Z

Also relevant:




EIP: mandatory "Security Considerations" for EIPs EIPs


    Hi everyone, 
To better manage the security risks in the Ethereum Change Management Process we propose a change to the EIP minimum requirements to include a mandatory “Security Considerations” section for the documentation of security relevant information directly with the EIP. 
This proposal is adapted from the IETF’s Request for Comments (RFC) system (RFC 7322 - Section 4.8.5) where this is mandatory already. 
The Meta EIP is currently in Draft status. We would love to get you involved making …
  

I think embedding the security considerations into the EIP itself is important.

Author: boris
Date: 2019-03-05T15:37:52.631Z

Yeah there’s two parts to this. One is adding security requirements to EIPs, the other is a security review period for release planning.
This proposal is the latter  so: yes, AND.

Author: owocki
Date: 2019-03-19T23:10:53.702Z

For what it’s worth, Gitcoin has added a 20 ETH security bounty for EIPs which starts in Mid May.  https://github.com/gitcoinco/skunkworks/issues/89
Title: Community_Call__FISSION_Codes___Translations
Category: Working_Groups

Author: expede
Date: 2018-10-05T21:08:23.819Z

The FISSION Core team is scheduling the first of their regular community calls to introduce the EIPs, gather feedback, and talk through questions, suggestions, and get feedback on what would be useful codes that people would find helpful.

When: Friday, Oct 12, 8:30AM PDT (Meeting World Clock)
Where: https://zoom.us/j/942432904
Hosted by: @expede and @jenncoop

Here is the agenda / notes document: https://hackmd.io/HANxYaZ-Q52VfDCYp8eUiw
Please add yourself if you plan to attend, and add your questions there
We’re looking forward to speaking with everyone Oct 12 
516×376 93.5 KB
Prior Discussion

Tags

erc-1066
erc-1444


Project status posts

ERC-1066: Ethereum Status Codes (ESC)
Update on ERC-1066 Status Codes project
EIP-1444: Localized Messaging with Signal-to-Text
Title: Community_Call_with_Swarm___Storage_Rent
Category: Working_Groups

Author: boris
Date: 2019-04-24T16:53:19.827Z

From a discussion on Twitter about Storage Rent and Swarm:
https://twitter.com/AFDudley0/status/1121077041233842176
Please follow this thread if you are interested in a community call, and we’ll update it with timing – likely week of May 6th.
@AFDudley @AlexeyAkhunov

Author: edinalovas
Date: 2019-04-25T10:53:46.700Z

Hi All,
This is Edina from Swarm. I would like to organize a call with you guys, shall I set up a doodle?
At the Swarm Orange Summit in Madrid (May 23-25) we will have a workshop on Ethereum Blockchain on Swarm and would like to invite you there to discuss this further.
Best,
Edina

Author: tgerring
Date: 2019-04-25T16:46:04.106Z

Is there a particular time that workshop is scheduled for and are there any other topics that might intersect with this theme?
If there is sufficient interest, maybe it’s worth setting aside non-summit time to meet as well.

Author: tvanepps
Date: 2019-05-02T02:57:06.308Z

It really depends on @AFDudley / @AlexeyAkhunov’s availability. I will try to reach them.
A doodle poll would be good to coordinate on if they have time this week!

Author: AlexeyAkhunov
Date: 2019-05-02T06:44:57.781Z

I had a call with some of the Swarm team members yesterday. I suggest doing community call as a part of summit (if there is a space in the agenda)

Author: boris
Date: 2019-05-02T14:08:07.951Z

Ok. Or afterwards with a summary. Mainly want to help the Swarm team tell their story and have people have an opportunity to ask questions live. Will leave this for now - let us know if we can help.

Author: jpitts
Date: 2019-05-02T17:00:27.870Z

Are there conversations/topics which we can get started here in the meantime? It may help get organized before the “kick-off call” from the summit.
@tgerring @nonsense @AFDudley …  and also @tjayrush from the Data Ring

Author: tgerring
Date: 2019-05-26T11:23:05.541Z

On Day 3 of Swarm Summit, we had a 90 minute discussion on improvements towards Ethereum based on Swarm.
We agreed that it would be useful to store  Ethereum block data on Swarm as an idea to improve the synchronization experience of adaptive nodes.
@pipermerriam Was so kind as to capture this in the following proposal:  https://github.com/ethersphere/user-stories/issues/9

Author: shemnon
Date: 2019-05-26T14:10:58.719Z

The linked spec has only headers in its subprotocol.  Why only headers?  To do a full sync bodies are needed and a fast sync also requires receipts.  If you are only validating the chain head then you can use headers only.

Author: tgerring
Date: 2019-05-27T08:47:43.630Z

Lacking a more robust answer from someone else, my understanding is that it was a result of the desire to start simple and build complexity over time
Title: Notes_from_Subscriptions_Ring_2018_10_19
Category: Working_Groups

Author: owocki
Date: 2018-10-29T13:26:00.071Z

Notes from Subscriptions Ring 2018/10/19 are here =>  https://hackmd.io/xpaKz9UUTUGE_39pR5awQA
Title: _WhiSpeG___2__Status_Call__Code_name__Oscar_
Category: Working_Groups

Author: Ethernian
Date: 2019-01-10T17:59:44.822Z

Hello All!
We are planning to make a second call of the Whisper Specification Group.
Preliminary Agenda

Understanding Needs, Usages and Requirements of Whisper as a Messaging Protocol for Ethereum.
Use Cases: CANTO Project and other use cases on heterogeneous Ethereum L2 level?
Who is the Product Owner of the Specification Project?
Announcement of Pre FOSDEM Messaging Workshop

Steps to do.

Anyone and any new topics for the agenda are welcome.
Please signal your time in the Doodle for the call.
The poll will be closed at the weekend as latest.
P.S. Proposed time frames are quite inconvenient for users from Europe. Sorry for that. This is because we need to onboard Oscar this time. Last call was scheduled to impossible times for his time zone.
Title: Community_Use_Satisfaction_Survey_for_Eth_Classic
Category: Working_Groups

Author: stev
Date: 2019-10-31T18:08:54.069Z

Hello folks, If you are satisfied or dissatisfied with Ethereum Classic, then we want to listen.
Everyone from the EthereumStack is welcomed to participate.
Here’s the Google Forms link https://forms.gle/T21rAxNbgqdMkN8z9
Title: ETHCC_data_ring_survey
Category: Working_Groups

Author: ankitchiplunkar
Date: 2019-02-27T16:45:06.823Z

Hi guys,
I was discussing with Ed regarding conducting a survey before the EthCC data-ring discussions (similar to  https://docs.google.com/document/d/1iWjqyA_Ylg5szvQnYFrR-N0H_9mshM8ZU88c1fxlalI/edit and https://docs.google.com/document/d/1PS0k9MaKPdPwEw3Uh9rq7USjq7LcSpT6ICQUXRij4YE/edit) . The goal is to have more “data” points while performing the data-ring discussions.
I have made a google form and would be great if we can spread it around: https://goo.gl/forms/Xt3fdiQHzNGaaus63
@tjayrush, @jpitts what do you think?

Author: jpitts
Date: 2019-02-27T17:01:56.805Z

Thanks for organizing this @ankitchiplunkar!
I noticed that the Data Ring does not have an entry in the scrolls, the result of this survey can inform how the ring charter is written.
List of Rings: https://github.com/ethereum-magicians/scrolls/wiki
Ring charter template: https://github.com/ethereum-magicians/scrolls/wiki/Ring-Charter-Template

Author: ankitchiplunkar
Date: 2019-02-27T17:06:08.183Z

@jpitts my pleasure 
Do you know what is the best mechanism to spread this form around?

Author: jpitts
Date: 2019-02-27T18:36:06.622Z

IMO here is best, we should Tweet about it as well.

Author: ankitchiplunkar
Date: 2019-02-27T19:41:45.796Z

Have tweeted the google form link https://twitter.com/ankitchiplunkar/status/1100843121452158977 would be great if you guys can retweet it.

Author: jpitts
Date: 2019-02-27T20:37:06.134Z

Two things you might add:

An open question, e.g. “Is there anything you’d like to see discussed?” this way people can let the group know if they have additional things to consider.
Brief explanation of the group, or a link to Jay’s original post Is There Interest in a Data Ring?

Author: ankitchiplunkar
Date: 2019-02-27T21:08:47.454Z

Made the two changes
Title: CoreDevs_ETH1x___Istanbul_Meeting_July_Poll___Feed
Category: Working_Groups

Author: boris
Date: 2019-04-25T19:51:49.713Z

We’re in the midst of sending out wrap up emails and links from last weeks CoreDevs Berlin meetings.
Here is the email that went out: https://md.spade.builders/lXX8_RxoRGyr6zunhmTuqQ
Please also use this thread for feedback for those that attended, those that viewed the livestream, or those with other comments 

Potential Next Meeting
Here are two polls to gather feedback on timing and location of a next meeting.
We have one volunteer @meknab who has said she can help out on the ground in Seattle or NYC. If you want to volunteer in a location or in general help out, leave a comment.
More links and action items to be added to this post or in the comments.

Where we would you prefer to attend a next meeting?
Pick two.




Seattle
New York
Somewhere in Canada
Somewhere in Europe
Elsewhere




0
voters





When would be good timing to attend?
Pick one.




Week of July 22
Week of July 29
I don’t care about meeting in person
I can’t make it




0
voters

Author: cdili
Date: 2019-04-26T15:19:29.630Z

should there be some options in August?

Author: boris
Date: 2019-04-26T15:34:26.914Z

Feel free to propose! I picked the dates because I think you had DEFCON conflicts at some point? August 14th is Testnet deploy, so I didn’t want to conflict too closely to that. Essentially part of this would be to have clients & testnet folks coordinate.
Here’s also what I think the topics would be:

work on testnet / main net Istanbul deploys – so more let’s get prepped for testing, interop, and so on
kick off for April 2020 – pick a name, get dates from @shemnon Cheesy Hardfork Schedule, and essentially solidify what the next HF is
host working group sessions – now that we have a list of WGs https://en.ethereum.wiki/eth1 we can ask those people to organize and just help host them

Also: to state again – I’m floating this as a proposed option. Should CoreDevs meet ~3-4 times per year, with the assumption that DevCon has meetings as well?

Author: gcolvin
Date: 2019-04-26T16:16:20.103Z

boris:

en would be good timing to attend?


What does “Week of” mean?  2 days?  5 days?
About 20 family members converge on my place August 2, and we need time to get ready.

Author: boris
Date: 2019-04-26T16:16:57.996Z

It means some TBD days in that week that will likely be a max of 2 days.

Author: charles-cooper
Date: 2019-05-21T16:36:21.657Z

I can help out on the ground in Seattle.
Title: Ethereum_1_x_Proposal_Sync_01_Notes___Nov__30__201
Category: Working_Groups

Author: jpitts
Date: 2018-12-03T06:17:30.593Z

Note: Chatham House Rule applies to this meeting.

When a meeting, or part thereof, is held under the  Chatham House Rule , participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed.

Agenda:


github.com/ethereum/pm








Eth 1.x Proposal Sync 1 Agenda



        opened 09:50AM - 28 Nov 18 UTC


          closed 03:56PM - 03 Dec 18 UTC




          lrettig
        







# Eth 1.x Proposal Sync 1 Agenda
### Meeting Date/Time: Fri 30 November 2018 at… [14:00 UTC](https://savvytime.com/converter/gmt-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo/2pm)
### Meeting Duration 1-2 hours
### Call will not be livestreamed or recorded, but unattributed notes will be published ([Chatham House Rule](https://www.chathamhouse.org/chatham-house-rule)).

# Agenda
1. Transparency, note taking, Chatham House rules
1. Recap of Nov. 2 discussion
1. Simulation working group [proposal](https://docs.google.com/document/d/1pIW6Uac5Qanx_L5Y_G4Ucrx_gjITkBgzQKmlBQbW3Cg/edit)
1. State rent working group [proposal](https://ethereum-magicians.org/t/ethereum-state-rent-for-eth-1-x-pre-eip-document/2018?u=lrettig)
1. Ewasm working group [proposal](https://ethereum-magicians.org/t/ewasm-working-group-proposal-for-eth-1-x/2033?u=lrettig)
1. Chain pruning [proposal](https://gist.github.com/karalabe/60be7bef184c8ec286fc7ee2b35b0b5b)
1. January workshop update (Joseph Chow)
1. Continuation of transparency discussion (if necessary)






Notes:
https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Eth1x%20Sync%201.md
Title: Signalling_Conversation_underway_in_a_different_th
Category: Working_Groups

Author: RexShinka
Date: 2019-03-02T14:15:07.991Z

Please be aware that I started an active signaling conversation in the Process Improvement thread. My apologies, I should’ve started it here.




Governance Voting Concept Process Improvement


    Governance Voting Concept
Why?

I feel Ethereum desperately needs an agreed decision making process before the next difficult decisions occur.
Has to be something we can implement now, using existing technology.
Has to be public and fair (though that is very relative).
Barriers of entry must be low and fair but not nothing. .
This paper puts forth the concept for discussion. It is not a complete system with all the rules needed. If there is enthusiasm, it could be quickly matured.
This concept i…
Title: Open_Protocol_Interfaces__OPIs__discussion_from_04
Category: Working_Groups

Author: jpitts
Date: 2019-05-06T06:34:24.495Z

Open Protocol Interfaces: Getting useful data out of Ethereum is really hard by @ricburton.
A related discussion wa organized by Balance.
Transcript of the meeting
Sound recording
Participants:


Lane Rettig from WASM and CryptoNYC

Jin Chung from Balance

Qiao from Messari

Chris Burniske from Placeholder

Kurt Fenstermacher from Digital Assets Data

Thomas Rush from Quickblocks

Author: ricburton
Date: 2019-05-09T15:44:18.370Z

I am excited about the work Yaniv and the team are doing at Graph Protocol.



The Graph



The Graph
The Graph is an indexing protocol for organizing blockchain data and making it easily accessible with GraphQL.
Title: Ethereum_1_x___Ewasm_Working_Group_proposal__dupli
Category: Working_Groups

Author: axic
Date: 2018-11-27T14:30:20.287Z

The Ewasm team has published the initial proposal for introducing a subset of Ewasm as part of the “Ethereum 1.x” effort:


docs.google.com



Ethereum 1.x - Ewasm WG Initial Report (published version)
Ethereum 1.x - Ewasm Working Group Initial Report 26/11/2018  Executive Summary Enhancement of the Ethereum protocol is hindered by the inflexibility of the EVM architecture. The method of extending the execution layer has been the introduction of...





We are looking forward to have a healthy discussion.  Please feel free to leave comments on the document or have discussion here.

Author: boris
Date: 2018-11-27T14:41:14.748Z

Hey @axic looks like @lrettig already posted  Ewasm working group proposal for Eth 1.x
Title: ABI_Specification_Working_Group
Category: Working_Groups

Author: fubuloubu
Date: 2018-11-20T18:38:10.500Z

Hey all!
We started the ETH ABI Working Group, which is aiming to standardize the ABI Interface Specification for Compilers, Web3 libraries, and other tools. If you are in one of these groups that consumes the ABI specification, please let me know so I can add you to this working group.
We also aim to create a standard test suite for ABI encoding/decoding that all of these groups can use to supplement their testing suite (and eventually merge all core featureset tests!).
Organization: https://github.com/ethabi

Author: Ethernian
Date: 2018-11-21T01:22:32.144Z

I have gathered a small and focused task force for whisper specification.
It could be part of this group, imho.

Author: fubuloubu
Date: 2018-11-21T14:13:38.846Z

Perhaps we could share approaches, but I think being focused is a strength. Contract ABI and Whisper don’t strictly affect each other.

Author: Ethernian
Date: 2018-11-21T16:13:47.476Z

fubuloubu:

Contract ABI and Whisper don’t strictly affect each other.


for sure not. It it is ABI specification group only.

Author: xinbenlv
Date: 2022-11-11T19:04:24.351Z

Hi from 2022,
Here is one other latest case demonstrating it’s good for having an ABI representation in EIP spec


github.com/ethereum/EIPs








        Review by
        

          xinbenlv
         - Add EIP-5805: Voting with delegation


master ← Amxx:vote_with_delegation




LGTM!. While I reserve my opinion on this particular point but respect this is a…uthor's discretion at the technical choice made in this proposal.

That said, this different understanding about ERC20's `approval` whether they mean to be `payable` or `nonpayable` or _unspecified_ seem to hard to be represented in Solidity, and hence a good point to use ABI actually
Title: Data_Layer_in_ETH_2_0
Category: Working_Groups

Author: fubuloubu
Date: 2018-11-05T00:10:21.728Z

I had some interesting ideas I brought up in this ETH research thread that tie in with the data ring: data structures, how data is stored, storage rent, etc.
The TL;DR is that IMO the data and execution layers (together, the data model) aren’t that well formalized yet, and I think there is some opportunity for improvement as we transition to ETH 2.0
We should try and get some work going on this so we can help with this aspect of the spec.
Title: _WhiSpeG__Summary_on_current_Whisper_UseCases
Category: Working_Groups

Author: Ethernian
Date: 2018-12-20T22:04:57.533Z

Summary
One week ago I had a call with @atoulme about Whisper UseCases.
The idea of the call was to break various UseCases apart up to particular requirements and map it to Whispers features (either existing or desired). Unfortunately, we have not found a lot of new UseCases and they are not understood and specified with all the details. Therefore requirements for some general purpose messaging system like Whisper are still quite unsharp.
Here are my personal summary of discussions and readings last time.
Secure Messaging for Social Networks
This is usual and most defined UseCase. This classic paper provides great review of many aspects and features of secure messaging in general.
Status.IM Team works hard on developing of next generation messaging protocol and published some interesting works and link collection.
Looks like most developers (both Status and EF) consider current limitations are more in protocol itself than in its specification.
Secure Messaging for Machine Communications
There is an UseCase about Messaging for Network Configuration.
Nodes joining and leaving permissioned network need some kind of secure messaging for it.
CANTO proposal will need some messaging on the top of devp2p/RLPx to broadcast network changes.
Whisper fits requirements of this UseCase not in the best way, because Whisper’s PoW-based anti-spam protection is in trade-off with guaranteed delivery, which is much needed.
Conclusions
A native ethereum messaging is much required for interconnect between corporate networks behind firewalls, because connection from ethereum node to an external messaging service (like rabbitMQ) is fragile and opening additional ports is a pain.
Looks like the Whisper adoption (as the native ethereum messaging stack) stucks not on missing specification but more on gap between UseCase requirements and implemented set of features.
Current research on Secure Messaging brings set of trade-offs, but no single universal solution suitable for all UseCases. It means the native ethereum messaging should offer more flexibility among trade-offs than current Whisper implementation to fit different UseCases.
Research on possible UseCases is quite important and should be done first. I would look for new UseCases and for requirements on ethresear.ch.
Any objections and critic are welcome.
Title: ERC_827_callbacks_can_lead_to_reentrancy_attack_ve
Category: Working_Groups

Author: jpitts
Date: 2018-07-06T12:56:47.686Z

This is an interesting case we all can learn from. Smart contract ERC-827 allows / potentially enables a bad contract security practice.
From issue comments on the ERC-827 EIP by the security researcher:

We wrote a blog post, how replacing ERC20 with ERC827, can lead to unexpected reentrancy attacks.
…

Given that potential use cases of transferAndCall are unclear, I see the value of our article in clarifying how it should not be used.
Similar issues apply to approveAndCall, however, given that this functionality does not exist in ERC20 (as you said), we would have had to construct an example with vulnerable code to use it. If you have concrete cases, where approveAndCall is called from a smart contract we would be happy to check.

Overall, our intention was just to notify people that special care is needed when using these functions inside a smart contract.
– ritzdorf, CTO @ ChainSecurity


Related tweets and stories:


twitter.com



Georgios Konstantopoulos (@gakonst) on X
@gakonst

Very interesting reads which I somehow missed, nice finds @chain_security!

tldr: ERC827 callbacks (transferAndCall et al) can lead to reentrancy attack vectors. 

https://t.co/b0okX8piYc

https://t.co/aIezvENlo8

cc @arvanaghi @maurelian_ @GNSPS









https://medium.com/chainsecurity/why-erc827-can-make-you-vulnerable-to-reentrancy-attacks-and-how-to-prevent-them-61aeb4beb6bf

From OpenZeppelin’s GitHub issue on this:

It is a really bad practice to allow the abuse of CUSTOM_CALL in token standard.

https://github.com/OpenZeppelin/openzeppelin-solidity/issues/1044

Author: AugustoL
Date: 2018-07-09T11:44:00.890Z

Hello @jpitts, thanks for bringing this up on the ethereum-magicians community.
The issue with transferAndCall is that there is no way to verify the actual balance that was transfered, that is why we recommend the use of approveAndCall to work with “verified” balance in the EIP description.
Now we have another issue that brings problem when you for example want to work with ERC223 or ERC667 tokens, you can use the fallback functions of this tokens from the ERC827 contract and drain funds of contracts. Example: erc827/contracts/examples/VaultAttack.sol at master · windingtree/erc827 · GitHub
We are working on changes on the standard to prevent this from happening, the main proposal that we have for now is the use of “allowed” callbacks, wich means that the receiver contracts will be able to allow functions to be executed on it.
I think the allowedCallbacks is a good solution, it adds the necessary interface to allow contracts to execute specific and tested arbitrary calls over them. Removing this permission of execute calls on any contract form the token contract, and it adds only a ~50 lines of code.
https://github.com/windingtree/erc827/pull/2
I would like to get some feedback from here.
Title: Data_Ring_Topic__Provider_Infrastructure___Running
Category: Working_Groups

Author: tjayrush
Date: 2019-02-19T22:01:34.800Z

The ecosystem should begin moving away from relying on centralized node/data providers. Potential areas for discussion:

Forking client code to add indexing / digesting services
EIPs specific to improving usability from the nodes
Better documenting existing RPC interfaces
Improving cross-client consistency (i.e. Parity traces vs. Geth traces)
Modular / plugable clients.
dAppNode

Action item: @Patrick will start a thread about what is required for devs to run nodes.
Action Item: @tjayrush  will write a Medium post and start an EIP related to building indices.
Please provide links or comments to any of the above.

Author: jpitts
Date: 2019-02-21T01:33:26.857Z

Super-excited about this one, as you know!
I would add business models / incentives /  “sustainability”.

Author: ankitchiplunkar
Date: 2019-02-21T17:58:58.846Z

This is a great topic.
We have earlier written about cross client consistency

https://medium.com/tokenanalyst/weird-quirks-we-found-in-ethereum-nodes-d5dcbad0c86
https://medium.com/tokenanalyst/towards-production-grade-open-source-ethereum-nodes-6ef2e9458fb4

Would be willing to contribute in any way possible.

Author: ferranbt
Date: 2019-02-25T08:18:19.924Z

Hi!
Some of the work Im working on might be useful for this topic.
For the past months I have been working on a modular Ethereum client in Go (https://github.com/umbracle/minimal). The main goal is to increase the use cases for the client by building it with plug and play components. For example, a discovery protocol to build clusters of nodes or an bandwidth-limited syncer protocol for contrained devices.
Besides, I am also working on another project that might be of interest for the data ring. Heura (https://github.com/umbracle/heura) is a Domain-Specific Language (DSL) to interact with Ethereum smart contracts. With a couple of lines is possible to call smart contract functions or listen for
events on specific topics. It is intended to make it extensible with plugins (e.g. send email alert messages for specific events or dump an ETL operation into a JSON file). Heura could be used to build indexes and digesting services for Dapps on top of Minimal.
I hope I can be of any help.

Author: tjayrush
Date: 2019-02-26T03:23:34.894Z

I’ve been thinking that some of the ideas in this post might benefit from short presentations at the Magician’s council in Paris. I think @ankitchiplunkar will be there. I’ll be there. @ferranbt  will you be in Paris next week?
@ankitchiplunkar Perhaps we can each do a short demo of the work we’re doing related to the above as part of the data ring discussion. Your thoughts?

Author: ankitchiplunkar
Date: 2019-02-26T09:21:50.608Z

Sounds, great. We can do a 10-15 minute presentation to onboard people into these discussions

Author: ferranbt
Date: 2019-02-28T14:18:44.081Z

@tjayrush Yes, I’ll be in Paris for the magicians council.
Title: Meta_tx_Community_Call_Meeting_0
Category: Working_Groups

Author: pet3rpan
Date: 2018-09-18T10:50:01.688Z

Since the creation of ERC-1077/1078, we figured out that we can do somepretty cool things with delegated execution of meta-txs. Many projects have sprung up surrounding this. So far we have had little communication between projects. There is a lot to be gained in doing so as we seem to all face similar challenges and issues.
We will be having a meeting with the following agenda: MetaTx Crew Agenda - Meeting 0 - HackMD
All details will be kept and updated there. Cheers! Talk soon

Author: pet3rpan
Date: 2018-09-21T17:36:48.194Z

Dates:
27th 5PM CEST
Location
The meeting will take place through a video call link that can be found at the bottom of the agenda. If you are joining, please read the agenda!
What to do to prepare
Read the agenda!
What else should I know about the meeting?
Read the agenda!
Is there some sort of chat we can join for a greater discussion?
Read the agenda!
I would like to discuss a topic, where can I…
Read the agenda!
Thanks to everyone who has read the agenda, I wish you happiness and joy in your life.
Title: Risk_Catagorization_for_EthSecurity_Guidelines_Wor
Category: Working_Groups

Author: RexShinka
Date: 2018-10-11T21:43:55.021Z

Develop a top level risk categorization that can be used to assess smart contracts.  It could address the content of the code, where a public contract that moves or stores assets is high risk and a contract that just moves no assets is low risk.
This topic was raised in the Guidelines Working group of EthSecurity.  The output will be used in the resulting guidelines and further refined later.
Title: Forming_a_Ring__EthSignals
Category: Working_Groups

Author: MaxSemenchuk
Date: 2018-07-27T10:23:23.331Z

Hey everybody, we’re forming a new ring around signalling.
Purpose: Research and identify relevant signals, develop resources to consolidate signals and news in a trusted community forum, & build tools to support the Core Devs decision-making process.
More info: https://github.com/ethereum-magicians/scrolls/wiki/EthSignals-Ring

Author: MaxSemenchuk
Date: 2018-07-27T10:24:06.469Z

@jpitts could you pls create a subgroup for that?

Author: boris
Date: 2018-07-27T10:43:11.996Z

GitHub issue please.

Author: Ethernian
Date: 2018-07-27T10:45:46.115Z

How the Ring differs from the Governance one?

Author: MaxSemenchuk
Date: 2018-07-27T10:59:14.870Z

Good question @Ethernian , could you pls share some info on the Governance Circle? I know the gitter channel, though not sure if any coordination exists besides that.

Author: Ethernian
Date: 2018-07-27T11:20:16.260Z

I have started here a Ring for Ethereum “Project/Program” Governance, which I meanwhile see as “Ring of Ethereum Architects” (explanation will follow).
I would see this Ring: EthSignals as more focused on tooling and Rings Architects and Governance should use it to make decisions. Reason is: EthSignals is not the only tool for Governance (there is a voting too) and Governance is not only about Signalling.
Would you agree to separate Ring Governance from Ring EthSignals?

Author: MaxSemenchuk
Date: 2018-07-27T11:42:06.723Z

What you’ve said seems right to me

Author: arrose
Date: 2018-07-30T12:38:00.738Z

Agreed - I think it is best to keep them separate.

Author: arrose
Date: 2018-07-30T12:40:16.977Z

Here is an update to the description:
Research and identify relevant signals, develop resources to consolidate signals and news in a trusted community forum, & build tools to support the Core Devs decision making process.
Title: Ethereum_1_x_workshop_at_Stanford_Jan_2019_livestr
Category: Working_Groups

Author: lrettig
Date: 2019-01-26T18:37:20.834Z

Live tweetstream is here: https://twitter.com/lrettig/status/1089211309030133760

Author: cdili
Date: 2019-01-26T21:39:29.370Z

Jan 26 afternoon https://www.youtube.com/watch?v=Nky1BPwap2M

Author: cdili
Date: 2019-01-27T17:48:17.183Z

Jan 27 (Day 2) morning: https://www.youtube.com/watch?v=P2S7OW2E1vk

Author: cdili
Date: 2019-01-27T22:44:30.604Z

Jan 27 afternoon: https://www.youtube.com/watch?v=dHZiWFWCGNM

Author: cdili
Date: 2019-01-28T18:48:55.946Z

Jan 28 (Day 3) morning: https://www.youtube.com/watch?v=CnOyVZ3HvK4

Author: cdili
Date: 2019-01-28T22:20:20.236Z

Jan 28 afternoon: https://www.youtube.com/watch?v=HAK3ijgLRoM

Author: cdili
Date: 2019-01-31T07:47:04.427Z

Thank you to Arjunan Gnanendran for all the livestreaming!
Title: _WhiSpeG____Follow_Up__Kick_off_call_on_06_Dec_201
Category: Working_Groups

Author: Ethernian
Date: 2018-12-08T15:05:59.741Z

Call Summary
Here is the Work-in-Progress version of the Summary.
All Call participants are invited to extend and correct it!
Participants
There were clearly two groups of people in the call: Solution Developers and Core Developers.
SolutionDevs are using Whisper and Whisper-Clients in their solution for corporate customers.
CoreDevs are developing technology (both protocol an client).
Most of communication in the call was between these two groups.
Chatham House Rules
I would ask all participants to apply Chatham House Rule to all WhiSpeG meetings. This is in respect to all Whisper Devs, who would not like to be exposed in public too  much.
Discussed Topics
1. Specification
CoreDevs:
Considering current state of specification as quite solid.
If SolutionDevs need better specs, they should create a PR or an Issues on specs. What is not good enough exactly?
More resources (technnical writers) to improve Specs would be appreciated.
SolutionDevs:
What is the current official specs that being maintained? Unclear.
It would be nice to have a spec of a quality of a good IETF level.
Looks like we are missing single source of true for Whisper spec.
2. Testnet
SolutionDevs:
Is there any testnet? We just don’t know any.
CoreDevs:
There is a testnet. We will publish inode’s addresses.
3. UseCases
CoreDevs:
ask about detailed UseCase descriptions from SolutionDevs. Whisper (like other IM protocol) has different aspects:

P2P,
Darkness (conversational and metadata),
Throughput,
Reliability.

Which of them are more important for which UseCase?
SolutionDevs:
UseCase descriptions can be provided.
4. Benchmarking and Comparison
CoreDevs:
UseCases provided by SolutionDevs should contains quantitative requirements.
It is hard to solve trade-offs correctly while developing protocols without quantitative requirements to be met.
There is a swarm toolset to benchmark a network. May be it could be applied to Whisper development too.
Different existing IM protocols should be evaluated and compared to each other. It helps to set better development goals.
@Ethernian:
Comparison and Benchmarking can be carried out as part of Comparative Studies made by Ring of Ethereum Architects .
5. Miscellaneous
Meeting biweekly proposed.
@Ethernian will create a poll to move existion chat group from telegram to somewhere.
Title: Bad_instruction___Error_occured_during_contract_ex
Category: Working_Groups

Author: Mansi2705
Date: 2020-03-03T05:04:50.660Z

Hello all
Please resolve my error which I met , It is seen on explorer
ethereumHashError1616×808 95.9 KB
Title: Knowledge_Aggregation_Process___Dry_Run
Category: Working_Groups

Author: Ethernian
Date: 2018-11-12T23:16:15.312Z

Hello All,
We have set up our Architects repo and filled it with documents about our Knowledge Aggregation Process. The Process is aimed to be social and properly incentivized and designed to collect and aggregate comparative knowledge about projects in Ethereum space with focus on interoperability.
Even if you have a different focus, may be you are interested to review our Ideas to incentivization because it could be applied to FEM community globally.
In the next days we will start a dry run with few contributors. We will walk through the process, verify it and collect feedback. If you would like to be part of it, let me know.