►
From YouTube: Ethereum Core Devs Meeting #73 [2019-10-25]
Description
A
Hello,
everyone
and
welcome
to
today's
core
developer
meeting.
Thank
you,
Tim
for
running
the
last
one.
I
was
away
and
thanks
for
everybody
for
participating
and
I
hope,
everyone
had
a
great
Devcon
who
was
able
to
go.
I
had
a
good
time
overall.
I
think
Japan
might
be
my
favorite
place
to
visit.
So
far,
let's
see.
Oh,
it's
tambul,
that's
a
big
item
and
that's
the
first
one
we're
gonna
talk
about.
Is
there
any
updates
on
the
Istanbul
tests
nets
that
have
been
launched
so
far?
Does
anyone
have
anything
significant?
A
Yeah
I
haven't
seen
anything
the
issues
either.
So
that
means
we
can
probably
look
for
a
main
net
block
number
now
so
do
we
have
any
ideas
on
that
or
are
we
gonna
decide
that
in
get
her?
What
what
are
people
thinking
and
I
guess?
The
first
thing
would
be
like
what's
a
rough
date,
we
want
to
do
it
and
then
we
can
decide
a
block
number
around
that
yeah.
D
B
B
D
D
B
A
B
All
the
clients
need
to
put
the
block
number
into
their
code
and
they
need
to
ship
the
code.
And
then
all
the
exchanges
and
note
operators-
and
you
know,
download
that
code
and
install
that
code.
So
I
think
for
weeks
at
a
minimum,
is
what
we
should
budget
for
that
sort
of
process
of
getting
it
shipped.
Getting
it
out
there
and
give
me
any
user
clients
installed.
B
F
Not
my
only
worry
on
that
by
having
the
backstop
date
be
at
January
like
pushing
Berlin
too
far
back
the
next
one
will
may
get
into
problems
with
the
the
ice
age.
So
I
would
rather
have
it
be
four
weeks
out
with
a
backstop
like
have
the
next
third
Wednesday
on
the
in
November,
see
the
backs,
but
that's
probably
Thanksgiving,
so
that
doesn't
work
but
having
the
backstop
be
the
December
date
so
that
it
isn't
pushed
in
January
for
the
one
hiccup
that
happens.
That
makes
sense.
D
B
A
A
G
We
didn't
really
push
it
a
lot
harder
because
it
was
mostly
just
a
specification
of
how
this
for
Chi
B
would
be,
would
look
like,
but
it
was
wasn't
actually
a
specification
to
include
it
anywhere
general
internal
people
kind
of
liked
the
idea
and
then
the
reason
why
we
brought
it
up
again
is
because
we
had
his
issues
with
Roxton,
where
the
network.
Essentially
there
was
a
miner,
pushing
the
non
forked
chain
quite
a
lot
and
generally
it
clients
have
a
hard
time
following
an
on
majority
chain.
G
Essentially,
this
was
the
reason
why
the
whole
fork
idea
was
created
and
designed,
and
then
the
question
really
was
the
reason
why
we
brought
this
Yeti
up
again
is
because
we
have
an
implantation
and
a
proposal
to
include
it
in
the
handshake
of
the
eath
protocol,
essentially
just
replacing
the
genesis
hash
field
with
this
work,
ID
field.
So
it's
just
a
tiny
beyond
trivial
change.
G
However,
since
it's
an
ecosystem
change,
we
felt
that
we
owe
it
to
the
ecosystem
to
actually
get
a
thumbs
up
and
not
just
roll
it
out
in
Gath,
and
so
as
far
as
I
know,
people
already
liked
the
idea
of
fork
IDs.
So
that's
nothing
new
this.
This
talk
is
just
about
whether
we,
whether
anyone
has
any
opposition
to
actually
start
using
it
or
not,.
D
D
G
Yeah,
but
why
yeah
I
guess
my
question
is:
does
it
make
so
if
it
is
based
on
the
Rob's
turn
Genesis
hash,
but
it
worked
away
into
a
completely
different
direction.
Then
it's
not
really
Roxton
anymore.
So
does
it
matter
that
you
don't
account
it
as
a
Robster
note,
if
you
know
that
it's
not
drops,
then.
D
I
am
just
starting
to
think
about
this,
but
that
really
the
bit
is
that
it
if
you
lose
that
information,
it's
like
an
easy
classifier
for
who
you're
talking
to
that.
That's
my
my
only
objection
since
it's
four
bytes
in
a
one
time
message
it
seems
simple
to
to
to
keep
both
or
to
keep
Genesis
hash
and
include
for
ID.
At
least
that
would
be
my
default
inclination.
G
Yeah
so
I
guess
I'm
not
really
married
to
by
the
way.
So
if
anyone
else
has
any
opinion,
but
for
example,
one
thing
that
we
can
do
is
that
in
each
60,
I,
don't
know
three
four:
whatever
is
the
next
one.
We
can
just
add
to
the
fork:
I
didn't
as
a
new
field
and
essentially
they
would
run
side
by
side
and
then
later
on.
If
we
decide
the
point
of
the
Genesis
hash,
we
can
always
drop
it
later.
D
H
G
Yeah,
of
course,
so
on.
So
this
is
just
a
networking
thing.
So
if
get
throws
out
in
64
with
this
extension,
we
will
still
support
the
old
protocol,
so
every
client
will
still
be
able
to
talk
together
like
nothing
happened,
so
it
is
fully
backward-compatible.
The
reason
why
it
would
be
nice
to
have
at
least
the
consensus
that
this
is
a
good
idea
is
because,
if
is
actually
the
theorem
namespace,
so
we
don't
want
to
turn
it
into
a
gas
wave
space.
I
A
B
G
F
I
just
said:
I
had
a
meta
question
about
that
before
I
know
they
don't
I,
know
that
these
kind
of
changes
don't
require
hard
forks.
Is
there
still
valuing,
or
should
we
have
them,
go
through
the
same,
the
IP
centric
process
or
kind
of
go
through
that
same
funnel?
If
they're
going
through
networking
or.
F
D
F
F
D
Because
we
have,
we
have
mechanisms
in
the
networking
protocol
for
like
negotiating
the
I'm
on
version
63
I'm
on
version
64
I
support
both
that
sort
of
thing.
This
isn't
a
thing
where
everybody
has
to
agree
on
it.
So
so
it's
it's
fine
for
any
client
to
roll
it
out
today,
if
they
wanted
to
and
it
wouldn't
affect
the
network
or
other
other
Peters
really
yeah.
K
K
Regarding
the
CI
piece,
because
we
do
have
an
networking
category
and
21:24
is
there
and
a
couple
of
other
no
discovery,
VIPs
or
ERC's,
whatever
you
might
call
them?
They
are
in
draft
status
right
now
and
I.
Think
one
of
the
questions
maybe
James
had
whether
we
should
have
a
I
piece
for
for
all
of
these
and
I
would
have
a
question
whether
we
should
move
them
to
final.
If
they
are
adopted.
G
So
I
would
say
that,
yes,
we
should
have
a
I
t's,
because
the
idea
is
act
as
these
documentation
so
that
you
have
essentially
two
spec
so
that
if
you
look
at
you
wondering
what
each
64
is,
you
can
just
pull
up
the
spec,
and
then
you
immediately
see
what
the
difference
compared
to
previous
ones,
so,
if
not
for
other
even
for
documentation,
I
think
it's
worthwhile
to
have
a
nice
back
of
the
of
the
change.
As
for
draft
versus
final
I.
G
Think
yes,
if
we
agree
that
we
want
to
roll
it
out,
then
when
we
roll
it
out,
you
should
probably
mark,
for
example,
the
fork
ID
I,
think
there's
some
minor
corner
cases
that
somebody
suggested
we
can
do
cleaner,
but
otherwise
it's
kind
of
more
or
less
final.
In
my
opinion,
however,
the
discovery
ones
I,
don't
know
so
that
can
be
played
around
with
I'm,
not
sure
how
final
that
is.
Probably
Felix
is
a
better
person
to
ask.
G
A
Okay,
I
think
then
I
think
we
need
to.
We
need
to
fix
some
of
the
EIP
process,
so
this
is
more
clear,
but
just
to
avoid
doing
process
for
the
sake
of
process
and
slowing
down
in
the
implementation.
I
think
we
can
say
this
is
final
and
agreed-upon
and
then
we'll
need
to
work
on
how
to
better
provide
a
process
for
these
in
the
future
and
I
think
that's
kind
of
where
you
get
that
James
right,
yeah.
F
G
Just
to
add
a
slide
to
die
diverge
from
that
slightly
I.
Think
so.
One
of
the
whole
reasons
why
this
whole
networking
changes
and
especially
fixes
work
around
discovery,
is
a
bit
problematic
in
the
IP
process
itself.
It's
because
it's
quite
a
few
steps.
For
example,
there's
an
EIP
on
the
LRC
IP
on
extending
discovery
v4
with
the
NRS
there's
an
exe
for
discovering
v5,
there's
an
eID
for
fork,
ideas,
setter,
etcetera
and
honestly,
these
all
should
be
individually
IPs
because
they
are
completely
independently
scoped,
tiny
sub
modules
or
some
protocol
things.
G
G
And
other
thing
is
that
as
far
as
I
see
it
currently,
mostly
Felix
and
Frank,
is
the
two
people
who
push
that
working
aspect,
but
the
only
way
to
prove
that
these
fact
that
these
things
like
en
ours
and
discovery
protocols
and
the
new
DNS
discovery,
the
only
way
to
prove
that
they
are
useful,
is
to
actually
more
or
less
spec
them
out.
Implement
them
roll
them
out
and
then
start
demonstrating
that
hey
these
work,
so
we
can't
really
get
stuck
and
block
each
individual,
a
IP
and
have
discussions
because
most
people
don't
care.
G
A
A
What's
listed,
is
the
process
and
scheduling
discussions
the
Ice
Age
and
the
tentatively
accepted
e
ip's
I
think
we
should
talk
about
tentatively
accepted
the
IPS
at
the
end
and
I'm
debating
whether
to
talk
about
the
Ice
Age
or
the
process
and
scheduling
first,
because
I
think
Ice,
Ages,
dependent
or
one
is
dependent
on
the
other
I'm
trying
to
figure
out
which
way
should
they
be
dependent
on
the
other
and
I
guess
it
depends
on
when
the
ice
age
is
supposed
to
happen.
Does
anyone
have
an
estimate
for
that?
Well,.
E
There
so
I
agree.
That's
like
VIP
centric
process.
It's
probably
something
you
want
to
aim
towards.
I.
Think
that,
given
like
historically
how
slow
hard
Forks
have
been
going
from
like
year,
long
hard
Forks,
with
a
bunch
of
eats
to
month,
like
months
in
between
hard
Forex
and
like
one
eat
for
hard,
for
it
might
be
too
much
too
soon,
and
so
I
I
was
wondering
if
there's
maybe
like
a
middle
ground,
we
can
do
here
like
have
an
upgrade.
E
That's
you
know
just
commit
they're,
upgrading
and
say
six
months
with
whatever
is
actually
ready,
then
so
kind
of
using
the
EIP
process
proposed
by
martin,
but
not
necessarily
going
live
with
each
eat
just
agreeing
on
a
date.
Shipping
whatever
is
ready
by
that
point
and
having
that
be
much
quicker
than
our
current
1
year
cycle,
but
without
going
all
the
way
to
just
having
one
upgrade
for
eat,
yeah.
G
Yeah,
so
I
don't
think
we
necessarily
want
to
go
with
one
upgrade
EEP,
so
I
think
it's
completely
fine
to
say
that
there.
So
even
the
EIP
centric
approach,
we
could
say
that
the
AIE
X
is
ready,
but
we
know
that
there
are
two
more
EITS
that
are
almost
ready
and
can
be
done
in
two
weeks,
so
it
makes
sense
to
bundle
them
together.
So
we
don't
necessarily
have
to
do
cowboy
style.
G
Let's
soon,
as
it's
ready
shoot,
it's
it's
live,
but
we
try
to
do
the
half
year
or
I
think
it
was
eight
month
hard,
Forks,
originally
so
Istanbul
I
think
even
Constantinople
was
supposed
to
be
an
eight
month
thing
and
at
least
our
results
where
that
yeah
can
we
just
add
this
one
and
that
one
and
that
one,
because
people
kind
of
always
feel
that
if
they
miss
the
heart
for
them,
god
knows
when
the
next
one
will
be.
So
sorry.
J
J
L
Hybrid
process
for
this,
like
considering
EAP
central
anything
really
or
10th
floor,
and
we
are
continuing.
The
I
have
pasted
the
link
here
and
you
guys
who
have
a
look
around
it.
I
mean
basically
what
I'm
trying
to
say
here
is:
we
can
ton
get
for
a
biannual
of
credit,
but
there
should
not
be
any
fixed
month.
It
would
depend
upon
the
readiness
of
EITS
and
we
can
consider
say,
for
example,
3
IPS
that
are
bringing
substantial
changes.
We
can
bundle
them
together
and
then
we
should
come
come
to
the
scheduled
path.
L
B
So
I
think
one
of
things
worth
pointing
out
that's
different
from
what
this
proposed
normal
is
tests
are
supposed
to
come
before.
We
include
it
in
a
block
because
what
we
did
before
as
we
would
decide
what
was
in
the
fork
and
then
Alec
would
have
to
implement
it,
and
then
we
have
the
records
tests.
So
now
that
retest
us
is
out
and
we
can
write
our
tests,
invasive
gear,
yeah
or
or
alle.
A
C
Yeah
and
I
just
want
to
us
that's
the
comment
at
Hudson
about
test
first,
so
the
thing
is
why
testing
drags
its
feet
quite
a
lot
historically.
Is
that
it's
very
difficult
to
do
the
testing
and
produce
the
test
cases
where
there
are
no
clients
that
I've
been
demented.
So,
therefore,
the
implementation
needs
to
come
pretty
soon
and
be
activatable
in
the
clients.
A
Yeah
I
I
agree
with
that
I
think
I
was
more
meaning
we
don't
like
we've
been
doing
before
we
don't
say
we
want
to
do
this,
eh
I
pee,
and
then
we
go
through
all
of
the
steps.
Only
two
at
the
end
of
it
say:
oh,
we
don't
want
to
do
it
anymore
because
we
found
this
during
implementation.
I
guess
it's
like
do
final
approval
after
everything's
done.
I
guess
is
what
I
was
trying
to.
I
A
B
E
Think
the
counter-argument
is
aside
from
the
ice
age,
which
I
think
on
the
last
call
we
said
was
not
until
next
summer.
So
it's
something
that's
not
super
urgent.
The
two
Apes
that
had
sort
of
the
most
traction
for
Berlin
were
1962
and
Prague
pal
profiles.
Obviously
pretty
controversial
and
Martin
this
morning
put
a
pretty
long
comment
around
1962,
so
that
one
also
has
some
stuff
to
figure
out.
All
this
to
say,
I
think
we
actually
there's
actually
case
if
he
made
that.
E
F
F
Is
one
I'm
I'm
joining
the
you
have
to
help
with
hard
for
coordination,
so
we'll
have
a
lot
more
time
and
I
on
the
process
itself
and
something
I
want
to
push
forward
and
as
far
as
the
EIP
centric
model
goes
for
me,
it's
a
focus
on
getting
me
eyepiece
ready,
rather
than
focus
on.
When
are
we
going
to
release
whatever
and
then
figure
out
what
will
fit?
So
just
the
the
it's
saying
we're
going
to
have
two
forks
per
year,
wouldn't
be
the
way
that
I
would
I
would
say.
F
A
F
The
changing
the
attitude
from
oh,
how
many
Forks
are
we
going
to
have
this
year
to
focusing
on
getting
a
IPS
progressing
through
the
epicenters
model
and
then
scheduling
them
when
they're
ready
and
having
a
system
of
that?
Okay
like
a
way
of
setting
the
schedule,
so
it's
consistent
predictable
for
people
to
use
I'm
using
the
third
Wednesday
about
having
the
windows
being
six
windows
a
year
that
it
can
ship
rather
than
but
not
saying
we're
going
to
fort
something
then
or
ship
something.
Then
we
can
if
there
is
something
ready.
F
This
is
when
they
will
go
through
and
if
it,
if
it,
if
it
doesn't
make
that
two-month
window,
then
it
hits
the
next
one
and
it
doesn't
hit
the
next
one
and
it
still
keeps
the
focus
on
getting
a
IPs
ready
to
be
forward
rather
than
saying:
hey.
Let's
have
this
date
and
this
white
focusing
on
when
getting
Forks
are
getting
out.
A
Okay,
I
think
that's
I,
think
that's
good
as
far
as
what
we're
gonna
do
for
Berlin,
it
sounds
like
things
are
tending
toward
more
of
an
EIP
centric
model
for
the
e
IPS
that
are
done,
which
would
be
the
Ice
Age
like
the
ice
age
block.
One
is
so
easy.
It
would
be
a
really
great
practice
because
we
can
say
this
has
gone
through
the
process
of
the
EIP
being
written.
You
know
being
implemented.
The
test
case
is
going
in
which
I
don't
even
know.
A
K
Was
wondering
when
to
interrupt
this?
This
might
be
maybe
an
unpopular
opinion,
but
I
kind
of
feel
like
that
the
EIP
centric
model
is
actually
what
we
have
been
trying
to
do
with
one
exception.
But
these
steps
and
the
IP
centric
model
explains
it's
pretty
much
the
same.
What
we
have
in
the
IP
one,
however,
somehow
we
were
not
successful
at
enforcing
those
steps
and
so
in
the
EIP
one
they
initially
accepted
is
just
called
accepted,
which
basically
means
that
people
are
they're
happy
with
the
idea.
K
K
It
took
quite
a
bit
until
some
people
from
clients
could
actually
focus
on
giving
feedback
on
the
IP
actual
low
level
feedback,
because
most
of
these
low-level
yuppies,
especially
the
ones
affecting
the
EVM,
it's
fine.
If
you
give
a
blessing
that
you
know
in
essence,
the
IP
looks
good
and
then
ask
the
or
let
the
champions
to
implement
them
create
the
test
cases,
but
then
how
many
cycles
do
you
do?
Would
you
accept
of
reviews
and
changes
to
that?
K
D
So
I
have
some
thoughts
on
this
I'm,
not
necessarily
like
ready
to
share
in
detail.
But
what
I'm
interested
in
us
looking
into
is
pursuing
the
kind
of
research
model
that
at
least
my
team
has
going
on
with
having
dedicated
resources
on
the
client
teams
that
are
focused
less
on
client
maintenance
and
development,
and
more
on
upcoming
research
and
implementation.
K
So
actually
Piper.
My
second
question
ties
into
to
what
you
said:
that
there
have
been
a
couple
of
IPs
which
had
been
well
received,
but
it
turned
out
that
the
champions
were
never
really
considered
to
implement
those
changes
themselves
or
create
the
test
cases.
They
were
only
interested
in
giving
the
idea
sharing
the
idea
and
then
expecting
client
developers
to
finish
it
off.
I,
wonder
what
will
happen
with
those
we
just
we
just
took
up
the
the
work
in
the
past.
A
It's
bothering
me
now
what
was
the
fork
before
Constance?
No
more
Byzantium
yeah
yeah,
so
the
reason
is
because
now
we
have
more
resources
that
are
in
the
hybrid
technical
non-technical
range,
so
James
just
got
hired
to
specifically
like
have
their
eyes
on
the
process,
work
with
people
to
improve
the
process
and
formalize
it
and
make
and
talk
to
the
client
teams
and
make
sure
everything's
being
done
properly.
A
Also
have
people
like
Pooja,
Tim
and
Trent
and
other
people
who've
been
attending
the
calls
Brent
who
are
behind
the
scenes,
helping
with
stuff
more
so
and
they've,
come
on
the
scene
in
the
last
six
to
eight
months
and
have
been
growing
in
their
roles
and
their
unofficial
roles.
I
guess
I
should
say
so:
that's
gonna
be
the
primary
determining
factor
for
you
saying
how's.
A
What
the
process
could
be
so
yeah,
you
have
improvement
proposals
that
aren't
formal.
You
have
working
groups
around
them
and
then
those
working
groups
improve
like
work
with
the
client
teams
and
on
both
we're
reviewing
and
implementation
and
testing,
and
those
working
groups
of
the
people
who
have
vested
interest
basically
recruit
and
push
for
things
like
review
and
implementation.
A
Oppai
pushed
it
in
the
wrong
chat.
Here
we
are
so.
If
you
look
at
the
what
the
process
could
be
a
theory
m1x,
it
has
a
bunch
of
charts
on
with
smiley
faces
on
what
the
process
could
be
like
in
the
future
and
I
think
we
don't
need
to
figure
it
out
today,
but
be
kind
of
thinking
about
this
model
with
the
other
ones.
We've
talked
about
when
considering
how
we
can
change
things
for
the
future.
K
However,
a
lot
of
VIPs
are
proposed
by
client
developers
themselves
because
they're
close
to
their
the
network
and
they
see
issues
and
they
want
to
fix
those
issues,
so
will
is
a.
Is
there
a
potential
that
we're
going
to
get
into
a
situation
where
these
client
developers
gonna
propose
the
unit
yet
is
going
to
only
work
on
the
only
IPs
and
everything
else
gets
neglected.
I.
D
Don't
think
so,
but
I'm
not
sure
which
model
we're
talking
about
in
the
concept
that
I'm
sort
of
working
towards
right
now.
It
involves
a
lot
more
close
collaboration
between
client
developers
so
that
we're
not
all
working
on
the
our
own
solutions
to
the
same
problems
at
the
same
time,
so
that
we
collaborate
more
closely
and
work
on
similar
things
more
closely.
A
A
Okay,
I'll
just
read
the
comment:
what
does
the
gift
team
look
like?
Are
there
efforts
to
onboard
more
core
members
to
that
team?
What
would
help
shepherding
a
IPS
and
the
same
can
be
asked
of
parity
and
neither
mind
and
the
other
clients
Bessie
is
there?
Is
there
any
ways
that
we
can
expressly
try
to
recruit
more
people
to
the
core
team,
or
would
that
would
that
help
Shepherd
e
IPS,
whatever
people's
opinions.
G
Yes,
so
speaking
for
the
gas
from
the
getting's
perspective,
we've
probably
been
doing
a
really
crappy
job
at
trying
to
find
new
people.
However,
back
when
we
did
have
a
few
people
join
and
then
leave
generally,
it's
not
easy
to
find
somebody
who
would
be
enthusiastic
about
working
on
low
level
protocols
that
wasn't
kind
of
our
the
things
that
I
we've
learned
that
the
gas
code
base
is
quite
complex.
G
It's
quite
a
lot
of
optimization,
so
we
there
is
a
pretty
steep
learning
curve
to
just
jump
in
and
start
making
modifications,
and
it's
also
really
hard
to
review
and
approve.
Be
ours,
for
example,
specifically
because
there's
quite
a
lot
at
risk
and
it's
a
bit
critical.
So
it's
it's
kind
of
hard
to
find
people
and
as
far
as
I
see
it,
not
many
people
enjoy
spending
a
month
trying
to
get
a
25%
speed
improvement
in
some
weird
corner
case
of
of
the
GAF
codebase.
G
E
I'll
kind
of
echo
what
Peter
said
like
so
I'm
from
base
you
Pegasus,
we
are
actively
hiring
the
engineers.
So
if
there's
anyone
with
a
Java
background,
who's
interested
in
this
stuff
and
the
protocol
generally,
we
are
hiring
and
the
the
the
I
think
it's
finding
like
the
intersection
of
people
who
have
like
the
technical
experience
desired
to
do
this,
and
also
there's
a
lot
there's
a
fair
bit
of
like
non-technical
work
that
goes
into
shepherding.
E
If
so,
there's
like
the
uncertainty
around,
you
know
what,
if
you
work
on
this
thing
for
a
year,
it
actually
doesn't
make
it
in.
So
it
is
hard
to
find
people
but
I.
Think
if
you
reach
out
to
anyone
on
this
call
your
destiny
and
you're
interested.
We
can
probably
find
you
somewhere
where
you
can
help
the
community.
K
These
processes
and
I
think
what
we
need
to
somehow
solve.
Is
this
step
one
getting
the
the
blessing
from
a
medicine
from
the
IP
centric
document,
but
basically
the
the
point
where
we
we
weren't
really
good
at
in
the
past,
is
reviewing
a
IPs,
giving
initial
feedback
and
I'm
not
sure,
what's
the
best
solution,
but
I
think
it
would
be
nice
if,
if
there
would
be
like
your
recurring.
K
F
F
It's
reasonable,
I
think
so.
I
experienced
this
on
the
other
end
as
part
of
the
Blake
to
be
proposal
that
I
was
begging,
people
for
feedback
and
then
and
part
of
part
of
what
happened.
Is
it
took
like
almost
three
months
for
it
to
be
merged
to
draft,
and
no
one
really
cares.
If
something
does
that,
it
doesn't
exist
and
like
a
lot,
it
was
so
and
something
that's
something.
I
really
want
to
think
about.
As
part
of
hard
for
coordination
is,
how
are
we
going
to
bubble?
Oh
should
be
looked
at
more
closed.
F
B
Was
just
going
to
say
that
I
thought
if
the
first
one
was
to
get
the
high
level
rather
than
the
low
level
details,
the
in
general
approval
was
to
say
that
awkward
days
were
like
yeah.
This
is
a
good
idea,
go
ahead
and
get
the
final
specification
and
implementation,
and
then,
at
that
point,
when
there's
a
client
implementing
it,
we
can
have
the
details.
I'm
I
wasn't
expecting
that
the
first
step
would
be
full
approval
of
the
full
API
and
all
that.
B
So
you
know
if
someone
came
with
the
proposal,
let's
change
the
EVM
I
could
replace
it
with
JVM
bytecode
that
golfer
desk
and
say
that's
a
bad
idea,
building
track
versus
if
it's
something
smaller
like
I,
think
we
should
support
this
specific
change
in
this
series
of
opcodes.
They
say
it
sounds
like
a
good
idea,
a
minute
all
right
figure
it
out.
You
come
back
and
say
this
is
specifically
what
it
looks
like
it.
Here's
a
test
cases
that
was
my
understanding
may
not
have
been
what
everyone
else
is
understanding
about.
K
Mine
would
be
similar,
but
I
think
this
also
depends
on
the
change,
because
some
changes
might
be
small
enough
contained
enough
that
we
we
can
on,
unlike
if
there
is
only
an
abstract
or
maybe
a
really
short
specification.
It
would
be
enough
to
to
give
a
blessing,
but
some
others
may
be
so
complex
that
you
know
it
may
look
like
okay,
they
make
the
implementation
and
it
turns
out,
it
has
to
be
changed
entirely
and
and
then
we
may
end
up
in
a
couple
of
cycles.
K
B
A
A
M
A
I
Meet
ya
there
was
official
destinies
and
part
of
those
tests
were
created
by
the
goal.
Client
and
the
goal
client
currently
passing
the
blockchain
test,
the
state
test
and
every
other
client
should
download
it
updating
runs
through
that
test
before
the
hard
fork.
Also,
all
tests
were
moved
to
the
legacy
test.
Folder
those
tests.
You
need
to
check
if
it's
affected
by
any
of
the
implementation
of
the
new
hard
for,
because,
like
you,
cool
you
could
break
something
is
an
implementation
of
a
new
changes
in
a
previous
work,
so
legacy
test
adjustment.
I
That
was
the
previous
part
work
rules
to
check
that
they
are
not
affected
and,
yes,
I
would
like
to
see
more
tests,
not
just
the
basic
coverage
of
the
EAP.
So
now,
every
client
developer
is
I'm.
Welcome
to
write
more
test
cases,
misery,
death
situation,
goal,
client
and
busy
client
fully
compatible
with
retested
eh.
Now
you
could
write
a
state
test
transition
test,
I.
C
Do
have
one
update
so
there's
a
new
hive,
that's
been
deployed,
it
has
changed
the
URL
and
I
posted
it
to
the
old
court
of
get
your
channel.
If
you
want
to
check
it
out,
but
it's
running
around
the
clock
always
pulling
the
latest
test,
the
tester
poster
and
the
latest
and
so
far
I
think
if
imperative
clients.
A
Okay,
just
to
go
over
decisions
from
last
meeting
the
ice
age
EAP
will
not
be
included
in
Istanbul.
Oh,
stupid
phone
will
not
be
include.
An
Istanbul
seems
like
there's
no
major
reason
to
do
it
now
should
give
us
enough
time
to
plan
for
another
four
and
not
delay
Istanbul
according
to
James's
calculations,
and
the
other
one
was
bring
your
objections
to
the
all
core
debs
in
two
weeks.
A
If
anyone
is
opposing
the
gift
in
defining
eath
64
as
the
fork
ID
thing
and
rolling
it
out
from
EIP
21:24,
we
already
talked
about
that
cat
herders
are
gonna
reach
out
to
the
Gourley
team
to
make
sure
that
there
are
clear
communication
about
node
upgrades
for
Istanbul
is
one
action
item
and
the
other
one
is
that
David
palm
will
talk
to
way
to
see
if
2200
should
be
self-contained
way.
Did
you
talk
to
David
palm
by
chance.
A
N
N
N
Write
appreciate
that,
and
also
just
a
comment
on
formalizing
the
process
of
getting
AI
P's
approved.
One
of
the
things
you
mentioned
as
some
VIPs
need
lots
of
review
and
other.
Please
don't
need
lots
to
review
and
and
we
need
to
track
how
many
people
are
reviewed
it
and
when
people
review
that,
if
they
find
a
problem,
how
do
you
formalize
that
tracking
anyway,
just
a
mention
for
canonize
er?
N
That's
exactly
what
canonize
er
is
designed
for,
for
example,
you
could
create
a
topic
for
any
IP
and
you
can
have
the
description
of
what
that
topic
is
and
I'll
pointer
to
the
spec
of
the
e
IP.
And
then
you
can
have
people
once
they
reviewed
it.
They
can
basically
sign
that
petition
or
join
that
camp,
and
you
could
have
a
whitelist
of
people
that
are
approved
to
review
an
e
IP,
and
then
you
could
you
use
a
canon,
Iser
algorithm.
That
would
only
count
their
vote,
and
so
you
can
see.
N
Okay
now,
we've
got
six
approved
people
that
can
approve
things
that
have
approved
this
I've
reviewed
and
reprove.
This,
and
also
if
someone
sees
a
problem
with
an
e
IP,
there
is
currently
no
formalized
way
for
someone
to
communicate
that
other
than
to
just
go
to
all
the
forums
and
start
yelling
and
stuff
like
that.
Yeah.
A
A
Bit
and
I
think
that
what
you
should
do
is
have
a
test,
what's
called
like
a
test
vote
or
whatever
it's
called
in
the
Canon
Iser
platform
and
put
that
in
the
etherium
magicians
forum
and
specifically
on
the
page
for
the
Tim
created
or
Dano
created,
I
forgot,
which
one
for
the
upgrade
process
that
process
for
the
train
station
I,
P
centric
model.
That's
an
ethereal
magicians
and
it
is
on
the
first
comment
on
the
agenda:
there's
a
link
to
it
and
it's
under
train
station.
Oh.
A
E
So
maybe
I'm
not
sure
we
want
to
discuss
this
now,
but
maybe
make
a
call
for
the
next
call.
There
were
a
bunch
of
each
them.
We
already
moved
to
tentatively
accepted
for
Berlin
and
I.
Think
there
was
like
some
controversy
around
pretty
much
all
of
them,
so
I
know
that
this
summer,
wouldn't
do
a
whole
bunch
of
them.
Peter.
You
had
a
whole
lot
of
comments
that
Marlin
this
morning,
you
had
a
comment
about
Thank,
You,
62
and
then
there's
obviously
frog
cow,
which
is
another
one
which
people
have
thoughts
on
I.
E
A
Yeah
and
we're
gonna
have
a
meeting
in
a
week
and
I.
Think
that'll
be
the
perfect
time
to
talk
about
that.
Okay,
a
week
from
now
and
cuz
yeah,
we
can
just
kind
of
that'll
be
the
main
topic
of
next
week's
meeting.
Cuz
we'll
have
the
fork
number
by
then,
and
that
way
we'll
get
back
on
track
with
the
meeting
times.