►
From YouTube: EIPIP Meeting 52
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/116
A
Welcome
to
eipip
meeting
52.,
I
have
shared
agenda
in
chat.
The
first
item
listed
here
is
github
discussion
for
discussion
2..
I
have
added
a
link
which
I
collected
from
the
eip
github
issue.
A
It
is
a
proposal
to
initiate
eip
discussion
to
thread
at
github
discussions,
as
you
can
see,
micah
already
pointed
out
the
potential
problem
with
github
discussions
that
they
are
not
distributed
and
cannot
be
reconstituted.
A
However,
I
feel
like
the
in
earlier
meetings,
we
decided
to
move
ahead
with
ethereum
magician.
One
of
the
issue
that,
and
that
was
highlighted-
was
the
limited
editing
window,
but
I'm
happy
to
share
that.
A
This
issue
is
now
resolved
and
I'm
just
trying
to
understand
now
like
are
we
good
with
fem
continued
as
discussion
took
place
and
we
don't
want
to
look
into
other
options
or
are
there
any
other
issues
that
needs
to
be
taken
care
of
before
we
start
increasing
awareness
of
fem
as
a
central
place
for
discussion
to
link.
B
I
don't
believe,
there's
anything
else
blocking
us
that
was
the
the
big
blocker
that
I
remember.
I
have
already
basically
told
everybody.
You
have
to
go,
create
an
ethereum
magician's
threat
for
discussion
links
like
anyone
who
creates
an
issue
on
our
github.
If
it's
not
related
to
the
ap
process
itself,
I
tell
them
to
go
to
your
magicians
and
I
close
the
issue.
C
A
Right,
I
know
we
have
changed
some
text
on
the
github
bot
to
help
people
understand
that
if
this
is
related
to
eip
discussion,
please
stop
it
across
it
and
create
a
threat,
but
we
were
trying
to
stop
ourselves
from
strongly
recommending
it,
but
it
seems
like
with
this
issue
being
solved.
We
can
start
doing
that.
A
A
Number
two
is
removing
spam
issues
and
comments.
This
is
collected
from
the
eat.
Rnd
discord.
We
all
know
that
we
have
the
eip.
Github
repository
is
being
spammed
a
lot.
People
come
and
write,
something
that
has
already
been
discussed
in
the
past
that
this
is
a
concern
that
we
don't
want
to
provide
an
opportunity
to
scammers
to
just
create
something
and
be
a
part
of
ethereum
repository.
A
So
we
did
talk
to
ef
devops
team,
and
it
seems
like
with
editors,
eip
editors,
having
admin
issues.
Now
they
are
in
a
position
to
close
the
spam
issues.
It's
just
that
we
might
need
to
update
the
list
of
eip
editors,
so
all
the
ap
editors
may
be
able
to
handle
this
thing.
B
Don't
think
that's
necessary.
I
think
that
I
just
didn't
know
where
the
delete
button
was.
I
I've
been
using
github
for
forever
and
I
never
even
saw
that
button
now
that
I
know
where
it's
at
I
can
delete
issues,
and
so
I
don't
think
it's
a
problem
anymore.
I
think
having
me
and
my
clients
are
both
admins
generally.
B
I
am
in
the
camp
that
from
a
security
standpoint,
I'm
in
the
camp
of
people
that
believes
that
you
should
limit
who
has
access,
and
so,
if
we
are
going
to
add
people,
I
would
recommend
removing
some
people
as
well.
I'm
okay
with
that.
If
someone
wants
to
remove
me
and
add
someone
else,
I'd
be
totally
happy,
but
I
don't
think
we
should
just
add
everybody
like.
I
think
it's
on
unnecessary
distribution
of
very
powerful
permissions.
B
A
All
right,
so
I
I
think
we
can
probably
check
with
that.
It
seems
that
list
is
pretty
old
and
it
has
access
to
the
like
emergency
eip
editors
as
well,
so
we
will
try
to
get
the
list
shorter,
with
whoever
has
have
admin
access,
as
of
now,
for
that
repository
should
be
the
owner
of
it
and
yeah.
That
way,
we
hope
to
spam
issue
get
addressed.
A
All
right,
moving
on
number
three
is
discuss
issue
used
to
get
sub
modules.
I
think
this
is
also
collected
from
the
eip
github
issue
section
and
also
the
user,
the
github
user
panda
pip1.
A
A
I
have
I
added
the
link
in
the
agenda,
so
it
says
that
currently
travis
ci
validates
all
files,
including
get
some
modules
which
the
eip
author
has
no
control.
Over
fixing
the
kit
modules
file
will
be
edited
every
time.
Someone
added
a
get
some
module.
The
bar
should
not
fail
when
this
file
is
changed.
A
B
I'll
just
reiterate
my
my
position:
I'm
not
a
fan
of
guess
that
modules
in
the
eip
repository,
they
add
a
lot
of
complexity
and
it
introduces
external
links,
and
so
it's
functionally
the
same
as
just
external
linking
which
means
it
can
404.
It
can
go
away.
All
the
problems
we
have
with
external
links
would
also
also
help
get
sub
modules.
B
They
just
it
adds
a
lot
of
complexity
to
the
repo
like
when
you
clone.
You
have
to
do
a
bunch
more
steps
in
order
to
get
some
modules,
not
a
huge
deal.
I
think
in
our
case,
because
most
people
probably
wouldn't
need
sub-modules
for
day-to-day
tasks,
but
we
would
have
to
make
ci
accept
them
and
deal
with
them
et
cetera.
So
I'm
generally
against
modules.
C
Yeah,
I
I'd
agree.
I
think
I
think
they're
slightly
better
than
just
arbitrary
external
links,
but
they
definitely
suffer
from
some
of
the
same
problems.
Then
you
know
I'm
okay
with
like
a
soft
stance
against
them
for
now,
and
then
you
know
if
it
comes
up
down
the
road
or
or
comes
back
up
as
another
like
recurring
issue,
then
we
can
discuss
it
again
later.
A
All
right,
so
I
see
micah,
has
already
commented
here
on
this
issue.
Maybe
we
can
go
ahead
and
add,
as
a
general
consensus
for
this
meeting,
that
eap
editors
are
not
generally
in
favor
of
this,
so
we
can
probably
close
this
issue
for
now,
but
if
then
something
else
comes
up,
we
need
to
bring
it
back.
Maybe
we
can
create
another
issue
and
start
discussing
it
at
that
point.
B
A
Oh
well,
that's
why
I
have
been
trying
to
kind
of
readjust
that
time,
so
it
suits
rest
of
the
eip
editors
like
we
have
five
on
board.
I
believe
right
now,
one
two
three
four
five.
Yes.
A
And
I
was
trying
to
reach
all
of
the
ap
editors
individually,
so
we
can
get
a
time
good
time
for
everyone
to
be
on
the
call
we'll
discuss
that
that
is
there
on
the
agenda
maybe
later
today.
Let's,
let's
finish
up
with
whatever
is
here.
First
number
four
is
mention
number
of
eip
drafts
that
were
submitted
but
not
merged
in
the
eip
inside.
So
this
is
again
a
common
by
the
same
user,
and
he
is
requesting
that
in
the
report
that
we
published
eip
inside,
we
should
also
add
a
hole
request.
A
Those
are
not
merged.
Generally.
How
I
add
details
over
there
that,
whatever
pull
request
is
merged
is
reflected
in
what
category
it
is
what
status?
It
is
sorry,
I
wasn't
adding
the
eip
category
and
type,
but
it's
a
good
suggestion
that
we
probably
add
type,
so
we
will
be
able
to
keep
track
of
how
many
of
what
a
core
networking
and
other
eaps
are
being
added
and
being
finalized,
but
I'm
I'm
still
into
minds.
That's
why
I
wanted
to
bring
it
here
like.
C
As
long
as
it's
not
too
owners
to
collect,
I
don't
see
it
as
a
bad
thing.
I
mean
it's
kind
of
a
an
indicator
of
how
much
work
eip
editors
are
of
doing
well.
Yeah.
It's
like
you,
can
kind
of
compare
the
ratio
of
things
that
were
merged
versus,
not
merged
and
then
be
like.
You
guys
are
doing.
You
know
a
terrible
job
as
the
ip.
B
Yeah,
I
tend
to
agree
that
if
this
is
an
easy
thing
to
get
metrics
on
and
someone
has
requested
it,
then
I
see
no
downside
to
providing
it.
It
might
give
insight
into
how
overwhelmed
we
are,
or
maybe
it
will
give
people
data
to
say,
wait.
You
guys
aren't
actually
overwhelmed.
You
keep
up
with
everything.
Clearly
you
can
handle
more
work.
I
don't
know,
but
I
I'm
not
opposed
to
it
being
added.
If
it's
easy,
if
it's
really
hard
to
get
that
data,
then
I'm
more
opposed
to
it.
Just
because
I
don't
want
to.
B
A
A
If
we
see
that
the
present
eip
editors
are
overwhelmed
with
the
job
that
is
assigned
here
all
right,
I
will
try
to
add
the
data
for
open
pull
request
for
new
proposals
and
proposals
which
are
added
to
be
moved
to
the
final
status
and
we'll
try
to
add
this
data
at
the
end
of
the
month.
A
Okay,
moving
on
number
five,
I
item
number
five
is
core
eips
in
an
executable
spec
world.
I
know
this
proposal
was
proposed
by
timbeku
and
was
also
discussed
in
the
all
code
meeting.
Now
that
we
already
have
the
discussion
to
link
for
this
proposal.
I
don't
know
this
is
a
formal
eip
or
not
discussion.
Two
link
is
also
available
at
fellowship
of
ethereum
magician,
and
I
have
added
the
link
to
the
agenda
for
people
to
refer
to.
B
I'm
still
holding
out
hope,
though,
I'm
losing
I'm
pretty
sure
I'm
losing
the
fight
I'm
gonna
hold.
You
now
hope
that,
with
the
executable
spec,
we
can
just
move
four
eaps
out
of
the
ap
process
and
into
some
new
process.
That
is
more
fitting
for
what
core
devs
need,
but
I'm
pretty
sure
I'm
gonna
lose
that
so
why?
Why
do
you
say?
You're
gonna
lose
that.
C
B
Are
some
some
reasonable
arguments
for
that,
such
as
continuity,
and
you
know
mental
effort
for
the
core
devs
things
like
that?
I
personally
think
long
term.
We
would
be
better
off
if
the
core
devs
had
a
a
process
of
their
own,
that
wasn't
also
infected
with
ercs,
and
you
know,
informational
and
everything
else,
and
also
that
was
you
know
once
we
have
a
single
spec,
a
process
that
integrates
with
that
better
than
the
iep
process
would
yeah
just
the
the
impression
I'm
getting
currently.
C
Well,
I
mean,
hopefully,
we
can
convince
people
that
there's
a
better
process
kind
of
hoping
that
that's
what
we'll
do
with
shanghai
when
we
get
there
but
yeah.
B
C
Sure
so
I
was
actually
helping
tim
quite
a
bit
with
his,
but
I
guess
there's
still
some
parts
that
yeah
I'll
go
through
this
and
I'll
write
up
like
an
alternative
one.
So.
D
A
Yeah,
I
think
the
idea
of
for
having
this
pack
and
def
that
we
discussed
in
earlier
meetings
it
was
nice
nice
to
have
it-
would
actually
differentiate
core
eip
process
with
the
rest
of
the
eip
processes.
Even
if
we
continue
the
normal
standardization
process
is
the
same.
It's
like
what
we
want
to
keep
it
in
the
in
the
file.
B
Yeah,
like
I
said
my
preference
would
be.
We
don't
keep
any
anything
core
eip
in
the
ip
process.
Once
the
extrudable
spec
is
out.
We
come
up
with
a
new
process
that
is
separate
and
I
feel
like
I
feel
like
we
can
come
up
with
something
better
given
a
green
field
that,
rather
than
trying
to
kind
of
become
something
that
looks
kind
of
like
eaps
and
fits
kind
of
into
the
earpiece
repo.
C
So
what
were
the
problems
you
had
with
tim's
specification
or
or
proposal.
B
I
guess
the
proposal
like
so
the
in
the
high-level
proposal
section
he
says,
use
core
eips
for
both
el
and
cl
changes,
and
my
understanding
is
that
he
basically
wants
to
keep
eaps,
as
is
with
the
exception
of
the
specification
section
changed
and
so
yeah
section
you
still
have.
The
header
of
the
metadata,
et
cetera
still
in
the
ip's
repo,
would
still
be
go
through
the
same
editorial
process,
etc.
B
I
I
feel
like
we
can
do
better
and
I
feel
like
this
is
a
good
opportunity
to
extract
core
eaps
out,
so
they
can
not
live
next
to
ercs
and
other
things,
and
I
feel
like
tighter
integration
with
the
executable
spec
change
control
process
would
be
valuable
rather
than
like.
Okay,
here's
the
ep,
then
we
point
that,
like
a
pull
request
or
something,
but
then
that
pull
request,
you
know,
might
change
over
time
or
you
know
it
may
be
handed
off
or
you
know
someone
who's
a
repository
like
that.
C
Yeah,
okay,
I
think
that's
that's
the
big
difference
I
see
between
what
I
want
and
what
tim
wrote
as
well
is
where
I
want
the
eip,
like
english
text,
to
be
part
of
the
execution
specs
repository
so
yeah
I
can.
I
can
write
that
up.
B
B
Yeah,
so
I
keep
keep
something
like
the
motivation
section.
You
know
the
rationale
did
serve
a
purpose
and
I
think
it
was
valuable,
like
I
think,
that's
a
good
section
to
have,
but
like
maybe
we
don't
need
to
have
the
abstract,
like
lots
of
people
complain
about
having
the
abstract
and
description
and
a
title,
and
maybe
we
just
don't
need
those
three.
You
know
we
just
use
numbers
and
that's
it
like
we
don't
we
don't
need
title
at
all.
I
don't
know.
C
Yeah
I'll
see
what
I
can
do,
I'm
probably
going
to
keep
the
the
template
from
the
eip
repository
mostly
intact,
just
because
I
think,
there's
some
continuity
there
but
yeah.
Let's
see
we'll
see
what
we
can
cut.
B
That
one
bugs
me,
because
it's
totally
redundant,
which
one
the
in
the
header
there's
a
field
for
the
date
that
the
ipo
is
created,
which
is
information
that
is
automatically
tracked
by
like
three
different
systems.
Already,
you
don't
need
to
manually
type
it
in
it.
Just
it
bugs
me,
because
it
serves
no
useful
purpose.
Well,.
B
A
But
about
that
particular,
but
about
that
particular
field
I
feel
like
that
is
the
only
way
to
like
give
a
high
level
information
when
someone
is
looking
at
eips.ethereum.org
right.
That
can
provide
a
reference
of
like
how
long
back
this
eip
was
created.
Obviously
that
feel
is
ambiguous.
B
I
would
like,
if
we
wanted,
to
keep
things
on
ethereum.org
earpiece.theorem.org,
that
I
would
like
to
that
field
just
be
filled
in
automatically
when
the
draft
is
merged,
the
file
creation
date
basically,
and
then
maybe
once
it
goes
final.
We
change
that
to
the
final
date,
because
really
an
eip
is
in
draft
is
not
an
eip.
B
It's
not
a
standard,
yet
it's
not
there
until
it
gets
final,
and
so
the
final
date
is
the
one
that
I
think
matters
the
most
once
you
get
there,
but
again,
like
my
big
convention
with
it,
is
that
we
could
automatically
generate
that
and
we
don't.
We
have
users
type
it
in,
and
that
bugs
me.
A
I
think
it's
a
very
good
suggestion,
like
the
date
for
the
eip,
the
final
date
when
that
proposal
is
actually
most.
Let's
consider
that
as
a
date
of
eip.
Maybe
this
is
something
that
might
need
some
more
discussion,
some
more
feedback
from
other
eip
editors,
but
that's
a
I
mean.
I
consider
it
as
a
good
piece
of
information
for
people
and
we
can
probably
have
some
standardization
over
there.
C
A
All
right,
let
me
let
me
bring
it
to
the
agenda
in
the
next
meeting
and
let's
see
what
other
people
think
about
it,
because
I'm
also
confused
about
this
state.
I'm
talking
personally
from
my
experience,
because
when
I
add
eips
as
like,
you
know,
draft
and
the
final
in
eips
inside
document
that
is
based
on
the
date
when
in
the
month
which
it
was
merged,
but
that
definitely
not
matches
with
the
date
that
is
reflecting
on
the
eips
on
like
eap's
website.
A
A
Okay.
Moving
on,
I
think
we
have
a
good
discussion
on
the
core
eip
part.
We
hope
to
see
something
coming
up
from
sam
wilson,
maybe
in
the
upcoming
meeting
or
the
acd
meeting.
I
don't
know
sam
when
you
are
ready
with
that,
but
it
would
be
good
to
have
a
couple
of
proposals
on
the
table
to
see
what
is
the
best
suited
and
what
people
want.
D
A
Okay,
let's
move
on
to
item
number
six
erp
bot
issues
and
eipv
issues.
I'm
aware
that
some
work
is
is
started
by
the
ech
engineering
team,
though
we
are
still
in
need
of
more
people
in
the
last
ech
meeting.
We
also
shared
the
information
that
we
are
looking
for.
More
ruby
deb,
though
we
haven't,
received
any
application
from
from
the
community.
So
people,
if
you
are
listening,
we
are
still
looking
for
more
people
to
look
into
the
bar
tissues
and
eapv
issues
plus
we
are
also
looking
for
a
ruby
tip.
A
If
you
are
interested
to
work
on
the
eip
side
or
help
out
with
the
ethereum
github,
please
reach
out
to
us,
you
can
find
us
on
the
echat
hardest.
Github,
sorry,
ech,
cathardus,
discard
channel.
A
The
next
one
is
eips
inside,
so
the
report
is
updated
till
till
date.
So
far
in
march,
we
have
one
eip,
which
has
moved
to
the
final
status,
that
is
eap,
4626,
tokenized
vault
standard,
and
the
repository
has
received
seven
new
proposals
as
draft
five
core
proposals
and
two
erc
proposals.
A
I
have
made
this
distinction
for
draft
and
I
will
be
making
this
distinction
for
the
final
eips
as
well.
There
are
13
eips
which
are
moved
to
stagnant,
and
one
eip
that
is
eip.
3651
warm
coinbase
is
resurrected
from
stagnant
to
review
and
is
also
being
considered
for
inclusion
for
the
shanghai
upgrade.
A
A
B
Oh
this
one,
I
think
sam's
comments
or
no
matt's
comment
most
recent
one.
I
generally
agree
with.
B
B
A
All
right,
maybe
if
one
of
the
ap
editors
make
comment
and
then
we
will
be
in
a
position
to
close
the
issue,
so
I
mean
when
the
issue
is
addressed,
we
can
probably
close
the
issue.
A
Okay-
and
I
think
that's
all
from
the
eips
insight
number
eight
is
eip-
editor
apprenticeship
meeting.
We
did
have
this
meeting
yesterday
and
we
did
try
to
catch
up
with
the
some
of
the
open
pull
requests.
The
recording
is
available
now
and
the
next
meeting
is
planned
two
weeks
from
yesterday.
A
Second
last
item
number:
nine
is
eip
ip
meeting
time
and
survey.
So
we
had
this
survey
to
collect
information
from
the
eip
editor.
So
far,
we
have
five
eip
editors
on
board
and
this
survey
was
for
the
collection
of
time
which
would
work
the
best
for
most
of
the
editors.
So
we
can
have
most
of
the
editors
on
the
meeting
and
if
there
is
any
preference
in
the
name
change
for
this
meeting,
it
looks
like
and
1430
utc
is
on
a
tie.
A
People
are
mostly
in
favor
of
eipip
meeting
and
they
don't.
They
are
not
looking
for
any
change.
So
now
that
today
we
had
this
meeting
at
1500,
I'm
open
to
like
a
revised
calendar
for
next
meeting
onward.
But
again
there
is
a
tie
14
on
14
30.
What
would
be
the
preferred
from
whoever
are
present
today.
C
The
east
and
later
is
always
better
for
me,
because
I
have
a
terrible
sleep
schedule
so
and
you're.
B
In
the
west
right,
yes,
I
have
a
terrible
sleep
schedule,
but
that
makes
it
earlier
better
for
me
because
of
that.
C
Yeah
I
mean
I'd
I'd,
be
okay
with
like
1am
eastern,
if
that's
easier
for
you,
but
I'm
pretty
sure
that
would
be
terrible
for
the
other
eip
editors.
C
It's
5
a.m:
utc,
but
yeah
yeah
anyways.
I
think
you
know
1400.
D
C
Yeah,
I
don't
know,
I'm
also,
okay,
not
really
moving
it.
I
I
can
usually
make
the
the
current
time.
So,
whatever
works
for
everybody
else,.
A
I
think
1400
is
generally
preferred
because
we
have
code
meeting
at
1400.
We
have
cl
meeting
at
1400
and
if
we
keep
this
meeting
even
at
1400,
it
will
be
like
easier
for
people
to
remember.
We
did
keep
it
for
1500
because
it
was
earlier
required
now,
but
now
there
there
is
an
opportunity
with
new
people
in
here.
A
A
Okay,
okay
yeah,
so
the
next
meeting
will
be
on
april
6th
at
1400
utc.
A
Let
me
quickly
open
it.
Eip
editors
will
complete
survey
to
finalize
time
and
date
for
future
meeting.
We
just
decided
on
1400
utc.
That
seems
like
most
of
the
eip
editors
want
to
have
discuss
potential
alternate
names
for
future
eip
ap
meeting.
It
is
going
to
be
eipab
meetings.
Puja
will
add
a
list
of
exceptional
cases
that
may
allow
it.
It
is
non-normative
changes
to
final
eip
to
hack
mba
files
as
reference
to
eip
as
reference
for
eip
editors,
I
keep
updating
the
eip
editors
apprentice
file.
A
That
is
there
with
faq
for
new
people
who
wants
to
get
on
board
with
eip.
Editing
task.
I
don't
know
I
haven't
added
the
link
here,
but
maybe
I
can
share
it
here
in
the
group.
So
if
there
is
any
suggestion
from
any
of
the
editors
here
that
can
be
added,
I'm
trying
to
add
things
here,
which
is
not
for
the
eip1,
but
still
it
is
useful
for
any
anyone
who
wants
to
contribute
as
a
reviewer.
A
So,
yes,
that
is
added
there.
A
And
the
last
one
is
puja:
will
contact
fem
re
ability
to
edit
post?
I
think
this
issue
is
resolved
now,
so
we
should
be
good
with
promoting
fpm
as
the
central
forum
for
discussion
tool
link
for
any
discussion
related
to
new
proposal
or
eipm
draft.
A
The
other
two
items
are
puja
will
follow
with
eip
github
admins,
to
update
setting
to
allow
admin
to
delete
spam
issues
that
is
tan
and
again
fem
limited
editing
window.
That
is
also
done.
So
I
think
we
are
all
good
with
the
items
listed
here
anything
else.
Anyone
would
like
to
bring
up
for
today's
discussion.
A
Actually,
I
tried
I
just
left
to
comment
for
one
of
the
participants,
but
he
said
that
he
unfortunately
would
not
be
attending
the
meeting.
It's
just
that
he's
just
trying
to
add
suggestions
for
a
topic
to
be
discussed,
but
I'll
be
getting
in
touch
with
those
people,
maybe
if
when,
if
or
when
they
are
ready
to
be
a
part
of
it,
happy
to
invite
them.
B
A
And
there
was
this
again
an
issue
which
suggests
that
people
are
looking
for
some
erc
meetup
to
discuss
this
kind
of
thing
like
what's
going
on
with
the
erc
and
help
out
new
authors
to
document
erc
in
response
to
that
issue
also
have
left
a
comment
that
if
people
have
questions
related
to
even
erc,
they
are
welcome
to
join
the
eipat
meeting.
So
we
can
address
all
these
issues
or
they
are
free
to
comment
to
agenda
to
be
added
in
the
meeting
or
just
create
an
issue
at
ethereum
eip
github.
A
We
can
also
collect
information
from
there.
We
are
trying
to
open
all
channels
for
new
authors
and
people
who
wants
to
contribute
as
a
reviewer,
so
yeah.
We
hope
to
see
more
participation
in
future.
Well,
thank
you.
Everyone
for
joining
us
today.
The
next
meeting
is
on
april
6th
at
1400.
Utc
have
a
good
one.
Everyone.