►
From YouTube: EIPIP Meeting 55
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/130
A
A
A
A
A
He
did
mention
that
he
will
be
following
the
recording,
and
the
list
that
we
have
here
is
of
open
issues
and
pull
requests
at
different
ethereum
repositories
based
on
his
priority.
What
he
thinks
will
be
of
priority,
I'm
gonna
just
read
them,
and
maybe
eip
editors
or
anyone
who
is
working
on
these
issues.
If
they
have
any
updates,
they
can
share
it
or
maybe
propose
any
possible
solution.
A
A
So
this
issue-
I
mean
this
particular
item.
I
think
we
discussed
it
earlier.
I
I
see
a
lot
of
like
a
comment
going
on.
Anyone
has
any
date
there
or
would
like
to
add
anything
on
that.
A
B
A
That's
right:
I
am
also
expecting
some
more
people
to
join
today.
Maybe
one
of
them
may
be
able
to
help
out
with
this,
though,
we
already
have
someone
also
looking
into
issues.
We
can
find
the
comment
there.
Okay,
definitely
we
know
that
this
is
one
of
the
highest
priority
items.
So
if,
if
someone
is
available
to
work
on
that,
we
will
make
this
off
one
of
the
highest
priority
item
to
look
into.
A
Okay,
okay,
that
sounds
good
mike.
I
just
curious.
Do
you
want
me
to
go
through
all
the
items
listed
here
or
is
there
anything
that
we
can
pick
it
up,
particularly.
A
I
mean
I'm
happy
to
read:
let's
see,
let's
just
go
through
it,
the
next
one
is
cannot
delete
files
in
asset
folders.
So
and
again
this
is
already
added
to
eip
bot
repository.
A
A
The
next
sub
item
listed
here
is
eip.
5069
eip
editor
apprentice
handbook
in
eip
form.
So
recently
we
have
noted
this
new
pull.
Request.
Number
is
five:
zero,
six
nine,
this
user.
He
has
documented
a
hack,
md
file
created
by
me,
where
I
have
collected
all
the
information
related
how
we
can
have
a
new
eip
auditors
on
board.
A
E
E
They
need
to
be
divided
in
some
way,
just
because
there
are
so
many
possibilities
for
ercs,
so
there's
lots
of
them
and
there's
just
a
lot
fewer
core
eips
and
a
lot
fewer
people
who
are
competent
to
really
understand
them
and
well
like
for
myself,
they're
the
only
ones
I'm
interested
in
reviewing.
A
Well,
this
particular
proposal
is
not
related
to
eip
and
erc-
probably
we
can
discuss
it.
When
we
go
back
to
item
number
one.
We
were
waiting
for
some
more
participants
to
join,
so
we
skipped
it,
but
this.
A
Not
a
problem
so
yeah
if
there
are
any
other
thoughts
on
like
do,
we
need
this
kind
of
meta
proposal
or,
first
of
all
do
we
need
this
as
a
proposal,
because
this
was
just
a
hack,
empty
file
that
we
were
sharing
earlier
yeah
and.
C
A
We
want
to
like
kind
of
formalize
that
we
may
use
some
kind
of
eip
and,
if
that
at
all,
it
has
to
be
an
eip,
should
it
be
informational,
meta.
E
So
yeah
it
didn't
used
to
be
that
formal,
but
there
was
simply
some
discussion
among
existing
editors
and
a
consensus
reach
that
a
new
person
should
join
and
it
was
loose
enough
that
I
recall
simply
adding
macaw
out
of
frustration
that
there
didn't
seem
to
be
any
other
editors,
but
me
for
a
while.
So
it'd
be
good
to
tighten
it
up
a
little.
But
I
think
there
should
be
some
consensus
of
all
the
existing
editors.
A
A
A
So
this
is
about
adding
eip
editor.
The
proposal
here
is
like
whatever
hackamd
file
that
we
were
referring
earlier,
where
it
is
documented
how
we
are
doing
this,
the
internship
program,
how
we
are
running
it
and
the
steps
that
we
are
following
to
onboard
an
editor.
He
is
just
proposing
to
have
these
things
publicly
available,
not
in
the
form
of
hack
md,
but
in
the
form
of
eib
may
be
stored
on
the
eip
repository
so
just
curious
to
understand
what
people
think
about
this
particular
proposal.
F
A
Right,
yeah
and-
and
this
proposal
is
proposed
as
a
meta
eap,
which
is
again
for
all
process
thing,
though
I
am
also
not
able
to
comprehend
it
completely.
This
user
has
used
my
document
and
he
reached
out
to
me
that
is
it
fine
to
have
him
added
as
an
author.
Obviously,
if
you
are
doing
the
leg
work,
if
you
are
championing
a
proposal,
you
have
to
be
a
co-author
of
that.
Maybe
we
can
wait
for
review
comments
from
other
people
like
other
editors,
because
it
is
already
added
as
a
pull
request.
A
A
A
Okay,
so
a
few
meetings
ago,
we
mentioned
that,
if
there
are
anything
that
people
would
like
to
be
discussed
in
eipip
meeting,
they
can
probably
list
it
here
on
the
eip's
repository
issue
issues
section,
because
we
are
strongly
discouraging
people
to
create
an
issue
for
eip's
discussion.
So
all
the
issues
here
are
listed
from
there
feel
free
to
drop
a
comment
over
there
on
the
issue.
That
is
linked
if
you
have
any
opinion
strong,
weak
whatever,
but
whatever
can
help
us
close.
These
issues
faster.
A
E
I'm
not
using
issues.
I
keep
getting
confused
on
just
how
to
introduce
an
eip,
especially
corey
ips,
because
we
have
a
section
on
the
magicians
where
discussions
of
core
eips
go,
but
in
general
you
want
to
you
want.
You
may
want
to
introduce
discussion
of
an
eip
before
you've
actually
introduced
one
with
a
pr
and
asked
for
a
number,
and
so
you
get
in
this
loop.
Where
you
can't.
E
B
So
you
you
can
start,
you
could
definitely
start
a
discussion
in
the
magicians
forum.
You're
correct,
you
won't
get
a
number.
Is
there
a
reason?
You
need
a
number
to
start
talking
about
it.
E
Look
at
the
core
section
of
the
eips
and
I
I
think
the
the
earl
there
includes
the
number
or
somehow
related
to
it.
So
so
you
can't
you
can't
really
get
something
started
there
until
you
get
an
eip
number,
it's
not
cause.
I
believe.
B
There's,
I
don't
believe
anything
stops
you
from
creating
without
a
number,
and
so
you
should
be
able
to
and
then
I'm
pretty
confident
that
we
fixed
it.
So
you
now
can
edit
infinitely
like
you're,
no
longer
limited
to
only
be
able
to
edit
within
the
first
like
10
minutes
or
whatever.
So
you
should
be
able
to
just.
G
B
B
B
Yes,
if
it's
not
fixed,
let's
let
me
know
I
tested
it
and
it
worked
for
me,
but
I
may
have
more
permission
so
it
doesn't
work
for
you
definitely
tell
us
because
it
should
be
fixed.
E
Okay,
well,
if
you
can
do
it
there
and
keep
editing
it
to
keep
it
up
to
date,
then,
and
then
remove
it
and
put
a
link
to
the
actual
the
actual
draft
when
the
time
comes.
That
works
very
well
great
thanks.
A
Yeah
we
hope
that
issue
is
fixed.
I
see
daniel
muted
unmuted.
Do
you?
Do
you
have
something
to
add
here?
I
know
you
are
also
working
on
an
eip
right.
H
Yeah
I
was
just
going
to
say:
I
know
you
can
create
draft
pull
requests
that
you
know.
That
might
be
a
way
to
have
a
draft,
but
not
have
it
being
reviewed
or
clogging
up
any
kind
of
processes,
and
you
could
just
point
the
discussion
to
that
draftful
request
in
magicians
until
you're
ready
to
make
it
official.
But
it
sounds
like
that's
not
the
only
way
to
solve
this
issue.
A
Right
that
is
also
a
very
good
point,
because
earlier,
when
we
used
to
have
draft
draft
was
the
only
status
before
it
can
be
moved
to
last
call
now
that
we
have
a
review
as
a
status,
so
people
can
always
create
the
initial
pull
request
as
draft
and
when,
unless
they
are
ready,
keep
it
in
draft
and
once
they
are
ready,
they
can
move
it
to
review
for
editor's
review.
E
Yeah,
I'm
just
thinking
of
the
ideas
that
are
often
vague
enough,
they're
never
going
to
get
to
an
eip,
and
you
don't
want
to
clutter
up
the
repo
with
draft
pr's
issues
used
to
be
a
good
place
to
say.
I
think
this
might
be
a
good
idea
for
an
eip
and
start
a
discussion,
and
that's
a
magician's
is
a
good
place
for
that
to.
A
Right
all
right,
going
back
to
the
the
last
item.
It
was
five
zero,
five
six.
I
I
know
that
there
are
a
few
comments
related
to
this
particular
issue
that
is
already
available
in
the
link
that
is
provided
in
the
agenda.
So
if
anyone
has
any
comment
or
suggestions
to
handle
this
one,
please
look
into
that.
No
tim,
you
did
not
miss
the
first
item.
We
are
just
coming
back
on
it
because
we
were
waiting
for
some
more
people,
so
we
thought
that
we
can
quickly
finish
this
up.
A
I
think
we'll
take
another
five
minutes
or
so,
and
we
should
be
going
through
all
these
small
items
and
then
we'll
go
back
to
our
item
number
one
again.
The
next
one
is
the
mud,
ethereum
cat
herders
into
ethereum
org
repository.
I
suppose
this
is
a
very
big
proposal.
A
A
I
know
I
had
a
chat.
Oh
yeah.
Let
me
first
mention
this.
I
had
a
chat
with
tim
earlier
and
we
were
thinking
about
how
to
make
sure
like
the
we
can
have
a
backup
of
some
of
the
important
repos
of
ethereum
categories
repository
and
we
did
discuss
about
eipip
to
be
considered
one,
but
I'm
not
sure
like
it
was
discussed
to
move
all
together
into
ethereum
yeah.
Please
go
ahead.
Micah,
sorry
for
introduction.
B
A
Yeah-
that
is
an
interesting
point,
and
I
would
love
to
hear
more
thought
on
that,
though
I
could
not
connect
with
this
person
like
to
have
a
long
chat.
He
said
that
his
availability
will
be
more
in
next
two
weeks.
He
has
some
exams,
so
maybe
when
he's
around
or
if
we
have
more
information
on
that,
we
can
probably
bring
it
back
but
yeah
if
anyone
has
any
any
kind
of
opinion
like
whether
it
should
be
or
it
should
not
be,
they
can
definitely
comment
on
the
issue
that
is
listed
here.
A
And
I
find
a
few
more
items,
three
more
items
that
is
like
already
listed
here
and
one
of
them
is
a
bug
which
is
again
eap,
bot.
I
think
we
can
cover
that
in
the
next
item.
It
is
eip
issue
number
77,
so
we
can
probably
discuss
it
over
there.
A
Okay,
all
right
so
in
the
essence
of
time,
and
now
that
we
have
a
lot
of
people
here
to
discuss
item
number
one.
Maybe
we
can
go
back
to
vitamin,
though
we
didn't
have
samuelson
on
the
call.
Yet
I'm
not
sure
if
he'll
be
able
to
make
it,
though
we
have
left
a
message
for
him.
So
let
me
go
back
to
item
number
one
and
see
what
we
have
since
the
last
meeting.
A
As
I
was
mentioning
that
we
have
been
discussing
this
item
for
past
few
meetings
and
we
have
a
lot
of
discussion.
So
if
anyone
interested
they
can
go
back
refer
to
the
recording
of
earlier
meetings
from
the
last
meeting,
it
seems
like
greg.
Colvin
has
some
concerns
and
we
kind
of
discussed
that
what
is
the
current
situation
with
the
python
specs,
as
well
as
with
the
people
who
will
be
able
to
understand
the
yellow
paper,
ethereum
yellow
paper?
A
It
looks
like
like
current
availability
of
resources
such
as
that
moving
towards
having
diff
to
python
specs
is
comparatively
better
because
we
have
more
audiences,
who
can
probably
understand
python
than
who
can
understand
the
current
yellow
paper,
but
because
greg
was
not
there
last
time.
So
we
wanted
to
bring
it
up
again
to
the
meeting
today,
so
yeah
feel
free
to
share
your
thoughts.
Opinion
concerns.
E
Me
yeah:
I
spent
a
fair
amount
of
time
with
sam
wilson
going
over
that
kind
of
view,
615
just
as
an
example,
because
it's
fairly
long
and
brought
home
some
of
my
concerns.
E
Sort
of
the
central
concern
is
just
that.
Python
is
a
bad
language
for
declarative
specifications
and
you
know
615
as
an
algorithm,
for
instance,
for
validation,
but
the
specification
is
almost
entirely
declarative.
E
It
has
a
very
short
algorithm
at
the
end
for
validation,
but
it
specifically
said
that's
not
part
of
the
specification,
so
having
python
code
for
implementing
a
spec
doesn't
work
as
the
spec
itself
and
right.
I
E
If
you
have
a
reference
implementation,
yes,
other
teams
can
basically
port
the
reference
implementation,
but
you
can
specify
things
without
writing
the
code.
E
You
write
declarative
specification
and
then
any
code
that
implements
that
specification
is
satisfactory
and
if
you're
using
a
procedural
language
like
python,
the
port
is
relatively
straightforward.
If
you're
using
a
non-procedural
language,
like,
I
guess,
haskell,
you
basically
have
to
reverse
engineer
a
declarative
specification
from
the
python
and
then
implement
it
from
that
and.
E
E
E
It
would
I
wouldn't
know
how
to
do
it.
I
don't
write
python
very
well
at
all
like
I
can.
You
know
I
can
put
together
simple
scripts
and
struggle
through
struggle
through
the
beacon
chain
code,
but
languages
we
have
for
doing
declarative
specification
are
basically
english
math
and
that's
about
it.
For
our
team,
there's
formal
languages
that
people
use
but
they're
gonna
be
even
harder
than
python.
I
Right,
but
I
think
that
one
of
the
challenges
when
we
talked
about
this
about
cordevs
with
like
english
is
martin
brought
up,
is
like
it
leads
to
a
bunch
of
eips
being
underspecified
right
like
whereas
like
if
you
have
to
actually
work
through
like
a
full
implementation.
I
You
by
definition,
have
to
like
specify
it
in
code
and
then
the
question
of,
like
you,
know,
python
versus
other
programming.
Language,
I
think,
is
a
bit
like
orthogonal
to
that.
I
But,
like
I
think
from
like,
when
we
presented
sam's
work
on
our
core
devs,
there
was
a
pretty
strong
consensus
that,
having
like
a
spec,
which
is
in
code,
provides
less
ambiguity
and
one
of
the
annoying
things
for
client
developers
is
when
a
new
eip
comes
in,
and
it's
just
like
underspecified,
and
they
actually
have
to
like
figure
out
what
the
author
of
the
eip
intended,
based
on
kind
of
their
english
or
like
declarative
specification,
which,
which
doesn't
have
everything.
E
E
Partly
if
we
want
to
do
this,
I
I'd
want
to
have
a
person
or
small
team
of
persons
who's
willing
to
work
with
people
doing
core
proposals
to
help
produce
this
python.
It
wasn't
clear
to
me
it
wasn't
clear
to
me
whether
this
was
a
full
implementation
of
the
client,
so
you
you
could
actually
test
it
is.
Is
it
a
full
implementation?
E
Yeah
it
is
okay.
Then
we
get
the
hassle
that
the
initial
implementation
is
likely
to
be
in
some
other
client.
I
you
know
work.
I
do
would
probably
be
either
in
the
c
plus
plus
client
or
the
go
client.
E
So
I
might
have
a
pr
on
a
you
know:
complete
implementation,
but
it's
not
going
to
be
the
python
client,
especially
if
I'm
doing
performance
work
on
geth
or
something
it's
it's
going
to
be
irrelevant
to
python,
but.
I
E
E
E
Wasm
solves
it
by
having
both
english
and
formal
spec
and
a
promise
that
the
two
of
them
mean
exactly
the
same
thing
and
that
took
some
very
good
people
to
do
that.
They
don't
have
a
reference
implementation.
E
E
B
I
think
that's
going
to
be
true,
no
matter
what
language
you
choose,
so
anything
we
choose,
there
will
be
a
set
of
people
who
do
not
know
it.
So
if
we
choose
python,
there's
a
lot
of
people
who
don't
know
the
python
features
go
some
people
who
don't
know
go
if
we
choose
f,
there's
going
to
be
some
people
who
don't
know
f
like
I
think
that
is
an
unsolvable
problem
like
the
fundamental
kind
of
underpinning
of
what
you're
getting
at,
and
that
leaves
us
the
question.
B
Okay
so
which
which
do
we
choose
and
we
can.
We
could
choose
a
like
a
formal,
formal,
something
you
know,
r
or
whatever
it
is
or
something
it
can
be
formally
specified.
B
The
reason
for
python,
I
think,
is
just
that.
It
is
the
most
likely
language
that
most
people
will
be
able
to
know
or
figure
out
like
it's.
It's
a
I
mean,
there's
a
reason.
People
use
it
for
teaching
right,
because
it's
relatively
simple
and
not
too
complicated
doesn't
have
a
lot
of
weird
edge
cases.
I
mean
it's
not
a
perfect
language,
I
don't
use
it,
for
example,
but
it's
not
hard,
and
so
I
I
think
that
I
mean
my
argument
here
is
basically
that
we're
not
someone's
going
to
be
unhappy
in
this
case.
B
It's
you
and
probably
some
other
people
as
well.
I'm
sure
there's
other
people
that
don't
want
to
write
in
python,
but
I
feel
like
this
is
kind
of
optimizing
for
the
least
total
unhappiness
across
the
core
dev
space,
no
you're,
not
getting
it.
I'm
sorry!
Well!
So
then,
there's
I
think,
there's
the
other
aspect.
We're
saying
I
do
agree
with,
which
is
that
a
declarative
specification
would
be
better.
I
agree.
B
The
problem
is,
is
that
we
getting
someone
to
write
and
maintain
a
full
declarative.
Formal
specification
for
ethereum
is
hard,
like
the
yellow
paper
was
supposed
to
be
that
and
it
was
totally
under
maintained.
No
one
could
read
it.
I
shouldn't
say
no
one,
many
people
struggled
to
read
it
and
we
want
something:
that's
approachable
and
accessible,
and
so
we
we
have
to
make
so
the
choice.
The
question
is,
is:
do
we
make
a
sacrifice
in
like
we
were
sacrificing?
B
What
you
said
declarative
is
better,
but
we're
sacrificing
that
in
order
to
increase
accessibility
and
approachability
and
simplicity
and
things
that
people
are
more
likely
to
be
familiar
with,
and
and
again
I
want
to
make
clear-
I
do
agree
with
you
that
something
formal
would
be
better
if
we
had
infinite
resources
and
we
didn't
have
to
worry
about
like
ramp
up
time
and
onboarding
time
for
new
eip
authors
stuff
like
that,
and
so
I
think
it's
python
is
just
kind
of
an
optimization
for
lowest
common
denominator.
I
guess
you
could
say.
E
B
Right,
my
information
would
be
to
write,
write
the
rules
in
english
or
whatever
you're
familiar
with,
like
you
can
write
them
in
the
eap
I
don't
think
is
limited
to
only
having
the
python
it's
just.
It
must
have
at
least
the
python,
and
so
you
could
write
your
ap,
perhaps
initially
without
any
of
the
python
you'd
author.
B
It
get
it
as
a
draft
like
you
might
not
allow
it
to
go
to
reviewer
last
call
without
the
python
implementation,
but
I
definitely
would
accept
a
draft
without
a
python
implementation,
and
so
you
can,
you
know,
write
it
in
something
you're
familiar
with
and
have
a
declarative
all
that
and
then
maybe
as
a
later
step.
Once
you
have,
you
know
you
kind
of
sold
some
people
on
it.
Someone
can
come
in
and
help
you
or
actually
do
the
python
implementation
so
that
it
satisfies
the
requirement
of
it
has
to
have
the
python
update.
B
That's
my
my
thinking
may
have
other
thoughts
on
that,
though,
because
process
wise.
C
As
long
as
like
I
mean
as
long
as
we
okay,
because,
like
there's
a
couple
ways,
you
could
do
it
right,
you
could
do
it
so
that
you
just
make
the
markdown
file
and
don't
make
any
changes
whatsoever
to
the
executable
spec.
C
You
could
make
the
markdown
file
and
change
the
dock
strings
of
the
relevant
functions,
which
I
think
doesn't
really
require
knowing
much
python
just
just
enough
to
be
able
to
find
where
you
want
to
make
the
change-
and
I
think
you
know
having
different
levels
of
like
like
I
don't
know
where
the
line
should
be
drawn.
Maybe
zero
python
is
probably
the
best
option,
but
yeah
there's
different
places.
You
could
draw.
E
I
can't
I
can't
do
this,
it's
just,
but
one
thing
so
I
could
look.
I
could
show
up
with
an
eip
that
uses
english
and
you
know
whatever
seems
appropriate
to
present
the
idea
clearly
enough
that
it
can
be
implemented.
E
If
you're
doing
something
that's
supposed
to
improve
performance,
you
need
to
show
it
does
prove
performance
in
the
important
clients
at
that
point.
You've
done
a
lot
of
work
and
then
you're
told
oh
you've
got
this
go
code.
Oh
you
have
the
c
plus
plus
code.
Oh
you
have
this
java
code
and
before
it
can
be
any
ip,
you
must
translate
this
code
to
python
and
it's
I'm
just
like.
No,
that's
too
much
work.
Well,
I
think.
E
No
really,
if
another
team,
who
is
the
python
team
says,
don't
worry,
we're
the
python
team
now
we'll
work
with
you
to
finish
off
the
spec,
but
it
really
seems
up
to
the
core
devs
themselves.
Weather
respect
is
ready
for
them
to
implement
whether
they
really
need
this.
It's
not
really
for
the
eip
editors
to
to
decide
what
the
core
devs
need
that
the
original
concept
was.
You
know
pretty
much
that
the
core
devs
are
operating
independently
enough
of
this
process
that
it's
up
to
them,
what
what
they
find
acceptable.
B
E
Fine,
I
I
can
with
I,
can
just
withdraw
some
eyepiece
or
or
ask
for
a
lot
of
help.
I
I
If
you
can't
do
it
yourself,
but
it
seems
like
sure
like
for
for
drafts
and
for
discussions,
I
I
appreciate
that
that
creates
a
ton
of
useless
overhead
and
and
like
we
shouldn't,
impose
that
on
people
but
but
yeah.
I
I
think,
like
to
move
to
cfi
or,
at
the
very
least
like
to
move
to
be
included
in
a
hard
fork.
I
Sure,
but
you
would
ideally
not
dump
it
all
on
them.
I
think
it's
a
bit
unsustainable
to
say
like
yeah,
the
people,
maintaining
the
spec
need
to
be
the
one
like.
I
think
it
would
be
good
to
have
the
norm
or
it's
a
bit
of
a
broader
set
of
contributors.
Okay,
well.
E
The
problem
was
that
we
would
have
a
specification
that
very
few
people
in
the
world
could
actually
read
and
we
decided
to
go
with
english,
ordinary
math
such
that
people
could
actually
read
it,
and
there
would
be
some
ambiguity,
so
it
would
be
a
job
we,
we
had
a
small
subcommittee
whose
job
was
to
disambiguate
the
english.
E
If
when,
if
and
when
issues
arose-
and
you
know
in
our
case,
we
were
specifying
a
language
so
examples
and
such
would
be
in
that
language
and
when
we
could
we'd
specify
things
in
that
language,
but
I
don't
know
it's
615
remains
an
example.
There's
there's
a
validation
algorithm,
but
you
could
slice
it
off.
E
The
proposal
and
formalists
were
able
to
go
through
it
and
write
complete
formal
specifications
based
on
the
english
help
me
get
the
english
cleaned
up
and
it's
a
totally
adequate
formalization
and
writing
a
validation
algorithm
in
python
rather
than
a
pseudo
c
fine,
it
would
be
more
readable
and
it
would
not
be
a
specification
you'd
have
to
re.
You
would
have
to
reverse
engineer
the
specification
from
the
python.
B
Definitely
for
something
like
6.5.
I
definitely
don't
think
that
you
should
remove
the
specification
you
have
like
the
english
language
version.
The
I
think
the
only
requirement
here
is
that
there
is
also
a
python
reference
implementation
functionally
like
this
did
not
preclude
you
from
also
having
you
know
better
stuff.
It's
not
even
declarative
language,
something
in
english.
Something-
and
I
don't
know
whatever
the
popular
declarative
languages
are
these
days
like
that's
acceptable.
It
just
also
has
to
have
the
python
reference
implementation.
E
So,
basically,
to
write
that
I
would,
I
would
have
to
learn
enough
python
to
write
what
might
be
a
fairly
difficult
algorithm
yeah
in
python,
and
learn.
C
E
Wait
a
minute
and
learn
how
the
reference
implementation
works
well
enough
to
make
a
pr,
even
if
the
pr
actually
involves
fairly
substantial
changes
to
the
reference
implementation,
you're
asking
an
awful
lot
of
people
that
unless
there's
you
know
unless
the
executable
spec
team
itself
is
willing
to
help
when
I'm
working
with
the
geth
team,
when
I'm
working
with
the
c-plus
plus
team-
and
they
think
it's
a
good,
you
know
a
good
thing
to
do
or
to
investigate
they
help
me.
You
know,
I'm
not!
I'm
not
left
alone,.
B
I
suspect
that
would
still
be
true
for
the
python
teams,
as
you
as
you
put
it,
I
did.
The
reason
I
don't
want
to
say
you
will
get
help
is
because
I
want
to
avoid
the
trap
of
saying
every
single
person
who
wants
to
draft
a
queer
eip
gets
a
slice
of
the
python
team's
time
like
I
want
to
make
sure
we
don't
fall
into
that
trap
because
there's
you
know
hundreds
of
vips
that
never
make
it
anywhere
and
they're
terrible,
and
we
should
not
be
dedicating
resources
to
those
people.
B
There
are
definitely
some
eips
that
are
going
places
and
we
want
them
to
be
included.
Like
I
don't
know,
let's
take
one
five,
five,
nine
as
an
example,
because
it
was
very
popular
like
for
that.
It
would
have
been
pretty
easy
to
find
someone
to
do
the
python
implementation
or
help
you
with
it.
615
may
also
fall
into
that.
That's
that
bucket.
B
There
are
a
number
of
people
who
are
interested
in
that
we
just
need
like
one
or
two
of
them
to
you
know,
help
out
or
the
python
team
maybe
interest
themselves,
and
they
can
help
out.
I
don't
think
anything
precludes
you
from
getting
help
from
people
who
are
familiar
with
it.
It's
just
I
I
just
want
to
be
very
careful.
We
don't
promise
that,
because
that
can
lead
to
worse
problems.
I
think
well.
E
E
B
Personal
preference
on
this
is
that
it
is
acceptable
to
approach
the
core
devs
with
an
idea
that
is,
you
know,
reasonably
well
described
and
ask
them.
Does
this
interest
you
and
if
we,
if
I
push
this
through,
you
know,
is
that
likely
to
go
through,
or
is
this
going
to
be
something
that
no
one
wants
to
implement
and
I
think
it's
very
reasonable
to
not
have
a
python
implementation
for
that?
B
I
So
that
would
be
just
like
process
wise.
That
would
be
after
something
is
cfi.
So,
like
take
615
as
an
example,
we
could
say
we
consider
615
cfi
for
the
next
hard
fork
as
as
is
like
with
just
the
go
implementation
but
then
prior
to
all
the
client
teams
or
like
in
parallel,
perhaps
to
all
the
client
teams
implementing
it
and
prior
to
it
being
like
officially
part
of
the
hard
fork.
Then
you
make
it.
I
E
Yeah
well
so
you're
saying
it's
not
acceptable
to
show
up
with
you
know
with
it
working
in
any
other
client.
Well,
you're
gonna
need
like
you're.
I
Gonna
need
to
show
that
it's
a
good
idea
right
like
and
if
the
way
for
you
to
do
that
is
showing
it
working
in
another
client
because
say
it's
like
a
performance.
Optimization
then,
like
that's
kind
of
the
way
you
convince
core
devs
that
this
is
actually
worth
doing,
but
I
think
from
that
point
up
to
like
before
everyone
has
done
it
that
implemented.
It,
then,
is
when
you
also
need
to
get
it
done
in
python
either
by
doing
it
yourself,
which
at
that
point
the
next,
I
can
do
it
and
again.
I
At
that
point
it
should
be
a
bit
easier
to
do
that,
because
other
people
should
want
the
cip
to
also
go
in
the
next
hard
fork
and
be
kind
of
incentivized
for
it.
Yeah,
and
one
of
the
reasons
I
guess
why
I'm
pushing
so
hard
is
also
is
like.
I
think
there
is
like
also
a
large
set
of
potential
core
eip
champions,
who
are
not
client
devs
and
for
who,
like.
I
This
is
much
better
like
I
was
talking
with
uni
swap
yesterday
about
their
eip
and
they
struggle
to
like
get
it
implemented
in
guesth
and
all
these
other
clients
which
have
nothing
to
do
with
like
the
type
of
code
that
they
write.
Usually.
So
I
think
python
is
like
much
more
accessible
for
all
these
folks
who,
like
work
more
at
the
application
layer
and
have
changes
they
want
to
propose
back
down.
E
E
If
you
don't
really
need
it,
then
you
don't
really
need
it
if
you've
already,
you
know
if
you've
already
implemented
another
client
to
then
say
well
fine,
but
you
also
need
to
implement
it
in
the
reference
client.
It's
just
like
it
was
hard
enough
to
do
it
in
one
client
and
unless
the
core
devs
are
saying
no,
we
must
see
it
in
a
in
executable
python.
E
E
A
One
other
point
that
I
would
like
to
bring
up
here.
Like
generally,
we
consider
four
at
the
max
six
core
eips
for
any
upgrade
and
considering
if
we
are
having
even
two
upgrades
in
a
year
and
we
have
one
or
two
proposal
which
needs
help
like
I
have
it
documented
in
python
that
can
be
provided,
but
I
totally
agree
to
tim's
point
that
we
should
not
be
making
it
a
burden
to
team
who
are
maintaining
their
specs
for
python.
A
But
in
my
understanding
this
is
something
doable
and
if
there
is
any
help
needed
to
push
a
proposal
now
when
it
is
considered
for
inclusion,
so
cfib
generally
from
the
process.
Point
of
view
such
as
that
proposal
should
be
in
review
and
ideally
to
have
a
spec
written
in
python
in
review
status
when
it
is
ready
to
be
shared
with
the
code
would
be
good
to
have.
A
But
if
not,
I
think
it's
just
reference
implementation
and
you
can
share
that
with
code
apps
and
if
it
is
acceptable,
then
someone
may
help
you
out
with
having
that
in
python,
and
you
can
proceed
from
there.
E
A
E
A
Well
noted,
I
think
this
is
a
fairly
good
discussion
and
that
we
are
trying
to
discuss
both
the
points
as
tim
and
sam.
I
think
I
read
somewhere
in
the
chat
that
it
is
good
to
check
with
the
all
code
meeting
is
more
like
what
other
clients
think
about
it,
because
we
try
to
come
up
with
a
decision
on
like
based
on
general
consensus,
like
whatever
is
good
for
a
big
number
of
people,
like
a
majority
of
people
who
try
to
move
ahead
with
that.
A
A
Yum
anything
more
to
add
on
this
discussion,
especially
for
related
to
having
it
in
python
and
not
in
python,
because
I
know
at
some
point
sam
mentioned,
that
if
it
is
so
contentious,
then
we
can
probably
drop
it,
and
I
just
don't
want
to
drop
it
just
like
that
before
we
have
like
a
very,
very
good
reason
to
drop
it.
A
That
that's
good.
I
think
if
this
is
something
that
that
cannot
be
like
closed
in
one
week
or
two,
maybe
we
will
have
to
work
on
this
adjectivally,
so
we
will
come
back
again
on
this
topic
next
week.
Not
this
particular
one,
but
I
know
jim
has
joined
here,
and
we
are
also
looking
for
some
support
on
the
ethereum
process
as
an
as
overall
help
there.
So
yeah
tim.
I
Yes,
so
we
have
mario
today
from
our
team,
who
can
probably
help
with
some
of
these
issues.
I
don't
know
marielle.
Do
you
want
to
introduce
yourself
real,
quick.
J
Hey
folks,
I'm
maria
havel,
I
work
with
ef
with
demon,
training,
vertical
support,
yeah
and
I've
been
looking
into
the
eap
bots.
I
I
was
listening
to
the
call
from
january
to
get
some
overview
about
the
bots
and
there
is
well
multiple
of
them.
J
There
are
multiple
issues
and,
and
the
this
eip
is
in
javascript,
I'm
not
really
experienced
with
that
and
the
the
apv
one,
the
that
one
is
in
the
rest,
I
might
be
able
to
help
there,
so
I
will
look
into
it
more
and
and
try
to
try
to
solve
some
lowering
issues.
J
Yeah
exactly
exactly
it's
the
eap,
verifier
validator
right
yeah
well
later
on,
so
because,
because
I'm
I'm
just
much
more
experienced
with
rust
than
with
javascript.
So
it
would
take
me
a
while
to
pick
up
on
the
other
one.
But
I
was
already
looking
into
this
one
and
and
yeah
I'll
be
glad
to
contribute.
B
However,
so
on
the
one
hand
I
want
to
say
you
know,
we
should
be
careful
about
singing
too
much
dev
effort
into
eipv
if
we're
just
going
to
eventually
deprecate
it.
On
the
other
hand,
we
are
desperate
for
help
and
people,
and
so
if
we
have
someone
who
wants
to
help
and
rest
is
what
they
want
to
do,
then
I
would
rather
keep
eipv
and
not
deprecate
it
and
instead
get
the
help.
If
that
makes
sense,.
J
Yeah
sure
you
have
to
get
it
yeah
I
mean,
let
me
see
if
I
will
be
able
to
to
figure
out
something
there,
but
so
what
would
be
the
timeline
there
like?
When?
Would
you
imagine
to
have
the
ipv
duplicated
if
there
are
contributions.
B
B
Again,
though,
that
that
process
is
very
slow
and
I
would
rather
take
the
help
where
you
can
get
it,
and
so
if,
if
you're
passionate
about
rust
and
you
hate
typescript,
then
I
would
much
rather
get
help
on
the
apv
than
nothing
for
sure
and
the
timeline
at
our
current
clip,
like
our
current
pacing,
is,
I
don't
know
many
years
before
we
managed
to
hear
the
vip.
J
That's
great
yeah,
I
mean
I'm
a
bit
busy
these
days.
I
will.
I
will
be
probably
able
to
look
into
it
in
coming
weeks
and
I
will
reach
out
to
you.
I
see
that
you
are
one
of
the
contributors
there
and
I
also
also
actually
have
in
touch
with
him
regularly.
So
so,
if
I
have
anything
I
will,
I
will
ask
and
yeah.
B
I
think
for
eapv
you
probably
want
to
talk
to
matt
late
client
he's
the
I
think
he's
the
one
who
ordered
it
originally
from
ruby.
I'm
not.
B
And
so
he
probably
knows
it
the
best.
I
I
actually
don't
speak
rust,
so
I
would
not
oh.
J
A
I
think
that
would
be
a
good
help
in
that
direction,
because,
as
matt
mentioned,
micah
mentioned
that
we
were
considering
that
to
be
converted
into
typescript,
probably,
but
now
that
we
are
getting
some
help
on
rest
side.
So
let's
have
it
what
we
get
there.
I
know
there
are
a
lot
of
open
issues
there.
So
it's
good
that
you
have
already
started
looking
into
it
and
we
have
someone
else
jose
on
the
call
who
is
currently
looking
into
eip
bot
stuff,
but
I
know
jose.
A
You
have
been
suggesting
a
lot
of
suggestion
how
to
improve
that
yeah.
If
you
have
anything
to
like
add,
I
know
we
are
out
of
time,
but
anything
quickly.
If
you
would
like
to
share.
D
A
Sounds
good
yeah
if
you
can
add
pull
request
that
would
give
more
clarity
to
eip
editors
there
to
may
be
able
to
review
it
and
decide
like
whether
that
is
a
good
suggestion,
or
that
would
be
a
good
solution
to
the
issue
that
is
looking
for
some
help.
So
that
would
be
great.
I
know.
Sam
wilson
has
done
a
great
job,
putting
out
small
issues
for
bot
that
that
can
help
automate
some
of
the
processes
so
slowly.
A
We
would
like
to
also
get
into
taking
up
those
issues,
but,
to
begin
with,
we
can
start
from
whichever
or
the
higher
priority.
A
We
are
out
of
time,
I'm
not
sure
if
you'll
be
able
to
take
any
other
item
listed
here
just
quickly.
I
wanted
to
mention
this
to
mario,
mario,
I'm
not
sure
if
you
are
available
on
ethereum
cad
holders
discord.
If
you
have
not,
maybe
you
would
like
to
join
and
we
try
to
have
discussion.
You
can
also
discuss
it
on
ethereum
rnd
eip
editing
channel,
but
there
are
also
editors
available
on
ethereum
cad
headers
eip
editors
channel
and
we
can
discuss
if
there
is
something
that
I
mean.
J
Yeah
yeah,
I'm
in
the
in
the
discord
and
I'm
following
here.
I
I
also
read
the
the
the
editor
apprenticeship
had
a
book
and
I
I
might
be
able
to
to
help
with
some
editing
as
well
or
some
some
feedback
for
the
piece.
A
Great,
thank
you
so
much.
Thank
you
tim
for
introducing
mario
to
the
group.
I
hope
this
will
help
us
a
lot,
because
we
have
been
looking
for
a
lot
of
help
to
towards
sport,
so
we'll
be
able
to
move
smoothly.
A
All
right
I'll
consider
that
we
are
good
for
today,
but
I
know
we
have
a
few
more
things
that
we
would
like
to
cover
it
in
the
upcoming
meeting.
So
thank
you.
Everyone
for
joining
us
today
hope
to
see
you
in
next
two
weeks
and
we
can
still
keep
chatting
on
the
discord.
Ethernet
and
eat
caters,
have
a
good
one.
Everyone
thanks.