►
From YouTube: EIPIP Meeting 81
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/232
A
Welcome
to
eipip
meeting
81
I
have
shared
agenda
in
chat.
Today
we
have
a
few
items
to
be
discussed
from
issues
and
pull
requests.
Those
are
new
and
one
from
the
past
discussion
meeting.
We
will
go
ahead
with
eaps
Insight
update
and
EIP
editing
office
hours
update,
starting
with
the
first
item,
which
is
to
discuss
open
issues
and
pull
requests.
Here
we
have
proposal
6953,
which
has
recently
been
added
as
a
informational
EIP
to
the
repository
I.
A
Suppose
the
question
that
was
being
asked
in
this
PR
is
which
direction
we
would
like
to
move
in.
Should
we
move
ahead
in
the
direction
of
making
this
proposal
as
living
or
we
should
move
in
the
direction
of
making?
This
proposal
to
final
Tim,
unfortunately,
could
not
join
the
meeting,
but
he
has
left
his
comment
suggesting
that
he
may
not
have
very
strong
opinion
in
either
direction,
but
a
weak
preference
going
towards
final
I'll
be
curious
to
hear
what
EIP
editors
think
and
what
is
the
recommendation
for
author
here.
B
I
think
living
proposals
are
very,
very
rare.
I
think
we
only
have
two
so
I'd
prefer
if
we
went
in
the
direction
of
like
this
is
a
list
of
all
the
transition
specifiers
up
to
today,
and
then
that
can
go
to
final
and
then
when
there's
a
new
one
introduced,
it
can
require
the
previous
one
and
introduce
the
new
one
and
I
think
that
would
probably
be
the
the
most
eipip
or
EIP
friendly
way
of
doing
it.
C
C
Therefore,
final
seems
to
be
what
he
intended
to
the
the
good
characterization
of
his
intended
status.
A
C
There's
just
one
thing
can
I
also
bring
to
the
attention
of
the
other
EIP
editors
that
this
is
categorized
as
informational
I,
wonder.
Is
it
more
of
a
meta
or
informational
one?
If
it
talk
about
mechanisms,
that's
binding.
B
C
So
core
core
EIP
so
activating
for
half
what
used
to
be
one
of
the
main
use
case
for
MATA,
and
here
this
one
talk
about
activation
mechanisms
and
if
it's
binding
seems
to
fall
into
the
same
category.
So
in
the
context
using
that
as
using
category
I
was
I,
think
it
seems
to
or
more
on
the
matter
side,
but
I'll
also
be
open
to
other
approach.
Information
is
totally
fine,
but
it
just
made
this
not
as
strong
as
it
actually
are.
B
Yeah,
so
it
it
if
a
new
proposal
were
to
come
along
with
a
different
activation
mechanism,
I,
don't
think
we
would
stop
them
from
using
it
like
if
so,
I
I,
don't
think
it's
strictly
a
meta
proposal,
but
it
also
could
be
a
core
proposal
since
technically
core
proposals
are
anything
relevant
to
core
Dev
discussions
and
I
think
we
can
argue
about
this
in
circles
forever.
I,
don't
care
if
we
just
want
to
put
our
thoughts
on
the
pr
I'm.
Okay
with
that.
C
B
A
I
think
that's
fine,
yeah
I
I
would
like
to
be
sure.
Like
Sam
did
I
get
you
right.
You
are
also
suggesting
to
move
it
in
the
direction
of
being
final,
because
going
through
the
proposal
it
looks
like
we
are
trying
to
record
the
activation
timestamp
for
all
the
upgrades
and
my
assumption
is.
It
could
have
future
upgrades
timestamp
added
to
the
proposal
as
well.
A
Okay
and
it
seems
to
be
I-
mean
in
my
mind,
like
the
way
I
am
reading
the
proposal
right
now.
It
seems
to
me
more
informational
than
meta,
because
this
has
already
happened
in
the
past
and
it
is
just
a
documentation
of
something
that
has
happened
in
the
past,
but
not
that
is
something
to
come
up
to
suggest
any
change
either
to
the
ethereum
protocol
or
to
the
EIP
process.
So
I
Believe
by
the
definition
of
meta
EIP.
It
is
probably
not
qualifying
to
be
added
as
meta,
but
it's
going
more
towards
information.
D
Yeah
I
think
we
can
remove
the
table
of
the
hard
folks
of
the
mainnet,
because
I
mean
that's
what
not
PR
title
anyway
says
it
says
what
are
the
types
of
hard
folks
that
are
there
in
ethereum
so
anyway,
this
information
is
stored
somewhere
else
in
ethereum
Gate
repositories,
Maybe
a
reference
to
that
git
repository
could
be
made
over
here.
D
A
All
right,
so
probably
what
we
can
get
from
this
call
is
like
people
are
in
agreement
for
moving
it
to
the
review
status
and
probably
moving
in
the
direction
of
final.
There
could
be
some
changes
required
in
the
proposal
and
that,
if
someone
can
leave
in
the
comment,
so
author
can
follow
and
do
the
needful.
A
Thank
you
all
right,
very
well.
Moving
on
to
the
next
one
is
an
issue
which
suggests
that
unlicensed
code
should
not
be
allowed
to
be
included
in
any
proposal.
I
believe
this
discussion
is
again
stamped
with
the
discussion
of
copyright.
Like
what
kind
of
information
we
can
add
to
the
documentation
of
proposal,
and
the
proposal
here
is
suggesting
that
copyright
sentences
should
not
be
added,
element
should
not
be
added
to
the
EIP
and
we
should
be
including
a
license
fee
like
cc0
should
be
there.
A
So
we
should
not
have
things
like
that,
I
wonder:
do
we
have
any
kind
of
documentation
anywhere
in
eip1
or
anywhere,
which
suggests
this,
and
we
can
share
this
with
authors,
so
they
can
not
do
this
mistake
if
this
is
a
mistake
or
I
suppose
there
is
another
question
that
is
coming
up
from
this
issue
is:
can
we
have
a
bot
check?
Is
that
possible.
B
Yeah
so
there's
a
PR
for
this
for
license
Checker
I'm
just
trying
to
find
it.
Now
there
is
a
yeah
there.
It
is.
B
There
is
a
bit
of
a
disagreement
between
myself
and
Panda
I
think
we
should
allow
any
open
source
license
that
doesn't
impose
restrictions
on
on
Downstream
implementation,
so
we
could
allow
Apache,
MIT
and
a
few
other
ones,
but
not
GPL
and
panda
is
of
the
mind
that
we
should
only
allow
cc0
but
regardless
we
definitely
should
turn
on
the
license
checker
for
to
prevent
unlicensed
bits
of
source.
There's
the
poorer
question
chat.
A
Five:
three:
seven:
nine,
that's
good
to
know
that
we
already
have
a
pull
request
for
that
license.
Checker,
but
again,
is
it
covering
all
sort
of
licenses
or
only
cc0.
C
Yeah
I
left
a
comment
in
September
2022.
My
position
is
that
I'm,
okay
of
requiring
any
assets
to
be
put
in
EIP
repository
as
cc0
coming
from
a
author
and
implementer
background
myself.
I
also
want
to
give
authors
other
authors
and
implementers
the
options
to
not
doing
so
by
allowing
linking
from
asset
page
from
assets
to
file,
because
it's
very
hard
for
people
to
put
an
Assets
in
this
very
strict
license
requirement,
while
also
allowing
them
to
reference
to
it.
So
we
could
either
relax
our
link
policy
to
allow
linking
to
implementation.
C
That
is
less
that
that
is
less
open
or
we
can.
We
can
not
require
the
cc0
for
assets,
but
not
likely.
If
we
do
both.
It
basically
damages
the
ability
for
authors
to
be
open,
more
open
to
share
the
and
share
those
work
with
us.
B
It's
not
just
whether
we
can
distribute
it
question
right,
like
I,
we
could
distribute,
for
example,
GPL
code,
and
it
would
be
not
a
problem
for
the
eip's
repository,
but
a
reference
implementation.
That's
GPL
as
an
example.
There
are
other
kinds
of
licenses
that
would
also
be
a
problem,
but
a
reference
implementation,
that's
GPL
in
facts,
the
downstream
projects
that
they
also
have
to
be
GPL.
So
if
we
allow
reference
implementations
that
are
like
non-free,
so
you
can
see
the
source
code,
but
you
can't
use
the
source
code.
I,
think
I.
B
Think
Maria
DB
has
an
example
of
that
license,
or
maybe
I,
don't
remember.
What
are
the
database
projects
has
an
example
of
that
where
you
can
look
at
the
source,
but
you
can't
use
it
like.
Those
kind
of
licenses
are
not
useful
in
a
reference
implementation
because,
like
they're,
basically
a
copyright
trap
for
for
implementers
and
I.
Don't
think
we
want
to
encourage
that
so
I'd
be
against
allowing
any
license.
That
is
that
that
imposes
restrictions
on
Downstream
implementations.
C
So
I'm
I'm,
totally
with
you
on
those
since
is,
could
potentially
be
a
copyright
trap
and
if
we
include
them
in
our
distribution,
that
could
be
that
that
that
could
cause
those
problems.
We
could
be
affiliate,
facilitating
these
kind
of
trap.
My
argument
is
that,
however,
we
should
be
allowed
not
Distributing
them,
but
reference
to
them
like
create
a
reference
link
to
them,
for
example,
in
our
current
policy,
if
we
only
restrict
to
cc0,
people
would
not
even
be
able
to
link
to
go
ethereum
as
a
reference.
C
Implementation
would
not
be
able
to
put
go
into
ethereum
code
to
the
repository
as
a
reference
implementation
now
I'm
totally
with
you
that
we
should
not
put
go
ethereum
code
into
into
the
EIP
Repository
and
redistribute
it
because
it's
on
GPL
license,
but
I
think
we
should
give
author
the
freedom
instead
to
point
to
other
code.
That
already
exists.
That
has
massive
adoptions,
as
reference
invitation
to
say,
hey
by
the
way.
C
C
Think
there
is
this
implied
difference
that
I
and
you
you
seem
to
hold
with
me-
can
I
verify
that
with
you
that
when
you
say
reference
imputation,
you
assume
that
people
is
gonna
copy
and
use
that
that's
the
main
use
case
for
reference
implementation,
where
I
think
reference
reference.
Implementation
is
only
to
show
how
it's
done
and
then
majority
of
the
people
will
decide
whether
they
want
they
want
to
go
down
the
same
route
or
re-implement
it
in
a
different
way.
Is
that
a
difference
that
I
implied
to
is
that
a
good?
B
It's
close
so
I
see
Anyone,
who
reads
the
reference
implementation
and
writes
a
new
program
as
creating
a
derivative
work
of
the
reference
implementation,
which
is
an
incredibly
old-school
legal
view
of
software
development,
but
a
lot
of
companies.
You
know,
don't
let
their
employees
look
at
GPL
code
for
exactly
that
reason.
So
there
there
is
an
argument
to
be
made
that
looking
at
a
for
example,
GPL
reference
implementation
will
force
all
like
derivative
implementations.
So
anything
that
uses
a
similar
kind
of
you
know.
Programmer
algorithm
is
in
the
reference.
C
I
think
that's!
None
of
us
are
legal,
legal,
expert
and
I.
Think
you
make
your
point.
It's
I,
I
I
do
know
that
that's
one
school
of
thoughts,
there's
also
another
school
of
thoughts
that
says
hey.
This
doesn't
seem
like
a
copyright
infringement
and
this
doesn't
seem
like
a
patent
protected
in
under
patent.
So
it's
okay
to
look
so,
but
yeah
I
don't
know.
Maybe
we
should
consult
someone
who
has
their
expertise.
C
My
point
here
is
that
if
we
hold
difference
in
this
way,
wouldn't
it
be
okay
to
revisit
the
link
policy
to
say
you
eat,
otherwise
you
wouldn't
be
able
to
let
people
put
reference
implementation.
So
my
strong
position
is
that
we
should
let
people
share
reference
with
implementation
as
much
as
possible,
because
otherwise
it
doesn't
matter,
it
doesn't
make
sense
and
doesn't
help.
We
advance
the
open
organ
open
standardization.
C
B
C
Yeah
I
think
that's
a
good
direction
to
go,
I
seems
to
be
agreed
by,
and
I
also
want
to
saw
that
the
gay
and
Greg
based
hand
so.
E
B
We
have
so,
let's,
let's
bring
this
back
to
the
actual
discussion
at
hand.
Somebody
accidentally
committed
code
with
the
unlicensed
spdx
identifier,
which.
D
B
E
Is
there's
I
think
we
should
have
a
general
policy
that
we
prefer?
We
prefer
proposals
that
have
actually
been
implemented
and
those
actual
implementations
May
well
be
GPL
to
proprietary.
You
know,
otherwise,
not
something
we
would
want
to
publish,
but
preventing
someone
from
linking
to
a
working
implementation
does
not
help
the
quality
of
The
Proposal,
but
I'm
quite
happy
to
take
things
one
case
at
a
time,
rather
than
try
to
make
up
a
rule
in
advance.
E
A
E
C
Yes,
so
one
example
that
I
can
think
of
I
I
should
probably
follow
find
links,
because
we
don't
let
link
is
there
were
authors
who
attempt
to
link
to
go
ethereum
which
is
currently
the
most
adopted
executive
I?
Don't
need
to
explain
to
you,
but
maybe
audience
who
are
watching
the
recording
and
it
was
rejected
on
the
ground
that
we
don't
allow
link
to.
C
We
don't
allow
links
to
Outsider,
VIP
and
other
approved
sources,
but
let's
assume
instead,
they
want
to
put
those
files
into
our
EIP
app
repository
under
a
slash
assets.
It's
not
allowed
because
go
ethereum
is
under
lgpl
and
therefore
even
one
of
the
most
adopted
clients
would
not
be
able
to
be,
and
also
supported
by
ethereum
foundation,
with
grants.
It
would
not
be
able
to
be
put
in
the
EIP
repository,
and
that
is
one
of
the
example
of
what
this
two
rules
together
will
prevent
from.
E
Can't
go
in
the
repository,
but
a
link,
a
link
to
a
you
know
to
a
link
to
the
relevant,
commit
hash,
and
that
should
be
acceptable
for.
B
B
All
right,
so,
let's
I,
think
the
license
discussion
is
a
much
bigger
topic.
Perhaps
we
should
open
a
discussion
thread
on
which
licenses
we
want
to
allow,
but
I
think
we
can
all
agree
that
we
don't
want
to
allow
unlicensed
code
in
the
EPS
repository.
Is
that
correct.
D
B
We
don't
want
authors
accidentally
sending
code
that
they,
they
shouldn't,
be
sending
so
I'm,
going
to
make
a
recommendation
that
we
turn
on
license
Checker
and
but
we
make
it
very
Broad
and
we
allow
everything
except
unlicensed.
A
Like
to
share
something
here,
I
recently
was
in
a
conversation
with
the
author
of
5773
I
think
he
suggested
a
very
good
idea
in
which
we
can
probably
share
reference
implementation,
if,
even
if
we
are
not,
including
that
in
the
part
of
proposal,
so
what
they
did
is
like.
They
came
up
with
this
an
npm
package
for
their
code
having
reference
implementation
and
shared
it
with
one
of
the
hacket
and
I
think
there
was
some
ZK
related
hackathon
going
on,
so
they
shared
with
the
participants
and
they
were
using
it.
A
So
when
they
are
using
the
package,
they
may
have
to
pay
the
license,
but
if
they
do,
if
they
don't
want
to
pay
the
license,
they
can
definitely
go
to
the
the
specs
that
is
specified
in
the
EIP
and
make
use
of
that
and
implement
the
proposal.
So
I
am
assuming
here
that
there
is
a
way
out
that
we
will
be
able
to
share
multiple
reference
implementation
by
not
making
them
a
part
of
the
standard.
The
repository
in
standard
we
just
mentioned
the
specs,
which
should
be
generic
and
be
available
for
everyone.
C
If
I
may
shamelessly
promote
this
effort
that
I'm
promoting,
which
is
an
open
source
effort
to
allow
authors
to
contribute
their
reference,
implementation
of
erc's
and
and
it
will
be
in
a
npm
package
which
we
currently
packaged
in.
So
if
anyone
is
watching
this
and
think
it's
a
good
idea
to
share
your
reference
invitation,
please
do
and
also
we
want
to
know
how
to
us
get
how
to
license
this
as
well,
currently
allow
CC
by
zero.
C
But
we
are
on
defense
of
whether
we
want
to
be
due
license
or
triple
license
so
that
it
can
maximize
the
chance
to
be
accepted
in
any
repository,
because
cc0
by
cc0
is
meant
to
be
close
as
close
as
possible
to
public
domain.
If
I
understand
it
correctly,
but
now
that
it's
given
a
name
is
no
longer
considered
as
fully
compatible
with
Pablo
domain.
It
seems
to
me
in
some
of
the
cases,
so
we
don't
know
how
to
be
as
even
broad
as
possible
than
cc0.
C
A
All
right,
I
think
we
can
take
us
at
Sam's
suggestion
here
that
for
this
particular
issue,
that
is
there,
there
should
be
a
bot
and
the
pull
request
is
already
there.
A
So
we
can
go
ahead
and
do
that
activate
the
bot
and
we
should
open
a
thread
on
Fellowship
of
ethereum
Edition
to
discuss
which
kind
of
licenses
should
be
allowed
with
this
bot
Checker
like
the
license
checker,
and
we
can
probably
have
elaborated
discussion
when
we
get
some
more
feedback,
because
in
this
closed
group,
I
think
we
have
repeated
on
this
discussion
multiple
times.
A
Okay,
so
yeah
I
I
think
we
should
have
that
as
a
summary
for
this
issue
7027
and
let's
move
on
to
the
next
one.
So
there
are
oh,
please
go
ahead,
correct.
A
Okay,
so
the
next
items
that
we
have
here
are
edits
to
final
EIP.
So
there
are
two
proposals:
eip4955
and
4804.
Both
are
in
final
status
and
we
have
received
a
pull
request
to
make
a
small
edits
to
it.
So
taking
the
first
one,
which
is
PR,
6937
I,
wonder
what
editors
think
should
we
go
ahead
and
merge
that
PR
or
we
can
let
the
proposal
know
that
we
cannot
make
any
changes,
because
this
proposal
is
already
in
final
status.
B
It
needs
one
more
so
I
think
the
way
it's
set
up
right
now
is
to
edit
a
final
EIP.
It
requires
author
and
two
editors,
so
if
one
other
editor
for
I
think
it's
ERC,
yeah
ERC,
so
that'll
be
Greg,
Matt,
myself
or
Panda.
What?
If
you
could
approve
it'll.
D
C
I
added
I:
do
it
I,
don't
know
if
it
approved
it
and
then
it's
definitely
gonna
be
EIP.
Validator
blogs,
but.
B
Yeah
I
I
I'll,
merge
it
I
just
need
I
want
to
follow
the
process.
Yeah.
A
Yeah
we
can
get
one
more
approval
if
we
have
plenty
of
editors
here.
So
if
one
first
can
add
profile,
then
that
can
be
much
perfect.
B
B
B
Yeah,
so
this
is
so
resolve
mode
always
had
two
modes.
It
just
didn't
say
what
the
return
values
were.
B
B
B
D
D
E
B
So
I'm
only
aware
of
one
implementation
of
it
and
it
it
would
have
only
returned
one
of
these
two
values,
but
it
would
break
a
theoretical
implementation,
but
I
don't
know.
If
that's
you
know
important
or
not,.
E
E
B
So
I
guess
I
think
I
think
the
safer
option
for
everybody
would
be
to
make
a
new
EIP.
So
maybe
we
ask
the
author:
if
they're
willing
to
and
if
they're
not,
then
we
revisit
this
discussion
again.
Yeah.
E
A
The
two
things
that
we
can
take
out
from
this
conversation
here
is
like
probably,
we
need
some
policy
around
Errata
and
one
suggestion
that
Sam
mentioned
about
an
option
for
author
to
move
from
final
to
withdrawn,
because
as
of
the
current
process,
that
is
not
possible
withdrawn
and
final.
Both
are
the
terminating
statuses
and
we
do
not
have
any
connection
over
there.
So
if
it's
okay,
we
can
go
with
like
more
discussion
on
either
of
these
policies,
and
maybe
we
can
bring
it
in
future
meeting,
but
for
this
particular
pull
request.
A
A
E
E
That
that
would
be
my
preference,
if
that
is
agreeable
to
the
author,
because
I
think
producing
whole
new
eips
gets
confusing
people.
Remember
the
numbers
associate
them
with
the
EIP,
and
this
isn't
like
such
a
big
change,
and
it's
not
a
breaking
change,
especially
it
just
isn't
going
to
break
anything.
B
B
E
Do
your
best
to
find
out-
and
you
make
the
change
at
which
point
if
anybody
follows
the
older
version,
they're
making
a
mistake.
E
I'm
not
hard
over
on
this,
it
just
a
whole
new
EIP
for
a
few
words,
and
the
few
words
are
only
there
to
document
how
it
actually
does
work
seems
overboard
yeah
at
the
other
end,
a
change
that
actually
would
break
existing
code
requires
a
new
new
EIP,
so
that
people
can
continue
to
follow
the
old
EIP
and
not
break
their
code.
E
It's
just
just
like
you
continue.
You
can
continue
to
conform
to
an
older
version
of
a
language
standard,
the
old
standards
still
there
and
still
a
standard.
It's
just
no
longer
the
current
standard,
I.
B
E
A
A
I
do
not
see
panda
on
the
call
and
I'm
not
sure.
If
anyone
else
has
any
information
about
the
EIP
number
brought,
do
we
have
any
progress.
I
remember.
In
the
last
meeting
we
discussed
that
we
started
but
has
to
be
stopped.
A
A
A
I
suppose
this
is
the
last
chance
to
add
any
kind
of
addition.
If
they
have
any
suggestion
for
the
author
proposals
are
erc5570,
the
last
call
deadline
has
passed,
it
was
yesterday
and
other
proposals
are
ERC,
5169,
client,
script
URI,
but
obviously
the
deadline
has
crossed.
So
if
author
did
not
receive
any
kind
of
suggestion,
they
can
go
ahead
and
create
a
pull
request
to
make
it
into
the
final
status.
A
And
there
is
this
recent
added
proposal,
which
is
the
ERC
5008,
which
I've
entered
into
last
call
recently,
and
the
last
call
deadline
here
is
June
1st,
so
people
listening
to
this
call,
if
you
have
any
thoughts
about
any
of
the
proposals
listed
here
in
this
MD,
for
the
changes
of
suggestion.
This
is
the
last
call
for
you
as
well.
Please
go
ahead
and
suggest
that
to
author,
because
we
would
try
not
to
make
any
changes
to
final
proposal,
as
you
may
have
heard
in
our
earlier
conversation
and
yeah.
A
That's
all
from
the
eits
insight.
We
did
have
EAP
editing
office
hour
yesterday.
It
was
really
great.
We
saw
a
lot
of
new
Authors
joining
our
call
trying
to
understand
the
process.
Many
thanks
to
Sam
Wilson
for
organizing
this,
like
for
leading
this
and
explaining
answering
questions.
I
can
understand.
Sometimes
it
can
be
overwhelming
coming
so
many
authors,
but
we
didn't
get
chance
to
look
into
all
I
believe
there
are
four
or
five
open
items
that
were
not
covered
in
the
past
meeting
any
of
the
editors
on
the
call.
A
If
you
get
a
chance,
please
take
a
look
at
that,
so
we
should
be
able
to
close
it
before
the
next
meeting,
but
for
new
Authors
who
are
trying
to
draft
a
proposal
and
have
any
kind
of
question
with
respect
to
other
process
documentation
and
they
are
trying
to
understand
because
it
is
their
first
time.
Please
join
us
on
the
EIP
editing
office
hour.
We
hopefully
be
able
to
help
you
out
and
you
can
propose
your
proposal
as
a
standard.
A
That's
all
about
item
number,
four
and
I'm
just
quickly.
Taking
a
look
from
this
summary
of
the
past
meeting
in
the
past
meeting
I
thank
God,
yeah,
so
EIP
part
numbering
we
already
discussed
panda
is
not
on
the
call
today.
So
we
can,
let
it
be.
The
bug
with
5507
was
response,
so
it's
covered
and
a
reviewer
working
group
of
Williams
sorry
Victor
shared
something
yeah,
some
sorry
I,
suppose
I.
B
Know
yeah,
so
one
feedback
item
I
received
from
the
core
devs
is
that
we
aren't
giving
them
enough
opportunity
to
provide
feedbacks
and
some
changes.
B
One
of
them
is
the
suggestion
to
not
number
EIP
drafts
and
only
assign
them
a
number
when
they
move
to
review
so
they're
asking
if
we
can
provide
meeting
summaries,
Somewhere,
In,
The,
Ether,
D
Discord,
but
not
in
the
all
core
devs
Channel
yeah.
So
just
so
you
know
I'm
going
to
be
posting
an
update
there
after
this
call.
A
A
A
B
So
I
think
it
could
work
if
we
it
like
yeah,
like
I'm
kind
of
torn
on
this,
like
being
able
to
have
a
number
as
soon
as
there's
something
merged
is
really
nice
and
you
can
refer
to
it
right
away,
but
on
the
flip
side
it
would
probably
encourage
people
to
move
to
review
faster,
which
is
kind
of
the
point
of
the
review.
B
Like
you
really
shouldn't
be
implementing
a
draft
EIP
because,
like
it
hasn't,
it
might
not
even
be
fully
written
yet
so
if
we
make
it
so
that
drafts
are
unnumbered,
authors
might
be
encouraged
to
move
to
review
sooner,
which
might
be
a
good
thing.
I,
don't
know.
I
haven't
made
up
my
mind
on
this,
yet
myself.
A
But
I
think
this
is
gonna
have
like
you
know
another
kind
of
discussion.
What
would
be
the
the
EIP
number?
Should
it
be
the
pr
plus
some
wordings
and
and
obviously
in
this
either
bot
has
to
do
or.
E
A
I,
if
I
remember
correctly,
according
to
the
process,
the
network
upgrade
process
that
they
follow.
If
a
proposal
isn't
draft
or
review
that
can
be
proposed
for
consider
for
inclusion
like
whether
accepted
or
not.
So
that
is
a
separate
discussion,
but
that
can
be
proposed
even
if
the
status
is
draft.
A
And
I
somehow
agree
like
a
Greg
what
Greg
mentioned.
If
we
enforce
having
EIP
number
at
the
review
status,
then
the
draft
status
would
be
as
good
as
the
idea
was
earlier.
So
now
people
do
not
think
of
idea.
They
just
make
a
draft
now,
eventually
they
will
just
come
up
with
idea,
and
that
would
not
be
an
idea.
That
would
be
a
draft
and
the
draft
would
be
the
review.
E
E
B
Tell
yeah
no:
they
they
just
want
a
number
to
talk
about
it.
It's
it's
Panda,
Micah
from
back
in
the
day
and
myself
a
little
bit.
Who
is
toying
with
the
idea
of
not
having
a
number
at
a
draft,
but
if
the
the
view
is
overwhelmingly
that
we
want
numbers
I'm
totally.
Okay,
with
that
too,.
E
E
Yeah,
it's
it's
just
what
it
is.
It's
how
we
operate,
but
we
purposely
have
low
standards
for
drafts,
because
we
don't
ever
again
want
to
get
dragged
into
political
and
legal
issues
about
whether
we
should
or
should
not
have
published
a
draft.
A
A
E
Get
ourselves
out
of
the
loop
for
that
arrest,
the
original
yeah
originally
getting
a
draft
into
this
system
was
a
purely
editorial
function
and
partly
automated.
So
it
it
wasn't
a
big
legal
issue
up
front.
So
there's
a
reason
not
to
impose
too
much
on
getting
things
into
draft
stage.
A
Okay,
I
think
we
have
good
context.
Probably
that's
a
discussion
Point.
Whenever
panda
is
around,
we
will
try
to
bring
it
up
on
the
eipip
meeting,
how
we
would
like
to
design
the
EIP
number
and
aggregate
status
it
should
be
provided
when
Bart
would
start
allocating
yeah
I,
think
that
is
also
we
can
make
it
optional.
That's
another
good
suggestion,
yeah
okay,
so
if
I
get
it
correct,
Sam,
you're,
gonna,
post
a
summary
to
the
Eid
r
d,
Discord
Channel
at
EIP,
sorry
yeah,
EIP,
editor,
Channel,
whatever
it
is
yeah
all
right,
awesome
cool!
A
C
Yeah,
if
I
may
mention
that
the
thanks
poja
and
thanks
many
e
editors
who
helped
we
had
a
first
ERC
Dev
call
yesterday,
it
was
quite
good
I
think
the
pier
we
start
to
sense
the
few
some
Sentiments
of
peer
review.
We
get
people
suggesting
each
other,
that's
a
great
start
and
just
want
to
say
a
big
thank
you,
but,
and
and
also
look
forward
to
have
you
join
next
time.
C
I
think
poja
will
present
when
she
is
ready
and
then
also
Sam
I,
already
put
you
on
the
on
sharing
the
WTF
for
next
time,
as
featured
topics
so
yeah.
If
any
other
suggestions
for
how
it
could
be
run
or
who
should
who
can
come
to
talk?
That
would
be
great
and
also
feel
free
to
point
authors
of
eic's
to
this
venue
if
they
want
to
seek
peer
reviews.
A
C
Right
I
shared
it
on
Discord,
I
shared
on
Twitter
and
the
the
repository
meeting
notes
as
well.
So
thanks
so
much
for
also
helping
out
with
the
recordings.
A
You're
welcome
very
well.
Thank
you
so
much.
We
have
two
minutes.
If
anyone
has
any
final
comments
to
add.
C
C
Yeah
I
just
want
to
mention
that
I
do
presented
a
proposed,
a
status
change,
the
criteria
for
erc's,
it's
it's
on
ethereum
magician,
a
post
I
want
to
talk
about
it
next
time
sign
up
and
but
for
editors,
I
love
to
get
your
attention
and
maybe
comment
on
it
before
next
time.
So
I
can
present
it
to
you
and
walk
to
you
too
and
get
feedback.
Thank
you.