►
From YouTube: EIPIP Meeting 58
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/146
A
A
That
is
open.
If
any
other
editor
may
approve
it,
it
can
be
done.
The
other
pull
request
to
update
it
is.
B
Yeah,
I
think
this
afternoon.
A
A
So
I
hope
this
would
be
done
and.
A
A
A
A
The
other
one
is
revised.
Eip2535,
it
looks
like
there
is
heavy
changes
done.
I
have
added
it
here
because
you
know
it
was
requested
by
panda
peep
to
be
getting
to
be
discussed
in
the
eipip
meeting.
However,
matt
and
sam
also
looked
into
this
pull
request.
Yesterday,
I
suppose
there
was
some
comment
left
too
so
yeah.
If
anyone
else
has
anything
to
add
here.
The
main
question
is
about
the
manual
merge
and
one
suggestion
that
I
brought
up
like
it
should
not
be
going
back
to
draft.
A
B
Oh
not
not
draft
back
to
review,
I'm
generally
inclined
to
leave
it
up
to
the
author
to
approve
it
like.
I
don't
like
touching
people's
eips
unless
it's
an
absolute
last
resort
and
the
author
of
this
one
is
fairly
active,
so
I
think
we
can
get
them
to
agree.
A
A
C
A
Moving
on
to
item
number
two,
that
is
eips
discussion
took
place.
I
have
added
this
item
just
because
there
was
some
discussion
on
discord
about
fem
or
the
e3
research.
I
know
there
was
a
general
agreement
to
have
a
fem
as
the
discussion
too,
and
this
morning
I
noticed
that
proposal
5133.
They
also
have
updated
it
to
fem.
A
So
is
it
generally
fine
like
we
will
continue
with
fm,
or
is
there
anything
to
be
discussed
here
when
you.
B
Yeah,
so
that
was
just
a
mistake.
I
think
it
was
overlooked.
The
I
think
the
ip1
direct
says
it
very
explicitly:
ethereum
magicians,
not
research,.
A
A
Another
thing
like
we
were
discussing
this
in
the
last
meeting,
so
I
created
an
issue
and
I
believe
we
have
collected
response
from
most
of
the
eip
editors
and
item
number
three,
which
was
seems
to
be
like
liked
by
most
of
the
people
over
there.
B
A
You're,
fine,
I'm
fine,
closing
it
and
thank
you
so
much
looks
like
after
a
long
time.
I
see
issues
as
15.
It
is
in
two
digits.
I
mean
two
digits
but
lower
lower
like
tens
and
twenties,
it's
very
low.
A
Moving
on
that
is
item
number
three,
but
I
would
still
like
to
skip
it
for
some
more
time.
We'll
wait
for
another,
maybe
a
few
items
to
go
over
before
we
come
back
to
execution.
Specs
discussion
skipping
that
item
item
number
four
is
git
badges.
So
there
is
an
issue
link
here
in
which
the
git
boy
up
team
discussed
about
how
to
be
distributing
it,
perhaps
for
recognition
of
contributors
or
maybe
wanting
them
or
make
it
memorable
for
them.
So
for
cathodes
the
link
is
live.
A
I
have
added
the
link
in
the
agenda,
so
whoever
have
contributed
to
the
calories
website
or
to
the
eip
ip
repository
pm
or
l2e
will
be
getting.
Perhaps
this
is
just
a
piece
of
information,
so
please
check
out
the
live,
link
and
share
your
feedback,
and
there
is
a
proposal
to
provide
a
retroactive
award
to
people
who
who
have
contributed
to
ethereum
related
repository,
which
are
not
active
anymore.
A
Okay,
number
five
is
eips
github
commissions
and
support,
so
I
tried
to
reaching
out
to
my
usual
contact,
but
it
seems
like
I
didn't
get
much
response
from
there,
so
I
don't
know,
but
the
issue
of
spamming
was
communicated
and
looks
like
joshua,
who
is
also
for
the
epdm.org.
A
A
There
is
item
number
six
about
eip
bots.
I
don't
see
jose
on
the
call,
so
maybe
we
can
skip
unless
anyone
has
anything
specific
to
comment
on
no.
A
Okay,
no
problem.
The
next
one
is
eip's
inside
it's
monthly
eips
status
reporting
in
june.
Today's
15th
of
june
half
month
have
already
passed
in
june.
We
have
two
eips
2464
and
2364,
which
were
long
pending.
Proposals
moved
to
final
six
eips
are
added
as
draft
and
two
new
proposals
are
waiting
to
be
reviewed.
I
mean
they
are,
they
are
being
reviewed,
but
there
are
some
more
work
to
be
done
on
that
site
before
it
can
be
merged.
A
A
A
D
I've
discussed
it
quite
a
lot
and
sam
and
I
have
discussed
it
one
on
one
quite
a
lot,
so
I'm
I'm
not
quite
sure
where
it
stands.
Do
we
do
we
have
an
actual
eip
for
it.
Well,
I'm
look
the
link,
I'm
looking
at
now.
Isn't
isn't
yet
a
pr.
C
Yeah
we
we
don't
have
like
a
formal
proposal
like
written
up
to
change
eip1.
Yet
I
think
we're.
B
A
C
The
rough
consensus
phase
among
editors,
okay,
so
so
like
personally,
I
think
I
I'm
still
weakly
in
favor
of
making
it
mandatory
for
core
eips,
but
you
know
I.
I
don't
want
to
push
the
issue
too
much
if
we
don't
have
rough
consensus
among
editors,
so
yeah.
Well,
you
need
enough
consensus
with
the
all
right.
The
corey.
C
C
D
A
lot
of
them
don't
and
they
do
care
a
lot
of
them.
I
don't
read
python
very
well.
I
I
can't
count
how
many
programming
language,
I
can't
count.
How
many
I
either
know
or
used
to
know
python,
even
I've
written,
but
it's
like
a
process
of
soaking
it
in
it's
like
okay.
Now
I
remember
but
I've
I've
tried
to
read
like
even
the
beacon
chain
spec
it's
just
like.
I
get
almost
nothing
out
of
it.
It's
like
yeah.
D
E
B
But
unfortunate
population
right
so
like
we
have
to
accept,
there
will
be
people
who
cannot
read
the
spec
and
the
question
is
is
which
set
of
people?
Do
we
want
to
exclude.
D
Right
but
if
you're
asking
someone
to
learn
english,
that's
of
more
general
use
than
python,
but
even
more
so
there's
things
you
need.
D
You
can't
say
certain
things
in
python:
I'm
looking
at
specs,
I've,
written
and
others
have
written
and
others
in
the
industry.
Look
at
the
wasm
spec
that
there's
there's
one
page
of
procedural
specification
and
they
even
say
this:
isn't
this
isn't
spec?
This
is
appendix
this
is
example.
The
entire
spec
is
declarative.
D
There
is
nothing
procedural
in
the
spec
and
python
is
not
a
language
for
writing.
Declarative
specifications-
my
own
specs,
it's
english,
but
the
spec
itself
is
a
fair
amount
of.
It
is
declarative.
It's
these
are
rules
you
need
to
follow.
Not
this
is
an
algorithm,
then
there's
in
then
there's
yes,
this
is
an
algorithm
for
checking
that
the
code
follows
the
rules,
but
simply
specifying
the
algorithm
would
be
generally
useless.
D
Trying
to
reverse
engineer.
The
rules
from
the
algorithm
would
not
be
easy
at
all
and
asking
everyone
else
to
write.
D
To
write
the
code
from
the
algorithm,
it's
like,
yes,
you
can
just
blindly
port
code,
but
it's
you
know
it's
really
not
fair
to
people
to
just
say
blindly
port
this
code,
that
you
don't
understand,
wait!
What's
this,
you
know.
B
And
you
could
so
I
think
the
perhaps
the
issue
is
is,
I
think,
when
I
think
executable
spec
and
the
ei
corey
ip's
moving
over
to
executable
spec,
I
am
at
what
I'm
imagining
is
that
people
will
still
probably
write
some
human
readable
portion
and
that's
going
to
be
held.
I
think
in
markdown
files
tentatively
the
plan
somewhere
and
in
that
place
you
could
still
have
your
declarative
specification
and
that
would
still
be
valuable.
The
the
only
thing
that's
really
changing
here
is
that
we're
we're
kind
of
rearranging
where
things
live.
B
So
that's
change
and
we're
saying
we
no
longer
will
allow
you
to
submit,
or
we
will
tentatively.
You
know
request
that
everybody
writes
a
reference
implementation
plus
reference
tests
that
that,
where
the
reference
information
passes
it
and
in
order
for
that
to
work
functionally,
we
need
to
have
a
shared
reference
implementation
and
that
shared
reference
implementation
is
going
to
be
in
some
language.
B
It
could
be
go,
it
could
be
rust,
it
could
be
python,
it
could
be
whatever
and
if
we
accept
all
of
that
which
maybe
you
don't,
but
if
we
accept
all
of
that,
then
it's
just
a
choice
of
okay,
which
language
is
most
likely
to
be
approachable
by
the
average
developer,
and
I
do
think
python
meets
that
bill.
I
agree
with
you
on
all
your
points.
I
think
that
python
is
not
great
for
declarative
stuff.
I
think
python
is
not
in
a
perfect
language.
B
I
mean
I
hate
the
fact
that
it's
not
statically
typed,
I
love
static
type
languages
python's.
Not
these
are
all
things
are:
pythonas
are
using
the
static
typing
stuff,
yep,
okay,
let's
step
up,
but
nonetheless
it's
not
the
best.
I've
tried
it,
it's
not
the
best
static
typer
in
the
world,
but
it's
passable.
B
Nonetheless,
I
think,
despite
all
of
that
and
I'm
not-
and
this
is
coming
from
someone-
I
actually
hate-
I
don't
like
python
like.
I
do
not
write
python,
but
I
do
recognize
that
it
does
make
for
fairly
readable
code
for
the
average
person
who
you
know.
B
If
you
just
pick
a
random
developer-
and
you
don't
know
what
languages
they're
gonna,
they
speak
ahead
of
time
or
they
right
ahead
of
time,
there's
a
good
chance.
If
you
show
them
python,
they'll,
be
able
to
figure
out
what's
going
on
and
and
that's
why.
I
think
it's
a
good
choice
again.
This
assumes
that
you
still
have
your
your
declarative
stuff
somewhere
somewhere
in
a
markdown
file
in
english,
most
likely
somewhere.
D
But
the
eip
author
is
not
necessarily
qualified
to
do
that,
especially
if
they're,
not
if
they're,
not
on
a
client
team.
E
B
Expectation,
sam
or
tim,
maybe
for
a
draft
proposal
in
this
new
executable
spec
world
would
the
is
it?
Is
it
expected
before
you
submit
a
draft?
You
already
have
pr
against
code,
or
can
you
submit
a
a
draft
with
only
the
markdown
portion
like
ignoring
like
getting
the
last
call
or
final
or
whatever
just
like
to
get
started,
is
the
expectation
that
people
have
code
or
is
expectation
that
you
start
with
maybe
mark
down,
and
you
work
your
way
up.
B
F
Specification
section
say:
imagine
I
I
guess
we
we
allow
it
because,
like
even
this
difficulty
bomb
vip
the
spec
just
I
guess
there
is
one
line
of
code
yeah.
I
don't
know.
B
So
so,
right
now,
if
you
didn't
have
a
specific
specification
section,
you
submitted
a
draft,
but
all
the
other
sections
are
filled
out.
I
would
probably
let
it
through
and
probably
I'd
encourage
you
to
fill
it
out,
but
I
don't
think
as
long
as
you
had
the
section
and
you
just
put
tbd
in
there,
I
would
probably
allow
it.
I
allow
you
people
to
put
tbd
in
all
the
other
sections.
B
B
You
need
to
actually
have
something
here,
like
you
can't
just
have
a
blanky
ip
that
you
fill
in
later,
but
if
you've
got
like
a
motivation
and
abstract-
and
you
know
some
some
rationale-
maybe
and
all
these
other
sections
are
in
there,
but
you
just
don't
have
a
spec.
Yet
I
would
be
okay
with
that.
Personally,
I
don't
know
about
the
other
editor.
B
D
D
Well,
but
even
if
it
was
it's
not
what
they're
doing
they're
they're
working
against
their
their
c
plus
client
I've,
I've
got
some
prs
going,
which
have
code
in
in
c
and
in
sudo.
Go
at
some
point.
I
would
translate
it,
but
it's
hard
enough
right
now,
just
getting
algorithms
right
without
translating
it,
and
I
I
really
don't
want
to
have
to
set
up
a
python
system
on
my
machine
and
get
a
client
running
and
understand
the
client
well
enough
to
make
modifications
to
it.
It's
just
like
that.
D
I'm
sorry,
but
this
is
hard
enough
work,
I'm
not
getting
paid
to
do,
and
if
we
want
such
a
thing
it's
I
would
just
need
a
lot
of
help
and
cooperation
from
from
a
client
team.
That's
maintaining
that
client
for
any
core
iip
I've
at
some
point
needed
help.
You
know
from
a
client
team,
typically
martin
recently
it'll
probably
be
the
epsilon
team.
If
we
decide
to
go
with
one
of
my
eips.
D
It
just
I
understand
we
did
it
this
way
for
the
cl
layer,
but
they
started
out
with
a
python
implementation
and
the
people
working
on
it.
You
know
the
whole
style
was
was
different.
It
was
a
matter
of
starting
with
a
working
python
implementation
and
continuing
continuing
to
keep
it
going
and
we
would
have
to
get
in
a
position
of
having
a
working
python
implementation
and
pretty
much
all
the
core
developers.
D
All
of
them
have
it
going.
They
understand
it,
they
can
speak
it
then.
Yes,
at
some
point,
it
just
becomes
a
bar
to
entry
that
before
it
before
you
have
anything
to
do
with
core.
You've
got
to
understand
this,
but
it's
going
to
take
time
to
get
there,
because
it's
not
where
we're
at,
and
even
so
I
I
would
resist,
because
I
just
go
it's
it's
not
worth
it.
D
It's
I
I
would
say
no
eips
can
be
much
more
in
the
language
the
author
chooses
and
this
transformation
happens
further
down
the
line,
and
it's
it's
more
like
the
yellow
paper,
there's
a
team
of
people
that
that
keep
the
yellow
paper
not
up
to
date
enough.
But
if
that's
a
problem,
they
need
resources,
we
don't
just
abandon
them,
so
I'm
going
in
circles.
I
think
I
think
my
point
of
view
is
pretty
clear
by
now
right.
I
think
two.
F
Two
things
that,
like
still
make
me,
fall
on
the
the
python
specs
either
one
like
unifying
the
like
beacon,
chain,
spec
and
and
and
execution
spec
like
you
know
sure
the
systems
are
different
today,
but,
like
we're
gonna
merge
in
a
couple
months,
there
is
you
want
the
theorem
to
be
like
a
coherent
thing
that,
like
people,
can
wrap
their
heads
around
having
to
like
having
one
python,
spec
and
then
yeah
one
an
until
an
unintelligible,
math
paper
that
basically
we
rely
on
three
volunteers
to
understand
and
upgrade
it's
just
really
bad.
F
That
they're
not
the
same,
and
I
guess
the
second
bit
is
like.
I
do
feel
like
we're
more
bottlenecked
by
client
developers
than
like
eip
proposals,
and
that's
been
true
for
like
the
past
couple
years
and
again
like
it
seems
like
from
client
teams
like
that
I
speak
to,
like
generally,
they
prefer
the
executable
spec
approach
and
yeah
and-
and
I
I
I
simply
like,
I
think
we
should
try
to
find
ways.
F
You
know
to
make
it
easy
for
people
to
take
part
in
this
process
and,
like
you
know,
perhaps
have
like
very
soft
requirements
around
when
this
pr
to
the
spec
is
actually
is
actually
required,
and-
and
I
suspect,
if
you
have
an
idea-
that's
like
valuable
enough
and
that
your
bottleneck
like
if
everyone
thinks
the
eip
is
valuable.
But
the
bottleneck
is
actually
right
in
your
prt
executable
spec.
Many
people
will
be
able
to
help
with
that
yeah.
So
I
I
don't
know
I
I.
F
It
is
like
a
change
to
the
process
and
for
sure,
if,
like
you,
you're
working
in
the
geth
code
base
like
it
might
be
harder,
but
I
think
like
having
a
full
specification
not
having
to
like
rewrite
weird
parts
of
ethereum
in
an
eip
and
having
something
also
that
maps
from
like
the
execution
to
consensus
layer
when
you're
thinking
about
a
change
that
spans
both
sides
and
as
much
as
people
want
to
say
that
it's
going
to
be
modular,
like
I
think,
like
we
look
at
the
next
hard
fork.
F
There's
changes
spanning
across
both
sides.
I
think
once
you
start
having
things
like
proposal.
Builder
separation,
you're
going
to
have
changes
on
both
sides.
I
mean
all
the
sharding
stuff
influences
both
sides
as
well.
Like
it's
much
more,
it
seems
much
better
to
have
like
a
unified
standard,
where
you
know
the
the
sharding
bit
on
the
consensus
layer
specified
in
python,
but
so
is
the
way
to
access
the
sharp
data
on
the
execution
layer
and
it's
on
one
place.
F
So
I
I
I
struggled
to
see
how
we
just
keep
the
two
separate
systems
and
like
it
seems
like
the
system
from
the
consensus.
Their
side
today
is
like
just
much
more
approachable
to
people,
except
this
whole
thing
about
like.
Where
do
you
put
the
the
marked
down
text,
but
that
seems
like
a
much
easier
problem
to
solve.
D
Yeah
we've
got
two
very
incompatible
approaches
here:
yeah
both
of
both
of
well.
The
eip
process
is
a
pretty
long
standing
now.
They
used
to
say
internet
time
was
seven
years
per
one.
No,
it
was
worse
than
that.
That's
dog
years
anyway.
Eip
has
been
around
a
long
time
in
the
context
of
ethereum.
I
don't
know
it
just
seems.
If
we
want
this,
there
needs
to
be
an
eip
team
and
the
people
maintaining
the
ip
client,
the
sorry,
the
people
I'm
not
doing
very
well.
D
Because
you'll
lose
people,
otherwise
it
may
not
matter,
but
you'll
you'll
lose
me.
I
I
I
cannot
be
maintaining
a
client
and
trying
trying
to
make
gifts
against
the
client.
D
That
isn't
isn't
the
client
that
I'm
actually
doing
the
work
in
and
of
late.
That
would
be
go
or
c
plus,
plus
because
I'll
be
working
with
martin
and
or
the
ipsilon
team.
So
as
far
as
getting
executable
code,
unless
they
move
over
to
python.
D
C
So
we
can,
we
could
do
a
block
in
about
12
to
13
seconds
on,
like
a
regular
laptop,
so
on
a
beefier
machine.
It
should
be
fine.
I
don't
have.
C
C
It
around
with
me
yeah
I
mean
it
can
so
like
if
you're
testing
individual
blocks,
it's
totally
fine,
and
I
don't
like
why
would
you
want
to
sync
mainnet
on
just
like
your
development
machine.
B
B
Yes,
so
it's
it's
capable
of
processing
blocks
and
doing
state
transformations,
and
you
know
all
that
stuff.
What
it
can't
do
is
do
that
fast
on
a
low
end
machine
so
like
someone
could
run
the
python
implementation
on
a
beefy
machine
somewhere,
just
to
make
sure
that
it's
staying
in
sync
and
it's
following
extension
rules
but
like
this
would
not
be
a
client
that
we
encourage
users
to
use
because
it's
unreasonably
slow,
oh
god,
yeah.
Definitely
not.
D
Yeah,
I'm
not
worried
about
that.
I'm
worried
about
the
fact
that
the
operating
protocol
in
the
end
is
the
spec
yeah.
It's
yeah.
I've
said
this.
If
what's
running,
there
has
to
be
specified
it's
for
the
period
of
time.
Any
protocol
is
running.
That's
what
was
running
doesn't
matter
what
the
spec
document
says.
D
So
if
we
want
to
document
what
was
running
during
that
period
of
time,
that's
that's
what
it
was,
and
so,
if,
if
the
executable
spec
can't
actually
keep
up
it's
not
as
useful
yeah,
I
keep
saying
you
know
I
would
love
to
have
a
reference
implementation.
D
I
think
that's
a
very
useful
thing
to
have,
but
I
would
see
it
as
a
client
alongside
the
other
clients
that,
like
the
other
clients,
you
know,
needs
things
need
to
get
implemented
and
ready
to
go
before
a
release,
and
so
the
eips
would
would
pick
up
python
at
some
point,
some
of
them
right
away,
some
of
them
a
little
further
down
the
line
so
maybe
before
it
gets
out
of
review,
that's
something
you
want
to
do,
but
not
going
into
draft.
D
B
I'm
weekly,
I
don't
have
any
immediate
problems
with
having
the
process
making
it,
so
the
process
allows
for
pr's
against
executable
spec
that
only
contain
the
markdown
portion,
which
is
the
human
readable
portion.
This
would
be
similar
to
you
know
submitting
a
pr
that
just
contains
comments.
B
I
mean
the
comments
in
this
case
are
kind
of
separated
out
a
little
bit
but
and
again
I'd
like
more
input
from
others,
but
my
I
don't
have
any
initial
problems
with
that,
and
so
that
would
allow,
I
think,
what
you're
describing
greg,
where
you
describe
your
your
your
eip
in
english
or
some
customs
declarative
language
or
whatever,
and
put
that
into
a
markdown
file.
You
send
a
pr
against
the
executables
facts,
repo,
which
is
where
these
markdown
files,
I'm
hoping
will
go.
I
think
tim
disagrees,
but
tbd
they'll
go
somewhere.
B
You
submit
that
pr
and
then,
as
things
progress
at
some
point,
there
will
be
a
requirement
to
get
the
code
in,
but
that
can
be
further
along.
Maybe
you've
attracted
people
with
your
great
idea
that
are
can
help
you
with
the
python
or
do
the
python
for
you,
and
so
we
would
end
up
with
reference
implementation
sometime
before.
D
Understanding
people
there
has
to
be
a
team
of
people
who
maintain
that
client
and
part
of
their
job
is
to
work
with
the
ips
to
to
get
to
get
them
working
and
then
there's
a
pr
without
sticking
to
pr
and
the
eip
can
it
can
be
huge?
Sometimes
I
I've
got
a
proposal.
D
F
Then
it
should
so
if
you
have
something
like
that
and
it's
scheduled
for
mainnet.
Obviously
someone
will
help.
You
write
it,
but
if
you
have
something
like
that
and
like
it's
not
scheduled
like,
should
somebody
else
than
you
who's
championing
it
spend
time
trying
to
map
it
to
another
spec
like.
I
think
it's
like
at
some
point.
Like
sure
like
I,
I
have
no
doubt
that,
like
if
we
have
an
eip
coming
in
and
like
there's,
no
pr
against
the
python
spec
and
that's
a
reference.
F
Implementation
like
the
ef
can
have
a
couple
people
that,
like
work
on
that,
there's
probably
client
teams
as
well
that
work
on
it
and
that's
basically
how
it
works
on
the
consensus
layer
side.
You
know
we
have
a
few
people
at
the
ef
who
spend
time
on
those
specs
but
they're
not
like
the
sole
contributors
to
them
and
if
something's
gonna
go
into
our
hard
fork
on
the
beacon
chain
like
for
sure
those
people.
If
nobody
else
has
stepped
up
to
make
a
pr.
Those
people
will
like
make
that
pr
to
the
spec.
F
But
if
anyone
who
has
like
an
idea
for
an
eip,
like
it's
just
not
tractable
for
any
team
to
like
implement
everybody's
random
ideas,
it's
like
there
needs
to
be
some
sort
of
gate,
and
I
think
that's
like
roughly
when
we
think
something
should
be
in
a
hard
fork,
and
I
think
then
eip
champions
kind
of
have
an
incentive
to
provide
this
implementation
before,
because
it
probably
increases
the
odds
that
their
thing
gets
into
a
hard
fork.
If
more
people
understand
it
and
there's
a
clear
spec
for
it
right.
D
Yeah
it's
just
at
this
point.
Sometimes
the
idea
is
clear
enough
without
code
changes
that
it
can
get
discussed
for
quite
a
while
and
the
teams
can
go
yes.
This
is
a
good
idea,
we're
going
to
put
it
in
sometimes
it's.
This
is
a
good
idea,
a
bunch
of
us
who
put
it
in
it
works.
It
was
a
small
change.
You
know,
others,
you
know
I
I
could
show
up,
anyone
could
show
up
and
it's
like
we've
gone
into
geth
and
we've
done
all
this
and
here's
the
change.
D
F
I
think,
if
you
look
at
like
the
process
like
having
a
spec,
that,
like
everyone
can
read,
which
is
not
like
some
client
code
is,
is
much
better
because
now
what
we
have
we
we
do
have
we
have
this.
This
yeah
we
do
have
this
weird
like
in
between,
where,
like
the
eeps,
are
often
underspecified
and
then
like
people,
end
up
looking
either
at
get
code
or
like
basically
finding
out
that
they
disagree
on
some
under
specification.
When
we
start
writing
tests
for
the
eeps
and
yeah,
it
just
seems.
D
D
D
F
Universal,
it's
like
who's,
like
the
people
that
you're
reaching
and
like
basically
those
people
are
like
programmers
who
write
who
write
specs
for
your
theorems,
it's
like.
If,
if
you
are
able
to
read
the
yellow
paper
and
like
yeah,
I'm
not
concerned
that
you
cannot
like
get
to
a
point
where
you
have
a
python
spec
working.
If
somebody
helps
you,
it's
like,
I
think
the
level
of
skill
required
to
digest.
I
mean
I
know
plenty
of
people
who,
like
contribute.
F
F
Back
pretty
strongly
like,
I
think
the
yellow
paper
is
like
10x,
less
approachable
than
even
this.
Like
weird
system
we
have
today,
which
is
like
yellow
paper
plus
a
bunch
of
deep
diffs,
I
suspect
most
of
the
newer
core
developers
have
not
necessarily
read
through
the
entire
yellow
paper
or
if
they
do
so,
they
basically
read
through
like
the
get
code
on
the
site,
but
like
I
yeah,
I
don't
think
it's
a
way
that
a
lot
of
people
intuitively
reason
about
ethereum.
D
Yeah,
you
can
go
out,
there's
actually
a
huge
academic
literature
at
this
point
of
people
going
into
ethereum
who
lean
on
the
yellow
paper
because
they're
you
know
they're,
actually
mathematicians
and
computer
scientists
but
yeah.
I
I
go
to
the
yellow
paper,
but
when
I
need
to
when
I'm
implementing
or
designing
and
need
to
make
sure
that
I
have
things
right,
I
go
to
the
yellow
paper
right.
F
Right
but
I
think
that's
kind
of
the
thing.
It
feels
like
there's
a
disagreement
here
where,
like
you,
kind
of
refer
to
the
python
spec
as
like
client
code,
but
it's
it's
not
quite
that
like
yes,
it
it,
it
does
run
and
it
does
take
the
main
net,
but
like
it's
not
like
practical
to
use
as
a
as
a
node
on
the
ethereum
network.
F
So
it's
like
it's
more
like
a
translation
of
the
yellow
paper
into
python
than
it
is
like
client
code,
and
I
think
I
don't
know,
I
think
the
amount
of
people
who
will
find
that-
and
I
mean
you
know
even
assuming
you
know,
math
and
and
python
equally
well,
the
yellow
paper
doesn't
really
have
diffs
as
well
as
well
established.
You
know,
I
I
don't.
F
Basically,
if
you
want
to
look
at
the
diff
between
two
hard
forks,
I'm
not
even
sure,
that's
possible,
because
last
time
I
checked
it's
andrew
from
from
aragon,
who
maintains
it
and,
like
will
typically
add
like
an
eip
at
the
time,
because
he
does
this
on
like
a
part-time
basis.
So
you
need
to
like
pull
together
like
the
set
of
commits
that
you
think
maps
to
a
hard
fork
to
get
like
a
diff.
It's
just
like
oh
yeah
yeah,
but
it's
like
assuming
the
comprehension
is
not
an
issue.
C
D
D
G
There's
also
nothing
stopping
people
from
continuing
to
maintain
the
yellow
paper
like
they
have
today
like
that
status
quo
can
continue
to
hold.
Maybe
they
won't
have
the
consensus
portion
of
it,
but
these
people
who
are
doing
it
today,
they're
free
to
continue
maintaining
and
the
people
who
are
reading
it
can
continue
using
that
as
their
resource.
D
Okay,
it's
this
is
I'll,
probably
wash
my
hands
of
this
at
some
point,
but
this
doesn't
sound
good,
we're,
there's
no
formal
spec
for
python
either
so
we're
building
on
sand.
But-
and
it's
not
it's
not
literate
programming.
So.
D
Given
given
the
wide
audience
for
the
spec
is
the
other
trouble,
you
should
be
able
to
read
the
english
and
still
get
the
gist
of
it.
D
I
mean
I
can
go
into
the
literature
with
a
lot
of
math
that
I
can't
follow
when
I'm
trying
to
just
chase
some
computer
science
ideas
I
want
to
implement
and
if
they're
well
written,
it's
sort
of
you
follow
the
english
it's
well
written
and
then
you
kind
of
go
math,
math,
math,
math,
math,
okay,
english,
okay,
I
follow
what
he's
doing
math
math
math,
I'm
not
quite
sure
what
the
hell
you
know,
but
that's
how
I
read
always.
D
It's
like,
oh,
I
can't
get
any
traction
here
at
all
yeah.
I
remember
I
just
go
through
pages
of
python
and
just
go.
I
don't
know
what's
going
on
here.
I
don't
know
what
the
concepts
are.
I
don't
know
what
the
purpose
is.
One
would
hope
that
I
don't
know
you
know,
I
don't
know
which
of
this
code
is
because
this
is
how
you
do
it
in
python
and
which
of
this
is
actual
spec.
B
So
I
think
that
I
mean
the
the
short
answer
to
which
is
spec
versus
which
is
python
is
what
is
a
what
is
externally
observable,
but
that
is
kind
of
a
cop-out
answer
because
determining
that
is
often
non-trivial.
I.
E
B
I
think
the
abs,
if
someone
who's,
writing
one
of
these
change
proposals.
My
hope
would
be
is
that
they
do
have.
You
know
some
english
commentary,
whether
that's
in
comments
or
if
it's
in,
like
the
markdown
file
as
in
the
abstract
section
or
something
so
a
person
hopefully
will
still
be
able
to
approach
these
change
sets
and
get
a
rough
idea
of
what
they're
trying
to
do
without
reading
the
python.
B
Now,
if
you
want
to
get
details
of
what
they're
doing
and
you
want
to
be
able
to
implement
it,
then
you'll
probably
yes
need
to
be
able
to
read
the
python,
but
if
you
just
want
to
know
like
you
know,
what
is
this
eip
proposing
like
the
again
the
abstract
comments,
those
should
be
sufficient.
If
they're
not,
I
would
say
that
the
authors
are
not
doing
a
good
job
like
this.
B
The
python
I
don't
know,
maybe
maybe
that's
too
strong,
of
a
statement.
Let
me
take
that
back
and
think
on
it.
A
So
maybe
in
the
essence
of
time
we
can
maybe
try
to
summarize
this
thing
and
look
into
probable
next
step.
I
I
am
like,
in
agreement
with
tim,
that
having
a
unified
process
for
el
ncl
will
be
good,
because
el
have
been
using
the
eip
process
for
whatever
the
process
is
as
of
now
but
cl.
It
is
going
to
be
a
new
process
altogether
to
have
an
eip
process
in
place.
A
So
if
we
give
them
something
which
is
closer
to
what
they
have
been
doing
in
the
past,
I
mean
like
the
process
that
they
have
been
following,
not
the
eip
per
se.
I
guess
that
would
be
helpful
and
again
again
agreeing
to
micah
that
there
will
always
be
a
subset
of
people
who
would
be
in
disagreement,
so
we
should.
We
should
understand
that
there
is
always
a
trade-off
of
new
process.
We
get
something
and
we
have
to
drop
something.
It
seems
like
the
proposed
process
for
using
python
is
something
that
again
in
work
in
progress.
A
Obviously,
we
haven't
built
up
the
complete
specs
so
far,
but
that
is
that
has
made
good
progress.
Sam
and
team
are
doing
doing
a
great
job
over
there
and
we
hope
that
it
will
be
really
close
to
the
main
net
spec
and
coming
back
to
greg's
point.
Like
maintenance
may
be
a
problem.
I
think,
when
a
process
is
in
place,
we
would
like
to
find
people
they
they
could
be
helping
out
maintaining
it.
A
So
if
there
is
a
challenge
to
just
have
it
that
they
live
in
the
python,
we
can
definitely
look
out
for
people.
We
can
set
out
bounty
if
we
don't
get
any
volunteers
or
we
can
look
into
other
options
just,
but
I
think,
moving
ahead
with
a
general
consensus
would
be
useful
and
helpful
on
the
larger,
larger
context.
Just
a
question
for
tim,
I
I
am
assuming
that
it
was
supposed
to
be
discussed
among
client
teams
and,
generally
speaking,
they
are
in
agreement
with
the
proposed
process.
F
So
I
don't
know
that
we've
made
like
a
formal
proposal,
like
obviously
we've
mentioned
this
a
couple
times,
and
I
do
think
like
what
so
so
so
first,
you
know
like
the
pi
spec
is
not
is
not
complete
yet
like
it's
it's
getting
there,
but
it's
not
like
up
to
the
main
net.
Yet,
obviously,
client
teams
are
very
busy
with
the
merge
so
like
the
amount
of
time
they
can
spend.
Looking
at
this
is
quite
small.
F
I
feel
like
what
might
be
helpful
is
trying
to
list
out
like
okay,
what
is
like
the
general
approach,
what
are
like
the
concerns
we
see
and
and
how
we
could
address
them,
because
I
don't
I
like,
I
feel
like
greg.
Obviously
you
have
like
some
objections
and,
like
we've
gone
around
them
many
times,
but
at
some
point
you
know
we're
gonna
need
to
make
a
call
and
and
decide
even
if,
like
it's
not
perfect,
so
I
you
know.
D
F
C
C
A
F
Yeah-
and
I
think
I
don't
know,
if
obviously
like
we're
not
gonna
like
we
have
a
spec
for
the
merge,
and
this
is
not
gonna
be
used
for
the
merge.
I
think
shanghai
is
probably
like-
maybe
the
first
fork
which
we
could
do
both
processes
in
parallel
or
something
and
then
like.
Realistically,
if
we
move
to
that,
it
would
be
like
the
fork.
After
that
we
deprecate
the
other
process,
which
is
still
like
much.
F
Yeah
yeah,
so
I,
but
that
said
like
if
yeah
before,
basically
sam
and
his
team
put
another
year
of
work
into
this,
you,
I
think
it's
valuable
to
have
like
a
general
sense
of
buy-in
from
like
client
teams
and
also
like
a
list
of
like
concerns
and
like
potential
solutions
to
them
and
there's
a
bunch
of
like
concerns
that,
like
we
discussed
about
just
like
how
the
specs
works,
but
then
there's
a
no.
This
whole
other
kind
of
level
of
like
shedding
around
like
how
the
entire
process
works
together,
but
yeah.
I.
A
Right,
yeah
right,
I
think
we
can
probably
use
greg's
suggestion
here.
He
earlier
mentioned
that
there
is
enough
no
formal
eip
proposed
for
this
changed
proposal.
I'm
assuming
we
could
be
having
a
meta
e,
because
this
is
a
great
change
in
prop
process
and
informational
or
any
other
eip
will
not
be
a
good
fit
for
it.
So
we
may
be
looking
for
someone
who
can
maybe
propose
a
meta
eep
for
this
change
process,
and
then
we
take
that
eep
to
the
client
team
asking
for
their
feedback
and
suggestion.
C
So
I
think
the
reason
why
we
haven't
gone
to
core
devs
with
a
formal
proposal
yet
is
because
we
wanted
to
have
like
not
a
unified
front,
but
at
least
have
some
rough
consensus
among
eip
editors
on
a
final
process,
and
then
we
go
to
core
devs
and
be
like.
Is
this
acceptable
to
you
guys
and
we
take
up
as
little
of
their
time
as
possible?
But
since
we
can't
reach
consensus
here,
maybe
we
go
to
them
with
something
a
little
bit
less
fully
baked.
B
I
would
at
least
like
to
so,
if
we're
gonna
do
that,
I
would
at
least
like
to
have
the
process
the
proposed
process
to
find,
which
I
still
think
we're.
We
don't
have
that
either
like
even
if
we
ignore
greg's
concerns
like
I
still
still
don't
think
we're
we're
there.
I'm
not
suggesting
concern.
D
You
know,
certainly,
if
I'm
maintaining
a
client,
I
don't
want
to
have
to
deal
with
random
prs
coming
in
because
most
likely
I'll
have
to
go
what
the
hell
are
they
actually
trying
to
accomplish
with
this
pr.
Okay,
that's
not
a
good
way
to
accomplish
it,
but
now
I
I
can
back
that
pr
out
and
do
it
the
right
way,
but
I
can
go
on
and
on,
but
you
know
first
that
needs
to
be
there.
It
needs
to
work.
D
F
Maybe
a
way
to
do
that
and
like
kind
of
based
on
micah's
point,
is
like
coming
up
with
a
process
that
we
could
use
for
shanghai
and
parallel
to
the
eip
process
as
like
a
sort
of
case
study
or
something
that
like
right,
obviously
won't
be
perfect,
but
we
we
can
iterate
on.
I
I
I
I
feel
like
that
could
be
a
good
way
like
it
forces
us
to
iron
us
iron
out
the
kinks
of
the
you
know
the
executable,
specs
and,
and
obviously.
F
F
A
A
I
will
try
to
reach
out
to
these
two
editors
who
are
not
on
the
call
and
try
to
like
get
their
feelings
where
they
are
and
in
the
meanwhile,
if
either
sam
or
tim,
we
can
have
a
proposal
to
kind
of
propose
this
new
process,
as
proposed
by
tim,
that
it
can
be
done
in
parallel
for
shanghai.
I
guess
that
would
be
a
good
trial
run.
A
A
Okay,
so
the
proposal
that
is
linked
here
is
a
hackmd
file
proposed
by
tim.
One
final
question
is
like:
are
we
planning
to
create
this
eip
based
on
this,
or
is
there
any
change
in
the
proposal?
Because
if
I
remember
correctly,
there
was
a
minor
change
which
was
discussed
in
one
of
the
earlier
eipip
meetings.
So
where
do
we
stand
there.
C
A
Okay,
if
it
is
not
too
much
of
a
hassle
sam,
would
you
be
willing
to
maybe
propose
a
proposal
based
on
your
hack,
md
and
tim?
You
propose
a
proposal
on
your.
How
can
we
that'd
be.
F
I'm
happy
to
work
with
sam
and
like
go
off
his
his
proposal
and
and
yeah.
I
guess
we
can
use
the
eip
editing
channel
is
that
okay.
A
C
So
one
thing
I
want
to
ask
which
eip
editing
channel
is
the
one
to
discuss.
A
C
A
A
A
Agreed
that's
right.
Yeah
I
mean
if
that
is
something
on
like
ethereum
level,
we
try
to
generally
discuss
it
on
the
rnd,
but
if
there
is
something
discussed
on
a
subset
level,
then
we
try
to
move
the
discussion
to
cataracts,
but
I'm
happy
to
share
that
all
eip
editors
are
on
cathodes.
So
if
there
is
anything
missed
out,
we
can
probably
share
it
on
both
the
channels
that
should
not
be
a
problem.
Okay,
just
to
maybe
summarize
this,
we
are
on
agreement
that
we
would
give
it
a
try
to
the
new
process.
A
A
A
There
was
just
a
one
action
item
section
and
I'm
looking
into
it
one
action
item
that
I
could
not
finish
it
up.
Maybe
I
will
bring
it
up
in
the
next
meeting.
That
was
a
collect
feedback
regarding
one
time,
nft
sale
of
unused
eip
numbers,
so
I
will
try
to
reach
out
to
people
and
collect
some
feedback
and
then
we'll
bring
this
item
in
the
next
meeting
and
rest
all
seems
to
be
covered.
A
Well,
thank
you.
Everyone
for
staying
a
few
minutes
longer
on
that
call.
I
hope
to
see
you
all
in
two
weeks.
The
next
meeting
is
planned
on
june
29
at
1400
utc
thanks.
Everyone
have
a.