►
From YouTube: EIPIP Meeting 83
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/241
A
A
We
have
a
bunch
of
pull
requests
and
issues
added
from
the
eaps
repository
to
be
discussed
today
and
probably
to
make
some
decisions
towards
the
merging
the
first
set
of
pull
requests
are
the
list
of
peers
proposed
by
Sam
Wilson
to
update
eip1
anyone
having
strong
feeling
to
merge
these,
and
not
probably,
we
can
discuss
one
by
one.
So
the
first
PR
here
is
6907.
It
is
to
update
eip1
to
allow
link
to
bips
any
thought
objection,
support.
B
So
I
think
the
only
person
with
an
objection
was
Gavin
and
I.
Don't
think
they're
here,
yeah.
A
All
right,
we
still
have
I
think
three,
four
more
EAP
editors,
so
anyone
from
the
editors
Community
other
than
Gavin
having
strong
opposition
to
that.
A
A
D
A
Very
well,
we
are
just
joined
by
light
client
math.
We
were
discussing
issue
number
sorry.
The
pull
request,
number
seven
triple
one,
so
it
is
about
at
w3c
as
a
permissible
origin
seems
like
most
of
the
editors
are
on
board,
just
checking
in
case.
You
have
any
thoughts
concern
with
this
one,
especially
with
respect
to
the
wordings,
as
is.
B
Some
discussion
on
the
w3c
one
so
we'll
have
to
I'll
go
over
it
again
to
make
sure
everything
is
good,
but
as
long
as
nobody
objects,
I
can
I
can
merge.
It.
B
Yeah,
we
could
probably
just
deal
with
these
all
as
one
big
group
so
like
bips,
anybody
object
to
linking
to
bitcoin
and
proven
proposals
Speak
now
or
hold
your
silence,
all
right,
w3c.
B
All
right,
ietf
rfcs,
are
we
allowed
to
link
to
those
anybody
object.
B
Cool
and
then
the
what
working
group,
any
objections.
B
Cool
the
yellow
paper.
I
know
you
object
Matt,
so
I
will
let
you
make
your
case
again.
D
B
E
Execution
specs
are
not
useful
for
that
purpose,
their
their
code.
You
can't
they're
not
useful
for
the
purpose
that
the
yellow
paper
is
you
can't
you
can't
express
Concepts.
You
can't
say
this
is
a
concept
that
I'm
using
that
you.
You
can't
just
include
blocks
of
python
code
to
explain
I'm.
Sorry,
we've
been
here
before.
E
D
G
G
A
In
the
last
meeting,
we
discussed
about
giving
permission
to
a
specific
commit
so
I'm
I'm,
assuming
that
it
is
being
proposed
with
the
allowing
link
to
yellow
paper
with
respect
to
having
specific
comment-
and
it
seems
like
we
just
need
to
get
Matt
on
board
and
everybody
else
seems
to
be
on
on
board
Matt.
Would
you
be
fine
with
comets.
I
E
Yeah
I'm
thinking
of
proposals
I've
written
and
how
the
hell
would
I
write
them
by
referring
to
by
making
I
guess.
I
would
have
to
understand
that
piece
of
code
and
the
reader
would
have
to
understand
the
piece
of
code
well
enough
to
even
understand
what
you
just
said.
I.
H
E
B
E
H
It's
the
same
way
that
we
do
the
consensus
layer.
It
works
fine
for
them,
I
think
that
it's
better
to
try
and
unify
the
approach
that
we
take
to
specifying
the
consensus
protocol,
both
consensus
and
execution,
and
because
the
yellow
paper
isn't
maintained,
I,
don't
think
that
we
should
be
making
room
for
it.
We
should
focus
on
unification
of
all
these
things.
E
Okay,
there
are
thousands
of
references
to
the
yellow
paper
and
just
go
to
Google,
Scholar
and
search
for
it,
thousands
of
references
and
the
the
execution
spec.
It
is
great
to
have
it,
but
it
doesn't
serve
the
purpose.
Programmers
can
read
it
mathematicians,
can't
necessarily
read
it.
Logicians
can't
necessarily
read
it.
We.
G
But
a
lot
of
people
read
reacts
so
even
though
they
might
not
go
into
I
did
they
might
read
it
and
then
use
it,
and
the
fact
that's
one
question
I
have
is
that
one
reason
we
we
put
so
much
restriction
which
I
object
on
linking
is
because
some
link
can
change
I'm
a
little
bit
curious.
Why?
At
this
moment,
we
are
rejecting
linking
to
yellow
paper
because
it
didn't
change
and
get
updated.
G
This
seems
like
conflicting
with
the
principle
why
we
restrict
linking
to
it
in
the
first
place
and
because
expect
execution
respect
again
in
the
future.
Stop
working
as
well
can
probably
like
if
it
happens
to
yellow
paper
that
it
stops
being
mentioned.
G
I
I
I
believe
this.
You
can
have
high
confidence,
just
like
yellow
people
can
stop
being
maintained
and
I
I
don't
see
the
reason
why
that's
a
a
paper.
G
G
G
A
group
of
people
think
it's
super
helpful
in
their
View
and
the
fact
that
we
stopped
linking
to
it
actually
reduces
the
the
chance
that
it
gets
no
to
noticed
and
support,
and
we
just
includes
excluding
mathematicians
and
other
people
from
even
joining
this
conversation.
C
E
There's
just
a
long
history
of
of
computer
languages,
other
systems
that
started
out
with
reference
implementations
and
then
wrote
actual
specifications
owasm
went
from
a
reference
implementation
to
a
real
specification.
Somebody
found
the
money
and
paid
some
experts
to
do
that,
and
they
did
it
and
reference
of
implementations
are
not
specifications.
They're,
not
they're,
not
readable
by
anybody,
but
programmers
in
the
language
in
which
they're
written
and
to
ask
people
to
Learn
Python
simply
in
order
to
to
participate
in
understanding
and
working
with
ethereum
is,
is
a
big
mistake
and
I.
E
Don't
think
we
should
contribute
to
it
and
I
just
don't
see
the
problem,
of
course,
in
the
link
as
as
part
of
the
editing,
it
is
a
question
of.
Does
this
link
to
the
yellow
paper?
Is
it
something
that's
likely
to
change
to
be
a
big
problem?
Yeah.
H
B
Well,
sorry,
I
just
have
to
this
agenda
because
I
added
all
the
other
ones
that
wanted
to
add
principal
sources,
I
kind
of
figured
we'd
just
be
like
we're
at
a
stalemate.
We
can't
decide
we'll
just
move
on
to
something
else
and
I'm.
Sorry
for
putting
on
the
agenda
again.
We.
B
Just
okay,
maybe.
B
A
A
Just
for
note
takers,
so
far
we
have
reached
consensus
for
the
first
four
pull
requests
that
could
be
merged
and
for
the
fifth
one,
if
we
get
the
time
today,
we
will
come
back
to
the
discussion
and
I'm
sorry
Mack.
If
we
do
not
get
time,
we
probably
would
like
to
discuss
it
further
or
whatever
is
decided
depending
upon.
If
there
is
any
request
to
get
a
discussed
in
the
future
meeting,
we
may
be
adding
all
right
moving
on
to
the
next
one.
A
The
next
one
is
is
not
for
any
proposal,
but
it's
a
for
about
a
CI
pump
seems
like
it
has
received
a
thumbs
up
from
Victor
and
waiting
for
review
by
Sam
and
Mac.
Anyone
has
thoughts
or
would
like
to
maybe
take
a
look
at
PR
number
6813,
CI
bump.
B
Yeah
I'll
take
a
look
through
it.
It's
if
it's
just
dependencies,
it'll
be
fine
to
do
offline.
A
Sounds
good
the
next
one
is
here
about
an
EIP
draft
which
is
now
closed,
and
it
is
requested
by
author
in
the
comment
to
the
agenda
that
he
thinks
that
this
proposal
could
be
reconsidered
and
this
PR
can
be
allowed
to
merge.
I
wonder
what
editors
think
about
it.
B
G
Well,
I
think
I'm
on
that
one
originally
I
think
it
was
trivial
that
it
doesn't
seem
like
a
EIP
would
be
VIPs.
It
seems
like
I'm,
slightly
convinced
and
made
neutral
now
with
the
author,
proposing
the
context
where
some
of
the
ZK
DVM
Solutions
trying
to
Market
them
as
evm
compatible,
but
in
in
in
some
of
the
behaviors
they
actually
did
not,
and
so
that's
the
background
of
the
Erp
and
with
that
I
I'm,
leaning
towards
neutral
because
I
it.
G
B
G
B
So,
like
I
said
when
we
first
brought
this
topic
up,
if
anybody
merges
an
EIP
defining
EV
like
evm
compliance,
I
will
make
a
different
EIP
with
different
evm
compliance,
and
there
will
be
no
clarity,
so
they're
like
like
as
a
thought
experiment.
That
shows
that
there's
no
reason
to
merge
this
EIP
because
it
doesn't
change
anything.
A
Because
if
it's
information,
probably
it
would
not
make
much
of
a
difference.
If
someone
wants
to
go
ahead
with
this,
because
it's
not
changing
the
protocol
or
it's
not
even
suggesting
to
follow
it.
G
Yeah
I
I
think
it's
it's
a
suggestion,
it's
more
or
less
than
a
subjective
and
then
I
I,
don't
know
if,
if
there's
a
reason
in
our
label
to
officially
reject
yourself,
I
would
love
to
hear
it
like
what
what's
our
official
reasons
down
where
it
says
hey
just
because
we
don't
think
it
matches
this
criteria,
we're
rejecting
it
and
in
the
future.
If
this
criteria
is
not
met,
we'll
go
by
that
as
well
yeah,
but
I.
Also
don't
wanna.
I
will
spend
too
much
time
on
this.
A
Maybe
anyone
would
like
to
comment
to,
or
maybe
respond
to
this
proposal
in
the
agenda
itself.
That
would
be
great
to
have
so
at
least
author
who
cannot
join
this
meeting.
May
get
a
clear
response,
or
if
we
are
open
to
have
a
discussed
some
other
time,
we
can
do
that
either.
D
I
I
just
had
a
question
if,
if
it
isn't
I
I
can
see
the
argument
that
the
EIP
group
or
the
EIP
Corpus
isn't
where
this
gets
decided.
I
feel
like
it's
kind
of
a
meta
question
is:
is
that
an
execution
api's
question
or
a
future
iteration
of
the
yellow
paper
question
like?
Is
there
some
Authority,
some
community
that
would
be
qualified
to
say
you
know
four
interrupt
purposes?
This
is
the
you
know
like
for
the
sake
of
bridge
safety
and
Bridge
interoperability.
H
But
if
it
doesn't
follow
the
execution
specs,
it's
not
ethereum
and
that's
fine,
but
once
you
start
opening
the
door
for
having
some
flexibility
on
that
definition,
I
think
it's
like
really
difficult
to
actually
describe
like
what
are
they
implementing?
What
are
the
deviations
they're
making
so
I
think
that
the
layer
two
should
be
doing
this.
B
D
D
Right,
so
maybe
that
test
Suite
just
needs
to
be
more,
have
harder
tests
or
something
right
like
if.
D
H
H
J
One
one
thing
I'll
add
as
well
for
Roll-Ups
is:
do
not
all
EDM
based
Roll-Ups,
so
it'd
be
kind
of
weird
to
have
like
evm
equivalents,
be
like
enshrined
in
a
way
as
something
better
like
it
feels
like
that's,
not
quite
the
right
level
of
abstraction
where,
if
L1
wants
to
like
make
a
claim
about
what
it
is
or
isn't
the
roll-up,
it
should
be
something
that,
like
also
includes
ZK
roll
up.
It
might
be
something
more
like
a
bridge
standards
or
some
amount
of
I.
J
H
Right,
like
they're,
trying
to
come
up
with
four
three
seven,
that's
equivalent
to
cross
both
optimistic
roles
and
ZK
ropes.
That's
pretty
hard
problem,
so
I
think
trying
to
expand
that
across
all
of
the
evm
is
even
harder
and
they
just
need
to
figure
it
out
themselves.
I,
don't
think
that
we
can
like
enforce
anything
upon
them.
There's
challenges
that
they're
going
to
uncover
as
they
implement
the
stuff
and
they're
going
to
need
to
make
their
own
decisions.
I.
A
Well,
it
seems
it's
clear
enough
that
most
of
the
EAP
editors
are
not
in
favor
of
having
it
reopen
or
maybe
even
considered
for
being
a
standard
at
ethereum
repository.
So
maybe
we
can
give
it
a
rest.
I
assume
from
Victor's
earlier
conversation
that
he
is
like
from
favor
is
moving
towards
neutral.
So
unless
we
get
a
strong
support
of
editors,
we
probably
will
not
be
able
to
reopen
this
proposal
and
move
it
forward.
A
Any
final
comment
on
this
topic
before
we
move
on
to
the
next
one.
A
All
right
so
moving
on
to
the
next
item,
which
is
a
discussion
continued
or
updates
from
the
past
meeting.
The
first
one
here
listed
is
new
contract
interface
and
eip's
should
be
required
to
include
a
privacy
consideration.
It's
issue
number
5682.
A
So
initially
we
discussed
this
item
in
October
last
year
and
this
issue
has
been
back
and
forth
on
the
EAP
AP
meeting
this
time
it
was
added
by
Sam
Wilson
to
today's
agenda
and
I
suppose
it
is
about
getting
affirmation
to
the
decision
made
in
the
earlier
meeting
and
proposing
the
changes
with
a
PR
so
Sam.
If
you
would
like
to
maybe
briefly
go
over
the.
B
So
people
really
want
privacy
explicitly
mentioned
for
some
reason:
I,
don't
really
understand
why
and
I
think
I'm.
The
only
one
blocking
that
so
I
think
a
reasonable
compromise
would
be
to
rename
the
security
consideration
section
to
just
security
and
privacy,
and
that
was
proposed
by
Greg
on
Discord.
B
Just
to
be
clear,
this
would
just
be
renaming
the
security
considerations
to
security
and
privacy,
and
you
don't
have
to
talk
about
privacy.
If
you
don't
want
to,
it
would
just
be
a
name
change.
A
J
G
Guess
I'm
just
curious
in
interface
in
in
interface
and
network.
It
could
also.
J
Right
yeah
so.
G
Maybe
only
four
doesn't
need
it,
and
then
we
can
exclude
cord
well
for
sure,
but
I
do
see
value
in
having
all
other
layers.
J
G
G
Ethereum
provider
in
router,
so
they're
trying
to
allow
multiple
equipment
providers
and
then
by
allowing
ethereum
providers,
the
involvement
would
be.
Do
you
notify
user
if
they
should
be
connected?
And
if
so
does
it
reveal
your
happiness?
And
then
that
is
by
itself
not
an
eerc
problem
and
also
you
could
get
your
transaction
bounded
in
in
some
bundlers.
G
Implication
of
your
intention
and
does
that
involve
impossible
and
we,
so
these
are
things
that
can
get
weird
and
core.
Of
course
everything
needs
to
be
changed,
but
even
so
I
I
think
there
might
be
other
configurations
in
the
future.
So
I'm,
okay,
the
core,
doesn't
included
I,
do
see
I
get
convinced
I
start
off.
G
Without
you
know,
it's
going
to
be
a
possible
thing
that
I
I
think
I
get
convinced
that
in
other
layers,
there's
very,
very
often
ignorance
of
of
privacy,
and
we,
some
authors,
do
want
to.
Let
reader
know
that
hey.
You
should
actually
for
a
few
minutes.
E
My
concern
was
just
that,
yes,
often
privacy
considerations
are
important,
but
they
are
often
so
intertwined
with
security
issues
that
trying
to
do
them
is
a
separate
section
can
be
difficult,
and
so
it
just
makes
more
sense
to
to
handle
them
together.
If,
if
they're
fairly
separate
in
a
proposal,
well,
you
you
do
them
in
separate
paragraphs,
but
forcing
them
into
two
sections
when
they're
relevant
can
just
just
make
it
too
difficult
and
Us
in
the
discussion
somewhat
linked
to
the
to
the
ietf
advice
on
that
and
specific
examples
there,
where
really
they
were.
E
A
I
see
a
comment
by
Sam
in
a
chat
like
if
God
and
ERC
have
different
rules
for
adding
I
think
we
should
hold
off
until
we
split
the
repos.
We
do
have
this
discussion
as
our
next
agenda
item.
So
if
it
is
fine,
we
can
probably
give
it
a
rest
and
give
some
time
to
have
the
discussion
about
splitting
ercs
and
core
eips
and
probably.
I
G
I
quickly,
comment
on
that
I
think,
there's
a
there's,
a
part
I
didn't
get
talked
about,
which
is
the
core
versus
other
all
other
VIPs,
not
just
ERC,
and
the
example
of
game
is
about
interface
and
I.
Do
think
that
there's
a
privacy
issue
with
network
as
well.
So
if
we
are
talking
about
carving
alcore
EIP
versus
all
other
VIPs
I,
think
that
is
a
good
discussion
that
we
can
hold
on
to.
G
But
if
we're
only
talking
about
ERC
versus
core
and
Network
and
and
interface,
then
I
I,
don't
think,
there's
a
good
boundary
to
draw
in
deciding
whether
they
should
improve
privacy
in
section
or
not.
A
Right,
yeah,
I
think
that's
a
good
point,
but
in
case
we
get
the
core
eip's
out
of
this
like
rest
of
the
EIP,
so
not
only
just
with
ERC,
also
from
interface
and
networking
I'm,
not
sure
what
is
the
proposal
here,
but
if
we
do
then
probably
getting
to
a
consensus
about
this
particular
mode,
one
will
be
way
easier
than
it
is
right.
Now.
A
All
right,
so,
let's
try
to
give
it
a
rest
right
over
here
we
have
about
20
minutes
left
on
the
call,
so,
let's
get
into
the
the
next
item,
which
is
kind
of
one
of
the
biggest
can
of
worms
coming
our
way.
So
the
next
item
that
we
are
going
to
discuss
is
about
splitting
ercs
and
core
eibs.
A
Most
of
the
people
on
this
call
are
very
much
familiar
with
the
discussion
point
we
have
been
discussing
in
this
meeting
as
well
I'm
curious
to
hear
what
what
has
changed
since
last,
and
what
do
we
want
to
discuss
for
today's
meeting
so
proposers?
Please
take
it
away.
J
So
we
now
have
people
who
are
like
reviewing
erc's
and,
like
you
know,
like
thinking
about
them
as
like
a
first
class
thing,
sort
of
EIP
editors
and
I
think
that
was
always
like
for
me,
the
biggest
blocker,
where,
if
like
I,
didn't
want
to
like
end
up
in
a
world
where
we
just
like
break
out
the
our
season,
like
it's
just
like
no
one
reviewing
them
and
Matt
and
Sam
have
like
agreed
that
they
could
stay
on
as
editors
on
both
sides.
J
If
we
were
to
split
things,
so
yeah
I
think
having
that
like
means,
we
have
probably
like
the
the
the
capacity
to
handle
both
repos
in
terms
of
why
we
should
split
them
like
I.
Think
high
level
is
just
there's
different
they're
like
very
different
users,
for
each
type
of
like
eips,
whether
that's
like
erc's
or
like
protocol
changes
and
talking
with
fine
teams.
You
know
it's
like
increasingly
like
every
every
time
we
talk
with
them.
J
Basically,
they
say
they'd
rather
have
it
split
and
they'd
like
to
see
the
eip's
process
sort
of
evolve
in
a
Direction.
That's
like
more
closely
coupled
to
like
protocol
development,
and
similarly
you
know,
there's
a
bunch
of
things
that
can
imagine
from
the
ERC
sites
where
it
would
make
sense
for
that
to
evolve
to
a
world
like
towards
something
that's
more
coupled
with
like
application,
error,
development,
yeah.
So
I,
don't
think,
there's
like
any
like
huge
new
reason
for
like
why
we
want
to
do
this.
J
I
think
it's
something
that,
like
at
least
on
the
core
side
like
pretty
much
all
the
users
or
like
folk
type
direct
with
who
like
write
the
IDS,
would
rather
have
this
changed,
and
if
we
have
the
resources
to
do
it,
I
think
it
makes
sense
to
you.
Yeah
I'll,
pause
here,
but
it's
the
background,
foreign.
J
I
think
networking
probably
makes
so
I
think
core
Network
and
networking
makes
sense
together.
For
sure
interface
is
a
bit
of
a
weird
one:
I
like
I,
don't
have
a
strong
opinion.
J
I
could
see
it
go
either
way,
and
maybe
it
gets
duplicated
like
across
both
categories
and
yeah,
honestly,
like
maybe
interface,
meta
and
informational,
sort
of
get
duplicated
or
sensed
to
one
side
or
the
other
I.
Don't
have
a
strong
view
on
that.
I
think
core
networking
makes
sense
together.
Meta
probably
makes
sense
more
on
the
core
side
just
because
of
how
it's
been
used.
Historically,.
J
Seem
like
maybe
they
could
just
be
duplicated
and
then
yeah.
So
the
question
okay
of
numbering,
my
my
very
simple
proposal
for
numbering
is,
like
you,
use
odd
numbers
on
one
side,
even
numbers
on
the
other
side.
So
we
we're
moving
to
the
bot
and
you
just
have
the
bot.
You
know
module
one
module
zero,
zero,
depending
on
which
repo
you're
in
so
like
you,
you,
you
sort
of
start
from
the
same
number,
and
that
means
you're
gonna
have
to
hard
code.
J
It
you
know
on
on
one
side,
but
like
say
you,
you
started
from
number
eight
thousand
or
whatever.
Then
you
just
like
increment
using
yeah,
even
or
odd
twins.
K
E
J
E
K
E
Think
it's
just
it's
just
an
administrative
system
that
we
use
to
file
things
and
give
them
numbers
and
run
some
Bots.
The
conceptual
distinction
is
what
matters
and.
H
G
I
K
A
H
A
Present
present
difference
between
core,
and
you
know,
any
other
proposal
is
like
core
generally
is
when
it
is
with
a
network
upgrade
we
keep
on
waiting
the
last
period
I
mean
like
when
it
reaches
to
last
call.
That
also
happens
when
it
goes
on
test
net.
Not
before
that.
So
there
are
certain
criterias,
which
kind
of
keep
it
separate
from
rest
of
the
proposal,
so
it
is
different.
I
think
it
would
be
interesting
to
understand
what
is
this?
What
is
that
is
blocking?
You
know,
because.
J
It
is
sure
yeah
yeah,
so
this
is
block.
It
just
adds
a
bunch
of
random
friction
and
you
can
imagine
you
know
it's
like
we're.
We're
always
like
contrasting.
What's
like
the
state
today,
but
you
can
imagine
a
world,
that's
like
we
actually
have
like
a
really
well-coupled
process.
Where
say
they
go
to
the
last
call.
There's
something
like
this
is
actually
implemented
or
has
like
a
series
of
tests.
J
You
know
in
like
execution
tests
and
we
can
just
get
like
more
specific
around
like
what
are
the
technical
requirements
for
like
core
eips
I
think
over
time,
as
well
as
we
incorporate
more
of
like
the
CL
stuff
into
it.
It
just
like
reduces
having
to
coordinate
between
CL
and
El,
is
already
kind
of
hard
having
to
coordinate
between
like
erc's
and
eip's
is
already
kind
of
hard.
J
So,
like
you
know,
just
reducing
that
the
like
CL
and
El
gives
you
yeah
just
like
less
people
to
coordinate
with
and,
and
it
doesn't
mean
again
like
you
know,
some
of
the
actual
people
might
stay
on
both
sides
and
like
I,
think
but
and
I
think
yeah.
It
just
opens
the
door
as
well
to
like
folks
in
the
application
they
are
like
that
feel
like
this
is
their
space
and
like
that
process
can
evolve
more
towards
like
an
application.
J
Standardization
process,
which
is
different
eips,
are
like
very
they're,
like
something
stronger
in
a
way
than
a
standard
where,
like
you're,
not
forced
to
use
the
erc20
standard
right
like
you,
can
deploy
a
contract
and
create
a
token
that
doesn't
use
it,
but,
like
you,
do
have
to
implement
the
IP
1559.
If
you
want
to
run
ethereum,
and
there
is
like
a
subtle
but
like
important
difference
there
and
yeah
I
I
think
just
like
they're,
literally
different
things
that
we're
trying
to
do
and
they
sort
of
started
out,
bundled
together,
but
yeah.
E
Yeah
ETF
manages
a
huge
range
of
documents,
some
of
which
are
informational,
some
of
which
directly
affect
the
Internet
Protocol,
others
of
which
Define
applications
that
people
may
or
may
not
run,
and
they
run
a
single
editorial
staff.
They
have
a
single
numbering
system
and
you
know
I've
said:
we've
got
issues
we
need
to
solve
that.
We
keep
going.
Oh
we'll
split
the
repo,
but
that
doesn't
actually
solve
the
issues.
It
creates
issues
of
its
own
and
it
comes
down
to
things
like
well.
Eip1
will
get
a
bit
more
complicated.
E
E
H
I
mean
we
just
made
a
mistake
in
the
beginning:
putting
them
together,
they're,
like
totally
separate
types
of
things
that
we're
trying
to
coordinate
around
one
is
core
eips
that
everyone
has
to
implement.
They
have
to
agree
on
otherwise
they're
Left
Behind.
Then
you
have
the
erc's,
which
is
like
way
more
similar
to
internet
standards
where
it's
like.
This
is
the
state
of
the
art.
This
is
how
it's
specified.
You
should
probably
use
it,
but
you
don't
have
to
you
can
do
whatever
you
want
and
I
just
think
like.
H
H
I
mean
sure
same
thing
with
HTTP.
If
you
don't
Implement
HTTP,
you
don't
get
HTTP,
but
it's
like
you,
don't
have
to
use
HTTP.
You
don't
have
to
use
DNS.
You
can
Implement.
You
can
come
up
with
your
own
protocol
for
finding
the
IP
addresses
of
names.
Ens
like
we
have
other
ways
of
doing
these
things
or
with.
B
Bitcoins
repository
and
that's
that's
where
I'm
going
with
this,
it's
like
the
ietf
is
so
General
that
it
standardizes
it
considered
as
multiple
competing
protocols
like
POP3
and
IMAP.
Let's
say,
whereas
we
are
specifically
in
ethereum
document
repository,
and
there
are
certain
documents
that
if
you
don't
Implement,
you
can't
be
on
ethereum.
So.
J
H
J
Right
there
can
be
competing
parallel
implementations
of
erc's.
There
cannot
be
for
eips
like
at
least
like
that
or
final
right,
like
there
can
be
two
there's
there's
been
like
three
withdrawal
eips,
but
at
the
end
of
the
day
it's
like
4895
is
the
spec
right
and
all
the
other
ones
are
just
like
that
then
drafts
and
that's
like
a
fundamental
difference.
A
But
that's
the
idea
with
the
standardization
here
like
what
I
have
observed
so
far
when
ERC
are
being
edited,
ERC
are
being
reviewed.
We
generally
try
to
make
sure
that
there
is
no
existing
standard,
which
already
has
the
same
kind
of
specification.
Unless
there
is
some
improvement
or
unless
that
specifies
that
it
is
based
on
top
of
an
earlier
existing
ERC
standard,
then
only
it
is
allowed
so
I.
J
And
I
use
sorry,
you
can
still
use
the
RC
20s,
even
though
ERC
1155s
exist.
You
can
argue
that,
like
1155s
are
better
but
like
it
doesn't
block
people
from
using
years
and
20s,
whereas
today,
like
on
a
theory
like
on
Main
net,
when
we
change
the
gas
costs,
you
can
argue
that
the
old
gas
costs
were
better,
but
you
you
can't
use
the
old
gas
cost
like
and
that's
the
the
difference
right.
You
like
force.
Everyone
on
that
change,.
G
G
In
some
cases,
so
I
like
to
use
poor
VIP
versus
all
other
VIP
and
I
see
strong
value
in
keeping
them
in
the
same
repository
and
then
keeping
people
so
that
people
can
have
an
eye
on
both
sides.
I
I,
don't
think
it's
a
it's
a
bug
to
begin
with,
it's
actually
a
good
thing.
One
example
is
that
metallic
himself
tried
three
times
to
go
for
account
abstraction
and
two
of
them
were
using
we're
trying
to
evolve
it
in
the
course
aspect,
and
then
we
didn't
win
very
small
and
then
so
account
abstraction.
G
The
4337
is
attempting
on
a
different
layer,
so
that
kind
of
knowledge
does
not
get
propagate
very
far.
If
you
have
people
working
in
Silo
and
and
that's
why
I
think
having
four
having
four
EIP
versus
other
VIP
would
be.
G
That
would
be
a
good
idea
in
in
the
same
in
the
same
place,
but
we
can
definitely
if
the
problem
is
about
people
don't
like
putting
in
the
IP
and
they
go
to
a
random
repo
I'm
fully
with
you
I
think
we
put
so
much
burden
in
other
in
too
much
restriction
in
author
and
I'm.
Always
a
big
fan
of
relaxing
it
and
like
we
don't
allow
other
considerations,
we
thought
a
lot
of
people
put
for
private.
G
We
just
make
up
this
reason
that
I
don't
feel
very
strong
and
then
over
any
author
who
want
to
do
this.
We
seems
to
be
in
in
a
way
of
work
and
then
it
would
not
be
changed
even
if
the
core
EIP
is
I,
I
I
bet
that
is
going
to
be
the
case
as
well.
I,
don't
see
very
convincing
argument
right
now.
How
harp
it
out?
You
can
actually
let
people
come
over
with
the
current
set
of
rules
yeah.
G
So
unless
that
is
dissolved,
I
don't
think
this
is
a
I
want
to
see
people
coming
and
and
use
this
as
their
way.
There
is
a
place
to
help
drop
their
VIP
by
making.
F
H
H
I
mean
I
think
generally,
we
should
also
deprecate
interface
because
we
have
execution
apis
which
covers
the
majority
of
the
interface,
the
types
of
things
that
interface
standardize.
The
one
place
where
it's
a
little
bit
confusing
is
around
like
JavaScript
libraries
and
they're
wanting
to
have
standards
and
I
think
that
you
know
maybe
it's
painful,
but
they
should
probably
migrate
to
interface
on
ercs
and
just
like
call
them
ercs
I.
Don't
really
care
that
much
though,
like
there's
so
few
of
them,
they
could
stay.
Eaps
too,
like
it
doesn't
really
matter
to
me
up.
G
Until
now,
I
feel
that
ERC
is
not
about
anything
to
be
to
be
standardizing
on
small
contrast,
so
I
feel
it's
very
confusing.
To
put
when
you
say
that's,
they
should
migrate.
The
the
JavaScript
library
on
cbrcs
and.
H
B
We
divide
it
by
audience
right,
so
the
people
who
are
implementing
it
and
like
and
generally
speaking,
like
networking
and
core
will
be
implemented
together,
so
they
should
be
in
repository
together
and
like
interface
and
erst
will
likely
be
implemented
together.
So
they
should
live
together.
J
I
guess
yeah
just
because
to
be
mindful
of
time
like
I,
my
suggestion
would
be
like
I
can
bring
this
up
on
the
next
all
core
devs
and
see
what
clients
thinks,
but
I
think
if
the
client
teams
strongly
desire
this
like
given
the
core
EIP
process,
is
effectively
there
as
a
way
to
like
standardize.
What
is
mostly
their
work.
I
would
like,
like
to
move
forward
with
this,
but
I'm
happy
to
yeah
check
in
on
all
core
devs
and
like
be,
if
there's
like
broad
support
for
this.
My
client
teams.
G
Can
we
have
a
list
of
items
that
they
think
it's
really
bad
and
hard
for
you
to
do
in
in
EIP?
In
the
current
EIP,
we
probably
and
then
I
I,
felt,
like
a
lot
of
things
exist
in
our
policy
restriction
like
I,
I
I
was
involved
in
in
the
complaints
that
people
cannot
even
link
to
execution
is
back,
and
that's
that's
one
of
the
reasons
they
just
stop
proposing.
G
That
I
saw
one
of
the
MP
just
started
in
the
draft
status
because
of
one
of
the
one
one
case
in
that
so
I
love
to
see.
What's
the
real
reason
that
they
don't
like
to
come
to
European
and
we
should
fix
that
I
really
feel
we
should
fix
our
EIP
and
just
relax
our
research
restrictions.
We
can't
relate
to
what
yellow
paper
we
can't
list
a
lot
of
things.
H
G
J
J
Actually
work
on
stuff
has
been
helpful,
so
I
don't
want
to
like,
like
completely
dismiss
the
changes,
but
I
think
it's
I
I
would
agree,
though
it's
like
almost
asking
them
about
like
what
they
don't
like
it
like
people
feel
very
checked
out
from
the
EIP
process
in
a
way
where,
like
they
just
feel
like
it's
like
this
thing
that
they
don't
really
have
control
over
or
like
every
time
they
engage
with
it.
It's
like
not
the
best
experience
and
like
splitting.
J
The
process
basically
gives
them
like
ownership
over
the
thing
where
it's
like
yeah.
This
can
now
be
the
process.
That's
focused
with
like
core
development
and
like
we
can
just
not
have
any
other
considerations
beyond
that.
As
we're
doing
changes
to
it,
I
do
need
to
hop
as
well,
though
unfortunately,
but
is
it
helpful
to
put
this
on
the
awkward
as
agenda
for
next
week
or
do
people
feel
like
there's
not
any
value
there.
A
J
A
J
Okay,
I'll
add
that
at
the
end
of
awkwardness
tomorrow
actually
next
week,
if
we
have
time
we'll
get
into
it
like
if
it's
possible,
we
run
over
and
and
don't
have
time
to
get
into
that,
but
I
think
yeah.
F
H
We
do
kind
of
need
consensus,
though,
like
we
do
not
I
mean,
of
course,
we
can
just
Fork
the
repository
and
do
whatever
we
want,
but
that's
just
like
we.
We
want
to
have
a
subdomain
on
ethereum.org
that
says
ercs
and
eips,
and
somebody
has
to
decide
who
you
know
picks
the
repository
that
it
points
to
and
those
people
are
kind
of
us
right
now.
K
G
I'm
happy
to
sit
in
the
corner
in
a
core
group
and
ask
what
kind
of
history
and
then
we
can
make
that
list
and
see
if
it's
it's
doable
and
maybe
they'll
come
up
with
it
with
the
ideal
states
that
it's
achievable
and
then
either
it's
by
forking.
That's
fine!
Either.
It's.
H
Not
the
core
devs
are
not
going
to
babysit
the
EIP
process;
they
don't
want
to
sit
and
engage.
They
have
so
many
breakout
rooms
and
other
things
to
do
they're
not
going
to
try
and
talk
about
the
process.
That's
they
that's
their
least
favorite
thing
to
do.
They
don't
even
want
to
go
to
the
calls
where
they
talk
about
the
technical
things
they're
not
going
to
engage
with
us.
G
G
They
don't
want
to
deal
with
erc's
I
have
never
blocked
a
a
a
updates
in
it.
H
G
E
G
I
can
use
I
use
a
different
way
and
then,
on
the
other
hand,
I'm
here
to
provide
aspect
of
the
Arty
authors
I
feel
it's
not
very
well
represented,
even
though
the
majority
of
the
a
portion
of
it
is
from
Erp
and
then
I
didn't
know
that
when
you
use
that
comment,
I
think
it
was
a
bit
personal
I
don't
want
to
go
that
go
down
that
route,
but
I
do
believe
that
there's
a
lot
of
value
in
having
people
look
at
the
both
side
of
the
category
as
well,
and
then
my
my
argument
is
that
splitting
it
doesn't
solve
the
problem
just
like
you
and
you
are
still
going
to
block
and
make
it
very
hard
in
the
in
the
future
for
all
the
new
core
EIP
reports,
three
of
food
for
them
to
add
it,
and
then
they
will
be
unhappy.
G
So
that's
that's
will
be
my
argument,
whether
that
you
believe
it
or
not,
I'm,
not
sure
but
yeah.
That's
that's
my
opinion.
A
Yeah
I
think
we
are
over
time.
We
will
be
probably
listening
to
more
from
directly
from
the
Codex
in
the
next
all
code
I'm
meeting.
It
would
be
really
interesting
to
hear
their
thoughts
like
what
they
are
trying
to
introduce
as
a
core
EIP
process
that
is
going
to
help
them.
If
that
is
something
really
good,
I
would
hope
that
ERC
or
any
other
category
process
should
also
Implement
those
changes.
It
would
be
nice
to
have
changes
which
are
going
to
make
life
simple
of
new
Authors.
A
A
So
I
know
we
had
a
couple
of
more
items.
Those
are
really
quick.
One
is
eips.
Insight
I
have
already
added
the
list
of
proposals.
Here
we
received
one
EIP
in
final
status,
and
that
is
of
course,
ERC
category.
We
did
receive
eight
drafts
out
of
those
eight
one
is
core
and
rest.
7
are
ERC
drafts.
We
have
only
one
proposal
in
last
call
with
deadline:
15th
August.
The
proposal
is
6093
for
rest
of
the
details.
People
may
refer
to
the
hack,
MD
or
the
eipsinsite.com.
A
We
did
have
a
EIP
editing
office
hour
yesterday.
Recording
from
the
past
meeting
is
added
and
also
the
agenda
where
authors
can
add
their
pull
requests
to
be
discussed
in
their
next
meeting
if
it
is
not
merged
before
the
next
one
I
have
also
added
the
summary
from
the
last
meeting,
also
shared
by
Sam
Wilson
on
the
eat,
r
d
Discord,
please
check
it
out
and
yeah.
Thank
you.
Everyone
for
joining
us
today
hope
to
see
some
good
reference
point
from
the
next
alcorder
meeting
to
have
it
discussed
in
this
meeting.