►
From YouTube: EIPIP meeting 36
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/75
A
All
right
welcome
to
eipip
meeting
36..
I
have
shared
the
agenda
in
the
chat
and
the
first
item
on
the
agenda
is
evolving
eip
process.
So
we
have
been
discussing
this
from
the
past
few
meetings
and
I
wanted
to
bring
it
up
to
this
meeting,
particularly
as
an
agenda
item.
So
we
can
discuss
how
we
are
looking
into
the
changes
that
that
can
be
expected
with
the
merge
and
like
future
upgrades
so
yeah.
I
like
that.
If
you
would
like
to
go
ahead
and
share
your
thoughts
on
it,.
B
Sure
so
we
originally
like
got
this
idea
from
kind
of
how
east
2
has
been
handling
discussing
core
changes,
and
it
feels
like
the
way
you
know
the
way
they
do
it
they're
able
to
kind
of
create
just
a
diff
against
their
specs,
since
they
have
this
executable,
pi
spec.
B
I
think
1559
is
a
good
example
of
something
that
basically
implements
not
in
working
ethereum
clients
just
to
show
the
things
that
it's
trying
to
change
and
that's
kind
of
like
where
our
motivation
came
from
just
seeing
how
things
are
not
working
as
well
for
either
one
and
how
they've
been
successful
in
these
two.
B
B
So
I'm
curious:
if
what,
if
people
have
thoughts
around
that,
I
don't
think
that
eips
or
like
the
concept
of
them
will
go
away,
because
I
think
that
there
is
a
lot
of
value
in
a
lot
of
the
pros
that
goes
into
an
eip
just
defining
like.
Why
do
we
want
to
make
this
change?
What's
the
rationale
for
these
things?
To
me,
this
is,
you
know,
really
replacing
the
specification
part,
because
to
me
the
specification
part
is
where
we're
creating
like
a
lot
of
duplication.
C
C
I
know
a
lot
of
people
disagree
with
me
on
this.
I
believe
that
motivation,
rationale
etc
is
transient
for,
like
a
better
word
like
it,
does
it's
not
something
that
needs
to
survive
forever
like
we
don't
need
to.
You
know,
have
a
permanent
record
of
why
it
was
decided
that
we
added
chain
id
to
specification
four
years
ago
or
whatever
it
was.
That
being
said,
I
have
no
problem
with
storing
that
information
somewhere,
but
I
don't
think
it
needs
to
be
like
in
version
control.
C
I
think
it's
fine,
if
that's
just
like
on
a
doc
site
or
inside
a
hackmd
article
or
in
a
blog
or
something
like
that,
like
I
feel
like
we're
in
a
youtube
video
where
a
peep
and
eat
type,
video
or
someone
talks
about
it
like.
I
think
those
are
all
very
reasonable
places
to
store
motivation
and
reasoning
for
things.
C
I
think
the
spec
is
the
piece
that
must
be
stored
in
version
control
system
and
have
history
and
like
be
easy
to
diff,
be
easy
to
see
the
change
set
stuff
like
that,
so
so
yeah
so
I'd
my
preference
just
put
all
the
other
stuff.
That's
not
the
spec
itself
into
the
pr,
and
then
it's
okay.
If
that
kind
of
goes
away
over
time,.
B
I
think,
like
one
interesting
model
that
we
could
learn
from
is
how
rust
does
rfcs
against
the
language.
They
seem
to
be
similar
to
eaps
in
a
lot
of
ways.
They
have
these
things
like
summary
and
motivation,
and
talk
a
little
bit
about
how
did
they
come
up
with
this
idea,
and
then
they
link
to
github
prs
and
issues
the
top
that
either
like
implement
these
or
places
that
a
lot
of
discussion
happens
on
those.
B
B
Tend
to
agree
that
I
don't
think
eips
necessarily
like
the
text
around
it
or
things
that
have
to
be
version
controlled
and
live
forever,
but
I
do
appreciate
the
ease
at
which
you
can
find
the
stuff.
Like
I'm
curious
about
some
certain
feature
and
rust.
It's
really
simple
for
me
to
pull
up
the
rfc
and
then
I
can
immediately
just
read
like
a
brief
summary,
and
these
are
things
that
are
like
kind
of
informal
they're,
not
really
really
long
things,
they're
generally
just
really
quick
summaries
and
like
motivating
reasonings
and
then.
B
Out
to
these
places,
these
github
places
where
I
can
see:
okay,
here's
where,
like
a
lot
of
discussion,
happened,
these
are
kind
of
the
entry
points,
and
so
that
might
be
an
interesting
way.
I
think
it
like
kind
of
removes
it.
It
avoids
fully
removing
this
idea
of
eips,
like
I'm,
not
sure
how
a
lot
of
people
feel
about
that.
I'm
afraid
that
a
lot
of
people
will
say:
oh
well,
we
like
eips,
that's
what
ethereum
is,
and
here
at
least
we
get
to
keep.
B
Yeah,
so
yeah
I'd
be
curious
to,
unfortunately
the
problem
is
it's
just
a
different
format
than
we
have
eaps
already
like
it's
a
little
more
informal.
It
really
just
focus
on
linking
to
these
github
things
and
so
yeah
anytime.
We
make
a
big
change
to
the
eeps
repo,
it's
not
clear
how
to
retroactively
apply
stuff
or
if
they
should
be
retroactively,
applied
at
all.
A
So
on
the
thought
of
removing
the
idea
of
eip,
like
completely
I
mean-
maybe
I
am
in
the
cam
that
I
would
say
that
let
it
be
there
for
some
more
time.
It's
really
helpful
for
new
people
like
I'll,
consider
myself
to
be
relatively
very
new.
Who
is
trying
to
understand
the
process
and
read
about
these
proposals.
A
While
doing
my
research
like
earlier,
when
I
learned
about
eips
and
proposals,
there
were
different
categories.
I
got
it
from
eip1
and
started
reading
about
it
doing
my
research,
but
while
my
research,
I
I
came
to
know
that
there
was
eip4
which
was
actually
superseded
by
eip1
and
there
we
get
all
these
types
and
categories.
A
So
if
we
find
the
history
that
would
help
us
connect
the
dot,
so
maybe
we
can
keep
the
history
but
the
template
how
we
store
it
could
be
different,
maybe
in
the
if
we
say,
for
example,
if
we
want
to
keep
it
in
hack
md,
let
it
be
like
it's
dot.
Md
file
is
also
not
bad.
Maybe
we
can
change
in
the
template
of
eips
and
move
the
technical
part
directly
as
a
pull
request
and
keep
the
other
content
the
relevant
or
the
text
part
in
this
hackmd
or
maybe
dot
md
file.
C
Another
idea,
if
we
want
to
do
a
slow
transition
like
we
don't
want
to
just
go
all
in,
we
could
just
keep
the
eips
as
they
are
and
just
change
so
that
the
specification
section
now
just
needs
to
link
to
a
pr
against
the
specs
repo
and
that's
it
and
anything
else
in
specification.
Section
is
invalid
and
that's
just
the
entire
specification
section
everything
else
stays
the
same.
That
would
be
a
very
easy
transition.
It
would
vary.
I
don't
think
anyone
really
disagree
with
that
strongly.
C
It's
nice
and
simple
and
make
sure
that
we're
getting
keeping
the
specs
repo
up
to
date
and
it
gets
people
used
to
doing
stuff
to
the
specs
repo.
But
it's
non-contentious.
C
E
D
C
Change
to
the
the
process
itself,
which
is
unlikely
to
get
a
lot
of
negative
pushback,
whereas
if
we
try
to
do
what
I
would
like,
I
suspect,
like
matt
indicated:
everybody's
gonna
disagree
with
it
and
we
might
gain
nothing
by
trying
to
do
too
much
of
one.
A
That's
right,
yeah
I
mean
I
am
in
very
much
agreement
with
michael's
proposal
about
having
the
spec
section
submitted
as
a
pull
request
and
that's
how
we
make
changes
so
like
this
idea
looks
good
to
me,
but
yeah
obviously
I'll
be
curious
to
know
what
other
people
think.
F
A
So
there
was
this
another
idea
of
like
when
we
are
talking
about
network
upgrade
and
network
upgrade
process.
There
was
another
thought
around
kind
of
for
differentiating
the
the
category
of
the
proposals
right.
So
there
are
proposals
for
protocol
changes
and
there
are
some
for
future
changes.
A
A
B
Yeah
I
mean
I
still
like
very
much
in
the
camp
that
there
just
needs
to
be
a
little
bit
more
leadership
in
at
the
core
layer.
In
terms
of
I
know,
that's
crazy
thing
to
say,
but
and.
B
I'm
not
asking
for
like
a
dictator
or
something
to
say
this
is
what
ethereum
is
because
I
say
it
is
I'm
just.
I
think
that
there
are
already
like
informal
leaders
who
have
ideas
of
things
that
you
know
we
should
be
doing
and
working
for,
I
think,
like
vitalik
is
a
has
been
a
great
leader
of
ethereum.
B
B
That
may
not
be
compatible,
so
I
think
that
if
we
had
a
little
bit
more
leadership
and
have
a
little
bit
more
responsibility
delegated
to
people
for
like
certain
areas
as
in
you
know,
you
are
kind
of
the
people
who
are
in
charge
of
looking
into
these
types
of
things:
improving
the
ux
of
ethereum,
improving
state
of
ethereum,
and
we,
like
informally,
have
a
lot
of
this
stuff.
But
it's
not
nothing
is
defined.
There's
no!
There's
zero
structure
around
these
things.
A
Yeah,
I
think
that
is
what
what
we
can
do
as
a
group
here
in
this
eipip
meeting
like
can
define
a
structure.
I
was
looking
into
like
older
proposals,
and
I
found
that
the
abstraction
of
transaction
that
was
originally
you
know
written
by
vitalik.
That
is
also
still
in
draft
status
right
now.
So
there
are.
A
These
are
important
proposals.
These
are
good
proposals,
but
they
get
lost,
maybe
because
we
do
not
have
a
process
defined
for
how
to
deal
with
these
kind
of
proposals.
Similar
similar
thing
was
also
there
for
some
of
the
networking
layer
proposals.
Proposals
are
implemented,
they
are
being
you
know,
deployed
in
a
client
and
they
are
being
used,
but
they
are
still
in.
Like
older
status,
I
mean,
maybe
because
of
author
forgot,
to
create
a
pull
request,
but
I
believe
sometimes
it
is
included
in
upgrade,
and
sometimes
it
is
not.
A
C
C
F
C
Yes,
like
in
a
very
simplified
version,
usually
there's
a
lot
more
delegation
involved.
So
you
have
someone
at
the
top
who
is
doing
very.
C
Yeah,
so
if
you
get
into
a
deadlock
specifically,
you
can
escalate
up
and
have
somebody
call,
and
even
if
that
person
doesn't
have
actual
authority
like
the
structure
is
flat
just
having
a
tiebreaker
like
having
someone
who
just
makes
a
call
often
is
very
valuable,
doesn't
even
matter
what
the
call
is
more
often
than
not
like
you
just
have
a
business
decision
that
needs
to
be
made.
It
doesn't
actually
matter.
What's
decision
is
made
it
just
a
decision
needs
to
be
made
and
ethereum
struggles
with
making
decisions.
C
We
saw
this
with
product
proof
of
work.
It's
like
the
canonical
example
of
not
being
able
to
make
a
decision
and
resulting
in
massive
amounts
of
engineering
waste,
because
just
because
we
couldn't
actually
decide
on
what
to
do,
whereas
in
a
traditional
company
you
know
you'd
have
someone
would
have
made
a
call
like
you
know,
long
before
you
spend
thousands
of
engineering
hours
on
both
sides.
Someone
would
have
just
been
like
we're
doing
this
or
we're
not
doing
this
yep.
That's
it
doesn't
even
matter
like
again.
C
F
G
C
F
C
So
yeah,
so
yes,
so
the
the
issue.
It
often
is
that
we
we
get.
We
get
into
a
stalemate
where
everybody
knows
what
everybody
else's
position
is
like,
at
least
within
the
courthouse
like
there's.
Definitely
within
the
community.
There
is
lots
of
misinformation
and
lots
of
uncertainty
and
lots
of
understanding
within
the
core
devs.
At
least
we
can
usually
get
to
a
place
where
everybody
understands
everybody
else's
position.
C
There's
just
like
there's
some
core
premise:
that
people
just
fundamentally
agree
on
like
some
like
kind
of
root,
belief
system.
Sometimes
it's
a
belief
system.
Sometimes
it's
just
like
a
disagreement
in
style
like
just.
I
was
raised
this
way,
and
this
was
more
comfortable
for
me
versus.
I
was
raised
this
way
and
this
is
more
comfortable
for
me
and
those
are
the
ones
that
I
think
we
really
struggle
with
is
when
the
it's
not
that
we
don't
understand
each
other's
positions.
C
F
F
All
that
needs
to
be
seriously
measured.
So
if
you
can
see
that
75
of
all
of
the
core
devs
and
everyone
are
clearly
on
board
and
the
noisy
people
that
are
that,
are
against
it
and
saying
there's
going
to
be
a
fork,
if
you
can
see
that
then
making
those
decisions
become,
it
can
become
a
decision.
If
you
see
75
percent
people
are
on
board
and
25
percent
people
aren't
versus
everyone.
Just
polarizing
says:
there's
going
to
be
a
fork
and
yelling
and
there's
going
to
be
four.
Can
you
do
this.
C
I
don't
think
the
core
devs
actually
listen,
that
much
to
people
who
yell
and
scream
fork.
I
think
there
are
a
few
core
devs
who
do,
but
the
impression
I
get
is
that
most
of
them
are
pretty
ambivalent,
like
most
of
them
seem
to
be
in
the
general
camp
of
forks
are
an
acceptable
form
of
governance.
If
two
groups
disagree
strongly
enough,
forking
is
the
appropriate
way
to
deal
with
that
situation,
and
that's.
Okay,
there's
definitely
people
in
the
community
that
disagree
very
strongly
with
this,
like
they
do.
C
Fiefdoms
so
so
yeah,
so
I
think
the
idea
the
idea
is
is
that
in
in
most
cases,
people
aren't
willing
to
fork
over
a
thing
like
you
have
to
be
pretty
big
and
significant,
like
the
dao
was
an
example
of
a
significant
enough
disagreement
that
caused
an
actual
fork
for
pretty
much
everything
else.
It's
not
enough
to
fork
over
like
prague,
pow
as
an
again
as
an
example.
I
don't
think.
C
C
H
Mechanic
also
because
contentious
forks
that
involve
something
that's
perceived
as
an
economic
blow
to
minors,
further
incentivizes
a
fork,
so
even
if
like
the
community
at
large,
might
not
support
it.
The
mining
community
might,
I
wouldn't
say
arbitrarily,
but
I
would
say
our
I
would
say:
the
mining
community
is
capable
of
making
a
decision.
That's
largely
independent
of
the
rest
of
the
ecosystem
sentiment
if
they.
H
Defending
their
own
that
their
own
holdings,
so
I
know-
and
prague
gets
a
bit
funny
that
way,
I'm
trying
to
predict
exactly
what
would
have
happened.
C
When
I
say
fork,
I
specifically
mean
a
a
fork
where
there
are
actual
users
on
both
sides
of
the
chain,
a
fork
where
it's
just
a
bunch
of
miners
who
just
go
off
and
do
their
own
thing
and
no
one
actually
uses
it.
That
happens
every
single
time.
We
have
okay
every
hard
fork.
C
There
are
miners
who
forget
to
upgrade,
and
they
just
keep
mining
the
old
chain
for
quite
a
while,
sometimes
like
that
is
very
normal,
and
what
specifically
a
contentious
fork
I
think
of
like,
etc,
is
the
only
one
that
ethereums
have.
I.
A
So
that
also
brings
me
to
a
point
where
I
wanted
to
bring
it
up
about
the
fork.
Identifier
right,
that
is,
this
proposal
is
a
network
layer
proposal,
and
I
know
that
is
already
implemented
in
get
so
someone
please
help
me
understand
that
so
I'm
I
have
not
complete
understanding
of
it
is
if
it
is
implemented
in
all
the
clients
or
just
get
only.
A
I
know
for
sure
that
is
there
in
the
gap,
but
is
it
helping
miners
like
getting
on
the
right
chain
if
that
is
included
with
the
latest
version
of
geth,
when
it
is
ready
for
any
network.
A
A
So
the
proposal
is
in
the
last
call.
We
had
invited
the
author
to
explain
about
the
proposal
and
there
is
a
very
good
video
on
peep
and
eve
about
this
proposal,
explaining
how
it
is
going
to
help
identify
the
right
chain,
because
they
they
don't
have
just
chain
id.
They
also
provide
identifier
for
every
upgrade.
So
that
may
be
very
helpful
for
miners
to
you
know,
find
the
correct
one.
Oh.
C
Yeah,
I
see
no,
so
this
wouldn't
help
with
miners
forking
off
during
every
hard
fork.
This
is
basically
just
to
the
way
the
gossip
network
works.
You
basically
just
kind
of
broadcast
out
and
talk
to
everybody,
and
you
try
to
find
people
that
are
on
the
same
chain
as
you.
It
would
be.
C
I
think
if
I
understand
it
correctly,
they're
basically
just
trying
to
make
it
so
you
can
segregate,
and
so,
when
you
open
up
a
channel
to
talk
to
somebody,
you
can
very
quickly
identify
oh
you're,
not
the
person
I'm
interested
in
talking
to.
I
want
to
talk
to
because
I'm
you
know
following
this
other
fork
than
you
are
so
that
way.
If
something
like
ath
dtc
happens,
you
don't
have
people,
you
know
still
gossiping
with
each
other.
It's
just
basically,
it's
a
network,
bandwidth,
saving
thing
more
or
less
performance
improvement.
C
A
A
Yeah
yeah
so
yeah
I
was
wondering
like
if
there
is
any
such
proposal,
which
are
there
for
improvement
of
network
layer,
they
are
generally,
I
have
not
seen
most
of
them
in
in
upgrades.
I
was
going
through
the
history
of
upgrades
and
looking
into
the
proposals
I
found
one.
I
think
there
was
one
eip8
that
was
accepted
in
homestead,
but
other
than
that.
No
other
proposals
are
there.
Okay,
if
I
followed
all
of
them,
then.
C
So
so
I
think,
there's
I
think,
there's
two
reasons
for
that.
One
network
network
changes
are
actually
pretty
rare.
We
don't
change
the
network
protocol
very
often
and
two
they
they
can
kind
of
have
because
they're
versions
and
you
could
the
clients
can
be
on
different
versions.
C
Usually
it's
felix
and
the
guest
team,
who
you
know
talks
about
something
they
propose
an
eip
and
then
you'll
see
they
actually
are
a
handful
of
network
network
eips,
it's
just
like
because
they
don't
need
to
go
to
final.
They
usually
just
get
forgotten
once
they
get
close,
and
so
I
suspect
a
number
of
these
are
actually.
A
Yeah
I
mean
like
it
would
be
good
to
have
them
as
finals
as
well
like
I
know
there
are
quite
a
few
version
of.
D
A
C
I
wouldn't
say:
superseded
like
you,
you
can
have
a
client
that
speaks
only
64.
talk
to
a
client
speak
64
and
65.
C
geth,
I
believe,
is
actually
going
to
drop
63
and
lower
soon,
and
then
they
won't
be
able
to
talk
to
people
who
are
not
on
64
or
higher
if
they
remember
correctly
so
yeah.
So
we
definitely
should
get
864
needs
65
out
of
draft
like
they
should
be
final.
I
think,
because
I
think
they're
in
production
now.
A
Right
and
same
for
66,
that
is
there
in
the
review
for
a
while.
C
D
Deprecating
64
and
65.
D
C
Okay,
I
believe
that's
yeah,
so
we
should
definitely
get
all
those
merged
and
moved
up.
Talk
to
felix
is
probably
the
best
person
to
talk
to.
They
definitely
understand
the
protocol
and
like
if
you
wanted
to
just
rope,
someone
in
and
say,
hey
can
just
here's
a
list
of
vips.
Can
you
tell
me
which
of
these
should
we
move
to
final?
Felix
is
probably
the
one
to
be
able
to
answer
that
easily.
A
Yeah
right
right,
I
will,
I
will
reach
out
to
him
on
this
week
and
we'll
create
pull
requests
for
at
least
which
are
in
like
draft
and
they
need
to
be
moved,
but
for
the
review
one,
I
will
request
author
to
move
it
all
right.
So
bottom
line
is
like
I
was
just
trying
to
understand
for
this
proposals
like
there
are
three
questions.
Three
open
questions.
A
As
per
my
understanding
like
one
are,
we
planning
to
have
like
code
proposals
going
the
same
way
as
it
is
going
for
now
for
the
network
upgrade,
irrespective
of
if
it
is
a
protocol,
change
or
a
feature
change.
Let's,
let's
come
with
the
same
process
and
the
next
one
was
for
net
network
upgrade
proposals,
network
layer
proposals.
Can
we
do
anything
about
it
or
it's
just
that
we
will
be
reaching
out
to
author,
because
these
are
not
very
frequent.
We
shouldn't
be
worried
or
bothered
much
about
it.
C
I'm
fine
with
network
just
following
this
same
process
as
core.
I
think
it's
just
a
matter
of
they're
just
infrequent
and
so
that
and
they
don't
need
to
follow
the
process
like
there's,
nothing
forcing
them
to
like
with
all
core
devs,
and
so
I
think
it's
just
a
matter
of
you
know.
Just
we
need
to
be
proactive
in.
A
A
And
their
inclusion
in
any
upgrade,
does
it
have
any
significance?
Should
we
or
should
we
not.
C
A
C
C
A
All
right,
I
think
this
topic
might
need
more
discussion,
so
we'll
get
back
on
this.
Maybe
in
the
next
meeting
we'll
have
some
more
thoughts
around
it
and
try
to
document
whatever
we
have
discussed
in
this
meeting
and
we'll
take
it
from
there.
A
Okay,
moving
on
the
next
item
is
a
new
eip
erc
editors
in
training
progress.
I
know
we
have
william
here
on
the
call,
and
there
was
some
discussion
in
the
discord
channel
as
well.
Anyone
would
like
to
give
any
update
on
how
we
are
doing
on
it
or
like
is
there
any
challenge
people
are
facing
that
might
need
attention.
C
H
C
D
H
That
being
said,
I
guess
on
a
more
serious
note.
I
have
not
put
in
very
many
hours
this
last
month.
I
am
hoping
that
the
future
does
yield
me
a
bit
more
time
for
that
there
were
a
few
things
sort
of
extended
waiting
for
me
this
month.
That
being
said,
it
is
something
I'm
keeping
an
eye
on,
and
if
I
see
that
consistently
that
I
don't
have
the
time
to
dedicate
to
it,
I'll
probably
withdraw
from
the
from
the
position
and
just
to
allow
someone
more
productive
than
me.
A
It's
actually
like
I,
I
would
suggest
that
do
not
withdraw
it.
Yet
we
need
people,
it
doesn't
matter
that,
like
you,
know,
you're
giving
one
hour
or
like
five.
H
H
A
In
the
meanwhile,
I
was
just
talking
to
light
client
and
we
were
thinking
of
having
a
recording
on
like
how
editing
works.
Maybe
I
I
can
have
my
lifeline
both
on
a
call,
maybe
in
an
episode
of
people
where
we
can
record
how
the
process
work
and
explain
it.
That
might
be
helpful
for
new
people
like
what
all
tiny
details
that
they
might
have
to
look
into
yeah.
H
To
be
honest
as
weird
as
this
sounds
like
client,
if
you
are
open
to
have,
I
guess
I
don't
have
a
better
term
for
this
than
like
a
ride-along,
or
something
like
that.
If
you're
about
to
do
some
eiping
or.
H
That
that
actually
doesn't
sound,
very
good
and
you'd
be
willing
to
have
me
kind
of
tag
along
or
something
like
that.
I.
D
D
B
Yeah
yeah,
I
think
I
mentioned
something
like
that.
That
would
probably
be
a
good
thing
to
do.
I
just
need
to
figure
out
yeah.
Maybe
we
can
huddle
together
after
this
call
and
figure
out
like
a
good
time
to
do
maybe
one
hour
every
week
or
two.
D
A
Right
yeah,
we
were
thinking
about
it
like
maybe,
meanwhile,
if
we
can
record
something
on
like
ama
kind
of
this
frequently
asked
questions
that
people
have
around
or
get
in
touch
with
all
these
people.
I
know
trent.
You
have
also
volunteered
to
do
that
and
william
is
there,
and
there
was
another
guy.
I
don't
know
he's
not
in
the
meeting
today,
so
we'll
check
with
him
too,
and
anyone
else
interested
to
generally
learn.
How
does
this
process
work
because
we
would
want
more
and
more
people
to
join?
A
A
Meeting
all
right
moving
on
to
the
next
item
is
jason
rpc
api
spec
progress
update,
I
believe,
alita
you
mentioned
in
the
last
meeting
that
you
would
like
to
go
ahead
and
provide
update
every
meeting
about.
What's
going
on
in
there.
I
Yeah,
so
basically,
in
the
past
week
we
have
gotten
through
most
of
what
I
mentioned
in
the
last
issue.
I
guess
I
didn't.
I
was
too
busy
to
fill
it
out
for
for
this
time,
but
like
are
there
any
endpoints
that
are
particularly
particularly
important
for
us
to
focus
on
over
the
next
two
weeks.
I
Okay,
do
you
know
offhand
what
those
ones
are.
B
I
wouldn't
actually
say
the
15
59
ones,
because
right
now
we
are
we've
kept
two
separate
implementations
of
the
spec
and
the
one
that's
in
the
eth1
specs
repo
has
the
1559
ones
and
is
kind
of
the
coordination
point,
and
I'm
just
like
keeping
those
updated
for
now
until
the
fork
passes,
but
yeah
we'll
we'll
transition
away
from
that
after
the
fork
passes.
So
it's
not
there's
not
like
a
strong
need
at
this
exact
moment
to
get
them.
B
It
was
just
talking
with
ted,
I
mean
we
are
using
this
process,
it's
just
which
specs
are
we
using,
and
I'm
would
rather
them
not
like
focus
on
the
one.
That's
apache
2
from
ethereum
classic
and
focus
on
the.
I
Speaking
of
which
that's
going
to
be
delayed,
probably
until
this
weekend,
because
I
have
been
very
busy
so
yeah,
but
I
did
promise
that
for
for
today,
so
that's
a
bit
of
an
update
but
yeah
I
will
have
pr
finished
and
I
mean
I'm
probably
just
gonna
merge
it.
If
that's
okay
with
you
all
I
mean
I
guess
you
know
you
all
can
review
it,
but
I
don't
know
it's
gonna
be
a
long
pr.
So
I
guess
michael
likes
to
read
long
pr's.
But
just
let
me
know.
I
But
anyway,
so
yeah,
there's
like
essentially
if
there,
if
anything,
comes
up
where
there's
like
specific
endpoints.
That
need
to
be
doing
that
need
doing,
let
me
know,
but
otherwise,
based
off
what
like
clients
said
and
micah
said,
I'm
probably
just
gonna
kind
of
prioritize
based
off
of
you
know
what
is
best
for
myself
and
for
the
person
working
who's
actually
doing.
I
The
work
here,
which
is
to
me
that,
like
they
don't
have
or
jared,
doesn't
have
a
lot
of
experience
yet,
and
so
I'm
trying
to
keep
it
somewhat
simple
to
to
kind
of
like
guide
that
learning
curve.
But
there's
a
lot
of
progress.
We've
been
doing
things
and
there's
also
a
major
discussion
right
now
about
format
which
is
like
kind
of
blocking
us
actually,
which
is
a
little
bit
frustrating
because,
like
I
think
it's
less
important
than
getting
things
out,
you
know
what
I
mean
like.
I
I
think
it's
easier
to
to
go
back
and
like
reformat
than
it
is
to
get
somebody
else
on
to
to
do
this.
So
it
makes
more
sense
to
me
to
just
kind
of
like
bite
the
bullet
until
we
can
figure
this
out.
As
far
as
formatting
and
just
go
with
whatever
we
have
right
now,
but
what
do
you
all
think
about
that.
C
I
Okay,
so
maybe
we'll
do
it
internally,
then
I
just
I
really
don't
want
to
slow
down
anything.
I
I
want
to
keep
things
moving
as
fast
as
they
possibly
can,
because
otherwise
you're
not
going
to
make
august
deadline
we're
already
very
much
so
I
mean
I
already
am
pretty
confident
that
we're
not
going
to
make
it,
but
if
we
slow
down
because
of
the
formatting
thing
that
we
are
definitely
not
going
to
and
so.
I
I
I
So
in
other
words,
my
point
is
that,
like
the
formatting
is
like
a
very
high
priority
right
now,
I'm
going
to
schedule
a
call
with
my
client
and
tomas
for
this
weekend
to
figure
this
out,
if
any,
if
anybody
else
is
interested
in
being
on
that,
please
let
me
know-
and
I
will
add
you
but
yeah-
it's
like
it
is
essentially
it's
saying
like
we
have
like
the
raw
information,
but
we
can't
deliver
and
if
you
can't
deliver,
then
you
just
have
a
bunch
of
work
in
progress
and
then
we
just
get
to
like
I
don't
know.
C
I
The
the
best
thing
I
can
think
of
is
just
this
weekend.
We
schedule
a
call
and
get
through
it
on
that
call
like.
Basically,
we
just
call
until
we
figure
it
out
so
yeah
I
it
was
supposed
to
be
this
past
weekend,
but
I
had
a
crisis
at
work
and
that's
resolved
now,
so
I
will
follow
up
with
it,
but.
I
I
guess
he
is
yeah.
I
can
also
message
in
his
mind.
B
If
you
just
ask
him
to
chat
in
the
jason
rpc
specs
discord
channel,
then.
I
Yeah,
I
think,
he's
a
little.
I
think
he
tends
to
be
a
little
bit
unresponsive
because
he's
very
busy.
I
I'm
not
totally
sure,
but
he
tends
to
be
a
little
bit
slow
at
times,
and
so
I
don't
know,
I
think
a
call
would
be
more
productive,
but
what
we
could?
What
I'll
do
is
I'll
do
an
async
as
well
as
schedule
a
call
just
so
that
we
hit
both
avenues
and
then
we
can
just
cancel
the
call
if
the
async
works
sounds.
A
Cool,
so
the
next
item
is
a
canonical
source
for
eips.
So
I
don't
know
brent
if
you
may
have
any
update
on.
F
A
Right
like
do
you
want
me
to
keep
it
on
recording
meeting,
or
should
we
take
it
off
and
one
you
have
yeah.
F
A
Right,
no
boys,
okay.
So
now
we
are
on
the
last
item.
It's
review
action
items
from
the
previous
meeting.
There
are
a
couple
of
tasks
that
were
like
coming
on
from
this
meeting.
I
just
want
to
quickly
have
a
like:
if
there
is
any
update,
the
one
is
eip
draft
banner.
Are
we
done
with
that
task
or
how
is
it
going.
I
Oh
yeah,
this
one.
I
have
unfortunately
not
finish
this
one.
I
don't
know,
maybe
I'm
gonna
see
if
somebody
else
wants
to
just
because
I'm
like
I
mean
I
can
do
it
like.
I
will
get
to
it.
It's
kind
of
like
how
what's
the
priority
of
this
item,
but
maybe
jerry
could
do
it.
I
don't
know.
A
I
think
if,
if
we
can
open
it
for
community,
I
mean
if
we
have
like
a
bandwidth
issue,
we
should
create
an
like
issue
and
share
it
in
our
discord.
We
have
so
many
people
from
like
you
know,
developers
community
as
well,
who
are
looking
to
contribute.
So
if
there
is
a
way
they
can
also
contribute
that
would
help
us
like
speed
up
the
task
and
yeah
I
mean
I
know
you
have
worked
on
it,
so
if
you're
around,
they
can
always
reach
out
to
you.
If
that's
okay
with
you.
I
Yeah,
of
course,
that
would
be
great.
I
think
I
think
just
posting
a
thing
saying:
hey:
are
you
interested
in
this
and
then
just
reach
out
to
elita?
If
you
are
and
then
I
can
give
them
what
I
have
right
now,
I'm
sure
that
there
is
not
I'm
sure
it
won't
take
that
long
for
whoever
ends
up
picking
it
up.
But
I
am
very
bandwidth
constrained
right
now
and
so
that's
resulting
in
unreasonable
delays.
A
A
The
next
task
that
we
discussed
sometimes
ago
was
a
boat
tracking
inactivity
period.
That
is
issue
73.
I
saw
jared
responding
on
that,
but
unfortunately
he's
not
there
wondering
if
you
have,
if
you
may
have
any
update
on
that.
A
Yeah
yeah,
it
is
issue
number
73.
I
see
your
comment
like
you
would
be
able
to
help
jared
working
on
this
staff.
It's
about
bot
tracking
inactivity
period
for
eips.ethereum.org,
so
they
can
move
the
proposals
to
the
appropriate
status
if
they
are
no
more
like.
You
know,
in
activity
for
a
very
long
time
and
that
withdrawn
status
or
so.
I
So,
in
this
case
I
don't
know
too
much
about
what's
happening
right
now.
I
do
know
that
jared
is
working
on
it
and
I
do
know
that
he
can
reach
out
to
me
with
questions,
but
I
do
not
have
a
status.
I
think
jared
has
been
working
very
hard
on
the
jason
rpc
stuff,
and
so
it's
feasible
that
he
and
he's
also
been
moving
recently
and
so
that's
feasible.
That
he's
been
unable
to
get
to
it.
Depending
on
the
like,
on
the
priority
of
this,
I
might
recommend
handing
off
to
someone
else.
I
I
can
you
know,
guide
and
train
whoever,
honestly
but
yeah.
I
I
I
mean,
I'm
not
totally
sure
I
think
maybe
follow
up
with
chair
asynchronously,
to
see
if
he's
done
any
work
on
it.
A
I
am
now
looking
into
the
last
meeting
notes
to
see
if
we
have
any
action
items
there
and
this
stations
number
one
anything
that
wants
to
be
on
ethereum
standard
needs
to
go
through.
If
you
can
github
repository.
I
believe
that
is
related
to
erc
process
that
we
discussed
in
the
last
meeting
alita
to
investigate
a
bot
exclusion
to
eip1.
My
understanding
is
this
is
done
alita.
Can
you
confirm
that
please.
A
A
I
believe
both
are
interrelated,
that
both
are
related
to
eip1
only
month.
The
json
rpc
api
is
back
in
either
one
o
as
duplicated
internally
until
after
london.
I
believe
we
discussed
this
today.
Lifeline
brought
it
up,
there
are
some
changes
and
the
last
one
is
change.
The
name
of
each
1.0,
api's
repo
after
london
is
shipped.
That's
a
decision,
no
action
item
on
anyone.