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 16 Agenda #14

Closed
Souptacular opened this Issue May 13, 2017 · 13 comments

Comments

Projects
None yet
5 participants
@Souptacular
Member

Souptacular commented May 13, 2017

All Core Devs Meeting 16 Agenda

Meeting Date/Time: Friday 5/19/17 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

  1. ERC-20 Token Standard Finalization [Fabian, Nick, or Hudson]
  1. Metropolis updates/EIPs.
  1. [Time permitting] "If we have time (no high priority), I would like to get some feedback about adding functionality that allows dapps to be notified whenever a certain address was touched by a transaction (including internal calls). This information does not necessarily have to be part of the block, but could be an isolated index database." [Christian R.]

Please provide comments to add or correct agenda topics.

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin May 13, 2017

Collaborator

Agreeing on gas costs for MODEXP, ECADD, ECMUL, ECPAIRING.

For MODEXP specifically, are we going to modify it to somehow incorporate bit length or not?

Collaborator

vbuterin commented May 13, 2017

Agreeing on gas costs for MODEXP, ECADD, ECMUL, ECPAIRING.

For MODEXP specifically, are we going to modify it to somehow incorporate bit length or not?

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin May 17, 2017

Collaborator

Another item: I am starting to get cold feet about the REVERT opcode being able to return data. My main concern is that it will break any applications that depend on being able to micro-charge for getting data. I do realize that such applications are not extremely secure in any case because the fee can always be circumvented via merkle proof magic, but even still such strategies always have some cost, and so there is opportunity for applications to be able to charge at least enough to pay back any fixed costs they have for transaction fees. I'm concerned that (i) we are introducing an economic change which breaks things, and that (ii) the marginal benefits of knowing why an error happened may not be worth the costs.

Collaborator

vbuterin commented May 17, 2017

Another item: I am starting to get cold feet about the REVERT opcode being able to return data. My main concern is that it will break any applications that depend on being able to micro-charge for getting data. I do realize that such applications are not extremely secure in any case because the fee can always be circumvented via merkle proof magic, but even still such strategies always have some cost, and so there is opportunity for applications to be able to charge at least enough to pay back any fixed costs they have for transaction fees. I'm concerned that (i) we are introducing an economic change which breaks things, and that (ii) the marginal benefits of knowing why an error happened may not be worth the costs.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 17, 2017

Member

An alternative without the economic change is REVERTLOG that almost aborts, but logs one event. So (benefit of REVERT) - (benefit of REVERTLOG) needs to outweigh the costs.

[EDIT: REVERTLOG needs to consume all gas, lest information can be encoded in the gas consumption]

Member

pirapira commented May 17, 2017

An alternative without the economic change is REVERTLOG that almost aborts, but logs one event. So (benefit of REVERT) - (benefit of REVERTLOG) needs to outweigh the costs.

[EDIT: REVERTLOG needs to consume all gas, lest information can be encoded in the gas consumption]

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 17, 2017

Member

Item: proposal about freezing EIPs to allow time for testing.

Currently, no test cases are ready and stable because there are no indications which EIPs have stopped changing.

