►
From YouTube: EIPIP meeting 38
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/79
A
Welcome
to
eipab
meeting
38
agenda
shared
in
the
chat.
The
first
item
on
the
agenda
is
evolving
eip
process.
I
have
added
it
considering
we
discussed
like
in
bits
and
pieces
in
past
meetings.
So
now
we
have
a
consensus
specification.
I
think
some
work
are
being
put
in
by
the
quilt
team
and
with
respect
to
much
do
we
see
any
any
changes
in
the
core
eap
process
in
general,
so
just
wanted
to
bring
it
up.
B
A
In
my
opinion,
yes,
first,
the
this
item,
like
corey
id
processor,
will
be
changed,
so
that
is
something
we
can
use.
Okay,.
C
I
guess
maybe
a
way
to
make
this
very
concrete.
Do
we
think
that
the
eth
one
spec
will
be
ready
for
us
to
use
it
like
as
the
merge
spec?
So
mikal
has
an
eip
out
right
now
like
do
we
think
yeah?
That's
what
like
basically
are
we
gonna
start
using
the
consensus
spec
after
the
merge,
or
do
we
think
we
can
actually
use
that
the
specter
merge
and
possibly
move
over
mikael's
eep
as
part
of
that
or
you
know,
alongside
that,
yeah.
D
D
C
Got
it
and
one
one
option
is
also
say
we
get
to
like
the
merge
test
nets
with
the
eip.
You
know
we
can
then
almost
like
backfill
it
into
the
spec
right.
So
maybe
it's
not.
Maybe
it's
not
what
we
use
to
implement
the
merge,
but
maybe
it's
kind
of
ready
by
the
time
the
merge
hits
maintenance
where
there
might
be,
like
several
months
lag.
C
A
Spec
all
right,
so,
if
I
understand
correct
we,
we
may
be
expecting
some
changes
in
the
process
in
terms
of
like
we
may
not
be
going
by
the
eip
process
in
general,
like
not
for
the
entire
set
of
the
proposal.
Just
for
this
pack
part
we
can
manage
it
with
the
help
of
pull
request
and
rest
of
the
details
can
be
added
to
the
eip.
Just
like
we
have
36.75.
C
Yeah-
and
we
should
keep
assuming
3675-
is
what
we're
gonna
use
like
and
share
the
clients
and
iterate
on
over
the
next
couple
of
months.
A
Oh,
that's
great
all
right
all
right!
That's
about
core
eip!
I'm
not
sure
if
we
have
any
more
clarity
at
this
point
of
time
yeah
if
anyone
would
like
to
add
anything.
Otherwise
we
can
move
on
to
the
interface.
A
One
okay,
similar
to
core
eib-
I
know
there
are
some
work
are
even
being
put
in
for
the
interface
eip.
We
did
discuss
yesterday
with
within
the
meeting
that
eip
editors
training
meeting
in
general.
How
do
we
see
interface
vip
in
future
right
right
now?
I
see
quite
a
lot
eip,
which
are
in
draft
status
and
review.
A
A
With
that
means,
whatever
is
interact
and
review,
they
did
not
need
to
move
forward
and
we
can
just
move
them
to
withdrawn
status
or
just
leave
it
as
it
is.
I
don't
know.
A
Yeah,
that's
what
I'm
wondering
like
if
these
proposals,
if
we
are
assuming
that
they
they're
not
supposed
to
move
forward
to
any
further
status,
let's
move
it
to
withdrawn
and
we'll
make
a
statement
like
we
have
other
banners
for
different
proposals.
We
can
have
a
banner
for
this
particular
category
written
here
that
these
proposals
are
not
supposed
to
move
any
further
and
we
can
be
using
the
specs
repository
for
any
anymore
interface.
Eaps
that
make
sense
sure.
C
A
Yeah,
okay.
In
that
case,
I
will
create
an
issue
to
look
for
someone
who
can
at
least
first.
The
first
thing
first
create
a
banner
that
we
are
not
moving
the
status
of
interface
eips
and
we
should
be
using
the
spec
repository
for
any
further
eips
in
this
category
and
then
eventually
I'll,
try
to
reach
out
to
different
authors
and
create
pull
requests
to
move
these
proposals
into
withdrawn
status.
C
Yeah,
there's
a
bunch
of
weird
things:
there's
like
stratum,
renaming
up
codes
like
I
don't
know
what
wallet
permission
system
is
yeah.
B
So,
like
there's
a
subset,
it's
json,
rpc
stuff
that
can
be
removed
or
marked
as
abandoned
or
withdrawn,
or
stagnant
or
whatever,
but
there
will
still
be
an
interface
category
and
there
will
still
be
eips
in
it,
which
means
we
can't
just
blanket
put
a
banner
on.
I
don't
think
or
if
we
do.
We
need
to
make
sure
it's
very
clear
that
the
banner
only
applies
to
json
rpc,
which
is.
C
A
Okay,
in
that
case,
it
looks
like
first,
we
need
to
like
separate
the
eips
which
are
non-json,
rpc,
eips,
and
then
the
withdrawn
stage
status
could
be
applied
for
only
those
are
json,
rpc,
specific
eips
and
for
rest
of
it.
We
can
just
have
a
banner
that
no
more
json
rpc
eaps
are
like
can
be
found
here
or
unusable
here
that
has
to
be
used
with
the
specs
depository
and
for
rest
of
the
interface
eips.
This
is
good
to
go.
A
I'm
not
very
sure,
like
how
I
mean
I
am
a
particular
I'm,
not
sure
that
I
would
be
able
to
differentiate
all
of
them.
Maybe
I
have
to
reach
out
to
or
if
anyone
here
in
the
group
knows
so
I
can
share
a
list
and
we
can
add
it.
A
A
A
A
All
right
moving
on
to
the
networking
eids,
so
I
talk
few
authors
and
have
created
respective
pull
requests
to
move
these
proposals
into
the
right
status.
I
think
there
are
only
a
few
left
in
the
review
status
and
draft
86
have
created
a
good
request
today
to
move
it
to
the
last
call.
A
A
The
eip
is
in
draft.
I
am
not
sure
I
left
some
comments
for
peter
we'll
wait
for
his
response.
If
not
it,
I
think
it
can
be
superseded,
because
we
are
moving
ahead
with
each
66..
A
Does
it
make
sense
to
move
it
with?
I
like
the
superseded
with
66.
B
No,
for
two
reasons:
one
I
think
we
dropped
superseded
because
it's
too
opinionated
and
two
I
believe
e66
actually
depends
on
e65
and
so
technically
let
me
verify
that
I'm
pretty
sure
yeah
e66
depend
it
requires
865
e65
requires
864..
So
technically
we
shouldn't
even
have
moved
66
to
last
call
or
to
review,
because
65
and
64
are
still
draft
like
those
ones
should
be
moved,
at
least
at
the
same
time,
if
not
first
does
66.
A
Okay,
so
what
I
can
do
is
like
I
can
create
full
request
to
move
it
to
review
status
for
64
and
65,
and
maybe
then
like
ask
the
author
to
approve
it,
and
we,
I
already
have
created
requests
for
66
to
move
to
last
call.
We
have
14
days
we'll
try
to
sort
this
issue
within
this
period
of
time
before
moving
it
into
the
final
status
and
that
about
1459
they
know
discovery
by
dns.
A
A
And
about
the
last
category
years,
erc,
a
few
months
back,
we
decided
to
leave
as
it
is
and
revisit
after
a
few
months
to
see
if
this
needs
a
process.
Change
just
wanted
to
have
a
quick
check
with
the
group
like
do
we
still
feel
that
the
way
it
is
moving
is
fine?
We
can
just
use
it
use
the
github
labels
to
address
erc's
or
the
process
that
we
discussed
earlier.
Should
we
try
implementing
it.
A
So
you
know
earlier
we
discussed
that
we
will
be
waiting
for
some
more
time
to
see
how
poor
eips
move
ahead.
If
we
are
moving
into
like
completely
the
quarry
it
is
out
of
the
eip
repository,
then
we
may
not
be
moving
erc's
but,
as
it
looks
like,
we
will
still
have
four
eips
in
the
github
repository
as
it
is
just
a
part
of
it
is
taken
out
of
the
github
repository
a
github
eip
repository.
A
So
I
think
the
changes
that
we
discussed
earlier
for
erc's
makes
sense,
especially
in
terms
of
taking
their
numbers
and
the
process
like
having
a
separate
repo
and
process
to
be
followed
similar
to
eip
but
managed
separately.
B
If
we
think
that
we
will
see
a
switch
over
to
the
f1
specs,
like
the
python
specification
like
within
the
next
12
months,
then
I
can
probably
be
swayed
to
give
up
on
getting
erc's
out,
because
when
that
happens,
I
will
just
stop
paying
attention
to
the
ips
repository.
B
D
B
A
Okay
in
the
meanwhile,
I'm
just
wondering
like
I
know
now
that
we
are
having
this
meeting
of
eips
and
editors
and
training,
so
we
are
trying
to
cover
more
and
more
eips
as
well
as
erc's.
I
mean
review,
at
least
I
don't
know
if
we
can
add
triaging
permission
to
more
of
the
reviewers
with
that
help.
C
We
don't
pay
for
github
enterprise
and
you
need
github
enterprise
for
that.
C
E
E
B
I'm
guessing
cat
herders
is
on
just
like
the
traditional
public
repo,
whereas
the
ethereum
organization,
I
think,
is
on
like
one
of
the
older.
Oh.
C
Well,
I
think
the
thing
is
we
are
maybe
not
an
enterprise
but
like
probably
like
a
paid
plan.
We're
probably
like
in
this
like
weird
middle
we're
like
we
are
like
an
organization
but
not
an
enterprise,
because,
like
yeah,
I
I
anyways,
I
yeah,
I
okay,
there's
like
a
team
plan,
so
I
wouldn't
be
surprised
if,
like
we
were
on
the
team
plan,
so
we
get
like
the
worst
of
both
worlds.
B
A
Okay
notice,
then,
in
that
case
yeah,
I
was
just
wondering,
because
I
found
that
lightline
added
to
some
full
request
that
it
is
an
erc
and
it
was
really
easy
to
sort
it
out.
So
I
was
wondering
if
I
can
also
contribute
or
other
people
who
are
trying
to
understand
the
eap
editing
part,
maybe
just
because
this
is
the
primary
thing.
We
can
do
it
without
too
much
of
effort,
but
no
worries.
A
Okay,
so
that
sums
up
the
evolving
eip
process
agenda
item
listed
here
on
eip's
site,
rendering
issues.
I
think
this
was
discovered
in
the
eap
3675
michael
also
left
some
comment.
I
left
the
first
comment
because
when
I
was
trying
to
read
out
the
file
that
was
giving
me
a
404
error,
so
I
suggested
to
move
out
the
anchor
part,
but
it
seems
like
there
was
some
rendering
issue,
not
sure
if
it
has
been
solved
or
someone
needs
to
look
into
it.
A
There
are.
The
next
item
is
eip.
Bot
alita
mentioned
in
the
comment
that
she
may
not
be
able
to
attend
the
meeting
today,
but
she
left
some
updates
on
work
she
has
been
putting
in
for
eip
bought.
A
A
few
issues
I
have
highlighted
earlier
was
a
proper
representation
of
eip
that
eip
dash.
Whatever
the
number
is,
I
think
that
would
be
a
good
practice
to
let
people
know
that
whenever
we
are
referring
to
eip.
That
is
something
that
we
need
to
do
and
my
assumption
is.
It
is
fixed
because
for
another
pull
request,
I
I
got
it
in
a
better
format,
so
we
considered
it
done,
I'm
not
too
sure
about
the
the
next
item.
A
If
a
user
get
a
specific
message
about
why
a
pull
request
failed
checks,
because
if
I
look
into
the
list
of
pull
requests
right
now,
most
of
them
are
red
cross.
That
means
they
are
failing
vote
check
at
some
point,
but
I'm
not
sure.
If
I'm
receiving
specific
message
what
is
failed,
I
mean
why
is
it
failed
and
how
I
can
fix
it
to
get
the
green
check.
B
A
B
The
current
bot,
you
cannot
green
check
it
like
it's.
The
green
green
check
means
your
merge.
Basically,
if
you
hover
over
the
check
mark,
it
will
say
like
two
of
four
or
three
or
four
or
one
of
four
or
four
or
five,
something
like
that
right
in
theory,
you
can
get
something
some
information
out
of
that
or
if
you
click
on
one
and
then
scroll
to
the
bottom
of
the
pull
request,
you
can
see
which
checks
are
failing,
which
ones
are
passing
if
the
failing
check
is
travis
ci.
B
A
That
makes
sense,
but
it
it
is
not
able
to
pinpoint
what
is
wrong
like
when
I
was
into
such
a
situation.
I
took
help
of
you
and
like,
and
you
guys
pointed
me
that
I
should
add
a
dash
between
eip
and
the
eap
number
and
I
got
a
green
check,
but
that
was
with
the
earlier
bar
and
I
don't
know
I
mean:
is
there
a
way
that.
B
Yeah,
so
yes,
right
now,
it
is
definitely
not
easy
for
end
users
to
understand
what
the
problem
is.
Usually
as
editors,
we
look
look
and
see
what
the
problem
is
and
then
tell
them
in
a
comment.
It
would
be
great
if
the
bot
could
comment
on
the
on
the
ipsl
for
on
the
pull
request
itself.
Saying:
hey
you
need
to
fix
this
thing,
even
better
would
be
if
it
offered
suggestions
on
how
to
fix
it.
Like
for
the
spelling
errors,
the
bot
could
just
offer
like
a
inline
suggestion,
but
all
this
requires
engineering
effort.
B
It's
a
reasonably
sized
task,
depending
on
how
good
you
want
to
make
it
especially
getting
the
travis
stuff
out,
because
it
requires
some
like
integration,
the
other
direction
which
is
complicated.
So
it's
not
a
small
task.
A
Got
it
okay,
so
we'll
consider
this
in
that
task
list,
but
we'll
have
we'll
have
to
alita
to
also
give
her
some
feedback
on
this,
how
long
or
like
if
she
would
like
to
have
more
people,
engage
working
on
this
or
whatever
we'll
talk
to
her.
Also,
the
next
item
is
metrics.
A
I
mean
the
sub
item
is
metrics,
I'm
wondering
if
there
is
a
way
to
get
collect
the
metrics
of
how
many
proposals
are
like
being
proposed,
if
not
new
proposals,
let
it
be
full
requests
or
issues
coming
up
every
month
or
every
week,
and
how
many
gets
the
reviews
comments
and
how
many
gets
closed
or
any
kind
of
metrics?
Is
it
possible
to
collect
data
with
the
help
of
github,
or
maybe
we
can
design
a
part
with
that.
B
A
Yeah,
I
I
see
that
too,
but
these
are
just
yes,
as
you
mentioned,
it's
very
very
high
level
like
multiple
requests
or
people
request,
something
like
that.
Okay,
then
maybe
first,
we
need
to
determine
what
kind
of
metrics
could
be
helpful
to
understand
like
how
we,
when
we
are
getting
the
request
from
community
and
then
to
see
if
this
is
helpful
and
if
not
then
maybe
look
into
the
part
well,
because
yeah,
please
go
ahead.
A
Yeah,
that
is
surprising
because
I
know
like
you
and
lifeline
keep
on
commenting
on
most
of
all
of
the
pull
requests,
not
sure
of
the
issues.
But
but
yes,.
A
Moving
on
the
next
item
is
eip
erc
editors
in
training,
progress
meeting,
so
we
had
this
meeting
yesterday
and
we
covered,
I
think,
the
five
five
over
five
proposals
so
reviewed
and
they
left
comment
there.
Thank
you
likeline
for
conducting
these
sessions.
A
James
hancock
also
joined
us
yesterday,
so
we
now
are
getting
more
and
more
people
involved
learning
the
process,
and
I
hope
that,
with
with
this
rate,
if
we
keep
on
working,
we
would
be
in
a
position
to
decrease
the
number
of
at
least
pulled
requests
first
under
10
and
then
we'll
start
considering
the
issues
section.
A
Okay,
the
next
item
is
json
rpc
api
spec
progress.
I
think
alita
left
her
update
on
the
comment
that
we
are
nearly
done:
collecting
the
necessary
data
to
write
edge
cases
and
are
well
into
finalized
track
to
begin
the
client
review
process.
The
open,
rpc
spec
needs
another
review
from
my
client
so
lifeline.
If
you
might
want
to
look
into
the
open,
rpc
specs
and
she
mentioned
about
a
blocker.
A
I
don't
know
if,
if
someone
from
here
from
the
group
can
help
it's
about
finalizing
the
format
for
the
edge
cases
in
the
open,
rpc
spec,
this
requires
that
we
first
merge
in
previously
discussed
open
rpc.
Second,
and
then
I
will
open
another
discussion
on
this
point.
A
Unfortunately,
I
do
not
see
too
much
on
the
call,
but
yeah
anyone
likely
and
micah.
If
you
guys
have
any
thoughts
or
suggestions
on
it.
B
I
think
we
agreed
previously
to
just
move
forward
with
everything,
except
for
that
and
then
internally
they
can
use
whatever
format
they
want
and
then
before
we
like
publish
it,
we
will
have
a
discussion
and
try
to
figure
out
what
the
best
format
for
that
is.
The
impression
I
got
was
that
no
one's
really
in
a
rush,
though,
to
solve
that
problem.
A
All
right,
I
I'll
ask
elita
to
follow
the
recording
and
then
maybe
she
can
look
into
it.
Maybe
in
the
channel
that
the
discord
channel
that
is
created
to
discuss
this
open,
rpc.
F
F
So
I
haven't
got
anything
to
show
yet,
but
so
I'm
hoping
to
be
able
to
understand
that
system
and
be
able
to
make
changes
and
then
be
able
to
propose
changes
and
show
people
prototypes
and
stuff
like
that,
but
I'm
still
still
working
on
it
and
so
hopefully,
in
the
future,
I'll
I'll
be
able
to
easily
contribute
and
help
a
lot
of
the
some
of
the
stuff
that
we'd
like
to
help
make
on
that
system.
So
still
just
learning
the
system.
A
A
The
sub
item
is
eap
draft
banner,
a
shout
out
to
felt
a
discord
user
who
took
up
this
issue
and
have
submitted
the
pull
request,
which
is
actually
merged
right
now,
and
we
have
this
banner
available
on
eips.ethereum.org
about
every
proposal
like
what
is
the
current
status
of
the
proposal
and
what
is
the
expectation
with
it
like
if
there
is
any
change
expected
or
people
or
it
is
ready
for
people
to
use
it.
So
thank
you
so
much
for
submitting
the
request
for
that.
A
The
another
sub
item
is
bought
tracking
inactivity
period
and
changing
the
state
of
the
proposal
that
is
still
open.
Alita
mentioned
in
the
ethereum
meeting
that
she
would
be
looking
into
this
issue
and
we'll
try
to
get
it
done
this
month.
A
So
I'll
wait
for
her
response
to
finish
it
up,
but
there
is
this
one
thing
that
I
found
on
a
bot's
comment.
A
A
I
don't
know
I
saw
somewhere.
It
is
two
months
or
something
like
that.
So
does
anyone
remember
what
was
the
decided
period
there.