►
From YouTube: EIPIP meeting 32
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/67
A
Welcome
everyone
to
eibip
meeting
32,
so
we
are
trying
to
skip
the
first
agenda
item.
That
is
progress
on
erc's
repo.
I
do
not
see
lifeline
on
the
call,
so
maybe
we
can
come
back
to
this
item
later
on
number
two
item
listed
here:
should
we
care
about
people
making
statements
regarding
the
trademark
in
informational
eips?
I
I
found
that
in
a
comment
left
by
you,
michael
michael,
you
would
want
to
speak
more
to
it.
B
B
It's
fine.
I
just
need
to
reopen
it.
It's
all
right
closed,
so
the
someone's
writing
an
informational
eip
that
talks
about
the
proposing
the
appropriate
way
to
use
the
term
ethereum
mainnet
right
now,
it's
pretty
used
in
a
bunch
of
different
contexts,
a
bunch
of
different
ways:
they're,
basically
trying
to
clean
up
the
language
around
ethereum
when
you're,
like
speaking
or
when
you're
present,
presenting
or
writing
a
blog
post
or
whatever.
B
Just
this
is
kind
of
the
official
way
we
talk
about
the
ethereum
main
primary
network
and
that's
all
all
fine,
it's
informational,
ap,
so
not
particularly
stringent
on
the
requirements.
However,
there's
one
section
in
there
that
has
a
note
about
the
trademark,
apparently
ethereum.
The
word
ethereum
is
trademarked
by
the
ethereum
foundation,
and
so
it
mentions
that
trademark
and
references
it
and
indicates
that
it
just
it.
B
C
Yeah
sounds
like
a
big
red
flag,
like
I
guess,
to
add
more
cutter
there.
You
know,
I
think
the
ef
has
tried,
as
I
understand
it,
to
not
use
the
trademark
except
to
defend
against
scam.
So
one
of
the
big,
I
think,
probably
the
biggest
use
case
for
the
trademark,
is
when
there's
like
a
scam
youtube
account.
That's
like
an
imposter
for
the
ethereum
foundation
or
for
ethereum.
The
ef
needs
to
own
the
trademark,
so
that
youtube
takes
down
that
account.
C
B
So
so,
just
to
make
sure
that
we're
all
on
the
same
page
context-wise,
I
don't
want
to
miss
misrepresent
this
person.
The
let
me
just
read
the
text
here,
even
though
the
name
of
the
network
is
ethereum
mainnet,
which
is
what
the
cip
is
about.
It
will
be
necessary
for
your
application.
It
may
that
may
be
critical
here.
B
It
may
be
necessary
for
your
application
to
show
this
as
ethereum
like
a
little
r
circled
mainnet
and
include
a
note
like
ethereum,
as
a
registered
trademark
of
ethereum
foundation
elsewhere
for
more
information
on
your
obligations
on
mentioned
ethereum
trademark
c,
and
then
it
references
the
uspto
registration
number
and
the
note
at
the
bottom
of
the
terms
of
use
page
so
they're
not
making
strong
recommendations
like.
B
C
B
So
it's
the
follow-up
question
then,
if,
if
no
one
wants
to
argue
for
it,
I'm
weakly
against
it.
I
express
this
to
the
author.
They
seem
pretty
adamant
about
keeping
it
included.
So
my
normal
strategy
here
would
be-
I
don't
merge
it
and
leave
it.
Some
other
author
or
some
other
editor
to
merge
it.
Unfortunately,
I
don't
think
there's
any
other
editors
in
the
room
right
now,
so
that
means
this
will
be
one
of
those
eips
that
sits
forever
unmerged
and
that
feels
like
a
really
bad
way
of
doing
governance.
B
C
B
In
commenting
like,
if
they
are,
that
might
help
settle
things
and
just
move.
C
B
Forward,
if
not.
B
All
right,
so
what
I'll
probably
do,
then,
if
we
don't
hear
anything,
is
I'll
tell
the
author,
I'm
not
comfortable
merging
this
unless
that
trademark
section
is
removed,
however,
you
might
have
luck
contacting
the
other
eip
editors
and
seeing
if
they
want
to
merge
it.
I
believe
this
particular
author
has
run
this
problem
before
so
they
know
who
the
other
author,
the
other
editors
are,
and
so
maybe
one
of
them
will
merge.
A
Oh
yeah
yeah.
I
have
seen
that
the
author
has
made
quite
a
few
pull
requests
for
a
few
eips
and
have
been
an
author
for
yeah
because
that
has
been
you
know
in
in
the
final
stage
as
well,
so
yeah
I'm
expecting
that
he
may
have
some
visibility.
So
let's
wait
for
that.
A
Moving
on
the
next
item
on
the
agenda
is
progress
on
json
rpc,
api
spec
in
each
one
dot
or
repository.
I
see
elite
on
the
call.
I
believe
someone
from
the
team
also
joined,
but
I
can't
see
him
anymore
alita
if
you
have
any
updates
or
if
you
would
like
to
share
something
on
that.
E
Yeah
so
there's
progress
on
it.
I
recently
finished
east
call,
or
I
got
to
draft.
I
spoke
with
tomas
about
kind
of
my
involvement
and
stuff
and
tomas
appears
to
be
like
recommending
me
to
be
doing
the
project.
But
it's
not
super
clear
about
like
like
there's
no
like
official,
like.
E
Oh
I'm,
the
one
doing
this,
so
it
has
me
a
little
bit
not
sure
if
I
should
be
putting
in
too
much
time
into
it
or
whatever,
because
I
don't
want
to
you-
know
waste
time
but
yeah,
so
we're
kind
of
in
a
bit
of
a
of
a
place
that
is
sort
of
blocking
progress
in
a
sense,
because
I
kind
of
need
assurance
that
I'm
gonna
be
the
one
working
on
this,
but
to
follow
up
as
well
like
we
are
in
the
process
of
drafting
up
all
of
the
json
rpcs
and
prioritizing
the
ones
that
should
be
done
first.
E
I
know
I
mentioned
on
a
each
magician's
post
about
this,
like
about
which
ones
are
the
most
important
and
pertaining
to
eip1559.
E
So
I
guess
just
just
to
kind
of
like
summarize
a
bit
it's
going,
okay,
but
it's
challenging.
I
think
at
times
to
put
too
much
time
into
it,
just
because
I'm
not
like
the
official
person
working
on
it,
I'd
like
to
be,
but
there
could
also
be
other
people
that
would
like
to
so.
I
spoke
with
pujo
about
this
as
well
and
were
we
hopefully
posting
something
soon,
some
sort
of
thing
on
github
or
ech
medium
to
invite
comment
or
proposal.
B
In
my
experience
in
this
space,
if
you
just
start
doing
some
work,
that
no
one
else
is
doing
and
do
it
well,
no
one
will
challenge
you.
A
That
yeah,
I
have
shared
the
appears
that
have
been
submitted
by
alita
in
the
chat
it's
for
jason
rpc
api.
If
I
remember
correctly
in
one
of
the
earlier
meetings,
we
decided
that
we
should
be
providing
access
of
each
one
or
specs
to
maybe
to
mass
to
kind
of
have
the
you
know
permissions
to
merge
these
pull
requests
after
review
and
when
they
they
believe
that
this
is
ready
to
be
merged
in
the
repository,
I
am
yet
to
no
work
on
that.
A
I
have
received
his
email,
sorry
github
id
yesterday,
and
maybe
I'll
be
doing
it
today
and
yeah.
If
anybody
has
any
comments
on
that
on
the
pull
request,
it
is
there
one
thing
that
I
would
like
to
get
more
clarity
on-
and
I
have
mentioned
it
to
anita
and
tomas
earlier,
like
the
part
where
alita
is
mentioning
that
she
is
getting
the
urge,
like
not
clarity
on
what
to
do
when
to
do
it.
How
to
look?
A
I
mean
obviously
she's
having
some
pictures,
but
if
we
kind
of
create
issues
for
whatever
task
she's
working
on
and
we
keep
on
closing
the
issues,
I
think
that
will
give
us
the
visibility
that
she
is
working
on
these
particular
tasks
and
if
there
are
tasks
that
she
may
not
have
time
to
do,
and
if
you
would
like
to
invite
people
to
do
from
like
from
the
community,
we
can
do
that.
So
I
believe
the
post,
so
that
we
discussed
could
be
helpful.
E
I
think
it's
also
worth
a
plan
on
my
end,
which
is
like,
if
there
isn't
clarity
on,
if
I'm
gonna
be
the
one
officially
doing
it,
like,
I
don't
know,
say
like
by
friday,
because
that's
like
a
week
after
I
submitted
each
call,
I
think
I'm
just
gonna
kind
of
start
doing
it
just
cuz.
I
mean
I
know
that
it's
an
important
thing
I
like
to
you
know,
make
progress
on
it
so
yeah.
I
think
that
we
can.
We
can
definitely.
E
A
Yeah,
I
I
mean
I'm
not
sure
like
if
I
understand
correctly,
one
of
in
one
of
the
meetings
when
we
had
to
manage
on
the
call
we
discussed
that
you
would
be
making
full
requests
and
creating
issues,
and
that
would
be
reviewed
by
a
group
of
people,
maybe
from
client
teams
or
micah
or
whatever
the
group
you
have
created
on
discord,
maybe
and
then
only
one
person
from
the
team
would
be
having
the
access
to
so
I
mean
I'm
okay,
I
do
not
have
any
problem
doing
that,
but
yeah.
A
I
I
think
getting
some
clarity
on
that
would
be
helpful.
E
So
the
reason
that
I
want
the
right
access
is
so
that
way
I
can
create
branches
off
of
the
repo
itself
and
because
it
makes
life
a
lot
easier
for
me.
As
far
as
emerging
is
concerned,
I
mean
I
think,
that
you
can
trust
that
I'm
not
gonna
merge
something
without
approval.
E
A
Yeah,
I
don't
forget
that
please
bring
me
your
github
id.
I
think
that
should
be
fine,
that
is
written.
A
Okay,
moving
on
the
next
item
is
progress
on
canonical
source
of
eips.
I
have
added
the
link
for
wip
document
that
is
created
and
maintained
by
brent
alpha.
I
believe
that
you
have
some
progress
on
that.
F
Yeah,
I
basically
wanted
to
so
I
I
missed
the
first
item
where
we
talked
about
progress
on
creating
a
new
erc
repository.
So
and
so
do
we
have
some
people
that
are
going
to
make
that
er
a
separate
erp
repository
or
what
was
the
decision
on
that?
Actually.
A
We'll
skip
that
we
are
going
to
come
back
later
because
we
received
a
message
from
lifeline
that
he
would
be
late.
I
mean.
F
B
F
A
F
B
F
B
F
So,
in
other
words,
it
sounds
to
me
like
then
so
on
the
eip
eips.ethereum.org
we
have
tabs
for
all
and
for
core
and
meta
and
all
that,
but
there's
also
one
for
erc.
So
do
we
want
to
leave
that
tab
there,
but
when
you
click
on
it,
go
to
the
other
repository
or
something
like
that
or.
B
F
Making
that
yeah
just
link
out
yeah
have
someone
maintain
a
whole
erc
repository
and
stuff
like
that,
so
any
I
guess
that's
my
question
is:
where
do
is
there
any
way
we
can
expect
someone
to
do
all
of
that
extra
work?
I
guess
is
my
question.
F
F
B
F
B
Erc's,
not
ethereum.org
or
whatever
it's
just
and
that'll,
be
like
a
link,
and
we
just
put
it
like
at
the
end.
We
rearrange
it.
So
it's
at
the
end
of
the
list,
instead
of
the
middle,
just
make
a
little
more
clear
that
it's
external,
maybe
put
a
little
external
link,
icons
next
to
it
or
something
I
don't
know.
F
Okay,
great
sounds
good,
so
there's
also
the
other
talk
of
moving
towards
a
model
that
the
ether
two
has
where
we
just
we.
It
sounds
like
we
wanna
the
talk.
There
was
completely
get
away
from
ercs
and
just
have
pull
requests
against
the
the
the
python
script
and
stuff
like
that
is.
Do
we
want
to
worry
about
any
of
that
right
now
or
or
is
that
future
stuff
or.
B
B
The
feedback
I've
gotten
from
just
core
devs
and
whatnot
also
seems
kind
of
generally
positive,
and
so
I
think
it's
one
of
those
things
that,
like
everybody,
kind
of
agrees,
yeah
that
would
be
nice.
That's
a
good
idea,
but
the
effort
involved
in
getting
to
like
mvp
for
it's
like
the
very
first
version
that
we
can
launch,
is.
B
F
Okay,
so
so
let
me
see
if
I've
got
it
all
right,
then
so
so
we
are
gonna
continue
on
as
planned
and
we're
going
to
leave
room
for.
If
we
can
find
some
resources
to
split
out
erc's,
we
will
hopefully
do
that,
but
for
the
time
being,
we'll
just
keep
on
working
with
what
we
got
and
and
I'll
keep
working
in
that
direction.
B
This
sounds
about
right,
yeah
ercs,
I'm
pretty
sure
at
this
point
are
going
to
be
extracted.
It's
just
a
question
of
when
the
rest
of
it
is
is
very
much
more
in
the
air
and
questionable.
B
B
C
C
It
pretty
clear
on,
like
the
actual
ethereum
network
page,
that
this
has
changed
right,
because
one
big
problem
we
had
when
we
moved
say
like
the
hard
fork
mellows
out
of
the
eips,
is
now
nobody
can
find
the
specs
for
the
hard
forks.
So
I
think
we
want
to
be
pretty
like
explicit,
where
this
stuff
is
moving
to.
C
Even
you
know,
like
I
agree
like
having
the
link
there
is,
is
good,
but
also
just
having
probably
a
note
or
like
a
warning
at
the
top
of
eepson
ethereum.org
that
says
hey
if
you're
looking
for
ercs.
This
is
the
right
place.
C
I
suspect,
if
we
do
that,
we
probably
still
will
keep
core
eips
as
like
the
way
to
define
those
changes,
maybe
because,
basically,
what
what
the
python
spec
would
be
is
you
know
the
current
spec
as
is,
but
when
you
propose
an
idea,
it's
not
gonna,
be
part
of
the
spec
right
it'll,
be
something
that's
like
separate
from
it,
and
you
know:
there'll
still
be
debates
about
what
gets
included
and
what
not,
and
it's
probably
very
messy
to
have
those
live
and
just
like
open
pr's
to
this
bank
and
that
are
not
merged.
C
So
I
would
not
be
surprised
to
have
something
where,
like
you
have
the
python
and
then
once
an
eip
is
accepted.
You
just
open
a
pr
against
the
spec
and
actually
update
it,
or
you
only
open
a
pr
per
hard
fork
or
something-
and
you
say
you
know,
this
is
like
the
changes
for
london,
which
is
kind
of
what
etude
does
right.
Yeah.
A
F
Okay,
that
makes
sense
so
so
basically
it
sounds
like
then
so
there's
still
we
there
will
still
be
some
kind
of
proposal
for
eips,
but
but
there'll
be
a
clear
gate.
So
that's
all
ahead
of
of
a
decision
being
made
and
then
once
it's
accepted,
then
the
pull
request
is
done
and
then
it's
officially
pulled
into
the
spec.
Is
that
something.
B
C
Anything
it's
like
a
very
naive
assumption,
given
the
amount
of
given
the
ratio
between
the
proposed
eips
and
the
merged
vips
right,
like
we
have
more
proposals
than
we
have
things
that
go
into
hard,
forks,
so
yeah
and
to
be
clear,
I
don't
think
that's
been
decided
but
yeah.
It
feels
like
it
would
be
very
weird
to
have
like
100,
open,
pr's
against
the
spec,
and
then
we
picked
the
top
five
of
those
and
then
the
rest,
just
like
I
don't
know,
gets
closed
or
something
it
seems
odd,
but
yeah.
It's.
B
Not
like
that,
out
of
curiosity,
what
makes
that
odd
to
you,
like,
whatever.
C
So
the
fact
that
there's
no
like,
I
guess,
artifact
after
right,
like
take
trunk
pal
just
to
you,
know,
take
something
that
didn't
get
in
that's
important.
C
What
do
you
do
with
like
the
frog
pal
pr
after
you
know
it's
not
in
london
exactly
whereas
now
you
know
the
eip
is
still
there
and
I
think
that's
kind
of
good
that
there's
like
a
long-term
artifact
to
it,
and
that's
I
guess,
that's
like
a
political
one,
but
there's
also
the
case
where,
like
eip
was
at
2200,
which
supersedes
in
other
eips
and
whatnot,
so
when
eips
start
building
off
of
each
other,
it
feels
also
cleaner
to
link
like
an
actual
thing
than
to
link
like
this
pr
supersedes
this
pr
and
whatnot
like
it's
not.
B
That
says,
if
fork
block
less
than
x,
this
is
the
rule
else
yeah
this
rule
kind
of
thing,
and
so
we
would
still
retain
the
history
aspect
for
the
the
prague
pow
and
similar.
I
mean
there's
a
lot
of
programs,
one
example.
There
are
many
here
right,
vips
that
are
proposed
and
they're
reasonable
and
they're
generally
good
ideas,
they're
well
thought
out
and
they
deserve
to
exist,
but
they're,
not
part
of
ethereum.
I
think
that's
the
class
that
I
think
we're
talking
about
here
for
those
ones.
B
My
personal
view
is,
I'm
not
opposed
to
just
leaving
them
open
pr's.
There
is
from
a
management
standpoint.
We
have
to
make
sure
we
don't
get
the
position
where
we're.
We
can't
manage
all
the
opr's,
but
I
think
with
github
labels.
We
can
handle
that
pretty
easily,
and
just
say
like
this.
This
eip
is
like
considered
for
inclusion
label
would
make
it
so
you
can
filter
and
see.
B
Okay,
what's
actually
being
considered
right
now,
instead
of
all
the
things
and
then
things
that
are
like
explicitly
like
were
considered
but
rejected
would
have
maybe
another
label,
so
you
can
filter
those
out
easily,
and
so
I
feel,
like
my
gut,
tells
me,
which
my
gut
here
is
very
weak
on
this,
but
my
I
weekly
feel
like
we
can
make
it
so
having
hundreds
or
thousands
of
open
pr's
is
not
unmanageable.
As
long
as
we
have
a
good
system
in
place
for
managing
that.
F
Oh
okay,
so
yeah,
I'm
guess
I'm
having
troubles
understanding
the
difference
between
what
mike
and
tim
are
saying.
It
sounds
like
micah,
both
micah
and
tim
want
to
split
apart.
There's
the
governance
part
where
things
are
being
proposed
and
people
are
trying
to
get
people
on
board
and
then
there's
the
bridge.
When
someone
something
finally
gets
accepted,
then
a
pull
request
is
done
and
officially
makes
it
into
the
spec.
B
So
the
difference
is,
is
what
I'm
proposing
is
that
we
as
soon
as
someone
has
an
idea
for
a
change
to
the
spec
they.
A
B
Open
a
pr
and
make
that
proposal
as
an
official
spec
change
so
like
that
is
the
first
step
in
the
official
process
like
you.
Can
there's
idea
steps
before
that,
where
you
like,
just
you,
know,
chat
on
forums
or
discord
or
whatever,
but
once
you
want
to
make
it
official
that
you
want
to
propose
a
change.
F
F
B
Yeah
they'd
have
a
label
that
indicates
this.
Isn't
this
isn't
considered
for
inclusion
yet,
or
this
isn't
and
like
part
of
this,
is
you
know,
matt
has
oh
matt,
that's
your
good,
so
is
that
like
client
matter?
Is
that
a
different
matt?
I
don't
actually
know
your.
B
So
matt
has
argued
with
me
in
the
past
that
the
eips
repo
or
the
ethereum
specs
repo
should
specify
ethereum
maintenance,
like
that's
the
thing
that
it
should
be
specified,
not
ethereum
like
things,
and
so
if
we
went
down
this
route,
I
think
we
would
be
moving
towards
that
world
view
where
eips
are
not
a
general
thing
or
this,
I
guess
ethereum
specs
repo,
it's
not
a
general
purpose
thing.
This
is
specifically
the
definition
for
maintenance.
It
is
not
the
definition
for
things
that
are
like
mainnet
or
even
the
test
networks.
F
B
It
does
create
complexity
for
testnets.
That's
actually
didn't
really
think
about
until
now,
but
like
if
we're
doing
prs
to
a
specifications
repo
then
and
they
don't
get
merged
to
the
specs
repo
until
main
net,
then
defining.
What
is
rinkaby
is
no
longer
trivial,
like
it's
no
longer
just
oh,
it's
eip155,
but.
B
H
Mean
it's
not
super
nice,
but,
like
you
could
have
branches
with
like
the
full
spec
for
the
test
net
and
then
you
could
have
like
a
tracker
where
it's
like
these
are
the
pr's
because,
like
they're
still
going
to
be
kind
of
like
eeps,
but
it's
like
these
are
the
pr's
that
we're
adding
just
so
it's
like
an
easy
place
that
someone
can
look
and
see.
These
are
kind
of
the
chains
that
are
being
discussed.
H
I
think
they
should
only
be
pr's
against
the
spec.
I
think
that
you
know
what
I've
felt
after
trying
to
write
several
eeps
is
that
you
end
up
writing
the
same
thing
over
and
over
again
for,
like
you
know,
half
of
the
eep
like
you're,
trying
to
describe
the
situation
and
you're
trying
to
set
up
like
what
is
mainnet
when
in
reality
like,
if
they
were
just
pr's
against
the
spec,
you
don't
have
to
do
that
anymore.
You
just
have
to
say
here's
the
difficult
spec
and
then
you
can
just
focus
on
the
rationale.
H
I
mean
that's
a
that's
a
good
question
I
think
like
in
the
pr
is
okay,
because
that's
how
a
lot
of
other
governance
systems
sort
of
work
as
far
as
I'm
aware
like
if
you
look
at
like
the
rust
language
like
how
they
do
rfcs,
it's
like
all
just
prs
into
the
rfc
repo
and
the
discussions
are
kind
of
there.
H
I
don't
know
if
they
have.
I
mean
it's
like
different.
Obviously
like
our
again
rfcs
are
not
quite
the
same
as
a
consensus
definition
of
what
mainnet
is.
I
don't
think
I
have
like
a
really
strong
opinion
on
whether
it
should
be
in
the
pr
in
a
separate
document
it
should
wherever
it
is,
it
should
be
accessible
pretty
quickly
and
it
should
be
documented
historically.
B
Just
for
you,
brent,
everything
is
up
in
the
air.
No
one's
decided
on
anything
right.
B
It's
I
I
appreciate
your
your
struggle
and
frustration
like
I
said
I
would
folk
work
under
the
assumption
that
we
still
have
core
eips.
We
still
are
doing
the
aap
process
as
it
is
today,
maybe
at
some
point
in
the
future
the
doubt
process
will
change,
but
for
I
think
your
work,
you
can
kind
of
just
ignore
that.
The
only
thing
I
think
that
matters
for
your
work
is
just
the
ercs
are
almost
certainly
going
to
be
split
out
from
the
eips.
F
A
Yep
thanks
everyone
yeah,
so
I
have.
I
also
wanted
to
give
a
small
suggestion
or
proposal.
I
don't
know
that
is
something
coming
up
in
my
mind,
like
whatever
we
have
been
discussing
about
like
that
may
happen
in
future
about
like
managing
it
through
specs,
using
pull
requests
for
updating
the
specs
of
the
main
net.
I
find
that
very
similar
to
each
tool
process
right.
So
I
was
wondering
like
we
are
working
on
london
upgrade
right
now.
A
I
know
this
is
not
the
right
audience
to
kind
of
decide
on
anything,
but
I
just
want
to
share
my
thoughts
like
right
now.
We
are
working
on
london
and
we
are
following
the
process
that
we
came
up
last
year
during
like
a
long
conversation
in
this
eipip
meeting
itself,
but
for
the
next
update,
maybe
shanghai,
before
the
merchant.
If
you
are
expecting
that,
I
think
it
it's
worth
giving
a
shout
out
that
we
should
try
this
pr
stuff.
I
mean
I
don't
know.
A
C
Yeah,
we
can't
do
that
if
we're
doing
shanghai,
because
there
is
no
spec
of
ethereum
one,
it's
something
that's
possibly
being
worked
on,
but
it's
definitely
a
prerequisite
like
we
don't
have
something
to
do
prs
against
right
now,
maybe
for
the
merge.
We
could
do
it
and
actually
that's
what
they're
doing
on
the
e2
side.
But
if
shanghai
is
just
like
a
feature
for
the
odds
of
having
like
a
stack,
is
very
low
and
I
wouldn't
want
to
put
that
as
a
blocker.
B
Yeah,
I
think,
unless
we
hire
someone
full-time
who
already
has
experience
with
ethereum
realistic
timeline
for
getting
a
full
spec
written
is
probably
like
a
year.
Even
if
we
hire
someone
full
time.
I
think
realistic
timeline
is
probably
a
year
yeah
and
we're
basically.
B
Needs
to
write
a
python
client
that
is
specifically
written
to
be
readable,
not
to
be
fast
like
the
currently
is
pi
ethereum,
but
it's
designed
to
actually
execute
relatively
quickly
and
therefore
it's
harder
to
read.
This
is
a
a
rewrite
of
a
entire
ethereum
client
that
is
explicitly
designed
to
be
readable.
A
A
Okay,
so
one
last
thing
that
I
wanted
to
discuss
in
this
topic,
particularly
about
my
types-
I
don't
want
to
bring
like
the
entire
thing
here,
like
moving
off
eip1
and
all
just
one
thing
like
for
this
past
two
upgrades
we
are
having
a
dot
mda
file
for
berliner,
taught
md
file
for
london.
A
So
what
do
people
in
general
think
about
if
we
create
like
not
create
if
we
like
kind
of
move,
the
meta
files
which
were
for
earlier
upgrades
here
or
maybe
a
copy
of
that
no
copy
wouldn't
make
sense,
but
yeah
I'm
moving.
A
To
the
eat,
one
spec,
like
we
have
like
network
upgrade
section
in
which
we
are
keeping
all
upgrades.
We
are
keeping
it
for
london,
we
are
keeping
it
for
berlin
and
even
if
we
we
have,
I
believe
there
is
a
file
created
for
us
as
well,
so
we
can
move
it
there.
B
Are
you
talking
about
moving
the
old
hard
fork,
meta
eips
there?
Is
that
correct,
yeah
yeah,
I'm
a
big
fan
of
that.
I
would
love
it
if
someone
just
sat
down
and
just
kind
of
transcribed
the
hard
fork
metas
over
to
eth1
specs
and
then
my
preference-
and
this
is
a
weak
preference
not
as
strong
as
that
I
have
in
the
past
my
preference
would
be,
then
we
actually
remove
the
them
from
the
ips
repository
and
just
replace
them
with
a
pointer
similar
to
what
we
did.
I
believe
for.
A
B
Eap,
it
just
points
at
ether1,
specs
repo.
If
we
were
to
move
the
like
retroactively,
move
the
other
ones
there
I
would
be
in
favor
of
also
having
them
just
have
a
similar
pointer
just
to
kind
of
encourage
people
and
reinforce
that
each
one
specs
repo
is
the
place
to
go
for
hard
fork.
Meta
information.
C
So
I
I'm
fine
doing
that,
but
I
would
wait
basically
a
year
until
we
have
actually
harmonized
the
e1
specs
any
two
specs
repo
before
doing
it,
because
then
you'll
just
end
up
with
a
bunch
of
broken
links,
but
I
don't
mind
taking
that
on
once,
like
I
guess.
The
first
thing
I
feel
like
I
need
to
figure
out
is:
how
do
we
merge
each
one
specs
any
two
specs?
And
it's
not
the
most
urgent
thing
right
now,
but
I
think
after
london
it
will.
C
It
will
kind
of
climb
on
that
list
and
once
we
have
that,
like
you
know,
ethereum
specs
or
whatever
then
yeah.
I
I
wouldn't
mind
putting
a
bunch
of
pointers
and
adding
the
past
hard
forks,
but
right
now,
yeah.
The
links
will
just
be
out
of
date
in
six
to
twelve
months.
B
Sure,
so
are
you
arguing
that
we
should
not
back
port
the
hard
forks
at
all
or
just
we
do.
C
I
I
think
we
should
back
link
to
them,
but
once
we
have
a
backlink
that
we're
fairly
comfortable
will
be
stable
right
like
so
I
don't
mind.
So
if
we
have
you
know
each
one
or
if
we
link
them.
If
we
battling
them
to
each
one
specs
and
the
each
one
specs
repo
goes
away
in
six
months,
then
we
have
a
bunch
of
broken
backlinks
we've
forgotten
about.
So
if
we
merge
each
one
any
two
specs
repo
into
like
ethereum
specs
post,
merge,
then
we'll
have
like
one
repo.
A
If
I
understand
correct,
we
are
ultimately
planning
to
move
out
everything
out
of
mata.
I
mean
meta
eat
right,
so
anyway
we
are
going
to
move
it
out
of
eips.
I
mean
like
it
is
repository
at
the
end
of
the
day.
So
if
we
bring
it
to
the
ethernet
repo
right
now,
maybe
it
will
be
pulled
to
the
e2
or
wherever
we
decide
to
move
like
merging
things.
It
will
be
pulled
together.
C
But
the
link
from
so
in
the
if
we
do
that
right
now,
you
basically
go
to
all
the
meta
eeps,
and
you
say
this
keep
is
not
not
accurate.
Go
to
these
one
specs,
but
all
those
links
will
break
when
we
do
the
transition
and
people
are
already
complaining
to
me
a
lot
that,
like
they
don't
know
where
to
find
the
hard
fork,
specs
and
whatnot
so
I'd.
C
Rather,
everybody
knows
that
the
hard
fork
meta
eeps
are
a
thing
right
now
and
I'd
rather
just
do
this
transition
once
than
do
it
twice,
because
now
it
feels
like
it's
messy
and
nobody
knows
where
to
find
the
london
spec
or
the
burning
spec
and.
B
So
I
feel
like
there's,
there's
three
three
options
here:
one
we
do
keep
all
hard
fork,
eips
in
the
aip's
repository
until
we're
ready
to
fully
move
them
all
to
ethereum,
specs
or
ether
specs
or
whatever,
or
we
have
all
of
them
in
each
specs
asap,
and
so
that
is
the
canonical
source
or
we
have
what
we
have
right
now,
which
is
legacy
ones
are
in
ethereum.org
meta
and
the
new
ones
are
in
each
specs.
B
I
feel
like
the
way
we
have
now
is
kind
of
the
worst
of
both
worlds,
because
there
is
no
con
canonical
place
to
go
to
look.
My
I
do
have
a
preference
that
we
move
the
canonical
place
not
to
be
eaps,
and
we
start
training
people
on
that
sooner
rather
than
later.
But
it
sounds
like
tim,
you
would
rather
go
back
on
our
decision
to
drop
eips
from
meta
or
sorry
drop,
hard
fork.
Eaps.
C
No,
so
I
guess
yeah
what
I
what
I
was
advocating
for
is
your
third
option,
which,
when
you
put
it
like
that,
does
sound
pretty
terrible,
so
yeah.
In
that
case
yeah.
I
feel
like
the
way
you
framed
it.
I
would
probably
rather
move
all
the
yeah
all
the
meta
eips
to
the
e1
specs
repo,
but
if
we
were
to
do
that,
I
think
we
should
give.
We
should
bring
it
up
on
all
corners
and
give
people
the
chance
to
chime
in
and
whatnot
like.
B
Yeah,
so
these
these
historical
eips
are
a
little
bit
easier,
I
think,
than
london,
shanghai
and
berlin,
because
those
are
new,
the
historical
ones
aren't
changing.
So
it
would
not
be
terrible
if
we
had
them
duplicated,
at
least
for
a
period,
so
we
can
leave
them
in
the
eaps
repo
as
they
are
now.
Don't
touch
them
and
then
also
have
someone
go
through
and
transcribe
them
over
to
one
specs,
and
then
we
can
tell
people.
You
know
the
right
place
to
look
for
hard
fork.
B
Changes
is
the
ethospex
repo,
but
people
who
are
still
going
to
the
old
place
will
still
see
the
old
stuff.
So
you'll
still
see.
G
B
C
B
Sure
and
then,
if
the,
if
that
link
breaks,
it's
not
critical,
because
we
still
have
the
spec
right,
yeah.
A
Right,
I
mean
yeah.
This
is
this
is
very
similar
to
what
I
was
having
in
my
mind
like
like
we
have
berlin.nbc,
and
in
that
we
will
be
having
everything
that
was
there
for
homestead
meta
eat
whatever
it
was
just
that
even
like
my
type
number
would
not
be
there,
but
the
content
will
be
there,
and
in
that
we
are
going
to
just
add
a
liner
that
this
is
now
available
on
homestead
md
eat
one
dot
or
spec
repo.
B
So
yeah,
if
you
have,
if
you
have
someone
in
mind
who
wants
to
go
through
those
hard
fork,
metas
and
just
kind
of
port
them
to
ethon
specs
repo,
I
think
I.
A
B
B
They're
relatively
easy
to
port,
I
don't
think
it
requires
any
specialized
like
ethereum
core
dev
knowledge,
it's
pretty
straightforward
process,
just
kind
of
time
consuming.
A
Yeah
sure
cool,
so
at
least
we
are
good
on
this
part.
So,
going
back
to
point
number
four,
where
we
are
discussing
about
canonical
source
of
eips,
just
to
summarize
this
for
brent
brent,
he
has
to
continue
working
on
ignoring
this
fact,
which
will
be
coming
in
future.
Just
work
on
the
erc
part
and
extraction
of
that
for
new
destination
of
meta
eats
not
all
except
eip1.
A
We
would
be
moving
meta,
eats
a
copy
of
it
to
the
ether,
dot
or
spec
repository
and
for
other
proposals,
core
interface
and
network.
We
are
like
kind
of
tabling
it.
Maybe
we
will
discuss
that
in
future.
A
Okay,
so
moving
on
the
next
item
on
the
agenda
is
a
progress
on
github
repo
action
bot.
I
believe
that's
going
to
be
really
quick
elite
on
my
car.
If
anyone.
E
Would
like
to
yeah,
I
can
hop
in
here,
so
it's
nearly
all
right.
They
can
make
you
just
check
right
now
to
see
how
it's
doing,
but
I
think
it's
fine.
We
want
to
make
one
change
potentially
to
it,
but
this
is
like
small
things,
but
overall
progress
is
good.
E
I'm
hopeful
that
we
can
do
a
murder
like
kind
of
activate
it
soon
mike-
and
maybe
you
can
fill
in
on
his
plan
for
that,
but
overall,
going
good.
B
It's
currently
more
reliable
than
our
existing
bot,
like
our
existing
blot,
hasn't
merged
like
four
or
five
eips
this
week,
whereas
the
elitist
spot
has
flagged
them
to
be
merged.
I
don't
know
if
it
would
have
actually
merged,
but
it's
at
least
gone
green.
A
E
So
the
bot
is
active
on
the
eips
repo
or
just
not
like.
Essentially
it's
a
stubbed
version,
so
it
doesn't,
it
doesn't
have
the
capacity
to
merge
anything
yet,
but
it
will
in
the
future
and
it's
so
it's
basically
running
in
production,
but
just
not
actually
merging
things.
A
Right
so
I
believe
to
mark
this
action
like
you
know,
completed,
and
this
thing
is
done.
We
would
want
to
move
that
to
etm
github
repo,
because
I
don't
know
it
appeared
to
me
like
it's
coming
from
her
personality,
when
I
saw
that
comments
from
bot
that
was
really
good.
Every
time
I
see
editor
on
every
proposal.
B
H
A
B
B
Yes,
just
whoever
I
don't
know
who
actually
has
rights
in
the
ethereum
organization
to
create
new
repositories.
So
I
don't
know
who
to
ask.
A
C
It's
the
ef
devops
team,
so
you
know
I
don't
even
have
the
right
if
somebody
can
send
me
just
like
a
quick
note,
just
giving
some
context
about
the
bot
and
whatnot
I
can
get
it
created.
A
Right
so
with
that
note,
I
was
going
to
come
back
on
agenda
item,
one
that
was
progress
on
erc
and
I
believe
we
need
help
there.
I'm
not
sure
if
we
have
this
ercd
book
created
yet
do
it
doesn't
even
have
any
information
on
that.
A
Say
I
was
trying
to
reach
a
couple
of
people,
but
I
had
no
luck
or
maybe
tim
if
you
can
help
us
on
that,
we
are
looking
for
someone
to
create
yes,
repo
and
get
access
to
micah
and
lifeline,
at
least
so
that
they
can
start
the
initial
work
and
then.
C
Yeah,
so
I
guess
yeah,
so
it's
the
ef
devops
team,
so
the
only
thing
I
would
need
for
both
repo
is
just
kind.
You
know
some
background
and
summary
like
they
want
to
understand
why
they,
you
know
we're
creating
the
repo.
So
if
somebody
can
just
send
me
kind
of
a
quick
paragraph
that
I
can
copy-paste
and
give
to
them,
that'll
that'll
help,
along
with
the
who
should
be
like
admin
on
the
repo.
E
B
I
can
let
elita
probably
can
describe
the
bot
better
than
I
can
so
I'll.
Leave
that
to
her.
E
Yeah,
I'm
gonna
reach
out
right
now
with
the
description.
I
don't
know
that
so
sounds
good.
A
Okay,
that's
all
about
it.
I
I'm
not
sure
if
we
have
anything
more
to
discuss
on
erc,
it
is
created.
A
Okay,
okay,
so
I
mean
like,
if
I
understand
right
after
it
is
created,
we
will
start
moving
and
we
will
have
to
publish
a
like
kind
of
announcement
blog
like
mentioning
what
all
changes
we
are
doing
with
that
process,
and
maybe
I
was
wondering
if
we
we
should
start
adding
questions
and
concerns
with
erc.
I
have
been
receiving
quite
a
few
comments
when,
with
nfts
and
all
they,
they
are
having
some
discussion
around
this
versus
business
standard
and
also
these
kind
of
stuff
may
be
added
in
future.
Eip
record.
A
A
A
Okay,
so
the
next
item
is
update,
eips.etm.org
with
changes
to
eip
and
erc
repo.
I
believe
we
are
going
to
see
this
like
in
our
next
one
or
two
meetings,
so
I
mean
we
have
to
work
on
that
create
a
boundary
for
json
rpc
api
spec,
I'm
not
sure
if
we
are
going
to
create
a
bounty
right
away,
but
I
am
expecting
some
kind
of
write-up
on
that,
maybe
from
a
later
that
would
be
helpful
and
complete
eip
report.
We
discussed
this
today
determine
pay
rates
for
eip
editors.
A
I
don't
know,
I'm
gonna
talk
to
mala
people
for
that.
I
have
a
meeting
this
week
so
after
the
conversation,
maybe
if
we
can
get
some
kind
of
clear
picture
in
that
one
funding
part,
I
will
be
happy
to
share
that
in
the
next
meeting.
A
The
next
item
is
31.6.
It's
add
an
erc
dictated
editor
for
now,
I'm
considering
like
client
for
the
editor
of
erc,
as
he
has
shown
interest
on
working
on
that,
but
in
future,
if
we
need
more
and
more
people
we'll
try
to
reach
out
to
community.
E
So
there
is
one
thing
which
is
that
there
is
more
work
to
be
done
with
the
bot
and
moving
forward,
I'm
kind
of
awaiting
like
funding
for
that.
So
that
would
be
one
thing
to
look
into.
I
don't
know
if
that's
more
of
an
ech
meeting
thing
to
talk
about.
E
Yeah
for
continued
work
beyond
the
initial
merge,
so
like
the
stuff
we
talked
about
today,
that's
all
gonna
be
done,
that's
included
in
the
initial
implementation,
but
then
there's
other
work
like
transferring
over
the
circle
integration
to
github
actions,
adding
some
more
features
to
the
bot,
more
considerations
along
those
lines.
A
I
think
I
could
use
help
here
from
the
eid
editor,
so
eap,
additives
like
whatever
we
have
decided
for
the
first
task.
I
believe
we
have
decided
on
a
fixed
amount
to
be
for
that
work
to
be
done
and
whenever
we
come
up
with
any
kind
of
enhancement,
work
or
nice
to
have
feature
that
has
to
be
added
on
eip
bar.
A
If
we
can
just
create
an
issue,
maybe
in
this
eipid
repo
or
the
ethereum
dot
eip
github
wherever
and
give
an
estimate
of
time
or,
like
you
know,
work
needed
the
feature
that
has
to
be
added.
That
would
be
easier
for
cathedrals
to
follow
up,
and
you
know
kind
of
provide
funding.
Funding
should
not
be
a
problem.
That
is
something
that
we
would
like
to
cover
from
the
edm
cathode
side,
but
getting
an
estimate
of
work
and
how
much
funding
is
required
would
be
helpful.
B
So
I
think
it
would
be.
It
would
be
easier
for
everyone,
except
for
the
cat
herders
if
it
was
if
we
were
able
to
hire
someone
to
kind
of
work,
somewhat
unboundedly
at
an
hourly
rate
or
something
like
that
or
salary.
Just
because
there's
a
number
of
kind
of
small
tasks
and
often
in
engineering
the
cost
of
estimating
how
long
they
will
take
ends
up
taking
more
effort
than
just
doing
the
task.
And
so
I'm
worried
that
we
would
end
up
wasting
more
time
and
money
on
just
doing
estimates
than
we
would
on.
A
B
Yeah
something
like
that,
I
think,
would
work
much
better
than
trying
to
figure
out
like
how
much
each
project
costs.
Just
because
there's
like
lots
of
little
things
that
I
think
we
could
really
benefit
from
having
just
an
engineer
who
was
somewhat
familiar
with
our
process
and
who
we
can
kind
of
go
back
to.
A
G
B
Eip
stuff,
it's
like
yeah
bots
that
help
us
do
editing
easier,
make
make
the
bots
better
improve
them.
There
are
also
things
like
we
talked
about
this
whole
thing
with
the
ercs
or
cips.
We
want
them
to
kind
of
share
a
numbering
system,
and
so
someone
could
write
like
some
tooling.
That
makes
it
so
we
have
a
mechanism
for
getting
shared
numbers,
so
they
don't
conflict,
don't
overlap.
There's
miscellaneous
stuff
like
that.
G
B
It
is
work
that
is
not
happening
because
we
don't
have.
We
don't
currently
have
anyone
like
we
have
everyone
who
does
eip.
Editing
is
an
engineer,
but
none
of
them
actually
do
engineering
for
the
ap
editing
the
last
person
who
did
a
significant
amount,
I
think,
was
nick
johnson,
and
that
was
like
two
or
three
years
ago,
I'm
here
with
the
original
bots
and
since
then
we
basically
have
you
know
we
have
again.
We
have
engineers
who
are
editors
but
not
acting
as
engineers.
If
that
makes
sense.
B
Oh,
you
know
very
much
because
there
should
be
something
I'm
suggesting
yeah.
There
should
be
someone
elita
has
done
workforce
previously
on
the
bot.
She
recently
wrote,
and
so
I
would
be
fine
with
her
being
that
person
or
someone
else
like
I'm,
not
particularly
attached
to
any
one
person
like
more
care,
but
that
there's
somebody.
A
That
was
another
point
of
consideration
like
I'm,
I'm
requesting
this
funding
for,
but
I
may
not
be
able
to
understand
to
whom
it
has
to
be
disposed
or,
like
you
know
when
and
how
much
if
it
is
just
on
a
monthly
basis
we
are
requesting
for
like
20
hours
a
month
or
so
we,
I
cannot
say
for
sure
that
it
is
secured
until
it
is
actually
secure,
but
when,
when
a
job
comes,
if
we
keep
on
posting
that
this
is,
this
is
supposed
to
be
done,
and
this
has
been
done
in
this
month.
B
A
Okay,
these
are
all
good
conversation,
I'm
very
happy
that
we
made
some
good
progress
today
I
mean
like
every
meeting
we
do.
But
yes,
there
was
a
lot
of
clarity.
I
was.
I
personally
was
looking
for.
So
thank
you.
Everyone
for
joining
us
today
and
I
hope
to
see
you
all
in
two
weeks.
Please
keep
sharing
any
thoughts,
any
comments,
any
concern
that
you
would
want
to
bring
it
up
related
to
process
improvement
of
ethereum
like
ecosystem,
make
a
comment
on
agenda
or
you
can
reach
out
to
us
all.