Byzantium changes

[pirapira]

We can check these boxes when we create PRs for the yellow paper, or the EIPs are dropped from Metropolis.

• EIP 5/8 ethereum/EIPs#211 (RETURNDATACOPY and RETURNDATASIZE) | #264
• EIP 86 to be followed in #231 (initial abstraction changes) | #277
• EIP 96 (block hash in a special contract) | #311
• EIP 98 remove medstate from transaction receipts | already in metropolis branch
• EIP 100 (difficulty adjustment) (equation (43). 2017-02-17: two options still; 2017-03-02 perhaps option 1(b)) to be followed in #253 | #266
• EIP 101 EIP 198 (Big-int precompiles) to be followed in #235 | #268
• EIP 116 ethereum/EIPs#214 (STATIC_CALL) to be followed in #234 | #270
• EIP 166 replay protection with higher-order bits of nonce, to be tracked in #259
• EIP 196 ethereum/EIPs#213 & 197 ethereum/EIPs#212 (zkSNARK verification primitives) | #297
• EIP 206 (REVERT) to be followed in #232 | #278
• EIP 649 | #333
• EIP 658 (add status code in receipts) | #318

This list initially followed ethereum/pm#4

[VoR0220]

Will ethereum/EIPs#116 be included in there? Or no?

[pirapira]

I added it.

[VoR0220]

awesome. I shall share this list so that Monax team can be aware too...these are all scheduled to be included, yes?

[pirapira]

Probably, a few points have already been overwritten by something else. I'm just adding everything that might be coming.

[pirapira]

A branch metropolis was created in this repository.

[5chdn]

EIP-649 is missing from the list. ☝️

[pirapira]

@5chdn I added it.

[bbuenz]

Why aren't ECPoints stored in their compressed form which is half the size? That is use just x + 1 bit instead of x,y?

[rbkhmrcr]

@bbuenz within the evm even the cost of storing 32 bytes is lower than the cost of recomputing y from a given x (or at least it definitely was up until the modexp precompile was added -- unsure about now, i'll benchmark it if u want). for txns the public key is recovered from the signature rather than sent alongside it so i assume you're asking about precompile justification?

[bbuenz]

Shouldn't the precompile cost be based on real world costs? I think Pieter Wuille said that in libsec256k1 group exponentiation is 1% more expensive which should be offset by the storage savings, shouldn't it?

[pirapira]

@bbuenz the gas costs across EVM are not accurate enough to make 1% calibration meaningful.

[bbuenz]

@pirapira I don't think I explained myself well enough. Using point compression, i.e. 32 byte eliptic curve points makes addition and multiplication just 1% slower. So you get 50% storage/communication improvement for just 1% computation loss. That seems like a clear win to me.

[pirapira]

This has been done. Thanks @gavofyork for the license and thanks @nicksavers for the merges.