►
From YouTube: EIPIP meeting #17
A
This
is
the
one
on
september,
23rd,
2020
and
we're
gonna
get
started
with
the
first
agenda
item
and
if
everybody
can
get
on
mute,
I
think
I
hear
just
the
tiniest
bit
of
background
noise
all
right.
Next
up
our
first
step,
we
have
the
eip
status,
abandoned
versus
withdrawn
discussion.
A
That's
an
issue
in
the
eips
repo
alex
bergzazzi
axic
opened
this
up
and
I
doesn't
even
want
volunteer
to
kind
of
go
over
what
the.
A
If
there
was
a
decision
made
from
this,
I
kind
of
had
trouble
following
it
only
because
there's
a
discussion,
that's
in
here
in
this
eip
issue,
and
then
there
was
a
discussion
on
the
eips
discord
channel
in
the
ieth
r
d
discord
server
and
I
think
james.
You
were
talking
mostly
with
alex
on
this
one
and
micah
a
little
bit
right,
yep
cool!
Can
you
like
the
latest
on
it,
because
I
thought
that
there
was
some
resolution
sorta.
B
Yeah,
it's
mostly
a
resolution
or
I
can.
The
update
is
the
so
we
we've
had
these
statuses.
We
over
a
period
of
months,
discussed
them
and
then
kind
of
settled
and
said.
Okay,
let's
do
this
alex
brought
in
this
addition
of
having
a
status
feel
having
an
additional
field
on
withdrawn,
eips
or
abandoned
whatever
the
term
was
that
we
wanted
to
go
with
that
showed
the
reasoning
for
withdrawn.
B
So
he
made
a
pr
to
have
this
field
be
added
to
the
withdrawn
vips,
which
that's
all
good
which
and
then
it
turned
into
a
a
stagnant,
is
withdrawn
and
abandoned
discussion
all
over
again,
where
we
had
a
lot
of
back
and
forth
about
why
we
would
do
either
and
we
could
I
do
the
I
can
of
course
relay
sort
of
my
thoughts
on
it,
but
I
don't
think
that's
really
the
the
the
more
important
thing
is.
B
I
don't
think
we
should
open
up
it
back
up
to
be
if,
if
alex
and
I
are
going
back
and
forth,
and
then
we
make
a
decision
in
the
discord,
we
have
then
ignored
the
contributions
of
all
the
other
people
who
have
been
part
of
this.
Without
opening
it
back
up
to
everyone
to
be
then
be
a
part
of
it
again
and
that's
just
a
lot
more
time
than
I
think
is
needed
at
this
point.
B
B
Let's
discuss
and
decide
this
today
about
adding
the
status
field
to
withdrawn,
and
if
that's
something
we
decide
on
then
great,
and
if
we
still
launch
the
statuses,
as
is
with
stagnant,
being
a
status,
and
we
can
always
deprecate
stagnant
if
it's
not
working.
How
we
want
and
move
it
into
withdrawn,
like
alex,
is
suggesting
a
minor.
C
Correction
just
for
clarity.
The
reason
field
is
the
way
you're
referring
to.
B
A
Great
and
mike
I
saw
that
you
commented
in
the
eip's
channel
and
the
etherndy
discord
that
that
we
can
go
forward
to
with
the
yeah
like
exactly
like
james
said,
with
the
original
that
given
when,
when
you
were
able
to
could
go
in
and
with
maybe
the
help
of
other
people
go
through
and
change
some
of
the
header
text.
A
Cool
other
comments
on
this.
D
D
But
if
we
have
like
five
minutes,
if
I
can
get
just
five
minutes,
I
would
like
to
just
run
through
why
clarity
on
this
is
important,
because
I
was
also
looking
into
the
document
of
exec
where,
where
the
proposed
process
of
withdrawn
is
there
where
he
is
recommending
that
we
should
be
adding
a
you
know,
reasons
field.
A
I
think
I
I
want
to
put
one
more
point
out,
just
real,
quick
and
then
and
then
let's
get
started
with
your
with
your
piece
of
this
that'd
be
great.
The
thing
I
wanted
to
put
out
is:
do
we
have
a
right
now
is
eip1
up
to
date
where
it
needs
to
be.
I
I
didn't
find
a
pr
that
did
the
right,
statuses,
okay,
it's
not!
So
we
need
to
do
that.
First,
sometime,
okay,
who
volunteers
to
do
that.
D
So
in
the
last
meeting
I
and
james
were
supposed
to
get
it
done.
We
decided
to
do
it,
but
there
was
this
thing
that
one
point
I
was
stuck.
I
also
mentioned
it
to
james
on
withdrawn
and
a
stagnant
for
withdrawn.
The
condition
is
this
proposal
can
never
be
resurrected,
but
when
it
is
a
stagnant,
the
the
thing
is,
the
proposal
can
be
resurrected,
so
it
cannot
be
one
or
the
other
field.
A
A
A
Yeah
and
feel
free
to
go
through
on
your
on
your
discussion
on
this.
I
think
I'm
reading
your
comment
right
now
a
little
bit
and
it
looks
like
it's
pretty
thorough,
so
yeah
feel
free
to
go
over
it.
D
So
it's
my
screen.
D
So
if
we
look
into
this
idea,
this
is
coming
from
execs
eip
overhaul
of
the
document
that
he
has,
and
this
is
the
proposed
process
so
in
this
process.
If
we
look
into
this
idea
draft
candidate
review,
everything
is
fine,
but
when
we
look
into
this
withdrawn
status,
it
can
go
back
to
draft,
but
when
an
eip
is
withdrawn
in
my
in
my
according
to
my
understanding,
it
cannot
go
back.
Please
correct
me
if
I
am
not
understanding
it
properly.
That
is
the
basic
difference
between
withdrawn
and
stagnant.
D
Right
so
I
would
like
to
just
take
everybody
here,
I'll
take
just
five
minutes
to
come.
Why
why
I'm
proposing
that?
I
know
it's
too
late
to
propose
that
I'm
fine,
if
it
does
not
go
through
in
this
time
and
will
go
later
on,
but
just
wanted
to
let
people
know
so
when
we
are
talking
about
eips
this
thing
I
think
I
have
shared
it
earlier
as
well.
This
is
the
current
process
that
we
are
following
in
this
rejected
is
basically
the
coming
going
to
the
hard
fork
network
coordination
part.
D
So
it's
not
a
part,
but
that
was
there
in
the
previous
one.
What
we
are
changing
here
is
the
status
accepted.
It
cannot
be
here
in
the
new
process,
so
this
is
what
we
agreed
upon.
Last
time
idea:
draft
review
living
stagnant
and
then
withdrawn
so
withdrawn.
Here
means
it
cannot
be
pulled
back,
but
it
withdrawn
the
status
that
I
understand
is
something
that
is
given
by
an
author
if
he
wants
to
willingly
withdraw
his
proposal.
D
But
what
for
the
proposal
that
is
not
fit
that
is
not
fit
to
move
to
the
next
state,
then
that
is
also
going
to
get
deprecated.
That
is
going
to
be
terminated
so
withdrawn.
I'm
not
sure
if
this
is
a
good
place
here,
where
all
these
thing
can
go.
So
I
came
up
with
this.
This
basic
thing
is
this
particular
thing
is
what
we
have
right
now
idea
draft
and
everything
abundant
slash
stagnant,
because
they
both
mean
the
same
thing.
D
That
means
it
was
left
by
an
author,
but
somebody
can
pick
it
up
and
bring
it
back
to
the
review
status,
and
then
we
can
start
moving
this
proposal
forward
withdrawn.
I
try
to
put
it
here
somewhere,
so
a
pro
proposal
can
take
it
back,
but
what
happens
to
those
eips,
though
they
have
to
be
deprecated,
they
cannot
be
moved
along.
D
So
I
I
moved
on
to
the
this
next
proposal.
Then
withdrawn
should
not
be
a
status.
It's
just
a
reason
why
eip
is
moving
into
the
deprecated
or
a
terminal
state.
This
leaves
us
with
this
put
this
process
in
which
nothing
is
added,
except
for
a
review
state.
That
means
whatever
we
are
having
right
now
is
there
we
just
removed
the
accepted
status,
which
should
be
part
of
network
upgrade,
and
we
added
a
review
state
which
everybody
agrees
to
that.
That
should
be
there
for
a
longer
period
to
get
that
proposal
reviewed
and
okay.
D
Fine.
This
is
the
network
upgrade
process.
I
was
just
trying
to
combine
them
together,
so
the
network
process
that
is
coming
from
the
james
project,
port,
cfi,
cfi,
approved
and
everything
else,
try
to
add
the
ad
status
here
and
then
how
we
are
gonna
join
these
two
things
like
core
eip
process
and
network
upgrade
process.
They
have
to
be
linked,
so
this
is
a
proposal
I
mean
this
is
my
my
that
this
is
the
way
this
can
be
linked
together.
D
So
yeah
I
mean
that
is
all
about.
Why
I
am
proposing
just
to
be
not
I
mean
withdrawn
and
abundant
cannot
be
one
thing
because
abundant
can
be
resurrected.
Withdrawn
cannot
be.
A
Okay,
thanks
for
all
this
work,
this
is
really
good.
I
would
say
if
you
go
back
to
slide
seven
or
is
it
a
it's?
Eight?
Sorry,
if
you
go
back
to
slide,
eight,
oh
by
the
way
brent
cfi
stands
for
oh
wait
until.
D
A
Yeah,
so
for
this
one,
I
think
so
this
is
one
of
the
two
process.
Iterations
you've
proposed
right
right,
got
it
okay,
I
like
the
second
one
better
because
there's
less
arrows,
and
I
think
that
makes
it
a
little
more
clear.
A
D
No
withdrawn
will
not
be
within
abandon,
it
will
be
with
deprecated,
and
here
is
the
reason,
so
I
have
mentioned
these
three
reasons.
One
would
be
author's
choice
that
would
be
considered
as
withdrawn.
D
Number
two
could
be
no
activity
over
a
period
of
two
to
three
years,
because
generally
I
mean
I
have
seen
that
proposal
takes
about
a
year
to
go
into
next
stage,
so
if
it
is
not
moving
for
two
to
three
years,
that
can
be
moved
to
deprecate
it
and
the
third
reason,
which
is
very
obvious,
fail
to
move
to
next
step
up
because
of
any
of
the
technical
impossibility
or
something
is
not
right
there.
So,
whatever
reason
we
consider
this
to,
you
know,
stop
working
on
that
proposal.
D
I'm
suggesting
this
because
I
was
trying
to
achieve
these
two
goals.
The
number
one
goal
is
close,
the
pr
spending
for
a
very
long
time
right.
That
is
our
idea
of
having
these
these
things
redefined
and
work
on
it,
and
the
other
thing
is
we
want
to
have
the
correct
list
of
eips
that
are
actually
valid,
and
people
may
be
working
on
it.
D
So
that
is
the
thing
that
I
think
that
adding
a
reason
field
as
exec
suggested
would
help,
but
I
am
still
not
convinced
that
we
should
have
withdrawn
as
a
separate
status.
I
find
that
as
a
reason
for
closing
a
pull
request.
A
Okay,
I'm
coming
around
to
that
personally,
but
I
want
to
hear
what
others
have
to
think
what
others
think
about
this
whole
deal.
C
What
is
the
argument
for
having
it
so
certain
eips
cannot
go
back
to
draft.
Like
I
mean
from
a
theoretical
standpoint,
you
can
always
just
create
a
copy
of
it,
so
you
can
always
get
it
back
to
draft
it's
just
whether
it'll
have
a
new
number
or
not.
What
is
the
reason
for
not
allowing
that
number
to
be
resumed
later.
A
There
would
be
there
would
have
to
be
some
intervention
as
to
basically
there
could
be
some
intervention
into
the
authors
section
and
other
pieces
of
when
it
was
so.
You'd
have
to
go
in
and
completely
change
the
header
file,
and
you
would
have
to
somehow
reflect
that
there
was
an
original
idea
from
an
original
author
at
a
different
date.
A
C
A
C
Sorry,
sorry,
I
I
definitely
agree
that
no
one
should
be
able
to
change
the
author
on
the
ip
except
for
the
author.
I
firmly
believe
that,
and
I
agree
fully.
I
guess
for
me
the
if
an
author
two
years
later
wants
to
change
the
authorship
or
decides
to
resurrect
it.
Why
should
we
stop
them
like?
Why
would
we
not
want
to
allow
that.
D
That
is
allowed
that
is
allowed
in
the
case
of
abandon
and
in
the
case
of
abandoned.
The
original
author
may
give
permission
to
another
champion
to
take
his
proposal
forward
and
that's
what
we
do
say
for
the
example
of
one
zero
five
seven,
this
the
original
author
has
allowed
greg
to
take
it
forward,
so
he
is
bringing
in
the
meeting
and
he
is
actually
now
added
as
an
author
to
that
proposal.
So
that
is
allowed
in
the
case
of
abandon,
but
not
in
the
case
of
withdrawal.
C
B
The
so
the
example
I
would
use
is
25
25,
the
lock
rewards
vip,
so
I'm
I
am
intending
to
have
that
be
withdrawn
and
the
if
someone
was
to
res
so
and
there
I
don't.
I
think
it's
me
and
I
think
it's
just
me
and
someone
else
is
the
author.
So
I
guess
if
we
sat
down
and
and
undid
it,
but
I
would
definitely
not
want
someone
else
to
resurrect
the
eip
and
somehow
me
be
tied
to
it.
B
C
C
C
Steal
that
authorship
from
me
or
transfer
that
off
on
my
behalf,
the
situation
I'm
considering
is
like.
So
in
your
example,
you
don't
want
any
anyone
to
take
over
your
ip.
You
want
it
to
go
away,
in
which
case
you
can
make
it
go
away
by
just
simply
not
giving
anyone
rights
to
it.
So
you
would
mark
it
withdrawn.
It
would
go
into
the
the
trash
bin,
basically
where
it
would
sit
forever,
because
you
will
never
give
rights
to
anybody
else
to
take
it
over
the
situation.
C
I'm
wondering
about
is,
if
you
decide
in
a
year
or
two,
you
change
your
mind
like
you
know
what
there
really
was
a
good
idea.
I
want
someone
to
take
this
over.
Why
why?
Why
are
we
stopping
you
like?
Why
does
the
ifp
editors
have
to
stop
you
from
doing
that,
like
what
do
we
gain
from
preventing
you
from
doing
that?
As
the
author.
A
I
think
you
get
a
little
bit
more
clarity
for
people,
I
think
you're,
adding
an
extra
line
or
you're
adding
an
extra
arrow,
but
you
are
not
so
I
guess
you're
resurrecting
from
a
band
and
just
to
go
over
your
proposal
micah,
it
would
be.
You
can
resurrect
from
abandon
and
you
can
resurrect
from
withdrawn
or
actually
you
can
resurrect
from
anything
but
rejected
right.
B
C
A
Also,
the
idea
that
so
I
guess
someone
could
come
up
with
a
competing
eip
in
the
future
with
an
eip,
that's
been
withdrawn
and
then
someone
could
just
resurrect
a
really
old
eip,
which
would
to
some
people
say.
Oh,
this
person
had
precedent
on
the
standard
and
it's
maybe
like
it
would
have
the
illusion
of
either
being
further
along
or
more
official
to
the
average
eye.
C
So
your
goal,
I'm
sorry,
just
to
make
sure
I
understand
that
correctly.
The
goal
with
the
finale
is
with
permanency
is
specifically
permanently.
You
want
finality
to
things.
You
want
a
state
that
cannot
be
undone
just
for
the
sake
that
it
cannot
be
undone,
so
people
can
rely
on
it,
not
being
undone.
Okay,.
A
Yes,
it's
because
there's,
I
think,
there's
edge
cases
we're
not
thinking
of
number
one
and
number
two.
It
would
make
it
easier
and
make
it
easier
to
have
and
have
a
little
more,
maybe
another
arrow
or
another
line,
but
it
would
have
finality
yeah.
I
think
that's
that's
the
best
way.
To
put
it,
were
you
saying
puja.
D
So
I
was
wondering
like
if
stagnant
and
abandoned
both
can
be
resurrected.
Why
do
have
two?
Why
not
have
just
one
I
mean
like
if
we
look
into
the
exceptional
statuses
that
is
mentioned
in
the
eip1?
It
says
that
author
or
new
champion
wishing
to
pursue
this
aip
can
can
ask
for
changing
it
to
draft.
So
if
we
are
giving
the
permission
even
with
the
withdrawn
either,
why
to
have
the
status
will
be
drawn
in
the
first
place.
Let
it
be
abandoned.
C
I
believe
that's
alex's
entire
argument
is
that
these
two
statuses
are
very
very
similar.
The
only
difference
is
how
it
got
there,
so
that
which
is
like
the
reason
field,
and
so
if,
but
I
think,
alex
is
under
the
assumption
that
we
do
not
want
the
statuses
to
have
different
finality
like
one
one
is
final,
one
is
not
or
not
final
bad
word
here,
but
it's.
B
Permanent
yeah-
and
I
I
would
there
is
there's
just
kind
of
weird
stuff
that
happens
with
cloud
on
numbers
being
lower
there
and,
and
things
not
being
final
like
like
imagine
the
the
the
resolution
that
would
be
for
the
community.
B
C
C
I
think
that
I
was
missing
that
in
all
the
previous
discussions
yeah,
like
I
agreed
with
alex
previously
that
those
two
circles
should
be
the
same,
because
I
did
not
realize
they
had
different
finality
constraints
with
them
having
different
constraints,
then
I
understand
why
we
have
two
separate
statuses,
I'm
on
the
fence,
whether
I
agree
with
the
finality
being
a
desirable
feature
or
not,
but
this
whole
conversation
makes
a
whole
lot
more
sense
now
or
the
whole
debate
rather.
F
So
I
have
a
question
on
this
slide,
so
it
says,
abandoned
and
deprecated.
I
thought
the
current
proposal
was
stagnant,
withdrawn.
D
Yeah,
fine
yeah,
that's
fine!
I
mean
I
put
abandoned
to
make
it
very
closer
to
whatever
it
is
right
now
current
proposal,
but
it
can
be
stagnant.
I
mean
there's
no
issue
with
that.
F
A
D
Rejected
originally,
originally,
it
was
rejected.
We
can
use
that
term
like
we
need
something
to.
You
know
even
link
that
if
we
want
to
use
the
real
term
the
rejected
one
here,
we
can
remove
the
deprecated
and
that's
how
we
can
connect
the
core
process
core
eip
process,
as
well
as
network
upgrade
process.
D
C
A
G
Sorry,
I
was
going
to
say
I
think
if
we
want
finality,
there
should
be
some
official
role
that
moves
things
from
stagnant
to
withdrawn
at
some
point,
because
we
don't
want
to
have
someone
with
eep
2
3
4
have
their
ebit
stagnant
for
five
years
and
then
decide
they
want
to
resurrect
it
and
put
something
completely
different
in
there.
It
seems
like,
after
two
to
three
years
of
being
stagnant,
it's
okay
to
move
into.
D
So
here,
in
the
reason
I
have
mentioned
like
if
there
is
no
activity
over
two
or
three
years,
this
flex,
okay,
fine,
this
model
provides
flexibility
even
to
bot,
as
well
as
author
and
the
editor.
D
So
when
an
editor
chooses
to
move
any
proposal
or
the
bot
chooses
to
move
any
proposal
because
it
has
not
been
active
for
a
very
long
period,
they
can
move
it
to
a
suppose
rejected,
not
duplicated
move
it
to
reject
it
there,
but
if
an
editor
or
a
bot
choose
to
move
any
proposal
to
withdrawn,
I
don't
think
that
would
be
acceptable
like
in
this
case.
If
this
withdrawn
is
done
by
a
bot
or
an
editor,
I
I'm
not
sure
if
editor
would
find.
D
The
editor
would
be
comfortable
with
that,
because
withdrawn
is
something
when
an
editor
asks.
I
have
mentioned
this
in
this
example
like
for
one
of
the
recent
eipz2583.
I
think
this
was
of
martin
and
he
mentioned
in
one
of
the
meeting.
I
need
this
to
be
withdrawn,
so
he
wants
it
to
be
withdrawn.
This
has
to
be
closed.
Now
this
pull
request
has
to
be
closed
as
soon
as
possible
because
when
we
say
withdrawn,
that
means
no
other
champion
can
take
it
forward
right.
G
If
we
are
interested
in
having
withdrawn
represent
finalization,
I
don't
understand
why
an
editor
or
a
bot
can't
move
eeps
to
that
set
stage,
because
it
seems
like
you're
not
always
going
to
have
the
author
around
to
vocalize.
If
it's
okay
to
move
to
withdrawn-
and
it
seems
like
the
reason
we
want
finality-
is
to
avoid
the
cases
where
you
have
a
low
number
eep
that
they
kind
of
decide.
B
What
was
I
going
to
say
so,
if,
if
you
allow
an
eip
editor
to
move
it
from
withdrawn
from
stagnant
to
withdrawn,
that
becomes
a
political
decision
about
whether
or
not
it
should
be.
G
G
They
can
like
get
started
again,
but
if
we
want
withdrawn
to
be
a
thing
that
avoids
authors
coming
like
far
down
farther
down
the
line
and
trying
to
resurrect
it
and
have
a
low
number
to
do
something,
maybe
different
than
what
they
had
originally
proposed,
or
to
have
more
credibility
against
the
competing
proposal,
that's
something
that
they're
unlikely
to
have.
You
know
actively
asked
to
be
put
to
withdraw
and
so
to
avoid
those
scenarios,
which
seems
to
all
hope
to
be
the
whole
reason
we
have
find
the
finality
of
the
status.
G
C
C
Like
something
that
a
bot
could
do,
I
mean
whether
it's
a
bot
that
actually
does
the
task
or
a
human
that
does
the
task.
I
don't
care
about
as
long
as
the
decision
making
is
algorithmic.
So
if
that
algorithm
is
just
this
many
years
since
the
last
touch
or
whatever
and
that's
algorithmic,
whether
I
do
click
the
button
or
above
this
button,
don't
care.
But
I
do
agree
that,
as
an
editor,
I
would
not
want
to
ever
put
something
into
withdrawn.
That
was
not
algorithmic.
C
A
I
think
this
is
compatible
with
how
we
just
about
how
we
have
it
then,
besides
the
combining
so
just
to
kind
of
go
over
right.
What
we
have
right
now
for
the
eip,
that's
going
in
with
puja
and
james.
What
we
have
is
stagnant
withdrawn
and
we
have
slide
seven.
What
we
we
have
right
now,
right,
yes,
okay
and
then
slide
nine
is
the
proposal
and
with
slide
nine
or
is
a
proposal
and
with
slide
nine
we
have
abandoned
and
stagnant
still
and
then
deprecated
separate.
But
some
people
are
saying:
let's
combine
the
two.
C
A
Okay,
so
alex
is
the
one
that
still
is
probably
it
could
be
in
favor
of
that
before
we
explain
what
we
talked
about
in
this
meeting,
so
that's
to
be
determined
yeah,
and
so
the
thing
we're
mostly
agreeing
on
is
the
reason
field.
I
think
we're
all
there
with
the
reason
field,
we're
not
entirely
there
with
what
the
names
are
going
to
be,
but
that's
not
too
hard
so,
for
instance
like
if
we're
going
to
keep
it
deprecated
or
rejected.
Like
that's
one
thing.
A
F
B
B
B
D
I
think
when
we
start
defining
withdrawn,
the
problem
will
be
highlighted
here,
because
when
we
define
the
term
withdrawn,
we
mentioned
that
this
is
an
act
by
an
author
when
he
decides
that
the
peer
cannot
move
any
further
right.
But,
according
to
the
present
diagram
that
we
are
considering
here
withdrawn,
is
something
that
can
be
done
by
a
bar
by
an
editor
and
not
specifically
by
an
author
as
well
as
if
something
moves
on
from
stagnant
to
withdrawn.
D
B
B
C
A
A
B
So
I
can,
I
can
edit
it's
pretty
easy
to
add
to
this
diagram,
so
I'll,
go
back
to
the
heck,
md
and
add
in
the
extra
arrows
and
not
have
them
be
implied.
B
Yeah
and
we
we
also,
we,
we
kind
of
decided
we
to
go
with
micah
on
that
from
my
memory.
D
I
get
it,
I
I
think
I
read
it
somewhere
on
mika's
comment.
Sorry,
I
messed
up
on
that
part.
I
got
it
no
problem.
A
Okay,
we're
almost
there.
I.
B
Feel
it
so
I'll
add
the
I'll
add
the
arrows.
So
it's
not
implied
and
that
will
help.
C
I
have
a
minor
preference
for
abandon
for
that
last
circle
because
it
doesn't
imply
whether
it
was
voluntary
or
not.
Yeah.
D
C
B
C
D
B
Either
we
keep
it
at
withdrawn
or
we
change
it
to
abandoned.
If
we're
gonna
have
it
be,
or
maybe
we
just
keep
it
at
withdrawn
and
then
do
a
proposal
for
having
an
algorithmic
way
to
get
to
withdrawn,
and
at
that
same
time
we
have
it
be.
We
then
add
it
to
abandon,
because
if,
if
an
author
can
is
the
only
one
that
can
choose
for
it
to
go,
then
withdrawn's
the
best
word
if
either
an
author
or
a
bot
can
get
there,
then
withdraw
no
longer
is
the
best
word.
D
E
E
B
A
practical
case
of
where
this
interaction
would
was
would
have
happened,
is
1559
had
at
least
six
months
of
no
one
working
on
it.
Early
last
year,
before
the
like
in
between
vitalik's
work
and
vulcanize
picking
it
up,
it
would
have
gone
to
stagnant,
but
when
it
was
resurrected,
it
would
have
gone
back
to
draft
and
working
again
and
in
that
case
keeping
the
same
eip
and
the
authors
and
all
that
stuff
totally
makes
sense.
B
It
wouldn't
have
made
sense
to
redo
everything,
but
it
also
hadn't
been
two
to
three
years,
and
I
at
this
point
we
either
we
either
go
with
this
with
the
word
withdrawn
or
we
change
the
word
withdrawn.
D
So
that
depends
upon
how
we
want
to
define
withdrawn
here
again.
So
if
we,
if
we
are
explicitly
mentioning
it,
that
it
is
something
that
has
to
be
done
by
author
only
and
bots
and
editor
cannot
do
it,
then
I
don't
think
withdrawn
is
the
suitable
word
here.
We
might
want
to
look
something
else,
and
my
recommendation
would
not
be
going
with
abundant
here
because
abundant-
and
you
know,
because
we
have
a
context
of
that
with
the
present
eip1.
D
B
So
us
using
the
term
just
correctly,
I
don't
see
a
problem
and
and
the
that
technically,
the
old
version
of
abandon
is
now
stag
is
is
what
is
considered
stagnant,
it's
just
stuff
that
I
don't
think
that
I
don't
think
will
cause
any
any
issue
of
confusion.
It's
just
better
language
to
be
accurate
about
it.
C
I
feel
strongly
about
that.
There
should
be
an
algorithmic
mechanism
for
moving
something
to
finally
dead.
I
feel
weakly
about
naming
that
thing
abandoned.
A
So,
okay,
so
I
think
I
like
withdrawn
better
because
withdrawn
seems
purposeful,
whereas
abandon
so
wait
withdrawn
seems
more
algorithmic
abandon
seems
less
algorithmic
in
my
mind,
when
I
just
like
look
at
the
words.
Yes,
I
could.
H
A
Really
yeah.
C
H
A
B
C
B
A
Now,
let's
do
renaming
next
meeting
after
more
discussion,
but
make
sure
we
point
that
out
in
the
eip,
whatever
comes
of
it
so
whatever
so
we
have
the
eip
going
in
that
james
and
puja
is
doing,
and
then
the
next
eip
that
we
put
in
that
changes
the
status
that
gives
the
reason
field.
That's
when
we
would
rename
it
is
that
is
that
accurate.
A
C
A
C
C
I
would
just
like
to
someone
to
say
what
we
just
agreed
to
just
to
make
sure
I
didn't
miss
something
I
think
I
get
it,
but
I
want
to
make
sure
we're
on
the
same
page.
I
can
say
it
if
what
I
think
is
the
case.
I
believe
we
all
agree
that
withdrawn
will
have
a
reason,
field
right,
yep
and.
E
C
B
C
B
B
C
A
A
A
I
have
a
question
about
it,
someone
mentioned
and
some
pr
that
I'm
forgetting,
because
I
looked
at
way
too
many
yesterday
that
there
was
a
little
bit
of,
or
maybe
it
was
just
a
discussion
in
general,
but
I
had
with
someone
where
they
said
on
the
network
upgrade
process.
A
A
A
It
pointed
to
different
repositories
that
had
the
specifications
in
them
so
because
it
did
that
there
was
a
little
bit
of
confusion
if
it
should
be
an
informational
eip
or
not,
and
one
of
the
arguments
said
well
whenever
they
merge
or
whenever
eth1
goes
into
a
shard
of
eth2
or
an
execution
environment
or,
however,
they
end
up
doing
it
right
now.
I
think
the
plan
is
to
have
it
via
its
own
shard.
When
that
happens,
will
that
require
an
eip
or
will
that
be
something
that
happens
and
then
subsequent
changes
would
require
an
eip?
A
B
C
I
don't
know
if
these
two
thing
team
agrees
with
that.
Necessarily
that
at
least
danny,
when
I
was
talking
to
him
and
discord,
seemed
to
think
that
he
believes
that
it
will
be
possible
to
keep
the
two
pretty
separate
where
each
one
lives
entirely
encapsulated
like
in
a
sandbox
inside
effectively.
A
B
No
and
that
that
is
something
we'll
have
to
sit
down
with
danny
and
the
e2
team
and
figure
out.
I
see
them
as
as
it
is
just
right.
I
see
it
as
working
out,
I
guess,
but
I
don't
see
how
it
works
out.
Yet.
A
And
I
know
greg
has
publicly
been
a
little
bit
on
the
fence.
It
seems
like
or
against
some
of
the
merging
this
early
in
the
game,
which
I
can
understand
and
somewhat
agree
with,
but
because
it
might
need
to
happen,
it
just
depends.
Does
it
happen
once
it's
actually
implemented
and
on
chain,
or
does
it
happen
after
right
before
then
it's
kind
of
a
timing
issue
more
or
less?
B
Yeah
and
where
the
intersection
of,
if
it's
something
that's
going
on
to
the
eth1
chain
and
having
it
go
through
an
eip
and
e
and
eth
1.0
specs,
makes
sense.
C
C
That's
to
do
that,
and
so
I
feel
like
for
eventually
when
we
do
want.
You
know
either
one
needs
to
to
combine
in
some
way.
I
think
it's
perfectly
reasonable.
In
my
opinion,
to
say
you
know,
eaps
are
a
great
tool,
but
it's
a
tool
that
doesn't
make
sense
in
this
case,
and
so
it's
okay
for
the
eth1
1.0
specs
repo
to
point
at
the
e2
specs
repo.
Instead
of
pointing
an
eip
like
it
normally
would.
A
I
I
like
that,
with
the
caveat
that
after
eth2
launches
I'm
on
my
current
position
without
thinking
about
it
for
more
than
a
couple
days,
is
that
once
eth2
launches
phase
zero,
any
changes
to
phase
zero
tweaks
or
anything
that
would
be
eip
sized
can
go
in
the
eip's
repo
sort
of
like
how
we
have
the
yellow
paper
that
launched
ethereum
and
the
eip
was
used.
A
repo
was
used
later.
B
D
B
B
So
it'd
be
fine
that
that's
also
be
fine
either
way
and-
and
I
don't
think
that
and
that
that
works
well
with
what
micah
was
saying.
Is
there
still
is
this
big
umbrella
of
eth2
that
doesn't
need
to
be
specified,
but
if
you're
changing
the
beacon
chain
or
if
you're,
changing
the
deposit
contract
on
each
one,
then
going
through
an
eip
to
make
that
change
makes
sense.
C
Yeah
totally
it's
just
for
that
initial.
I
think
the
yellow
paper
example
is
another
great
example.
Where
we
had,
we
did
not
do
eips
for
every
single
change
from
nothing
like
technically.
We
started
at
zero
right
and
then
we
iterated
to
a
yellow
paper,
but
we
didn't
do
like
a
million
little
eips.
We
just
had
a
single
yellow
paper,
so
yes,
that
works
for
me
perfectly.
A
So
I
think
he'll
be
fine
with
that,
and
we
have
one
more
minute
left.
Was
there
anything
that
anyone
wanted
to
get
to
in
the
last
minute
that
we?
That
would
be
like
a
stopper
for
them
pursuing
something
in
the
next
two
weeks.
A
That
should
have
been
that
should
have
been
taken
off
because
it
turns
out.
We
can't
unless
we
update
the
oh,
you
know
what
I
did
say.
I
was
going
to
ask
the
devops
team,
but
I
and
I
didn't
yet,
but
I'm
like
pretty
like
80
sure
they're
going
to
say
it's
cost
prohibitive
to
do
that,
and
the
reason
for
that
is
the
to
change
the
type
of
github
purchasing
structure
or
like.
What's
it
called
to
change
the
type
of
organization
structure
from
every
private
repo
you
pay
for
to
every
user.
B
A
Comfortable
because
really
an
eip
editor
is
a
is
a
status,
it's
not
a
technical
permission
set.
It
is
right
now,
but
it
doesn't
have
to
be
so.
I
can
make
people
in
the
repo
have
right
permissions
as
long
as
they
know
the
scope
of
what
they
can
do
and
it's
slightly
monitored,
so
they
don't
merge
anything.
They
just
do
labels
kind
of
a
thing,
and
I
mean
I
think
we
trust
like
client
to
do
that.
I
would
just
be
needed
to
talk
about
what
the
other
editors
kind
of
a
thing.
A
C
A
Okay,
can
you
message
me
just
a
quick?
I
haven't
done
that
in
a
while.
If
you
could
just
message
me
like
a
couple
sentences
of
your
process,
is
it
pretty
much
just
going
through
and
a
new
one
comes
in
and
you
comment
on
it,
or
only
when
we're
called.
C
A
A
A
Okay,
the
next
meeting
is
october
7th.
I
thought
this
was
a
really
good
meeting
thanks
everyone
for
your
comments
and
especially
thanks
to
puja
for
the
all
the
diagrams
and
the
and
the
presentation.
That
was
very
helpful.
Otherwise
we
would
have
been
just
talking
with
words
and
that's
not
good
for
this
type
of
thing.
Yes,.