I propose introducing the notion of "freezing an EIP for Metropolis". Once EIPs are frozen for Metropolis, any change in the EIP that changes test cases needs to go through the All Core Devs meeting with the unanimous vote (it's meant to be hard, but not impossible, to achieve).

As an effect, when a frozen EIP has a critical problem, but if any party says they have not enough time to test the fix, the EIP would be dropped from Metropolis.

The first question is if we shall try to have this distinction "frozen". (Implementation details should come afterward: e.g. how to keep track of the frozen states; which EIPs to freeze first; shall we set the minimum duration between freeze and activation.)

Member

pirapira commented May 17, 2017

Item: proposal about freezing EIPs to allow time for testing.

Currently, no test cases are ready and stable because there are no indications which EIPs have stopped changing.

I propose introducing the notion of "freezing an EIP for Metropolis". Once EIPs are frozen for Metropolis, any change in the EIP that changes test cases needs to go through the All Core Devs meeting with the unanimous vote (it's meant to be hard, but not impossible, to achieve).

As an effect, when a frozen EIP has a critical problem, but if any party says they have not enough time to test the fix, the EIP would be dropped from Metropolis.

The first question is if we shall try to have this distinction "frozen". (Implementation details should come afterward: e.g. how to keep track of the frozen states; which EIPs to freeze first; shall we set the minimum duration between freeze and activation.)

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 18, 2017

Member

Item: was there a decision about opcodes of RETURNDATASIZE and RETURNDATACOPY?

I heard somewhere that that last coredev meeting decided that RETURNDATASIZE and RETURNDATACOPY shall move from 0xd and 0xe to some new opcodes, but I didn't attend it. I don't see the change in the EIP or in the last meeting's records (I found none). Was there a decision? If yes, what are the new opcodes? The EIP has been updated.

Member

pirapira commented May 18, 2017

Item: was there a decision about opcodes of RETURNDATASIZE and RETURNDATACOPY?

I heard somewhere that that last coredev meeting decided that RETURNDATASIZE and RETURNDATACOPY shall move from 0xd and 0xe to some new opcodes, but I didn't attend it. I don't see the change in the EIP or in the last meeting's records (I found none). Was there a decision? If yes, what are the new opcodes? The EIP has been updated.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 18, 2017

Member

Regarding EIP 96: should the gas price of BLOCKHASH already change from the beginning of the Metropolis, or from the block where the behavior of BLOCKHASH changes? https://github.com/ethereum/EIPs/pull/210/files#r117211219

Member

pirapira commented May 18, 2017

Regarding EIP 96: should the gas price of BLOCKHASH already change from the beginning of the Metropolis, or from the block where the behavior of BLOCKHASH changes? https://github.com/ethereum/EIPs/pull/210/files#r117211219

@pirapira pirapira referenced this issue May 18, 2017

Merged

EIP96 - blockhash refactoring #4066

4 of 4 tasks complete
@chriseth

This comment has been minimized.

Show comment
Hide comment
@chriseth

chriseth May 18, 2017

Contributor

If we have time (no high priority), I would like to get some feedback about adding functionality that allows dapps to be notified whenever a certain address was touched by a transaction (including internal calls). This information does not necessarily have to be part of the block, but could be an isolated index database.

Contributor

chriseth commented May 18, 2017

If we have time (no high priority), I would like to get some feedback about adding functionality that allows dapps to be notified whenever a certain address was touched by a transaction (including internal calls). This information does not necessarily have to be part of the block, but could be an isolated index database.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 18, 2017

Member

Regarding EIP 211 (RETURNDATACOPY): the behavior of reading out-of-bounds from the returndata buffer is under discussion. We can at least gather opinions.

Member

pirapira commented May 18, 2017

Regarding EIP 211 (RETURNDATACOPY): the behavior of reading out-of-bounds from the returndata buffer is under discussion. We can at least gather opinions.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 18, 2017

Member

Regarding EIP98 (med state removal): this should start at (inclusive) METROPOLIS_FORK_BLKNUM instead of one block after that (as written in the EIP). Pointed out by @gumb0 ethereum/EIPs#98 (comment)

Member

pirapira commented May 18, 2017

Regarding EIP98 (med state removal): this should start at (inclusive) METROPOLIS_FORK_BLKNUM instead of one block after that (as written in the EIP). Pointed out by @gumb0 ethereum/EIPs#98 (comment)

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 18, 2017

Member

Regarding EIP96 (BLOCKHASH contract): should the blockhash-maintainance call at the beginning of each block increment the nonce of SYSTEM_ACCOUNT? https://github.com/ethereum/EIPs/pull/210/files#r117260179

Member

pirapira commented May 18, 2017

Regarding EIP96 (BLOCKHASH contract): should the blockhash-maintainance call at the beginning of each block increment the nonce of SYSTEM_ACCOUNT? https://github.com/ethereum/EIPs/pull/210/files#r117260179

@arkpar

This comment has been minimized.

Show comment
Hide comment
@arkpar

arkpar May 19, 2017

@chriseth We have transaction tracing for internal calls implemented in Parity. It allows to do exactly that - query for any changes for the account.

arkpar commented May 19, 2017

@chriseth We have transaction tracing for internal calls implemented in Parity. It allows to do exactly that - query for any changes for the account.

@pirapira

This comment has been minimized.

Show comment
Hide comment
@pirapira

pirapira May 19, 2017

Member

@Souptacular I gave a wrong link about EIP211 discussion: the last point in 2.a. This should be under discussion. Currently, the link doesn't point to a discussion but to a test file. Sorry.

Member

pirapira commented May 19, 2017

@Souptacular I gave a wrong link about EIP211 discussion: the last point in 2.a. This should be under discussion. Currently, the link doesn't point to a discussion but to a test file. Sorry.

@Souptacular

This comment has been minimized.

Show comment
Hide comment
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment