►
From YouTube: EIPIP Meeting 59
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/152
A
All
right,
I
think
I
just
have
shared
agenda
in
chat,
welcome
to
eipip
meeting
59.
This
looks
like
a
small
agenda
for
today's
meeting.
The
first
item
that
is
added
here
is
clarify
how
to
use
erc
versus
eip
to
refer
to
different
eips.
A
This
has
been
collected
by
tim
baker's
comment
on
the
last
meeting
agenda.
So
yeah
we
have
been
discussing
about
this
thing
like
we
see
that
people
are
sometimes
referring
it
as
erc
and
sometimes
referring
it
as
eip.
A
So
for
eip
depot,
I
have
this
question
that
I
I'm
not
sure
I
think
I
would
like
to
clarify
it
for
myself
as
well
like
many
times
when
we
are
referring
to
any
erc
category
proposal
in
another
eip.
C
Okay,
I'm
excited
actually
I'm
on
my
headphones.
Sorry,
I
mean
I
I
feel,
like
erc,
has
sort
of
been
used
a
lot
by
the
community
and
it's
kind
of
difficult
now
to
say.
If
you
want
to
refer
to
erc20,
it's
now
eip20.
C
I
mean
we
can't
really
control
people
doing
conversation,
but
I
think
that
it
just
adds
confusion
if,
like
in
an
already
confusing
process,
if
now
these
things
that
they
talk
about
and
that
is
published
in
every
place,
that
it's
erc
721
years,
t20,
yeah
or
c1155,
and
now
all
of
a
sudden
they're
only
eips,
and
so
it's
just
like
people
start
questioning
like.
Why
is
this
the
case?
And
I
just
don't
it's
just.
It
seems
a
little
unnecessary.
B
Are
you
lobbying
to
change
changes
so
when
people
refer
to
an
ea
erc
within
the
eaps
repo,
they
now
do
erc
dash
number
number
number
and
then
the
link
is.
I
mean
now.
C
B
So
I
don't
feel
strongly
about
this.
If
people
have
a
strong
opinion
on
wanting
to
have
the
erc
instead
of
eip,
I'm
fine
with
it,
but
we
should
definitely
update
the
rules.
If
that's
the.
E
C
B
A
Actually,
I
am
in
favor
of
keeping
it
eip,
because
you
know
this
is
an
opportunity
that
we
can
probably
take
it
to
educate
people
that
eips
and
ercs
are
not
different.
Erc
is
a
category,
but
it's
not
a
type
individually.
That
is
as
good
as
any
other
eip
like
networking,
interface
and
code.
Definitely
the
process
can
be
a
little
different.
The
application
can
be
different,
but
that
is
part
of
ethereum
repository
and
that
has
been
forever
eip.
A
20
people
started
calling
it
for
their
convenience,
but
still
the
repository
calls
at
eip20
and
at
the
time
when
it
was
listed,
it
was
listed
as
eip20.
It
was
verbose
that
they
started
calling
it
erc.
So
if
we
cannot
control
what
people
would
like
to
say,
let
it
be
erc,
but
for
documentation
purposes
if
we
start
mentioning
it
as
eip,
maybe
in
long
run,
people
will
learn
about
the
process
and
come
around
because
at
this
point
what
I
feel
that
changing
eip
eip22
erc20
on
github
repository
would
be
a
big
deal.
A
We
have
to
write
a
bot
altogether
to
change
this
process,
to
get
it
renamed
based
on
the
category
until
we
find
that
this
is
my
feeling,
I'm
like
more
inclined
towards
it,
but
again,
I'm
not
an
eiv
editor,
so
I'll
leave
it
on
the
grid.
A
Do
we
see,
do
we
see
a
hope
of
getting
eip
written
as
erc
on
the
naming,
as
in
header,
I'm
talking
about
in
future.
A
C
A
E
B
The
making
things
show
up
differently
on
ethereum.org
isn't
too
hard.
This
requires
a
little
bit
of
engineering
elbow
grease
to
tell
jekyll
to
do
the
right
transformation
when
it's
compiling,
however,
github
dot
com,
slash
ethereum
eips,
that
one
is
significantly
harder
because
people
do
link
to
that
and
that
one
we
do
not
have
control
over
redirects.
F
B
So
renaming
files
is
problematic
and
I
would
advise
against
that
just
because
it's
gonna
be
a
huge
amount
of
work
and
pain
to
do
so.
But
I
don't
really
have
a
problem
with
changing
our
rules
on
how
people
title
their
links
so
right
now
we
tell
them.
Your
link
must
be
named
eip-120,
I'm
fine
telling
them.
You
can
name
it
erc-20,
but
it's
still
going
to
link
to.
F
Eip-20.Md
yeah,
I
think
I
think
that
makes
sense.
I
think,
like
changing
all
the
links
and
whatnot.
This
is
like
a
huge
waste
of
time
and
like
no
one's
died,
that
erc20
is
eip
20..
I
feel
like
if
it's
easy
to
change,
also
the
title
like
not
if
that
doesn't
break
the
bot
right,
like
it's
kind
of
neat,
if
like
it,
could
link
to
if
the
title
could
be
like
erc20,
but
not
a
strong
opinion
there.
I
would.
F
I
would
definitely
not
take
on
like
technical
debt
of
any
kind
to
make
this
work,
though,.
F
Or
I
guess
so,
like
the
the
h1
header,
like
the
the
first
thing
in
the
markdown
file,
can
that
be
called
like
erc20
without
breaking
I
wouldn't
by
the
way
I
would.
I
think
it
would
be
weird
to
change
it
for
each
dollar
final
so
like.
I
think
it
would
be
like
a
going
forward
thing
like
or
anything
that's
in
draft
or
review.
I
guess
it
would
be
weird
to
now
change
the
ip20
but
like
if,
if
I
have
a
new
eip,
can
I
just
title
it
ercx.
B
So
I
mean
maybe
I'm
generally
apprehensive
about
leaving
the
repository
in
a
half
and
half
state.
If
we
can
avoid
it,
I
would
want.
I
would
ideally
like
to
hear
a
pretty
compelling
argument
for
why
this
will
have
a
very
significant
positive
impact
in
order
to
support
having
like
half
of
the
eips
be
yet
erc
dash
and
half
of
them
be
eip
dash.
That
feels
like
it
would
add
a
lot
of
confusion.
A
A
That
is
something
that
is
coming
automatically
with
the
with
the
bot
for
all
eips,
irrespective
of
category
and
type,
and
that
is
going
to
be
a
tedious
job
to
change
it,
especially
for
erc
category
at
this
point
of
time,
and
I'm
not
sure
how
much
benefit
do
we
get
after
changing
this.
A
So
the
question
I
think
I
was
trying
to
ask
here
that
micah
has
very
well
put
it
into
the
chat
that
what
do
we
want
people
to
be
referring
it
to
erc20,
which
will
end
up
as
eip20.md
or
do
we
want
it
to
be
written
as
eip20
that
will
again
end
up
as
eip
20
dot
md,
so
in
in
in
communication,
if
people
are
using
erc
that
that
is
not
that
we
can
control,
but
as
a
group
who
are
trying
to
improve
the
process,
what
we
can
control
is
the
documentation
part.
A
A
A
Okay,
maybe.
B
A
That
makes
sense.
That's
exactly
what
I
was
trying
to
propose
here.
What
I
can
do,
I
will
create
an
issue
and
I
will
try
to
put
it
over
there,
so
we
can
collect
feedback
from
all
other
eip
editors
who
are
not
present
on
this
call,
and
maybe,
if
community
want
to
participate,
we
can
also
get
their
feedback.
So
the
question
that
I'm
gonna
put
it
over
there
like:
how
do
we
want
to
refer
to
an
eip
in
the
documentation
part,
especially,
we
are
not
controlling
how
people
want
to
communicate.
A
Cool,
so
the
next
item
listed
here
is
a
meta
eip
for
executable
spec
process
for
core
eips.
If
I
remember
correctly
in
the
last
meeting
we
discussed
about
that,
we
would
be
moving
ahead
with
whatever
was
proposed
as
executable
specs
for
corey
ib's
process,
I'm
not
sure
if
either
tim
sam,
you
got
got
time
to
maybe
come
up
with
a
meta
eip
wondering
if
there
are
any
updates
on
that
side.
F
There
is,
but
I
don't
think
it's
quite
final,
so
I
sent
something
to
sam
last
week.
Yeah.
F
No,
no,
no
yeah
and
I've.
I
just
yeah.
I
haven't
even
thought
about
it
since
before
I
saw
this
called
my
agenda,
so
I
basically
sam
had
a
proposal.
F
A
proposal
scouter
proposal
I
sent
like
a
counter
counter
proposal
and
basically
it's
quite
close
to
like
what
sam
had
the
there's
two
changes.
I
guess
one
is
it:
it
proposes
two
paths:
either
we
keep
eip
as
the
place
to
write
the
english
stuff
or
we
or
or
sam's
approach,
which
was
we
don't
do
that,
so
it
kind
of
shows
what
the
process
would
would
look
like
on
both
sides
with
like
some
pros
and
cons
that
that's
the
bit.
F
Hopefully,
sam
can
also
like
unbias
a
bit
more
and
I
think
that's
like
the
biggest
question.
That's
probably
like
probably
something
we
just
want
to
get
client
devs
input
on
and
then
like
whatever
they
choose.
It
probably
makes
sense
there
and
then
the
other.
The
other
smaller
change
is
that
sam's
proposal
would
have
new
eips
the
branch.
The
branch
name
would
be
like
eips
slash.
The
actual
eip
number
slash
a
fork
that
it
was
targeting.
F
I
propose
that
we
don't
have
like
a
target
fork
on
an
eip
when
it
gets
proposed,
because
if
you
imagine
something
like
take
3074,
for
example,
you
first
propose
it.
I
don't
know
for
like
berlin,
then
london,
then
shanghai,
and
it's
weird.
You
would
just
want
to
have
like
a
single
branch
that
tracks
this
proposal
rather
than
having
like
eep
slash
of
3074,
slash,
berlin
and
then
e
3074,
slash,
london
and
and
so
on.
F
It
seems
a
bit
weird,
so
it
seems
like
it's
just
a
bit
cleaner
to
like
have
eep,
slash
the
number
and
then
like
it's
up
to
the
eip
champion
to
rebase
their
branch
off
like
if
master
or
whatever
the
fork
is,
if
they
want
to
then
keep
putting
it
forward,
and
I
think
that
kind
of
matches
like
the
current
eip
process
like
if
you
have
a
change
and
it
doesn't
go
in
a
hard
fork
and
then
some
changes
happen
in
this
hard
fork
that
affect
your
eip.
F
Then
we
expect
people
to
update
their
eip.
They
don't
necessarily
like
create
the
new
eip
and
they
would
create
a
new
eip
in
the
case
where,
like
the
changes,
are
so
significant
that,
like
it's,
it
doesn't
make
sense
anymore,
and
I
feel
like
this.
This
could
work
here
too.
So
yeah
basically
just
changes
that
and
proposes
a
world
where,
like
we
do
keep
we,
we
do
keep
the
each
repo
for
naming
and
non-uh
specification
descriptions.
F
And
I
think
yeah,
sorry,
oh
and
after
this
I
think,
if
we
have
like
rough
agreement
here
like
I
would
be
up,
I
don't
know
if
there's
going
to
be
time
on
the
next
soccer,
devs
we've
been
we've
been
running
out
of
time
quite
frequently,
but
I
think
in
the
next
chord
f
call
or
two.
F
It
just
might
be
good
to
take
five
minutes
to
like
ask
for
feedback
about
that,
and
I
guess
not
only
from
el
devs,
like
also
from
cl
devs,
because
yeah
this
would
obviously
affect
if
they
you
know
if
they
need
to
actually
write
eips
or
whatnot.
A
D
F
I
think
yeah
we
do
need
to
resolve
like
do
we
keep
the
eip
repo
or
not,
because
it's
like
it
would
be
a
very
weird
draft
now,
because
it's
basically
it's
almost
like
it'd,
have
to
be
two
different
proposals
and
I'd.
Rather,
we
just
get
clear
feedback
from
client
devs
and
we
we
can
narrow
it
down
to
one
and
and
like
yeah,
refine
that
spec.
D
F
F
I
don't
know
like,
even
if
they're
not
directly
affected
like.
What's
better,
I
don't
write
the
I
don't
write
the
ips.
I
have
a
strong
opinion
about.
What's
better
so.
B
But
I
yeah,
I
don't
know,
maybe
not
having
an
opinion
is
unrelated
to
whether
it
affects
you
or
not.
A
If
the
question
is
like
whether
we
need
an
eip
repo
or
not,
I
feel
like
either
I
mean
like,
irrespective
of
the
answer
yes
or
no,
they
would
need
a
place
where
they
can
start
making
pull
requests
and
eipd
will
be.
There
will
be
there
for
other
proposals,
so
maybe
core
eip
people
will
not
be
using
that.
F
Oh
yes,
yes,
I
think
sam
and
I
agree
that
there
needs
to
be
like
a
description.
Basically
all
the
stuff.
That's
in
the
core
eip
still
needs
to
happen,
and
the
question
is:
do
we
still
call
those
core
eips
and
have
them
in
the
eip
repos,
or
do
we
just
put
them
coupled
in
the
execution,
executable
specs
repo?
D
E
B
F
A
Can
maybe
I
can
maybe
propose
a
metal
path
here?
I
think
it
is
inspired
by
tim's
earlier
thought.
Even
I
am
in
like.
I
find
it
good
when
people
find
these
proposals,
because
it's
become
way
easier
to
communicate
it
with
community
and
get
feedback
on
just
one
individual
topic
that
we
want
to
share
about.
Just
like
one,
five,
five,
nine.
Maybe
what
we
can
do
is
like
earlier.
A
We
used
to
have
meta
eip
for
upgrades
right
and
it
was
like
all
together
their
meta
eip,
but
we
started
bringing
them
together
in
upgrade
dot
md,
and
we
keep
that
in
executive
execution,
specs
repository.
A
If
people
like
the
group
decides
to
not
use
current
eip
repository
for
future
core
proposals
when
it
is
finalized,
we
can
maybe
create
a
dot,
md
file
of
that
and
bring
it
to
the
repository
for
people
to
refer
to
what
do
people
think
about
it?
I
mean
like
not
until
it
is
finalized,
but
once
it
is
finalized,
then
we
bring
it
here.
Yeah.
F
The
problem
is
you
talk
about
it
most
when
it's
not
final
right
like
and
and
the
other
thing,
the
other
big
challenge
with
this
stuff
is
eips
that
span
both
the
el
and
cl.
F
It's
really
nice
to
have
a
single
name
to
talk
about
it
like,
for
example,
take
like
eip4844
we're
gonna
have
like
talked
about
it
for
a
year
before
it
goes
live
at
least,
and
it's
almost
like,
after
that,
it
doesn't
really
matter
because,
like
it's
live,
it's
part
of
ethereum
and
and
yeah,
and
it's
like
90
of
the
discussion
happens
like
before
the
thing
goes,
live
but
anyways.
I
don't
want
to
take
up
this
entire
call
to
like
go
on
the
pros
and
cons.
I
do
think
it
would
be
good.
F
F
A
Okay,
if
we
have
to
summarize
it
for
note
taking
people
at
this
point
like
just
from
the
present
participants,
we
are
agreeing
like
to
move
the
specs
directly
to
the
executable
spec
and
not
be
a
part
of
present
eip
depository.
Is
that
a
correct
summary
tim.
F
B
B
B
I
am
pretty
confident
that
you're
going
to
end
up
with
some
core
devs
being
passionately
on
one
side,
some
passionate
other
side
and
some
kind
of
don't
really
care
and
somewhere
in
the
middle,
and
so
it
would
be
nice
if
we
could
come
up
with
like
a
plan
for
how
we
make
a
decision
under
the
assumption
that
the
core
devs
aren't
going
to
magically
solve
this.
For
us.
B
F
You,
let
me
know
yeah,
I
I
agree
yeah,
but
I
think
it's
probably
worthwhile
to
actually
go
through
that
step
and
then
have
at
least
a
little
more
information
when
you
you
need
to
sort
through
it
and
if
the
general
feeling
from
the
courthouse
is
like
we
don't
care,
then
I
guess
we
make
a
decision
here
and.
D
One
concern
I
have
with
going
to
the
core
devs
is
that
I
don't
think
that
there's
consensus
on
even
you,
you
know
similar
opinions
to
greg's
are
gonna,
be
like
some
of
the
courthouses
are
gonna
express
that
and
I
I
I
don't
think
adding
more
people
to
the
mix
is
going
to
help
at
all.
C
F
Don't
know
that
I
don't
think
we'll
get
more
consensus,
we'll
get
maybe
more
information
yeah,
but
I
I
agree
it
might
not
be
consensus.
A
I
I
agree
that
moving
to
towards
the
acd
meeting
would
be
the
right
next
step,
but
as
sam's
concerned,
I
have
the
similar
concern
and
I
would
prefer
reaching
out
to
them
when
we
have
a
draft
of
like
meta
e.
Proposing
like
this
is
our
proposal.
The
question
should
be
like
okay,
this
is
what
we
are
proposing
and
the
question
should
not
go
back
to
whether
we
should
do
this
or
not
in
the
first
place.
A
So
until
we
have
that,
like
draft
form
of
meta
e,
we
can
probably
hold
reaching
them.
B
This
is
a
good
point
that
if
we
show
up
with
a
complete
plan,
I
think
we're
more
likely
to
get
buy-in
and
consensus
rapidly
than
if
you
show
up
asking
questions.
What
do
you
guys
think
we
should
do
you
show
up?
We
want
to
do
this?
Is
anyone
opposed,
I
think,
you're
more
likely
to
get
positive
feedback
than
we'd
like
to
change
some
things?
What
do
you
guys
think
we
should
change
et
cetera.
F
You
see,
I
don't
know,
I'm
not
convinced,
but
I
I
can
be
but
yeah.
I
guess
because
this
is
like
a
big
change.
It's
like,
if
I
I
think
it's
like
worse
to
come
in
there
and
be
like
okay,
we're
just
gonna
like
stop
using
corey
ips,
rather
than
saying
like
we
want
to
do
an
executable,
spec
and
there's
like
pretty
general.
I
think
consensus
across
that.
F
Like
sure
some
people
disagree,
but
it
feels
to
me
like
it's
more
of
like
an
80
20
situation
than
like
50
50.,
at
least
from
the
last
conversation
we
had
on
awkward
devs,
which
was
already
a
while
back.
But
then
it's
like
saying:
okay,
we
want
to
do
that.
F
F
Yeah
no
and
yeah,
and
I
think
some
of
the
like,
I
think
you
know
the
the
best
feedback
I
remember
from
the
last
discussion
was
when
martin
said
that,
like
a
bunch
of
core
eips
are
underspecified
and
this
spec
actually
forces
people
to
literally
specify
code
what
they
want
and,
like
I
think
it's
like
yeah
the
quality
of
the
feedback.
You
get
like
to
me
that
that
was
like
if
I
was
on
defense.
That
was
the
thing
that
I
was
like.
F
Okay,
if
we
solve
this
problem
for
martin,
like
the
executable
spec
will
have
been
worth
it
and
there's
not
really
a
strong
counter
argument.
So
maybe
my
hope
is
like
by
having
this
conversation
on
aqua
devs.
There's
something
of
that
vein
with
regards
to
like
eips
versus
not
that
that
comes
out,
and
then
it's
just
like
a
no-brainer.
A
Okay,
so
maybe
we
can
give
another
eipip
meeting
to
discuss
this
further
before
we
reach
out
to
acd.
F
A
Okay,
yeah,
that
makes
sense-
maybe
we'll
try
to
like
share
more
of
this
hackmd
file
to
people
and
try
to
collect
more
feedback
on
that.
A
Cool
I'll
I'll
try
to
bring
this
in
the
next
meeting.
Moving
on
to
item
number
three,
that
is
eap,
bots
related
discussion-
I
don't
see
jose
on
the
call,
but
it
looks
like
jose
got
stuck
somewhere
in
testing
part
and
he
is
having
hard
time
creating
the
testing
environment
for
some
of
the
issues
that
he
is
proposing,
solution
to,
and
also
I
haven't
heard
from
the
from
the
guy
on
the
eipv
side.
I
wonder
like:
is
there
anyone
else
or
is
there
anything
that
foundation
can
maybe
help
out
with.
A
Yes,
I'm
asking
if
we
can
get
more
resources
for
this,
because
I
haven't
seen
any
progress
on
eipv
issue
from
this
resource.
The
foundation
site.
A
Okay,
let
me
try
to
rephrase
my
question,
so
I
wanted
to
check
if
we
can
get
some
help
or
some
support
from
nhdev
who
is
maybe
available
to
help
out
with
bot
eip
part
presenter,
but
to
solve
issues.
There
are
a
lot
of
open
issues
and
pull
requests
as
well,
but
the
resource
from
categories
who
was
working
on
the
improving
the
bot.
He
is
stuck
with
the
testing
environment
and
he
is
looking
for
some
help.
So.
D
Okay,
so
I
can't
help
with
that.
I
have
no
idea
how
to
set
up
typescript
environments
if
somebody's
working
on
eipv.
I
could
probably
help
with
that.
I
don't
know
if
anybody
else
does
typescript,
but.
A
Yeah
for
eipv-
if
I
remember
correctly,
we
had
someone
join
in
a
few
weeks
ago
and
we
were
hoping
to
get
some
updates.
I'm
I'm
not
sure
I
did
not
received
any
feedback
and
I
haven't
seen
any
improvement
there,
so
maybe
we
will
try
to
reach
out
to
them
again
and
if
not,
then,
if
someone
from
the
community
is
willing
to
look
into
the
eapv
path
issues,
please
reach
us
so
some
for
the
typescript
bot.
Is
it
okay
that
I
I
recommend
that
resource
to
reach
out
to
you
for
help.
Whatever
is
needed.
A
A
A
In
addition
to
that,
there
are
nine
eips
in
draft
that
have
been
added
new
and
one
eip
in
informational
category
has
been
added
as
a
living
status.
So
this
would
be
the
second
living
eip
after
eip1,
because
eip1
was
the
only
living
eip.
So
far,
there
are
some
small
changes
to
not
some.
There
is
just
one
minor
change
to
eip
681,
which
was
a
final
eip.
A
A
I
earlier
mentioned
in
one
of
the
meetings
that
I'm
also
planning
to
have
a
separate
website
where
we
can
have
these
charts
and
graphs
directly
getting
it
from
the
github
repository.
I
remember
mika
mentioning
that,
instead
of
going
ahead
with
api,
we
should
may
be
able
to
create
bot.
I
just
wanted
to
provide
some
update
on
that
side.
Mica,
it
seems
like
we
are
having
some
trouble
creating
bot
right
away.
A
A
A
So
that's
that's
the
approach
that
we
are
currently
taking
like
collecting
data
directly
from
there
and
creating
a
temporary
database
to
store
data
on
everyday
basis.
We
are
still
working
on
how
to
automate
the
entire
process.
We
are
working
towards
it
and
I'll
be
reaching
out
to
the
group
and
yeah.
It
is
if
there
are
any
help
needed
on
that
side.
Just
wanted
to
provide
this
update.
A
Moving
on
to
eip's
editor
apprenticeship
meeting,
we
had
meeting
number
20
yesterday
the
recording
is
now
available.
Now
we
are
trying
to
look
into
the
proposals
all
especially
erc
category
proposal,
because
we
have
been
receiving
a
lot
of
requests
from
erc
authors
that
they
need
help.
So
if
any
author
is
new
and
they
want
to
discuss
anything
in
a
specific,
you
are
welcome
to
join
the
eip
editors
apprenticeship
meeting
and
share
the
questions
with
the
eip
editors.
D
D
A
F
A
So
I
wonder
like
anyone
from
the
foundation,
I
don't
know
they
would
be
able
to
help
out
with
any
of
the
future
needs
for
that,
so
maybe
tim
and
now
like
client,
if,
if
you
guys
have
any
reach
on
devops
site
for
future
help,
maybe
we
can
use
that
but
sam.
If
you
are
fine
with
that,
I
can
remove
this
thing
anyway.
I
haven't
received
oh.
A
A
Next
is
which
I
will
collect
feedback
regarding
one-time,
nft
sale
of
unused
eip
numbers.
Unfortunately,
I
could
not
collect
feedback,
although
I
have
seen
that
the
issue
that
is
created
on
eips
github
repository
has
received
a
lot
of
comment.
Maybe
I
will
try
to
maybe
tweet
about
it
and
collect
more
feedbacks,
but
I
will
get
back
on
this
item
next.
Meeting
third
is
samus
and
timbeko
will
create
a
meta
e
for
executable
specs.
We
just
discussed
about
the
process,
so
I
will
get
back
to
this
item
next
week.
A
I
mean
next
meeting
remaining
eap
editors
to
give
their
view
on
using
executable
specs
in
eap
process.
Obviously,
we
are
in
process
of
collecting
feedback
from
community
from
api
editors
and
all
core
dev
developers,
so
we'll
try
to
get
back
on
this
one
in
the
next
video.
A
Thanks
sam,
I
see
your
comment.
I
have
eips
dot
fyi,
that's
nice
name!
Okay,
thank
you
definitely
will
look
into
it.
B
If
we
have
extra
time,
we
can
continue
discussing
executable
spec.
I
do
feel.
B
F
Yeah
yeah
meme,
yes,
yeah.
B
F
Value
and
then
yeah,
the
two
strongest
ones
are
like
mean
value,
and
you
can
use
the
same
number
to
describe
a
change
across
el
and
cl.
So
you
don't
have
like
el1234
and
cl4567
mapping
to
the
same
feature
in
a
way
like
say,
beacon,
chain,
withdrawals
or
like
eip484.
B
So
I
feel
like
the
latter
problem
we
could
solve
without
using
the
efp's
recall
like
we
can
have
a
number
selection
mechanism
and
when
that
number
pool
is
both
cl
and
el
and
for
any
given
number,
you
may
only
have
an
el
part
or
only
a
sale
part
or
you
may
have
both
parts,
but
that's
all
yes
yeah.
So.
F
B
So
if
so,
the
we
need
a
a
number
selection
system-
and
that
could
just
be-
you
know,
create
an
issue
in
github
and
let
them
use
their
auto
incrementing
number
for
it,
or
we
can
have
a
website
that
you
click
a
button
and
it
will
just
give
you
a
number
like.
There
are
a
bunch
of
ways
we
can
get
numbers,
and
so
I
feel
like
let's
ignore
that.
Half
the
problem
for
now,
because
I
feel
like
that's
solvable
in
many
many
ways.
B
B
So
I
guess
in
in
my
mind
I
don't-
and
maybe
you
can
convince
me
otherwise,
with
this
I
don't
see
huge
value
in
ethereum
changes.
Being
memeable
like
like
rfcs
are
useful,
not
because
they
mean
well
but
they're
useful,
because
they
specify
useful
things
that
are
useful
to
people,
and
I
don't
see
yeah
you
help
me
understand.
Why
do
you
think
yeah
yeah
yeah?
Why
are
they
injured?
Why
do
we
want?
Yes.
F
So
so,
for
example,
like
look
at
the
altair
hard
fork
right,
they
don't
have
like
any
numbers
or
whatever,
and
it's
really
hard
to
describe
to
people
what
happened
in
the
altair
hard
fork.
So
I
think,
like
having
individually
assigned
numbers
to
changes,
make
it
easy
to
say,
like
you
know,
change
one.
Two,
three
four
is
a
gas
cost
change,
or
this
is
like
the
change
to
the
validated
reward
curve.
F
So
that's
like
and
that's
like
the
first
degree
of
meme
ability,
if
you
want
right
where
it's
like,
because
then
otherwise,
it's
just
like
people
who
are
very
deep
in
the
weeds
who
discuss
like
these
pr's
on
github
and
like
there's,
no
yeah,
there's
no
thing
to
hatch
onto,
and
I
think
I
think
I
think
that's
bad
yeah.
I
think
that
will
be
solved
regardless.
B
Yeah,
I
agree
with
you
on
on
this
point
having
a
a
short
name,
whether
that's
a
number
or
a
randomly
generated
word.
I
think
anything
is
fine
as
long
as
you
have
something
that's
short
and
concise,
and
you
can
refer
to
it
by
that
thing,
you
know,
like
I
mean
github
has
like
auto
repo
names,
for
example,
or
just
generate
a
single
or
a
double
word.
We
could
do
that.
We.
F
F
Just
aligns
those
two
process
better
and
it
also
you
know
the
community
knows
what
it
is
and,
like
you
know,
the
community,
like
it's
been
like
a
year
year
and
a
half
now
and
like
the
elcl
names,
are
still
quite
hard
have
to
place.
I
I
have
half
the
the
people,
still
use,
e2
and
obviously
over
time,
that'll
change,
but
I
I
think,
like
I
think,
it's
better
to
call
them
all
ethereum
improvement
proposals
than
to
call
them.
Oh,
this
is
like
el
abcd
and
cl
like
xyz
like
it's
just
like
a
it.
F
It
compartmentalizes
them
to
an
extent
that
I
don't
think
is,
is
good
and
and
hopefully
in
the
future.
It's
like
we
want
like
the
modularity
at
the
software
level,
but
I
guess
it's
just.
I
just
think
it's
wrong
to
like
expose
this
at,
like
the
the
user
slash
community
level
from
their
perspective,
it
should
be
like
eip4844
and
like
it
reduces
you
know
the
the
fees
for
l2s,
but
then,
like
implementers,
can
deal
with
eip
484
on
either
side.
I
don't.
F
I
don't
actually
care
where
the
where
the
text
is
stored,
so
I
would
be
fine.
I
would
be
fine
in
a
world
where
we
actually
just
store
the
text
in
the
eips
repo.
One
thing:
that's
a
bit
weird
technically
there
with
sam's
proposal,
though,
is
the
text
only
gets
stored
in
branches,
and
I
think
that's
probably
wrong,
like
you,
don't
want
the
actual
text
to
just
be
stored
in
branches
rather
than
master,
but
that's
not
right.
I
think
that's.
F
But
you
want
a
way
to
render
that
and
again
these
are
not
like
impossible
problems,
but,
like
I
think
it's
I
think,
there's
value
in
having
like
eeps.ethereum.org
and
and
if
we
change
it
from
core
to
el
and
cl
or
whatever.
Even
that
doesn't
work,
though,
actually
because
this
is
the
other
thing
that
doesn't
work.
It's
like,
if
you
make
a
list,
you
want
4844
to
be
like
a
thing
and
then
point
to
the
implementation.
Details
on
both
sides
and
like
client
devs
have
asked
for
that.
F
In
the
past
like
when
we
were
when
we're
like
discussing
withdrawals,
for
example,
they
don't
just
want
to
see
like
withdrawals
on
the
cl
withdrawals
on
the
el.
They
want
to
see
okay,
what
happens
at
like
this
higher
level
of
like
you
know
this.
This
is
what
like
the
cl
is
doing,
and
then
the
el
gets
this,
and
then
this
is
where
it's
actually
specified
in
detail.
F
So
this
is
like
the
bit
I
struggle
with
it's
like
if
you
have
something
like
withdrawals
like
4844,
it's
just
like
much
more
logical
to
like
specify
at
a
higher
level
what
the
change
is
and
then
link
to
like
the
implementation
details
on
both
sides,
and
obviously
you
can
leave
some
comments
and
whatnot
like
in
the
implementation
details
that
are
a
bit
more
in
the
weeds
yeah.
F
B
So
I
think
you
made
a
few
points
in
there,
so
I
think
the
having
both
sets
of
things
and
in
the
future.
Hopefully
if
we
continue
to
go
down
the
path
of
modularity,
you
know
more
than
just
like
this
networking
layer,
there's
a
sense
layer,
there's
the
engine
layer,
there's
the
evm
layer,
etc.
B
Having
all
those
be
share,
a
numbering
system,
I'm
fine
with
having
them
share
a
naming
convention,
I'm
fine
with
as
well
so
they're
all
eips
or
whatever,
I'm
also
generally
fine
with
taking
the
eip
name
and
leaving
the
eips
repo
that
has
all
the
leftover
stuff
which,
with
something
else
so
there's
not
confusion
so
like
turn
it
into
the
erc's
repo
or
whatever.
I
think
I'm
also
fine
with
that.
I
think
where
I'm
in
disagreement
with
you
is.
B
B
If
we
continue
down
that
path,
I
think
we
don't
want
changes
to
frequently
touch
multiple
pieces
like
if
we
do
pull
out
the
evm
and
we
have
the
cl
pulled
down.
We
have
the
el
pulled
out
and
we
have
like
the
transaction
pooling
pulled
out
or
something
and
all
in
different
modules.
B
In
order
to
maintain
the
velocity
and
the
benefits
of
this
modularity,
we
really
want
them
to
be
as
isolated
as
possible,
and
so
I
think
that
I
think
the
thing
that
that
bugs
me
about
your
desire
to
to
have
them
kind
of
like
make
it
easy
to
have
these
change.
Sets
that
cover
both
cl
and
el
is.
F
B
So
I
feel
like
I
feel
like
we
can
most
of
them.
We
can
do
modularly
if
we
force
ourselves
to
and
that's
what
I'm
pushing
for
is
that
we
force
ourselves
to
do
that
like
we
like
they
take
withdrawals,
for
example,
withdraws
our
parts
el
parcel.
That
is
a
thing,
but
we
can
divide
it
up
so
that
the
changes
are
isolated
from
each
other
and
they
don't
depend
on
each
other,
and
I
think
the
the
el
side
would
need
to
go
first.
I
think
someone
else
who's
more
familiar
with
it.
B
B
But,
like
you
don't
start
doing
the
the
second
one
until
the
first
one's
finished
and
you
might
from
a
design
standpoint
you
might
design
like
and
architect
things
more
broadly
when
it
comes
to
specifications
and
defining
things,
I
really
do
think
feel
like
we
should
be
doing
this
separately,
and
so,
even
in
that
short
term
and
over
the
next
one
to
two
years,
we've
got
withdrawals
and
we've
got
sharding
and
all
this
stuff.
I'm
I'm
just
really
loathe
to
throw
away
this
modularity
that
we've
just
finally
gained.
B
We
finally
gained
some
modularity
in
the
system
and
we're
on
a
path
towards
enhancing
ethereum's
development
velocity
and
I
feel
like
if
we
just
merge
them
like
from
a
specifications
level,
then
we've
thrown
away,
throwing
that
modularity
away
and
we're
back
to
bottlenecked
on
whoever's
the
slowest
developer
and
that's
really
what
we
need
to
get
away
from
is
being
bottlenecked
on.
You
know,
whichever
team
is
most
bogged
down
and
we
wanted
to
make
it
so.
The
evm,
for
example,
can't
iterate
without
having
to
wait
for
the
we
got.
B
You
know
a
dozen
evm
proposals
that
alex
wants
to
move
forward
with,
but
he
can't
because
he's
blocked
on
the
core
devs
and
similarly,
you
know,
there's
consensus,
changes
that
I
really
don't
want
to
be
blocked
on
the
execution,
devs
and
so
yeah.
I
think
that's,
I
think,
that's
when
I
think
about
it.
I
think
that's,
I
suspect.
That's
where
our
biggest
disagreement
is.
Is
that
I
really
want
to
discourage.
F
B
Yeah,
I
agree
with
you
that
we
shouldn't
be
exposed
to
users
and
I
actually
do
think
that
we
need.
So
we
have
the
execution
layer,
a
team
and
we
have
the
consensual
team.
I
really
do
think
we
need
a
packaging
team
at
this
point
like
we
need
a
team
whose
job
it
is
to
make
it
so
we
can
shift.
I
think
peter
actually
started
putting
something
together
like
this
as
a
side
project
where
it
was
like
a
thing
you
could
download.
B
I
think
that
should
be
something
that
we
develop
as
like
an
actual
thing
and
you
know
sponsor
if
necessary,
but
you
know
that
needs
to
exist,
and
I
I
totally
agree
with
you
that
we
should
not
be
exposing
this
stuff
to
the
user
at
all,
but
I
think
the
right
way
to
do
that
is
not
to
turn
it
into
model
ftp
software,
but
rather
have
a
set
of
people
whose
job
it
is
is
to
bring
all
the
pieces
together
at
the
end,
yeah
and.
F
Yeah
anyways
we're
at
time,
but
I
think
there
is.
There
is
part
of
that
where
it's
like
within
the
process
of
working
on
it
like
like
484,
I
think,
is
like
a
really
good
example
here,
like
we
need
to
tell
users
about
it
and
l2
teams
about
it
and
like
get
people
who
are
not
like
full-time
core
devs
to
engage
with
this
stuff
and
so
having
a
single
place.
B
F
Really
shitty
experience
like
it's
not.
It
feels
like
it's
a
half-assed
like
thing
that,
like
you
know,
no
one
can
find.
There's
no
discoverability
like
it's.
It
would,
I
think,
there's
like
a
lot
of
value
in
just
having
like
a
document.
That's
like
hey.
Here's
like
the
overall
change,
here's
the
rationale
and
like
here's,
how
you
get
one
level
deeper
into
detail
and
I
feel
like
that
should
be
like
an
official
thing.
That's
part
of
the
specs,
not
just
like
a
a
side
thing
that,
like
any
ip
author
puts
together,
yeah.
B
I
think
what
you're
looking
for
is
like
a
design
document
where
it's
not
a
specification,
it
doesn't
get
into
the
nitty-gritty.
Details
of
you
know
this
byte
goes
here,
but
it's
a
yes
a
design
document
that
maybe
has
some
flow
charts
that
maybe
has
some
sequence
diagrams
and
has
you
know
lots
of
text
that
describes
how
things
are
talking
to
each
other?
I
agree
that
is,
it
would
be
a
very
useful
document,
I'm
not
against.
B
I
don't
think
I'm
against
formalizing
that
process.
I
don't
feel
like
the
eips
repo
is
the
right
place
for
it,
because
the
ip's
repo
at
least
currently
is
you
know
pretty
strict,
pretty
standardized
like
you
know,
we
have
bots
that
expect
a
bunch
of
things
to
be
in
place
and
so
I'd
rather
not
have
design
documents
in
there,
because
I
feel
like
there's
going
to
be
constrained
and
I
want
them
to
be
or
less
constrained.
Like
really
encourage.
B
You
know
external
links
like
I
want
that
to
be
a
thing
in
a
design
document
I
want.
You
know
lots
of
images
and
lots
of
flow
charts
and
I
don't
want
to
be
constrained
to
you
know
you
have
to
have
these
sections
and
you
have
to
have
these
header
fields
or
the
bots
going
to
complain
at
you,
and
so
so
I
I
think
I
agree
with
you.
The
design
docs
would
be
valuable,
I'm
ambivalent,
whether
they're,
formalized
or
not.
I
don't
see
a
huge
value
in
that,
but
I'm
not
against
it
either.
F
Okay,
that's
fair.
I
think
I
would
be
fine
if
yeah.
If
we
had
like
yeah
anyways,
I
I
need
to
hop,
but
I
think
I
think,
there's
probably
something
there
that
that
could
work
yeah.
F
A
Both
yeah,
thank
you
all
see
you
in
two
weeks.