►
From YouTube: EIPIP meeting 42
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/87
A
Welcome
to
eipip
meeting
42
and
I
have
shared
the
agenda
in
the
chat.
The
first
item
listed
here
is
post.
Merge
will
core
cover
execution
and
consensus,
or
do
we
plan
to
categorize
eips
based
on
what
they
touch
so
eip
process
after
the
merge
is
something
that
people
are
interested
to
learn
about.
I
have
picked
up
this
agenda
item
from
the
eip
editing
channel,
though
I
find
some
responses
there
later
on,
but
not
sure
if
there
is
any
general
agreement.
A
B
So
we
lost
light
client.
I
was
curious
for
his
thoughts,
but
I
can
share
mine
and
what
I've
been
trying
to
advocate
for
yeah
please.
So
I
I
think
eips
are
really
good
because
they
provide
kind
of
an
english
description
of
the
changes,
especially
I'm
just
focusing
on
quarry
ips
right
now
and-
and
I
think,
there's
a
lot
of
value
in
like
when
there's
a
change
to
be
able
to
like
bundle
it
with
an
eip
number.
So
say
you
know,
eip
1559.
Is
this
change
transaction
fee
market
eip
2929?
B
Is
this
change
the
gas
cost
prices
and
and
so
on,
and
I
think
that's
like
a
really
valuable
property
like,
for
example.
Now,
if
you
look
at
the
altair
upgrade
there,
isn't
there
isn't
eips
for
each
of
the
changes
and
it's
kind
of
hard
to
like
explain
what
all
the
changes
do.
So
that
being
said,
eips
are
also
not
a
great
place
to
actually
have
the
technical
specifications
for
the
changes
for
a
bunch
of
reasons
and
like
clients
has
has
gone
on
to
this
before.
B
But
it's
just
it's
hard
because,
like
you,
don't
have
all
the
entire
specifications.
So
you
have
to
provide
a
lot
of
context
and
whatnot,
and
the
the
cool
team
has
been
working
on
an
executable
specification
for
for
the
execution
layer.
So
my
I
guess
a
long
way
of
saying
what
I
would
like
us
to
do
is
to
keep
core
eips
as
a
way
to
describe
the
changes.
B
That's
at
a
high
level,
both
on
the
execution
and
consensus
layer,
but
then
not
necessarily
use
them
to
to
have
the
actual
technical
implementation
inside
so
that
this
way
you
could
say
an
upgrade
of
the
execution
layer
or
the
consensus
layer
has
eips
x,
y
and
z,
and
the
eips
all
have
a
link
to
a
pr
in
the
in
the
respective
spec
and
that
pr
is
basically
what
the
actual
technical
changes.
So
that's
what
I
would
like
to
see.
B
A
B
So
it
would
be
a
pr,
I
guess,
from
the
individual's
fork
onto
the
main
ethereum
repository
and
then
when
it
gets
merged.
I
guess
when
it
gets
accepted
into
a
hard
fork
or
something
like
the
pr
would
always
be
on
the
main
repository
right.
It's
just
opened
by
someone
else,
and
I
guess
if
it
gets
accepted
into
a
hard
fork,
then
the
pr
gets
merged
into
the
the
main
branch.
A
All
right,
maybe
I
am
missing
something
here,
but
if
I
understand
for
a
proposal
to
be
merged,
maybe
even
as
a
draft,
it
has
to
have
no
external
links.
So
the
first
first
time
then
proposal
is
being
proposed
as
a
pull
request
to
eip
repository.
It
will
be
individuals,
but
it
gets
accepted
and
then
for
further
changes.
There
will
be
a
link
within
the
eip
for
the
technical
specification.
A
C
So
I'm
not
a
fan
of
that
strategy,
as
I'm
sure
no
one's
surprised
at.
I
prefer
the
strategy
that
I
think
sam
is
planning
on,
which
is
that
the
execution
specs
repo,
once
it's
ready,
will
have
the
human
readable
content
in
it,
and
so
the
entire
process
can
be
done
in
the
specs
repo
and
already
we
have
that.
I
think
in
the
consensus
specs
repo.
They
already
have
the
human
readable
version
as
well.
No.
B
Yeah
but
those
are
they're
bad
they're
good
if
you're
reading
the
spec
and
you're
trying
to
understand
what
it
does:
they're
bad.
If
you're
trying
to
reason
about
like
the,
why
you
know
like
when
we
have
discussions
about
including
eips,
I
think
those
are
a
pretty
bad
format
because
they
don't
walk
you
through,
like.
What's
the
rationale,
what
you
know,
what
what
basically
benefits?
Does
this
bring?
What
are
like
the
trade-offs-
and
I
think
eips
are
great
for
that,
like
a
really
good
self-contained
document.
C
C
B
Right
right,
yeah,
it
helps
like
encapsulate
the
changes
in
like
a
really
valuable
way.
Like
I
don't
know,
I
found
like
I've
struggled
to
like
explain
alternative
people
more
than
I
struggle
to
explain,
say
like
berlin,
because
it's
not
quite
as
easy
to
like,
say
hey
there
were
these
three
changes
brought
in
and
like
at
a
high
level.
Here's
what
many
of
them
do.
So
I
I
don't
know
it
does
feel
like
it.
B
Maybe
it's
just
for
not
technical
people
like
me,
but
it
does.
C
C
Don't
you
talk
to
people
about
like
what's
in
berlin,
because
berlin
just
happened
or
what's
in
the
merge
or
altair,
because
it's
very
recent,
but
no
one
cares
what
happened
in
homestead
other
than
like
the
people
who
are
implementing
it
and
need
to
have
a
client
that
can
travel
through
homestead
and
everyone
else
is
completely
oblivious
and
doesn't
care
like
regular
humans,
like
not
engineers,
don't
need
that
history
long
term
so
and
the
reason
I
think
it
matters
how
permanent
the
information
needs
to
be
is
because
I
think
for
certain
types
of
content.
C
B
Right,
I
guess
the
other
thing
is
and
I'm
not
sure
how
much
this
is
like
valued
here,
but
I
think
eips
are
really
well
understood
by
the
community
and
they're
like
easy
to
point
to
and
for
people
to
like
hatch
onto,
whereas,
like
even
now
that
we've
moved
say
the
hard
fork
specs
to
like
the
specs
repo
I
still
get.
I
had
literally
vitalik
asking
me
for
the
the
meta
eip
for
london
right
then
being
like
well
where's
the
eip.
B
C
I
think
this
is
this
is
one
of
the
things
that
I
dream.
Maybe
one
day
we
can
get
to
a
place
where
people
that
aren't
implementing
specifications
don't
use
eips
for
anything
like
no
one
who's
using
a
web
browser
goes
and
looks
at
the
w3c
specs
like
they
are
incredibly
technical
and
they
are
impossible
for
anyone
to
read.
Regular
people
go
look
at
like,
and
even
regular
developers
go
look
at
canius.com
or
whatever
like
they
go
to
other
places.
To
get
that
high
level
information.
They
don't
go
to
the
specification
like
rfc.
C
See
the
same
thing:
people
who
go
to
rfcs
are
people
who
are
trying
to
implement
an
rfc
compliant
thing,
and
that
is
it.
No
one
else
looks
rfcs,
and
I-
and
I
think
this
is
where
I
end
up
in
conflict
with
a
lot
of
people
on
the
ap
eips-
is
because
I
want
the
ips
to
be
that.
C
I
want
them
to
be
a
technical
specification
designed
for
a
very
select
group
of
people,
not
that
we
want
to
exclude
anybody,
but
just
like
the
target
audience
is
a
very
small
set
of
people,
the
people
that
are
implementing
things
on
ethereum
directly
and
they
need
this
strict
specification
to
look
at,
and
then
we
have
all
that
other
stuff
like
that.
Regular
people
go
and
look
at
somewhere
else,
and
I
think
I'm
kind
of
alone
on
this.
C
I
think
everybody
else
would
just
rather
the
eips
repo
just
be
this
monolithic
thing
where,
as
the
source
of
all
information
for
ethereum,
I
think
my
problem
with
that
is
a.
I
don't
really
like
monolithic
things.
I
like
things
that
are
very
targeted
but
separately.
We
just
don't
have
the
manpower
to
manage
a
repository
that
grows
outside
of
the
scope
that
it
currently
has.
C
If
we
had
more
manpower,
then
I
think
I
would
push
back
less
hard
because,
as
we
extend
the
the
audience
the
target
audience,
it
gets
harder
and
harder
to
maintain
things
and
you
get
more
and
more
people
trying
to
get
involved
and
contribute,
and
it
just
it
becomes
really
hard.
Whereas,
if
you
keep
it
very
constrained,
say
look,
this
is
a
targeted
at
these.
You
know
30
people
and
that's
who
we're
going
for
you
know
we're
not
targeting
everybody
else.
C
Then,
like
the
management
of
it,
is
much
smaller,
because
there's
less
people
throwing
things
in
at
it,
there's
less
people
reading
it
less
people
debating
you
know
what
should
we
do
for
different
things?
B
I
so
I
guess
I
kind
of
agree.
I
I
100
agree
with
like
the
fact
that
limited
by
number
of
people
limits
the
amount
of
things
we
can
do.
If
that's
really
the
main
constraint,
I
think
that's
a
solvable
problem
and
I'm
conscious
that
we've
tried
to
solve
this
problem
before
with
like
mixed
success,
but
we've
also
tried
harder
things
on
ethereum.
B
I
I'm
also
pretty
sympathetic
to
your
point
of
like
no
one
cares.
After
and
and
whatnot,
I
think
I
would
be
kind
of
fully
on
board
with
your
vision
it's
like.
If
we
have
a
better
process
defined
for
the.
How
do
we
actually
talk
about
stuff
and
decide
on
stuff
when
we're
doing
it.
C
C
I
think
personally,
I
I
really
like
just
as
an
engineer
who
uses
github
all
the
time
like
most
of
my
days
on
github
or
it
used
to
be
at
least
I
really
like
prs,
and
I
like
using
pr's
as
the
place
where
people
discuss
things
and
talk
about
things.
I
find
them,
because
the
code
is
right
there,
it's
like
close
to
go
by
and
once
the
pr
is
merged,
it
kind
of
just
goes
away
and
you
can
still
reference
it
like
if
you
want
to
refer
back
to
discussions
or
whatever
you
can.
C
But
I
do
like
that.
Personally,
I
don't
know
if
it's
a
perfect
fit
here,
because
I
think
pr
start
to
fall
apart
when
you
get
a
large
number
of
people
involved
in
the
discussion
process.
Unless
you
have
like
someone
shepherding
like
the
the
first
post
and
making
sure
that
it's
always
up
to
date
with
the
latest
conversation,
but
I
think
no
matter
what
we
need
a
shepherd
for
every
change,
and
so
the
question
just
is:
where
is
the
shepherd
maintaining
the
current
documentation
for
the
change
itself?
C
So
not
the
specification
but
where
they
documented
those
things
like
the
rationale,
the
motivation
and
as
people
are
contributing
to
the
discussion.
You
know
they
add
things
like
when
I
was
doing
2718
people
would.
If
I
saw
a
question,
come
up
like
more
than
once.
I
would
just
add
it
to
the
rationale,
and
so
you
need
somebody
there
doing
that
step
like
making
sure
that
this
contains
the
latest
information
for
1559.
C
B
B
It's
like,
I
agree
with
you,
I
think
in
theory,
and
then
I
I
just
like
think
of
all
the
practical
steps
and
like
hiccups
to
getting
there
and
it
seems
like
a
harder.
C
Creating
a
new
process
for
a
thing
is
hard,
so
it's
much
easier
to
just
shoehorn
your
thing
into
an
existing
process.
So
it's
like.
Oh
there's
a
process
right
there,
that's
related
to
ethereum
I'll,
just
jam
my
thing
in
there
and
just
kind
of
squeeze
it
until
it
fits,
and
I
totally
recognize
why
people
do
that,
because
setting
up
a
new
change,
control
process
thing
is
a
ton
of
work
and
lots
of
you
know
figuring
out
the
details.
C
It's
it's
complicated.
I
just.
I
worry
so
much
that
if
everybody
jammed
once
because
what
I've
noticed
is
once
someone
jams
their
thing
into
the
ap
process,
then
they
come
back
like
like
they
force
it
to
fit
in
there
and
it
kind
of
fits
like
you
can
jam
it
in.
It
maybe
fits
and
then
like
a
month,
one
or
two
people
do
that
and
a
couple
months
passed
and
then
those
people
are
like
hey.
We
should
make
the
apd
process
work
better
for
these
things
right.
D
C
You
know
wanting
to
change
the
process
because
it
doesn't
fit
their
thing
and
I
don't
have
a
good
solution.
Other
than
hey
go,
build
your
own
process,
which
isn't
a
good
solution.
It
sucks.
A
Well,
I
don't
think
that
we
are
going
to
get
a
solution
right
away
today
in
this
call
for
everything
but
yeah,
but
I
think
in
improving
the
process
we
we
have.
We
have
covered
a
long
distance
and
educating
people
like
how
do
we
work
and
now
that
with
some
new
changes
coming
in,
maybe
if
we
try
to
define
the
process
early
on
would
be
helpful
for
other
people.
A
While
I
agree
to
both
micah
and
tim
suggestion
about
seeing
eip
repository
in
a
different
way,
but
I
think
or
that's
that's
workable
for
core
eips
and
there
are
a
ton
of
people
who
are
there
using
erc's
as
well.
So
if
ercs
are
there
processes
are
there,
standards
are
there,
it
will
be
cluttered,
we
just
have
to
try
to
clean
it
up
and
with
the
help
of
some
of
the
bots
that
that
have
been
designed
recently
to
you
know,
help
us
with
the
process.
A
Those
are
good
and
irrelevant
and
as
per
the
like
people
looking
into
the
history,
may
not
everyone
be
interested
looking
into
the
history,
but
some
students,
especially
like
I,
interact
with
a
lot
of
college
students,
and
I
have
seen
when
they
are
trying
to
learn
something
they
try
to
dig
inside,
say,
for
example,
account
abstraction
the
latest
proposal
that
vitalik
proposed.
So
when
one
of
my
students
he
was
looking
into
that
proposal,
he
tried
to
look
into
all
earlier
proposals
that
were
written
for
a
counter
abstraction.
A
B
Yeah-
and
I
think
realistically,
this
is
gonna-
be
a
high
focus
after
the
merger
like
at
least
once
the
merge
is
like
done
code
wise
yeah.
I,
and
I
think
it's
gonna
be
hard
to
get
input
from
like
actual
engineers
and
folks
from
like
danny
until
the
merge
is
is,
is
a
bit
farther
along
yeah,
even
like
personally,
it's
yeah.
B
I
know
this
is
important
that
we
need
to
do
it,
but
it's
like
obviously
less
important
than
the
merge,
and
so
it
just
like
falls
to
the
bottom
of
my
priority
list
every
week
relative
to
just
whatever
thing
related
to
the
merges.
B
So
I
think
once
we're
like
in
a
spot
where
the
code
is
mostly
stable
and
we're
kind
of
going
to
main
nets,
then
then
people
will
have
much
more
mental
bandwidth
to
deal
with
this
and
we'll
also
be
forced
to
deal
with
it,
because,
basically,
we're
going
to
need
to
start
planning
the
withdrawals
for
afterwards.
A
I
think
sooner
I
mean
I
understand
your
priority
list
here
like
getting
into
merge
specs
in
place,
but
I
think
the
sooner
we
start
discussing
on
the
process
better.
It
would
be
for
us
because,
as
for
now,
we
have
just
one
proposal
that
kind
of
describe
the
changes.
What
we
are
expecting,
how
we
are
going
to
switch
from
proof
of
work
to
proof
of
stake.
That
is
very
good,
but
in
case
we
are
trying
to
have
some
more
features
or
something
to
be
added.
If
we
keep
getting
them
as
like.
A
You
know,
proposals
as
eips,
and
we
have
a
place
particular
place
for
that.
That
would
be
good
for
people
to
follow
because
they
would
not
feel
the
friction
like
something
has
changed.
It
would
be
same,
but
if
it
start
thinking
about
right
at
the
point,
when
merge
is
there,
I
think
it
would
be
a
little
late
for
that.
B
B
It
just
feels
like
there's,
there's
little
appetite
from
like
actual
engineers
to
discuss
this,
and
maybe
I
don't
know
once
we
get
to
a
spot
where,
like
the
cordless
calls,
are
pretty
empty
again
because,
like
you
know,
we're
done
with
the
merge
and
people
are
just
saying
that
they
fixed
it.
As
bugs.
That's,
maybe
like
a
good,
a
good
signal
that
we
should
start
bringing
it
up.
B
I
think
one
thing
that
could
be
valuable
and
is
maybe
getting
like
sam
to
present
the
executable
spec
on
an
alcor
devs
once
he
feels
it's
like
in
a
reasonable
spot,
so
that
I,
I
suspect,
like
most
people
on
all
core
devs,
don't
even
know
that's
been
worked
on.
Yeah
could
be
yeah.
B
Maybe
like
a
if
we
can
like
peep
it
absolutely,
but
if
we
can
also
do
like
a
five
ten
minutes
on
all
corners,
I
think
yeah.
It
just
catches
different
audiences,
but
like
absolutely,
we
should
have
even
and
maybe
like
a
sort
of
teaser
on
all
core
devs
or
something
where
he
can
just
kind
of
give
a
high
level
overview
and
then
invite
people
to
come.
There
yeah
yeah.
A
All
right,
I
think
we
are
close
to
like
half
of
the
meeting.
So
let's
just
move
on,
unless
someone
has
some
last
thought
to
go
on
with
on
this
topic,.
C
A
All
right,
so
moving
on
to
the
next
item
listed
here
is
remove
updated
from
eip1.
Likeline
has
just
started
this
issue
and
I
saw
some
comment
from
mica,
but
I'm
not
sure
if,
like
there
is
any
reference
to
any
pull
request.
A
The
link
is
added
to
the
agenda,
so
this
updated
is,
is
there
in
eip1,
but
it's
not
being
used.
It
is
about
the
last
updated.
I
think
it
is
redundant
because
github
will
give
us
the
last
date
of
updating
that
proposal.
So
it
is
not
something
that
an
eip
author
should
keep
on
adding
every
time.
He
is
updating
his
proposal.
C
C
So,
for
that
one
we
just
need,
we
have
two
pr's
out.
We
need
to
merge
one
of
them,
both
both
pr's.
Remember.
E
C
A
Okay,
we
will
be
coming
to
that
admin
issue
as
well
like
that
is
there
in
my
agenda
list
today,
but
before
that
I
also
want
to
go
through
this
one.
So
do
we
consider
that
number
two
remove
updated
from
eip,
one
like
salt.
A
Okay
cool,
so
next
one
is
some
of
the
changes
that
I
was
wondering
how
to
deal
with,
and
that's
why
I
have
listed
them
here
with
this
eip
bot
like,
as
I
mentioned
earlier,
200
proposals
have
been
moved
to
stagnant
so
far
in
the
month
of
september
and
october.
A
A
A
C
So
if
someone
has,
I
think,
I'd
rather
people
go
to
review
first,
so
I
don't
have
a
good
reason
for
that.
To
think
about
it,
I
just
want
to
make
sure
that
people
are
getting
the
appropriate
eyes
and
they're
just
skipping
ahead
to
the
end
in
hopes
that
no
one
will
actually
look
at
their
thing.
C
So
I
guess
I
guess
realistically,
if
someone
wants
to
go
straight
from
nothing
to
last
call,
I
don't
actually
have
an
argument
against
that,
like
if
you're
so
confident
in
your
thing
that
you
think
that
you
don't
need
anyone
else
to
look
at
it
before
it's
done.
I
guess
you
could
just
go
straight
to
last
call
like
like,
I
can't
think
of
a
good
reason
to
force
people
to
iterate
through
the
steps
like
the
more
I
think
about
it.
So
I
guess
yeah,
I
don't.
A
Yeah
that
sounds
fair
to
me
as
well.
We
might
want
to
like
add
some
text
to
eap
when
describing
these
changes.
Yeah
like
do
you
have
any
thoughts
or
do
you
think
it
is
fair
to
go
back
to
the
original
status.
E
I
don't
really
mind
that
much.
I
would
prefer
slightly
to
go
to
draft
to
review,
but
if
they
really
want
to
go
to
last
call
that's
also
okay,.
A
All
right,
I
will
make
a
note
of
that.
The
next
one
is,
I
think
we
discussed
it
yesterday
in
the
eip
editors,
apprenticeship
meeting
it's
like
when
an
author
is
making
a
pull
request
to
change
the
status.
Would
it
require
editor's
permission
or
should
the
bot
design
it
like?
It
should
be
auto
merge,
like
our
our
thought,
would
like
likeline
suggested
that
it
should
be
auto
merged
because
author
is
there.
A
So
actually
I
I
saw
that
there
is
this
one
example.
I
think
the
proposal
was
one
five,
two
three,
so
it
said
that
the
barter
left
a
message
that
it
is
auto
merging,
but
it
never
merged.
So
I
guess
there
is
some
bug
you
might
want
to
look
into
it
later.
A
I
suppose,
like
land,
has
also
created
an
issue
in
the
eip
part
repository,
so
you
might
get
some
reference
on
that.
A
Okay,
the
next
one
is
if
moving
the
proposal
is
impossible
for
any
reason
say,
for
example,
eap3403,
partial
removal
of
refunds.
We
know
that
there
is
another
proposal
that
went
into
one
of
the
earlier
upgrades
and
this
is
never
going
to
go
through
now.
This
has
been
moved
to
stagnant,
so
we
would
want
this
proposal
to
be
out
of
repository,
not
stay
in
the
stagnant
forever,
so
the
next
course
of
action
could
be
to
move
it
to
withdrawal
and
withdrawn.
A
A
A
So
there
are
a
couple
of
proposals
say,
for
example,
eip2070,
which
was
mata
e
prepared,
for
I
guess,
berlin
or
london.
I
know
that
it's
not
gonna
go
ahead,
so
it's
better
to
be
withdrawn.
That
is
that
we
know
the
author.
Maybe
we
can
reach,
but
there
are
few
more
proposals.
A
There
was
one
for
partial
removal
of
refunds
eip3403.
We
know
that
there
is
some
other
proposal
that
went
into
the
final
upgrade,
so
this
would
never
pull
through
and
we
don't
want
to
leave
in
stagnant
forever.
Is
it
fair
that
someone
creates
a
pull
request.
C
C
Yeah,
I'm,
like,
I
still
think,
there's
value
in
so
I'm
not
a
fan
of
doing
anything
with
other
people's
eips,
and
so
we,
the
two
options
we
have
currently
it's
our
current
process
is
either
allow
it
to
fall
on
stagnant
just
due
to
no
one
touching
it
for
six
months
or
two
months
or
whatever.
It
is
or
ask
the
offer
author
to
withdrawn,
like
we
don't
have
a
process
for
any
other
terminal
states
besides.
Those
two
and
I
treat
them
like
mentally,
is
fairly
similar.
A
Oh
no,
I
was
wondering
I
was
wondering,
like
the
proposal
that
has
a
hope
that
it
can
be
pulled
back,
should
stay
in
withdrawn
as
long
as
author
wants
to.
But
there
are
certain
proposals
which
personally,
I
feel
is
no
hope
for
them
to
ever
get
added
to
the
final
repository,
because
that
was
an
intermittent
proposal
and
something
better
was
proposed
during
the
same
cycle
and
the
better
one
went
into
the
upgrade.
So
we
know
that
the
older
version
is
never
gonna
go
through.
C
So
the
two
questions
I
or
one
question
will
comment:
what
would
you
like
to
see
them
with
these?
Like?
Do
you
want
them
deleted
from
the
repository
or
do
you
want
a
new
status.
C
So
my
concern
is:
is
that
deciding
what
is
which
eips
are
never
never
possible
and
which
are
not
is
challenging
at
best
like,
for
example,
this
this
proposal?
3403
partial
removal
of
refunds,
like
maybe
the
authors,
feel
that
there's
still
a
chance
for
that,
just
with
a
little
bit
of
tweaks
or
whatever?
Similarly
like
when,
before
eip1559
went
out,
we
had
several
counter
proposals
that
people.
D
C
C
Five
yeah
well
one
five,
five,
nine
one
could
argue
kind
of
it
won
some.
The
the
authors
of
those
may
feel
like
you
know
they
want
to
try
this
again
in
six
months
or
a
year
or
whatever,
maybe
they're
waiting
for
1559
to
fail,
so
they
can
bring
their
thing
back
in
and
so
I'm
very
hesitant
as
an
editor
to
get
into
the
business
of
deciding
whose
eips
are
no
longer
relevant
and
who's
aren't
like.
C
C
That
being
said,
like
I'm
perfectly
fine
with
stagnant
being
terminal
like
if
it
we
can
just
update
the
ip1
or
the
picture
or
whatever
to
just
say
you
know,
stagnant
stagnant
can
be
terminal
like
it's.
Okay,
if
things
stay
stagnant
forever,
because
there
will
be
a
lot
of
stuff,
this
isn't
stagnant
forever.
A
I
hear
you
yeah.
There
was
this
another
proposal
that
was
also,
in
my
mind,
like
2593,
which
was
escalator
free
market
change
for
eat
1.0.
Now
that
1559
is
there,
so
I
was
considering
that
it
may
not
go
through,
but
hearing
your
thoughts.
It
is
possible
and
yeah.
An
author
may
decide
at
this
at
some
point
that
he
would
want
to
bring
it
back.
A
Okay,
so
I
see
one
more
plus
one
on
stagnant
forever,
so
maybe
we
would
like
to
make
these
changes
on
eip
one.
I
will
keep
it
open
for
at
least
one
or
two
more
meetings.
These
changes
that
we
are
discussing
today
for
eip1
and
then,
after
a
few
rounds
of
discussion,
maybe
we
will
update
the
eip1.
C
Yeah,
I'm
also
okay
with
just
if
you
want
to
create
a
pr
against
eip1,
we
can
have
discussion
there
asynchronously
if
you
prefer
that.
A
Yeah
that
that
may
speed
up
the
process
make
sense
all
right
and
the
last
one
here
on
the
list
was
about
the
moving
the
proposal.
If
there
is
a
necessity,
but
eip
author
or
champion,
isn't
actively
involved,
I
know
micah,
you
suggested
someone
getting
involved
from
the
eip
editor
apprenticeship
program
to
look
into
that,
and
we
kind
of
discussed
that
yesterday
in
the
eap
operating
apprenticeship
program.
A
But
the
concern
here
is,
we
might
want
to
have
authors
approval
to
be
added
them
as
a
champion
or
co-author
for
the
proposal,
and
if
we
are
not.
D
C
So
ideally,
we
get
the
the
current
author
to
like,
if
they're
not
interested
in
doing
the
champion,
championing
themselves
like
the
the
busy
work
of
fixing
things
and
getting
through
the
review
process,
making
changes
etc.
C
Then,
ideally,
we
get
the
author
to
sign
off
on
somebody
helping
them
out
and
so,
for
example,
you
know
if,
if
there's
some,
we
will
will
william,
I
don't
know
what
he
goes
by
if
he
wants
to
help
out.
That
would
be
a
great
place
to
help
and
he
helps
someone
who
is
interested
in
getting
involved
in
corey
aps
to
learn
the
process
and
everything,
but
they
can
do
it
with
someone
else's
idea.
So
they
have
someone.
C
They
want
to
push
through,
but
they
don't
want
to
do
all
the
bureaucratic
stuff
of
vip
editing.
They
can
get
help
from
someone
who
wants
to
learn
the
process.
So
that's
the
ideal
scenario
which
I
think
we
all
agree
on.
If
the
author
is
completely
unresponsive,
but
we
do
want
to
get
it
pushed
through.
The
fallback
option
is
to
have
find
someone
who
wants
to
champion
it
and
go
through
the
editorial
process
to
just
basically
make
a
clone
of
it,
make
a
new
a
new
eip.
C
A
So
the
second
option
question
the
eip
would
not
be
the
same
number
correct.
A
Maybe
we
we
discuss
with
the
eap
author,
try
some
more
time
give
some
more
time
to
it
and
if
not,
then
maybe
that
is
the
ultimate
option.
I
suppose.
C
Yeah,
maybe
try
reaching
out
to
the
author
on
multiple
channels
like
just
like
email
or
discord
or
github,
just
to
see
maybe
they're
simply
not
getting
the
messages.
I
don't
know.
A
Okay,
that's
like
most
of
the
sections.
The
next
one
is
eip
insight.
So
this
is
just
a
monthly
report
that
I
have
started
recently
talking
about
how
we
are
doing
on
eip
site
up
till
october
15.
There
are
two
new
proposals:
one
is
account
abstraction,
4337,
the
other
one
is
difficulty
bomb
delay
to
summer
june.
That
is
eap
4345.
A
One
proposal
moved
from
draft
to
review,
that
is
an
erc
1581
and
about
115
proposals
have
been
moved
to
stagnant
status.
We
see
some
efforts
are
being
made
to
pull
out
some
of
the
proposals
that
is
good
and
encouraging
that
at
least
people
are
trying
to
move
their
proposal
to
a
decent
status.
We
are
happy
with
the
progress
that
that
we
are
making
with
the
help
of
bart
and
the
team,
eap,
editors,
elita
and
everyone
who
are
heavily
engaged
in
helping
out
with
this.
So
thank
you.
Everyone.
A
The
next
item
that
we
have
listed
here
is
the
future
of
the
eip
merge
part.
So
we
know
that
there
was
another
bot
run
by
nick
johnson
and
that
was
not
working
for
a
while
or
we
thought
that
it's
a
good
idea
to
create
our
create
a
different
bot,
and
that's
why
we
have
eip
bot.
A
D
Don't
is
this
the
one
with
the
travis
ci
that
we'll
get
right
now
yeah?
I
don't
think
next.
A
But
he's
still
running
it,
I
mean
he
has
still
kept
it
on
and
he
wants
to
check
whether
it's
safe
to
turn
it
down
if
it
is
not
being
used
at
all
and
if
it
is
being
used.
It's
fine.
D
I
think
that
this
is
a
different
one.
We
have
two
eip
validators
and
realizing
one
isn't
travis
it's
in
ruby,
and
I
don't
know
if
you
want
to
like
trans
transfer
the
logic
from
here
over
to
the
other
one
or
something.
But
regardless.
C
C
To
elita's
question
yes,
long
term
it'd
be
nice
if
we
consolidated
the
bots
into
one
consistent
location
and
ideally
one
consistent
language,
but
I
think
that's
probably
not
a
high
priority.
It's
not
for
me.
A
All
right,
so
this
is
good
like
I
can
inform
him
to
turn
it
down.
The
next
one
listed
here
is
admin
access
to
eip
repo
and
a
report
to
eip
editor.
So
recently
we
have
made
some,
I
can't
say,
changes
it's
just
that
we
are
trying
to
represent
it
correctly,
like
most
active
eip
editors,
and
we
have
a
new
section
called
emeritus
editors
to
list
all
the
editors.
Thank
you
tim
for
that
suggestion
that
really
helped.
A
I
didn't
want
it
to
remove
the
name,
because
it's
it's
good
to
have
history
there
and
I
talked
to
different
eip
editors,
which
are
still
as
listed
as
active,
but
they
would
want
to
be
like
removed
from
there
with
that
list.
A
I
think
I
will
be
sending
one
more
pull
request
to
update
the
list
we
have
received
from
some
of
the
eap
editors
that
they
do
no
longer
want
to
be
a
part
of
active
editing,
but
I
was
wondering
like
the
eip
github
repository,
there
are
very
few
people
who
have
like
admin
access.
I
suppose
micah
you
already
have
the
admin
access
unsure
about
exec
and
yep.
C
Just
just
me
and
the
like,
it's
just
me,
jamie
pitts
and
nick
johnson.
A
Yeah
yeah,
so
I'm
wondering
like
not
most
of
the
people
are
heavily
engaged,
but
lifeline
is
so.
Can
we
consider
getting
access
to
the
people
who
are
working
right
now?
Right
like
I
know
there
are
only
two
three
people
exec
like
client
micah.
I
see
all
these
comments.
I
know
greg
also
expressed
interest
to
get
the
right
access
to
the
current
repo.
C
C
Similarly,
okay,
he
contributes
fairly
regularly,
not
as
regularly
not
as
regularly
as
matt,
but
regular
enough
that
I
consider
him
an
editor
with
greg,
I'm
more
on
the
fence
and
the
reason
is
because
pretty
much
the
only
time
he
interacts
with
the
ips
repo
is
when
he's
working
on
his
own
eyepiece
like
he
doesn't
really
do
any
editing
of
other
people's
stuff
and
I'm
kind
of
hesitant
to
and
incentivize
people
to
kind
of
get
eip
access
just
so
they
can
merge
their
own
eips
and
bypass
the
process.
C
Yeah.
That's
my
weak
feelings.
I
I
if
he
wants
to
get
returned
to
being
involved.
I'm
okay
with
that
and
similar
with
nick
johnson,
like
nick
johnson,
was
an
active
editor
in
the
past,
but
isn't
anymore
again
the
only
time
he
interacts
with
the
repos
with
his
own
stuff.
That
being
said,
nick
has
historically
shown
a
little
more
restraint
and
he
usually
will
defer
to
the
other
editors
and
won't
automar
like
won't,
merge
his
own
prs,
for
example,.
D
A
Right
for
nico,
he
said
that
he
would
be
like
he
would
be
interested
in
getting
into
active
editing,
but
his
time
constraint
does
not
permit
him,
so
he
would
like
to
be
a
part
of
non-active
editors
for
now,
but
greg
showed
his
interest
and
he
said
that
I
would
be
like
like
interested
in
getting
back
into
editing,
but
for
access
right
now.
I
think
let's
go
ahead
with
lifeline
and
see
with
like
in
a
period
of
time.
C
Yeah
just
talk
to
jamie
pitts.
I
believe
this
is
the
right
person.
A
A
Okay,
okay,
the
one
thing
the
part
will
show
a
notice
to
new
issues
to
make
a
discussion
thread
on
ethereum
magician.
A
A
Similarly,
we
would
like
to
have
a
one
for
the
issues
section,
because
we
have
over
400
issues,
and
I
mean
I'm
assuming
more
than
50
are
non
active
discussion
things.
So
if
we
can
have
similar
part
activated-
and
we
start
closing
the
issues,
we
will
have
room
for
active
discussing
issues
like
real
issues
that
people
would
like
to
discuss
about.
D
All
right,
okay,
yeah,
that
one
is,
I
can
definitely
do.
I
will
add
that
to
the
list.
A
D
Yeah,
I'm
just:
are
there
any
other,
I'm
gonna
be
doing
a
bug
bash
with
with
the
bots
this
weekend
and
just
try
to
basically
get
through
every
single
bug
so
get
your
bugs
in
like
if
you
know
of
any
bugs
that
aren't
reported.
Yet
please
report
them
on
the
eip
repo,
so
I
can
have
you
bought
repo,
so
I
can
just
grind
through
them
this
weekend.
D
A
Okay,
later
just
for
your
information
like
like
there
is
this
one
resource
he
has
reached
out
to
me
and
he
might
be
interested
into
looking
into
the
erb
spot
site-
oh
like
it
as
in
working
on
it,
yeah,
not
no,
not
completely,
but
you
you
mentioned
earlier
right,
so
you
might
be
looking
for
someone,
so
he
is
interested
I'll
I'll,
try
to
get
more
conversation
and
if
he
fits
with
you
you're
happy
to
refer
to
you.
Yeah,
okay,
and
I
think
that's
all
we
have
listed
on
the
agenda
today.