►
From YouTube: EIPIP Meeting #14
A
A
We
usually
talk
about
that
with
james,
but
he's
not
going
to
be
here
today,
but
we
do
have
a
note
from
edson
a
proposal
from
him
for
the
network
upgrade
process,
it's
in
a
github
gist
and
a
comment
at
the
bottom
of
the
agenda
page
so
edson.
If
you
want
to
just
kind
of
go
through
that,
it
looks
really
interesting,
feel
free
to
take
it
away.
A
B
All
right,
so
I
just
started
a
brainstorm,
a
list
of
statuses,
I'll
start
with
that.
So
these
are
just
possible
solutions
for
a
hard
four
coordination
process.
B
These
are
just
ideas,
something
that
we
can
discuss
on
to
see
whether
we
should
move
forward
or
not,
but
I'll
start
with
the
statuses
one's
eligible
for
inclusion.
So
this
opens
the
discussion
for
the
hard
work
implementation,
the
decision
to
implement
them
in
clients
before
testing
after
the
implementation
is
done.
B
They
could
be
motioned
to
do
testing,
to
have
position
to
have
the
eap
tested
to
be
a
test
net
or
just
state
net
tests,
fuzzing,
etc
or
combination
of
these
once
that
the
next
step
is
staged,
which
is
the
decision
for
it
to
actually
go
into
mainnet,
which
includes
deciding
what
date
to
put
it
on
so
once
it's
decided,
both
it's
included
and
the
date
has
been
set.
Then
it's
staged
deployed
as
that
date
is
passed.
B
It's
live
and
rejected
is
during
any
of
these
if
it
doesn't
pass
from
once
that
next,
the
eap
is
rejected,
meaning
the
eap
isn't
going
to
be
eligible
for
mainnet.
C
Yeah,
I'm
just
wondering
just
rejected
like,
for
example,
I'm
imagining
prague,
pow
and
a
lot
of
people
wanted
would
want
something
like
that
to
move
to
reject
it.
But
anyway,
I'm
just
wondering
what
some
of
the
thoughts
are,
how
things
like
that
would
be.
B
Determined
yeah,
so
for
here
it's
just
the
status
is
not
really
how
it's
determined,
but
that
could
be
a
good
way
to
figure
that
out.
Oh
the
next
one
I
just
simplified
it.
So
it's
into
three
sentiment
and
gathering
sentiment
from
qd
for
the
demand
of
the
ap.
So
this
is,
should
the
ap
be
implemented,
it's
s.
First
then
refinement
the
ap
is
implemented
and
tested.
B
So
testing
and
implementation
are
in
the
same
step,
and
then
it's
it's
done
when
the
spec
is
final
made
final
and
then
deployment
the
time
for
release
is
chosen
and
the
eip
is
released.
B
B
Work
any
questions
about
this
one.
A
These
four
that
you're,
going
through
these
groups
of
four
these
are
all
they're,
usually
not
complementary.
These
are
options
right.
B
E
No,
I
was,
I
was
just
going
to
ask
like
these
statuses
that
you
have
mentioned
here,
is
going
to
be
started.
Statuses
attached
to
eips
right,
I
mean
similar
to
like
eip
process
or
how
we
are
planning
to
like
put
them
in
that.
E
B
I
think
we
should
have
this
conversation
another
time,
because
I
think
we
we
already
have
discussed
it
right.
We
weren't
gonna
include
the
status
and
the
in
the
eap,
but
maybe
included
into
meta
eap,
but
we
could
add
another
header
specifically
for
corey
aps.
E
Okay,
sorry,
I
didn't
mean
to
interrupt
and
please
go
ahead
and
maybe
at
the
end
of
this
proposal
I
would
like
to
you
know
mention
my
like
another
counter
proposal,
which
is
like
different
from
statuses,
where
I
I
prefer
to
call
them
as
a
stages.
So
please
first,
let's
continue
this
sorry
of
interruption.
B
Yeah
I
mean
like
here:
I
call
it
stage
so
instead
of
statuses
stages,
whatever
it's
just
kind
of
the
steps
in
the
eip
process,
I
mean
hard
fork
creation
process.
So
here's
the
third
one
eligible
estimated
here.
We
estimate
a
schedule
for
the
or
we
define
the
scope
for
the
eap.
For
so
how
long
it
looks
like
you
might
take
and
then
develop
public
review
public
reviews,
another
synonym
for
auditing
testing
final
request
of
changes,
public
review.
B
B
We
monitor
the
eap
to
see
if,
if
it
is
working
as
I
expected
and
yeah
for
a
period
of
time,
it
might
be
a
couple
months
or
something
any
questions
about
that.
B
B
B
That
all
right,
what
do
you
think
about
all
of
them
like
compared
once
one
to
the
other.
A
F
Grouping
so
for
the
first
one,
I
think
that
the
first
two
items
could
be.
E
However,
I
am
not,
as
I
mentioned
my
reservation
earlier
as
well,
like
I'm,
not
very
much
comfortable
having
it
all
together
in
a
separate
repository,
but
the
process-wise
number
one
looks
good
to
me.
D
Personally,
I
think
number
one
looks
good
as
well
with
number
two
having
the
stages.
I
think
it
could
also
be
helpful
just
to
know
like
like,
for
example,
what
elita
was
saying
about
how
a
number
one
and
two
could
be
together
so
maybe
stage
one
it
could
be
number
one
and
two
stage
two
could
be
like
testing
and
staging
and
then
maybe
stage
three
could
be
deploying
or
then
or
rejection
would
be
the
other.
A
A
Cool
and
then
pooja
you
had
something
about
this,
though,
was
that,
like
directly
related
to
this,
did
you
want
to
say
that
now
or
at
the
end
of
the
meeting
or.
F
E
G
F
E
E
So
here
I
have
tried
to
specify
the
I
mean,
try
to
put
it
in
the
form
of
eip.
It's
coming
up
from
the
eip
that
was
proposed
last
year
for
that
time
process
when
we
were
doing
schedule
base.
But
now,
since
we
have
changed
the
process
and
we
are
doing
more
eip
based,
so
I've
tried
to
change
the
process
based
on
the
efi
and
I'm
just
anybody
has
to
say
something.
I'm
sorry.
A
A
So
for
the
document
you
just
posted
puja.
I
think
this
is
a
tough
one
because
we're
I
we
created
a
test
repo
for
putting
things,
and
this
is
something
we
can
just
go
and
delete
if
we
decide
we
want
to
change
it
later.
But
for
the
moment
we
did
create
a
repo
for
called
eth
1.0
dash
specs
for
specifications
like
efi
and
other,
like
a
summary
of
the
eips
that
go
into
network
upgrades
and
just
kind
of
that
sort
of
thing
so
proposing
an
eip.
E
So,
just
just
to
I
mean
like
be
a
little
I'm
just
trying
to
be
a
little
flexible
here.
I
have
actually
mark
a
specific
section
where
I'm
talking
about
github
repository
and
in
that
in
the
comment
section.
I
have
mentioned
that
if
we
are
planning
to
have
another
repo,
we
can
put
this
thing
in
that
ripple.
E
So
the
process-
what
I
I
was
trying
to
put
here,
is
like
trying
to
define
the
preconditions
for
the
eips
to
be
considered
as
as
an
efi.
So
I
mentioned
to
precondition.
It
has
to
be
a
core
eip
and
it
would
not
be
applicable
for
any
other.
The
statuses
can
be
anything
from
draft
to
final,
because
we
have
seen
that
there,
the
eips
as
soon
as
they
enter
into
the
you
know
as
a
pr
form.
E
People
have
started,
considering
it
for
efi,
because
we
want
to
be
like
you
know,
just
with
the
speed
to
not
delay
the
upgrade
because
of
any
particular
eip.
So
those
are
the
preconditions
and
the
proposal
can
be.
I
mean
like
I
have.
I
have
mentioned
these
like
different
stages,
proposal
socializing
and
reviewing
of
an
e.
So
one
thing
that
I
I
was
trying
to
be
flexible
here
is
like
once
an
eip
is
created
when
I'm.
E
What
I
mean
here
by
eip
is
created
is
by
the
pull
request
that
is
being
created
in
the
eip
repo
and
at
the
same
time,
if
people
want
to
it
to
be
considered
for
efi,
they
can
go
ahead
and
create
an
issue
in.
I
personally
mentioned
here
as
eipip
repository,
but
if
we
have
another
test
repo,
it
can
be
replaced
by
the
test,
repo
and
whatever
is
suggested
here.
The
repository
can
be
changed,
but
my
thought
process
was
like.
E
We
should
be
following
the
eip
numbering
process,
because
at
the
end
of
the
day
the
eip
has
to
be
has
to
be
having
a
specific
number
and
that
is
defined
by
the
pull
request
number
that
is
there
in
the
eip
report,
other
than
the
regular
processes
I
have
mentioned
one
another
new
point
here
is
socializing
of
an
eip
like
earlier.
Socializing
was
just
by
you
know,
having
a
magician
thread,
discuss
it
in
ac
getter.
E
But
there
is
this
new
proposal
that
I
mentioned
in
previous
cathodes
meeting
and
we
would
like
to
have
others
feedback
as
well.
Although
I
shared
it
with
few
editors
earlier,
and
we
received
some
good
feedback
on
that,
it
is
about
a
video
series
on
eip,
where
we
would
discuss
some
eips,
because
sometimes
author
has
this.
E
E
Kind
of
you
know
thing
for
spec
dedicated
to
that
eip
would
be
a
good
reference
point
and
it
would
be
helpful
in
socializing
that
eip
with
community
other
than
that
there
are
some
review
process
steps,
and
I
have
suggested
a
tracker
board
for
the
stages
that
I
was
mentioning
earlier
like
these
efi
can
be
tracked
with
the
tracker
board.
My
suggestion
was
for
eipip
repo,
but
I'm
okay
with
changing
it
to
test
repo
and
the
stages
that
proposed,
except
as
accepted
it's
very
much
similar
to
what
edson
has
already
proposed.
E
A
I
think
this
is
great.
I
need
to
look
at
it
more
before
I
give
further
feedback.
A
Okay,
well
looks
like
we
can
probably
go
on
from
there
unless
anyone
else
had
any
other
comments
on
edson
or
puja's
things.
I
Yeah,
I
was
gonna
say
that
you
know
I
spent
some
time
thinking
about
this
and
I
you
know
after
a
little
bit.
I
just
realized
that
I
don't
have
enough
context
and
I
don't
feel
like.
I
can
really
give
a
good
proposal
on
how
to
actually
upgrade
the
network,
because
I
think
you
know
it's
important
to
come
up
with
the
organizational
flow
of
how
this
happens,
and
I
think
you
guys
have
done
like
a
really
good
job
with
that.
But
you
know
that's
something
that
we
can
definitely
come
to
consensus
on.
I
Some
points
to
me
like
the
most
difficult
problem
is:
how
can
we
make?
How
can
we
get
for
developers
to
agree
on
making
something
happen,
and
how
can
we
have
the
community
buy
into
some
sort
of
road
map
for
ethereum
and
to
me
these
are
like
really
difficult
problems,
because
something
that
you
know
someone
thinks
is
a
good
idea.
I
A
core
developer
may
not
think
it's
a
good
idea,
or
they
don't
have
the
bandwidth
to
implement,
and
so,
like
my
struggle
with
trying
to
come
up
with
something
is
how
do
we
kind
of
overcome
this,
and
I
don't
really
have
a
good
answer
to
it
and
I
think,
like
really
the
only
things
that
I
can
think
of
is
that
it's
just
you
know
one.
We
need
to
avoid
any
sort
of
chain
split
at
all
cost.
I
Even
if
you
know
it's,
I
don't
I
mean
I
don't
know
I
didn't.
I
don't
know
how
to
define
a
minority
that
says
this
is
okay
to
just
change.
Split.
A
ten
percent
of
skinny
thinks
it's
bad
but,
like
let's
say
you
know
in
the
instance
of
prague
power,
this
was
something
that
was
just
you
know
hotly
debated
amongst
the
community,
and
so
we
wanted
to
avoid
a
chain
split
there.
I
I
I
think
that's
like
one
thing
that
we
really
need
to
avoid,
and
the
second
is
that
there
are
things
that
are
coming
in
the
future
that
are
going
to
be
that
are
going
to
be
very
contentious,
like
proof
of
stake
and
sharding
and
stateless.
I
But
this
is
what
they've
kind
of
implicitly
agreed
upon
by
being
a
part
of
this
network.
So,
for
those
sorts
of
things
like
we
kind
of
have
this
like
this,
we
should
have
a
more
formal
definition
of
what
this
roadmap
is,
what
our
principles
of
ethereum
are.
That
way
we
can
say.
Yes,
this
is
a
contentious
upgrade,
but
this
is
what
you
bought
into.
This
is
what
we've
been
saying.
We
want
to
do
for
five
years,
yeah
that
was
kind
of.
J
I
A
Okay,
I
guess
I
really
like
that
direction,
because
it
makes
it
a
little
bit
more
clearly
defined
what
the
community's
values
are.
Like
you
said,
I
don't
know
if
it's
in
the
scope
for
eipip
only
because
we
already
have
so
much
on
our
plate
and
a
lot
of
the
defining,
whether
something
the
reasoning
behind.
If
something
should
be
chain
split
or
to
avoid
it
is
something
that's
more
in
a
procedural
and
not
only
not
even
procedural.
That's
the
wrong
word!
A
It's
in
a,
I
guess,
non-procedural
thing
where
it's
like:
that's
decided
based
on
people
running
nodes
and
even
deeper
than
that.
That's
decided
like
a
direction
on
that
is
decided
based
on
the
procedure.
We
don't
need
a
procedure
to
decide
the
direction
of
a
chain
split.
I
guess
is
what
I'm
trying
to
say.
Does
that
make
sense.
I
Yeah,
I
agree
I
mean
I
think
that
this
is
not
something
that
falls
under
the
authority
of
the
ipip
group.
I
think
I
I
don't
know
how
to
you
know,
build
this
collective
community
roadmap.
We
already
have
some
sort
of
implicit
one,
but
you
know
to
have
a
little
more
formal
one
to
point
to
in
the
event
that
we
have
these
contentious
network
upgrades
in
the
next
two
to
three
years.
F
Yeah,
so
one
idea
I
would
kind
of
throw
out
there
is,
if
we
had
so,
okay
eipip
is
focused
on
the
drafting
process
and
then,
if
you
had
a
separate,
I
think
maybe
even
is
what
the
efi
is.
I'll.
Be
honest.
F
I'm
not
100
clear
on
on
that,
but
if
you
have
like
a
separate
process
for
the
actual
implementation
of
something
once
it's
proven
to
be
technically
sound,
it
would
be
potentially
beneficial
of
the
eipip
group
to
define
at
what
point
it
changes
from
right,
a
drafting
process
to
an
implementation
process,
which
I
think
is
what
you're.
What
you're
talking
about.
I
I
think
the
whole
network
upgrade
process
is
just
like
completely
separate
from
the
drop
saving
process.
Maybe
there's
some.
You
know
back
and
forth
behavior
where
we
start
to
implement
something
and
realize
that
something
the
ip
needs
to
be
updated.
But
to
me,
like
everything,
that's
been
discussed
before
this
is
all
about.
I
You
know
how
can
we
I
mean,
like
we're
implicitly
saying
like
we
have
these
statuses
or
these
stages,
and
we
can
just
go
from
stage
to
stage
to
stage,
but
I'm
just
trying
to
point
out
that
my
question
is
like:
how
do
we
actually
figure
out
how
to
go
from
implementation
to
you
know
thing,
and
I
don't
think
that
it's
right
to
say
just
because
I've
implemented
something
in
every
client
and
it's
technically.
I
Okay,
that
you
know
we
should
have
some
sort
of,
like
some
sort
of
you
know
very
rigorous
definition
that,
because
I
implemented
it
because
it's
in
these
clients
we
can
ship
it.
I
think
that
there
needs
to
be
more.
I
think
there
needs
to
be
more
people
who
are
formally
defined,
as
you
know,
being
accountable
for
the
changes
to
the
network.
I
We
kind
of
implicitly
have
that
you
know
with
the
go
ethereum
team,
but
they
need
to
be
accountable
that
these
changes
are
going
to
be
good
for
the
network
and
they
need
to
have
rationale
why
those
changes
are
good
early.
If
they're
going
to
say,
if
they're
going
to
keep
us
a
change,
they
need
to
have
rationale
why
it's
not
a
good
change
to
the
network,
and
these
are
these
are
things
that
like
go
beyond
just
you
know,
having
stages,
and
you
know
the
organizational
flow
of
it
so.
B
Yeah,
so
so
yeah,
so
that
was
the
next
part
I
excluded,
which
is
how
you,
how
you
move
from
one
stage
to
the
next
so
that
it
it
should
deal
with
like
should
eaps
get
in
versus?
Are
they
typically
sound,
because
that's
the
issue
we've
been
having
with
the
past
contentious
eips
that,
yes,
they're
technically
sound
but
like
yeah
is
the?
Is
it
like
ethical
to
include
that
or
is?
Are
they?
Is
it
okay
to
include
from
philosophical
perspective?
B
Is
there
actual
consensus
for
it
to
be
included,
so
there's
no
hard
fork?
No,
no
chain
split,
I
mean
so.
That's
probably
something
we
should
consider
outside
of
the
statuses,
but
I
think,
having
statuses
defined
or
stages
defined
is
a
good
first
step.
C
Everyone
starts
signing
the
petition
and
he
and
if
he
can
prove
that,
there's
a
lot
of
people
on
board
with
that
eip,
then
you
know
it's
not
going
to
be
consent,
contentious
and
if
someone
else
has
a
different
point
of
view,
they
can
create
a
competing
camp
and
the
community
can
organize
around
that.
The
camp
statements
can
change
dynamically.
C
Unlike
a
petition,
a
petition
can't
change
once
the
first
person
signs
it,
but
these
are
designed
to
be
changed
and
modified
and
negotiate
and
build
and
track
consensus,
and
so
you
can
track
in
a
large
community
how
much
consensus
there
is,
and
if
you
can,
then
basically
we
it
doesn't
need
to
be
formalized
or
defined
or
anything
you
can
just
see
yep.
We
have
90
of
everyone
all
and
well.
We
have
different
ways
to
canonize
things
you
can.
C
F
What
I'm
hearing
is
that
the
general
eip
drafting
process
and
implementation
process
could
do
with
could
deal
with
sort
of
separation
between
the
whole
consensus
problem,
as
well
as
the
general
drafting
problem,
which
is
something
that
maybe
we
should
draft
up.
Something
say
like
for
each
step,
you
know
have
like
a
parallel
consensus
protocol,
that's
being
followed.
J
A
J
A
A
lot
of
comments
we
can
time
box
it
ali
did
you
have
it
was
your
point
responded
to
yeah.
I
did
check
a
message,
real
quick,
so
I
wasn't
listening.
Sorry,
okay,
so
next
up
would
be
constraining
the
eip
repository
scope,
which
we
kind
of
just
we
kind
of
were
back
and
forth
on
that
a
little
bit.
E
A
Yeah
yeah,
this
one
is
on
working
groups,
exploring
the
idea
of
working
groups
and
there
is
a
link
if
you
click
on
it,
to
a
chart
and
a
comment
from
light
client.
So
yeah
I'd
like
kind.
If
you
want
to
just
do
a
summary
of
that
real
quick.
I
Yeah,
so
I
guess
first
before
I
you
know
talk
about
working
groups
rather
than
you
know,
coming
up
with
a
solution
in
search
of
a
problem.
I
thought
I
would
share
like
what
I
view
as
some
of
the
things
in
the
ip
process,
and
just
you
know
the
the
repository
that
I
think
are
problems
right
now
and
I
think
there's
like
two
main
ones
and
the
first
one
is
that
I
think
the
proposals
are
generally
low
quality.
I
You
know,
there's
a
not
a
lot
of
effort
is
put
into
a
lot
of
these.
These
proposals,
they're,
usually
hacked
together
and
then
it's
just
kind
of
left
up
to
editors
to
guide
these
people,
who
are
really
not
even
that
enfranchised
into
being
a
part
of
the
process.
They've
just
decided
to
make
a
pull
request
in
two
hours,
they've
written
something,
so
they
really
haven't
even
read
one.
They
don't
they're,
not
they're,
not
trying
to
make
like
a
really
quality
technical
document.
I
I
think
this
creates
a
cycle
where
proposals
are
low
quality
and
so
the
people
involved
in
the
eip
process.
The
editors
are
not
incentivized
to
really
take
the
time
to
make
the
proposals
better
and
to
really
guide
those
people,
because
there's
just
a
lot
of
quality,
and
so
them
not
being
enfranchised
to
be
a
part
of
the
more
part
of
the
process
leads
to
more
low
quality.
So
I
think
that's
a
that's
a
cycle.
That's
happening
right
now
on
the
eip
or
pod
story.
I
The
second
thing
is,
I
think,
that
there's
not
a
lot
of
people
who
are
willing
to
make
you
know
unpopular
decisions
in
in
the
eip
repository
to
reach
the
goals
of
having
higher
quality
eips
or
to
have
more
informative,
eips
rather
than
changes,
and
I
think
that
instead,
you
know
everything
is
just
accepted
in
the
repository,
because
that's
the
path
of
least
resistance
for
for
the
editors
to
do,
and
so
I
think
that
you
know
these
two
together,
just
creating
like
a
situation
where
the
eip
repository
is
not
something
that
people
in
the
community
are
super
proud
to
be
a
part
of
or
to
to
have
so
it.
I
You
know
if
we're
not
proud
of
the
cip
repository
this,
isn't
you
know
like
a
status,
very
strong
technical
document,
then
less
people
are
like
willing
to
contribute,
and
so
we're
having
this
problem,
where
we
hardly
get
people
to
be
editors,
because
this
isn't
like
a
prestigious.
You
know
role
to
be
playing,
and
I
think
that
we
can
fix
that.
I
I
feel
like
working
groups,
I
feel,
like
you
know,
adding
some
sort
of
additional
hierarchy
to
the
eip
process
would
be
helpful
and,
to
me,
like
I
feel
like
working
groups
is
something
that
pretty
much
every
standard
organization
in
the
world
has,
and
it's
something
that
ethereum
can
implement
into
the
eip
repository,
and
so
in
that
comment
I
just
you
know
shared
a
couple
of
just
like
very
you
know:
generic
working
potential
working
groups
that
I
think
could
add
value,
and
you
know
we
can.
You
know
talk
you
know
all
day
about.
You
know
what.
I
I
We
should
have
some
sort
of
some
people
who
are
in
charge
of
you
know
the
the
actual
or,
like
you
know,
infrastructure
behind
the
eip
website.
Like
what
happens,
if
we
make
a
change
to
the
continuous
integration
suite
like
I
made
a
change
last
week
that
hudson
you
you
emerge,
and
I
didn't
realize.
I
I
made
a
mistake
on
removing
some
quotes
from
a
hard
fork
meta
and
that
caused
the
titles
to
be
to
to
be
erased,
and
so
like
we
change,
we
fixed
it
in
a
pr,
but
there's
no
one
who's
really
accountable.
As
far
as
I
can
tell
for
these
sorts
of
changes.
You
know
this
is
my
mistake,
but
there
wasn't.
You
know
a
group
of
people
going
through
this
pr
to
make
sure
that
it's
all
sound
so.
I
A
Yeah,
I
think
that's
some
good
thoughts.
I
think
starting
small
on
that
is
definitely
important,
so
having
just
a
few
working
groups
to
start
on
a
specific
things
is
kind
of
a
trial
and
also
utilizing
github's
triage
permission
level
at
the
repository
would
be
good
to
start
with,
to
get
people
like
used
to
using
the
repository
and
like
I'll,
put
the
link
in
the
chat,
but
there's
something
called
a
triage
level
permission
set
where
you
can.
A
Contributors
can
proactively
manage
issues
and
pull
requests
without
right
access,
so
that,
and
also
there's
maintain,
which
is
project
managers.
You
need
to
manage
the
repository
without
access
to
sensitive
or
destructive
acts
actions
so
that
that'll
be
nice,
so
that
people
can't
just
like
sneak
in
and
do
a
ton
of
stuff
with
right
privileges
at
first,
if
we
don't
trust
them
or
if
they
need
like
time
to
get
adjusted.
I
And
honestly,
I'm
not
even
sure
if
you
know
the
working
groups
are
people
who
should
have
write
access
to
the
eip
repository,
they
can
sure.
But
to
me
it's
almost
like
they're
going
to
aid
the
editors.
If
the
editor's
job
is
not
to
technically
validate,
so
it
shouldn't
be
to
technically
validate
every
eip.
You
know,
there's
so
many
different
aspects
of
ethereum.
I
You
can
have
someone
who
really
understands
the
evm
and
it
shouldn't
be
their
job
to
also
understand,
like
all
the
toe
different
token
interfaces
in
depth
and
like
how
they
should
be
working
together,
and
I
think
a
great
working
group
would
be
some
sort
of
interface
working
group
where
you
have
a
couple
of
people
who
really
understand
these,
and
they
should
play
a
role
in
commenting
on
the
in
the
eip
repository.
They
don't
actually
have
to
have
the
right
permissions,
but
they
just
need
to
say
hey.
This
is
our
working
group
has
goals.
I
This
is
our
roadmap.
We
wanted
to
design
tokens,
and
that
are
you
know.
Where
can
you
propose,
does
or
does
not
fall
kind
of
like
within
what
we're
working
on?
So
this
is
like
our
feedback
for
you,
so
I
can
prove
this
and
the
eip
editors
can
come
in
and
see
that.
Okay,
the
working
group
there's
comments
on
us.
They
either.
I
think
this
is
like
a
go
or
a
no-go.
I
can
just
go
ahead
and
make
sure
that
everything
is
like
syntactically
correct
and
I
can
just
merge
this.
F
So
to
clarify
is
your
primary
suggestion
that
we
have
sort
of
panels
of
experts
per
se
and
or
auditors
to
verify
changes
that
are
made
to
a
certain
like
category
of
eip.
I
I
think
that
the
way
that
you
describe
it
there
is
more
of
a
reactive
way
yeah,
and
I
would
rather
the
eip
or
the
eap
work
groups,
be
more
of
an
active
playing
active
role
in
the
process.
Rather
than
saying
welcome
to
the
working
group
you're
going
to
just
review
eips
that
come
in,
I
think
that
they
need
to
actively
be
playing
a
role
and
say
this
is
the
working
group
for
interfaces.
These
are
our
goals
as
a
working
group
we're
going
to
design
eips
that
meet
these
goals.
I
If
other
eips
from
the
community
come
in
we're
going
to
be
a
place
that
can
help
give
them
feedback
or
help
direct
them
to
the
right,
you
know
to
to
eips
and
efforts
that
are
more
aligned
with
what
the
goals
of
the
network
are.
This
isn't
stopping
anyone
from
coming
up
with
their
own
eip
and
implementing
it,
but
I
think
that
there's
already
this
input,
these
implicit
working
groups-
there's
you
know,
there's
different,
like
levels
of
how
like
formally
defined
they
are.
I
We
have
the
one
x
working
group
and
they
have
their
sets
of
goals
they're
working
towards,
and
so
they
should,
they
should
be
being
held
accountable
for
that
in
the
eip
process.
I
think
it's.
It's
weird
that
you
know
1x
is
such
an
important
upgrade
to
ethereum,
but
it's
not
mentioned
in
the
the
eip
repository.
I
A
Yeah,
I
don't
have
an
answer
I
wish
I
did
now
that
mike
is
an
editor
come
to
me
and
micah,
and
we
can
start
to
relay
this
idea
and
maybe,
if
you
or
someone
you
know
wants
to
be
like
the
first
guinea
pig
for
this
type
of
thing,
then
that
would
be
helpful.
So
if
you
have,
if
the
plan's
there
and
we
have
someone
who
could
be
a
guinea
pig,
then
we
can
go
to
the
me
and
micah
can
go
to
the
eip
editor's
channel
and
pitch
the
idea.
A
It
doesn't
even
have
to
be
oh,
my
god,
my
phone,
I'm
gonna,
turn
it
off.
It
doesn't
even
have
to
be
too
long
but
yeah,
just
what
whatever
you
want
to
make
it
more
like
official,
that
you
want
to
contribute
for
sure
that'd
be
great.
Okay,
thanks.
A
No
problem,
okay,
standard
format,
so.
A
Which,
oh
one,
oh
I'm
on
agenda
13.?
What
am
I
doing?
My
life
is
a
mess.
Okay.
Now
I'm
back,
we
are.
We
are
now
going
to
item
number
four
new
eip
validator.
The
eip
validator
was
integrated.
Oh
congrats.
Thank
you.
Light
client,
here's,
the
validator
eippr
it's
in
that
comment
and
like
client
for
those
who
don't
know
what
the
eip
validator
is.
Can
you
tell
us
more
about
what
that
means
and
what
you
accomplished.
I
That
runs
every
time
you
submit
a
pull
request
to
eip
repository
and
what
it
does
is
it's
checking
to
make
sure
that
the
epf
is
syntactically
valid,
so
make
sure
that
the
ip
number
is
there
make
sure
that
the
status
is
one
of
the
known
statuses,
with
the
categories
from
the
known
categories,
all
these
things
and
there's
some
other
things
that
I'm
hoping
to
add
into
it,
like
it's
going
to
make
sure
that
all
of
the
headers
from
the
eip1
are
being
respected
and
these
sorts
of
things
so
the
first
version
that
that
was
kind
of
about
parody,
with
the
old
eip
validator
that
was
written
in
ruby.
L
B
I
think
we
should
present
the
statuses,
the
new
ones
for
the
eap
process
to
the
core.
Devs
meeting
get
final
approval
there
and
then
start
adding
it
to
the
eip
repo.
A
Cool
so
yeah,
I
guess,
put
a
pin
in
it
and
we
will
come
back
and
pull
that
pin
out
later
when
we
talk
to
the
core
devs
or
something
all
right.
Anybody
else
have
anything
on
that.
One.
A
Okay,
onboarding
eip
editors.
That
would
be
a
survey
to
set
expectations
of
an
eip
editor
and
triaging
permissions.
Oh
I'm
getting
feedback
on
your
mic
james.
A
There
we
go
so
the
for
the
survey.
I
think
that's
edson
right.
A
And
then
the
triaging
permission
I
alluded
to
this
a
little
bit
ago,
with
my
get
my
github
link
that
I
posted.
But
there
are
permissions.
We
need
to
explore
when
onboarding
new
editors,
to
get
like
junior
editors
to
have,
like
the
triaging
permission
or
a
lower
permission
than
right
privilege
in
order
to
kind
of
get
up
to
speed
on
eips
and
monitor
them
and
stuff,
like
that.
A
A
E
L
A
Yeah-
and
we
should
actually
talk
more
about
that,
because
I
want
to
make
sure
everyone's
on
the
same
page-
the
repo
was
created-
I
don't
know
if
we
ever
fully
decided
as
a
group
what
goes
in
there.
A
E
That
just
one
concern
that
I
have
mentioned
earlier
about
the
about
the
storage
format
like
if
we
are
planning
to
store
it
in
form
of
eip.
If
not,
then
it
is
fine
with
me
because
I'm
not
sure
if
we
decided
on
the
format
of
it
and
if
we
are
planning
to
decide
it
in
some
of
the
eap
format.
I
am
concerned
about
the
number
system
for
this.
A
Yes,
I
see
so
that
might
need
to
be
that
can
actually
be
decided
between
you
and
james
and
anyone
else
who
wants
to
be
in
that
discussion
outside
of
the
call
the
numbering
system,
because,
if
that's
solved
and
then
we
can
move
it
out
of
the
eip
repo,
that
would
make
it
so
that
there
are
less
eips
in
the
repo
that
have
to
be
dealt
with
by
editors
and
they
can
move
to
that
new
repository.
That's
just
dealt
with
by
james
and
whoever
else
is
you
know,
admins
in
that
repository
the
new
one.
L
And
I
I
even
though
we're
moving
eips
over,
I
don't
think
they,
I
don't
imagine
them
being
moved
as
in
the
same
format
or
as
eaps,
because
we
have
an
opportunity
to
optimize
the
format
for
the
specific
case
of
what
we're
doing
outside
of
the
eip
process,
like,
I
think,
a
lot
of
what
we've
done
is
somewhat
like,
held
in,
at
least
by
formatting
and
content
by
the
limits
of
the
eip
process
previously.
L
A
A
A
So
if
you
do
this
second
link,
I
posted
you'll
see
all
the
specs
there's
eth
2.0,
specs,
stateless
ethereum,
specs
and
then
eth
1.0
specs,
and
I'm
hoping
that
1.0
and
2.0
will
get
merged
at
some
point.
But
I'm
not
positive
that'll
happen
immediately
and
I
think
there's
someone
outside
I'm
going
to
check
on
that
real
quick
I'll,
be
back.
Y'all
can
continue.
E
So
if
I
understand
it
correct-
unlike
for
this,
these.
E
Instead,
I
will
be
using
it
as
network
upgrade
or
maybe
retrast
retrospective,
that
we
decided
in
the
previous
meeting
like
retrospective
report
dot.
Md.
Am
I
correct
to
understand
this.
L
Not
totally,
I
mean
you're
you're
right
that
it
will
be
different,
I'm
not
totally
sure
what
it
will
be.
Yet
I
think
we
should
take
some
time
and
it'd
be
great
to
get
in
the
issues
on
the
repo.
If
you
have,
I
idea
this.
That
would
be
a
good
place
to
add
the
network,
upgrade
suggestions
or
other
sorts
of
things
for
how
to
handle
this
movie
forward.
I
don't
know
what
it
will
look
like
immediately,
but
it
will
be
something
I
hope
different.
I
I
just
want
to
make
a
comment.
I
don't
know
how
much
you
guys
talked
about
the
naming
convention
here,
but
I
think
that
you
know
each
1.0
specs
is
very
different
from
these
2.0
specs
repository.
Unless
someone
is
planning
to
go
back
in
and
and
rewrite
the
yellow
paper
in
some
sort
of
spec
format,
it
seems
it's
kind
of
weird
to
use
that
as
a
coordination.
F
Refill
so
I
was
actually
planning
on
editing
the
yellow
papers.
Is
that
something
that
you
wanted
to
coordinate
offline.
I
I
mean
I
guess
I
just
think
that
the
the
yellow
paper
should
probably
live
in
east
1.0
specs
now,
because
the
east
2.0
spectrum
repository
has
all
the
specifications
required
to
implement
these
two
clients,
but
for
each
one
we
don't
necessarily
have
that.
That's
kind
of
the
most
of
the
yellow
paper.
I
I
guess
you
know.
The
weird
thing
is
that
the
east,
these
two
specs
repository.
Doesn't
you
know
they
don't
have
the
concept
of
eips
the
item,
so
I
don't
know
what
the
proper
way
of
like
integrating
the
idea
of
incremental
changes
like
that
that
need
to
be
backwards
compatible
to
expect
refill.
I
think
this
is
mostly
bike.
Shutting
at
this
point,
but
I'm
just
trying
to
say
that
if
we're
gonna
have
a
spec
repo,
it
should
probably
all
be
all
inclusive,
including
the
yellow
paper.
L
I'm
fine
with
that
and
eth2
hasn't
figured
out
how
they'll
update
the
spec.
I
they
haven't,
had
a
vips
ii,
eth2
quote-unquote,
yet
no
so
they're
on
the
other
side
of
this
for
us,
but
that,
but
that
didn't
really
make
much
sense
but
yeah.
I
would
agree
that
it
should
be
inclusive
of
things
like
the
the
current
state
of
ethereum
and
all
you
need
to
do
to
do
a
client.
A
I
I
guess
my
thinking
was
just
looking
at
how
these
two-spec
repo
is
modeled
and
everything
in
these
two
specs
repo
essentially
defines
how
to
write
these
two
o
clients.
So
if
we
have
these
one
o
specs
repo,
where
it
only
has
some
like
new
upgrades
that
seems
like
it
doesn't
follow
the
you
know
for
this.
A
One
it
doesn't
have
to
because
eth
2.0
had
the
the
benefit
of
being
able
to
start
fresh,
whereas
our
stuff,
you
know,
has
a
lot
of
baggage
from
other
repos
and
a
lot
of
history
so
like
moving
like
the
light
cl.
The
yellow
paper
file
out
of
the
old
repo
would
erase
all
of
that
previous
pull
requests
that
people
have
to
reference-
and
you
know
branches
and
things
like
that
for
different,
like
byzantium,
upgrade
and
stuff
like
that.
I
A
You're
right
that
would
be
really
cool,
that'd,
be
so
cool.
A
Okay,
I
think
we're
out
of
time
actually,
so
we
might
wrap
this
up
here
for
now.
Let's,
let's
pick
up
on
the
yellow
paper,
talk
for
next
time
or
in
the
chat
and
were
there
any
final
things
people
wanted
to
throw
out
since
we
didn't
get
through
much
of
the
agenda
before
we
go
that
would
you
know
they've
been
waiting
to
get
an
update
on
or
wanted
some
feedback
on
before
we
go.
L
Okay
feel
free
to
make
issues
in
the
specs
repo
about
the
specs,
repo
or
suggestions,
and
things
like
that
that'll
be
a
place
where
discussion
can
start
happening
around
it.
A
Sounds
good
all
right,
hey
thanks!
Everyone,
a
lot
of
good
stuff
was
brought
here
today.
I'm
I'm
really
really
happy
about
the
progress
see
y'all
in
two
weeks,
thanks
husband,.