►
From YouTube: EIPIP meeting #30
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/62
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
A
This
item
was
discussed
in
the
previous
meeting
and
hudson
created
an
issue
for
this,
where
he
kind
of
summarized
discussion
so
far:
michael
further
added
gold
and
potential
solutions
and
major
road
blocker
for
today's
discussion
that
we
would
like
to
resolve
so
the
goal
mentioned
there
is
a
separate
notification
system
for
erc
editors
and
subscribers
and
eip
editors
potential
solutions,
separate
github
repositories
that
we
discussed
in
the
earlier
meeting.
A
So
people
can
watch
on
the
only
one
repository
or
both
if
they
would
like
to
the
problem
that
we
discussed
was
a
numbering
system.
So
I'm
trying
to
open
the
floor
for
any
other
comment
or
suggestion.
A
Can
we
just
start
from
the
goal
like
how
to
separate,
or
do
we
actually
want
to
you
know?
Is
there
any
other
way
for
a
separating
notification
system.
A
So
if
we
take
a
like
yeah,
please
go
ahead.
Micah.
C
I
think
my
preference,
I
think,
I'm
sorry,
let
me
meet
my
phone,
my
preference
is
so
when
you
say
duplicate
numbers,
you
mean
like
having
an
erc1
like
starting.
C
So
what
about
people
who
do
naming
conventions
where?
Because
like
erc20,
is
technically
eip20
and
like
there's
some
eips
that
are
erc's
but
are
not
referred
to
as
ercs,
but
they
are
ercs.
B
So
we
don't
have
to
worry
about
collisions
the
other
direction,
because
the
eip
started
out
way
ahead.
Well,
we
don't
have
to
worry
about
collisions
the
other
direction
anytime
soon,
because
eip
is
already
up
to
like
what
is
it
three
thousand
five
hundred
or
something
and
it'll
be
a
while
before
yet
ercs
catch
up
assuming
they
do,
I
don't,
and
by
and
when
they
do
catch
up,
they
will
be
called
ercs,
not
eips,
because
we'll
have
super
repo
and
also
ever
process
whatever,
and
so
not
too
worried
about
that
particular
problem.
B
C
Yeah,
that's
kind
of
where
I'm
at.
I
think
we
should
start.
We
should
just
pick
a
mid
number
or
starting
at
a
certain
like
3000
whatever
and
just
go
up
from
there,
where
there's
ercs
and
eips
separate
and
they
can
overlap.
I
think
that'd
be
my
my
solution.
B
If
we
want
to
do
that,
I
think
we
would
need
to
either
come
up
with
a
new
mechanism
for
choosing
numbers
which
is
fine
or
someone
write,
a
script
that
will
burn
through
issue
number
one
through
3500
in
the
erc
repo.
C
B
Could
too
hard
to
run
through
all
the
numbers?
I
don't
think
I
don't
think
I
get
rate
limited
it's
like
a
day
or
two
on
a
script.
A
So
I
was
wondering
like
in
the
last
meeting
we
also
discussed
about
you
know
having
a
separate
repo
for
erc,
but
opening
you
know
just
issue
section
in
the
eip
report
so
that
we
do
not
have
the
overlap
and
we
do
not
have
to
go
back
to
number
one.
I
was
wondering:
do
we
find
any
any
issue
with
this
proposal
like
maybe
to
implement
this?
A
My
recommendation
would
be
to
discourage
people
from
using
the
issues
of
eip
repo
to
open
it
for
eip
discussion
and
like,
as
we
were,
also
encouraging
people
to
open
an
issue
in
the
fellowship
of
ethereum
magician,
so
we
will
going
forward.
Maybe
we
will
keep
the
issues
section
only
for
erc's
to
grab
a
number
that
way.
We
will
never
be
in
conflict
with
the
eip
number
and
we
will
not
disturb
whatever
has
been
done
till
date,
like
whatever
ercs
or
eips
were
there.
We
will
not
be
disturbing
that.
B
That
would
not
resolve
it
would
not
resolve
our
problem
of
subscriptions
because
you
didn't
generally
subscribe
to
a
whole
github
repo,
or
at
least
I
do.
I
don't
think
you
can
subscribe
to
just
issues
or
just
prs,
like
you
described,
subscribe
to
the
repo
or
not.
B
I
think
just
writing
a
script
that
burns
through
issue
number
one
through
3500
on
the
erc's
repo
is
probably
the
easiest
and
it
sounds
like
it
satisfies
most
people.
The
biggest
problem
there
is
is
finding
someone
to
write
it.
Maybe
we
can
get
elita
to
do
it.
She
sounds
interested
in
picking
up
some
work,
pretty
easy
script
right.
D
Okay,
sorry
about
mike
wasn't
working.
I
I
still
really
feel
like.
We
should
not
have
conflicts
between
the
ips
and
ercs
and
I'm
not
you
know,
tied
to
one
certain
way
of
doing
that.
I
think
the
two
ways
that
we
talked
about
are
a
a
spreadsheet
or
something
some
central
source,
or
we
could
do
it
have
another
repository
where
you
create
an
issue
to
get
a
a
number
and
then
that
way
that
always
is
happening
sequentially
and
then
they
just
post
a
link
to
say
hey.
I
request
my
number
here.
This
is
my.
D
D
I
think
that
people
generally
use
you
know
refer
to
their
eeps
and
ercs
by
their
number,
and
there
are
many
famous
numbers
and
it
would
be
bad
to
have
an
erc,
1559
or
you
know,
an
erc
2718,
and
you
know,
as
editor
sure
we
can
kind
of
try
to
avoid
those
things
from
happening.
But
I
just
don't
think
that
that's
you
know
a
really
good
solution
for
for
what
we
want.
D
I
think,
like
long
term,
even
I
I
this
may
be
crazy,
but
I
kind
of
think
we
could
really
move
away
from
eips.
I
actually
thought
about
this
last
couple
weeks.
I
don't
even
I
don't
think
eips
themselves
actually
make
much
sense,
and
so
then
we
would
just
kind
of
be
stuck
with
erc's
and
then
that
we
wouldn't
have
this
issue
of
numbering
as
as
much.
C
D
One
ethereum,
and
so
it
doesn't,
you
know,
in
my
mind,
make
a
lot
of
sense
to
have
lots
of
lots
of
eips
that
you
kind
of
like
understand
in
a
piecewise
fashion.
There
should
just
be
a
single
specification
that
you
understand
as
one
unit,
and
I
think
like
on
the
longer
term.
That
would
be
a
much
better
way
of
going
about
proposing
network
changes.
If
we're
putting
prs
against
the
specification.
B
Yeah,
you
have
my
vote.
The
hard
thing
I
think,
is
going
to
be
convincing
like
migrating
everything
to
that
and
getting
the
initial
specification
up,
like
I
mean
that's
probably
half
a
year
to
a
year
of
work,
just
to
get
the
initial
spec
yeah.
D
I
think
yeah
I
mean
it's
something
just
to
kind
of
keep
in
mind.
There's
someone
who
I
believe
is
going
to
be
working
on
a
spec
in
the
not
too
distant
future.
B
D
A
So
if
I
understand
this
correct,
like
the
suggestion
of
separating
the
reaper,
we
want
to
keep
it
on
hold
for
some
time
and
as
you're
expecting
somebody
to
start
working
on
it
and
then
we'll
have
a
better
picture
of
it.
B
B
Yeah,
so
from
given
engineering
resources,
there
are
a
number
of
solutions
to
this,
so
one
is
just
to
make
a
if
there's
a
bot
on
both
repos.
It
just
checks
for
collisions
like
as
part
of
the
merge
process,
just
to
make
sure
we
don't
merge,
collisions
that's
one
way.
Another
way
is
a
little
tiny
little
web
app
that
runs
somewhere.
B
B
Okay,
did
you
guys
get.
E
B
So
basically
saying
given
engineering
resources,
there
are
a
number
of
solutions.
This
problem
one
would
be
to
have
a
merge
bot
sitting
on
both
the
rfc
repo
and
the
ip
repo
that
just
make
sure
anytime.
There's
like
you,
sign
a
number
just
like
normal
and
if
there's
a
conflict,
it'll
adjust,
the
bot
will
tell
you
and
you
can
give
another
one.
B
So
that's
a
simple
solution
that,
if,
if
we
have
engineering
resources
to
spend
another
one
little
tiny
web
app,
it
just
gives
out
numbers,
and
we
can
just
ask
it
for
a
number
via
some
mechanism.
Maybe
only
editors
of
the
two
repos
can
do
so
so
that
way,
someone
just
doesn't
click
the
button
over
and
over
again.
So
I
think
the
problem
is
easier.
If
we
have
engineering
resources
allocated
to
it,.
A
Yeah,
I
think
for
this.
If,
if
there
is
a
solution-
and
I
know
alita
is
available
and
she
showed
her
interest
in
working
towards
it.
So
if
this
is
something
that
we
think
of
like
a
priority
amp,
I
think
the
cat
had
us
would
be
happy
to
fund
this
thing
and
get
it
fixed
for
the
solution
we
need
for
the
time
being,
I
mean
like,
maybe
before
march,
whatever
the
eip
process,
we
are
following.
B
Yeah,
I
don't
actually
care
that
much
about
how
the
numbers
are
picked.
I
have
like,
like
I
said,
my
preference
is
very
weak.
I
would
rather
just
get
things
moving
then
spend
another
two
weeks
debating
it.
So
whatever
people
want
whatever
gets
the
ball
rolling.
A
B
A
A
Yeah,
I
think
one
last
thing
I
have.
I
just
want
to
make
a
quick
mention
of
that
that
we
are
working
on
securing
funding
for
eip
and
erc's
adidas
as
well,
like
we
mentioned
earlier,
that
it
would
be
helpful
to
hire
more
people,
but
funding
was
an
issue.
Now
we
are
looking
into
that
respect.
May,
if
not
in
this
meeting,
maybe
in
the
next
meeting.
If
we
could
discuss
an
estimate
of
how
much
funds
would
be
needed
for
three
to
six
months,
that
would
be
helpful.
A
And
I'm
expecting
the
present
editor's
input
for
this,
because
I
think
those
people
can
give
us
a
fair
idea
and
we
would
be
just
people
to
arrange
resources
and
funds.
B
Quick
quick
note
before
we
close
out
this
topic,
the
someone
should
probably
look
at
the
rc's.
I've
been
auto
archiving
them
for
our
last
conversation
and
they're
starting,
I
have
noticed
they're
starting
to
pile
up.
D
D
B
It's
not
good,
you
could
just
get
it,
get
a
saw
and
cut
off
half
your
space
bar
and
then
lay
your
thumb
in
this.
In
the
gap
there
we
go.
A
Okay,
so
if
that's
it
on
this
item,
I
will
discuss
further
in
the
next
meeting
about
the
next
steps
that
we
kind
of
agreed
upon
in
this
meeting.
Moving
on
to
the
next
item,
it's
a
json
rpc
api,
spec
support
needed
for
coordination
and
funding.
A
couple
of
weeks
ago
we
organized
peep
and
e
for
ap
147
for
json
rpc
spec
there.
We
realized
that
such
spec
need
not
to
be
following
the
standard
eip
standardization
process
and
should
not
live
on
eip
repo.
A
Tomas
has
been
leading
the
json
rpc
spec
calls
where
all
parties
joined
to
discuss
this
standard
spec
and
in
the
last
meeting,
as
well
as
in
the
json
rpc's
last
meeting,
it
was
discussed
to
make
e1.0
repository
the
placeholder
for
these
specs,
thanks
to
mass
for
joining
us
today
to
discuss
how
we
can
provide
support
that
is
needed
for
this
chance
to
move
forward.
A
Unfortunately,
I
don't
see
eric
and
sam
richards,
the
other
two
participants
who
we
have
contacted
for
this
issue.
The
mask:
can
you
would
you
like
to
go
ahead
with
the
summary
that
you
have
mentioned
in
the
comment
for
reference.
H
Hi
yeah,
thanks
for
invitation
and
I'll,
be
happy
to
share
some
summary
of
the
last
two
or
three
months
of
calls
with
the
various
teams,
including
the
client
developers.
They
library
implementers,
like
the
libraries,
integration,
libraries,
implementers,
the
tooling
implementers
and
so
on.
So
we
started
by
analyzing
whether
json
or
pc.
H
Api
should
be
more
of
a
change
in
suggestion
of
changes
or
simply
a
spec
of
existing
thing,
and
there
is
a
very
clear
agreement
that
what
we
care
about
is
the
spec
and
to
deliver
the
very
detailed
information
about
all
the
mostly
used
json
rpc
items,
and
one
important
outcome
of
this
course
was
that
we
no
longer
would
like
to
approach
it
from
the
perspective
of
the
entire
json,
rpc
or
modules.
Because
that's
the
level
of
view
where
the
most
differences
appear
that
are
not
necessarily
differences
that
cause
trouble
to
the
user
so
like.
H
H
But
if
we
look
at
single
endpoints,
like
eth
block,
number
or
eth
call,
those
are
widely
used
implemented
in
all
the
clients,
and
this
is
where,
on
the
low
level,
the
specification
is
missing
and
our
initial
view
was
that
some
way
of
specifying
each
of
those
endpoints
separately
in
a
most
formal
and
ethereum
style
way
would
be
good
and
we
picked
eip
processes
the
the
way
to
go.
However,
recently
I
was
suggested
on
those
calls.
That's
within
eip
ip
goals.
H
You
had
the
vision
of
moving
things
to
the
spec
repositories
for
ethereum
one
and
potentially
ethereum
two,
and
this
is
totally
fine
and
if
you're
asking
about
the
support,
I
think
that
all
these
people
that
are
willing
to
work
on
actual
spec,
preparing
the
details
of
endpoints
and
finding
out
those
such
cases
and
describing
them
would
benefit
from
from
some
help
on
just
just
arranging
that
properly
and
organizing
that
within
repository,
that
would
that
would
follow
the
style
of
specification
that
you
picked
for
all
the
other
items
within
ethereum,
so,
like
the
the
exact
form,
is
not
the
most
important
for
us.
H
What
we
would
like
to
achieve
is
ensuring
that
it's
complete
on
each
endpoint
level
and
it's
every
single
endpoint
is
separate.
So
so
that's
we
do
not
have
the
spec,
which
is
a
single
document
for
all
the
end
points
that
is
not
a
spec
that
is
separate
document
for
each
module,
but
it's
actually
a
spec
where
you
can
clearly
separate
and
independently
edit,
every
single
endpoint
within
json
rpc
again
explaining
that
by
endpoint
we
mean
here,
I
think,
like
a
single
method.
H
Eth
block
number
with
different
potential
parameter,
setups
the
of
the
modules
that
are
in
question,
so
the
eth
module
is
the
one
for
which
the
end
points
are
mostly
used
and
most
important
and
where
we
can
get
some
immediate
gains
by
just
simply
specifying
one
by
one.
Some
of
those
like
block
number
like
call
estimate
gas,
the
ones
that
are
used
over
and
over,
that's
called
because
of
their
complexity
and
wide
usage
and
many
different
users
asking
for
additional
functionality,
improvements,
changes.
H
They
ended
up
being
slightly
different
in
different
clients
and
what
else
so
one
more
outcome
of
those
conversations
was
that
we
do
want
to
have
the
some
technical
way
of
describing
formal
way
of
describing
the
cips
is
well
something
that
would
at
least
defined
interfaces
in
a
way
that
alice
for
automatic
code
generation
or
automatic
verification
of
the
api
being
implemented
by
the
given
client
or
not.
And
that's
that's
where
there
was
wide
agreement
that
open,
rpc
format
can
be
reused.
H
This
is
something
that
was
initially
created
within
the
domain
of
ethereum
classic,
and
I
believe
that
zachary
belford
is
ready
to
help
here
with
writing
this
part
of
the
spec.
So
we
think
that
every
single
endpoint
will
be
the
description
that
will
define
what
clients
do
now
and
if
there
are
any
discrepancies,
it
will
suggest
how
they
should
be
resolved,
but
also
there
will
be
a
technical
part
which
we
say.
H
Oh,
this
is
the
this:
is
the
formal
spec
following
the
open
or
pc
standard
that
you
can
use
to
write
tools
to
generate
tools
then
also,
I
know
that
ethereum.org
wanted
to
be
hosting
that
information,
so
that
would
be
great
if
that's
automated
in
some
way.
So
this
info
is
not
over
time.
It's
not
being
updated
on
any
of
the
sites,
whether
it's
spec
or
ethereum.org,.
H
And
also
when
think
about
eip1474,
which
was
like
the
the
first,
probably
the
most
successful
attempt
so
far
to
do
json
rpc
specification
that
one
is
approaching
json
rpc
as
the
whole,
but
but
it
also
provides
all
those
basics
of
explaining
what
the
types
like
quantity
or
block
number
block
graph,
and
so
on
data
are
so
we
we
still
need
the
basis,
so
we'll
still
need
to
explain
those
basic
r
repeatedly
used
types,
and
we
think
that
maybe
something
like
that
can
be
introduced
almost
like
a
both
as
a
basis
that
those
endpoint
specific
documents
can
refer
to,
but
also
something
that,
in
the
end,
can
actually
gather
the
links
to
all
of
those
endpoints
and
create
a
way
to
navigate
between
them.
H
A
So
I
was
looking
into
some
conversation
on
the
discord
channel
and
there
was
this
mention
of
creating
a
folder
and
they
eat
one
respect
people.
So
how
do
you
guys
want
to?
You
know,
proceed
in
that
direction
like
getting
access
to
that
is
okay,
or
is
there
a
defined
group
who
would
be
reviewing
the
pr
and
we
can
manage
it
on
our
end?
Do
you
have
any
thoughts
on
that
part.
I
H
Think
this
part
we
don't
have
very
formally
specified,
so
I
think
that
there
should
be
reviewers
for
each
of
those
and
then
it
should
include
at
least
all
the
client
developers
saying
developers
from
all
the
clients
represented
saying:
oh
yeah.
This
is
correct,
as
for
the
current
state
of
things,
whether
they
should
be
formally
having
access
to
that
repo
or
just
simply
submitting
prs
and
making
comments
via
standard
github
interfaces.
It's
an
open
question.
H
B
I
think
having
a
finite
number
of
editors
who
are
just
familiar
with
the
process
is
valuable.
It
keeps
people
from
accidentally
merging
or
thinking
they've
gone
through
the
process
correctly,
and
then
they
just
merge
and
it's
too
soon
or
there
was
an
agreement.
H
Yes,
I
think
that
we
would
like
to
suggest
on
one
or
two
people
that
would
be
actually
writing
the
spec.
If
you
think
that
you
can
that
you
have
someone
that
you
can
suggest
for
that
role,
so
eric
eric
suggested
zachary's,
I'm
not
sure.
If
that's,
I
assume,
that's
with
zachary's
knowledge,
that's
how
it
sounded
in
the
email
and
if,
if
there
can
be
one
more
person
involved
in
actual
writing
and
writing
the
spec
and
contacting
people,
then
I'll
be
very
happily
helping
to
to
just
get
connected
to
all
the
client
teams.
H
All
the
tooling
teams
for
these
reviews-
and
I
can
be
in
that
process
like
on
on
decision
making
on
when
it's
ready
to
merge,
just
because
I
think
that
I
remain
the
person
that
that's
actually
connecting
all
those
teams
and
deciding
what
is
what
is
the
common
agreement
around
bertie
gerstberg.
H
And
everyone
else
can
be
just
reviewer
or
if
you
suggest
that
there
should
be
more
people
that
will
actually
reach
out
to
every
single
client.
As
I
please
suggest
this
one
person
that
would
be
familiar
with
this
and
would
be
ready
to
add
documentation,
photos
back
and
be
responsible
for
communication
within
the
team.
A
So
I
think,
to
begin
with
creating
a
folder
in
each
one
or
spec.
Repo
should
not
be
a
challenge.
We
can
go
ahead
and
create
that
folder
and
if
you
would
want
to,
you
know,
write
the
first
initial
documentation
for
this.
That
would
be
great
and
on
the
development
part,
as
we
mentioned
that
maybe
resource
is
needed.
Actually,
I
was
approached
by
someone
to
kind
of
fund
these
kind
of
activities.
A
H
So
I'd
like
to
underline
that
funding
actually
is
not
not
an
issue
here,
it's
more
about
finding
the
people
that
are
ready
to
work
specifically
on
writing
with
all
the
support
of
actual
resolving
the
the
questions.
Finding
answers
to
the
questions
of
how
the
things
what
should
be
described.
H
So
it's
this
like,
maybe
a
bit
more
entry-level
task,
there's
a
person,
that's
that
is
exploring
this
rpc
or
works
more
like
with
json
or
pc,
but
not
exactly
as
a
developer
of
the
of
the
implementation
and
it's
ready
to
work
with
developers
and
ask
questions
for
for
clarification.
Work
with
me
and
ask
where
some
additional
input
is
needed.
A
Sounds
good?
We
will
try
to
spread
word
around
this
for
the
requirement
and
if
we
have
someone
we'll
send
it
to
you,
what
what
are
the
thoughts
of
other
people
here
unless
like
having
the
access
and
a
folder
on
each
one
inspect
ripple.
C
A
So
yeah
for
the
next
steps
we
I'm
gonna
go
ahead
and
create
the
folder
for
json
rpc
spec,
and
we
can
start
working
on
it
tomas.
If
you
would
like
to
start,
you
know
kind
of
the
first
thing
they
read
me
or
the
documentation
that
is
needed.
We
can
start
from
there
and
see
how
different
clients,
collaborate
and
try
to
add
stuff
there.
Does
that
sound?
Okay
to
everyone.
H
C
A
Eap
template
sounds
fine
to
me
because
it
is
not
living
on
the
eap
repository.
I
don't
think
it
should
be
an
issue
here.
It
can
be
in
any
way
that
is
preferred
and
easy
to
maintain.
Obviously
we
are
expecting
it
to
be
updated
with
the
help
of
pull
requests.
So
whatever
template
we
may
decide
on,
the
first
should
be
okay,.
I
B
So
if
it
was,
if
it
was
me
which
is
not,
I
would
actually
model
it
off
of
these
2.0
specs
repo
rather
than
eaps.
B
I
believe,
if
you
take
a
look
at
their
repository,
they
basically
have
markdown
files,
which
are
just
specifications
like
they
don't
have.
You
know,
motivation,
sections
and
rationale
and
security
considerations.
They
just
have
a
spec
and
it
makes
it
a
lot
less
wordy
a
lot
faster
to
iterate
on
and
generally
just
easier
on.
Everybody.
J
I
think
also
worth
noting
that,
when
the
merge
happens
or
before
the
merge
happens,
we're
gonna
want
to
merge
those
actual
those
actual
repos
so
doing
stuff.
That's
you
know,
in
line
with
the
e2
specs
repo
is
probably
future
proof,
as
I
suspect
you
know,
the
e2
specs
repo
is
much
more
fleshed
out
than
the
e1
specs
repo.
So
that's
probably
the
one
that
will
will
model
everything
off
of.
H
Yeah,
I
think
from
from
my
perspective,
this
is
one
thing
that
I
would
need
the
most
support
with
like
just
be
very,
very
clear
on
when
it
should
land.
This
feels
very
vague
since
that
last
meeting,
when
we
were
said
that
when
we
were
told
that
eap
is
not
a
good
place,
it
feels
like
we
are
suggested
not
to
use
the
ap,
but
there
is
no
clear
information,
maybe
or
where
to
go.
H
J
A
B
The
idea
there
is
just
that
over
time
we
have
the
beacon
client,
which
will
have
its
own
set
of
public
facing
interfaces,
we'll
have
the
application
client,
which
has
instead
of
public
facing
interfaces.
Some
of
those
are
json
rpc.
Some
of
those
are
rest.
I
think
it
would
be
good
to
just
kind
of
from
an
organizational
standpoint.
B
J
G
J
And
the
only
small
thing
so
right
now,
I'm
looking
at
the
east
one
specs
repo
and
it's
really
focused
around
network
upgrades
and
whatnot
like
the
main
readme.
So
I
can.
I
can
update
that
like
once
once
we
have
the
pr
for
json
rpc,
I
can
update
the
readme
to
just
make
it
a
bit
more
general
and
mention
that
you
know
network
upgrades
are
only
one
of
the
things
that's
being
tracked
here.
A
Okay,
I
think
if
we
are
good
on
this
part,
we
can
go
ahead
for
the
next
topic
and
obviously
I'm
gonna
connect
with
you
to
mass
offline
and
see
if
there
is
anything
needed
more.
A
Moving
on
the
next
topic
on
the
agenda
is
eips
and
network
upgrade
process
requirement.
There
is
an
issue
linked
to
this
item,
so
we
discussed
this
item
in
the
last
meeting,
and
people
seem
to
be
in
agreement
offer
the
format
that
that
I
proposed
in
the
comment
section
like
when
it
is
cfi.
It
is
in
draft
when
it
is
dotnet
it
would
be
for
review
and
the
mainnet
phase
it
will
be
last
call
eaps
will
be
marked
as
final
only
if
it
is
deployed
on
the
main
net.
A
Jim
has
left
a
couple
of
comments,
so
on
that
part
he
mentioned
about
removal
of
the
testing
green
light
thing,
and
instead
of
that,
he
suggested
to
add,
I
mean
reword
it
differently.
I'm
trying
to
find
out
my
issue.
J
Yeah,
I'm
looking
for
the
issue
right
now,
but
basically
the
testing
green
light
phase
does
not
exist
like
so.
There
is
no
testing
green
light,
so
I
don't
think
it
makes
sense
to
have
that
and
then
yeah,
I
think,
the
time
to
move
eips.
The
last
call
is
when
we
agree
on
a
list
of
eips
for
a
hard
fork
like
we
don't
want
them
to
be
already
on
the
test
net.
We
want
to
say
like
look.
This
is
the
london
art
fork.
It's
eeps
one.
C
So
that
would
mean
the
devnet
phase
here,
I'll
post
the
issue
the
devnet
could
be
review.
Devnet
would
go
into
public
test
net.
Then.
A
So
yeah,
I'm
also
in
total
agreement
that
the
eip
green
light
doesn't
does
not
make
much
more
sense
here.
So
we
can
simply
remove
that
section
and
yeah,
I'm
fine
with
that.
So
what
basically
we
are
saying
is
like
when
it
when
it
is
in
cfi,
then
only
it
will
be
in
drafter
review
when
it
moves
to
devnet.
It
has
to
be
in
review
or
last
call.
C
C
Okay,
okay,
I
was
under
the
impression
that
last
call
meant
changes
can
go
in
because
usually
people
don't
look
at
it
until
last
call,
but
if
enough
people
want
to
if
the
definition
is
different
than
how
I'm
thinking
about
it,
I'm
I'm
cool
with
that
and
we
can
go
ahead
and
make
last
call
like
really.
This
is
the
final
time
to
look
at
it.
Instead
of
changes
can
go
in
and
I
guess
the
reason
why.
J
I'd
be
I
I
I
would
agree
with
you
in
theory,
but
in
practice
we
don't
even
move
stuff
like
we
didn't
move
the
eaps
for
berlin.
The
last
call
until
two
of
the
test
nets
had
already
forked
right
like
so
it's
still
a
net
improvement.
If
we
agree
to
move
at
the
last
call
when,
when
we
set
the
fork
blocks,.
C
As
long
as
the
definition
on
eip1
starts
to
say,
that
last
call
means
only
only
the
most
urgent
of
changes,
such
as
security
can
do
things
so
not
like
nominal
changes.
C
And
then
I
guess
the
other
piece
is.
Should
the
last
call
mean
the
same
thing
for
ercs
as
well.
C
J
The
definition
in
eip1
is
pretty
good
like
it
says
this
is
the
final
review
window
for
an
eip
before
moving
to
final
and
the
ip
editor
will
assign
last
call
status
and
set
a
review
end
date,
typically
14
days
later.
If
this
period
results
in
necessary,
normative
changes,
it
will
revert
the
eip
to
review,
which
I
mean
it's
general
enough,
that,
like
it
works
for
magnet
and
ercs.
C
B
So
it
just
means
once
it's
somebody's
final.
You
cannot
do
changes
that
change
the
the
meaning
of
the
document,
so
in
the
case
best
technical
specifications.
You
cannot
change
the
like
protocol
that
you're
working
on.
However,
you
could
make
an
edit
to
fix
a
typo
or
you
can
make
an
edit
to
improve
some
wording
or
something
like
that.
You
just
can't
change
the
the
content
itself
like
it
still
has
to
say
the
same
message.
B
B
J
J
I
think
we
all
have
like
an
agreement
based
on
you
know
the
core
devs
process
like
what's
necessary
and
what's
not-
and
it's
quite
murky,
to
define
beyond
that,
so
I'm
finding
it
pretty
general.
C
J
A
A
J
C
J
A
Sure
so
one
also
one
important
change
that
we
discussed
in
one
of
the
earlier
meetings
that
last
call,
which
was
for
14
days
only
this
is
not
going
to
be
14
days
only
it
is
minimum
of
14
days,
so
that
is
one
change
and
the
other
change
is
resting.
Green
light
has
to
be
removed
and
status
should
be
last
call.
A
G
D
Yeah
like
client,
so
I
was
wondering,
is
the
is
the
purpose
of
considered
is
cfi
kind
of
meaning
that
cordov
expect
that
to
go
into
a
hard
fork,
or
is
it
something
good
going.
J
J
So
I
just
put
up
an
issue
for
that
yesterday
on
this
connected.
D
D
J
So
my
point
of
view
on
this
is
so
much
context
changes
during
forks
that
the
stylus
should
probably
reset
every
fork
because,
like
otherwise,
we
end
up
carrying
a
bunch
of
old
eeps
as
cfi,
and
it
kind
of
doesn't.
C
J
Anything
anymore,
I
was
looking,
and
I
was
looking
yesterday
at
the
ones
that
got
basically
cfied
before
berlin
that
didn't
make
it
into
berlin.
And,
frankly,
you
know
they're
all
irrelevant
the
only
one
that's
relevant
is
at
2537
and
that
got
brought
back
into
berlin.
So
you
know
I
yeah
just
like
cfi
it
again.
So
that's
kind
of
my
I
guess
my
my
read
of
it
would
be.
It's
like.
J
You
know,
generally
positive
towards
having
this
in
the
upcoming
hard
fork,
and
you
know
that
doesn't
guarantee
inclusion
and
I
think,
by
default,
it
should
reset
between
forks
and
you
know
the
bar
for
for
it,
the
unreached.
You
know
to
become
cfi
again.
It's
just
somebody
stepping
up
and
saying
I
want
to
champion
this
for
this
fork,
so
it
doesn't
have
to
be
like
a
huge
bar,
but
at
least
we
know,
there's
still
some
interest.
J
We
know
that
the
proposal
is
still
relevant
because,
like
for
example,
you
had
2711,
which
was
sponsored
transactions
which
is
basically
superseded
by
3074
right
and
it.
B
D
Yeah
that
that
all
makes
sense,
I
think,
like
the
main
reason
for
asking
this,
is
that
you
know
my
experience
here
with
3074
has
kind
of
been,
and
I
think
this
is
like
something
that's
going
to
be
general
eeps
that
aren't
brought
by
you
know,
basically,
by
like
a
core
team,
is
that
you
know
you.
It's
really
important
to
have
people
look
at
it,
but
it's
really
hard
to
get
people
to
look
at
it
without
a
stamp
of
approval.
D
That's
going
to
a
hard
fork
or
like
some
sort
of
something
that
says
it's
beyond
just
a
spec
that
someone
came
up
with
last
week,
right
and
so
to
me.
It
felt
like
maybe
cfi,
is
that
thing
and
I'm
trying
to
understand
if
that
is
the
case,
where
you
bring
it
into
all
court
devs-
and
you
say,
here's
a
change
that
I
want
to
make.
I
want
to
champion
it
for
the
sport
and
cordev
say
yeah.
That
makes
sense.
D
We
could
see
it
go
into
this
fork.
Maybe
here
are
some
things
that
need
to
be
done
to
make
it
happen
like
you
need
to
have
some
support.
You
need
to
do
an
audit
whatever,
but
we'll
move
it
to
cfi.
That
way,
it
has
the
stamp
of
approval
that
you
can
go
to
the
community
and
say
look
is
this
something
that
court
does
like
are
are
amenable
to
having
in
the
fork.
I
need
support
from
the
community.
A
J
B
J
C
J
Went
the
other
way
around
because
we
kind
of
knew
1559
was
going
to
drive
the
fort.
We
and
1559
had
been
cfied
like
you
know
two
years
ago
or
something
so
like
1559
went
right
in
and
the
difficulty
bombed
as
well,
and
now
we
have
like
other
stuff
that
we're
looking
to
you
know
also
add
in
the
devnets,
but
we
haven't
made
a
decision
about
whether
they're
in
the
fork
or
not.
So
it's
yeah,
it's
a
bit
murky.
D
Yeah,
okay,
I
mean
it
seems
like
it's,
it's
how
I
was
understanding
it.
Maybe
in
the
future
we
can
have
like
a
little
bit
more
process
around,
but
you
know
see
if
like
when
something
is
cfi
like.
I
think
that
it
should
be
okay
for
something
to
be
cfi
if
it's
contingent
on
something
being
done
like
3074
is
kind
of
contingent
on
this
audit,
and
I.
D
A
Okay,
so
we
are
very
close
to
the
time.
We
have
one
last
item
that
we
quickly
want
to
check
on.
That
is
progress
on
canonical
source
for
eips.
E
Yeah
we've
got
a
staging
site
up
now.
E
I'm
gonna
paste
that
url
in
the
chat
thing
and
we
made
a
slight
change,
we're
still,
and
so
you
can
go
to
there
and
and
and
and
it's
a
mirror,
a
staging
mirror
and
and
so
we're
learning
how
to
modify
and
keep
that
up
to
date,
but
other
than
that
icon
up
on
the
top
of
the
page,
we
haven't
made
any
changes
yet
but
anyway,
making
progress,
that's
kind
of
slow
and
also
I
had
the
question:
how
are
changes
made
to
the
ethereum.org,
because
some
of
this
I
think
we're
going
to
want
to
get
some
changes
into
ethereum.org?
C
That
manage
or
with
ethereum.org
it's
an
open
source
repo
in
github,
so
you
just
do
a
pull
request
there
and
then
get
one
to
review.
It.
E
Oh
okay,
cool,
that's
right
and
do
you
guys
have
the
repository
for
that.
C
I
can
find
it
and
send
it
to
you,
but
I
think
it's
just
a
theory.
A
morgue.
A
Okay,
that
sounds
good.
The
last
item
is
discussing
about
earlier
decision
items
and
action
items,
so
I'm
just
gonna
quickly
run
over
it
so
see.
If,
if
we
missed
on
anything
cfi
draft
defnet
review
those
were
the
decision
we
already
discussed
it
today,
split
editorship
between
ercs
and
eips.
Without
this
separate
repos,
we
haven't
covered
the
editorship
part
yet,
but
we
did
some
discussion
on
the
splitting
of
the
area
pose,
allow
what
to
fail
if
it
was
going
too
much
to
be
turned
on
at
a
later
date.
B
So
on
that
one
we
need
in
order
to
turn
the
bot
on.
We
need
someone
with
admin
access
to
be
around
when
we
do
that,
and
so
we've
been
struggling
to
coordinate
with
the
admin
of
the
ips
repo
to
get
that
enabled
that's
the
number
one
hold
up
right
now,.
B
I
think
hudson's
an
admin
and
james
is
an
admin.
I
don't
know
who
else
twitch
repo
the
efp.
F
Oh
okay,
then
we'll
take
care
of
that.
Then
I
didn't
know
we
got
powers.
A
Cool,
so
we
got
it
solved.
The
next
decision
was
around
for
json
rpc,
so
we
we
discussed
it
today
create
a
new
repository.
That's
just
for
interface,
instead
of
migrating
to
e2,
specs
repo.
I
think
we
are
moving
in
a
different
direction.
So
that's
fine
and
action
items
deciding
on
number
system
between
erc
and
eaps.
A
I
am
not
sure
if
we
have
made
a
decision
on
that,
but
I'm
sure
alita,
light,
client
and
mica
can
be
working
on
that
and
we'll
see
I
mean
like
we'll
see
how
this
number
system
has
to
be
considered.