Skip to content

All Core Devs Meeting 19 Agenda #17

Description

@Souptacular

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 - https://github.com/paritytech/parity/issues/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.

Activity

  1. Souptacular commented on Jun 22, 2017

    @Souptacular
    ContributorAuthor

    @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.

  2. holiman commented on Jun 29, 2017

    @holiman

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

    • Determining gasprices for new opcodes & precompiles.
  3. karalabe commented on Jun 29, 2017

    @karalabe
    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).

  4. karalabe commented on Jun 29, 2017

    @karalabe
    Member

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

  5. Souptacular commented on Jun 29, 2017

    @Souptacular
    ContributorAuthor

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

  6. Souptacular commented on Jun 29, 2017

    @Souptacular
    ContributorAuthor

    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."

  7. Souptacular commented on Oct 6, 2017

    @Souptacular
    ContributorAuthor
  8. added
    ACDType: All Core Dev calls - execution & consensus
    ExecutionLayer: Issues that affect the execution layer
    on Feb 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ACDType: All Core Dev calls - execution & consensusExecutionLayer: Issues that affect the execution layer

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions