►
From YouTube: EIPIP Meeting 74
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/210
A
Welcome
to
apip
meeting
74
I
have
just
shared
agenda
and
chat.
We
have
a
few
open
issues
and
pull
requests
as
usual
to
be
discussed
on
this
call
as
well
as
we
have
another
important
topic
which
is
EIP
and
ERC
repo
separation.
There
is
a
proposal
that
we
will
look
into
and
we'll
cover
some
of
the
discussion
continued
from
earlier
meetings.
So,
let's
get
going.
A
B
Is
pandas
actually.
C
C
In
fact,
I'm
still
not
entirely
sure
where
some
of
the
stuff
that
needs
to
be
fixed,
even
is
I,
have
tried
multiple
times
to
fix,
particularly
the
bug.
That
means
that
PR's
that
delete
files
can't
be
merged
multiple
times,
unsuccessfully
so
I
really
don't
even
know
how
to
fix
that
one
I'll
and
I
also
so
what
I
did
was
I
made
a
complete
rewrite
of
the
EIP
bot
I
think.
The
only
reason
that
it's
not
merged
is
concerns
over.
C
If
there's
some
oversight
we
made
that
allows
PRS
to
be
merged
when
they
shouldn't
be
so
basically
concerns
about
me
like
I,
have
fully
tested
it
tested
every
part
of
it
manually
and
have
automated
tests
too,
but
there
is
still
a
chance
that
something
slipped
through
and
I
think
that's
what's
blocking
it
at
some
point,
it
would
probably
be
useful
to
merge
it.
Maybe
try
it
for
a
take
a
snapshot
of
the
repository
and
roll
and
and
force
push
it
backwards
if
need
be,
but
I
really
don't
think
that
there
is
any
bug.
C
D
A
All
right,
so,
let's
go
ahead
and
merge
that
if
any
of
the
editors
May
merge
it
during
the
call,
it
would
be
nice
or
we
can
do
it
after
the
call
as
well.
Moving
on
to
the
next
one,
which
is
an
issue
I,
think
it's
a
new
contract,
interface
and
EIP
should
require
to
include
a
privacy
consideration
section.
B
On
this
I,
don't
think
we
need
another
section,
for
it.
I'm
feel
pretty
strongly
that
if
there
are
privacy
considerations
for
an
EIP,
they
should
go
in
the
security
consideration
section.
C
B
C
E
C
I
think
I
think
we,
the
privacy
considerations
at
the
very
least,
should
be
mandatory
for
choreographies.
Even
if
there
are
oh.
E
A
C
I
think
it's
primarily
for
like,
as
you
said,
transparency
purpose.
It's
like
if
something's
gonna,
like
somehow
leap
some
information
just
by
the
nature
of
whatever
algorithm
it
uses
that
should
probably
be
taught
the
end
user.
It
also
makes.
But
as
someone
who
has
done
application
development
being
able
to
know
what
what
affects
the
tools
you
depend
on
create
allows
for
things
like
gdpr
compliance
to
be
a
little
bit
easier.
C
So
that
would
be
my
rationale
for
why
it
would
be
a
good
idea,
two
at
the
very
least,
rename
the
security
considerations
to
considerations.
C
B
C
In
fact,
there
might
even
like,
for
example,
the
my
EIP
that's
the
ethereum
notary
interface
interface,
that
I'd
like
to
put
a
legal
consideration
in
there
if
possible,
but
like
that's
just
like
not
and
there's
no
good
place
to
put
that
sorry,
trains.
F
How
about
we
add
a
new
other
considerations
and
as
optional,
so
that
if
someone
want
to
bring
in
privacy,
they
can
bring
in
there
and
if
they
go
or
any
other
things
comes
up,
they
can
put
it
there
and
we
can
still
keep
a
security
considering
separate
and
mandatory.
C
I
was
thinking
just
subsections
of
the
consideration
section,
so
you
have
to
top
the
second
level
considerations,
third
level,
privacy,
third
level,
security,
third
level.
On
other.
B
Well,
I,
don't
think
we're
gonna
get
very
far
talking
about
this
on
the
call.
Maybe
we
can
make
a
thread
on
or
actually
discuss
this
in
the
issue.
A
D
I'm
also,
generally
against
I,
do
like
the
idea
of
people
being
more
cognizant
about
how
their
ERC
and
I'm
saying
ERC,
because
I
think
that
there's
not
many
cases
or
eips
coming
to
play
with
respect
to
privacy.
But
I
do
think.
There
are
a
lot
of
ERC
protocols
that
should
consider
follow
their
application.
Deals
with
user.
C
C
A
Okay,
it
definitely
looks
like
we
have
divided
opinion
here
on
the
call
that
the
present
participants,
so
maybe
we
can
have
more
discussion
going
on
in
the
issue
section
and
if
we
get
more
feedbacks
there
probably
will
bring
it
up
to
the
next
meeting.
Does
that
sound
reasonable.
A
Awesome,
so
we
know
that
we
have
another.
We
have
another
topic
for
discussion
today
and
that
is
a
proposal,
a
proposal
to
separate
eips
and
ERC
repo.
The
proposal
is
proposed
by
Tim
Baker.
We
have
him
on
the
console
team
if
you
would
like
to
maybe
provide
a
brief
overview,
so
we
can
start
discussing
on
the
topic.
G
Yeah
sure
I,
thank
you
for
having
me
also
thank
you
forever,
like
all
of
you,
I
think
almost
everyone
on
this
call
sort
of
replied
on
this
thread
so
appreciate
the
engagement
there,
I
guess
it's
probably
worth
starting
from,
like
you
know
where
this
came
from,
and
then
we
can
get
to
the
specifics,
but
high
level.
The
thing
I
I,
like
the
number
one
thing
I've
been
like
focused
on
and
sort
of
care
about,
is
figuring
out.
G
How
do
we
get
to
a
point
where
there's
a
single
sort
of
pretty
straightforward
process
to
propose
consensus,
changes
to
ethereum
and
by
consensus?
I
mean
like
not
just
consensus
layer
but
just
like
the
changes
to
the
consensus
rules
of
the
protocol
and
today
I
mean
I
think
pretty
much.
Everyone
here
knows,
which
is
for
clarity
like
on
the
execution
layer
side.
We
use
this
weird
thing
where
we
have
a
yellow
paper.
That's
now
out
of
date,
we
have
eips
that
act
as
like
layers.
G
We
apply
on
top
of
the
yellow
paper,
and
this
is
you
know
more
or
less
what
we,
which
we
call
our
spec
and
or
at
least
historically,
that
was
the
case
and
then
on
the
CL
side.
They
have
a
python
spec
where
they
just
make
prs2,
and
that
is
basically
the
the
actual
spec
of
the
network.
G
You
spent
a
bunch
of
time
over
the
past
year,
getting
an
El
spec
up
to
mainnet,
which
is
which
is
great,
so
I
think
this
gives
us
like
a
much
better
sort
of
technical
base
on
which
to
like
specify
changes
to
ethereum,
especially
in
the
post-martial
context,
and
so
we've
I
think
we've
done
like
really
good
work
rectifying
that's
part
of
the
process,
but
the
bit
that's
still
quite
separate
is
that
we
basically
use
eips
to
specify
changes
on
on
the
execution
layer.
G
They
don't
do
that
on
the
consensus
layer
and
it
would
be
nice
that
this
would
be
the
same
thing
and
a
few
reasons
why
this
would
be
nice
is
like
one
you
can
think
of
like
the
changes
on
the
consensus
layer
now
matter
like
much
more
given
that
like
we've
merged,
you
know,
the
beacon
chain
is
live
and
it's
all
one
system,
and
you
know
you
can
take
one
very
like
straw,
man
example,
you
could
say:
look
the
consensus
layer
can
literally
just
double
issuance
on
the
network.
G
Do
this
through,
like
some
random
PR
to
the
specs
and
there's
not
really
a
great
place
where,
like
it
gets
it,
it
gets
like
documented
in
a
way.
That's
as
easy
for
people
to
understand
as
like
eip1234
is
the
place
where
the
changes
proposed,
the
other
the
other
bit.
That's
quite
hard
is
when
you
have
changes
that
affect
both
layers.
So
we
have
two
examples
of
this
right
now,
like
withdrawals
and
and
4844,
and
both
are
like
pretty
awkward.
G
So,
like
withdrawals
has
like
a
hack
MD
that
acts
as
a
sort
of
meta
spec
and
then
that
basically
points
to
the
CL
repo
and
the
El
repo
for
the
cleip
and
the
the
CL
specs.
Sorry
in
the
ELA
P
to
like
describe
the
changes.
4844
is
this
weird
sort
of
EIP
where
the
El
changes
are
described
in
the
Eep
and
then
the
sort
of
references
without
linking
the
CL
specs
for
the
rest,
so
I
I
think
you
know
the
the
ideal.
G
G
The
biggest
challenge
is:
how
do
we
get
people
on
the
consensus
layer
side
to
want
to
interact
with
the
EIP
process,
to
like
specify
their
changes
and
and
kind
of
add
this
extra
degree
of
like
formality
to
their
process,
which
they
don't
currently
have
I?
Think
they're?
You
know
I
spent
a
bunch
of
time
talking
to
them.
They
fear
that,
like
the
EIP
process
is
pretty
rigid
and
bureaucratic
and
and
that
the
the
sort
of
friction
created
from
it
won't
be
worth
it.
G
You
know
and
and
just
sort
of
slows
them
down,
and
they
would
also
like
the
feel
like
they
can
like
they
don't
they
aren't
only
the
ones
that
have
to
comply
to
the
EIP
process,
but
maybe
you
know
the
EIP
process
and
can
can
kind
of
adapt
to
how
they
do
things,
because
you
know
they
might
do
things
better
than
than
we
do
as
well,
and-
and
so
you
know,
this
is
kind
of
a
long
intro.
G
That
is
like
very
I,
don't
know
like
enticing
for
people
on
the
consensus
layer
to
start
contributing
to,
and
ideally
that
has
like
lower
friction
than
the
full
EIP
processes
that
exist
today
and
then
you
know
the
sort
of
second
order
effect
from
there
is
I
think
based
on
that
you
can
imagine
core
EIP
starting
to
like
evolve
in
a
way,
that's
different
than
the
rest
of
the
EIP
process
and
I
think
this
is
kind
of
where
the
idea
of
like
splitting
erc's
and
eips
came
out
of
where
you
know
this
would
be
a
a
way
to
kind
of
signal.
G
Like
look,
this
process
was
well
diverged.
This
is
like
the
first
step
in
that
Divergence
and-
and
you
know
we
can
kind
of
then
both
take
them.
Take
them
forward
in
different
directions.
G
I
appreciate
all
the
arguments
that
you
know
like
there's
a
some
high
technical
overhead
to
do
that
so
I
I
I,
don't
want
to,
like
you
know,
incur
all
this
work
just
for
the
sake
of
it
like
I,
think
it
it's
it's
sort
of
considering
the
the
like
those
drawbacks
as
well,
but
I
think
you
know
the
sort
of
meta
proposal
I
have
here
is
like
how
do
we
include
CL
people
and
give
them
away?
G
That's
like
much
more
flexible
where,
like
they
can
start
to
iterate
on
the
process,
even
if
it
doesn't
meet,
you
know,
whatever
bar
the
current
EIP
process
has
I
think
it's
it's
like
we're
in
a
much
better
spot.
G
If
we
have
like
quote-unquote
bad
CL
eips
that
like
don't
fit
our
templates,
don't
you
know
work
quite
well,
then,
if
we
have
the
current
status
quo,
which
is
nothing
and
like
them
being
sort
of
scared
to
the
the
to
engage
so
yeah
I'll
pause
here,
but
that's
high
level
sort
of
why
I
wanted
to
bring
this
up
and
and
kind
of
the
rationale
behind
it.
Yeah.
C
C
Secondly,
I
think
that
there's
no
reason
why
we
can't
have
a,
for
example,
my
proposal
to
just
automatically
merge
all
the
drafts
that
would
make
it
very
easy
to
get
started.
I,
don't
I,
don't
and
we
could
even
possibly
disable
make
the
validator
do
warnings
for
draft
eips
instead
of
full
blocks.
B
Select
Echo
puja's
argument
against
Auto
Merchant
draft
PRS
is
that
a
lot
of
eips
get
abandoned
in
draft,
so
the
only
time
editors
interact
with
them
is
in
the
first
PR
into
the
port
into
the
repository,
so
I
think.
That's
probably
the
strongest
argument
against
just
automatically
merging
drafts.
I.
B
C
D
A
Like
make
sure
that
we
are
adding
only
good
proposals,
even
in
the
draft
status,
there
is
nothing
wrong
in
staying
as
long
as
they
are
not
ready
to
be
merged.
As
draft
considering
that
we
have
now
so
many
channels
open,
we
do
arrange
this
by
weekly
meeting
for
EIP
editing
officer.
Authors
are
welcome
to
come
and
talk
to
us
to
move
the
proposal
to
make
them
better
and
then
add
it
as
a
draft.
If
we
start
Auto
merging.
E
F
I,
if
I
may
chime
mean
I
think
a
team
comes
in
and
raise
the
problem,
that's
because
of
EIP
editing
has
of
too
many
frictions.
F
They
want
to
kind
of
propose
a
fork
and
I
can
resonate
a
lot
with
that
I'm,
actually,
a
big
fan
of
reducing
the
frictions
and
respect
adopters,
including
allowing
much
more
linking
to
useful
sources.
What
I
feel
that
we
were
going
into
debate
is
about
like
whether,
like
a
micro
area,
whether
we
want
to
accept
drug
merging
or
not
that's
a
more
practical,
but
in
a
high
level
do
we
want
to
have
a
fourth
version.
F
I
personally
feel
that
I'm
totally
in
support
of
having
a
core
EIP
and
maybe
Network
EIP
and
even
interface
EIP,
have
different
rules
and
different
layouts
and
different
merging
frictions
by
different
people.
What
I
feel
reserved
is
to
have
different
repository
and
different
domain
names
to
serve
them,
which
has
both
technical
problem
as
well
as
it
creates
confusion
for
people
to
understand
where
to
go
to
to
look
at
ethereum
proposals.
F
So
what
I
propose
to
game
and
a
group
is
that?
Can
we
allowed
a
group
of
core
contributors
to
quickly
become
EIP
editors
and
for
them
to
make
decisions
about
their
emerging
rule,
their
editing
rules?
In
that
way,
we
can
keep
distance
in
one
single
repository
yeah.
That
would
be
my
proposal
in
this
I.
C
Agree
with
that,
we
could.
We
could
just
Fast
Track,
quite
a
few
core
core
developers
into
being
core
EI
eipe
editors
and
actually
with
the
new
with
the
new
IP
review
box.
It
wouldn't
be
that
hard
to
to
make
it
like
a
core.
Only
like
no
website
changes
like
a
slimmed
down.
Editor
thing
that
only
works
for
for
eops
and
doesn't
give
General
editor
stuff.
B
C
People
to
want
to
work
with
I
can
answer
that.
It's
that
we
spend
the
it
to
a
lot
of
people.
It
appears
that
we
spend
a
lot
of
time
on
knitting
picking
stuff
and
I
can
actually
I
actually
somewhat
agree
with
that
Center.
But
it's
just
that.
The
reason
why
we
spend
so
much
time
on
nitpiggy
stuff
is
that
we
want
our
eips
to
look
good
right.
C
That
goes
back
to
the
kind
of
the
like
the
like
reputation
like
things,
but
I
think
that
we
are
actually
a
little
bit
too
nippy
with
too
nitpicky
and
some
in
some
cases,
particularly
with
drafty
IPS,
that
aren't
even
going
to
see
the
light
of
day
a
lot
of
the
time,
but
yeah
I
think
it's
nice
and
maybe
I'm
children
yeah.
That
needs
to
be
reduced.
G
So
I
think,
like
I,
followed
the
process
more
closely
than
like
the
average
consensus
layer,
Dev
and
I
do
think
it
has
improved
like
quite
a
lot
over
like
the
past
I,
don't
know
six
ish,
maybe
12
months.
I
do
think
like
that.
Those
like
incremental
improvements,
sort
of
are
perceived
against,
like
four
years
of
basically
stagnation
from
the
CL
teams
and
and
and
I
think.
This
is
a
lot
like
you
know,
there's
a
bunch
of
like
small
tweaks
that
that
cause
friction
like
I
mean
and
whether
this
is
like
the
syntax
rules.
G
Whether
this
is
yeah,
this
I
don't
know
the
the
templates
or
stuff
like
that.
G
I
mean
you
know,
I
think
it
like
the,
for
example,
the
the
SSD
EIP
right
now
you
could
imagine
a
world
where,
like
you,
just
merged
the
first
draft
of
that
and
then
still
kind
of
have
the
discussion
about,
like
you
know,
the
improvements
after
it,
but
I
I
do
think
like
talking
with
cl
folks
is
like
they
just
viewed
this
as
like
something
that,
if
they
sign
up
for
will
like
slow
them
down
immensely
and
they
might
not
be
able
to
control
and
they
sort
of
add
this
dependency
in
their
process
that,
like
they
I,
don't
know
they're
sort
of
fearful
of
to
some
extent
and
and
something
that
like
signals
to
them.
G
That,
like
you,
know,
they'll,
be
able
to
like
use
this
process
in
a
way.
That's
like
useful
for
them.
Even
if
it's
not
like
completely
following
sort
of
current
rules,
I
I
think
that's
the
thing
they
would
like
to
see
and
whether
this
is
you
know,
spilling
it
out
in
a
separate
process
in
repo
I.
Think
that
that
sense,
that
signal
I
think
the
other
option
of
like
yeah,
adding
some
like
you
know,
potentially
even
just
CL,
EIP
editors
or
something
that
that
can
merge
stuff.
G
You
know
like,
even
if
it's
not
if
it's
not
perfect,
that
might
be
good
enough
to
get
them
to
use
it
and
and
I
think.
If
we
went
down
that
route,
you
know,
for
example
like
it
would
be
worth
looking
then
at
like
okay,
I,
don't
know
over
the
past
two
months
like
we,
we
sort
of
force
merged
these
four
eips.
G
What's
like
what,
where
the
friction
comes
from,
but
I
I
do
think,
like
you
know,
there
there's
definitely
like
a
quote-unquote,
irrational
fear
from
the
CL
side
to
participate
in
this.
That's
based
on
just
like
the
accumulated
perception
over
a
long
time,
rather
than
like,
having
spent
a
ton
of
a
ton
of
time
to
sort
of
yeah
actually
engaging
in
the
process
and
I
guess
most
people,
it's
just
you
know.
Most
people
don't
have
a
ton
of
time
to
engage
in
the
EIP
process.
D
I
think
Beyond,
just
this
like
question
about
being
fearful
of
the
process.
There's
also
this
problem
that
the
process
for
getting
you
know
core
eips
over
the
line
and
the
process
for
doing
ercs
are
different
and
we're
spending
a
lot
of
time
trying
to
come
up
with
the
rules
that
work
for
both
of
these
systems-
and
we
are,
you
know,
just
coming
up
with
something
that's
sort
of
modeled
in
the
middle
and
I.
Think
that
to
me
is
the
biggest
argument
why
it
needs
to
be
just
separate,
because.
D
I
think
Corey
IPS
there's
this
very
specific
small
group
of
people
that,
like
are
actively
working
all
the
time
to
try
and
make
these
things
happen,
and
we
have
very
like
specific
ideas
about
you
know
trying
to
come
up
with
certain
test
cases.
You
know
writing
security
considerations
about
all
these
things
and
for
erc's
it's
like
a
completely
wide
open
world.
Like
anything
is
possible.
We
have
people
who
are
writing
completely
new
protocols.
We
have
people
who
are
writing
additions
to
protocols
like
we
should.
They
should
be
thinking
a
lot
more
about.
D
How
can
they
make
the
process
more
amenable
to
the
types
of
things
that
they're
doing?
You
know
we
don't
really
have
as
much
of
this
extension
of
EIP
is
usually
in
core
EIP.
So
that's
like
a
super
common
thing
for
ERC
all
the
time
they
want
to
add
new
things
to
the
nft
standard
as
it's
something
that
they
just
keep,
adding
more
and
more
erc's,
rather
than
coming
with
a
more
principal
top-down
approach
about.
How
can
we
just
like
continue
moving
the
NFP
standard
forward?
D
Then
they'll
end
up
with
a
much
better
process
that
speaks
of
their
names
will
end
up
with
a
much
better
process
of
some
sardines,
because
we'll
be
able
to
bring
people
in
who
are
involved
with
the
core
process.
Who
don't
have
to
ever
look
at
anything
because
they
aren't,
we
are
successions
about.
You
know
we
want
to
make
this
change.
Oh,
this
change
doesn't
work
as
well
for
ERC,
etc,
etc.
G
Great
and
I
think
that
the
question
is
like
I
think
there's
two
there's
two
levels
to
that.
One
is
like
the
technical
coupling
of
the
repos
and
two
is
like
the
quote-unquote
management
of
it.
So
you
can
imagine
in
a
world
where,
like
you
know,
we
keep
it
all
in
one
repo
to
like
lower
technical
overhead,
but
then
we,
the
the
process,
sort
of
evolved
independently
or
whatnot
and
and
I
think
there
it's
like
yeah.
Maybe
you
need
like
you
just
need
time
and
over
time
you
see
yeah
over
time.
G
You
see
them
the
Virgin.
Maybe
that
leads
to
a
split
I
do
think
like.
Even
if
you
read
the
ip1
today,
there
are
like
all
these
awkward
things
around,
like
you
know,
Corey,
IPS
and
I.
Think
there's
also
this
weird
question
with
Corey
IPS,
that's
different
is
like
how
do
they
fit
with
the
network
upgrade
process
and
that's
always
been
like
a
very
sort
of
awkward
thing
and
and
potentially
having
a
separate
process
there
I
potentially
having
a
separate
process.
C
One
another
there's
a
lot
of
arguments
for
having.
F
Also
10
ID,
proposed
by
55,
was
being
referenced
in
I,
believe
erc's
112
a712,
which
is
both
I
personally,
perceive
as
both
interface
and
ercs.
These.
F
I
think
I
think
William
entrigan
provide
a
good
argument
about
a
nor
forking,
mainly
because
of
the
technical,
the
the
the
wholeness
of
the
technical
side,
a
stack
people
can
go
to
and
then
see
everything
together.
It
is
definitely
nothing
preventing
them.
You
can
even
break
down
core
uip
into
two
different
repository
for
execution
and
and
and
consensus
right,
but
like.
F
F
So
why
do
you
the
reason
the
rational
arguing
for
unifying
them
is
can
be
also
leveraged
to
you
to
to
argue
for
unifying
many
of
the
other
stacks
like.
D
Okay,
the
people
who
are
working
and
the
people
who
are
working
on
these
core
things.
This
is
one
specific
group
that
they're
working
on
the
El
they
care
about
what
the
CL
is
doing.
If
you
want
a
CEO
care,
what
the
El
is
doing.
This
is
like
a
a
known
group
of
people
or
is
the
application
inside
like
this
is
also
a
number
of
people,
but
if
they're
completely
disjoint,
there's
no
there's
almost
no
overlap,
people
who
are
building
application
stuff.
D
C
G
There
is
because,
like
for
example,
like
the
most
obvious
feature,
is
that
a
consensus
change
requires
the
entire
network
to
adopt
it
or
the
network
is
gonna,
afford
right
and
it's
like
and,
and
you
know,
and
it
it
has
to
be
bug
free.
Otherwise,
the
networks
you
know
well
I
can
try
to
bug
like
I,
think
the
sort
of
bar
in
terms
of
like
consensus,
building
that
we
require
for
Corey
IPS
is
you
know
much
much
higher
than
an
ERC
which
is
like
an
opt-in
feature
and
then
and
then
I
agree,
I
think
Sam.
G
You
were
the
first
to
make
this
point
on
magicians.
Then
this
is
like
sort
of
a
spectrum
right.
Imagine
core
eips
are
on
one
side
of
it.
Ercs
are
on
the
other
side,
something
like
an
interface.
Eip
is
kind
of
weird,
because
you
know
maybe
like
sure
not
all
the
clients
need
to
add
868,
but
then,
if
they
don't
gossip,
these
transactions,
the
right
way
it
kind
of
messes
up
with
the
you
know,
with
the
network.
G
Right,
there's
like
a
standard
for
like
a
new
NFC
royalty
thing
which
you
know
is
opt-in
has,
like
you
know,
there's
no
sort
of
if,
if
I
never
know
that
it
exists,
I
can
use
ethereum
and,
like
my
experience,
has
not
changed,
but
then
there's
something
like
oh
we're,
gonna
double
the
issuance
and
then
it's
like
wow
everybody
who,
like
has
a
say
in
like
ethereum,
should
probably
be
aware
of
this
thing,
and
this
is
where,
like
I,
think
Corey
IPS
are
different.
We're
like
even
when
we
add
an
opcode.
G
It's
like
we're
asking
all
the
nodes
to
like
update
at
the
same
time
and
and
it's
really
valuable
that,
like
this
information
is
like
clear-
and
this
is
I
guess
not
to
Matt's
point-
it's
like
the
fact
that
we
don't
have
this
for
the
CL
today.
I
I
see
this
as
like
a
really
terrible
sort
of
failure
of
the
process,
because
you
know
you
go
to
the
CL
specs.
G
G
You
don't
have
something
like
a
security
consideration
sections
you
don't
have
something
like
a
rational
and
and
and
I
think
it's
just
like
the
process
is
much
less
like
legible
than
the
EIP
process
and
like
yeah
rectifying.
That
is
like
basically,
the
number
one
thing
I
care
about
like
if
we
can
get
to
a
spot
where,
when
we
have
changes
happen
on
the
consensus
layer,
there's
like
a
handful
of
VIPs,
we
can
point
to
that
say:
Hey,
you
know,
we've
changed
validated
rewards
we've
like
updated.
G
The
fourth
choice
rule
you
know
whatever
else
like
added
withdrawals
like
that's
extremely
valuable,
because
then
the
community
can
review
those
changes,
understand
them,
which
is,
is
much
harder
to
do
today.
Yeah.
A
I
think
we
are
talking
about
maybe
two
different
processes
here.
So
when
we
are
talking
about
separating
repo
am
I
understanding
is
that
we
are
trying
to
follow
the
same
process
that
was
followed.
That
was
being
followed
so
far,
and
it's
just
that
we
are
having
two
different
folks
for
erc's
and
eids.
They
both
followed
separately,
but
when
we
are
trying
to
follow
the
process
which
is
already
being
followed
by
the
fields,
perhaps
that
is
going
to
be
a
different
process
than
than
the
one
currently
being
followed
at
EAP.
A
So
if
we
happen
to
follow
what
CL
is.
F
A
D
G
So
it's
almost
like.
We
don't
see
them,
but
yeah,
yeah
and
I
I
think
that's
that's
bad
yeah.
C
How
about
this
compromise
we
introduced
a
new
type
of
VIP,
basically
a
track
EIP
and
it's
basically
a
redundant
it's
a
different
EIP
one.
It
describes
an
entirely
different
process,
but
everything's
still
on
the
same
repo,
so
it
can
all
enter
so
so
track
you,
so
eips
of
different
tracks
can
still
interact
with
one
another
while
still
having
several
processes.
G
I,
don't
even
think
we
need
a
new
VIP
one.
This
is
sort
of
what
I
liked
with
forking.
The
repos
is,
like
you
know,
most
of
the
stuff
actually
stays
the
same
right
like
so
I.
Don't
think
you
need
a
separate
EIP
one
I
think
I,
don't
know
where
the
EIP
rules
are
written.
Are
they
eip1s
or
on
like
the
whole
page
of
the
website?
G
Know
the
other
way
I
would
frame.
This
is
like
I
would
rather
lower
the
friction
and
then
rebuild
the
process
than
to
try
and
like
proactively,
come
up
with
the
right
process,
because
I
think
that's
sort
of
the
thing
that
it's
like.
If
we
add
a
bunch
of
new
process
rules
to
make
this
work,
then
we
don't
know
that
they're
right
and
this
is
sort
of
the
the
other
problem
it's
like.
If
we
can,
just
you
know,
try
out
a
bunch
of
Cl
eips
see
how
they
differ
and
then
sort
of
go
from
there.
G
D
D
E
G
I
think
this
is
yeah.
This
is
kind
of
back
to
what
I
was
saying
earlier
is
like
to
me.
If
we
had,
you
know
someone
who
can
like
force,
merge,
client
cleips,
you
know
these
people
are
not
stupid
either
right
like
they
do
care
about
their
work.
They
do
generally
like
do
high
quality
stuff.
So
it's
like
you,
you
start
by
force
merging
their
stuff
in,
even
though
it
breaks
the
rules.
Then
you
sort
of
retroactively.
Look
at
like
okay.
What's
like
what
rules
did
it
break?
How
did
this
thing
differ?
G
You
know,
and
you
can
even
imagine
a
world
where,
like
aside
from
asking
for
a
title
with
like
a
number,
that's
you
know
they
don't
need
anything
else
right
like
maybe
they
don't
even
use
the
same
sections.
Maybe
they
don't
use
that
and
then
it's
like.
Maybe
you
like
over
time
sure
you
build
this
separate
eip1
that
documents
this
but
I,
think
your
odds
of
like
success
are
much
better.
G
If
you
start
from
allowing
them
to
use
it
as
they
would
want
to
use
it
and
from
there
you
know
potentially
enshrining
some
things
or
maybe
you
know
after
six
months,
you
tell
them
look,
you
know
you
guys
never
put
in
a
security
consideration
sections,
that's
really
bad.
We're
gonna
force
you
to
start
doing
it,
but
at
that
point,
they're
already
sort
of
like
engaged
enough
that
they
can
maybe
understand,
like
the
the
value
of
of
this
yeah.
Well,.
B
B
Oh
no,
it's
got
to
be.
It's
got
to
be
one
of
them
directly.
It's
got
to
be
a
CL
developer
because
they
need
to
learn
the
process
and
that's
it.
B
So
if
they
had
a
development
like
if
they
had
a
core
EIP
editor,
they
can
go
as
fast
as
they
want.
They
won't
be
blocked
on
anything
because
they
can
just
approve
their
own
eips
and
they
can
force
merge
if
they
want
people
to
improve
their
own
Yankees
sure
but
I'm
talking
about
like
as
a
group
like
okay,
anybody
inside
as
long
as
that
that
death
doesn't
write.
B
Okay,
sure
so
how
we
could
add
two
like
it
doesn't
matter
right
like
yeah
and
they'll
only
get
notifications
about
Corey
APS,
maybe
a
few
random
ones.
But
it's
really
not
that
bad
as
long
as
you're,
not
on
the
ERC
track,
and
that
way
they
control
exactly
how
much
friction
there
is.
D
E
D
A
B
A
D
A
Example
of
a
consensus
layer,
a
proposal
which,
which
was
considered
to
be
standing
in
the
process
for
way
too
long,
that
it
was
for
proposal
for
it
44
to
be
moved
to
the
review
status.
So
Sam
had
this
discussion
in
the
call
we
had
yesterday
the
EAP
editing
office.
However,
there
was
dependency
on
one
proposal
to
another,
so
they
wanted
to
have
like
each
68
to
be
a
part
of
a
required
section.
A
If
they
allow
people
to
just
keep
on
Force
merging
and
do
not
follow
any
process,
then
it
may
end
up
creating
chaos.
So
the
simple
thing
was
there
to
have
each
68
and
review
and
to
get
each
68
interview
we
needed
to
have
e67
in
review,
so
I
talked
to
Marius,
yeah
I
think
created
a
pull
request
and
it
was
solved
so
I
think
it
is
a
simple
process.
A
Yeah
roses,
and
we
have
people
like
many
years-
did
not
have
to
come
and
make
the
pull
requests.
I
did
it
for
him.
So
when
we
know
what
is
the
problem,
we
are
here
to
help
them
out.
Sam
explicitly
mentioned
in
the
comment
that
what
we
need
is
to
move
this
into
review
and
Proto
made
a
PR
to
make
it
into
a
review
process.
So
it's
not
that
it
is
dependent
on
anybody.
A
It's
just
that
awareness
that
is
lacking
in
the
CL
team
and
it's
the
comfort
that
we
have
to
provide
them
that
if
you
are
following
the
right
thing
and
if
you
even
if
you
don't
know
what
is
the
right
thing,
we
are
here
to
help
you
out.
So
let
us
know
what
challenges
you
are
facing
and
we
are
here
to
help
you
out,
move
it
smoothly.
Congratulations.
E
F
G
Don't
think
it's
the
right
thing,
they'll
be
like
it's
just
stupid.
Why
should
I
like?
Why
is
this
rule
there,
like
I,
just
want
my
spec
and
I
sympathize
with,
like
you
know
the
reason
why
the
process
is
there
but
I
think
if
you
start
by
like
forcing
them
to
follow
and
like
sort
of
Wade
through
this,
like
Labyrinth
of
like
exceptions
and
networking
VIPs
I
think
are
like
every
time
like
I,
don't
know
for
some
reason
they
sort
of
end
up
being
the
worst
ones,
but.
D
Like
I
mean
I,
think
part
of
it
is
that
the
guest
team
absolutely
hates
the
EIP
process
and
refuses
to
engage
with
it,
and
so,
as
the
people
who
are
making
the
network
eips,
they
make
the
draft
just
to
get
the
number
and
tell
the
people
to
implement
it
and
that
they
don't
ever
do
anything
else
with
it.
Yeah.
G
Like
okay,
we
add
a
couple:
we
add
a
couple
CL
folks
as
EIP
editors
for
core.
They
can
force
merge
stuff,
it's
important
that
they're
actually
CL
people
and
not
just
like
random
people,
because
this
acts
as
a
way
to
pull
them
into
the
process.
G
G
I
think
the
thing
is
like
yeah:
they
need
to
have
Force,
merge
access
for
Corey,
IPS
and
and
feel
that,
like
you
know,
they
can
sort
of
own
that
part
of
the
process
and
then
through
social
means
we
can
hopefully
align
them
with
the
rest
of
the
process,
but
technically
they
should
have
sort
of
free
reign
on
that
sort
of
small
section.
G
A
Yeah-
and
just
you
are
like
getting
access-
is
not
a
big
challenge
here.
We
just
want
to
make
sure
that
people
having
answers
are
really
responsible.
I
mean
I,
don't
mean
to
say
that
year
pay
data
are
not
responsible.
We
just
want
to
maintain
a
few
bullet
points
to
be
covered
over
there
and
getting
that
fish
should
not
be
a
problem,
and
we
are
happy
to
provide
all
the
support
to
just
go
through
the
basics
of
it
and
yeah.
It
would
be
great
to
have
more
people
in.
G
Yeah
and
I
think
one
thing
also
that,
like
we
can
in
terms
of
being
responsible,
maybe
one
soft
requirement
we
can
do
is
we
can
tell
them
look,
you
can
force
merge
stuff
but
like
try
and
keep
that
for
cl
things
right
so,
like
you
know,
because
I
don't
think
we
should
add
a
separation
in
core
eips
but,
like
I,
think
it's
fine
to
say
that,
like
you
know,
evm
changes
like
shouldn't
be
forced
merged
in
by
some
CL
Dev,
who
just
is
pissed
off
at
the
EIP
process
like
technically,
they
would
be
able
to
do
that,
but
to
tell
them
like
you
know,
please
refrain
from
that
and
use
this
as
a
way
to
help
CL
folks
on
board
I.
C
Speaking
of
editors,
can
we
make
zinyan
one.
B
Okay,
wait
before
we
jump
topics
here.
I
have
something
else
to
throw
in
just
a
heads
up
that
the
merge
to
eip1
that
makes
ercs
use
ERC
Dash
as
the
prefix
and
everything
else
use.
Eip
Dash
as
a
prefix
was
merged.
So
I'm
in
the
process
of
updating
epw
be
ready
for
a
lot
of
very
angry
people
being
very
confused.
A
A
C
A
C
Well,
I
I
think
the
the
purpose
of
dips
repository
is
literally
any
standard
relating
to
ethereum
I,
think
that
is
the
scope
of
it.
Quite
frankly,
I
don't
think
that
the
special
rules
for
query
IPS
make
sense
like
having
it
make
it
having
it
turn
the
final
only
when
it's
merged
into
the
quote-unquote
canonical
ethereum.
That
doesn't
make
sense
to
me
right,
because
the
standard
is
final.
Long
before
that
I
think
didn't.
D
C
D
I
mean
I
think
this
is.
This
is
and
I
I
think
that
this
is
just
like
not
understanding
the
process
very
well,
because
there's
no
way
that
we
can
make
something
final
before
it
reaches
a
test
net.
If
we
make
it
final
before
a
reason
to
test
that,
and
we
realize
that
there's
like
a
small
City
that
needs
to
be
changed
at
the
last
moment,
we
have
to
go,
create
a
whole
new
AIT
and,
let's
create
a
huge.
You
know,
cause
and
confusion
about
what
is
the
actual
thing
that's
going
in
and
so
like.
C
Yeah,
and
that
would
be
the
risk
of
moving
it
to
final
before
a
Tesla
is
made,
but
nonetheless
I
don't
think
it
needs
to
be
the
EIP.
Editors
is
responsibility
or
anything
related
to
the
EI
to
the
Erp
processes,
responsibility
to
care
about
what
has
or
has
not
been
implemented.
Where.
D
D
That
that's
that's
not
really.
What
I'm
asking
for
I'm
I'm
trying
to
say
that
I
think
that
the
process
for
ercs
and
eaps
are
different
and
that
they
should
be
completely
separate.
Yes,
the
original
scope
of
the
EIP
repository
was
to
Define
all
of
the
standards
related
to
ethereum,
but
that
one
in
2016
and
over
the
years
we
have
realized
that
that
things
that
are
happening
on
the
application
layer
are
very
different
to
think
they're
happy
as
a
core
layer
and
so
I'm
saying
that
the
scope
should
be
changed
at
this
point
in
time.
C
What
changes
would
you
propose
would
be
made?
What
what
divergences
would
you
like
to
see
in
the
processes.
D
I
think
the
process
that
we
have
right
now
is
reasonable
for
doing
core
protocol
changes,
but
it's
not
very
good
for
the
application
developers
and
how
do
I
know
it's
not
very
good
if
the
application
developers,
because
they
don't
even
follow
the
process,
unisoft
launched
this
big
permit
2
contract
a
few
months
ago,
and
they
just
didn't
go
through
the
entry
process.
No,
they
were
like.
Why
would
we
do
that
like
let's
just
ship
it,
and
this
is
like
the
risk
that
we're
having?
Because
people
don't
want
to
do
this
process.
C
If,
if,
if
everyone
is
complaining
about
the
same
thing,
both
both
elcl
and
application
devs,
then
that
suggests
that
there's
something
wrong
that
should
be
fixed
everywhere
and
not
by
forking.
D
D
C
D
Mean
look,
I,
hear
you.
They
should
be
more
involved
with
the
process.
I
I,
don't
disagree
like
I'm
frustrated,
a
lot
more
involved
with
the
process,
but
I
think
the
right
way
to
get
to
the
ball
with
the
process
is
to
sandbox
this
process
away
from
the
core
process,
and
let
them
be
the
captain
of
that
thing.
Let
them
have
ownership
and
responsibility
over
the
this
full
like
end-to-end
process,
if
we
add
them
and
involve
them.
C
F
I
think
what
what
team
has
proposed
in
two
steps?
The
first
step
is
inviting
the
CL
team
Court
to
become
editors
and
see
if
they
can
still
fit
in.
This
is
separation.
D
This
is
separate
than
the
CL
editors
yeah,
we're
separating
the
ercs
and
the
EAP
repository.
We
already
said
that
we'll
add
the
CL
people
with
editors
and
they'll
have
Force
merge,
abilities,
I'm,
saying
that
we
need
to
get
the
arcade
out
of
this
process
as
well,
and
let
the
app
developers
take
the
range
and
really
you
know
manifest
the
process
that
they
they
want
to
have.
D
C
D
F
A
Right-
and
we
are
almost
out
of
time
for
like
to
have
this
discussion
continued-
maybe
we
can
bring
it
back
in
the
next
meeting
for
two
days
from
what
we
got
as
a
conclusion
that
maybe
on
the
tomorrow's,
the
CL
side,
CL
meeting
will
try
to
look
talk
to
CL
and
Dev
and
see
if
they
are
interested
to
be
a
part
of
the
process,
and
maybe,
if
Matt,
if
you
would
like,
we
can
bring
it
back
again
to
hear
your
arguments
of
having
it
separated.
Though
I
feel
like
when.
D
Seconds
this
has
been
going
on
for
three
years
and
I
just
want
to
make
it
happen
and
I.
Don't
think
that
there
are
any
compelling
reasons
to
keep
these
things
together,
other
than
this
idea
of
unity
and
I'm,
saying
that
there
is
no
need
for
this
thing
of
unity,
because
they
are
actually
not
a
singular
like
a
design
space
anymore.
We
are
very
well
aware
that
these
are
two
totally
different
areas
of
development,
and
we
should
respect
that
by
giving
them
their
own
places
to
Define
their
processes.
A
Right
I
as
much
as
I
agreed,
but
I
think
that
you
know
this
thing
coming
from
more
from
the
ERC
authors
that
I
don't
want
to
be
a
part
of
eib
repository,
we
want
to
be
having
a
separate
repository
than
code
or
EIP
repository
would
make
more
sense
to
me,
but
so
far
I
think
we
have
not
received
any
negative
feedback
in
terms
of
complaints.
Like
ERC
authors,.
A
D
Don't
have
to
go
through
this
chart
process,
but
they
they
they
do
have
issues,
they
don't
use
the
process,
so
they
just
don't
use
it
and
then
they
go
on
with
their
lives
and
they
launch
their
projects
and
their
their.
You
know
standards
and
they
just
say
you
should
use
it
because
we're
a
unit
so
operator.
You
should
use
it
because
we're
open
to
these.
A
D
Make
well
I
mean
if
you
look
into
permit
too
I
have
permit.
Two
is
totally
something
that
should
be
a
standard
like
permit.
To
is
this
idea
that
you
have
this
Singleton
permit
contract
or
you
give
an
allowance
like
a
Max
allowance
to
and
then
unit
swap
is
able
to
across
all
of
their
different
token
pairs,
rather
than
given
the
allowance
of
that
token
per
contract
across
all
the
token
pair
contracts.
It
can
basically
do
some
sort
of
like
authorization
via
This
Global,
permit
contract.
B
C
D
D
To
be
I
think
they're,
absolutely.
Why
is
that
not
like?
Because
they
built
it?
Everybody
should
use
this
permit,
but
everybody
should
use
this
permit
contract
and
so
in
the
interest
of
doing
things
in
like
an
open
way
that
is
amenable
to
everybody's
needs.
It
would
have
been
a
lot
better.
Unisoft
was
like
Hey
open
C.
What
do
you
think
about
this?
Permit
2
contract?
Is
this
something
that
you're
going
to
be
able
to
use
too,
because
if
everybody
implements
their
own
permit
to
contract,
then
the
gain
is
not
that
large.
Oh.
C
Google
like
take
Google,
for
example,
Google
has
tons
of
Standards
with
with
the
ietf
like
they
do
have
a
vested
interest
in
interoperability.
D
B
D
F
A
I'm,
sorry
to
like
interrupt
here,
we
must
have
to
wrap
up
now.
We
are
like
beyond
the
time
we
can
definitely
bring
it
back
in
the
next
meeting.
I
just
want
to
make
one
small
point
before
we
point
up
like
what
we
are
doing
here
is
helping
people
to
build
a
standard.
We
cannot
force
people
to
come
and
build
a
standard
with
us,
so
it
is
totally
up
to
people
who
want
to
contribute
who
want
to
help
other
people
out
what.
A
That's
yeah,
but
what
we
can
do
is
just
by
making
the
process
easier,
so
we
can
rather
focus
on
what
are
the
challenges.
What
are
the
friction
that
people
are
feeling
here
and
try
to
resolve
that
I
I
think
this
would
be
a
good
point
to
maybe
wrap
up
and
have
if
people
would
like,
we
can
have
it
discussed
in
the
next
meeting.
Anyway,
we
have
to
see
the
result
that
is
coming
up
from
the
CL
team
or
more
eipa
editors
if
they
are
willing
to
join
any
final
comment
thoughts.
F
Yeah
I
just
want
to
quickly
check
if,
with
the
to
the
temperature
checker
for
adding
me
as
an
editor.
C
D
Ultimately,
I
think
that
we
need
to
be
bringing
people
into
the
process
who
are
involved
with
client
teams,
and
that's,
like
my
in
focus
I.
Think
if
you
wanted
to
come
on
an
ERC
editor,
then
that
would
be
great.
But
I
am
like
worried
about
adding
more
people
who
have
the
power
of
controlling
what
the
like
standardization
processes
for
core
eips,
who
aren't
involved
with
the
court
process
at
all.
A
We're
going
to
start
like.
D
D
Have
this
conversation
about
changing
the
process
and
I
am
saying
like
I,
don't
feel
super
comfortable,
but
I
need
more
people
who
have
the
ability
to
change
the
EIP
core
process
who
aren't
involved
with
these
client
teams,
and
so
what
like
you're
supposed
to
not
participate
when
we
start
talking
about
changing
the
core
process
like
this
is
a
very
confusing
way
and
we
haven't
had
an
editor
added
in
this
manner
before.
F
Yeah
I'm
in
favor
of
letting
CL
and
El
and
core
devs
to
make
the
whole
decision
about
the
the
core
EIP
editing
rules.
I
can
reframe
from
participating
at
all
yeah.
Well,
that's
totally:
okay
and
then
I
actually
don't
have
a
strong
opinion.
There.
D
D
No
I'm
talking
I'm
talking
about
any
types
of
meetings.
We
have
great
tooling
for
dealing
with
this
on
the
pr
level
I'm
talking
about
at
this
meeting
level.
When
we
start
talking
about
you
know,
we
want
to
have
this
change
like
what,
if
we
want
to
change
the
statuses
or
something
for
core
EIP,
you
got
a
new
status
like
about
to
go
in
hard
work
right
like
having
these
discussions.
F
Yeah
I
can
totally
refrain
from
commenting
on
the
core
EIP
process
as
an
as
an
ERC
editor
for
sure.
Yeah
I
totally
understand
that
you
need
more
context
on
that
side.
To
comment
on
that.
D
Your
concern
yeah
I,
mean
this-
is
this
resolved
my
concern
on
that
front?
I
still
think
that
this
is
like
a
a
muddied
situation
of
having
the
ERC
and
eits
together
to
me
doesn't
make
a
very
clear
reason
to
have
them
separate,
but
we're
not
going
to
resolve
that
for
a
while,
so
I'm
having
to
forward
with
this
agreement.
A
All
right,
I'm,
not
sure,
like
Sam,
has
already
dropped
off.
So
do
we
have
a
consensus
here
like
what
are
we
trying
to
conclude
out
of
this.
D
A
All
right,
thank
you
guys.
Thank
you
for
joining
us
today.
Hope
to
see
you
in
two
weeks
have
a
good
one.
Everyone.