All Core Devs Meeting 18 Agenda

[Souptacular]

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: 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?
   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 - 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
   d. Review time estimate for testing/release.

Please provide comments to add or correct agenda topics.

[sophiii]

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]

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

[obscuren]

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]

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

I'd like to add

• EIP 208: Abstraction of transaction origin and signature.md 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]

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

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]

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]

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

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]

Added notes and audio/video here: https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2018.md

Closing issue.