►
From YouTube: Ethereum Core Devs Meeting #75 [2019-11-15]
Description
A
A
B
C
A
Right
now,
ether
chain
is
the
only
one
who's
confirmed
to
have
been
updated
and
the
cat
herders
and
the
others
are
going
to
help
reach
out
to
them.
But
if
any
one
just
happens
talk
to
any
of
those
groups,
just
let
him
know
to
update,
maybe
send
out
some
tweets
to
them.
Stuff
like
that
James
was
there
anything
else
just.
D
16%
adoption
so
far
on
the
way
to
Istanbul,
and
we
have
some
better
data
this
time
that
we've
ever
had
from
ether
nodes
about
the
adoption
and
it'll
be
great
for
next
time.
You
used
this
as
a
benchmark,
how
we're
doing
as
a
community
as
for
adopting
we're
made
of
adoption
and
anyone
reach
out
to
me
if
you
either
have
connections
or
know
how
to
connect,
because
I
actually
working
on
this.
Oh.
A
A
Okay,
the
next
item
is
Berlin,
updates
and
I.
Think
that's
just
a
carryover
from
the
last
agenda,
because
I
think
since
we're
doing
EIP
centric
now
we're
just
gonna
go
over
a
ip's
and
whatever
happens
makes
it
into
there.
Unless
someone
who
needs
to
talk
about
the
timing
or
anything
like
that,
okay.
E
A
Yeah
thanks
McHale,
it's
been
great
to
have
you
on
the
call
the
last
few
years
and
see
aetherium
Jay
supported.
It
was
one
of
the
I
think
it
was
one
of
the
earliest
of
theorem
clients,
along
with
a
left
and
death
so
and
Piatt
theory
or
PI
app
at
the
time.
So
yeah,
it's
been
a
it's
been
a
long
time
and
thank
you
so
much
for
all
the
support.
A
All
right,
testing
updates
I
think
we
have
one
from
Andre
who's,
not
on
the
call
test.
Death
actually
is
Demetri
on
here
now,
I'll
just
say:
the
announcement
test
death
tool
now
supports
generating
test
with
a
string
like
Istanbul
+
e
IP
number,
instead
of
a
fork
name.
This
could
be
useful
for
the
EIP
centric
process.
If
anyone
would
like
to
look
into
prototyping
e
IPS
on
the
left,
then
they'll
have
a
link
with
details.
This
is
the
last
comment
on
the
agenda.
C
Gumbo,
so
that
thing
he
mentioned
is
guess
already
supports
it,
and
it
basically
means
that
if
anyone
wants
to
make
test
cases
for
a
particular
eat,
then
you
can
make
those
test
cases
without
the
Berlin
heart
for
being
too
fine,
you
can
just
yeah
base
it
on
the
only
heart
for
it,
like
frontier,
plus
your
ich
number
and
activated
for
test
cases.
So
that's
pretty
nice
and
that's
about
it.
A
All
right,
everybody
get
hype,
we're
at
item
number
5
and
that
is
eligibility
for
inclusion,
I
pee
review.
We
have
two
e
IPS
today.
The
first
one
is
e
IP,
two
three
four
eight
validated
EVM
contracts,
I
believed
Ana
was
gonna
talk
about
that.
Just
by
you
know
giving
an
overview
of
that,
and
then
we
can
discuss
different
discussion
topics
on
it.
So
go
ahead.
Anna.
F
F
There's
been
a
lot
of
proposals
for
EVM
opcodes
that
have
been
multibyte,
and
one
of
the
things
I've
pointed
out
in
the
rationale
is
that
somebody
can't
find
the
link
right
now,
but
there
was
a
demonstration
that
just
adding
in
that
a
multi
by
a
multi
byte
code
right
now
will
actually
break
some
executions,
because
if
you
have
a
multi
bite
that
contains
one
byte
after
it,
that
is
the
jump
destination.
And
then
you
run
it
with
the
new
version.
G
F
Jump
destination
will
be
removed
and
you
can
theoretically
break
that
on.
That's
a
combination
of
one
of
the
four
features.
There's
four
basic
features
that
we're
combining
into
this
this
conglomerate
VIP.
The
first
one,
is
to
actually
use
the
EIP
1702
versioning
infrastructure
to
to
turn
on
since
after
this
point,
all
the
other
options
in
the
CIP
are
eligible
for
use,
but
the
version
one.
The
second
one
is
to
use
the
the
headers
into
the
EVM
options.
F
That's
one
of
the
one
of
the
alternatives
that
was
listed
in
the
NQ
1702
for
how
to
allow
code
to
opt
in
to
a
new
versioning
scheme
and
I
think
this
is
essential
that
we
provide
some
octave
or
somebody's.
You
see,
I
want
to
be
out
of
the
old
system,
because
otherwise,
I'm
gonna
have
to
upgrade
all
the
tools
and
make
sure
that
nobody
ever
uses
an
older
version
of
solidity
to
compile
their
main
net
code,
which
I
just
don't
think,
is
sustainable.
I.
F
Think
it's
more
sustainable
to
combine
the
header
and
also
one
of
the
opcodes
from
the
EIP
615,
which
is
the
begin
data
hub
to
present
an
envelope
around
your
EVM
code,
so
it
activation.
We
would
turn
on
on
the
EFI
system
to
versioning
at
the
inter
version.
One
account
if
you
start
your
EDM
code
with
the
marker,
which
could
be
you
know,
zero,
zero,
zero
one
and
end
it
with
the
either,
don't
end
it
or
ended.
With
the
begin
data.
You
can
still
put
all
of
your
things
afterwards.
F
There
are
some
flags
and
solidity
that
allow
you
to
put
the
or
hash
of
your
source
code
in
your
EVM
code,
and
that
goes
on
to
the
next
thing
that
we
want
to
fix,
which
is
invalid.
Op
codes
is
that
those
form
hashes
will
have
invalid
outputs
if
the
EVM
tries
to
execute
those
hashes,
it's
going
to
blow
up
whether
this
opcode
doesn't
exist.
F
So
if
I
I
put
in
the
wrapper
around
the
EVM
code,
we
can
say
this
is
the
only
code,
that's
executable,
and
anyone
who
wants
to
put
all
their
other
extra
metadata
about
their
in
class
like
what
the
spore
hash
code
is
completed
after
the
begin
data.
That's
the
third
step
in
the
fourth
step,
I'm
putting
in
there
as
well
we're
going
in
and
adding
this
well,
the
third
step
as
part
of
the
third
step,
I
skipped
where
we
actually
validate
the
code
within
that
wrapper.
F
So
once
we
have
that
set
up
inside
the
wrapper
when
you
deploy
your
contract,
there
is
a
validation
steps
that
we
go
through
to
make
sure
that
each
code
point
is
actually
a
valid
code
point
and
if
you're
applying
enough,
if
you're
deploying
an
OP
code
that
doesn't
exist,
then
it's
rejected
because
it
doesn't
exist
now
in
the
future.
It
might
exist
as
a
multi
buyer
single
bike.
F
Not
an
option,
but
when
you
have
a
push
end
code
and
you
have
a
jump
code
afterwards,
we
validate
that.
So
that's
one
validation.
Now
that's
perfect,
because
you
can
still
have
jump
codes
that
are
done
dynamically,
but
those
are
happening
less
and
less.
Since
you
know
we
don't
have
to
push
all
these.
If
this
has
issues,
we
can
take
the
static,
jump,
validation
out
and
push
you
didn't
get
another
version,
but
that's
something
we'd
like
to
have
a
discussion
about
at
the
very
least
I
think
those
are
the
four
parts.
C
F
We
need
to
validate
the
contracts
before
they
go
onto
the
chain
and
we
need
some
mechanism
to
do
that.
That
is
that
will
prove
that
all
our
codes
in
this
code
stream
are
going
to
be
valid,
op
codes,
so
that
has
to
go
with
the
opt-in.
If
we
don't
validate
them,
that
people
can
put
in
an
unused
octave
and
the
very
next
byte
can
be
the
jump
destination
operation
and
the
way
the
EVM
works.
Now
you
can
jump
that
jump
desktop
to
make
operation.
F
You
can
jump
over
all
the
invalid
code,
so
if
the
bike
that
they
had
before
the
jump
desk
becomes
a
multi-line
code,
when
you
interpret
it
you're
not
supposed
to
jump
into
the
destinations
like,
you
can't
jump
in
the
middle
of
a
push
in
operation.
So,
like
every
jump,
publications,
if
you
bring
in
another
multi
byte
code,
we
would
need
to
jump
over
all
the
contents.
Okay,.
F
And
I
haven't
done
a
full
investigation
of
all
of
the
upper
all
the
contracts
on
the
net,
but
considering
that
we
are
in
a
in
an
environment
where
people
will
break
things
because
again
between
the
timing
specified
us.
That's
how
you
deploy
that.
If
that's
a
problem,
we
should
just
expect
that
someone's
and
then
deploy
a
contract
that
breaks
that
invariance.
F
One
thing
is,
we
could
have
a
VM
when
they
recognize
it
discard
it
and
move
the
PC
to
zero,
invite
five
in
a
stream.
Another
option
is,
we
would
recognize
it
and
discard
it
and
make
PC
for
me
to
be
getting
the
operation
of
PC
for
the
stream
and
another
option
is
to
make
it
a
multibyte,
no
op
operation
so
make
it
the
code
header.
F
They
would
also
need
to
include
the
header
and
the
wrapper
in
the
create
two
data
as
well.
So
whatever
they
load
into
the
memory
would
also
need
that
the
reason
I'm
concerned
about
PC
0
and
the
index
lighting
up
is
you
can
still
get
up
the
header
with
the
ext
code
copy
operation
and
that's
why
I'm
not
liking.
F
The
idea
initially
thought
it
was
a
good
idea,
but
I'm
not
liking
it
of
having
piece
equals
0,
be
at
the
4th
index
of
the
stream,
because
I
think
those
should
still
line
up
it's
a
little
bit,
consistency
so
of
those
three
I've,
ok
with
any
of
them
from
recommendations
from
other
ones.
My
favorite
one
is
to
turn
the
header
into
a
multi-byte
know.
I.
C
C
E
C
Read
all
right:
okay,
yeah
I'm
short
version
is
init
code
is
very
cheap
to
execute
because
you
don't
expand
memory
once
and
can
have
a
megabyte
of
init
code
and
you
can
run
it
and
then
you
can
flip
a
bite
somewhere
and
you
can
run
it
again
at
only
700
cost
and
if
we
need
to
do
the
validation
up
from
right
now,
that's
fairly
cheap.
We
just
have
to
do
one
pass
on
the
on
the
code
and
flip
a
few
bits
in
there.
F
F
C
F
F
Because
there's
the
header
at
the
beginning
want
to
see
begin
data
you
stop
validating,
because
you
know
it's
not
going
to
be
executed,
I
mean
just
make
sure
each
opcode
as
you
pass.
It
is
valid
and
if
it's
not
you
know,
it
should
I
I'm
just
intending
this
to
be
a
one
pass
validation,
including
against
existing
validations.
So.
F
C
C
F
A
H
The
core
reason
for
why
I
want
to
discuss
this
is
mainly
in
renaming
the
opcode
sha-3
to
catch
shock,
since
this
hasn't
been
done
in
solidity
already,
and
it's
generally
really
confusing.
That's
the
one
that
I
made
my
concern
about,
but
I
think
the
other
naming
suggestions
are
good
too.
So
this
is
Alex
proposal.
I
didn't
write
it,
but
he's
not
here
on
the
call,
so
I
just
wanted
to
haven't
discussed.
G
C
G
G
But
I
mean
it'd
be
something
that
we
could
at
least
consider
moving
forward
with,
under
the
condition
that
we're
kind
of
like
waiting
to
hear
from
people
that
that
we
know
30.
You
know
that
are
raising
concerns
for
things
that
they
know
would
break,
but
it'd
be
interesting
to
at
least
explore
this
I.
A
I
think
for
additional
feedback,
martin
lund
fall.
I
would
say
that,
because
this
is
a
pretty
old
AI
there's
a
magician's
thread
on
it.
When
was
the
last
time
that
was
even
touched,
though,
that
was
okay,
June,
there's
just
a
few
comments.
If
you
could
revive
that
magician's
thread
post
it
to
Twitter
and
reddit
and
other
social
media
that
you
feel
is
applicable
and
get
more
people
to
voice
their
support,
maybe
even
some
of
the
people
writing
these
auditing
tools
that
use
this
and
who
could
benefit
from
it.
A
A
A
Yeah,
we
need
to
work,
we're
good
I'll,
be
talking
about
later
about
redoing
the
EIP
process,
so
this
can
come
up
then,
but
let's
go
ahead
and
just
keep
it
since
we're
practicing
on
this
whole
eligible
for
inclusion
thing,
we'll
keep
it
as
an
EFI
and
add
it
to
the
meta
for
the
EFI
switch
will
be
talk
which
is
now
linked
in
the
core
deaf
agenda
under
yeah,
EFI,
EIP
review
and
I.
Think
yeah,
that's
what
James
did
and
yeah
we'll
come
back
to
this.
For
sure.
Is
this.
A
I
I
A
You
mean
for
the
eligibility
for
inclusion,
yeah
process,
we're
going
through
I
would
say,
I
think
the
reason
we're
doing
it.
This
way
is
so
that
we
can
give
a
preliminary
almost
like
a
thumbs-up,
but
not
anything
official
for
people
to
continue
to
do
research
and
potentially
prototyping
on
their
AIP,
which
actually
dictates
that
it
should
change
and
specification
based
on
feedback.
So
I
would
say
we
should
probably
do
it
that
way.
Based
on
what
we
talked
about
last
time,
but
look,
we
can
definitely
look
at
other
things
too.
I
The
specification
is
mature
enough
to
be
so
before
we
move
that
into
yes,
I
I
mean
the
thing
is,
even
if
starters
we
can
have
like
between
last
call
and
draft.
We
have
another
start
of
saying
education.
It's
almost
Rosen,
because
I
mean
there
could
be
two
in
the
first
set
or
maybe
seems
like
simple
changes
that
completely
change
the
perspective
of
the
yeah
II
green
new
attacks
or
or
make
some
implementations
really
hard
to
implement.
So
yeah.
F
So
when
we
say
EFI
we're
not
saying
that
you
know
you
can
go,
do
whatever
you
want,
there
is
another
gateway
point
that
that
has
to
pass
through
the
all
core
who
says:
let's
put
this
in
a
fork
now
and
so
I
think
we
need
to
consider
where
we
want
to
pile
up
all
these
objections.
If
we
pile
them
up
to
the
very
beginning
in
the
process,
then
we
really
haven't
changed.
Anything
and
I.
Think
one
of
things
I,
like
about
more
into
proposal
to
be
IP
centric.
F
Is
he
getting
preliminary
thumbs
up
and
then
he
implemented?
And
you
can
see
you
know
when
you
implement
from
aspect
unless
you're
very
thorough
with
the
spec,
you
don't
see
anything
even
then
there
are
certain
engineering
problems
that
you
won't
see
by
going
into
the
handling
of
the
spec.
So
you
know
I
think
the
final
you
know
vetting
of
it
for
multiple
clients.
We
need
a
full
specification
before
you
know
the
other
clients
implement
it,
but
I
think
that
you
know,
fixing
that
implement
specification
and
eligible
for
inclusion,
I
think
is,
is
to
hampering
I.
I
A
I
Agree
but
I
what
I
was
seeing
like
like?
We
have
the
spectrum
of
the
on
the
really
lifestyle
we
have
ideas
and
on
the
really
right
side,
we
have
really
well
from
Suffocation's.
What
I'm
saying
is
like
a
IP
issue.
If
it's
only
idea,
we
really
can't
determine
whether
it
is
suitable
for
EFI
really
should
be
at
least
somewhere
in
the
middle.
It
should
be
at
least
have
some
kind
of
education
and.
I
A
I
F
F
If
you
grab
this
something
productive
will
result
from
it
and
without
that
state,
that's
a
lot
of
profit
as
a
problem
with
a
lot
of
the
people.
I
mean
that
was
one
of
the
main
problems
that
6:15
hat
is
they
ran
out
of
money
and
they
couldn't
you
know,
get
some
sort
of.
You
know
a
surety
from
anyone
that
they
would
actually
see
production,
so
they
couldn't
get
grants
for
it.
F
So
that's
I
think
what
the
point
of
this
first
step
was
was
as
much
to
make
sure
that
teams
who
are
already
funded
can
get
some
sort
of
assurance
it'll
happen.
So
when
they
go
ask
for
grants
that
it'll
be
easier
to
get,
I
mean
16:55
or
whatever
the
number
is
for
the
fee
market.
That's
exactly
what
happened
in
1655.
There
is
talk
about
major
spec
changes
already,
so
you
know,
that's
I
think
it's
working
as
intended.
There
I.
I
Mean
if
we're
talking
about
like
financial
financial
support
for
teams,
I,
don't
think
he's
a
big
ask
for
the
yet
he
orders
to
at
least
get
their
specification
into
a
working
state.
That
is
something
at
least
in
the
middle
of
the
idea
and
full
specification
spike.
I,
don't
think
that's
a
big
ask
and
if
we
are
at
least
high
education,
that
is,
will
writin
I,
don't
think
so.
I
A
F
A
A
Yeah
so
whoever's
doing
notes,
we
are
moving
this
to
last
call
and
it
is
also
going
into
EFI.
I
feel
like
right
now.
Last
call
is
a
status
on
an
EF
ID.
Well,
no!
No!
No!
It's
not
necessarily!
This
is
a
weird
case,
so
we'll
just
go
with
the
flow
right
now
and
say
it's
both
an
EFI
and
in
last
call
oh.
L
Yes,
I
could
comment
on
yeah,
be
in
the
terms
of
current
test.
Hey,
oh
yeah.
The
renaming
of
op
codes
would
not
actually
require
to
regenerate
any
of
test
because
the
generated
test
they
consist
of
a
byte
codes.
However,
if
you
want
to
change
some
second
existent
and
test
and
the
solidity
will
already
be
changed,
just
you'll
require
yes,
this
might
lead
to
current
confusion
between
solidity
versions
and
the
test,
but
overall
it
would
not
affect
any
test.
At
the
moment,
I
could
use
like
both
solidity
veterans
and
generates
a
test.
Is
that.
I
A
F
I,
do
I
mean
we're
having
more
steps
to
the
process,
but
I
do
like
the
notion
that
if
something
is
gonna
go
to
EFI,
then
it
has
to
be
noted,
stated
in
one
off
for
devs.
The
next
sounds
weird
ever
going
to
do
it
to
get
people
who
weren't
sensitive
to
review
it.
Although
I
think
you
know,
I
got
some
great
feedback
from
Martin
already
on
this,
but
I
do
think
that
you
know
before
we
should.
A
Got
it
so
generally,
if
you
call
it
to
be
EF
I'd
and
generally,
it
won't
be
on
the
first
awkward
to
have
call
unless
it's
something
like
as
simple
as
what
Martin
lund
fall
brought
to
the
table,
that
we
could
agree
on
pretty
quickly,
but
that
you
would
say
I
want
to
get
this
to
an
EFI
state.
Therefore,
we're
starting
discussion
on
this
is
that
what
you're
saying
yeah.
F
A
I
I
F
I
I
I
The
my
reason
is,
and
of
course
like
with
multibyte
instructions
are
actually
quite
complicated,
is
more
complicated
than
we
previously
thought,
and
we
also
had
like
I
mean
this
code.
Prefix
is
the
really
old
idea
is
started
like
in
when
the
heroism
discussion
was
started,
but
later
we
found
more
and
more
issues
and
code
prefix.
I
That's
why
the
7002
account
versioning
decided
to
move
to
using
the
serger
the
work
out,
the
arrow
key
filled
in
in
account,
and
that's
also
why
the
two
extensions
that
allowing
it
four
versions
of
contractility
provides,
does
not
use
code
prefix
at
all.
I.
Think,
there's
also
a
really
extensive
discussion,
probably
now
that
extensive.
But
we
do
have
some
discussions
during
the
EIP
six
one:
five,
where
we
discussed
why
code
prefix
may
not
be
good
idea,
so
yeah
just
for
reference.
F
So
the
reason
why
I
didn't
go
with
the
extra
field
in
the
in
the
contract
creation
or
with
the
extra
op
cuts
is
that
that
presents
a
tooling
problem.
We
would
need
to
then
also
upgrade
all
of
the
tooling
for
them
to
support
that
as
well.
I
mean
guests
are
also
requiring
them
to
do
the
headers
and
the
wrappers,
but
I
was
trying
to
get
as
minimum
a
footprint
into
here
as
doing
that
and
bringing
in
new
op
codes
and
new
fields.
Just
about
engineering
wise
is
unnecessary.
F
C
C
Prefix
thing
is
that
the
day
before
it's
hard
for
kids,
where
we
start
operating
different
time
code
deploy
a
lot
of
contracts
with
that
code
prefix,
and
it's
the
day
after
once,
the
evm
starts
executing
my
code,
prefixed
contract
that
I
deployed
the
day
before
it
will
try,
treat
it
like
a
validated
contracts,
but
it
is
not
and
therefore
how
should
it
behave
when
I
do
a
jump
to
into
a
data
section,
because
clearly
the
EVM
will
not
do
the
jump,
Aston
alysus
at
runtime.
So
one
of
the
problems,
that's.
F
Why
it's
combined
with
the
account
merging
before
account
merging
turns
on
you,
can
deploy
all
these
old
contracts
with
the
elevation
when
the
cab
versioning
turns
on
when
you
deploy
a
contract
or
bring
it
in
via
transaction,
and
you
have
version
1
on
the
account
that's
when
it's
gonna
validate.
So
all
these
old
contracts
that
have
that
header
will
never
be
evaluated.
Cuz
I'll
be
extra
0!
That's
why
I'm
using
both
of
these
facilities
to
make
sure
for
that
situation,
that
people
don't
clutter
it
up
with
stuff.
I
I
mean
I
also
I
mean
dear
heart.
You
have
beautiful
issues
so
so
far
the
thing
is
code.
Prefix
was
originally
means,
just
be
a
solution
for
our
conversion,
so
we
just
think
decided
like
fervor.
We
have
neutral
proposals,
so
we
just
hides
a
realization
that
whole
prefix
just
won't
work
along,
and
if
you
combine
the
code
prefix,
which
is
combine
code
prefix
with
7002,
we
basically
have
two
layers
of
account
versioning
on
top
of
each
other,
which
is
quite
unnecessary.
I
I
understand
the
tooling
cooling,
so
ecosystem
tooling
concert,
but
the
heat
the
thing
is
I
mean
now
that
has
had
really
done
any
analysis
of
I
mean
which
one
will
actually
bring
more
tools.
The
thing
is
for
some
like
analysis
stores
like
on
evn.
They
would
require
like
oza,
the
aver
mock,
of
course,
of
valid
under
not
beauty
buys.
I
So
so
so
in
that
case,
because
of
the
code
trick
fix
those
tools
might
be
changed,
but
on
the
other
hand,
for
if
we
use
arrow
key
fields
like
I
mean
7002
only
the
thing
is,
we
might
actually
break
marsh
lace
source
because
we
only
require
a
change
in
the
concrete
creation
transaction,
but
not
actually
the
red
code
layout,
not
anything
else.
So,
just
a
general
comments
I
mean
we
can
discuss
this
later.
Is
that
means
out
the
peg
recovery
issue
is
really
has
been
Church.
F
We
do
the
transaction,
then
we
have
to
have
the
compiler
and
the
client
code
and
EBM
versus
if
we
do
the
account
versioning
in
the
rack,
where
we
take
out
the
deployment
stuff,
we
just
need
a
compiler
and
the
EVM.
So
I'll
I'll
note
these
ins
into
that
that
those
are
some
of
the
concerns,
but
you
know
one
of
these
ways.
I
think
we
need
to
get
there
so
that
we
can
start
them,
enabling
these
multibyte
instructions
in
a
solution.
There
is
to
an
end,
a
validation.
F
I
K
A
A
That
would
include
pretty
much
any
in
all
aspects
such
as
what
requirements
are
required
to
get
the
IP
editors.
How
can
we
recruit
the
IP
editors?
What
should
those
be
may
be
redoing,
a
IP
one,
how
to
make
the
process
more
clear
to
outsiders.
Things
like
that,
so
we're
gonna
just
start
having
at
least
next
week's
meeting
will
be
the
first
one
and
then
we'll
decide
from
there.
You
know
what
we
want
to
do
if
we
want
to
have
more
meetings
or
not
if
you're
interested
in
attending.
A
Reviewing
previous
decisions
made
and
action
items
for
call,
74
I
looked
at
it,
it's
basically
the
astable
block
number
was
decided.
The
Berlin
AIP
deadline
was
tentatively
decided
as
the
third
Wednesday
of
March
and
there's
a
list
of
VIPs
that
were
accepted
and
final,
and
some
that
were
eligible
for
inclusion
that
need
to
be
talked
on
more
and
we
might
need
to
start
over
on
that
eligible
for
inclusion
section
on
some
of
those
EIP.
Since
a
lot
of
them,
we
just
kind
of
threw
into
the
efi
bucket
without
having
a
lot
of
discussion
on
them.
A
F
D
D
The
predicting
of
what's
going
to
happen
with
the
it's
really
weird
math
for
some
reason:
that's
how
how
it
was
designed-
and
there
is
a
last
year-
Vitalik
Lane
metallic
wrote
a
script,
Lane
cleaned
it
up
that
and
used
to
predict
and
there's
also
just
going
in
it's
pretty
menial
process.
But
you
just
go
into
the
different
block
numbers
and
figure
out
what
the
values
that
affect
the
ice
age
currently
are.
That's
just
hard
to
make
time.
I'm
working.