Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

All Core Devs Meeting 19 Agenda #17

Closed
Souptacular opened this issue Jun 22, 2017 · 7 comments
Closed

All Core Devs Meeting 19 Agenda #17

Souptacular opened this issue Jun 22, 2017 · 7 comments

Comments

@Souptacular
Copy link
Contributor

Souptacular commented Jun 22, 2017

All Core Devs Meeting 19 Agenda

Meeting Date/Time: Friday 6/30/17 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

  1. Metropolis updates/EIPs.
    a. Any "subtleties" or questions we need to work out.
    1. EIP 86/208: Abstraction of transaction origin and signature - Contract addresses cannot any more be computed (or rather guaranteed) without a live blockchain, and even then we have no guarantee that a deployed code is ours (or that it remains ours in the face of reorgs). [Peter]
    2. EIP 86/208: Abstraction of transaction origin and signature - Discuss the comment here Abstraction of transaction origin and signature.md EIPs#208 (comment) and further refined by Abstraction of transaction origin and signature.md EIPs#208 (comment) [Peter]
    3. EIP 86/208: Abstraction of transaction origin and signature: Atomicity over an ECDSA's accounts operations [Jeff Coleman]
    4. Metropolis Difficulty Bomb EIP [Everyone]
    b. Updates to testing.
    - Documentation and other updates
    c. Details and implementations of EIPs.
    1. Updates from client teams.
    - geth - consensus, core/*: metropolis features go-ethereum#14337
    - Parity - Byzantium release openethereum/parity-ethereum#4833
    - cpp-ethereum - [META] Byzantium implementation progress aleth#4050
    - yellowpaper - Byzantium changes yellowpaper#229
    - pyethapp
    - Other clients
    2. Determining gas prices for new opcodes & pre-compiles [Martin HS/Everyone]
    d. Review time estimate for testing/release.
  2. Block gas limit increase update [Hudson]
  3. EIP 186: Reduce ETH issuance before proof-of-stake [Vitalik/Avsa/Nick have comments]

Please provide comments to add or correct agenda topics.

@Souptacular
Copy link
Contributor Author

@holiman Does any of the following need to be added to this week's agenda?

  1. EIP 208: Abstraction of transaction origin and signature.md EIPs#208 Concerns [Martin H.S]
    i. A transaction hash no longer uniquely identifies an execution, since a transaction at least theoretically can be included in multiple blocks, or multiple times in a block.
    ii. Do we need to modify rpc-call which assumes hash = unique execution, to return a list of transactions instead of a single element?
    iii. What side-effects does the breaking of this invariant have on the clients?

It was in last weeks and I'm not sure we came to conclusions on every point.

@holiman
Copy link

holiman commented Jun 29, 2017

No we can remove that. We may want to add a point

  • Determining gasprices for new opcodes & precompiles.

@karalabe
Copy link
Member

I would like to request a slot for discussing some possible issues around EIP 208 address abstractions. Namely that contract addresses cannot any more be computed (or rather guaranteed) without a live blockchain, and even then we have no guarantee that a deployed code is ours (or that it remains ours in the face of reorgs).

@karalabe
Copy link
Member

karalabe commented Jun 29, 2017

One of the issue I'd like to discuss: ethereum/EIPs#208 (comment) and further refined by ethereum/EIPs#208 (comment).

@Souptacular
Copy link
Contributor Author

Nick Johnson To-do: Write a new PR for the return data change that can obsolete 98.

@Souptacular
Copy link
Contributor Author

EIP 186 Comments from chat channel

Vitalik: "I want to re-bring up EIP 186; I think we are more than secure enough with ETH at these levels (or even at $50) and wasting more electricity than some countries is tragic so we could use a decrease"

Avsa: "The plan for Casper is to start with a slow transition from PoW, right? Is the idea to have a slowly decreasing reward? Maybe if we set a slowly decreasing schedule now - which then has a slight uptick when PoS comes around, it might be an actual incentive for miners to move to the PoS chain when that is ready"

"I am also tentatively in favor of it with we can justify it in terms of incentiziation. I am against it if it’s heavily dependent on ether price or if it’s about pure economic planning
Maybe what is needed for this conversation to move forward is a clear proposal with numbers backing it up: reduce to X on Y date then changes to N when PoS comes etc. We also need to account for black swans: what if the new ice age comes, Casper isn't ready and ether is under $20?"

Nick: "My own opinion on this has evolved; I'm tentatively in favor of at least a modest reduction.
Exactly because it's a step towards the reduced issuance Casper is likely to have."

@Souptacular
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants