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

Closed
Souptacular opened this Issue Jun 6, 2017 · 11 comments

Comments

Projects
None yet
5 participants
@Souptacular
Member

Souptacular commented Jun 6, 2017

All Core Devs Meeting 18 Agenda

Meeting Date/Time: Friday 6/16/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 206 REVERT Opcode : The "Specification" section in the EIP does not specify that REVERT can return data to the caller. Neither does it specify how the caller can access the returned data. [Yoichi]
    2. EIP 208 Abstraction of transaction origin and signature: Atomicity over an ECDSA's accounts operations [Jeff Coleman]
    3. EIP 208: ethereum/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?
    4. EIP 211 RETURNDATACOPY and RETURNDATASIZE: This is complete right? [Hudson]
    5. EIP 213 zkSNARK verification primitives: Gas costs for additional and mult. on EC [Christian or someone]
    6. EIP 214 STATICCALL: Various potential errors [Vitalik]
    b. Updates to testing.
    - Documentation and other updates
    c. Details and implementations of EIPs.
    - Updates from client teams.
    - geth - ethereum/go-ethereum#14337
    - Parity - paritytech/parity-ethereum#4833
    - cpp-ethereum - ethereum/aleth#4050
    - yellowpaper - ethereum/yellowpaper#229
    - pyethapp
    - Other clients
    d. Review time estimate for testing/release.

Please provide comments to add or correct agenda topics.

@sophiii

This comment has been minimized.

Show comment
Hide comment
@sophiii

sophiii Jun 6, 2017

I would like to see some of the subtleties around #EIP208 discussed. Specifically I am worried about transaction validation leading to DOS attacks.

I think the current strategy of white listing proxy accounts is not enough as the contract the proxy calls could throw and this would revet the gas that was paid to the miner.

Secondly these is a possibility that this could lead to a network split attack. An attacker makes a contract that would fail to pay 1/2 of the nodes if they are the one to mine an a proxy transaction there. Then makes a proxy transaction that calls that contract and broadcasts it. 1/2 of the nodes see this transaction as valid so they rebroadcast it. When they rebroadcast it to a node that this transaction does not pay they see it as invalid and blacklist the sender as sending bad transactions. Over time an attacker could isolate a specific miner or group of nodes this way.

See my comments https://github.com/ethereum/EIPs/pull/208/files

sophiii commented Jun 6, 2017

I would like to see some of the subtleties around #EIP208 discussed. Specifically I am worried about transaction validation leading to DOS attacks.

I think the current strategy of white listing proxy accounts is not enough as the contract the proxy calls could throw and this would revet the gas that was paid to the miner.

Secondly these is a possibility that this could lead to a network split attack. An attacker makes a contract that would fail to pay 1/2 of the nodes if they are the one to mine an a proxy transaction there. Then makes a proxy transaction that calls that contract and broadcasts it. 1/2 of the nodes see this transaction as valid so they rebroadcast it. When they rebroadcast it to a node that this transaction does not pay they see it as invalid and blacklist the sender as sending bad transactions. Over time an attacker could isolate a specific miner or group of nodes this way.

See my comments https://github.com/ethereum/EIPs/pull/208/files

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jun 14, 2017

Member

@sophiii would you like to attend the meeting to voice your concerns?

Member

Souptacular commented Jun 14, 2017

@sophiii would you like to attend the meeting to voice your concerns?

@obscuren

This comment has been minimized.

Show comment
Hide comment
@obscuren

obscuren Jun 14, 2017

Member

The initial idea is to ignore any broadcasted abstract transactions and gradually come up with a strategy to accept them in the transaction pool. We will still accept the transactions as valid if the transaction was included by a miner.

The EIP allows for further experimentation.

Member

obscuren commented Jun 14, 2017

The initial idea is to ignore any broadcasted abstract transactions and gradually come up with a strategy to accept them in the transaction pool. We will still accept the transactions as valid if the transaction was included by a miner.

The EIP allows for further experimentation.

@sophiii

This comment has been minimized.

Show comment
Hide comment
@sophiii

sophiii Jun 14, 2017

@Souptacular I would be happy to.
@obscuren I am worried that after some experimenting we will realize that there is no DOS proof method of validateing other than very restrictive white listing. So i want to raise the issue now in case that we need to build a less DOS able transaction abstraction format.

sophiii commented Jun 14, 2017

@Souptacular I would be happy to.
@obscuren I am worried that after some experimenting we will realize that there is no DOS proof method of validateing other than very restrictive white listing. So i want to raise the issue now in case that we need to build a less DOS able transaction abstraction format.

@holiman

This comment has been minimized.

Show comment
Hide comment
@holiman

holiman Jun 16, 2017

I'd like to add

  • EIP 208: ethereum/EIPs#208 (comment)
    • 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.
      • Do we need to modify rpc-call which assumes hash = unique execution, to return a list of transactions instead of a single element?
      • What side-effects does the breaking of this invariant have on the clients?

holiman commented Jun 16, 2017

I'd like to add

  • EIP 208: ethereum/EIPs#208 (comment)
    • 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.
      • Do we need to modify rpc-call which assumes hash = unique execution, to return a list of transactions instead of a single element?
      • What side-effects does the breaking of this invariant have on the clients?
@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin Jun 16, 2017

Collaborator

@obscuren I am worried that after some experimenting we will realize that there is no DOS proof method of validateing other than very restrictive white listing

Even if this is true, IMO that is totally okay. Even if we have a whitelist that accepts proxy accounts of a very specific format, that have a purity-checked signature checker followed by a specific piece of code to increment the nonce and forward the call, that is still an improvement over the status quo.

However miners will only include transactions that pay them. Could this result in valid transactions that never get executed as the payment fails and thus no miner wants to include them?

Yes. But that's a feature, not a bug. Of course transactions that do not pay for their own gas should not get included.

This could lead to alot of over heard for miners dealing with these transactions that will never get processed but are still valid.

The overhead should be bounded in terms of gas; elsewhere I suggested targeting a bound of 200000 as that's high enough to do ring signatures, hash ladder signatures and pairing-based BLS signatures but nothing more complex.

I think that this is not enough to ensure the miner gets paid. As a transaction can throw in an external contract which will undo the previous payment.

What do you mean by "external contract". Think of the "intended call tower" as being:

  • NULL_SENDER calls ACCOUNT
  • ACCOUNT checks signature and nonce, increments nonce
  • ACCOUNT calls CALLEE
  • ACCOUNT calls COINBASE to pay for gas

ACCOUNT can be required to contain "assert msg.sender == NULL_SENDER" to prevent re-entrancy attacks. Whatever happens inside CALLEE can at worst lead to CALLEE consuming all of its gas; there's no risk of it "breaking out" in any way. And the call to COINBASE would only have 2300 gas, so it can't do anything interesting.

Collaborator

vbuterin commented Jun 16, 2017

@obscuren I am worried that after some experimenting we will realize that there is no DOS proof method of validateing other than very restrictive white listing

Even if this is true, IMO that is totally okay. Even if we have a whitelist that accepts proxy accounts of a very specific format, that have a purity-checked signature checker followed by a specific piece of code to increment the nonce and forward the call, that is still an improvement over the status quo.

However miners will only include transactions that pay them. Could this result in valid transactions that never get executed as the payment fails and thus no miner wants to include them?

Yes. But that's a feature, not a bug. Of course transactions that do not pay for their own gas should not get included.

This could lead to alot of over heard for miners dealing with these transactions that will never get processed but are still valid.

The overhead should be bounded in terms of gas; elsewhere I suggested targeting a bound of 200000 as that's high enough to do ring signatures, hash ladder signatures and pairing-based BLS signatures but nothing more complex.

I think that this is not enough to ensure the miner gets paid. As a transaction can throw in an external contract which will undo the previous payment.

What do you mean by "external contract". Think of the "intended call tower" as being:

  • NULL_SENDER calls ACCOUNT
  • ACCOUNT checks signature and nonce, increments nonce
  • ACCOUNT calls CALLEE
  • ACCOUNT calls COINBASE to pay for gas

ACCOUNT can be required to contain "assert msg.sender == NULL_SENDER" to prevent re-entrancy attacks. Whatever happens inside CALLEE can at worst lead to CALLEE consuming all of its gas; there's no risk of it "breaking out" in any way. And the call to COINBASE would only have 2300 gas, so it can't do anything interesting.

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin Jun 16, 2017

Collaborator

Do we need to modify rpc-call which assumes hash = unique execution, to return a list of transactions instead of a single element?

My preference is for any RPC call that currently uses a hash to refer to a transaction to instead refer (in the EIP86 case) to the first successful execution of a transaction, meaning the first execution that did not throw/revert in the outermost layer of execution. Later on we can add the ability to look up all positions where a given transaction was included (ie. tx -> ((blknum, txindex), (blknum, txindex) ... )), and then the ability to look up a transaction receipt by (blknum, txindex). This abstraction also has the benefit that it increases efficiency, as you can look up all receipts in a block without ever accessing the transactions.

There are situations where I expect multiple executions of the same tx will be a totally legitimate and regular thing. The main one I can think of is where a contract periodically issues a bounty to "poke" it (eg. ethereum alarm clock) and exactly the same poke transaction is used multiple times because there's no reason to change the data around. But we can use initially restrictive whitelists to mostly prevent this from happening until all the tooling is finished.

Collaborator

vbuterin commented Jun 16, 2017

Do we need to modify rpc-call which assumes hash = unique execution, to return a list of transactions instead of a single element?

My preference is for any RPC call that currently uses a hash to refer to a transaction to instead refer (in the EIP86 case) to the first successful execution of a transaction, meaning the first execution that did not throw/revert in the outermost layer of execution. Later on we can add the ability to look up all positions where a given transaction was included (ie. tx -> ((blknum, txindex), (blknum, txindex) ... )), and then the ability to look up a transaction receipt by (blknum, txindex). This abstraction also has the benefit that it increases efficiency, as you can look up all receipts in a block without ever accessing the transactions.

