►
From YouTube: EIPIP meeting 44
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/91
A
All
right
welcome
to
eipip
meeting
44.
I
have
shared
the
agenda
in
chat,
so
the
first
item
that
we
have
added
here
is
add
labels
to
pr's.
This
was
brought
up
by
greg,
not
there
and
greg
coleman,
but
the
one
with
chain
save
you
mentioned
it
in
the
eip
editing
discord
channel.
A
I
was
also
interested
in
sorting
these
crs
and
once
requested
to
get
that
triaging
permission,
but
it
was
brought
to
our
attention
that
triaging
permission
is
not
possible
with
the
present
ethereum
github,
for
so
many
reasons,
so
it
was
dropped.
But
I
really
like
the
idea
of
lifeline
of
having
it
done
by
the
bot.
A
B
I
am
I'm
a
fan
of
the
bot
doing
everything.
Of
course
it
takes
engineering
to
do
it,
so
we
have
to
decide
whether
it's
worth
it
or
not.
It
wouldn't
be
so
for
purely
status.
Change
should
be
relatively
easy,
like
yeah,
so
the
problem
is
is
like
analyzing,
a
diff
is
non-trivial
like
it's
possible,
but
it's
a
bit
of
work
to
analyze
a
diff
and
identify
like
what
changed
within
a
pr.
B
A
A
Going
on
the
next
one
is
a
general
consensus
for
closing
the
discussion
to
issues,
so
I
have
referred
to
three
links
here,
so
I'm
a
little
lost
here.
Maybe
I
missed
some
important
piece
of
information.
I
thought
the
group
came
to
an
agreement
that
we
will
try
to
enforce
a
fellowship
of
ethereum
magician,
as
the
only
discussion
took
place
and
the
part
was
even
updated
accordingly
to
provide
a
message
whenever
any
issue,
a
new
issue
is
created.
B
So
the
if
I
remember
correctly,
the
conclusion
we
came
to
was
that
we
would
strongly
recommend
ethereum
magicians,
but
we
wouldn't
strictly
enforce
it.
So
you
tell
people
you
should
really
use
ethereum
magicians
unless
you
have
a
very
good
reason
not
to
whatever
that
might
be.
We
didn't
really
specify,
but
the
idea
was
is
that
if
issues
are
still
acceptable
but
frowned
upon,
given
that
there
are
some
people
who
feel
very
strongly
that
they
want
to
create
an
issue
discussion,
not
an
ethereum
magician's
discussion,
and
so
they
do
and
separately.
B
A
Well,
I
agree
yeah.
That
was
like
a
strong
recommendation
and
definitely
it
wasn't
enforced
though
the
idea
was
slowly.
We
can
move
people
unless
they
have
like
very
strong
reason
of
bringing
it
back
to
the
issues
section
for
older
issues.
I
don't
know
when
we
started
running
the
bar
to
make
it
stale.
The
idea
was
to
close
the
issues
which
which
are
not
in
active
discussion.
A
However,
if
that
proposal
is
on
the
github
repository,
the
discussion
tool
link
is
available
there,
even
if
the
issue
is
closed
and
that
will
always
accept
the
issues.
So
that
is
something,
and
if
people
want
to
keep
it
open
forever,
it
would
definitely
will
get
lost
because
nobody
scrolls
back,
like
10
or
12
pages,
and
to
find
that
particular
issue
to
comment
on
that.
But
with
the
help
of
link
added
to
the
proposal,
it
is
way
easier
that
we
can
do
so.
A
I
think
the
idea
was
to
stop
getting
more
discussion
to
issues
created,
so
we
can
use
that
particular
channel
for
the
useful
issues
that
people
would
like
to
generally
discuss.
A
I
mean
again,
this
is
not
up
to
me
because
I'm
neither
the
author
nor
the
eip
editor,
but
I
was
just
trying
to
give
it
get
clear
picture
to
the
community,
so
they
would
know
what
to
do
and
like
where
to
go.
So
if
we
are
recommending
from
even
with
the
help
of
bart
that
you
should
be
going
and
opening
and
discussion
to
link
at
fem
and
at
the
same
time
we
are
allowing
people
to
have
this
opened
here.
B
B
D
D
A
D
B
B
D
So
we
don't
necessarily
have
to
clean
all
the
issues
for
the
issues
to
become
useful.
We
just
have
to
stop
letting
irrelevant
issues
come
into
place.
Of
course,
there's
still
going
to
be
like
a
few
dozen
issues
scattered
in
the
history
that
are
always
going
to
be
difficult
to
find,
but
I
think
that
that
this
is
like
a
much
more
reasonable
path
to
having
usable
issues
than
clearing
all
of
the
issues
that
exist.
B
So
my
counter
argument
is
twofold:
one
there
is
value
in
having
the
issues
list
to
be
actually
actionable
things,
because
when
you,
you
know,
look
at
github
and
you
see
there
are
41
open,
pull
requests
that
is
much
more
actionable
than
500
open
play.
Requests
like
we
used
to
have
similarly
with
issues.
If
you
see
450
issues,
no
one's
going
to
read
through
those,
whereas
if
you
have
50
issues,
some
new
apprentice
may
be
like
you
know
what
I'm
going
to
go
through
the
issues
and
see
what
something
I
can
handle
worst
name.
B
I
can
do
like
they're.
Actually,
you
know
actionable
items.
The
second
one
is
that
I
would
tentatively
argue
that
no
one
in
their
right
mind,
finds
a
discussion
link
for
an
eip
by
going
to
the
issues
list
and
looking
for
the
iep.
They
always
start
with
the
idea
and
get
linked
to
it,
and
so
closer
open
is
irrelevant,
and
so
there's
no
downside
to
closed
and
there's
a
very
minor
upside,
which
is
the
issues
listed.
D
B
A
Well,
I
think
the
old
issue.
A
So
I
suppose
we
are
actually
talking
about
two
things
here:
one
closing
the
old
issues
and
the
second
one
allowing
people
to
open
the
new
issues.
A
So
if
we
talk
about
allowing
people
to
open
new
discussion,
is
there
a
general
agreement
that
we
can
try
to
request
author?
Let's
say
if,
assuming
that
he
does
not
have
very
strong
reason
to
go
ahead
with
issues
and
not
go
to
the
fem.
A
To
start
the
discussion
tooling,
I'm
I'm
specially
referring
to
an
issue
number
4431
that
I
think
has
been
started
just
10
days
ago
and
it's
fairly
new
and
there's
not
much
of
a
discussion.
And
I
don't
know
why,
but
did
not
provide
the
message
saying
that
you
should
go
ahead
and
start
discussing
at
fem,
though
it
was
designed
that
way.
A
At
some
places,
not
all
the
classes,
because
I
remember
adding
it
somewhere
that
it
is
highly
recommended,
but
when
I
was
checking
it
today,
I
found
that
there
are
other
mentions
and
there
they
have
this
permission
to
open
it
at
issues.
So
I
was
wondering
if
we
can
unify
that
eip1
and
do
it
if
all
the
editors
are
on
board.
If
not,
then
we
have
to
leave
it
the
way
it.
D
B
A
One
thing
that
I
want
to
mention
here
is
generally
people
who
are
creating
issues
or
generally,
they
are
trying
to
add
a
new
proposal.
They
are
already
there
on
fam.
Like
I
mean
it's
rare,
I
mean.
Definitely.
I
haven't
seen
in
my
experience
that
someone
is
not
there
on
fem
and
they
are
trying
to
do
something
here
on
github.
A
F
A
A
Makes
sense
all
right
I'll
go
ahead
and
do
that
I
will
I
mean
if,
if
it
is
fine
by
this
group,
then
to
make
it
like
highly
recommended,
I
will
create
a
pull
request
to
make
all
the
possible
changes
in
eip1,
where
we
are
suggesting
where
to
open
the
discussion
to
link.
A
A
Okay,
now,
let's
move
on
to
the
next
one,
so
the
next
one
is
eip
editors,
apprenticeship
meeting,
so
the
meeting
went
well.
Of
course
we
had
a
decent
attendance
of
new
contributors,
so
thanks
to
timbeko
for
generating
the
momentum
and
help
us
getting
people
reach
us
on
the
discord
channel
and
many
thanks
to
matt
garnett
for
answering
questions
from
their
group.
There
were
a
lot
of
questions,
just
in
short,
the
in
the
meeting.
Yesterday
we
had
a
quick
introduction
of
possible
contributors
for
their
background.
A
I
presented
a
10
minute
overview
of
eip
type
category
and
the
present
process.
Matt
took
the
stream
of
questions
and
worked
this
with
reviewing
a
pull
request
which
is
now
merged
as
an
eip
in
draft
status.
A
A
So
we
have
shared
all
these
information
and
if
someone
is
still
having
question
or
they
would
want
to
reach
us,
please
reach
us
on
ech,
discard
eip
editor's
channel
to
share
your
questions.
D
A
I
see
some
comment
here
on
the
chat
we'll
get
back
to
that.
Let's
finish
up
the
agenda
either
first,
because
those
are
really
low
in
number.
So
we
are
almost
on
the
last
item
listed
on
the
agenda.
For
today.
It's
a
eip's
insight,
the
monthly
eip
status
reporting.
A
I
have
updated
the
inside
for
november
up
till
15
november.
So
far
we
have
three
new
drafts.
One
eip
is
withdrawn
and
two
have
been
moved
to
stagnant
and
three
eips
have
been
reserved
from
the
statement
status.
A
The
good
news
is
864
and
65
are.
Finally,
in
the
last
call
with
the
review
period
ending
on
november
19th.
E
A
I
know
thank
you,
I
I
I
thought
someone
is
saying
something
and
I
just
spoke
over.
There
is
one
thing
that
I
wanted
to
bring
here
before.
I
actually
make
a
pull
request
for
that
in
eip1,
the
bibliography
section,
if
we
can
check
it
out,
it
looks
like
something
is
wrong
with
the
formatting,
because
I
don't
see
any
text
over
there.
When
I
was
looking
into
the
raw
draft,
it
is
available.
B
Let's
see,
I
think
it's
because
markdown
is
recognizing.
This
is
just
a
link
lists
and
it
is
using
it
to
back
the
links.
A
B
So
so
the
markdown
renderer
sees
that
list
of
links,
and
it's
saying
hey.
These
are
just
link
references
and
then
elsewhere
in
the
document
where
that
link
shows
up,
it
will
replace
like
if
you
do
square
bracket,
devp
square
bracket
somewhere
else
in
the
document.
It
will
replace
that
in
rendering
with
that
link,
but
it
doesn't
display
that
below
so
you
can
just
get
rid
of
the
the
header
and
put
that
I'm
not
personally
a
fan
of
this
style
of
markdown,
but
some
people
like
it
like,
I
prefer
just
inlining
links.
E
B
A
B
F
B
If
you
do
that,
instead,
instead
of
just
the
p2p
instead
of
that
do
the
first
one
so
the
second
one
and
then
you
can
get
rid
of
the
the
section
entirely.
B
But
someone
just
need
to
go
through
and
update
all
the
links
throughout
the
the
other
option
is
just
delete
the
bibliography
heading
the
subheading,
so
it
doesn't
look
weird
when
it's
rendered
and
you
just
leave
the
kind
of
link
list
and
maybe
put
it
at
the
very
end
of
the
document
after
the
copyright
I
don't
know
like
I
said,
my
preference
is
to
just
not
use
that
style
of
markdown
links.
I
find
it
confusing,
but
I'm
not
that
passionate.
A
All
right,
so,
if
I
understand
correct
so,
if
I
understand
correct
this
section
is
required
because
we
have
been
using
this
style
for
providing
links
at
certain
places
in
the
document,
and
we
cannot
simply
replace
remove
this
section.
Unless
we
have
these
things
listed
somewhere
down.
E
B
B
Let's
use
that
for
it,
so
the
the
square
brackets
followed
by
the
parentheses
that
one
is
an
inline
link,
and
so
that
works
just
like
you'd
expect.
The
title
will
be
what
you
see
when
it's
rendered
and
the
link
inside
parentheses
is
what
happens
when
you
click
on
it,
for
the
other
format,
where
it's
just
square
bracket,
title
square
bracket
and
there's
no
parentheses
afterwards.
B
B
I'll
look
for
that
somewhere
else
in
the
page
and
then
when
it
renders
it
will
fill
in
the
link.
So
if
we
want
to
delete
that
section,
someone
needs
to
go
through
and
convert
all
the
links
that
are
just
square
bracket
links
without
the
parentheses
to
the
ones
that
have
the
square
bracket
and
parentheses.
Does
that
make
sense.
A
Yeah,
it
does
yeah,
I
mean
I
mean
I'm
just
trying
to
think
over
here
is
like.
It
definitely
is
helping
I
mean
when,
when
it
was
written
for
the
first
time
it
might
have
been
very
helpful
because
they
don't
have
to
repeat
adding
link
everywhere
and
if
someone
has
to
go
do
that.
That
should
not
be
a
problem,
because
that
is
going
to
be
just
one
time
task
to
be
done,
and
people
can
start
following
that
as
a
practice
for
anything
new
to
be
added
here.
A
So
before
doing
that,
maybe
I
can
create
an
issue
or
maybe
a
pull
request
and
then
see
what
is
the
general
opinion
there,
because
this
seems
like
a
big
change,
because
people
who
have
written
it
initially
might
have
considered
that,
like
not
mentioning
it
again
and
again,
maybe
for
so
many
reasons,
just
removing
it.
B
E
B
They're
all
linked
exactly
once
without
the
link
and
then
exactly
ones
down
the
biography
section
like
none
of
them
are
reused,
and
so
that
the
argument
you
made
is
the
reason
people
say
this
is
a
better
way,
but
in
practice
it
doesn't
appear
to
actually
be
benefiting
us
at
all.
In
fact,
some
of
them
are
in
the
bibliography
and
don't
exist
anywhere
else
like
the.
B
Yeah
so
like
the
pull
request,
link
is
in
the
bibliography,
but
it
doesn't
exist
anywhere
in
the
page
anymore,
and
so
this
is
the
problem
with
those
sorts
of
links.
Is
it's
very
easy
when
you
edit
the
document
to
just
like
delete
a
line,
and
then
you
don't
realize
that
there
was
a
bibliography
link
that
needs
to
be
deleted
as
well,
which
is
why
I
prefer
the
inline.
A
A
A
G
Yeah,
so
it's
just
something
that
didn't
get
that
much
attention
back
in
the
r
d
discord.
I
was
wondering
if
anyone
read
that
and
had
some
thoughts
there,
but
we
can
discuss
it
another
time
or
maybe
not
just
the
general
vibe
is
just
safe,
yeah
for
very
complex
things,
specs
versus
aips,
but
I
don't
know.
B
So
the
I
we
definitely
have
talked
about
it
and
thought
about
it.
A
lot
the
currently
sam
and
others,
sam
edel,
is
working
on
a
executable
spec
for
ethereum
this
means.
So
the
idea
is
basically
a
version
of
ethereum
written
explicitly
for
being
readable,
not
for
being
performant
or
usable,
and
so
it
likely-
or
in
fact
we
know
it-
will
not
be
able
to
run
in
the
real
world.
It's
written
in
python.
B
You
will
not
be
able
to
sync
mainnet
off
if
you
would
like
to
run
it,
but
it
is,
will
pass
all
the
tests
and
it
is
a
functional,
client
and
again.
The
goal
here
is
it's
written
to
be
incredibly
readable
and
the
idea
is
is
in
the
future,
hopefully
near
future,
we'll
see
how
fast
they
can
get
that
done.
B
Instead
of
having
the
yellow
paper,
which
is
both
unreadable
and
not
executable,
we
will
have
the
executable
spec,
which
people
can
read
and
execute
and
so
other.
When
we
do
changes,
we
can
just
make
a
pr
essentially
or
a
diff
against
that
executable
spec
and
say
this
is
the
change
and
the
reason
is
valuable.
Is
things
like
eip
1559,
for
example?
B
We
basically
had
to
kind
of
redefine
a
bunch
of
stuff
in
the
specification
section
of
that.
So
that
way
the
change
made
sense
like
in
order
to
explain
the
change
you
had
to,
for
we
had
to
first
explain
the
existing
system,
and
this
is
very
tedious
and
annoying,
and
it
leads
to
bugs
and
whatnot
so.
B
B
If
you
would
like
to
keep
the
eip
process
and
have
the
eips
maybe
link
out
to
the
a
diff
against
the
executable
spec
in
the
specification
section
sam,
I
believe,
wants
to
keep
the
certain
sections
of
the
ap,
such
as
security
considerations,
backward
compatibility,
rationale,
motivation
in
a
isolated
document,
but
in
the
specs
repo,
so
maybe
in
the
form
of
like
still
a
markdown
document
of
some
kind
and
they
would
sit
and
sit
next
to
the
change
itself.
B
In
some
way
I
mean
there's
people
like
me
who
are
on
the
far
extreme
of
I
would
prefer
to
just
say,
keep
all
that
information,
because
I
consider
it
to
be
transient
information.
Keep
that
information
in
the
pr
that
is
goes
along
with
the
spec
change,
but
don't
retain
it
somewhere
permanent
and
so
there's
definitely
lots
of
discussion
on
this
lots
of
differing
viewpoints
and
opinions.
C
B
How
that
turns
out
and
wait
to
see
you
know
what
structure
is
like
and
maybe
try
a
few
different
things
before
going
too
hard
on
one
solution,
so
yeah,
so
does
that
answer
your
question
of,
or
would
you
like
to
discuss
it
more,
I'm
open
for
it
yeah
yeah,
that's
awesome
is
that
sam
wilson,
yeah
sam
wilson,
is
the
one.
A
Recently,
sam
wilson
came
on
and
he
provided
the
latest
on
the
execution
respects
that
that
he
is
working
on
for
documenting
in
python
as
well
as
he
proposed
his
new
idea
of
eip
process
that
he
thinks
could
be
useful,
but
that's
in
thought.
Phase
right
now
probably
will
keep
on
iterating
and
think
what
would
be
the
better
way
or
better
approach
to
continue
the
eip
process
once
this
pack
is
like
fully
functional
and
people
are
out
of
the
merge
thing
and
start
thinking
in
this
direction.
A
B
A
No
problem,
I
will
share
that
with
you
I'll
do
me
you
and
I
want
to
bring
one
last
thing.
Oh
okay,
if
we
are
done
with
this
topic
of
britain,
did
that
answer
your
questions.
A
A
Is
it
any
value
making
it
a
standard
that
whenever
we
are
referring
to
a
status,
it
should
be
all
caps
and
whenever
it
is
where
you
are
referring
it
to
a
word,
it
can
be
in
running,
say,
for
example,
review
review
is
a
review
that
we
do
for
proposal,
but
review
is
also
a
status
so
when
we
are
trying
to
refer
it
as
a
status
and
we
start
using
it
in
all
caps
would
help
people
to
differentiate
between
whatever
we
are
talking
about.
I
mean
it's
just
my
general
thought.
What
do
you
guys
think.
B
I
find
myself
sometimes
doing
that
just
out
of
habit,
I
think,
for
the
habit.
I
think,
for
the
same
reason
that
you
just
described.
I
do
it
it's
kind
of
subconscious
and
when
I
catch
myself
doing
it,
I
correct
and
remove
the
all
caps.
But
if
everybody
agrees
to
do
all
caps,
I'm
okay
with
it.
D
D
I
I
don't
really
care
that
much,
but
I'm
not.
I
don't
really
like
all
capital
words
when
it's
not
really
unnecessary.
B
A
All
right,
because
in
the
eip1
at
the
moment
I
see
that
it
is
a
mix
of
both
like
some
places
when
we
are
writing
it
explaining
the
statuses,
it
is
kind
of
all
caps
and
somewhere.
It
is
running
so.
A
A
No,
it
just
came
to
my
attention
because
sometimes
in
my
general
presentation,
I
talk
about
statuses
and
I
myself
write
it
in
both
ways,
sometimes
running
and
sometimes
in
all
caps.
So
I
was
thinking
to
bring
it
to
a
standardization
that
I
can.
I
can
follow
it
for
myself
and
that's
why
I
wanted
to
bring
it
up
to
you
guys.
B
A
G
B
B
A
A
Okay,
let's
move
on
to
the
last
item.
That's
the
action
item
from
the
last
meeting.
43.1
is
rename
review
period
end
to
last
call
and
to
be
added
in
eip
template.
I
saw
a
recent
merge
which
suggests
that
it
is
something
different
than
last
call,
and
I
don't
want
to
like
debate
on
that.
If
it
is
fine
by
everyone.
A
So
I
think
I
I
saw
the
per
request
where
we
have
actually
updated
this
particular
field,
but
it's
not
as
last
call
and
it's
it's
something
different.
It's
last
called
a
review
period
last
call
or
something.
Oh.
B
Yeah
yeah
the
we
renamed
deadline
or
not
deadline
whatever
it
was
called.
A
Last
call
and
or
last
call
deadline,
something
I
don't
know
I
mean
I
it's
again,
not
a
hill
that
I
would
like
to
die
on,
but
I
just
want
to
say
that
it
has
been
updated,
not
accordingly,
what
was
discussed
something
different,
but
there
is
an
update
that
might
reflect
that.
It's
about
the
last
call
period,
not
the
tv
period,
I'm
trying
to.
E
Yes,
I
think
I'm
trying
to
pull
it
out.
A
Oh
sorry,
I
think
yeah
yeah,
I
think,
matt
updated
it.
How
is
it
rename
review
period
end
to
last
call
deadline.
B
B
The
name
could
be
better,
and
so
I'm
totally
fine
with
the
person.
A
Right
right,
yeah
yeah,
I
was
just
trying
to
make
it
a
point
that
it
has
been
updated.
Now
it's
no
more
review
period
ending
is
reflecting
the
last
call,
not
exactly
the
same
wording,
but
the
field
is
updated
now
and
it
should
be
better.
I'm
making
more
clarity
yep
all
right.
The
next
one
is
what
it
takes
to
be
on
the
list
of
active
editors.
Oh
it's
just
the
listing
of
it
43.3
to
agree
on
who
gets
mentioned
in
ea.
A
So
if
anyone
is
hearing
this
call,
we
are
looking
for
a
champion
who
can
jump
in
the
idea
shared
by
nick
johnson
and
eib's
issue
section,
and
if
you
are
willing
to
put
on
time
please
reach
ap
editors
or
the
cat
holders
anywhere
on
their
discord
channels,
ethernet
or
mdc.
A
The
last
one
here
is
puja
to
open
an
issue
with
eatpod
repo,
a
little
check
the
bad
merge.
I
think
the
part
has
merged
the
eip
2070
that
we
were
having
issues
with
and
yeah.
I
think
that's
all
from
the
action
items
from
the
last
meeting
we
have
about
five
minutes
left.
Anyone
wants
to
bring
up
anything.
F
B
D
B
C
A
A
G
B
So
eip
numbers
are
just
numbers,
so
it's
just
going
to
be
a
number
from
like
one
to
ten
thousand
or
whatever.
Now
people
can
put
whatever
they
want
in
the
title.
We
generally
leave
that
entirely
up
to
the
author,
I
discourage
people
from.
B
B
I
would
if
I
saw
someone
referring
to
their
eip
as
another
eip
number
than
what
it
is.
I
would
probably
step
in
and
correct
them,
and
if
you
see
someone
doing
that
in
the
efus
repo
pointed
out
to
me,
because
that
is
definitely
not
acceptable.
In
my
opinion,
like
the
numbering
system
exists
for
a
reason,
and
it's
people
should
not
be
trying
to
basically
use
the
like.
B
When
I
see
when
I
see
what
you
just
typed
there,
my
gut
is
that
someone's,
basically
trying
to
use
the
marketing
poll
of
1155
in
order
to
pump
their
own
thing
and
I'm
very
much
not
a
fan
of
that
the
numbering
system
should
not
be
a
marketing
scheme,
like
its
numbers,
are
meant
to
be
monotonically,
increasing
and
strictly
for
organizational
purposes.
The
title.
C
B
You
should
go
by
so
like
if
you
want
a
cool
title,
give
your
eip
a
cool
title
like
as
much
as
I
hate
the
diamond
standard
naming
system,
that's
a
cool
title
and
it's
meaningful,
and
so
people
can
call
it
the
diamond
standard
so
yeah.
So
so
the
the
short
answer
is,
you
should
not
be
naming
an
eip
that
is
not
eip1155
as
eip155,
not
something,
nor
should
you
name
it.
Erc1155.Something.
G
Okay,
yeah!
No,
I
didn't
get
that
clear
across
very
clearly.
I
think
it
was
more
that
I
feel,
like
I've
at
least
found
on
two
proposed
ercs,
that
there
were
subtypes
within
the
document
in
some
senses
in
like
a
stronger
version,
then.
G
Within
the
same
arcs,
I
can
find
the
examples
if,
as.
B
B
I
have
to
think
on
how
I
feel
about
that.
Like
I
feel
like,
if
you're
gonna
have
two
standards,
you
should
just
have
two
standards
in
the
pa
for
core
eips.
Specifically,
I
strongly
advocate
to
every
single
author
that
if
you
can
break
an
eip
up
into
multiple
eips
you
should
they
go
through
smoother
they're
easier
to
implement.
People
can
choose
whether
they
implement
all
or
nothing
or
one
or
the
other.
From
a
communication
standpoint,
it's
way
easier
from
a
coordination
standpoint.
B
It's
way
easier,
like
people
should
be
writing
very
small
eips
that
do
the
least
amount
possible
is
similar
to
the
general
concept
in
software
engineering,
where,
if
you're
going
to
submit
a
change
request,
they
should
be
as
small
as
possible
and
you
submit
multiple
small
change
requests
that
are
each
individually
useful
and
individually
tested
and
everything
rather
than
one
monolithic
one,
because
it
just
makes
the
process
a
lot
easier.
So
I
feel
very
similar
for
eips
that
really
they,
if
you've
got
multiple
standards
within
an
eip.
B
That's
a
very
strong
signal
to
me
that
you
really
have
multiple
eips
and
you
should
just
create
multiple
aps
so
yeah.
I
guess
I
guess
my
answer
is
I
don't
have
a
strong
opinion
on
the
sub
naming,
because
I
don't
think
people
should
be
doing
that
getting
into
position
in
the
first
place
where
they
need
the
sub
name.
A
I
think
this
is
something
that
has
to
be
given
by
the
eip
editor,
so
otto
should
not
try
to
grab
a
number
for
himself
or
herself
right
in
the
first
place
and
when
we
are
doing
it
with
the
help
of
a
pull
request
or
issue
number,
I
don't
think
this
kind
of
number
system
should
exist
in
the
first
place.
B
Yeah
in
this
case,
what
they're
saying
is
someone
wrote
an
eip,
so
let's
say
eip1234
and
then
within
eip1234.
It
has
two
different
standards
defined
and
they're.
Saying
like
how
do
you
refer
to
the
two
different
standards
like?
Do
you
do
eip1234.a
and
b
or
do
eip1234.1
and
dot
two
or
something
else?
And
my
argument
is
you
just
have
the
ip
one,
two
three
four
and
eip
one,
two,
three
five.
A
I
would
really
support
your
argument
here
because,
as
you
mentioned,
that
you
already
have
been
advocating
it
for
the
core
eips
and
that
turned
out
to
be
really
good,
it
is
helpful
in
implementation.
Finders
find
it
easier
to
implement,
so
I'm
hoping
that
it
would
be
helpful
and
even
on
the
application
side,
if
any
developer
wants
to
pick
up
only
one
part
of
the
eip-
and
there
are
two
separate
eips-
proposing
different
solutions.
D
I
A
Right
yeah,
it
wasn't
like-
and
there
is
this
there
is
this
calendar
that
is
created
by
ethereum
pm,
so
that
might
also
need
some
updating,
because
that's
also
showing
the
older
one
and
the
one
that
I
run.
I
updated
it
this
morning
so
might
be
sincere.
A
C
H
I
guess
is
there
anything
really
urgent
that,
like
you
really
needed
me
for
yeah?
Okay,
sorry
about
that,
I'm
gonna
change
the
time
zone
on
the
protocol
meeting
invites
to
be
utc,
which
I
think
we
can
do
now.
So
that
means
that
it
actually
stays
kind
of
fixed
right.
A
B
D
H
A
Oh
well,
thank
you,
everyone
for
joining
us
today
and
hope
to
see
you
in
next
two
weeks
and
thank
you
tim
for
already
updating
the
universal
calendar
that
we
are
recommending
people
to
join
and
follow.
So
thanks.
Everyone
see
you
in
two
weeks.
Thank
you.