►
From YouTube: EIPIP Meeting #10
A
Alright,
hello,
everyone
and
welcome
to
eip
ip
meeting
number
10.,
let's
get
started.
The
first
agenda
item
is
an
eip
number
registry
process
and
I'll
go
ahead
and
post
the
agenda
in
the
zoom
chat.
A
I
know
we've
talked
about
this
a
little
bit.
James
is
on
vacation
and
some
of
these
items
are
his,
so
we'll
be
going
through
them
pretty
quickly.
I
think
this
is
one
of
his
items,
but
I
know
some
people
in
here
also
had
some
comments
on
that.
So
there
is,
let's
see
the
last
I
heard
about
it.
Was
there
was
a
possib.
There
was
like
an
idea
to
have
editors,
keep
up
with
a
list
of
eip
numbers
and
then
assign
the
eip
numbers.
A
B
I,
what
I
remember
is
that
there
was
bloat
with
the
eap
numbers
that
the
erp
numbers
were
tied
to
the
issues.
So
we
wanted
a
way
to
possibly
reduce
that
and
then
greg
had
a
point
where
well,
yes,
there's
blow,
but
it
was
kind
of
decided
early
on.
I
think
it's
in
the
agenda.
B
It's
comment
getter
and
that
it
let
me
try
to
open
it.
C
I
shared
the
link
in
the
chat
for
they
get
a
comment
received
from
greg
colvin.
B
B
If,
if
there's
bad
actors,
they
can
be
banned,
if
necessary,
I
think,
like
the
current
process
is
fine,
as
in
it
has
a
low
bar.
Is
it
low
barriers
to
entry?
If
we
were
to
have
people
go
through
any
the
eip
editors,
it
might
increase
their
workload,
and
currently
I
don't
think
we
have
too
many
ap
editors,
so
they
might
be
overwhelmed,
but
just
accepting
numbers
if
you
were
to
do
it
that
way
and
if
we
were
to
like
have
them
do
a
pr
to
an
existing
eap.
A
That
makes
a
lot
of
sense.
I
would
say
that
this
is
probably
a
like
not
as
big
of
an
issue
to
tackle.
It
is
something
we
do
want
to
look
at,
but
I
feel
like
we're,
maybe
trying
to
fix
a
problem.
That's
not
a
major
problem
right
now,
because
we
are
using
github
and
if
we
were
to
ever
move
away
from
github
for
the
eip
process,
then
we
would
need
to
come
up
with
a
numbering
thing,
but
until
then
there's
not
really
a
pressing
need
for
it.
A
I
don't
think-
and
so
it's
almost
like
we'd
be
putting
more
overhead
on
editors.
If
we
were
to
do
this
to
do
at
literally
any
numbering
system
and
as
far
as
the
bloat
argument,
I'm
not
sure
there's
that
much
bloat
like
people
can
spam
eip's
repo
to
make
the
number
go
up
a
long
time,
but
it's
unlimited
numbers
so.
C
Personally,
I
agree
with
the
idea
of
continuing
with
the
eip
github
issue
number,
because
I
mean,
as
we
mentioned,
that
it
is
going
to
be
unlimited
and
if
we
are
seeing
it
for
even
a
very
long,
very
long
time,
there's
no
no
change
in
the
previous
and
the
present
system
when
we
are
continuing
by
number
and
we
have
the
pr
number,
it's
very,
very
convenient
to
refer
in
the
different
calls,
even
before
it
is
actually
being
merged.
So
suppose
we
have
different
pr
number,
plus
the
plus
another
number
for
eip.
C
It
may
kind
of
create
some
kind
of
confusion
after
a
while,
because
we
start
discussing
long
before
it
is
actually
being
more.
D
Yeah,
the
other
idea
with
mine
is
basically
to
introduce
to
commission
the
development
of
the
front
end
to
to
the
eap
repo
and
basically
to
have
every
every
potential
eib
author
submit
their
eaps
through
this
front
end.
But
it
would
definitely
add
an
additional
layer
of
complexity,
although
it
would
probably
solve
the
numbering.
E
B
I
think
if
there's
a
way
to
automate
it,
I
think
we
could
solve
it,
but
right
now,
if
we're
having
to
do
it
manually
through
a
pr
through
an
eap,
maybe
if
we
could
get
the
vip
bot
to
do
it,
and
that
would
be
better,
but
currently
I
think
it
might
cause
more
more
complexity,
more
inconvenience.
A
That's
kind
of
the
consensus
I'm
hearing
from
the
group
today
so
yeah
we
can
does
anyone
else
have
comments
on
this.
Otherwise
we
can
move
on
from
it
because
it
sounds
like,
as
far
as
today
goes,
there's
not
a
lot
of
strong
opinions
to
continue
to
work
toward
a
solution
to
this
today.
A
All
right
next
item
separation
of
the
eip
process
from
the
hard
fork
coordination
process.
We
worked
on
this
a
lot
last
time
I
was.
I
was
editing
the
agenda
earlier
and
I
forgot
to
move
this
one
because
since
james
isn't
here-
and
we
solved
a
lot
of
this
last
time-
we'll
go
over
this
next
meeting,
just
to
refresh
everyone's
memory
on
the
new
chart
that
we
have
or
not
new
chart,
but
the
edited
flow.
A
I
guess
the
flow
chart
and
some
other
notes
that
james
put
down-
and
I
think
that's
in
the
eips
to
do
link
on
item
six.
I
think
it's
a
hackmd
that
has
yeah
the
hackmd
item
on
on
number.
Six
is
owned
by
axic,
but
I
think
james
hancock
also
works
on
it.
So
that
should
have
the
latest
stuff
if
you're
interested
in
looking
at
it.
But
since
we
don't
have
axac
and
james
here,
I
think
we
should
wait
till
they
get
on
the
next
meeting.
A
James
is
just
on
vacation
he'll
be
back
in
next
week
and
then
axic,
I
don't
think,
was.
B
B
A
Good
idea,
let's
see,
and
do
we
want
to
do
any
of
that
today
anybody.
D
Okay,
we
could
anyway,.
A
Edson,
did
you
have
something
I
was
gonna
say
we
should
wait
till
james
is
here:
oh
okay,
cool
in
that
case.
Next
up
we
have
item
four,
the
zips
reference,
especially
keywords.
A
Zcash
has
one
called
zips
and
on
the
very
first
section
in
terminology
there
are
keywords
that
are
defined
like
must,
should
should
not
may
required
that
are
defined
in
rfc
2119
and
then
it
also,
interestingly
enough,
it
says
the
term
network
upgrade
in
this
document
is
to
be
interpreted
as
described
in
zip
200..
A
A
So
this
will
be
a
really
cool
way
to
look
at
how
to
our
sub
processes
or
our
meta
eips,
or
our
active
vips
and
stuff.
Like
that,
I
really
like
what
they
did
with
zip200
and
I
like
that
they
have
different
terminologies
defined.
Are
there
other
comments
or
other
topics
within
this
item?.
B
I
think
astm
have
a
section
for
keywords
or
terminology:
are
they
included
as
a
part
of
their
standards?
I
think
a
few
other
standards
like
bodies
have
the
same.
Lord
standard
organizations
have
the
same
thing,
a
terminology
section,
I'm
not
sure
if
we
should
convert
or
apply
their
specific
terminology,
but
we
can
probably
consider
adding
a
terminology
section.
B
A
F
So
I
I
would
also
say
that
it
should
be
required.
The
use
of
the
keywords
in
like
in
templates
or
submissions.
A
Yeah,
I
think
that
keywords
are
important
and
so,
whether
or
not
they're
as
far
as
if
they're
required
or
not,
I
don't
know
where
I
am
on
that
issue,
but
I
think
it
is
important
to
at
minimum
included
in
the
template.
Like
you
said,.
A
A
A
Okay,
the
next
agenda
item
is
number
five:
how
to
deal
with
non-normative
edits
to
existing
eips,
ensure
the
responsiveness
of
editors
on
actually
merging
prs
and
split
eips
into
multiple
repositories.
So
this
is
micah.
I
don't
think
that
micah
is
here,
so
we
might
not
be
able
to
talk
too
much
on
this,
but
we
can
kind
of
go
over
each
one,
because
there's
three
different
topics
within
the
comment
that
micah
left.
A
A
How
would
we
deal
with
important
updates
like
wording,
improvements
or
clarifications
of
something
that
like
is
incredibly
wrong
or
a
new
security
consideration?
If
we're
deciding
that
that's
required
for
one
of
the
eips
that's
been
published
for
a
while,
and
we
can't
contact
the
author.
Does
anyone
have
ideas
on
how
that
could
be.
C
Resolved
not
a
specifically
on
the
resolution
part,
but
I
was
going
to
comment
on
this
section
like
it
may
be
also
related
to
again
the
increasing
the
number
of
pr's
like.
If
we,
if
we
do
these
kind
of
non-normative
edits,
we
again
have
to
create
a
pr
here,
so
I
mean.
A
Yeah,
if
there's
like
consensus
among
the
editors,
that's
an
important
enough
change,
just
make
it
and
there's
a
history
within
github
that
you
can
go
to
to
see
when
the
changes
were
made
and
you
can
maybe
maybe
have
the
editors
have
a
requirement
to
notate
a
date
or
maybe
have
a
section
of
the
eip.
That's
like
post
eip
changes.
I
don't
know
if
we
want
a
section,
because
that'll
imply
that
you
can
change
your
eip
in
the
future,
which
this
should
really
be
a
rare
process
but
yeah.
C
The
other
solution
that
I
think
was
proposed,
sometimes
back
in
in
one
of
the
initial
meetings
of
eipip,
to
have
a
kind
of
group
which
is
like
subgroup
for
the
these
editors.
Because
again,
these
non-normative
edits
may
not
be
a
big
deal.
I
mean
like
these
are
important
to
make
it
provide
better
clarification,
but
may
not
be
something
that
all
the
time
we
might
have
to
attract
editors
attention
here.
So
if
there
could
be
some
kind
of
subgroups
which
would
be
looking
into
these
kind
of
pull,
requests
and
kind
of
approving.
A
We
definitely
need
that,
if
there's
enough
of
those
eips
to
warrant
that
I
don't
know
right
now
how
many
of
them
are-
and
this
is
like
a
section
of
eips
that
are
needing
to
be
edited
because
of
improvements
after
they've
been
finalized,
so
not
just
in
draft
status
and
that
we
can't
contact
the
author.
I
feel
like
that's
more
going
to
be
more
rare,
but
I
could
be
wrong.
F
Is
is
it
required
if
the
eip
is
finalized,
then
would
you
need
to
have
the
author's
input
just
to
reword
things.
A
It's
probably
a
good
idea,
because
otherwise
people
can
accuse
the
that's
a
good
point.
They
could
accuse
the
editors
of
being
malicious
or,
when
I
say
malicious,
I
don't
mean
like
really
malicious,
but
like
changing
up
the
wording
for
their
own
benefit.
That
would
be
the
only
thing
I
can
think
of.
If
it
comes
from
the
author
and
the
editors,
then
that's
like
two
sources
saying
this
needs
to
be
changed
and
that
might
be
enough
for
a
consensus
around
the
change
was
my
thinking.
F
A
Let's
see
anybody
else
have
comments
on
this
one.
A
A
We
can
touch
on
it
a
little
bit
today
if
we
want,
since
we're
going
through
the
agenda,
pretty
quick.
Does
anyone
have
any
off
the
cuff
ideas
for
either
recruitment
or
incentivization
for
editors
and
making
sure
they
merge
prs
at
a
fast
rate.
A
Yeah,
that
might
be
a
good
discussion
topic
all
on
its
own.
Actually,
I'd
say:
let's
do
that.
G
On
that
there's
a
lot
of
teams
that
are
working
on
clients
right.
Would
it
be
some
kind
of
onerous
to
put
the
responsibility
on
all
the
all
the
companies
developing
clients
to
provide
or
pay
for
or
assign
people
on
their
teams
to
be
editors
or
some?
I
don't
just
a
thought,
but.
A
The
only
thing
would
be
that
would
maybe
work
for
core
eips
for
ercs,
which
is
the
majority
of
eips
that
wouldn't
be
applicable.
I
don't
think
or.
G
A
Wanted?
Okay,
that
makes
sense
thanks
all
right
anything
else
on
that
topic,.
H
I
mean
sorry
just
as
an
offhand
idea,
sometimes
having
creating
some
sort
of
achievement,
type
of
visualized
thing
incentivizes
people,
because
they
can
show
it
off
to
people.
I
know
it
sounds
very
flat
as
an
idea,
but
it
it
does
tend
to
work.
It
just
has
to
be
based
off
of
objective
things,
and
it
doesn't
have
to
be
super.
Complicated,
doesn't
have
to
be
an
nft
specifically,
it
could
just
use
git
coins,
kudos
framework.
A
C
We
do
not,
we
may
not
have
enough
editors
to
do.
You
know
this
kind
of
responsibility
to
take
this
responsibility
at
this
point
of
time.
So
maybe
we
should
be
focusing
on
how
to
onboard
more
editors
to
kind
of
solve
the
issue
in
longer.
A
Oh,
I
couldn't
hear
you
elita.
Can
you
talk
again?
It
might
be
my
internet
connection,
but
I
think
you
cut
out.
F
Sure
I
was
wondering
if,
if
we're
talking
about
core
editors
or
just
specific
eip
editors,
or
in
other
words,
authors.
A
My
internet
cut
out
for
a
second,
so
I
don't
know
what
that
was.
One
is
in
reference
to
is
that
for
item
two
for
micah's
stuff.
C
A
A
Yeah
and
once
we
get
to
the
point
where
we're
talking
about
editor,
more
editor
involvement
and
how
to
recruit,
and
things
like
that,
I
think
that
will
improve.
What
am
I
trying
to
say
if
we're
talking
about
that
kind
of
stuff,
I
think
once
we
start
talking
about
that
in
a
future
meeting,
we
can
better
coordinate
around
designations
for
editors
and
things
like
reputation,
systems
or
kudos
systems
or
stuff
like
that.
F
I
think
it
might
be
beneficial
to
kind
of
have
a
description
of
what
it
means
to
be
an
editor
that
would
probably
help
people
or
help
us
at
least
narrow
down.
Where
we're
going
to
be
looking
to
say,
advertise.
H
A
Okay
for
the
next
one
split
eips
into
multiple
repositories
as
a
reviewer,
I
don't
want
to
see
or
review
ercs,
but
I
do
want
to
see
review
core
eips.
A
protocol.
Dev
may
not
want
to
see
a
review
interface
eips
by
splitting
core
interface
and
ercs
at
a
separate
repos
people
can
subscribe
to
one
or
more
rather
than
having
to
drink
the
entire
fire
hose
of
vips.
A
I
see
their
point.
My
first
response
to
that
would
be
separating
them
into
multiple
repositories
would
be
a
lot
of
work
which
wouldn't
be
impossible
to
do,
but
for
the
benefit
of
people
just
seeing
what
they
want
to
see
from
github
notifications,
we
can
make
our
own
rss,
feed
and
other.
There
already
is
rss
feeds
actually
for
different
types
of
eips,
and
we
can
make
more
of
those
we
can
make
different
custom
email
notifications.
A
We
can
connect
it
to
maybe
discourse
forms,
or
things
like
that.
So
I
think,
there's
better
ways
to
solve
the
what
what
people
want
to
see
and
review
from
a
notifications
perspective
other
than
splitting
it
out
into
multiple
repositories,
but
I'm
open
to
hear
other
ideas
that
or
other
reasons
why
multiple
repos
would
be
a
good
idea.
B
I
agree
with,
I
agree
with
you
as
in
we
could
just
it's
the
he
just
needs
a
notification
for
corey
aps
and
then
anyone
else
could
just
have
a
notification
for
erc
eaps,
for
example,
and
we
do
that
with
rss
or
email
notifications,
but
I'm
splitting
them
out,
I'm
currently
the
numbers
tied
to
that
repo.
D
Yeah,
as
far
as
I
know,
we
have
github
github
labels
for
issues.
How
about
we
start
using
them
actually.
A
A
A
C
I
would
agree
that
this
labeling
system
would
be
helpful.
I
I
mean
adding
to
it
like
documentation
of
these
kind
of
instructions
in
the
eip1
would
be
very
much
helpful
for
newcomers.
You
know,
or
maybe
even
to
existing
eip
editor
or
crea.
Authors
to
you
know,
follow
these
things
when
we
are
so
when
we
are
done
sorting
out
a
kind
of
a
pool
of
things
that
we
would
want
to
implement.
If
it
is
documented
there
much
easier
for
reference
and
implementation
would
be
simpler.
A
A
Okay,
that's
all
for
item
number.
Five,
all
of
micah's
comments.
Six
is
to
discuss
the
eip1
brainstorming
document,
which
one
is
okay,
that's
a
james
thing.
I
think
that's
james's
document,
that's
not
linked
here,
so
we
may
have
to
skip
this
one
yeah.
Let's
wait
until
james
comes
back
great
number.
Seven
clarifications
on
how
a
pre-compile
address
is
decided.
A
We
were
having
problems
at
a
core
eip
level
on
how
it's
unclear
when
there's
an
eip,
that's
a
core
eip
that
has
to
assign
a
pre-compile
addre
or
an
opcode
that
is
assigned
a
pre-compile
address.
How
to
assign
that
this
isn't
a
hard
one
to
solve.
A
As
long
as
the
core
developers
come
up
with
a
system
which
isn't
even
that
hard
because,
like
it
just
kind
of
goes
in
order
and
the
only
way
that
you
can
make
a
new
pre-compile
is
to
like
do
it,
you
could
put
it
wherever
you
want
in
this
huge
like
list
of
addresses
within
aetherium,
but
deciding
like
which
one
goes.
Where
is
the
is
the
question
I
think
we
just
discussed
in
the
core
dev
meeting
where
it
should
go,
and
they
said
yes
or
no.
A
So
I
don't
really
know
how
big
of
an
issue
this
is,
and
I
think
james
reflected
that
in
and
the
issue
in
ethereum
magicians,
if
you
click
on
the
link
and
then
martin
commented
that
the
final
state
of
pre-compile
addresses
might
be
good
to
include
in
a
hard
fork
meta
if
any
pre-compiles
are
added-
and
I
agree
with
that-
there's
some
list
floating
out
there
of
where
of
the
pre-compiles
and
some
of
them
are
updated.
A
A
A
Problem
sounds
good
and
then
the
last
item
on
the
agenda
is
review.
Previous
decisions
made
from
the
eip
improvement
proposal
call
notes
so
decision
item
9.1.
The
eip
process
flow
will
be
separate
from
hard
fork.
Coordination,
9.2.1,
rename
the
status
of
eip1
active
to
living,
9.2.2,
rename
inactive
to
stagnant
9.2.3,
no
name
change
for
final
status,
9.3
discussion
to
be
continued
on
eip
number
registry
process
and
9.4
a
medium
blog
to
share
the
final
eipip
survey
report
will
be
published
on
friday.
A
Did
9.4
happen.
I
think
that'd
be
edson.
B
Yeah,
so
I
think
it's
actually
shared
in
the
agenda
number
three
so
there
I
could
repeat
that
again.
It
was
just
three
different
phases
that
we
could
work
on.
First
is
decision.
Making,
second,
is
clarification,
and
third
is
onboarding,
so
formal,
like
the
specifications,
are
formal
and
clarity
can
be
with
the
process
to
participants
or
within
the
eips
itself.
B
But
you
can
look
through
that
article
be
helpful
to
reference
for
every
meeting
yeah.
But
those
are
all
the
results
from
the
survey.
A
Okay,
that's
all
the
decisions
made
in
the
summary
there's
that
link
in
item
number,
eight
to
review
the
items,
action
items
and
the
notes
from
the
previous
meeting.
If
you're
interested
very
well
done,
notes,
it's
like
a
transcript
more
than
notes
and
that's
the
last
item.
Are
there
any
other
items
that
people
have
to
bring
up
or
want
to
propose
for
the
next
meeting.
H
H
I
do
like
the
fact
that
there's
a
it
seems,
there's
there's
a
a
effort
to
continue
to
lower
the
barrier
of
entry,
and
I
think
one
of
the
biggest
blockers
for
me
being
a
part
of
any
sort
of
process
has
been
there's
just
so
much
so
much
information,
asymmetry
and
so
many
things
going
on
all
the
time
that
if
it's
not
a
low
enough
barrier-
and
it's
not
immediately
in
my
face-
it's
just-
it's
not
going
to
be
seen.
So
I
think
that
is
a
good
effort
to
continue.
A
A
Yeah
yeah
we
should
one
decision
was
that
we
should
have
generous
use
of
labels
when,
in
the
prs
for
eips,
once
things
get
going.
E
C
And
a
pre-compile
address,
it
was
again
suggested
by
james.
So
do
we
want
to
see
that
on
the
next
agenda
next
meeting
when
james
is
on
on
on
here,
but
or
should
we
drop
that.