►
From YouTube: EIPIP Meeting 27
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/54
A
Okay,
so
hello,
everyone
and
welcome
to
eipip
meeting
number
27..
The
first
item
on
the
agenda
is
the
eip
github
repo
action,
bot
and
pj.
You
said
you
have
a
small
update
because
I
don't
think
elite
is
here.
B
Yeah
considering
the
issue
with
the
present
efp
bot,
the
eipip
group
discussed
to
address
this
by
possibly
having
another
bond
and
ethereum
cathedrals
are
funding.
The
effort
and
elite
moved
from
the
team
is
working
on
it.
I
guess
she
made
some
progress.
As
far
as
I
know
she
had
some
questions
related
to
testing,
but
unfortunately
I
don't
see
her
on
the
call
today.
So
maybe
I
would
ask
her
to
get
in
touch
with
the
micah.
If
that
is
fine
and
yes,
we
can
get
it
done.
Like
often.
A
Okay
sounds
good
all
right.
The
next
item
is
progress
on
the
content
for
the
eth
1.0
spec
repo,
including
json
rpc
and
network,
upgrade
pages.
B
So
the
atm
we
are
trying
to
add
some
useful
resources
to
ethereum
one
dot
or
spec
repo,
and
I
believe
james
is
taking
care
of
that.
Maybe
adding
the
previous
network
upgrades
and
some
effects.
B
I
have
just
one
small
update
on
gsn
rtc
side
that
ech
is
organizing
a
peak
meeting
for
eip
1474
remote
procedure
call
specification
on
march
17th
with
eric
marks
and
maurice
one.
We
are
where
we
are
trying
to
provide
the
overview
of
the
proposal
and
how
the
implementation
is
done,
because
many
people
have
questions
on
that
particular
proposal.
B
A
All
right
great
item
number
three
is
the
relationship
between
the
eighth
one
and
eth2
specs.
I
think
that's
something
that
danny
put
on
the
agenda
and
wanted
to
talk
about
today
with
the
merge
coming
up
and
things
like
that
so
danny.
If
you
want
to
kind
of
talk
about
what
you
had
in
mind
for
the
discussion
today
and
we
can
chime
in.
C
So,
as
you
know,
largely
we've
done
specification
writing
in
an
independent
repo
called
the
eqo
spectrum.
Though,
and
moving
forward,
we
are
beginning
to
write
specs
that
have
a
tighter
relationship
to
existing
specifications,
things
that
we
normally
call
each
one
specifications
and
just
for
some
context,
the
way
that
we're
currently
writing
specifications
and
currently
protecting
things
is
essentially
take
each
one
subtract
out
proof
of
work,
addie's,
two
as
consensus
layer
and
you
have
specifications.
C
Obviously
we
did
2982
at
the
end
of
last
year,
which
was
met
with
some
contention
from
eip
editors
as
to
whether
that
actually
made
sense
to
tie
like
the
20
specs
repo
into
the
eips
that
way
in
an
informational
spec,
and
I
just
want
to
pick
your
brains
get
some
advice,
get
some
thoughts
on
how
best
to
do
this,
because
the
specifications
moving
forward,
look
like
modifications
to
the
consensus
layer,
proof
of
statements,
layer,
specifications
in
the
e2o
repo
and
linking
somehow
into
the
application
layer,
specifications
which
is
largely
like
what
we
call
ease,
one
largely
exists
in
eips.
C
I
know
there's
also
the
yellow
paper.
I
know
there's
also
this
one
of
specs
repo
on
releases
and
there's
a
lot
of
moving
parts,
and
it's
not
clear
how
to
it's
clear
in
my
mind
how
to
link
them
together
technically,
but
not
necessarily
practically
from
like
a
specification
and
maintenance
standpoint.
So
I
just
wanted
to
see
if
y'all
had
any
ideas-
and
I
don't
suspect-
we'd
necessarily
decide
today,
but
I
just
wanted
to
put
it
out
there.
A
So
I
guess
my
first
thought
is:
what
is
the
way
that
we
can
do
this?
That
best
signifies
that
this
is
a
single
etherium,
because
I
think,
that's
really
important
to
make
sure
that
we
don't
frame
this
well,
it's
already
kind
of
a,
I
think,
misnomer
might
be
the
right
word
that
eth2
is
like
totally
separate
from
each
one
or
like
is
a
whole
new
thing,
and
each
one's
deprecated
more
so
than
this
merge
that
we're
kind
of
developing
a
new
narrative
for
so,
I
think,
that's
an
important
aspect.
A
I
also
think
that
it
might
be
hard
to
answer
how
it
should
come
together
until
we
figure
out
how
best
to
organize
eth1
stuff
and
get
that
complete,
because
from
last
I
heard-
and
someone
might
be
able
to
answer
me-
the
yellow
paper
is
not
updated.
The
eips
repo
is
still
looking
for
more
editors
and
the
ethos.
Spec
repo
still
doesn't
have
all
of
the
things
it
wants
in
it
yet,
including
previous
network
upgrade
information
and
some
other
stuff,
like
the
json
rpc
spec.
C
A
Is
part
of
it?
Yes,
so
it
used
to
be.
When
you
go
to
the
eip
repo,
you
would
have
different.
You
would
have
meta
eips
for
like
homestead
and
all
those
other
ones,
and
that
would
really
conflate
a
standards
process
with
a
release
process,
including
stuff
like
having
final
and
eips
mean
it's
enough
work
when
you're
talking
about
quarry
ips.
So
we've
changed
up
some
of
the
terminology
and
also
tried
to
separate
out
the
standards
from
the
non-standard
stuff,
including
network
upgrades,
to
make
it
a
little
bit
easier.
A
C
Great
interesting
so
in
my
mind,
and
maybe
not
in
the
mind
of
everyone,
but
what
we
call
each
one
is
more
like
in
this
and
in
a
merged
world,
each
one,
minus
proof
of
work
is
like
the
application
layer
and
ease.
Two
is
the
kind
of
consensus
layer,
the
cradle
for
the
application
layer,
and
maybe
maybe
the
linkage
is
actually
between
these
two
spec
repos
in
that,
when
there's
a
once,
there's
a
merge.
D
C
Kind
of
things
are
released
in
tandem
where
the
application
layer
is
at
this
point
and
the
consensus
layers
at
this
point
and
they're
they're,
tied
together
through
essentially
on.
D
C
On
the
on
the
consensus
layer,
there's
like
a
function
call
under
the
application
layer,
but
in
it
it
might
be
very
clean.
It
also
might
there
might
be
more
than
one
tie
and
it
might
be,
it
might
be
dirty
and
we
might
just
kind
of
see
how
it
how
it
lands,
so
that's
one
possibility
and
to
so
tie
them
through
these
two
repos,
instead
of
through
the
eips,
like
I
tried
at
the
end
of
last
year,.
E
So
my
initial
thought,
with
the
process
that
would
result
in
the
least
change
to
the
process,
would
be
that
anything
that
needs
to
happen
for
the
merge
that
would
go
into
an
eth1
client
would
go
through
the
ap
process,
so
any
changes
that
each
one
clients
need
to
make
prior
to
the
merge
and
then
once
the
merge
happens
at
that
point,
any
changes
to
either
eth1
clients
or
e2
clients
would
go
through
the
eip
process.
So
basically
the
e2
clients
would
join
the
eip
process.
As
of
the
merge
until
the
merge,
then
yeah.
C
D
C
C
No,
it's
quick
and
dirty
kind
of
by
design
things
move
very
quickly
and
rapidly,
and
we
do
have
kind
of
rough
consensus
in
the
specs
repo
and
what
gets
built
by
clients
and
released.
But
the
plan
is
certainly
to
refine
that
into
a
point
in
which
that
it
unifies
with
the
e10
development
process
at
the
merge.
C
B
Okay,
so
from
where
I
was
looking
at
this
each
one
and
e2
merge
process.
I
consider
this
like
to
be
in
like
three
phases.
If
we
divided
that
would
be
helpful
for
both
of
us
from
the
ethos,
client
perspective
and
maybe
from
the
e-2
client
perspective.
Something
is
like
pre-merge
stage
hypothetically
like
if,
for
this
merge
has
to
happen
like
in,
like
next
15
months
by
the
summer
of
2022,
so
we
have
this
pre-merge
phase,
so
we
have
to
work
on
the
proposals
that
is
needed
for
the
e2.
Much
later
on.
B
B
Okay
and
if
we
consider
that
to
happen
before
august,
we
we
might
want
to
focus
on
the
proposal
sites
like
which
proposal
would
be,
if
at
all,
that
would
be
needed
for
the
eat
to
merge
and
then
for
while
preparing
for
the
eth2,
whatever
proposal
we
could
not
consider
and
they
and
we
find
that
these
are
useful
and
that
would
be
needed
or
maybe
helping
out
in,
like
whatever
the
shifting
of
brain
from
each
one
to
e2
would
be
required.
We
can
look
into
that.
B
So
what
I
was
trying
to
mention
here
is
like
if
we
would
like
to
consider
this
much
process,
not
the
process
of
the
overall
ethereum
chain
running,
but
what
what
we
are
expecting
from
ethereum
1.0
client.
Maybe
we
have
to
figure
out
what
e2
needs
from
us,
as
that
was
mentioned
in
the
last
encoder
meeting
right.
C
C
How
do
we
write
it
down
and
where
do
we
write
it
down
and
there's
interplay
there,
certainly
and
tim,
and
I
and
others
are
going
to
work
on
the
the
practical
component
of
like
what
actually
we
plan
on
producing
a
document
the
next
week
or
so
that
says
like
these
are
all
the
things
that
actually
need
to
happen,
at
least
from
the
best
of
our
understanding
right
now,
and
we
have
a
relatively
clear
path
on
how
to
begin
to
integrate
those
onto
the
consensus
layer
side
on
the
on
the
2o
side
in
terms
of
specifications,
and
then
we
need
to
think
about
how
to
integrate
them.
C
On
the
other
side-
and
I
think
you
know,
a
number
of
these
things
can
show
up
as
as
eips
but
contextually
the
eips
need
the
so
like,
for
example,
the
change
of
the
difficulty
opcode
that
that's,
you
know
essentially
like
bricked
in
a
proof-of-state
context,
and
you
need
to
decide
what
that
what
it
returns
in
that
context,
because
there's
legacy
contracts
that
use
it.
D
C
That
says,
brick
the
difficulty
op
code
it
it
needs
the
context
of
in
the
context
of
proof
of
stake,
because
otherwise
it
looks
like
a
pretty
silly
eip,
and
so
at
that
point
I
mean
we
can
point
back
to
the
20
specs
repo,
but
which
works,
but
there's
also,
I
don't
know
we
need
to
figure
out
that
process
and
mike
are
you
back.
E
Just
to
be
clear
what
I
proposed
before
I
got
disconnected
wasn't
necessarily
my
preference
just
that
was
the
process
that
was
closest
to
what
we
have
today.
E
Regarding
your
question
on
linking
to
east
2
specs
repo,
so
I
have
a
pretty
strong
policy
as
anyone
who
watches
the
vips
repo
would
know
against
linking
outside
of
eth2
repo,
and
the
reason
for
that
is
because,
for
any
sort
of
long-lived
document,
repository
links
will
all
eventually
404.
any
lengths
that
is
outside
of
your
page.
E
And
with
a
single
editor,
I
cannot
keep
up
with
the
thousand
things
of
404
every
day.
That
being
said,
I
also
recognize
that
it's
unreasonable
to
say,
okay,
you
need
to
define
all
of
these
two
specs
in
the
eip's
repository
like
that's
insane,
and
so
I
I
don't
have
a
great
solution.
I
think
we
might
just
have
to
accept
that
we're
going
to
have
broken
links
at
some
point
and
that
we
make
an
exception
in
this
one
case.
E
C
In
terms
of
maintenance
and
and
if
if
we
presume
that
the
merge
happens
and
the
eco
specs
become
canonical
consensus
for
state
consensus
specs
and
are
used
in
mainnet
ethereum,
the
there's
less
of
a
chance,
I
mean
there's
definitely
a
chance
that
links
break.
But
if
we're
pointing
to
like
specific
releases
on
that
repo,
you
know
those
that
are
maintaining
the
two
spectrum.
C
Those
that
are
maintaining
relative
eips
become
certainly
have
more
of
an
overlap,
and
so
there's
probably
less
chance
that
it
becomes
like
kind
of
an
external
repo
that
just
or
an
external
link
that
just
dies.
But
I
see
I
mean
I
definitely
I
I
I
agree
with
you
that
there's
a
there's,
fundamentally
kind
of
an
issue
there
and
makes
relevant
yeah
he's
brittle.
So
I
mean
one
other
and
this
one
other
potential
way
to
do
this.
C
No,
I
didn't
think
about
it.
Do
does.
E
E
No,
for
basically
the
same
reason,
I
mean
the
type
of
the
class
of
problems
that
I'm
worried
about
with
the
u2
specs.
Repo
is
less
that,
oh,
what
if
e2
specs
when
we
don't
go
to
these
two,
it's
more
like
what
what
happens
when
github
starts.
Centering
people
and
everybody
moves
to
gitlab
and
now
the
e2
specs
is
not
github.com2.
Specs
is
now
gitlab.com,
two
specs
and
then
six
months
later
they
joined
the
bandwagon.
We
moved
to
some
random
dark
web
onion.
E
Yeah
so
again
again
in
this
one
case,
maybe
this
is
a
special
case.
It's
worth
it
going
forward
like
long
term,
and
this
gets
back
to
we're
saying
that
I
don't
necessarily
think
the
eaps
process
is
the
best
process
for
use
to.
E
It
might
be
better
and
would
address
this
if,
instead
of
having
eip
process
that
then
adjusts
a
spec
that
lives
somewhere
else
like
right
now,
the
eip
process
kind
of
technically
adjusts
the
yellow
paper.
Since
you
guys
already
have
all
your
stuff
in
github,
it
might
make
more
sense
to
have
your
change
control
process
b,
pull
request
against
that.
So
that
way,
it's
all
in
one
place
and
right,
and
I.
C
C
C
Yeah
yeah,
I
understand,
would
if
there
was
a
more
maintained,
yellow
paper
and
somebody
doing
that.
Would
that
change
the
way,
the
relationship
with
like
the
eip
core
ips
and
the
ethernet
vector
repo
and
stuff,
or
is
that
do
you
consider
just
kind
of
independent
at
this
point.
E
I
I
would
like
that,
like
I
would
love
it.
If,
instead
of
the
yellow
paper,
we
had
a
specs
repo,
like
you
guys
have
for
east
2,
and
we
had
it
for
each
one
and
actually
documented
the
current
protocol
fully
and
then
from
there.
We
could
then
do
prs
against
that
as
either
as
part
of
the
eip
process
or
just
replace
the
erp
process
with
direct
pr's
to
the
spec.
E
The
reason
I
haven't
pushed
on
that
or
even
proposed
really
is
because
that's
a
pretty
big
change
and
it's
hard
enough
getting
you
know,
one
op
code
removed
nonetheless,
changing
the
entire
process.
C
B
A
C
Yes,
yes,
paul
is
sorry.
Cat
paul
is
has
a
lot
of
familiarity
with
the
wasm
spec,
which
has
a
written
spec
and
a
accompanying
code
spec.
That,
like
kind
of
line
by
line,
is
very
literally
an
implementation
of
the
written
spec,
and
he
is
talking
about
doing
that
for
the
yellow
paper
and
updating
yellow
paper
and
such
a
executable
spec,
along
with
a
written
spec,
might
change
the
way
the
possibilities
are
doing
here.
Obviously,
there's
a
lot
of
unknowns.
There
one
will
be
done,
two
who's
maintaining
it.
C
You
know
all
of
that,
but
it
might
be
worthwhile
for
one
of
y'all
to
reach
out
to
paul
to
get
a
handle
on
what
he's
attempting
to
do
and
whether
that's
relevant
to
the
iep
stuff.
So
let's
do
this.
C
We
can
talk
about
this
as
much
as
you
all
want
to,
but
I
I
will
say
I
won't
drop
an
eip,
like
we
did
at
the
end
of
last
year
without
chatting
with
y'all
and
as
the
specs
are
written
on
the
2o
side
and
we're
trying
to
formalize
how
to
do
the
same
on
the
the
1
0
side.
C
A
Does
the
spec
all
the
way
up
to
the
merge,
and
then
they
start
filing
the
ips.
After
that
that
that
sounds
like
what
we're
set
up
for
today.
Yeah
I'd,
say.
C
C
The
one
well,
the
one
problem
is
there's
like
there's
two
major
things
we
want
to
do
with
the
beacon
chain.
One
is
merge,
the
ethereum
application
layer
into
it
and
the
other
is
charting
iterative
work
on
the
consensus
layer
after
the
merge
that
didn't
include
sharding
would
probably
be
pretty
simply
to
be
able
to
be
done
in
eips,
but
post
that.
C
A
I
I
think
what
we
want
to,
I
think,
a
good
goal
for
when
we're
figuring.
This
out,
though,
is
to
make
sure
that
eth
two
stuff
feels
comfortable
rolling
into
eips,
trying
to
figure
out
the
best
way
to
say
this
like
right.
We
don't
want
this
to
be
a
hindrance.
I
guess
like.
C
C
Even
if
we
do
move
in
to
do
iterative
work
in
the
eip
stuff,
it
will
always
be
accompanied,
at
least
for
the
foreseeable
future,
with
executable
spec
modifications
which
so
then
we're
maintaining
things
in
two
places
which
isn't
crazy.
I
mean
that's
the
the.
C
D
Yeah,
my
understanding
of
the
yellow
paper
is
that
it's
a
user-readable
version
of
what's
in
the
the
eips
combined
with
e2
spec,
the
e2
spec,
or
I
mean
the
east
one
spec
in
the
eips.
D
B
C
Right
so
I
mean
in
that
sense
it
might
go
to
to
that
end.
If
we
do
want
to
maintain
this
thing,
the
executable
you
spec
in
a
different
place
to
be
able
to
build
tests,
then
that
would
point
to
potentially
not
doing
the
iterative
vip
thing
and
having
a
different
change
process
more
closely
to.
C
E
E
A
A
Okay,
that
might
be
it
but
but
yeah.
I
think
that
this
would
be
the
opportunity.
The
only
opportunity
if
we
were
to
do
this
after
merge
to
separate
the
eips
repo
between
ercs
and
eips,
and
then
that
new
fresh
start
would
enable
us
to
do
all
eth2
and
one
related
core
consensus,
application,
protocol
work
and
one
repo
and
then
erc's
in
the
other.
E
E
E
Oh,
my
god,
I
do
not
want
to
read
the
latest
upgradeable
smart
contract
protocol
or
the
10th
latest
or
whatever
we're
up
to
the
one
problem
you
might
run
into.
Is
that
I
suspect,
if
we
do
this,
what
will
happen
is
no
one
will
be
an
editor
for
the
air
sees
repo,
like
the
only
reason
I'm
an
editor,
for
it
is
because
it's
currently
bundled
in,
and
I
feel
obliged
to
respond
to
them
as
soon
as
you
split
it
off.
E
C
A
Yeah
that
makes
sense
okay,
so
it
sounds
like
where
we're
at
is.
If
default
happens,
and
we
don't
have
more
of
these
meetings
as
things
get
closer,
it
would
be
spec
repo
or
the
specification
repo
for
eth2
continues
on,
and
then
they
start
doing
eips
after
the
merge,
and
then
we
figure
out
something
for
sharding
later,
which
michael.
A
C
E
Yeah,
I
would
say
the
default
should
be
that
application
layer
does
eips
and
this
layer
does
whatever
their
process
is
probably
pull
requests
and
then,
if
someone
comes
up
with
a
reason,
not
to
do
that,
then
we
have
a
backup
plan
of
at
the
merge.
Have
these
two
specs
go
to
eyepiece?
D
C
C
Is
to
have
very
few
right
like
I,
I
think
that
there's
a
lot
more
moving
pieces
in
the
proof-of-stake
mechanism
than
the
work
mechanism,
and
so
I
would
expect
certainly
over
the
next
12
months,
some
refinement.
There's
some
refinement
expected
to
go
out
this
summer.
So
I
I
can't
say
for
sure,
but
that'd
be
great
if
it
was
largely
stable
and
then
we
can
get
back
to
application
layer,
modifications,
yeah
yeah.
I
don't
know.
A
Okay
and
I
hope
more
people
as
things
get
closer
to
the
merge-
will
get
more
involved
in
a
meeting
like
this
yeah,
because
I
think
we
just
need
more
think
people
thinking
on
this
for
different
ideas
and
yeah.
It's
unfortunate.
There
wasn't
as
many
people
on
today,
but
let's
have
a
different.
A
Let's
definitely
bring
this
up
again
at
a
future
eipip
meeting
and
hopefully
by
then
we'll
have
a
few
other
things
solved
like
more
editors,
onboarded
and
things
will
be
cleaned
up
a
bit
more
so
that
I
mean
hope,
I'm
hopeful,
but
there's
no
indication,
that's
happening,
but
I'm
still
hopeful
that
we'll
have
more
editors
and
things
like
that.
So
we
can
have
things
cleaned
up
a
little
more
and
like
have
a
better
clear
distinction
and
what
the
eath
one
point
of
spec
repo
becomes.
A
Yeah,
another
default
is
going
to
be
the
the
linking
between
the
eth1
eips,
like
the
difficulty
opcode
stuff
and
linking
that
to
reasoning
at
an
eth2
repo.
That's
like
I
think
that
has
what
has
to
happen.
I
can't
think
of
an
alternative
unless
we
start
including
more
documentation
in
the
eip
repo
itself.
A
E
B
C
That
I
I
can
provide
the
context
verbally
like
the
in
the
context
of
an
merge,
a
movement
to
prove
mistake
like
this
is
a
modification
of
the
difficulty
op
code
to
be
this
instead
of
the
previous
proof-of-work
context,
and
I
can
say
that
all
verbally,
I
don't
have
to
even
point
to
an
external
link,
but
it's
at
least
contextualized
by
something
that
is
not
in
the
eip
repo.
E
Yeah
I'm
willing
to
to
let
it
slide
in
this
case,
because
this
is
special.
The
the
reason
I
have
I
have
this
personal
rule
is
because
I
get
ercs
that
have
just
like
links
to
people's
personal
github
accounts
and
they're
like
go
go
here
for
all
the
details
of
this
spec
yeah.
C
A
E
E
C
E
C
D
On
fear
of
external
con
links
and
and
401
errors
to
me,
everything
should
be
done
in
a
weekly
way,
leaderless
way
like,
for
example,
right
now,
we've
got
eip.ethereum.org
and
ethereum.org
slash
eips
and
we're
proposing
moving
the
ethereum.org
eips
over
to
eips.ethereum.org
and
that's
going
to
break
a
few
links.
And
so
I
would
like
to
take
on
the
responsibility
to
track
down
those
links
and
get
them
fixed
ourselves.
Because
micah
mentioned
the
bottleneck
process.
D
He
can't
keep
up
with
all
the
links
and
keep
them
all
fixed,
but
but
if
you
put
it
on
the
leaderless
bottom-up
way,
so
when
someone
moves
a
page,
they
should
be
able
to
go
out
and
find
all
the
links
and
make
the
changes
from
the
from
that
end
when
you
so
that
we're
not
bottlenecked
by
by
anything
and
everything
can
be
done
by
anyone.
But
anyway,
just
a
thought.
E
Yeah,
it
gives
me
one
idea,
though,
in
theory
eip
specs
repo,
yet
e2,
specs
repo
is
currently
a
github
repository
right
likes
with
markdown
files
in
github
hypothetically,
we
could
include
it
as
a
sub
module
and
the
eips
repo,
and
that
way
we
can
link
internally.
C
Right
and
a
an
eip
that
modified
the
consensus
layer
could
also
modify
the
would
actually
modify
like
actually
do
the
code
modification
as
well.
A
C
Yeah
the
gel
paper
is
like
gel
paper,
is
a
k
specification
of,
I
think,
primarily
the
evm.
It
doesn't
have
all
the
cradle
components
like
the
stuff,
but-
and
I
don't
know
I
don't
know-
if
that's
actually
very
maintainable-
the
gel
paper
owners
claim
that
it's
very
maintainable,
but
it's
it's
very
dense
to
read.
In
my
opinion,.
C
I
would
say
I
would
also
I
would
encourage
one
of
you
to
hit
up
paul
d
to
hear
about
what
he's
working
on
on,
like
an
executable
spec
accompanying
with
some
yellow
paper
updates,
which,
if
we
had
an
executable
that
kind
of
both
layers,
then
we
can
start
to
do
some
pretty
interesting
things.
Maybe
and
putting
that
in.
Like
the
1
0
spectrum,
though,
and
there
can
be
some
interplay
between
the
two
there.
A
Yeah
we
just
throw
money
at
someone
to
maintain
the
yellow
paper.
I
think
just
get
it
up
to
speed
before
the
merge
yeah.
You
gotta
find
the
right
someone.
A
Okay,
I
think
we're
good
with
this
topic,
unless
anyone
has
any
final
stuff.
A
Soon,
yeah
we'll
have
another
one
of
these
eventually
bye.
Unless
you
want
to
stay
whatever
you
want
to
do,
I'm
out
later
all
right
see
you
next
up.
We
have
eip
editors,
onboarding
and
request
for
funding.
I
don't
have
an
update
for
that,
so
we
can
go
to
the
next
thing.
Oh
actually,
no,
we
do
have
an
update
for
that.
We
have
a
blog,
don't
we.
B
Right
so,
after
the
release
of
the
block
blog
become
an
editor,
we
have
been
approached
by
a
few
people
from
the
community.
Those
are
interested
in
being
edited
and
they
have
questions
on
the
process
part
and
if
this
position
is
compensated,
etc.
B
B
Okay,
so
like
what
would
be
the
best
place
where
we
can
send
like
any
group-
or
I
don't
know.
A
Micah
where's
your
preferred
place
to
be
discussing
with
these
people
like
either
the
eips,
chad
and
eath
r
d,
discord,
the
cat,
herders
chat
and
discord
or
a
telegram
group.
What
do
you
like.
A
Okay,
pooja:
do
you
have
a
place
that
you
think
would
be
best?
Maybe
the
cat
herders
discord.
B
A
And
if
you
make
that
channel
remind
me
to
turn
on
notifications
for
it,
because
I'm
really
bad
at
that,
so
in
fact
I'm
going
to
change
my
notification
settings
for
the
cad
headers
channel
after
this
call,
because
I
think
they
got
muted
automatically
when
I
joined,
and
I
don't
want
that
to
happen.
B
Okay,
yeah,
I
mean
definitely
so
there
is
already
a
channel
of
eip
where
alita
is
throwing
some.
You
know
stuff
for
the
boss
one,
but
I'm
gonna.
Do
we
want
to
have
a
separate
channel
for
the
api
data?
So
we
can
continue
the
discussion
over
there
because
everything
is
going
for
the
eip
depot.
Only
there.
E
So
one
question
one
question
I
I
have:
maybe
someone
else
can
ask
of
all
the
applicants
is
why
in
the
hell,
would
you
want
to
work
for
free
on
fbi
fees?
Anyone
who
wants
that
at
eips,
I'm
very
suspicious,
of
which
I
know
I
shouldn't
be
since
I
should
that
would
make
me
suspicious
of
me,
but
I
am
very
suspicious
of
me
too.
I
don't
know
why
you
guys
trust
me.
A
They
probably
are
asking
about
compensation
which
isn't
happening
yet,
but
if
they're
still
like
I'm
willing
to
wait
for
that
or
like
I'll
come
back,
when
we
have
compensation
that'd
be
fine
too,
we
can
still
vet
them
beforehand
or
get
to
know
them.
That's
not
that's
not
a
negative
thing.
E
B
Yeah
we
received
these
queries
like
if
this
job
is
compensated.
I
already
have
informed
people
that
at
the
moment
it
is
not,
but
we
are
considering
some
options
to
get
provide
funding
to
this
particular
road
and
yeah.
Obviously,
if
they
would
want
to
consider
it
now
or
maybe
come
back
later,
it's
fine
okay.
A
B
D
Yeah
I
integrate
last
last
meeting
we
talked
micah
had
the
idea
of
removing
meta
information
in
the
eip
repository
like
eip1
out
of
the
repository,
and
so
I
it
included
that
idea
in
in
in
the
proposal
that
I'm
doing,
and
the
next
step,
I
think,
is
to
create
a
so
what
and
we
want
to
move
that
into
eips.ethereum.org.
And
so
I
think
the
next
step
is.
D
We
need
to
set
up
some
kind
of
staging
area
where
we
can
build
a
new
version
of
ethereum
or
eips.ethereum.org,
and
I
asked
puja
before
the
meeting
who's
responsible
for
that
and
sounds
like
axic
is,
and
so
I'm
going
to
reach
out
to
to
find
out.
If
there
already
is
a
stationary
grade,
if
not
I'll,
look
towards
seeing
what
is
required
to
set
one
up
like
that
and
push
in
that
direction.
But
that's
just
just
an
update
of
where
I'm
going.
What
I'm
going
to
do
next.
A
D
When
we
made
the
changes
to
the
eipip
process,
all
of
the
new
updates
got
made
to
eip1
and
right
now,
that's
the
canonical
set
of
staging
of
of
where
the
canonical
information
is
and
last
meeting
micah
proposed,
moving
that
out
of
there
and
moving
that
someplace
on
to
eip.ethereum.org,
and
so
that
that,
and
so
I
added
that
proposal,
and
I
think
that's
a
great
idea
specifically
since
it
it
needs
to
take
some
of
the
workload
off
of
eip
editors
and
and
stuff
like
that,
and
and
so
I've
assumed,
that's
okay,
it
sounds
like
you
might
have.
A
I
more
just
want
to
understand
it
before
I
have
a
problem
with
it
or
not
because
like
if
it's
so
it
wouldn't
be
a
meta
eip
anymore.
It
would
just
be
a
rule
set.
Then
yeah.
D
We
would
define
the
canonical
med
eip
information
somewhere
on
eip.ethereum.org
and
and
that's
why
I
want
to
set
up
a
a
staging
area
where
we
can
move
all
that
and
get
all
that
set
up
and
get
it
because
right
now
it
is
the
ip1
that
is
the
canonical
stuff,
but
we
want
to
get
a
stationary
set
up
and
get
everyone
on
board
and
say:
yes,
that's
sufficient.
E
E
Like,
for
example,
right
at
the
top,
what
is
an
eip
eip
rationale:
talks
about
the
eip
workflow.
What
belongs
in
successful
eip
like
this
all
feels
like
the
workflow,
probably
is
fine
to
stay,
but
like
the
what
belongs
successfully,
I
fee
feels
more
like
a
tutorial
or
like
a
blog
post
or
something
that's
kind
of
this
isn't
a
spec.
This
is
just
like
some
helpful
information
for
newcomers,
and
I
currently
that
type
of
information
is
spread
out
in
multiple
places
and
I
feel
like,
rather
than
putting
everything
more
stuff
into
eip1.
E
Instead,
we
can
take
some
stuff
out
of
the
ip1
and
have
efp1
focus
purely
on
this.
Is
the
process
like
these?
Are
the
requirements
like
it's?
Basically,
a
standard
for
eips
like
eip1,
becomes
an
eip
in
it.
Like
I
guess.
What
I'm
trying
to
say
is
eip1
is
a
technical
standard
right
now
it
is
a
technical
standard
with
a
whole
lot
of
non-standard
information,
like
non-normative
information
in
it,
and
I
would
like
to
pull
out
some
of
that
non-normative
information
and
put
it
somewhere
else.
A
E
A
E
Yeah,
the
idea
is,
we
would
take
the
information,
that's
currently
there
and
then
move
it
over
to
ethereum.org
and
then
delete
it
from
eip1
after
it's
moved,
so
not
not
that
we
delete
it
first
and
then,
maybe
later
we'll
add
it
somewhere
else.
It's
definitely
a
migration.
So
we're
moving
to
a
new
location.
A
Yeah,
I'm
not,
I
don't
have
a
strong
opinion
on
this
like
I'd.
Probably
if
I
had
to
choose
I'd,
probably
keep
it
the
way
it
was
for
simplicity
but
like
at
the
same
time.
I
see
your
points
and
that
sounds
good
to
me.
We
can.
This
could
also
start
the
thing
where
it's
like
less
opinionated,
on
how
to
do
stuff
and
and
more
just
like
you
said,
a
technical
specification
on
the
process
itself.
E
Yeah,
that's
that's
what
I
would
like
looking
through
it
like
as
an
example,
there's
a
history
section
in
the
ip1
that
talks
about
bitcoin's
bip
process
and
that
really
an
ibm
doesn't
belong
in
it
like
a
technical
spec
for
how
to
build
an
eip.
It's
like
history
and
it's
interesting,
and
it's
useful
just
I
I
feel
like
the
ethereum.org,
which
already
has
a
whole
bunch.
More
of
that
type
of
information
is
a
better
place
for
it
like
the.
Why
and
the
history
and
the
you
know
stuff
like
that,.
D
A
E
Yeah,
I
think
that's
technical,
like
basically
anything
that
I
as
an
editor
would
refer
to
and
say,
hey
you're,
not
following
the
standard
point
back
to
eip1
so
like.
If
someone
tries
to
go
from
draft
to
final,
I
would
point
to
eip1
and
say
that's
not
allowed
see
here.
Okay,
so
if
it's,
whereas
I'm
never
going
to
point
someone
and
say,
hey,
look
at
the
history
and
of
the
bitcoin
process
like
as
a
reason
to
reject
their
eip.
E
So
if,
if
something
is
like
a
specification
or
a
standard
or
like
a
requirement
for
the
process,
then
I
would
say
ep1
and
if
it's
more
just
metadata
about
the
process
or
description
of,
why
we
have
this.
Or
you
know
where
this
is
the
history
of
it
stuff
like
that.
That
would
be
moved
over
to
ethereum.org.
D
E
I
mean
there's
the
other
option
and
I'm
not
against
this,
not
for
it
just
to
throw
it
out
there,
which
is
to
just
get
rid
of
vip
one
and
just
put
everything
somewhere
else.
D
E
Okay
with
that,
oh
just
I
mean
it
does
mean,
there's
just
one
less
place
that
people
have
to
know
to
look
for
things
like
it
consolidates
information,
so
I'm
not
against
just
one
the
whole
thing
out.
I
don't
know
how
other
people
feel.
D
Right
but
but
I
think
we
should
have
a
very
clear
location,
whether
it's
eip1,
where
these
are
the
states
eip
go
through,
and
this
is
the
process
you
do
to
migrate
from
one
step
to
the
other
and
it
doesn't
need
to
be
any
ip1.
But
if
that's
where
we
want,
but
but
we
should,
if-
and
I
was
proposing
moving
that
exactly
thing
so
that
every
time
you
want
so
mike
had
to
say
you're
not
following
this,
he
would
point
to
wherever
that
location
is,
and
I
thought
we
were
removing
that
the
eip.etherium.org,
but
but.
E
D
Okay,
so,
which
way
so
have
you
changed
your
mind
and
should
I
back
off
a
little
bit
on
that
or.
E
D
That
idea,
because,
because
because
the
eip
repository
is
where
we
want
to
have
the
ether
spec,
and
we
eventually
want
to
have
that
the
canonical
ether
spec
stuff
and
have
some
kind
of
automated
process
where
that's
the
canonical
ether
spec
and
all
that
meta
information
should
be
moved
out
of
that.
So
that's
I
like
that
idea,
but
anyway,
so
so
so
are
we
still
going
with
completely
moving,
but
but
again
before
we
make
that
move,
we've
got
to
have
the
staging
area
and
we've
got
to
have
everything
built
and
say.
D
This
is
where
we
want
the
new
to
be
new
stuff
to
be,
and
it
has
to
be
sufficient
for
micah
and
hudson
and
everyone
ether
and
and
pooja,
and
everyone
make
sure
we
have
okay
yeah
everyone's
happy
with
that.
Now
we
can
throw
the
switch
so
so
so
that's
why
my
proposal
is.
We
need
to
start
building
a
staging
area
where
we
can
start
building
that
and
moving
everything
out
and
moving
in
that
direction.
D
A
I
don't
have
a
strong
opinion
because,
like
I
see
the
pros
and
and
a
little
bit
of
the
cons
cause
like
the
cons,
mainly
the
number
one
con
in
my
head
is
like
it's
now
in.
There
is
now
information
in
two
places
or
more
that
people
have
to
go.
Look
so
like
I
might
need
to
go.
Read
a
blog,
read,
ethereum.org
and
read
eip1
to
get
the
technical
non-technical
and
recommended.
E
D
E
Hey,
you
probably
did
I
I
I
learned
the
other
day.
My
brain
is
full.
I
asked
them
a
question
and
like
five
minutes
later,
they
gave
me
an
answer
and
I
was
like.
Oh
that
answered
has
pushed
out
the
question
and
I
no
longer
remember
what
I
asked,
because.
F
The
ants
replaced
it
that's
great,
okay,
not
for
me.
A
So
anyways,
if
we're
done
with
that,
the
last
item
is
reviewing
previous
meeting
action
items.
So
the
first
one
is
complete:
transfer
vip
bot
to
github
actions.
That's
still
ongoing.
26.2
is
brent
to
open
a
pr
to
the
eips
repo,
that's
still
ongoing.
We
just
talked
about
that
editor
blog
to
be
reviewed
and
published.
That
happened
and
then
follow
up
with
oasis
for
the
json
rpc.
What
was
the
oasis?
A
I
know
I
know
about
the
oasis
json
rpc
stuff,
but
who
was
doing
that
was
that
james
or
james
okay,
so
we'll
have
to
get
in
touch
with
him
about
that.
Otherwise,
I
think
that's
all
the
meeting
items
is
there
anything
else.