There are situations where I expect multiple executions of the same tx will be a totally legitimate and regular thing. The main one I can think of is where a contract periodically issues a bounty to "poke" it (eg. ethereum alarm clock) and exactly the same poke transaction is used multiple times because there's no reason to change the data around. But we can use initially restrictive whitelists to mostly prevent this from happening until all the tooling is finished.

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin Jun 16, 2017

Collaborator

Also, I realized there is one really cool benefit of EIP86: because the set of non-includeability conditions for a tx can expand, we can have ICOs where all the failed transactions do not clog up the blockchain. Somewhere between 50-99% of ICO purchases on average fail, so I can see this being a significant de-facto capacity boost.

Collaborator

vbuterin commented Jun 16, 2017

Also, I realized there is one really cool benefit of EIP86: because the set of non-includeability conditions for a tx can expand, we can have ICOs where all the failed transactions do not clog up the blockchain. Somewhere between 50-99% of ICO purchases on average fail, so I can see this being a significant de-facto capacity boost.

@sophiii

This comment has been minimized.

Show comment
Hide comment
@sophiii

sophiii Jun 16, 2017

@vbuterin If the Callee cannot break out there is no problem. I will keep thinking about this but for now @Souptacular can you remove my item from the agenda and i can add to a future meeting if i find anything else ;-)

sophiii commented Jun 16, 2017

@vbuterin If the Callee cannot break out there is no problem. I will keep thinking about this but for now @Souptacular can you remove my item from the agenda and i can add to a future meeting if i find anything else ;-)

@vbuterin

This comment has been minimized.

Show comment
Hide comment
@vbuterin

vbuterin Jun 17, 2017

Collaborator

Regarding EIP86, and specifically the part where the address of a contract created by a transaction changes from sha3([sender, nonce]) to sha3(sender ++ initcode): there is a theoretical possibility that this would lead to loss of funds, if users send ETH to addresses of the form sha3([sender, nonce]) where contracts have not yet been created, expecting to create contracts in the future at those addresses to spend the funds.

There is currently no reason to believe that such a technique is in significant use, but a small risk nevertheless exists. The somewhat larger risk of losses comes from combination bugs: situations where a user sends ETH to a contract that does not exist (eg. because they meant to send ETC to a contract that exists on the ETC chain, but instead sent ETH), and right now some of those situations are recoverable, as the user can sometimes just recreate the contract on the ETH chain, but with EIP86 this will become impossible because the address generation mechanism will change.

There are two possible paths:

  1. Be very loud and clear about the fact that this compatibility-breaking change is happening, so that people can create the contracts before Metropolis happens.
  2. Make the Metropolis change ONLY apply if tx.sender == NULL_SENDER (ie. the transaction is an EIP86 transaction). This parallels the existence of CREATE and CREATE2 opcodes in metropolis.

(1) is marginally cleaner, (2) is marginally safer. Note that if we later on want to make a compulsory transition from regular accounts to EIP86 accounts (my preference: eventually we should, so that we can gain the simplicity benefits of the protocol only having one type of account), we do need to be loud and clear about the impact that this will have on people sending ETH (or other tokens) to not-yet-existent contracts, and how people who want to do such a thing can do so safely (namely, using EIP86 transactions and the CREATE2 opcode).

Collaborator

vbuterin commented Jun 17, 2017

Regarding EIP86, and specifically the part where the address of a contract created by a transaction changes from sha3([sender, nonce]) to sha3(sender ++ initcode): there is a theoretical possibility that this would lead to loss of funds, if users send ETH to addresses of the form sha3([sender, nonce]) where contracts have not yet been created, expecting to create contracts in the future at those addresses to spend the funds.

There is currently no reason to believe that such a technique is in significant use, but a small risk nevertheless exists. The somewhat larger risk of losses comes from combination bugs: situations where a user sends ETH to a contract that does not exist (eg. because they meant to send ETC to a contract that exists on the ETC chain, but instead sent ETH), and right now some of those situations are recoverable, as the user can sometimes just recreate the contract on the ETH chain, but with EIP86 this will become impossible because the address generation mechanism will change.

There are two possible paths:

  1. Be very loud and clear about the fact that this compatibility-breaking change is happening, so that people can create the contracts before Metropolis happens.
  2. Make the Metropolis change ONLY apply if tx.sender == NULL_SENDER (ie. the transaction is an EIP86 transaction). This parallels the existence of CREATE and CREATE2 opcodes in metropolis.

(1) is marginally cleaner, (2) is marginally safer. Note that if we later on want to make a compulsory transition from regular accounts to EIP86 accounts (my preference: eventually we should, so that we can gain the simplicity benefits of the protocol only having one type of account), we do need to be loud and clear about the impact that this will have on people sending ETH (or other tokens) to not-yet-existent contracts, and how people who want to do such a thing can do so safely (namely, using EIP86 transactions and the CREATE2 opcode).

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular
Member

Souptacular commented Jun 22, 2017

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