►
From YouTube: EIPIP meeting 41
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/85
A
Welcome
to
the
ipip
meeting
41,
I
have
shared
the
agenda
in
the
chat.
The
first
item
on
the
agenda
is
a
process
for
networking
eips.
So
in
the
past
few
meetings
we
have
discussed
processes
for
different
types
and
categories
of
eips
that
the
proposal
should
be
moved
and
also
to
the
appropriate
statuses.
A
A
I
know
micah
left
some
comment.
I
don't
know
if
you,
if
you
would
like
to
go
ahead
and
provide
a
quick
summary
for
people
here
or
who
may
follow
the
call
afterwards
and
then
we
can
probably
discuss
on
it.
B
B
B
The
the
issue
is
just
the
like,
like
basically
it's
felix
and
peter
are
the
only
ones
who
do
networking
ips.
I
think
I
have
one,
but
they
they're
really
hard
to
these,
don't
fit
within
yeah.
That's
not
even
true.
B
C
B
But
they,
for
whatever
reason
they
don't
want
to
do
that,
and
this
is
why
I
say
that
either
do
that
like
follow
the
iep
process
or
create
a
different
process,
and
I
think
both
are
viable
solutions
like
if
they
feel
like
the
eip
process
is
not
a
good
fit.
Then
I
think
it's
totally
fine
and
I
think,
there's
other
processes
that
one
could
design
it
seems
like
what
they
want.
Is
they
want
to
use
the
ap
process
as
a
means
of
advertising
so
like
they?
They
don't
want
to
actually
do
the
ap
process.
B
They
just
want
the
to
use
it
as
a
as
a
way
to
communicate
with
people,
and
I
feel
like
that's,
not
the
right
usage
of
the
ap
process
like
we
have
a
process
in
place
in
order
to
ensure
standards,
you
know
are
of
certain
quality
and
that
there's
a
you
know,
steps
you
go
through
to
make
sure
you're
getting
the
reviews.
You
need
et
cetera.
C
A
Yeah
right
yeah
right,
so
I
have
invited
felix
to
the
meeting
as
well.
I'm
wondering
if
he
has
some
microphone
issue
of,
because
we
can't
hear
your
feelings.
C
I'll
just
finish
my
thought
to
me:
it
feels,
like
you
know,
they're,
just
in
a
way
that
they
have
to
after.
This
is
clearly
a
final
eep
that
they
have
to
go
through
every
single
stage
like
if
we
could
just
convert
it
to
a
final
leap.
That
would
probably
be
fine
and
in
the
future
we
should
just
you
know,
try
and
be
more
aware
and
help
convert
that
to
a
final
eat
before
it
becomes
like
a
year
out
of
dates
of
essentially
being
final,
but
not
listed
as
final.
B
B
So
my
my
general
concern
with
just
moving
these
to
final
is
that
I'm
a
a
big
fan
of
incentive
alignment,
and
if
we
do
this,
then
there
is
now
an
incentive
for
if
you
don't
want
to
go
through
the
ap
process,
you
just
simply
have
to
wait
long
enough
and
then
you
can
avoid
the
process
and
the
process
exists
for
a
reason
like
we.
We
don't
have
the
review
step.
The
last
call
step
just
for
fun
like
they
want
people
to
go
through
these
steps.
E
D
There's
I'm
sorry
this
there's
always
the
big
trouble
with
the
audio.
I
don't
have
a
lot
of
time,
but
I
guess
you
are
already
discussing
this
like
networking
eip
problem
yeah.
So
I
have
two
comments
mostly.
So
I
think
in
general,
the
eip
process
is,
you
know,
kind
of
okay
and
I
think
that
it
may
even
work
for
the
networking
eevs
of
the
future.
D
But
I
think
at
the
moment
the
discussion
is
about
the
networking
eves
of
the
past,
which
I
think
are
different
because
at
the
time
when
they
were
created
also
the
e
process
was
very
different
and
it
was
less
organized
with
the
all
core
devs
and
I
think
it's
just
from
a
different
time.
So
that's
kind
of
the
the
main
difference
and
then
the
other
thing
is
that
I
want
to
say
about
it.
D
D
It
makes
a
lot
of
sense
because,
obviously
they
all
have
to
implement
the
exact
same
thing,
so
it's
kind
of
like
the
the
e-process
also
serves
as
the
kind
of
repository
of
the
specifications,
for
example,
because
you
just
need
a
specification
to
develop
the
change
in
the
clients,
and
so
you
know.
Obviously
the
feedback
is
very
clear
and
since
everyone
has
to
implement
it
exactly
in
the
same
way,
it's
something
that
can
also
really
easily
be
verified.
D
You
know
by
tests
and
stuff
if
it's
actually
implemented
and
then
with
the
networking
things
we
are
in
a
much
better
situation
regarding
the
testing
now,
but
you
know
earlier,
especially
when
these
eaps
under
discussion
were
created.
It
was
you
know,
kind
of
we
were
mostly
just
trying
to
capture.
You
know
like
the
the
the
general
idea
and
since
the
clients
were
like
so
so
kind
of
like
disorganized
regarding
the
networking,
it
was
just
kind
of
you
know.
D
D
You
know
alternative
networking
mechanisms
as
well
as
long
as
you
know
they,
because
they
ultimately,
we
want
all
the
clients
to
be
able
to
connect,
so
they
should
implement
some
common
thing,
but
they
can
also
implement
arbitrary
extensions
to
it
or
whatever
you
know
like
it's
just
not
regulated
like
so
tightly
as
the
ethereum
consensus
is,
and
so
for
this
reason
I
think
the
networking
needs
are
more
like
you
know,
like
sort
of
like
kind
of
like
informational,
I
mean
like
there
is
a
spec
and
the
spec
says
what
you're
supposed
to
implement,
but
we
have
also
seen
that,
like
half
of
the
clients,
don't
implement
all
of
the
specs,
so
they
already
like
out
of
spec
most
of
the
time,
and
then
you
know
other
clients
they
just
have.
D
B
So
I
think
that
one
of
the
things
that
makes
me
lean
slightly
towards
not
using
the
ap
process
is
because,
unlike
other
consensus,
changes,
the
networking
protocol
actually
does
have.
You
know
the
like
a
webpage
that
defines
it
like
it's
actually
specced
out
somewhere
else
and
having
the
that's
specked
out,
and
I
believe
you
maintain
that
website
right.
Felix,
the
rlp
x,
stuff.
D
Yeah,
so
the
specs
yes,
so
it
has
its
own
specs,
and
but
I
can
already
interject
right
here
so
basically,
the
reason
why
we
have
the
specs
is
because
I
use
these
specs
to
document.
You
know
what
the
protocol
actually
is,
and
my
reasoning
always
behind
the
specs
was
that
I
want
them
to
be
very
comprehensive,
but
at
the
same
time,
most
of
what's
written
there
is
is
just
basically
also
just
documentation
about
what
the
clients
are
really
doing.
So
in
a
way
the
spec
there.
D
D
You
know
what
is
the
actual
behavior
of
the
clients
and
there
was
no
respect
for
it
like
you
know
before,
and
there
was
also
no
effort
before
for
things
like
you
know
the
transaction
handling
and
things
like
that,
it's
just
it's
just
stuff
that
you
know
like
was
kind
of
like
one-off
invented
by
someone
and
then
later
I
just
put
it
in
the
spec,
because
I
think
it's
the
right
way
to
do
it.
You
know
so
I
think
yeah
we
cannot
really
make
like.
D
So
for
me,
the
the
networking
eeps
have
the
independent
purpose
from
the
spec,
which
is
to
you
know,
like
lay
out
the
change
in
advance
and
then
once
it's
implemented,
we
can
always,
you
know,
like
you,
know,
refine
the
spec
and
you
know
also
apply
what
we
learned.
You
know
from
implementing
the
eep
version
of
the
changes
or
something
you
know
like
this.
A
Like
I.
D
B
Well,
so
I
think
that
there
are
a
couple
of
examples
where,
for
example,
eth2
has
a
specs
repo
and
their
change
control
process
is
not
the
e
process,
all
they
what
they
do
is
they
have
prs
against
that,
and
then
they
people
review
those
pr's
know
when
the
pr
is
merged.
That
means
it's
final
and
that
process
is
much
more
lightweight
than
the
ap
process
and
it
works
great
for
them.
B
Similarly,
the
json
rpc
is
going
switched
to
using
a
similar
process
where
you
have
a
repo
that
has
the
current
spec
and
then,
if
you
want
to
propose
a
change
to
it,
you
submit
a
pr
people
discuss
the
pr
and
then,
when
the
pr
merged
that
means
it's
final.
Those
processes,
in
my
opinion,
are
lighter
weight
and
generally
better.
In
fact,
I
would
like
to
move
the
ap
process
to
that.
B
Eventually,
the
problem
is,
we
don't
have
a
spec
like
in
github
for
ethereum,
particularly
the
consensus,
ethereum
consensus,
and
so
we
can't
do
a
pr
based
approach.
It
feels
like
the
networking
stuff
is
at
a
place
where
we
could
switch
to
that.
So
that's
why
I
advocate,
for
it
is
because
I
actually
do
think
that's
a
better
way
to
do.
Change.
Control
is
to
just
have
people
submit
prs
against
an
existing
specification
document,
and
then
you
can
discuss
on
that
pr.
B
What
you
know
pros
cons
back
and
forth
all
that
you
can
use
that
pr
as
a
way
to
alert
people
of
the
changes
so
again
using
eth2
as
an
example.
They
very
commonly
will
link
those
their
their
prs.
You
know
to
each
other
and
they
come
up
in
the
eighth
two
calls
or
like
consensus,
calls,
and
so
the
reason
I
advocate
for
this
isn't
because
I
like
I
want
to.
I
want
the
networking
stuff
out
of
the
eip
process.
It's
more
that.
B
I
think
this
is
a
better
process,
and
since
you,
the
networking
stuff,
is
already
very
close
to
being
able
to
switch
to
this
process.
It
feels
like
it
might
be
a
good
time
to
switch
over
it
avoids
it
also
avoids
having
you
know
this.
This
kind
of
two
separate
processes
where
one
is
you
have
the
spec
over
here
that
you're
working
on
and
then
separately.
You
have
the
eips
that
you're
working
on
and
then
you
have
to
kind
of
merge
them
like
you
can
do
it
all
at
once.
In
one
place.
D
D
I'm
sorry
yeah
there
was
a
break,
so
basically,
I
think
the
the
the
the
I'm
not
bothered
by
you
know
like
putting
other
people's
eeps
into
this
back.
You
know
later
as
well.
Like
I
mean
I'm
the
editor
of
the
spec,
so
that's
kind
of
okay.
Nobody
has
to
edit
this
back.
For
me,
to
be
honest,
I
would
just
you
know
rather
prefer
to
write
it
myself.
D
D
It
won't
be
good,
so
is,
is
better
to
kind
of,
I
think,
like
maintain
the
spec,
you
know
myself
and
then
you
know
have
the
changes
be
proposed
by
the
eep
so
because
I
like
the
e
process
for
the
networking
as
well,
also
because
the
eep
kind
of
forces
you
to
actually
put
the
changes
into
a
certain
structure,
and
I
found
this
very
helpful
with
my
own
eeps
and
I
think
it's
something
that
I
would
prefer
to
have.
D
If
there
was
just
you
know
some
kind
of
pull
request
based
approach,
then
it
would,
I
think
it
would
kind
of
get
lost,
because
you
we
we're
not
really
going
to
start
like
pull.
Requests
are
too
lightweight
for
this
kind
of
thing,
you're
not
really
going
to
reject
someone's
pull
request,
because
the
description
isn't,
you
know,
100
right,
but
you
can
totally
do
it
with
an
eep.
So
it's
kind
of
like
something
something
different.
D
I
think
so
I
would
prefer
to
keep
the
the
e
format,
because
people
actually
have
to
justify
their
changes
and
then
what
I've
done
with
the
spec
is
kind
of,
like
I
put
basically
when
I
work
the
e
content
into
the
spec,
sometimes
the
spec,
the
spec
is
only
changed
in,
like
you
know,
like
10
lines
or
something
or
is
only
like.
D
You
know
like
a
couple
words
added,
so
it's
not
really
like
you
know
most,
you
know
the.
Not
all
networking
changes
are
like
you
know,
big
things,
but
it's
kind
of
great
to
have
the
eep
as
well,
because
then
in
the
changelog
of
the
spec,
I
can
just
link
to
the
eep
and
say
you
know
we
made
this
change
and
now
it's
you
know
the
version,
something
something
and
here's
the
link
to
the
eben.
Then
in
the
eep.
D
You
can
actually
find
all
of
this
material
that,
like
led
up
to
the
decision,
so
I
think
it's
kind
of
like
good
to
have
both
because
you
have
the
the
the
the
final
spec
which
represent
the
current
state,
but
you
also
have
all
of
the
changes
with
their.
You
know.
Respective
justification
in
the
form
of
the
eeps,
so
I
think
this
is
the
value
that
I
see
in
the
eeps
and
also
in
keeping
the
eaps,
because
it
really
makes
you
think
about.
D
You
know
how
you're
actually
going
to
justify
the
change
you
want
to
make,
because
you
know
changing
these
things
also
really
hard.
So
you
kind
of
have
to
you
know
like
kind
of
do
some
thinking
in
advance.
You
can't
just
you
know,
come
along
and
say
I
want
to
change
this
thing
like
it
takes
like
months
to
make
changes
there.
You
know.
B
I,
I
want
at
least
people
to
find
value
in
the
processes
that
we
have
in
place.
I
was
under
the
impression
that
you
guys
weren't
getting
a
lot
of
value
out
of
the
eip
process,
because
it
seems
like
you
and
peter
are
reluctant
to
go
through
the
actual
whole
process,
but
if
you
guys
are
are
getting
value
out
of
it,
then
I'm
fine
with
continuing
to
have
networking
yeah.
D
It's
mostly
just
for
the
historical
things
where
we
don't
get
the
value
out,
because
we
think
it's
a
bit
silly
to
you
know
like
retroactively.
Try
to
you
know
like
apply
the
process
to
these
hips,
which
are
already
you
know
like
basically
done
like
for
us
these
pro.
These
things
are
done
because
they
are
implemented
they're
in
the
spec.
There's
no
need
for
us.
D
You
know
to
go,
there's
no
value
in
going
through
the
process
for
these
eeps,
but
there's
certainly
value
in
the
process,
for,
like
any
kind
of
you
know
like
newer
eaps,
because
we
would
really
like
to
receive
the
feedback
and
discuss
it,
and
you
know,
and
some
things,
maybe
not
in
the
spec
yet
so
you
know,
for
these
things
is,
is
it
is
different?
You
know
it's
just.
B
So
so
I
I
agree,
as
I
was
saying,
I
I
think
that
even
for
the
historic
erps,
there
is
still
value
in
going
through
the
process,
not
because
we
expect
to
make
normative
changes
like,
like
you
said,
they're
already
implemented.
B
They
like
minor
corrections,
typos
all
those
sorts
of
things,
and
so
I
do
think
even
for
these
old
eips.
Even
if
the
normative
content
won't
change.
I
do
think
there
is
value
in
just
having
it
go
through
each
of
those
steps.
Just
so
we
can
make
sure
we
get.
You
know
the
very
all
the
normal
people
who
review
these
things
can
see
it.
B
I
know
there's
at
least
one
person
who
has
an
rss
feed
of
last
call
eips
and
they
don't
read
any
eips
until
they
get
to
last
call
and
then
like
for
me
as
an
editor.
I
generally
glance
over
an
eip
when
it
goes
into
draft,
and
then
I
give
it
like
a
full
actual
read
when
it
goes
into
review
and
so
there's
a
good
chance
that
you
know
if
an
eip
is
currently
in
a
draft,
no
one's
actually
looked
at
it,
and
so
we
don't
have
people
who
have
had
an
opportunity
to.
B
Actually
you
know,
give
any
feedback
on
the
non-normative
stuff,
and
that's
that's
my
main
reason
why
I
would
like
to
see
it
go
through
the
normal
process,
and
this
doesn't
have
to
be
onerous
or
long.
It's
basically
just
submit
a
pr
set
it
to
review.
Wait
a
couple
wait
a
week
or
so
just
to
give
people
time
to
review
it
and
then
set
it
to
last.
Call
wait
two
weeks
give
people
time
to
review
it
and
then
set
it
final.
There's
a
good
chance.
You
know
no
one's
gonna
have
anything
significant
to
say.
B
Maybe
these,
like,
I
said
I
haven't,
looked
at
them
closely,
but
maybe
they're
totally
great
and
no
one
will
have
any
feedback
or
maybe
they'll
get
just
like
some
nitpick
stuff
about.
You
know
formatting
or
structure
things
like
that,
or
maybe
some
people
will
have
some
more
detailed
feedback
on
how
we
can
better
explain
things
or
better,
more
clearly
present
the
change.
D
Yeah
cool,
so
let's
do
it,
then
I
mean
like
I'm.
Okay
with
this.
We
can
just
do
this.
It's
okay,
yeah,
okay,.
A
Yeah,
so
now,
if
I
may
just
propose
one
small,
not
change
actually
can
be
an
addition
continuing
the
current
process,
so
we
will
be
following
the
process
for
the
networking,
but
I
know
the
networking
eips
are
generally
not
brought
on
onto
the
all
core
dev
meeting,
but
I
think
that
would
be
great
if
we
start
doing
that.
A
That
will
give
an
opportunity
to
the
get
team
to
announce
the
change
that
they
want
to
bring
to
their
client
and
if
any
other
client
is
interested
either
to
give
feedback
or
maybe
to
implement
in
their
plan,
they
will
also
get
you
know,
information
kind
of
thing,
and
I
I
hope
that
is
going
to
be
helpful
for
the
team
just
to
have
one
one
point
here
to
mention.
There
are
certain
proposals
I
mean
at
least
one
I
can
see
here
is
eip
three
four,
three
six,
which
is
proposed
by
daniel
farin.
A
I
was
trying
to
reach
out
to
the
author
and
his
point
of
view
was
like
it
depends
on
like
get
client,
so
my
question
to
felix
here
is
like
what
to
do
with
the
proposals
which
are
because
gets.
Implementation
is
like
major
implementation
in
theory,
if
we
come
across
certain
proposals,
which
is
not
by
the
get
team,
but
from
some
different
team,
how
do
we
want
to
handle
that.
A
D
Yeah
it's
kind
of
interesting
because
there
is
actually
an
eat
for
the
for
the
click.
So
this
is
not
a
guest
specific
and
it's
also
implemented
by
other
clients
as
well.
So
the
either
click
protocol
is
eip225
and
it
is
final.
D
So
this
one
is
just
an
extension
of
the
two
to
five
and
it's
in
review
for
some
reason.
Yeah
I
mean
the
question
is
mostly
just
who
should
review
it
and
I
guess
it
has
to
be
brought
up
in
all
corners.
You
know,
because
if
it's
a
review,
it's
something
that
kind
of
everyone
would
have
to
implement.
I
guess
what.
B
Why
why
is
this
networking
apa?
This
feels
like
a
corey
ap.
D
D
A
D
D
Yeah,
so
this
we
should
fix
puja.
I
wanted
to
say
regarding
the
thing
you
said
earlier,
we
have
actually
in
fact
announced
the
networking
eips
in
all
quarters,
it's
just
a
very
long
time
ago,
so
I
think
we
will
absolutely
bring
on
the
networking
erp's
to
the
to
the
all
core
devs
every
time
like
at
least
you
know
me
and
peter
when
we
write
the
next
one
which
is
already
planned.
You
know,
by
the
way
we
already
have
another
idea
for
the
next
networking
eep.
D
We
will
absolutely
bring
it
onto
the
or
quartus
call,
and
I
think
this
is
something
that
is
also
very
valuable
for
us,
for
us
is
always
kind
of
the
plan,
because
we
also
see
the
all
quarters.
As
being
you
know,
like
the
forum
where
you
can
discuss
these
things.
So
it's
like
great
that
it
exists
right
for
this,
so
we
will
definitely
do
it
is
what
I
want
to
say.
A
Great,
so
I
I
think
we
have
a
kind
of
consensus
here,
we'll
be
following
the
same
process,
but
if
I
may
request
you
to
kind
of
either
approve
the
eips
which
are
existing
in
draft
status
like
I
have
created
a
couple
of
pr's
just
by
changing
his
status
either
it
can
be
approved
by
the
author
or,
if
get
team
has
time,
and
they
would
like
to
create
their
own
pull
request
and
change
the
status.
A
D
A
All
right,
thank
you
so
much
for
joining
us
felix,
and
I
think
we
made
a
lot
of
this
particular
conversation
and
I
will
reach
out
to
the
author
of
3436
or
maybe,
if
micah
or
any
other
eip
editor
would
like
to
leave
a
comment
saying
that
this
should
be
in
the
core
proposal.
Then
probably
we
can
take
it
from
there.
Thank
you
once
again.
D
B
D
A
All
right,
I
think
that
went
well
and
we
actually
had
a
conclusion
that
how
we
want
to
go
ahead
and
look
for
the
networking
eips.
So
moving
on,
I
don't
know
before
we
move
on.
Does
anyone
have
any
final
statement
to
save
for
this
topic?
C
A
All
right,
moving
on
to
the
item
number
two,
which
is
progress,
update
on
moving
to
stagnant
status
by
part,
I
have
added
the
link.
So
in
the
past
a
few
weeks,
a
substantial
amount
of
work
has
been
done
by
the
eip
bot
and
editors,
not
sure
how
I
feel
about
thanking
alita
for
activating
bart
for
this
job,
because
it
feels
like
the
number
of
open
issues.
A
number
of
open
pull
requests
are
back
to
where
we
started,
but
I
hope
that
it
will
be
like
closed
in
near
future,
so
ali.
A
I
mean
the
changes
are
the
proposals
that
I
see
that
you
have
recently
closed,
some
of
the
issues
that
we
added
to
kind
of
modify
the
part
accordingly
like
what
would
be
the
closing
period
like
two
weeks
time,
or
something
like
that.
I
want
to
explain
on
that.
E
Yeah,
so
I
mean
I
implemented
several
features
here
for
the
stagnant
bot.
Now
it
kind
of
so
it
auto
cleans
like
any
backlog
stuff
or
if
it.
If
it
creates
a
a
new
pr
by
mistake,
then
it
will.
That
was
like
a
repeat
of
a
previous
one.
Then
I
will
delete
that
one
on
the
next
in
the
next
run,
so
anyways,
I
I
implemented
a
bunch
of
features
and
I
fixed
a
bunch
of
bugs
with
stagnant
thought.
E
I'm
sure
we
still
have
a
ways
to
go
before
it's
like
actually
really
good.
I
know
I'm
sure
micah
or
people
who
like
are
actually
looking
into
the
pr's
there's
like
a.
I
think,
there's
200
right
now
for
the
stagnant
bot,
which
I
mean.
If
there's
that
many,
then
you
know,
but
anyway,
yeah
so
moving
forward
over
the
next
few
weeks.
E
You
can
see
my
comment
on
this
agenda,
but
I'm
really
working
on
some
bug
fixes
and
feature
requests.
I
have
some
kind
of
final
notes,
which
are
please
leave
any
requested
features
or
bugs
you
notice
as
a
issue
in
the
eip
bot
repo,
because
it
makes
it
a
lot
easier
to
track.
E
And
then
I
think
there
was
one
other.
But
that's
basically.
E
E
E
And
then
essentially
like
excuse
me,
you're
gonna,
close
it
and
then
it's
gonna
be
reopened
the
next
week,
so
you're
gonna
have
to
close
it
every
week
until
I
can
implement
some
sort
of
better
solution
to
that.
B
Also,
the
bot
checks
to
see
if
there
is
an
existing
pr
of
some
kind
against
the
ap
right
or
just
not
do
that.
That's.
B
I
would
say
of
all
the
features
that
would
be
the
highest
priority:
one
because
we
don't
want
to
have
to
because
what
happens
is
mark
is
withdrawn.
User
comes
in
and
says,
hey.
I
created
a
pr
to
move
this
to
review,
but
they're
waiting
for
an
editor
to
review
it,
and
sometimes
it
takes
like
up
to
a
week
or
two,
and
so
in
those
cases
the
user
is
doing
everything
right
and
ideally
we
wouldn't
be
opening
a
new
pr
against
them.
E
Okay,
yeah,
I
mean
I
can
do
that
before
I
fix
the
bugs,
so
the
current
prioritization
plan
was
fix,
bugs
associated
with
the
the
main
eip
bot
and
then
do
feature
work.
But
I
can
prioritize
that
feature
above
all
else
and
get
that
done
this
week.
B
I
think
that
I
I
wouldn't
say
above
all
else,
but
I
do
think
that
particular
feature
is
pretty
important
just
because
it's
going
to
be
very
confusing
for
users
when
they
keep
getting
pestered
about
their
vip
need
to
be
withdrawn.
When
they're
doing
the
right
thing,
I
think
it's
very
confusing
for
for
people
so
like
if
there's
some
critical
bug,
I
think
that
should
take
priority,
but
if
it's
just
like
little
miscellaneous
bugs,
then
I
would
do
this
feature
first.
I.
A
B
I'm
just
because
like
to
me,
this
is
almost
this.
This
is
basically
a
bug
pestering
people
to
close
their
aps.
That
they've
already
done
the
right
thing
on.
A
A
Moving
on
so
the
next
thing
is
the
decision
on
closing
issues.
In
the
last
meeting
we
were
discussing
how
to
address
the
open
issues
issue.
A
So,
in
my
experience,
it's
not
a
healthy
practice
to
have
like
a
lot
of
open
issues,
because
it's
not
kind
of
good
reflection
of
the
work
being
done
or
managed
by
the
team
who
is
managing
their
github
repository
though,
and
I
know
that
people
are
putting
a
lot
of
effort
and
time
into
it.
A
So
I
want
to
you
know
kind
of
bring
attention
to
it,
so
we
can
come
to
a
resolution
and
way
out
in
the
last
meeting
michael
suggested,
getting
it
done
like
resolved
with
the
help
of
eip
bot
marking
them
as
an
style
issue.
The
way
we
are
addressing
the
pull
request,
but
it's
not
under
production.
Yet
so
I
did
try
to
leave
some
comments
on
bunch
of
issues
and
a
few
people
actually
created
a
thread.
But
the
item
like
the
issue
is
still
open.
A
But
that
is
one
of
the
questions.
Yes,
so
following
the
advice,
someone
would.
A
Okay,
then,
that
may
be
something
that
the
api
editor
might
have
to
do
that,
or
we
can
actually
just
leave
a
comment
that
okay
find.
This
has
a
like
respective
fem
thread.
We
can
go
ahead
and
close
that
so
yeah.
A
Yeah,
I
mean
the
reason
why
I
am
like
hesitant
on
enforcing
this,
because
I
see
for
even
in
the
past
three
four
weeks.
There
are
a
couple
of
issues
where
people
actually
started
storming
in
their
discussion
threat.
They
have
started
adding
discussions
and
I
just
don't
want
them
to
be
get
lost,
and
at
that
point
it
feels
bad
to
me
like
asking
them.
No,
no.
You
stop
discussing
here,
go
to
fdm.
B
I'm
I'm
I'm
fine
with
that,
like
just
let
people
when
I
talk
to
people
about
that,
I
usually
just
let
them
know
hey.
We
have
we're
trying
to
get
consolidates
the
discussions
for
eips
in
the
ethereum
magicians
forum.
Can
you
please
move
this
conversation
over
there
and
me?
If
it
helps,
we
can
offer
assistance
with
that
like
if
they
don't
know
what
assistance
they
would
need
but
like
if
they
don't
understand
the
process
or
they
don't
understand
where
we
can
provide
guidance.
A
Right
while
we
have
alita
here,
I'm
just
trying
to
understand
anita.
If,
if
I
understand
correctly,
the
bot
leaves
a
comment
on
the
first
issue.
If
someone,
if
some
issue
is
created
by
new
user,
they
leave
a
comment.
This
is
your
first
issue,
go
ahead
and
refer
to
eip1.
A
E
B
A
Or
not,
really,
I
mean
just
just
my
idea
was
like,
as
we
are
suggesting
them
to
follow
eip1.
We
can
just
add
an
additional
line,
saying
that
if
this
issue
is
created
to
disk
this
proposal
and
add
the
link
as
discussion,
two,
please
close
it
and
create
a
a
thread
at
fellowship
of
ethereum
magician.
B
Yeah,
this
should
be
like
as
soon
as
we
find
the
line
that
should
be
like
a
anyone
can
submit
a
pr
to
the
bot
to
make
that
change.
Then
text,
I
don't
know
where
the
text
actually
lives
is-
is
all.
A
A
I
will
send
it
to
you,
okay
in
the
and
it's
got
channel.
So
if
we
people
want
to
change
the
text,
we
can
do
that
all
right.
I
think
that
would
be
a
quick
fix
that
will
actually
help
us
stop
getting
new
issues
as
discussion
too,
and
then
we
will
eventually
take
on
the
existing
issues.
A
Taking
it
one
by
one
is
little
challenging,
but
maybe
if
we
get
bandwidth
to
get
that
help
of
bot
for
issue
section,
I
mean
I
understand
this
is
not
highest
of
the
priority,
but
we
can
add
it
to
our
to-do
list.
No.
A
A
Okay,
moving
on
the
next
item
is
eips
inside,
so
I
have
recently
started
like
curating
a
list
of
eips
which
is
moving
from
one
status
to
another
status.
This
eip
insight.
Actually
I
know
that
it
is
going
to
be
like
used
by
very
niche
user
base,
but
I
have
a
feeling
that
it
can
be
useful
in
long
term
so
for
people
who
are
interested
in
tracking
eips
and
they
want
to
follow
what
changes
are
coming
up
in
ethereum
blockchain.
A
This
monthly
report
will
be
helpful,
so
if,
if
anyone
has
any
suggestion
to
you
know,
add
things
to
this
monthly
reporting
that
people
may
find
useful.
Please
let
me
know.
A
In
the
last
meeting
we
we
see
three
decisions
taking
the
one,
adding
execution,
clients
and
forward
execution.
Specs
number
two
update
eip
editors
in
eip1
number
three
eipap
meeting
will
now
longer
be
now
be
larger,
but
only
occurring
once
a
month,
I'm
not
sure
about
the
larger
part,
but
we
are
at
least
following
once
a
month,
so
that
is
there
and
the
other
two
sorry.
I
did
not
get
a
chance
to
create
the
respective
pull
requests.
A
So
that's
all
for
the
meeting
today
before
we
close
anyone
wants
to
bring
up
any
other
topic.
C
C
I
don't
know
how
much
people
on
this
call
follow
the
roll-up
space,
but
basically
optimism
recently
announced
that
they
were
changing
their
approach
to
rollups
and
now
they
want
to
create
a
rollup
that
is
basically
one
for
one
compatible
with
with
mainnet,
and
so
what
it
looks
like
from
a
user
and
a
developer
is
you're
just
using
some
ethereum
sidechain
and
in
the
back
end
it's
has
data
availability
posted
on
mainnet.
It
has
fraud
proofs,
and
so
it
has
the
security
that
you
expect
from
a
role.
C
But
it
looks
like
something:
that's
less
secure
like
polygon
and
there's
a
lot
of
drama
between
these
teams.
There's
a
lot
of
like
financial
incentives
of
like
successfully
shipping
roll-ups,
and
so
it's
kind
of
seems
like
it's
difficult
to
get
people
on
the
same
page
and
have
everyone
work
together
in
a
in
a
happy
manner,
and
I
was
just
curious
if
anyone
has
thoughts
on
like
this,
you
know
developing
some
sort
of
open
role
of
specification.
C
B
C
That's
one
of
the
hypotheses
that
people
make
about
rollups.
I
think
that
things
are
changing
a
lot
and
what
people
are
finding
is
that
people
want
to
have
an
environment
that
looks
exactly
like
ethereum.
They
don't
want
to
have
to
think
about
different
nuances
of
the
virtual
machine
or
like
different
state
layouts.
They
just
want
all
the
tools
to
work
exactly
like
it
works
in
ethereum,
and
so
now
you
kind
of
have
an
endpoint
that
everyone
is
trying
to
converge
on.
C
We
want
to
be
able
to
have
a
rollup
that
emulates
the
ethereum
like
mainnet
environment,
and
so
it's
a
matter
of
like
how
can
we
create
a
fraud,
basically
a
specification
for
a
fraud,
proof
mechanism
that
allows
that
environment
to
be
verified
on
mainnet
and
that's
kind
of
what
people
are
working
towards,
and
you
know
people
of
course
can
still
implement
their
own
things,
but
I
think
there's
a
lot
of
value
in
having
something
that's
one-to-one
with
ethereum,
because
now
you
get
to
use
these
tools
all
the
tools
that
are
already
implemented
for
mainnet
again
for
free
on
your
up.
B
If
people
want
to
create
eips
for
a
one
roll
up
to
rule
them
all
by
all
means,
probably
would
be
an
erc.
I
think,
like
I
said,
I'm
not
a
fan
like.
I
think
that
trying
to
like,
I
recognize
the
value
of
standardization
and
I
think
roll-ups
are
not
the
right
place
to
do.
Standardization
like
I,
I
get
that
it's
nice
to
have
tooling
that
works
across
them,
etc.
B
B
So
I
think
that
so
yes,
there
is
some
amount
of
re-engineering,
but
there's
also
exploration
and
experimentation
like
people
are
doing
different
things
and
trying
to
figure
out
what
works
and
I
think,
that's
incredibly
valuable.
And
if
we
encourage
people
to
all
do
the
same
thing,
then
we
lose
that
exploration
and
experimentation,
and
so
we
lose
that
value.
C
Yeah,
so
I
guess
there's
like
two
things,
I'm
trying
to
understand
which
you're
specifically
talking
about.
So
there
is
the
exploration,
experimentation
of
the
actual
runtime
environment
that
people
are
going
to
be
using-
and
this
is
you
know,
a
different
virtual
machine,
a
different
state
layout,
all
of
those
things,
and
there
is
the
back
end
that
the
users
don't
see,
but
that
allows
for
the
optimistic
roles
to
be
approved
on
mainnet,
and
so
with
this
new
standard.
C
The
idea
is,
we
already
have
a
specification
of
what
the
runtime
environment
looks
like
it's
just
ethereum,
and
so
now
we're
trying
to
develop
a
standard
for
proving
ethereum
on
mainnet
and
you're,
saying
it's
good
to
have
this
exploration
of
people
doing
different
things.
B
So
I'm
not
talking
about
both.
So,
for
example,
arbitrarium
has
had
I
don't
know,
I
haven't
paid
attention
recently,
but
they
had
a
different
mechanism
for
doing
their
fraud.
Proofs
than
optimism
did,
I
think
I
heard
optimism
of
switching
to
arbitrary
solution
because
they
found
it
better.
But
again
I
don't
follow
very
closely
and
I
feel
like
that's
very
valuable,
like
the
fact
that
arbitrarium
went
and
did
something
different
and
they
tried
something
and
it
seems
to
have
worked
and
they
like
it.
B
I
don't
like
discouraging
that
and
when
you
introduce
standards,
you
kind
of
discourage
that
not,
I
would
say,
discourage,
but
people
are
more
likely
to
follow
the
standard,
because
it's
easy
rather
than
going
and
exploring
and
trying
new
things,
which
I
would
like
to
incentivize
people
to
do
at
least
a
little
bit
yeah.
C
Okay,
so
I'm
like
super
on
board
with
people
who
want
to
build
different
run
times
like
I
think,
fuel
labs
is
building
a
different
run
time
for
contracts
and
totally
on
board
with
them
doing
their
own
things
and
experimenting.
C
I'm
like
more
worried
whenever
we
there's
a
lot
of
people
who
have
this
end
goal
of
recreating
ethereum
and
now
it's
a
matter
of
you
have
different
families
of
proofs
and
so
arbitrary
has
an
interactive
proof
and
optimism
was
originally
doing
a
non-interactive
proof,
and
so
these
are
just
families
of
doing
these
things.
And
if
you
have
three
four
or
five
teams
who
are
implementing
these
different
families,
it
seems
like
there's
a
lot
of
the
same
work
going
into.
C
B
So
I
think
in
in
that
case
it
sounds
like.
Maybe
what
you
want
is
just
an
open
source
project
rather
than
a
standard,
so
I
think
like
if
you
have
two
roll-ups
that
are
building
basically
the
same
thing
it
feels
like
they
should
have.
Ideally,
in
that
perfect
world,
where
everybody
gets
along
and
works
together,
happily
there
would
be.
You
know,
a
library
repository
that
both
teams
contributed
to
and
worked
on
and
that
library
would
then
be
used
in.
B
C
Sourced,
I
think
it
varies
between
mit
and
gpl,
I'm
not
sure
exactly
which
I
think
most
of
optimism
stuff
has
been
mit
and
then
anything
that
forks
geth
is
obviously
gpo
yeah.
So
it's
really
a
matter
of
getting
people
together
and
doing
syncing
together.
B
Yeah
and
I'm
definitely
a
fan
of
people
contributing
linux
being
an
economical
example.
You've
got
a
billion
different
flavors
of
linux,
but
they
all
have
the
same
kernel
more
or
less,
and
you
know
just
using
open
traditional
oss
processes
to
build
that
kernel
and
then
everybody
uses
them,
I
think,
is
very
reasonable.
B
C
Okay,
interesting
all
right,
similar
thinking
area,
but
slightly
different
curious.
When
you
have
thoughts
on
this
idea,
the
way
that
ethereum
was
launched,
we
didn't
have
any
mechanism
and
protocol
to
fund
the
development
of
the
protocol
and
I
think,
we're
past
the
point
where
anything
like
that
is
plausible
to
implement
in
the
l1.
C
B
Instead,
you've
just
got
like
some
amorphous
group
of
people
who
are
all
working
together
like
you
have
on
ethereum,
you
know,
there's
there's
no,
I
mean
there's
ethereum
foundation,
but
they
very
much
do
not
run
things,
and
so
deciding
does
geth
get
the
money
or
does
another
mind,
get
the
money
or
does
vessel
get
the
money
is
an
incredibly
hard
problem
so
with
rollups.
B
I
think
that
if
your
roll-up
is
designed,
where
you
have
some
central
person,
who
is
the
development
team,
then
yeah,
I
think
it's
totally
reasonable
and
I
I
personally
don't
have
any
problem
with
them,
receiving
a
reward
for
their
work
or
payment
for
their
work.
B
If
they're
trying
to
build
a
roll
up,
that
is
totally
decentralized
and
has
no
leadership.
Things
get
much
more
complicated.
C
Yeah
yeah,
I
mean
it's
definitely
a
really
difficult
problem
to
try
and
figure
out
the
correct
distribution
mechanism
for
the
funds.
To
me.
You
know,
I
think
there
are
like
ways
of
doing
it.
Some
really
bad,
some,
not
as
bad.
The
thing
that
I
struggle
to
to
rationalize
is
why
would
people
not
just
remove
that
functionality
from
the
protocol,
like,
I
can't
think
of
a
good,
like
suppose,
you
do
have
this
open
source
project.
This
is
the
role
for
ethereum
many
projects
fork
that
and
just
deploy
their
own
rollups.
C
B
B
However,
they
can
go
anywhere
like
there's
really,
no
reason
to
pick
one
place
or
another
other
and
the
reason
we
picked
on
l1
to
burn
them
was
because
deciding
to
go
anywhere
else
was
way
too
contentious
and
that's
burning
them
as
the
non-potential
solution.
If
you're
setting
up
your
own
new
roll-up,
you
can
pick
where
those
go,
and
you
just
say
you
know
it
goes
to
my
account
and
they're
gonna.
B
If
someone
forks
and
does
their
own
thing,
they
can
send
them
somewhere
else,
but
they're
still
going
to
go
somewhere
like
they
need
to
not
go
to
minors,
that's
critical
for
incentives,
but
that's
basically
it
they
can
go
anywhere,
and
so
I
think
that's
a
good
opportunity,
because
those
fees
do
you
know,
need
to
be
collected
for
incentivization
reasons,
and
you
know
functionality,
reasons.
C
C
Where
you
could
say
you
know
we
all
implement
the
same
fee
burning
like
you
have
to
be
part
of
this
group
of
roll-ups,
where
you
have
fast
communication
to
other
rollups.
You
have
to
have
the
fee
burning
functionality
that
goes
to
public
goods,
and
so
now
you
can
like
join
that
group
of
rollups
and
everyone
rolls
back
together.
Everyone
goes
forward
together
and
you
can
quickly
communicate
within
one
block
to
other
roll-ups.
C
This
is
better
than
the
finality
that
you
have
to
wait
for
for
many
other
things,
and
so
that's
that
it
could
be
a
way
to
cause
people
to
to
create
friction
like
if
you
don't
want
to
pay
the
public
goods
funding
fee.
You
can
deploy
a
role
outside
of
that,
but
look
you're
going
to
have
a
longer
finality
period
and
the
communication
is
going
to
be
slower
to
that
group
of
rollups.
I
don't
know
if
you
have
any
other
thoughts
on
like
how
to
incentivize
on
a
social
or
technical
layer,
so
the.
B
The
one
the
warning
I
would
give
is
just
that
throughout
history,
any
time
charitable
donations
have
tried
to
been
forced
they've
eventually
been
captured,
like
the.
If
there
is
a
group
of
people
who
are
deciding
where
a
set
of
funds
goes
eventually,
that
group
of
people
will
be
captured
by
some
group
who
you
know,
directs
it
to
themselves
in
some
way,
often
indirectly,
but
usually
they
end
up
getting
those
payments,
and
so
by
allowing
people
to
do
charitable
donations
on
their
own
you.
B
It
is
a
very
strong
deterrent
against
capture
of
those
shared
relations,
because
as
soon
as
someone
captures
it,
people
just
simply
stop
giving
that
money
to
that
that
group,
whereas
if,
if
you
try
to
enforce
that,
you
know
everybody
who
wants
to
participate
in
this,
you
know
conglomerate
needs
to
send
their
money
here.
Then
you
end
up
with
now.
C
A
All
right,
thank
you
for
this
discussion.
I
don't
know
if
it
actually
answers
to
the
question
that
you
added
here
on
the
agenda
light
line,
but
I'm
happy
to
move
it
to
discord
or
maybe
to
the
next
meeting.
If
you
would
like
to
before
we
go.
I
have
two
things
I
wanted
to
like
just
bring
to
your
attention
here.
I
don't
know
for
some
some
reason
I
find
eip
3779,
I'm
going
to
share
the
link
here
right
away,
so
I
find
this
pull
request
as
marched.
A
But
when
I
look
into
the
proposal
it
is
still
in
the
draft.
Oh
sorry,
my
bad,
I
may
have
missed,
read
it.
He
actually
have
updated
the
ap.
Sorry
that
was
my
back
okay
and
the
other
thing
is:
do
we
want
to
continue
the
one
month
or
the
four
weeks
thing
or
is
it
okay?
We
we
keep
it
tentatively
for
two
weeks
and
if
we
don't
have
much
things
on
the
agenda,
we'll
come
back
after
two
four
weeks.
What
do
you
think.
B
I
have
a
week
preference
for
meeting
every
two
weeks
and
we
just
cut
it
short
if
we
don't
have
anything
to
talk
about
rather
than
having
less
frequently
that
way.
If
something
does
need
to
be
talked
about,
we
have
a
semi-regular
opportunity
to
do
so.
A
A
So
that
way,
nice
yeah
yeah
yeah.
In
fact
I
am
also
yeah,
I'm
also
in
agreement
to
that.
I
feel
like
having
it
two
weeks
put
us
into
a
schedule
like
okay.
We
have
to
like
get
things
done
before
that,
and
we
have
this
agenda
ready
and
if
we
do
not
have
much,
then
we
will
move
it
to
the
four
weeks.
Okay,
I'll
mark
it
for
two
weeks
now
and
then
we'll
come
back.