►
From YouTube: EIPIP Meeting #9
A
Hello
hope
the
stream
can
hear
me.
Okay
looks
like
it's
going
well,
hi
everyone.
This
is
eipip
meeting
number
nine.
It
looks
like
what
we
got
today
is
the
first
agenda
item
separation
of
eip
process
from
the
hard
fork
process.
We
made
a
lot
of
a
lot
of
progress
on
this
last
time,
so
we
can
start
to
go
over
this
again.
I
think
james.
You
had
worked
on
editing
the
model,
the
the
image
after
last
call
right
or
what
was
I
thinking
of
access
doing
that.
A
Okay,
do
you
want
to
go
over
that
once
the
edits
happened
and
just
review
kind
of
what
we
based
on
what
we
did
last
time,
what
edits
were
made.
B
A
B
So
you
can
go
from
idea
to
draft
and
then
inactive.
I
left
in
an
inactive
and
withdrawn
just
so
we
could
talk
about
it.
I
don't
know
whether
we
should
still
have
two
or
not,
but
just
so
that's
clear
the
and
then
I
need
to
move
this
a
little
bit.
So
I
can
see
it
it's
behind
my
my
thing,
so
you
can
go
back.
You
can
go
forward
to
inactive
or
back
to
draft
or
from
inactive
to
withdrawn
and
but
then
after
it's
withdrawn,
you
can't
go
backwards
without
making
like
a
new
one.
B
What's
the
thought
for
that,
and
then
you
can
go
from
draft
to
review
and
you
can
go
from
review
to
forward
and
that
that
this
could
go
back
and
forth
quite
a
bit
like
between
review
and
last
call
or,
however
it
needs.
Oh,
I
guess
I
need
to
also
put
an
arrow
here.
B
Being
this
one
is
the
the
one
that
I
think
the
between
review
and
active,
that
the
the
way
active
should
work
is
that
you
do
a
change
to
active
and
then
it
goes
into
review
and
then,
after
a
certain
amount,
then
it
goes
back
to
after
that.
The
pr
is
reviewed
and
edits
and
stuff
go
through
that
it
goes
back
to
active
status.
So
people
know
to
go
when
to
look
at
eip.
One,
for
example,.
B
And
it's
probably
good
to
do.
Let's
just
do
quick
definitions
for
everyone
to
be
up
to
speed.
What
we're
talking
about
so
ideas,
pretty
obvious
draft!
Is
you
become
a
draft
when
your
formatting
is
correct
and
you
have
all
of
the
requirements
for
an
eip
inside
of
the
ip
itself?
That's
pretty
low,
like
the
quality
stings
and
a
lot
of
should
it
be
implemented
or
not
or
not
at
all.
B
And
then
that
is
a
request
for
the
community
and
for
other
eip
authors,
saying
that
this
is
at
a
point
where
I
want
other
people
to
chime
in
on
this
eip
and
get
feedback
for
more
it's
in
a
more
stable
state,
or
it's
at
least
articulated
well
for
people
to
come
in
and
listen
to
it,
which,
after
that
point,
then
there's
a
process
of
last
call,
meaning
that
I've
I'm.
B
B
B
And
so
then
that's
how
an
eip
can
be
superseded
the
big.
So
the
last
call
that
is
that
this
line
it
seems
we
were
pretty
agreed
on
or
had
consensus
about
that.
This
is
a
great
way
to
handle
this
flow.
B
A
Only
comment
is
that
in
between
some
of
the
arrows,
we
need
to
make
sure
we
put,
or
maybe
by
the
statuses,
put
like
meta
only
on
active,
so
that
people
know
that
active
is
not
an
eip
status
for
just
anything
same
thing
with
superseded.
Superseded
is
never
with
never
to
be
used
with
a
meta
eip,
because
those
can
only
be
active
or
review.
B
A
And
then
yeah,
that's
all
I
had.
D
Again,
what
is
active
and
inactive?
I
just
didn't
get
the
idea.
B
I
didn't
describe
really
described
it
yet,
so
that
would
be
how
that
fits.
So
active
is
a
special
status.
It's
a
weird
name,
but
it's
related
primarily
to
things
like
meta,
vip
registries,
like
the
efi
document.
What
eips
are
on
efi
that
shouldn't
ever
be
finalized?
That's
a
that's
a
rolling
document,
it's
a
living
document,
that's
continually
updated,
and
so
we
shouldn't.
B
We
should
expect
that
it
is
something
that
is
updated,
semi-regularly
or
when
necessary,
depending
on
what
the
registry
is
and
eip1
is
another
example
of
kind
of
this
special
kind
of
eip,
where
the
idea
is
that
it's
never
finished.
It
is
a
it's
designed
to
be
editable
and
to
have
changes
made
to
it.
So
having
it
be
in
this
having
it
go
through
last
call
and
final
doesn't
make
sense,
because
we're
not
going
to
make
another
eip1
we're
going
to
continually
edit
eip1.
D
So
maybe
the
better
name
for
it
would
be
rolling,
then,
like
rolling
release
of
of
the
you
know
of
linux,
distributions
like
the
whole
idea
that
the
release
is
never
finished.
It's
continuously
updated,
so
it's
yeah.
A
I
think,
rather
than
renaming
that
one
I
almost
want
to
rename
inactive,
and
the
reason
is
because
inactive
and
active
are
not
related
at
all,
in
fact
they're
on
totally
different
eip
tracks,
but
people
may
conflate
them
for
the
fact
that
they
are
generally
mean
opposites
of
each
other.
So
making
an
active
like
a
name
like
stagnant
seems
a
little
bit
more
straightforward
in
my
opinion.
A
But
artem
can
you
elaborate
on
why
you
would
want
to
rename
active.
D
Well,
because
for
me
active
when
I
first
looked
at
this
diagram
today,
I
thought
that
active
is
means
deployed
on
the
ethereum,
and
I
guess
this
is
the
first
thing
that
many
people
would
assume
that
it's
this
eap
is
active.
It's
live
on
the
network.
E
E
D
Oh,
I
guess
that
for
at
least
for
the
newcomer,
both
all
accepted
and
final
and
in
this
case
active
they
are
all
confusing.
B
D
So
active
so
there's
just
you
know
at
the
glance
there's
just
not
enough
distinction
between
active
and
final,
like
yeah,
like
you
said
it's
it's
like
accepted
very,
very
much
like
accepted.
A
I'm
just
googling
synonyms
for
that
and
I'm
not
finding
anything
for
active,
that's
good.
I
found
some
stuff
for
inactive
like
we
could
call
it
rolling.
I
I
like
rolling.
I
think,
because
this
is
a
technical.
This
is
a
technical
specifications
like
repository,
so
rolling
could
be
a
good
one.
I'm
not
like
opposed
to
it
yet
or
anything.
D
Stagnant
works
better.
B
But,
except
accept
it
sounds
like
it's.
It's
like
accepted
into
what
first
thoughts
for
ethereum
improvement
proposals.
Oh
it's
accepted
into
ethereum,
which
is
yeah
yeah
and
domain
name,
which
implies
a
lot
of
stuff,
and
it's
can
and
can
be
confusing.
E
G
Final
I'd
previously
suggested
a
registry,
since
it's
kind
of
meant
for
largest
race.
A
A
So
the
chat
has
some
stuff
elita.
C
A
Oh,
the
only
other
comment
was
active
to
vital
changing
the
word
active
to
vital
was
puja's
idea.
D
I
it
would
give
wrong
connotation
to
it.
I
mean
vital.
E
B
D
A
D
A
I
A
G
D
I'm
not
not
necessarily
staged,
I
mean,
that's,
I
guess
that's
the
next
topic
or
another
topic,
but
or
well.
The
eips
in
general
are
just
building
blocks
for
the
for
ethereum
ecosystem
and
if
we
make
any
eap
final,
if
we
accept
it
into
this
toolbox,
it
doesn't
mean
that
it
is
staged
for
say
inclusion
into
the
theory
main
net.
D
E
Yeah-
and
I
think
final,
like
the
definition
is
literally
the
spec-
will
not
change
anymore
unless
we're
typos,
and
I
think
I
I
feel
pretty
strongly.
We
should
keep
it
as
such,
because
it's
also
it's
also
something
that's
really
distinct
from
the
deployment
right,
because
we
can
say
this.
Eep
is
final.
So,
for
example,
the
prog
power
heap
is
final.
The
spec
is
done,
but
that's
independent
of
the
stage
at
which
it
is
with
regard
to
like
a
main
net
deployment.
A
E
A
Got
it
okay
and
then
inactive
to
stagnant
would.
Would
that
be
something
that
anyone
disagrees
on,
because
I
heard
three
people
say
that
was
better
than
inactive.
B
The
the
intention
for
inactive
as
if,
if
a
certain
amount
of
time
has
passed
and
the
eib
has
been
inactive
or
not
or
or
I
guess
stagnant
is
another
word
you
could
use.
Then
it's
put
into
this
stage,
which
means-
and
it
was
automatic
it
was
by
the
system
automatically
put
into
this
stage
because
of
inactivity.
B
So
it
seemed
pretty
descriptive,
but
I'm
not
I'm
more
tied
to
the
function
than
the
than
what
it's
called.
H
A
A
B
I
would
if
we
were
talking
about
main
net
stuff
I
would
be.
I
would
be
more
tended
to
agree
with
that.
I
think
leaving
it
a
standard
as
being
final
is,
is
articulated
well
enough
or
is
clear
enough
on
its
own.
A
A
B
Yes,
that's
because
I've
I'm
trying
to
switch
out
inactive
for
stagnant,
okay
and
it
and
it
automatically
formats,
so
it
then
had
both
okay.
Here
we
go
yeah.
I
think
the
last
thing
to
talk
about
is:
do
we
have
is
stagnant
and
withdrawn
necessary,
or
do
we
just
have
one.
G
G
I
actually
think
it's
good
to
have
two
because
stagnant
implies
soft
inactivity
and
then
withdrawn
like
assumes
finality,
so
it
might
be
good
to
add
finality
to
the
inactive
statuses.
A
So
we
don't
want
to,
we
wouldn't
want
stagnant
or
withdrawn
to
be
the
only
one,
because
then
the
person
wouldn't
know
if
it's
permanent
and
the
person
wouldn't
know
if
it
just
lapsed
over
time
or
not,
which
is
important
to
make
a
distinction
of.
If
you
want
to
resurrect
it
and
become
a
new
champion
of
it.
First,
for
instance,
because
that
happens,
a
lot
with
the
ips
or
new
champions
come
in.
D
Can't
withdrawn
eips
get
new
champions.
That's
that's
my
one
question
and
another
question:
do
we
want
to
only
have
withdrawn
but
not
rejected?
E
Yeah,
I
think
I
think,
like
also
just
politically,
it
makes
a
huge
difference
to
just
say
you
know
this
is
the
new
proposal
for
x,
and
this
is
what
we've
done
in
the
past
as
well
like
when
we
fixed
like
eip
1283,
the
other
eip
kind
of
combined,
both
the
original
one
and
the
fix
into
one.
So
I
think
it's
it's
simpler
to
like
say
this
is
a
new
iop
which
replaces
this
previous
one,
rather
than
were
kind
of
retaking.
This
odip.
B
B
E
I
think
in
the
in
the
hard
fork
process
you
should
have
a
rejected,
so
it
kind
of
goes
from
from
eligible
for
inclusion
to
like
included
or
rejected,
and
then
the
mainnet
right.
B
Yeah
and
as
last
week,
I
had
a
very
long
conversation
with
with
bryant,
and
he
I
think
I've
been
convinced
that
it's
better
to
have
kept
track.
Keeping
track
of
what's
on
maintenance,
be
part
of
the
hard
fork
process
and
kept
out
of
this
entirely.
A
So,
even
though
it's
kept
out
of
this,
if
I'm
just
a
person
reading
the
eip
repository
and
I'm
like
okay,
eip
972,
I
want
to
see
if
that's
ever
been
included
in
a
hard
fork.
Well,
I
need
to
go
through
every
meta
or
will
that
be
in
the
header
or
every
hard
fork
meta.
I
should
say
how
will
I
be
able
to
quickly
ascertain
that
a
core
eip
has
made
it
into
a
fork
or
not?
B
I
think
there's
two
ways
to
solve
to
solve
that.
I'm
not
sure
which
one
fits
and
that's
a
big
open
question
one
is,
would
be
at
the
status
level
of
having
a
status
that
says
that
this
is
live
on.
Mainnet
like
it's
been
implemented,
so
that
people
know
this
is
something
that's
part
of
ethereum,
which
kind
of
and
then
the
other
one
would
be
to
have
a
document
or
registry
that
tracks.
These
are
all
the
eips
on
mainnet
and
and
have
that
be
a
registry
iap,
that's
tied
to
the
hartford
process.
B
E
Yeah-
and
I
think
the
use
case
is
maybe
a
little
bit
like
weird
like
I
feel
like
people-
will
either
care
about
what's
in
the
hard
fork
and
then
they
can,
you
know,
find
a
hard
fork
or
they'll
care
about
a
specific
eip,
but
I
think
the
use
case
would
say
say
I
don't
know
you
wanted
to
see
his
eip
xyz
included
in
a
hard
fork.
You
just
go
to
the
place
where
the
hard
fork
process
is
defined.
E
D
Yeah,
so
I'm
I'm
a
little
bit
confused.
I
assume
that
this
diagram
that
we
are
discussing
currently
this
process
is
only
about
inclusion
into
the
into
our
eap
toolbox,
so
to
speak,
not
deployment
on
the
on
any
network.
B
A
A
D
Between
so
so
so
your,
but
that
registry
would
be
another
eap.
I
I
assume,
and
it
would
follow
the
same
path
as
that
we
have
been
discussing
for
the
past
half
an
hour.
G
It
would
be
a
living
document,
so
it
would
be
like
eip1
and
the
heart
and
the
eligible
inclusion,
eap.
A
Yeah
I
like
that
idea.
A
lot
does
anyone
else
have
comments
on
this:
the
graph,
the
things
we've
been
talking
about
stuff
like
that,
because
we
can
move
on
to
the
other
agenda
items.
If
not,
it
sounds
like
we're
slowing
down
on
this
and
came
to
a
few
really
good
decisions.
C
I
have
a
question
about.
Am
I
immune?
Okay,
you
can
hear
me
what
what
about
ones
that
are
like
recovery
of
funds
like?
Is
it
eip
999,
which
was
rejected?
C
But
I
wonder
if
someone
had
a
powerful,
I'm
just
hypothesizing
here
had
a
powerful
consensus
building
tool
and
they
could
start
building
consensus
and
if
they
could
definitively
show
that
say
greater
than
90
of
everyone.
90
of
ether,
90
percent
of
the
core
devs
and
everyone
was
on
board
with
on
with
moving
that
from
withdrawn
back
to
active
or
something
like
that
and
and
then
getting
something
approved
simply
because
they
could
definitively
prove
that
everyone
was
on
board
with.
That
is.
C
B
And
the
the
part
about
getting
consensus
from
the
network
to
implement
is
all
on
the
hard
fork
implementation
layer,
not
on
the
standardization
layer.
Like
you,
don't
need,
you
don't
need
consensus
to
define
the
standard
for
your
vip.
You
can
just
make
it
and
then
have
it
be
the
best
that
you
can
think
of
and
then
and
then
all
of
the
other
stuff
happens
in
the
parallel
process.
D
A
A
The
reason
they
would
go
through
when
you
say
they
would
go
through
scrutiny
or
not
clarify
that
would
be
helpful
yeah
like
do
you
mean
the
decision.
What
do
we
define
the
decision-making
process
and
the
standardization
process
we're
talking
now.
D
Yeah,
so
basically,
what
would
be
the
the
bar
for
moving
the
eap
into
into
last
call
and
into
final.
D
Is
an
open-ended
question,
but
but
yeah
I
expect
that
the
this
bar
would
be
lower.
A
For
core
eips,
specifically,
it
would
be
the
first
step
would
be
eligible
for
inclusion,
and
that
would
be.
Someone
has
made
an
idea
created
a
draft
and
then
said
my
draft
is
at
the
point
where
I
want
to
consider
doing
things
like
implementation
test
implementations
that
are
really
rough
stuff
like
that
and
then
from
there,
if
the
if
the
devs
core
devs
say
yes,
this
meets
the
standards
for
efi.
This
is
something
that
could
definitely
go
in
then
it
would
go
from
there
to
like
further
implementations
and
then
into
that.
A
I
A
B
The
I
think,
your
point
artem
that
it's
easier
to
go
from
review
to
last
call
to
final
is
is
definitely
the
case,
and
I,
I
think
that's
fine,
that's
part
of
the
difficult
part
previously
was
the
paul
was
the
political
part,
slash
cordev,
including
in
mainnet
parts.
So
having
that
not
be
a
requirement
to
get
to
final
means,
it's
easier
to
get
to
the
final
stage,
for
if
someone
wants
their
vip
to
get
into
mainnet,
then
there's
just
all
of
the
whole
other
process.
B
That
hudson
was
talking
about
of
getting
it
through
efi
getting
it
through.
B
All
of
these
things,
they're,
like
you,
wouldn't
be
able
to
get
into
mainnet
without
going
through
this
plus
doing
that
extra,
like
effort
and
here
actually
the
review,
I
think,
means
that
they'll
get
better
scrutiny
earlier
earlier,
because
something
we've
had
previously
is
an
eip
goes
for
quite
a
long
time
in
development
and
the
authors
are
working
on
it
and
then
at
the
tail
end,
then
everyone
looks
at
it,
or
at
least
they're,
like
the
scrutiny,
is
really
delved
in
at
when
we.
B
Finally,
just
when
I
finally
put
a
hey,
we're
thinking
about
doing
this
when
so
here
with
review,
it's
a
little
bit
of
combination
of
this
is
this
will
help
focus
conversation
on
eips
from
the
core
devs
and
the
community
as
they
are
ready
to
be
talked
about,
and
then,
even
though,
like
I
think,
greg's
eip
is
actually
a
good
example
of
this.
Sorry,
if
this
is
a
little
bit
of
a
tangent
but
his
his
eip
is
for
doing
the
subroutines
like
this,
the
the
stat.
B
What
he
has
proposed
is
a
is
a
well
thought
out,
like
you
could
say
it's
a
standard
and
you
we
could
make
it
be
a
final
one.
There
are
some
additional
concerns
that
that
the
core
devs
have
related
to
it
like
should
we
have
more
restrictions
or
not
when
it's
when
it
comes
to
deploying
to
mainnet
so
in
in
greg's
case,
it
would
be
easier
for
it
to
get
to
final,
which
is
nice
for
him,
because
he
has
this.
B
He
has
a
thing
that
he's
trying
to
get
done
and
implemented
and
worked,
and
then
other
people
who
want
to
add
on
and
build
on
it
can
do
that,
but
he
does
it
means
he
doesn't
have
to
go
back
and
forth
forever,
trying
to
make
make
what
works
for
the
core,
devs
or
the
rest
of
them.
He
can
get
to
a
finished
product
and
then
additional
things
that
need
to
be
done
like
so
it's
being
implemented
into
the
f-net
that's
coming
up,
and
at
that
stage
we
we
could
say
like
at
some
point
hey.
B
This
is
this
is
good,
but
there's
some
extra
things
that
need
to
be
done
before
goes
into
mainnet
and
we
could
either
now
I'm
rambling
a
little
bit,
but
I
hope
that
has
a
bit
more
more
pieces
that
are
helpful.
That
answer
any
of
your
concerns.
G
One
thing
I
wanted
to
add
was
that
I
think,
having
the
eaps
be
fast
tracked,
being
able
to
be
free
of
strike
to
final,
which
is
kind
of
considered
a
feature,
because
if
you
have
an
eip
in
final
and
it's
and
it's
rejected
by
the
hard-fought
coordination
process,
then
they
can
make
a
version
of
1.1
quickly
to
try
to
address
any
concerns
brought
up.
G
A
D
Yeah,
that's
that's
a
bit
concerning
that.
You
can
have
a
like
a
final
ap
that
will
go
on
a
test
net
and
then
suddenly
an
intestine.
You
discover
issues
and
then
you
have
to
do
another
eip
to
replace
it.
So
it
feels
like
a
lot
of
boilerplate
boilerplate,
but.
E
E
D
But
somewhere
some
eips
are
never
to
be
meant
to
to
be
deployed
on
on
the
main
net
yeah.
E
A
Yeah
you
can
make,
I
mean
I
could
make
something
called
the
icebreaker
format
and
it
like
completely
redefines
how
you
do
account
abstraction
or
I'm
just
throwing
words
around,
and
it
could
go
to
last
call
and
then
final
as
long
as
there
is
as
long
as
there
is
like
the
core,
devs
say:
yes,
that
can
go
to
final,
but
that
doesn't
mean
it's
included
in
a
hard
fork
ever
so.
Click,
for
instance,
is
a
good
example
of
that.
A
A
Okay,
so-
and
there
was
another
client
that
just
skipped
it
so
that
doesn't
mean
that
either
a
networking
protocol
or
a
core
eip
either
one
of
those
could
go
into
a
hard
fork.
But
it
can
still
be
final
and
I
think
we're
going
to
have
to
drive
that
point
home
because
that's
going
to
be
confusing,
especially
since
final
up
until
now
or
including
now
means
that
it
went
into
a
hard
fork.
So
we're
redefining
the
term.
D
Yeah,
just
just
small
notes:
the
networking
eip
is
a
networking
protocol.
Is
it's
a
bit
orthogonal
to
to
the
hard
forks
because
it
does
not
affect
the
chain
state
only
how
the
clients
talk
to
each
other,
so
it
doesn't.
It
doesn't
require
a
hard
fork
deployment
and
it
doesn't
affect
the
chain
state,
so
it
yeah
it
doesn't
require
a
separate
inclusion.
A
Process,
that
is
a
good
point
and
that's
why,
if
on
eip1
right
now,
networking
is
actually
a
separate
category
within
a
within
the
standard
tracks
of
eip.
A
A
D
It
rather
I'm
sorry
I'd
rather
call
it
not
included
but
but
staged,
because
it's
sure.
E
Sure
yeah
I
mean
it's
just
because
we
use
eligible
for
inclusion,
so
I
used
to
but
like
whatever,
that
I
don't
have
a
strong
opinion
on
the
on
the
name,
but
just
mostly
like
how
the
two
processes
kind
of
interact
with
each
other
and
yeah
that
I
have
to
jump,
though
so
yeah
thanks,
everybody
bye,
tim.
A
Thanks
tim,
okay,
okay,
this
was
all
really
good
any
final
stuff
before
we
move
on
to
the
next
item,.
A
Okay,
so
the
next
item
is
an
eip
number
registry
process.
That's
a
lot
better
than
what
we
have
now.
Does
anyone
have
thoughts
on
a
better
process
and
also,
I
guess
we
should
go
over
what
we
currently
have
right
now.
I
believe
it's,
my
pr
number
right.
B
That
is
not
very
well
toxic,
but
does
not
our
we
don't
really
even
follow
well,
but
it
says
that
after
an
eip
is
implemented,
then,
and
after
an
eip
is
mur
as
a
put
as
a
pr,
then
an
eip
editor
gives
it
a
number
and
the
number
usually
references
the
pr
number.
B
A
D
Yeah
I
mean
I
have
the
same
basic
opinion
that
it's
it's
pretty
awkward
and
it
ties
us
to
the
platform
basically
to
github
pull
requests.
But
then
there
is
just
no
better
way
so.
I
So
I
assume
that
just
just
confirmed
are
we
talking
about
the
labeling
or
the
numbering.
I
Okay,
so
the
reason
that
I
thought
changing
it
in
the
or
one
of
the
reasons
I
brought
it
up
was
because,
at
least
with
the
z
cash
model,
they
use
different
numbers
to
signify
different
states
of
the
process
and
different,
like
you
know,
purposes
of
the
actual
of
the
actual
draft.
So
if
we
had
say
a
you
know,
you
could
have
the
same
labeling
scheme.
So
that
way,
it's
that
we
have
right
now.
So
that
way
it's
unique.
But
then
you
have
like
a
dash
zero.
A
That's
an
interesting
idea.
I
think
I
love
how
zcash
does
it
from
at
least
from
my
review
of
the
numbering.
However,
they
only
what
they
do,
if
I
remember
correctly
is
for
things
like
if
it
is
a
consensus,
critical
change,
for
instance,
its
numbers
100
through
199.
If
it's
a
networking
change,
it's
200
to
299
and
the
problem
with
that
is
we
have
so
many
that
we
can't
define
a
pre
a
preset
range
like
they
can,
because
they
have
many
fewer
eip
or
they
have
many
fewer
zips
than
we
do
eips.
C
A
I
Exactly
and
I
think
you
can
take
just
like
an
extension
as
it
were,
just
a
classification
which,
which
is
which
would
be
variable
as
like
throughout
the
process,
and
presumably
that
would
help
maintain
history
of
the
process
as
well.
So
you
could
say,
for
example,
have
the
0
through
90
be
if
it's
whatever
and
then
each
and
then
each
change,
that's
accepted
or
reviewed
increments.
That
extension
by
one
something
like
that.
I
As
I
recall,
the
statuses
were
in
the
header
of
the
eip,
which
might
which,
in
my
opinion,
is
difficult
to
comprehend
or
read.
But
I
suppose
I
haven't
championed
an
eip.
B
B
I'm
I'm
a
little
hesitant
for
that
and
I
think
it
has
to
do
with
one.
We
have
way
better
defined.
Statuses
like
this
is
very
not.
This
is
pretty
comprehensible,
I'm
looking
at
all
the
draft
dips
and
how
they're
organized
things
like
having
the
number
b.
The
link
is
very
easy
to
handle.
B
I
don't
know
if
we
add
any,
I
guess
it's.
I
don't
see
what
we
get
specifically
out
of
having
more
using
the
number
system
to
better
specify
the
statuses
when
we
are
when
we
have
the
statuses.
B
I
don't
really
know
where
I
fall
so
I
have.
I
don't
think
I've
thought
about
that
enough
to
really.
I
want
to
think
about
that
more.
I
So
the
primary
reason
why
why
I
believe
it
would
be
a
or
why
it
would
be
beneficial
is
if
we
have
a
lot
of
vips.
It's
easy
to
say,
query
the
eips
to
sort
only
certain
you
know,
categories
or
certain
state
vips.
C
B
I
wouldn't
need
any
other
information
to
do
that
pretty
easily,
like
writing
a
script
to
do
that,
because
this
is
really
strict
on
what
the
inputs
are.
B
A
Yeah
go
ahead.
G
With
regards
to
the
number
being
tied
to
the
pr
and
issue
number
axic
in
the
previous
meeting
brought
up
the
using
a
smart
contract
to
to
choose
the
number,
I'm
not
sure
if,
if
that's
too
complex,
if
or
if
we
should
continue
using
pr
numbers
for
the
erp
number,
I
don't
see
what
problem
that
solves.
B
That
is
a
lot
more
complexity.
The
the
so
reasons,
I
think
the
vip
number
process
sucks
or
is
really
unhelpful,
is
the
inflation
of
because
it's
tied
into
the
github
issues.
We
get
weird
things
where
well.
B
For
me,
I've
wanted
to
go
in
and
make
a
lot
of
little
changes
to
like
updates
to
eips
like
if
I
was
going
to
change
the
status.
It
would
be
nice
if
I
did
up
like
a
lot
of
changes,
but
I
am
hesitant
to
do
a
hundred
prs
because
I've
immediately
bumped
the
number,
because
I
wanted
to
have
a
couple.
Things
changed
on
a
lot
of
ones,
so
they
could
be
decided
individually.
B
So
then,
I
start
packaging
things
together,
which
has
its
own
like
weird
incentive
like
a
weird
consent,
not
incentivization,
but
like
I
think
you
get
what
I'm
saying
like
it's
it's
ten!
It's
it's
pulling
my
thought
process
into
a
weird
place
because
of
trying
to
work
within
them.
B
The
I
think
itself,
the
it's
confusing
like
having
huge
gaps
in
numbers
is,
is
confusing,
I
think,
to
people
who
it's
like.
Well,
why?
Why
do
we
have
vip
2000
and
then
eip
2150?
B
That's
like
that's
like
more
of
a
just
general
reason,
but
not
like
a
super
hard
reason.
I
would
say
not
to
do
it
not
to
do
it,
how
I've
so
I
I
would
say
it's
a
big
deal
that
we
figure
out
a
way
to
do
this,
that
isn't
tied
to
the
using
github
issues,
because
it
would
free
up
github
issues
to
be
used
for
a
lot
of
other
things.
B
D
Personally,
I
would
just
turn
off
github
issues
for
the
eap
repo
and
put
the
pull
request
submission
behind
some
kind
of
a
bot.
So
you
could
so
people
would
have
an
interface
to
submit
an
eip
and
the
bot
would
just
submit
it
as
a
pull
request
and
maybe
give
that
author.
The
rights
to
the
created,
pull
request.
B
Yeah
getting
the
bot
to
be
better
but
stuff
like
that
would
be
amazing.
I
thought
of
a
proposal
for
doing
that,
for
choosing
numbers
or
having
numbers
and
having
an
eip
registry
of
eip
numbers,
and
then,
when
I
write
an
eip,
I
go
in
and
I
request
this
number
I
like
I
get.
I
get
the
next
number
and
then
the
editors
are
the
ones
that
say
yep,
okay,
because
they
are
the
ones
who
hit
the
merge
button.
B
I
like
edit
that
pr
afterwards
to
be
able
to
get
the
number.
It
would
be
a
lot
easier
for
me
as
a
and
from
an
editor
perspective,
to
sit
down,
write
an
eip.
Go
to
the
eip
registry
say
oh,
this
is
the
next
one
write
in
that
number
hit,
merge
and
then
the
draft,
and
then
that's
just
ready
to
go.
I
B
A
Okay,
who'd
be
responsible
for
the
registry
of
numbers,
the
editors-
I
guess
yep
I'll-
think
about
this
more
and
we
have
one
minute
left.
If
there's
any
final
comments
on
this
talking
point.
D
Yeah,
it's
just
feels
like
github
is
I
don't?
I
don't
know
if
github
is
like
the
best
solution
for
for
eip
management
in
general,
but
yeah?
That's
not
like.
I
have
an
alternative
right
now.
A
Okay,
I
think
we
should
wrap
up.
Then
we
have
a
little
less
than
a
minute
left
if
not,
if
even
that,
so
let's,
let's
get
to
the
other
topics
next
time
by
moving
them
up
the
list.
A
It
looks
like
oh,
the
other
two
topics:
weren't
super
there.
Oh
the
eipip
survey,
though
we
have
a
new
document
on
that.
If
edson
do
you
want
to
run
through
that
real
quick.
G
Yeah,
so
this
is
probably
gonna
be
published
on
friday.
It's
in
the
telegram
I
can
post
it
in
the
chat.
It
just
summarizes
the
results
in
the
form
of
questions
so
say
we're
almost
done
the
set
creating
the
the
eip
process,
statuses
separate
from
the
hard
fork
process.
G
A
Yeah,
but
I
think
so.
G
Yeah
go
through
the
article
if
you
haven't
already
it'll,
be
public
on
friday.