►
From YouTube: Ethereum Core Devs Meeting #33 [02/09/18]
Description
A
B
A
C
D
D
D
There
was
new
suggestion
that
the
test
generation
should
run
using
any
client,
not
just
shitty
precedent
for
that.
Dimitri
started,
working
RPG
based
test
generation
so
currently
is
station
code
is
written
in
C++
and
88
recalled
CPP
clients
functions,
but
the
next
plan
is
to
separate
this
disinterred
different
executables
talking
over
an
RPC
so
that
test
generation
can
burn
any
client.
That
suppose
did
this
Takeshi
methods.
D
D
E
E
In
the
same
vein,
we
should
talk
and
take
a
look
at
how
we're
running
the
consensus
tests
over
JSON
RPC
for
pi
EVM.
So
we
have
a
full
test
suite
that
actually
runs
the
JSON
test
Suites
over
over
an
RPC
connection,
so
it
loads
all
the
data
with
some
special
custom,
RPC
endpoints
and
then
test
them
using
standard,
RPC,
endpoints,
actually.
D
C
By
the
way,
we
also
had
a
quick
chat
in
Berlin
on
Wednesday
that
it
will
be
nice
to
have
a
have
a
discussion
with
a
few
people
specifically
about
somehow
standardizing
these
methods
among
clients,
so
that
we
we
can
do
something
that's
meaningful
for
all
the
clients,
I
think
on
Tuesday
that
scheduled
for
Tuesday.
Anyone
wants
to
introduce
this.
D
One
so
for
this
one,
the
set
of
methods
is
already
defined,
so
basically
the
method,
that's
used
by
certain
tests,
the
testings
with
possibility
I
mean.
So
this
is
really
the
compiler
being
compiled.
A
beam
by
the
code
must
be
tested
in
some
client
and
currently
it's
just
among
stability
and
CPP
serial,
but
if
other
clients
support
the
same
method,
so
tests
can
run
on
these
variants
as
well,
and
this
works
as
a
test
of
possibility,
as
well
as
a
client.
So
it
should
be
a
wing
meeting
and
four
distinct
set
of
methods.
A
C
B
A
Okay,
the
next
topic
is
a
IP
867,
so
the
IP
867
is
a
an
EIP
that
proposes
that
we
have
a
standardized,
etherium
recovery
proposal,
system
or
ERP,
so
the
recovery
of
certain
classes
of
lost
funds
can
be
submitted,
so
I'm
gonna
just
go
ahead
and
have
Dan
who's
joining
us
he's
five
for
D
on
github
and
the
one
of
the
people
who
proposed
this.
So
he
can
go
ahead
if
you
Dan,
if
you
could
give
an
outline
of
what
this
is
and
then
kind
of
an
overview
of
where
the
conversations
gone
the
past
week.
F
Sure
so
the
that
major
outline
of
the
proposal
sort
of
came
together
as
I
was
talking
to
people
in
the
recovery
Channel,
so
I'm
with
news
economy.
We
were
affected
by
the
parody
multi-sig
issue,
but
I
know
that
there's
CIP
1:56
that
was
out
there
and
there
was
a
different
set
of
cases
that
would
potentially
could
be
addressed
through
that
there
was
some
conversation
on
that
issue
about
trying
to
include
other
cases,
but
it
seemed
like
maybe
it
didn't
all
fit
together.
F
So
as
there
was
discussion
going
on
in
the
ether,
recovery,
Channel
I
think
in
the
context
of
the
original
solution
that
was
put
forward
by
parody
that
had
suggested
so
maybe
some
ppm
modification
so
I
think
the
big
difficulty
with
that
was
that
it
would
affect
contracts
that
were
already
out
there.
They
had
some
ways
to
maybe
mitigate
that,
but
it
really
looked
like
there
was
a
lot
of
potential
for
unintended
consequences
with
those
EVM
changes,
and
so
the
conversation
in
the
ether
recovery
channel
is
sort
of
started
to
focus
on
irregular
state
change.
F
F
So
what
the
we
ultimately
came
up
with
was
that
okay,
first
of
all,
we
make
the
assumption
that
there
are
these
cases
that
people
would
like
to
see
salt,
and
if
that's
the
case,
you
know
what
cases
could
be
solved
by
an
irregular
state
change
and
even
what
cases
should
be
considered
and
then,
if
we
were
to
say
okay,
yes,
maybe
there
are
some
cases,
these
certain
types
of
cases
that
could
be
considered?
What
should
that
process
look
like,
rather
than
having
everybody
say,
submits
a
change
to
each
client?
F
That's
you
know
is
it
is
going
to
be
coded
and
it's
going
to
be
another
if
block
somewhere
in
the
in
the
code
and
it's
going
to
be
technical
debt.
So
is
there
a
way
that
we
can
handle
this
to
minimize
the
amount
of
effort
that's
associated
with
each
one
of
these
recovery
proposals
and,
at
the
same
time,
make
sure
that
the
verification
process
is?
F
Is
very
clear,
so
what
we
wanted
was
a
transparent
process
that
would
allow
some
of
these
cases
to
be
addressed,
and
what
I
tried
to
do
in
the
in
the
proposal
was
be
very
clear
about
the
types
of
cases
that
could
be
addressed
and
specifically,
where
you
know,
there's
no
there's.
No
one
contesting
the
ownership
of
funds.
Let's
say
I
certainly
would
exclude
any
sort
of
case
where
someone
says
hey
this
guy
I
sent
him
some
ether
and
he
didn't
do
what
he
said.
F
F
There's
some
I'm
stuck
ether
and
if
there's
everybody
would
agree
that
everybody
who's
at
least
directly
affected
would
agree
that
it
would
be
better
if
XYZ
happened.
Is
there
some
way
to
take
those
cases,
a
very
narrow
set
of
cases
and
say?
Well,
maybe
we
can
address
those
and
I
think
I.
In
my
the
way,
I
was
thinking
about
this.
F
The
there's
a
number
of
cases
that
have
been
talked
about,
there's
the
EMP
156
cases,
there's
the
save
splitter
cases,
there's
the
parody
multi-sig,
there's
another
one
with
a
client
library
that
left
off
some
padding
or
included
some
extra
padding
I,
don't
remember
exactly
the
details
where
I
can't
say
for
sure.
If
you
know
all
of
those
could
be
handled
by
this
process,
but
if
there
were
a
way
for
them
to
essentially
present
their
case
present
their
evidence
that
hey
it's
obvious.
F
What
the
right
thing
is
to
do
here
who
the
true
owner
of
it
is
here's
the
set
of
actions,
here's
how
I
decided
what
addresses
would
be
affected.
So
there's
this
verification,
script,
that's
included.
So
if
we
were
to
you,
know
narrow
it
down
to
this
very
small
set
of
cases.
Is
there
some
way
that
we
could
handle
this?
So
the
conversation
and
the
P
was
started
off
just
about
you
know
whether
there
was
maybe
some
conflict
with
see
if
they
are
in
philosophy
on
whether
or
not
this
should
be
done
and
and
I
think.
F
F
The
other
types
of
concerns
are
about
cost
and
you
know
whether
or
not
it's
it's
maintainable
or
whether
or
not
it's
going
to
be
too
difficult
to
try
and
handle
all
these
Europe.
You
requests
and
I
think
any
concerns
that
have
to
do
with
the
resources
I
think
are
pretty
right
forward
to
address,
especially
given
the
amount
of
funds
that
are
locked
up,
I
mean
even
just
in
the
parity
multi-sig
alone,
somewhere
around
half
a
billion
dollars
at
the
moment.
F
So
I
think
if
funding
is
an
issue
or
resources
is
an
issue,
that's
that's
an
easy
problem
to
solve,
and
then
the
other
thing
that's
brought
up
is
maybe
just
risk,
and
so
that's
a
lot
of
the
process
that
was
included
in
the
ERP
proposal
was
about.
How
can
we
reduce
risk
one
of
the
things
that
we
can
put
in
place?
F
So
one
of
the
conversations
that
came
up
was
about
some
language
in
there
that
had
some
peer
review
type
of
process
and
I
think
that
was
initially
looked
at
as
maybe
selecting
a
special
set
of
people,
though
only
they
could
do.
The
validation
and
I
I
really
put
it
in
there,
because
I
thought
well
we're.
F
But
that
was
the
intent
of
including
it
and
I
guess
the
other
place
where
things
maybe
were
not
so
clear,
was
I,
think
I,
misunderstood
the
directions
of
causality
in
this
process
and
and
that
the
IPS
would
be
proposed
and
unapproved,
and
then
there's
sort
of
disagreement
that
once
an
EIP
has
approved
that
the
clients
will
go
and
implement
it
and
I
understand
that.
That's
not
the
way
it
happens,
and
it's
more
the
other
way
around
that
when
clients
agree
and
they
may
have
their
own
approval
process
pulling
the
community.
F
However,
they
do
it,
then
that's
when
something
gets
marked
as
accepted
so
I've
updated
the
language
in
there
and
reflect
that
and
make
sure
that
I'm
not
attempting
to
give
any
additional.
You
know
bureaucratic
power
to
whoever
the
VIP
editors
or
are
the
people
who
are
doing
the
verification
that
wasn't
my
okay.
A
F
That's
the
yeah,
if
that's
the
process,
that
was
my
understanding
is
that
that
was
the
process,
and
so,
when
it
didn't
get
merged,
I
was
concerned
that
that,
if
it
wasn't
getting
merged
that
it
was
sort
of
influencing
the
discussion,
that
would
happen
because
people
would
see
how
this
thing
is
blocked
from
even
being
merging
it's.
Maybe
it's
bad
idea
or
I'll
wait
until
it
gets
merged.
F
In
order
to
give
my
opinion,
I
don't
know,
but
if
that's
the
standard
procedure
that
it
should
be
unmerged
until
it's
effectively
accepted
that
that's
what
I
didn't
understand
as
I
thought
it
would
get
merged.
Unless
there
was
some
major
issue
and
then
people
could
have
a
discussion,
it
would
be
draft
and
so
yeah
I
think.
If
that's
the
logical
next
step,
then
great
I
be
happy
to
have
that
happen.
But
if
you
tell
me,
that's
not
the
way
it
works,
then
yeah.
A
So
here
I'll
do
I'll,
just
give
my
opinion
first
and
then
we
can
go
around
to
the
other
editors
and
people
in
the
room
who
have
some
comments,
but
basically
the
biggest
issue.
Right
now
is
the
fact
that
there
needs
to
be
some
updates
to
EIP
1.
There
needs
to
be
clarity
on
just
what
gets
merged,
how
it
gets
merged,
because
the
EIP
process
was
initially
left
vague
and
pretty
much
a
copy
of
the
VIPs
Bitcoin
and
pretty
mint
proposal
process.
A
So
after
that,
there
has
been
a
few
times
that
it's
been
updated
to
more
address.
Aetherium
sneed
such
as
adding
ERC's
as
a
subtype
of
VIPs
to
be
approved,
there's
also
a
path
that
any
IP
takes
from
draft
to
acceptance,
but
as
far
as
when
it
gets
merged
to
the
repository
that
I
have
not
seen
that
written
anywhere.
As
far
as
like
after
time,
X
or
thing
X
happens,
it
gets
merged
it's
more
at
the
discretion
of
the
editors,
and
so
it's
been
very
mixed.
A
What
gets
merged
so,
for
instance,
er
C,
20
I,
think
it
was
mentioned
in
the
thread.
I,
don't
think
that
got
merged
four
years.
After
it
was
being
widely
used,
not
because
of
anyone
trying
to
Brigade
it
or
stop
it
from
happening
or
anything
like
that,
it
just
was
the
editors
just
not
merging
it
yet,
and
everybody
using
it
anyway.
So
there
isn't
that
clear
of
a
process
right
now
for
when
things
get
merged.
A
A
So
it's
now,
in
my
opinion,
a
priority
for
people
to
or
for
the
EIP
editors
to
change
the
process
somewhat,
make
it
more
clear
and
until
then
I
personally
don't
think
it
should
be
merged,
but
I
definitely
want
other
opinions
of
the
room
but
Dan.
If
you
want
to
respond
first
and
then
we'll
get
other
opinions,
yeah.
F
I
think
that's
I,
think
that's
fine!
If
the
if
the
process
isn't
clear
right
now,
I
mean
certainly
it
helps
if
I'm
still
making
at
it's
still
getting
feedback
to
not
have
emerged.
I
think
the
biggest
drawback
is
just
the
it's
hard
for
people
to
go
and
read
it.
They.
You
know
they
know
where
to
click
in
github.
That's
fine
drew
from
people
who
aren't
familiar
with
that.
Maybe
it
might
be
difficult
to
go
in
there
and
figure
out.
Okay.
How
do
I
actually
read
the
thing?
I
saw
some
comments
on
reddit.
F
A
C
G
G
G
A
Plans
for
a
while
has
been
to
update
the
process,
so
this
isn't
spurned
by
the
controversial
EIP.
I
will
admit.
However,
it's
definitely
put
more
pressure
on
it.
To
go
faster,
so
I
mean
there's
always
gonna
be
a
chance
of
biases
creeping
in
with
anything,
and
the
best
thing
we
can
do
is
just
stay
open
and
transparent
about
this
yeah
yeah.
A
G
Me
say
one
more
thing
quickly.
I
think
is
especially
important
for
something
like
this,
where
it
really
does
play
deeply
into
this
kind
of
important
questions
about
like
what
is
the
nature
of
the
blocking.
What
is
the
relationship
between
the
blockchain
in
the
community
and
how
do
we
kind
of
like
like
it
does
affect
this
question
of?
Like
you
know
what
is
the
philosophy
of
aetherium
and
and
so
like
in
this?
G
These
proposals,
especially
proposals
that,
like
do
kind
of
you,
know,
set
important
precedents
that,
like
impact
the
relationship
between
the
community
and
the
platform,
I
think
need
to
be
subject
to
a
tremendous
amount
of
public
debate
that
I'm
not
actually
sure
the
each
process
is
designed
to
really
handle,
and
as
an
example,
let
me
just
say
that
I,
don't
I
mean,
in
my
recollection,
was
at
the
die.
Hard
fork
entirely
happened
outside
of
the
each
process.
I'm,
not
sure.
G
If
that's
something,
we
think
was
a
good
idea,
but
I
think
that
was
something
that
happened
because
the
east
process
wasn't
set
up
to
deal
with.
That
kind
of
the
kind
of
existential
deep,
like
philosophical
kind
of
like
important
fundamental
questions
about
the
relationship
between
the
community
and
the
Oracle.
G
So
that's
that's
kind
of
true,
but,
like
you
know,
we
did
have
like
well
over
a
month.
There
was
certainly
enough
to
do
go
through
the
east
process.
If
that
was
what
we
were
gonna
do,
but
but
we
didn't
right,
I'm,
not
sure
what
does
it
do?
People
think
that
the
east
process,
it
would
have
been
appropriate
venue
for
the
down
hard
floor,
I.
A
G
A
D
I
can
last
week
I
merged
one
EEP
and
the
author
of
the
EEP
to
me
he
was
still
modifying
deep,
so
I
have
to
continue
the
my
you
just
think,
because
I
don't
want
to
be.
You
know,
particularly
against
particularly,
but
then
so
this
time.
This
time
was
my
first
time
reviewing
the
process
method
concerning
the
consensus
process
and
okay.
Well-
and
this
is
this-
was
my
first
time
looking
at
this
theorem
philosophy
mentioned
in
it
number
one.
D
During
that
period,
I
refused
to
merge
this
EEP,
because
that
document
was
against
having
trusted
operators
up
here,
but
I
mean
at
most
like
3040
people.
Deciding
balance
transfer
seemed
like
at
least
at
odds
with
this.
That
document
that
philosophy
document,
but
well
later
this
week,
I
noticed
that
this
SEM
philosophy
mentioned
in
deep
number.
One
was
originally
just
copied
and
pasted
from
the
Bitcoin
document
be
0,
0,
1
and
there
it
was
like
not
in
keeping
with
the
people
in
philosophy,
and
then
it
was
modified
in
the
same
philosophy.
D
So
now
I'm
not
sure
if
this
theorem
philosophy
mentioned
in
it
number
1
refers
to
a
particular
document
or
not,
and
I
wouldn't
use
this
theorem
philosophy
Clause,
unless
I'm
sure
that
most
of
the
same
community
believes
that
the
SEM
philosophy
and
I
I
don't
have
that
kind
of
confidence
anymore.
So
I
don't
use
this
SEM
philosophy
thing
anymore,
so
they
for
me
the
same
as
the
usual
EEP.
So
after
some
spirited
King
Hitler
format
and
if
it's
very
fish
fighting
not
fun
or
something
I,
just
not
as
addressed.
A
Yeah
and
I
think
that's
I,
think
that's
a
good
policy
and
I
mean
we'll
talk
about
what
the
final
process
should
be,
but
I
mean
I
think
we
should
be
getting
in
a
habit
of
merging
them.
Personally,
we
need
to
talk
with
the
other
editors
and
you
know,
get
some
feedback
but
merging
them
as
soon
as
the
author
wants
them
merged
and
it's
formatted
correctly
sounds
like
a
fair
way
to
do.
It.
D
D
F
Yeah
I
think,
if,
if
this
is
something
that's
not
uncommon,
I
haven't
followed
too
much
the
the
IPS
that
that
have
come
out
before
in
the
process.
That's
behind
it,
and
my
major
concern
was
just
if
this
is
something
your
regular.
That's
happened
and
it's
acting
as
a
signal
to
the
community
and
knots
may
be
influencing
the
debate.
If
that's
not
the
case,
then
it
doesn't
concern
me
so
much.
If
there's
a
good
reason
to
to
leave
it.
Unmerged
I
mean
certainly,
as
I
mentioned,
continuing
to
edit.
A
F
H
Still
very
controversial
or
still
being
being
built,
I
don't
think
it
should
merge.
I
think
that
the
fact
that
the
year
c22
so
long
were
it
wasn't
that
much
we
eat
really
was
formatted
and
I
don't
mean
that
only
for
the
request
for
for
recovery
to
recovery,
but
even
things
like
the
next
token.
There
are
multiple
token
elimination,
hood
are
being
floated
and
I.
Think
all
of
them
are
at
birch.
I
would
say
that
the
best
way
to
merge
something
is
after
it
has
been
tested
in
the
wild.
H
H
F
I
H
D
E
Basically,
when
something
is
like,
you
know,
met
whatever
the
minimum
old
standards
are,
it
seems
like
merging
something
as
draft
is
fine,
and
then
at
that
point
you
can
continue
a
conversation
in
a
separate
poll
request,
at
which
point
it's
a
lot
easier
to
pick
out
the
things
that
have
changed
from
the
original
draft.
It's
a
lot
smaller
set
of
changes.
It
might
actually
facilitate
that
sort
of
tweaking
discussion
that
that
has
to
happen
for,
for
those,
like
minor
rule,
changes,
small
changes
to
the
so
merging
things
prior
to
them
being
accepted.
E
You
know
for
implementation,
it
seems
fine
and
I
feel
like
we
still
have
a
pretty
good
forum
for
continuing
discussion
just
through
a
secondary
pull
request
that
that
modifies
the
EEP,
even
if
that
initial
per
request
is
literally
just
changing
the
status
to
accepted,
at
which
point
the
the
discussion
can
continue.
There.
E
Yes,
so,
like
initially
things
get
merged
as
draft
once
they're
sort
of
gonna
be
author
feels
like
it's
a
good
starting
point
and
all
of
the
you
know,
various
sort
of
minimum
requirements
have
been
met,
after
which
a
second
pull
request
gets
open,
changing
the
status
from
draft
to
accepted,
at
which
point
that's
where
the
sort
of
deeper
discussion
can
happen
on
all
the
little
tweaks
that
maybe
need
to
happen.
I
see.
D
D
A
Yeah
there's
also
superseded,
so
that's
another
good
one.
So,
for
instance,
if
there's
a
new
token
standard,
there's
gonna
be
some
discussion
on
whether
it's
superseded
zrc
20
or
if
it's
just
an
alternate
standard
that
then
gets
accepted
to
then
be
used
by
whoever
wants
to
use
it.
So
that's
a
whole
nother
discussion
for
another
day,
but
so
there's
there's
a
lot
of
statuses.
We
can
use
to
make
things
clear
once
a
once.
A
PR
has
been
merged.
Any
other
comments
on
this
topic.
B
A
B
A
And
then
once
it
gets
a
little
bit
more
mature,
probably
you
know
it's
only
been
around
for
a
week
and
once
it
gets
a
bit
more
community
support.
Bringing
it
up
in
another
coordinate,
meeting
I
think
would
be
very
appropriate,
so
I
think
then,
and
also
once
we
figure
out
the
merging
thing
and
just
things
kind
of
move
along
a
little
bit,
we
can
bring
it
back
up
at
a
core
dev
meeting.
J
K
J
Just
one
exit
here,
so
one
small
thing
I
would
like
to
you
know
if
somebody
hears
this
or
somebody
wants
to
make
a
like
a
public
debate
about
it,
I
think
that
would
be
good,
regardless
of
what
the
process
is,
because
I
understand
what
we're
discussing
here's
just
a
kind
of
formality
which
I
don't
know
really
important
in
this
case.
So
yes,
let's
have
a
public
debate
about
it
and
just
to
to
figure
out
whether
it's
a
good
thing
to
do.
J
A
J
I
would
actually
suggest
not
going
even
beyond
it
I
think
it's
such
an
important
topic.
It
should
be
debated
like
in
a
sort
of
live
video
or
something,
but
you
know
I
know
it's
not
it's
just
beyond
this
meat
beyond
the
purview
of
this
meeting,
but
I'm
just
kind
of
the
suggestion.
That's
that's
a
good
idea.
E
That
debate
to
a
live,
video
basically
puts
people
on
the
spot
and
makes
this
a
politician
based
thing
rather
than
a
like.
Let's
have
a
careful
discussion
about
it,
so
I
think
keeping
it
in
text-based
asynchronous
formats
is
a
much
fairer
way
to
do
a
contentious
debate.
Otherwise
it's
a
popularity
contest.
It.
A
D
J
A
A
A
So,
let's
start,
if
and
I
updated
this
right
before
the
meeting,
so
you
might
have
to
refresh
the
page
to
see
them,
but
II
IP,
145
bitwise
shifting
instructions
for
the
EVM
that
one's
pretty
uncontroversial.
Does
anyone
have
any
comments
on
that?
We've
pretty
much
said
before
that
it
can
go
in,
but
does
anyone
have
any
other
comments
on
that
and.
B
H
I
A
D
B
For
the
spreadsheet
that
was
more
for
coming
up
and
writing
down
complex
scenarios
of
the
types
of
tests
that
should
be
needed
for
something
like
the
shifting
operations.
I
think
it's
perfectly
fine
with
just
using
the
once
in
the
eat.
Plus,
maybe
a
few
few
more.
If
there
are
n
a
particularly
interesting
educators,
which
I
don't
know
what
they
would
be.
That's.
L
Yeah
I
guess
I
mean
we
have
those
test
cases
defined.
It
just
needs
to
be
translated
into
an
actual
state
test,
I
think
in
the
test
repo,
so
every
client
can
test
against
it.
Oh
and
I
think
there
was
a
second
part
to
this
briefly
mentioned
last
time
and
that
in
the
test
repo-
and
there
needs
to
be
a
new
heart
fork
added
called
concerned
in
opal,
I
suppose
and
it
needs
to
be
generated,
etc.
I'm
gonna
finish
the
process
there
so.
D
B
C
I
just
wanted
to
say
that
if
a
while
back,
we
are
discussing
that
it's,
it's
really
really
hard
to
make
new
test
cases,
meaning
that,
for
example,
if
while
I
am
implementing
an
EIP
and
I,
find
some
really
weird
corner
case
for
the
golden
foundation.
To
do
it,
it
would
be
really
awesome
if
I
could
just
somehow
create
the
test
case.
That
can
be
run
against
the
other
ones
and
back
then
we
were
discussing
that
it
would
be
nice
if
we
could
somehow
figure
out
a
more
streamlined
approach.
C
D
C
But
that's
exactly
my
point
that
of
course,
I
have
every
one
of
us
can
make
tests,
but
if
it's
going
to
take
half
an
hour
that
I'm
simply
not
going
to
do
it
because
it's
it's
just
painful
and
gets
in
the
way.
So
if
we
could
streamline
it
so
that
you
could
do
it
in
maybe
three
minutes,
then
that
would
really
help
I
see.
Okay,
three
minutes
is
a
good
number.
C
L
So
another
comment
in
in
general:
I
suppose
we
don't
really
have
a
proper
timeline
yet
for
for
the
heart
fork
or
any
of
these
changes,
but
what
should
be
so
if
practically
right
now,
it's
it's
really
hard
for
anyone
not
familiar
with
the
test
way
to
create
new
test
cases.
What
should
we
expect?
What
kind
of
time
frame
should
we
expect
for,
like
the
bit
by
shifting
test
to
appear.
L
A
A
L
D
A
A
Okay,
the
IP
210
block
hash
refactoring,
that's
another
one
that
Martin
and
I
agree
with
him
kind
of
implied
was
not
very
controversial.
So
I'm,
let
me
go
to
block
hash
refactoring,
that
is
a
State.
That's
a
system.
Contract
I
believe
that
reduces
protocol
complexity.
It
says
to
process
the
block
hash
opcode,
so
one
perspective
I've
heard
on
this
is
that
it
is
a
good
stepping
stone
for
pieces
of
Casper,
since
this
would
be
the
first.
A
B
Of
this
obsess
is
that
the
certain
port
number
there
will
suddenly
appear
a
contract
at
address
and
no
f0
and
that
add
another
contract,
and
it
also
specifies
the
code
that
will
go
in
there,
although
that
may
change
and
what
this
contract
so
and
then
afterwards
in
each
block,
this
contract
is
called
before
any
other
transactions.
A
call
is
made
from
some
system
address.
B
The
calls
made
to
this
contract
and
the
call
data
contains
the
previous
block
cache
and
once
256
blocks,
I.
Think
as
number
has
passed
since
the
fork
invocation
of
the
opcode
loCash
will
instead
be
a
call
to
this
contract,
and
what
this
contact
does
is
that
it
saves
blockages
state
requiring
the
clients
explicitly
maintain
this.
B
E
I
A
I
B
L
Can
give
some
clarifications
at
least
what
I
understand
there
is?
It
should
be
able
to
cover
more
than
20
56-bit
2056
hashes,
but
there
were
different
implementations,
storing
and
them
in
a
different
way
and
as
a
result,
if
calling
the
block
up
code,
that
would
still
be
limited
to
256
items
and
it
would
have
a
fixed
cost.
L
The
800
you
have
mentioned,
but
a
contract
would
be
able
to
directly
call
the
contract
and
retrieve
more
information
if
it
supports
storing
more
than
256
hashes,
and
that
would
have
just
a
regular
cost
of
calling
and
but
the
actual
cost
of
the
contract
was
well.
The
extra
cost
of
the
contract
would
be
it's
a
normal
EVM
contract,
so
it's
just
regularly
calculated,
but
I.
Think
maybe
lanes.
Question
was
more
like
what
happens
to
the
first
transaction
in
every
block.
A
Yeah,
so
actually
that
brings
me
to
a
comment
that
Powell
made
ten
days
ago.
It's
at
the
very
bottom
of
the
poll
request
for
this
eeep
and
it
says
that
the
code
still
has
a
bug
and
that
he
wants
to
write
unit
tests
for
the
contract
and
that
he'd
like
to
implement
it
in
Julia
to
estimate
the
lower
boundary
of
the
gas
consumption
am
I,
saying
that
right,
Julia.
M
A
L
A
A
J
J
It's
Alexi,
so
basically
we
asked
we
want
an
assessment
of
how
much
saving
in
disk
space
or
whatever
this
change
will
bring
and
I.
Think
Andre
from
the
C
C++
team
has
already
did
some
analysis.
But
this
analysis
only
covers
only
covers
the
number
of
accounts
which
could
be
deleted
at
a
certain
threshold
of
the
that,
what's
considered
to
be
dust
and
it's
actually
attached
to
the
year
to
DAAP.
J
So
what
I'm
planning
to
do
in
the
next
couple
of
days
is
that
I
have
a
code
which
could
analyze
how
many
nodes
in
the
actual
state
tree
would
be
removed
if
the
different
thresholds
and
I
will
post
that
Graff.
So
for
everybody
to
see
so
that
we
can
make
more
informed
decision
whether
this
AIP
brings
enough
improvement
to
justify
the
implementation.
A
C
Yes,
so
we
also
had
a
discussion
about
this
internally
and
this
yet
is
bit
interesting
and
this
problematic,
because
so
the
original
proposal
that
Gavin
made
I
think
he
said
that
he
proposed
that
any
account
that
has
less
than
420
Saboo
should
be
deleted
and
I'm,
not
sure
it's
where
I
saw
the
exact
number.
Somebody
says
that
that
would
amount
to
by
about
45
cents
currently
and
I
think
this.
C
This
really
highlights
the
issue,
the
core
issue
with
the
CIP,
in
that,
how
do
you
define
a
threshold
which
is
a
good-enough
threshold
in
the
future
too,
because,
for
example,
if
you
would
propose
now
that
we
delete
everybody's
accounted
as
less
than
45
cents,
then
the
entire
ecosystem
would
blow
up
that
body
mean
because
all
of
a
sudden-
something
that
was
one
and
a
half
year
ago
and
a
significant
sum
now
became
what
I
wouldn't
call
foreign
accent
significant,
but
still
it's
not
insignificant
anymore.
Well,.
A
C
Yeah
and,
for
example,
Felix
had
so
way
back.
Yeah
I
know
it
this.
This
is
off
the
table
currency,
but
just
to
mention
it.
There
was
some
proposal
that,
whether
or
not,
if
should
or
should
not,
for
example,
collect
rent
from
contracts
or
from
accounts,
and
it's
an
interesting
concept
that
if,
if
were
to
go
down
the
rent
approach
and
all
of
a
sudden,
you
don't
need
to
clean
up
best
accounts
anymore,
because
all
these
accounts
will
eventually
run
out
of
front
and
get
deleted
anyway.
Now
this
is
obviously
a
completely
different
discussion.
C
H
Its
contract,
so
it
might
encourage
people
to
either
create
wallets
that
they
didn't
necessarily
need
to
hold
small
amount
of
money
or
to
use
wrapped
F
as
a
token
which,
in
the
end,
might
even
use
more
disk
space
and
not
necessarily
bring
rain.
So
it
might
encourage
behaviors
that
they
might
make
people
use
even
more
disk
space,
but
those
that
this
space
is
in
contracts
not
in
accounts.
C
B
Think
it's
interesting
to
note
from
opposed
to
the
graph
that
Alexei
posted,
that
there
are
10
million
accounts
with
balanced
cero,
so
I'm
guessing
they're
not
count
as
I'm
Turkish
have
nonzero
norms
right
so
I
mean
if
we
changed
emptiness
I
mean
we
could
basically
set
the
threshold
at
zero
instead
of
420
shabbat.
We
wanted
to
oh.
B
C
B
C
B
H
B
A
Cool,
so
Ebates
59
was
created
by
vitalik
as
an
update
to
one
of
his
previous
eeap's
about
account
abstraction
that
eep
was
a
culmination
of
ideas,
or
my
understanding
is
that
it
is
updated
based
on
feedback.
He
got
from
an
eighth
Research
Forum,
so
right
now
account
abstraction
is
still
up
in
the
air.
There's
people
who
are
very
in
favor
of
account
abstraction
just
because
they
don't
see
the
point
of
having
a
whole
hard
fork
for
minimal
changes
and
that
that
something
this
important
should
go
in.
I
B
B
C
Think
in
more
in
general,
the
entire
community
and
ecosystem
would
prefer
this
abstraction,
because
all
of
a
sudden,
then
you
can
do
a
lot
of
stuff
that
are
currently
not
necessarily
impossible,
but
really
really
hard,
for
example,
to
have
a
contract
pay
for
its
own
fees.
Currently,
you
can
only
do
that
if
you
have
some
specialist
set
up
to
the
mining
pool,
etc,
and
this
would
actually
make
that
possible,
which
immediately
would
make
a
lot
of
applications
possible.
I.
A
C
But
those
so
that
those
who
are
fairly
easy
but
retirement
currently
is
that
account
obstructionist
officer
is
a
lot
of
work,
probably
and
a
lot
of
things
to
test,
and
the
same
goes
for
for
the
scaling
solutions.
So
I
think
it
would
be
nice
to
figure
out
whether
we
want
the
next
hard
work
to
focus
on
scaling
or
to
focus
on
account,
distraction
and
stick
to
it.
So
mine
doesn't
matter
the.
A
Thing
is,
though,
that
there's
no
e
IP
right
now,
so,
basically
there's
no
scaling
solution.
That's
an
e
IP
right
now
until
sharding,
which
would
be
beyond
the
constantinople,
hard
fork.
So
I
guess
I'm,
not
sure
what
you're
referring
to
when
you
say,
focus
on
either
scaling
or
this
for
the
next
hard
fork.
C
And
my
suggestion
would
be
that
if
you
want,
we
should
either
focus
on,
for
example,
getting
the
account
abstraction
done
for
the
next
hard
fork
and
do
something
with
it.
Or
if
we
decide
that
we
want
to
push
Casper,
then
maybe
you
should
put
focus
on
that
front
and
half
and
ship
it
as
fast
as
possible.
Instead
of
getting
lost
between
both
changes.
I.
B
Yes
and
now,
because
now
we're
talking
about
different
types
are
count
abstraction,
the
one
you're
talking
about
it's
886
and
that
was
even
more
complex
because
it
and
I'd
allowed
stuff
like
paying
for
your
transaction
with
the
RC,
20
tokens
or
whatever's.
This
is
a
different
variant
and
that's
also
good
to
be
aware
of
it.
I
mean
if
the
community
wants
account
abstraction.
It
should
be
aware
that
this
proposal
does
not
include
paying
with
their
random
things.
B
You
need
to
pay
with
the
ether,
but
essentially
the
previous
proposal
was
binned,
and
one
of
the
reasons
it
was
bent
was
that
you
could
do
a
reorg
attack
where
someone
created
its
own
multi-sig
of
them.
Malicious
miner
did
the
reorg
and
suddenly
someone
else
owned
that
accept
contract
and
I.
Think
this
proposal
does
not
suffer
from
that,
and
because
a
cost
structure,
yeah.
I
H
Opinion
is
I
think
that
the
the
italics
proposing
is
important
and
I.
Think
a
lot
of
a
lot
of
developers
are
waiting
for
some
kind
of
distraction.
But
my
opinion
is
that
the
way
it
is
described,
it's
very
technical
when
it's
very
and
it
makes
it
hard
for
outsiders
to
contribute.
So
maybe
if
someone
could
try
to
try
to
do
a
write
up
on
it
and
try
to
get
more
require
more
feedback
from
just
like
normal.
C
I'm
a
bit
unsure
about
that
at
the
current
point,
I
mean
it's
always
nice
to
together
community
feedback,
but
I
think
that
was
one
of
the
biggest
issues
with
the
originally
acted
is
say
that
everybody
wanted
it
everybody
liked
it
just
nobody
from
the
client
developer
teams
actually
put
the
effort
in
to
implement
it,
and
then
after
it
was
everyone
thing
was
said
and
done,
and
we
figured
that
yeah.
We
should
definitely
implement
it.
It
turned
out
that
it's,
it's
really
really
messy.
A
Yeah,
suffice
to
say
that
one
is
at
this
point
not
officially
going
into
Constantinople
and
means
a
lot
more
discussion
all
right.
The
last
agenda
topic
is
client
and
research
updates.
So
let
me
go
ahead
and
go
to
the
list
of
clients,
so
the
first
one
will
go
with
death.
Have
any
updates
or
things
you
want
to
announce.
C
A
K
Not
much
updates
from
parodies
right
now
we
have
security
audit
incoming.
We
just
published
a
blog
post
this
morning,
yeah
we
started
to
improve
the
light
client,
it's
really
overdue
and
last,
but
at
least
might
be
worse
to
mention
that
our
next
release
will
come
without
any
wallet,
interface
and
user
interface.
K
I
N
Are
trying
to
test
and
debug
all?
It
is
done
so
far,
but
the
problem
is
that
we
can't
connect
with
the
payee
tab
so
trying
to
solve
the
problems
with
PI
as
its
that's
it
for
Casper
and
working
on
performance
improvements
still
working
on
that
and
I
can
say
that
we
have
a
stable
version,
which
is
just
a
reminder
that
we
have
a
problem
with
the
too
long
database
flash
and
we
now
have
a
table
working
where
database
flash
a
hundred
times
faster
than
in
the
version
which
we
have
in
the
master
branch.
N
E
L
Yes,
so
basically,
the
most
of
the
development
happen
in
the
in
the
VM
implementation,
and
there
was
a
major
release
made
last
week,
which
was
the
the
only
release
made
since
the
Byzantium
heart
fork,
and
this
one
fixes
a
lot
of
different
things.
Some
of
the
changes
started
out
as
performance
increase
changes,
but
they
ended
up
being.
They
ended
up
cleaning
up
the
code
significantly.
It
should
be
much
easier
to
understand.
L
What's
going
on,
it
did
fix
a
lot
of
potential
consensus
bugs
on
certain
edge
cases
mm-hmm
and
it
fixed
a
couple
of
other
issues
which
have
been
experienced
by
truffle,
so
contract
testing
should
be
under
certain
circumstances,
should
be
much
easier
and
they're
better.
With
this
release
and
after
the
release,
there
was
some
work
on
running
code
coverage
test
code
coverage
reports
are
while
running
the
state
tests
and
doing
that
we
have
found
I
think
a
list
of
like
ten
different
items
where
we
believed
that
the
tests
weren't
covering
certain
edge
cases.
L
L
So
we
did
an
update
to
the
latest
version
of
the
state
test,
repo,
which
was
hard
to
figure
out
what
what
is
the
actual
latest
version
of
it,
and
what
is
the
latest
stable
version
of
it
and
it
seemed
like
the
information
we
got
from
uhé
and
Dimitri
is
whatever
version
used
by
cpp.
Terrarium
is
the
latest
version
of
the
state
tests,
so
we
have
updated
to
that
version
and
the
VM
isn't
isn't
successfully
passing
all
of
them,
so
work
is
being
done
and
fixing
those
issues
now
and
after
those
are
fixed.
J
Yes,
so
I'm
currently
dealing
with
fixing
all
the
tests
that
exist
in
the
tree,
so
before
probably
many
charts,
some
more
and
also
I'm
running
the
tests
on
how
does
it
behave
on
hard
drive,
I
think
at
the
moment
it's
pretty
promising.
It's
actually
no
difference
to
the
speed
with
SSD,
but
I
still
have
to
test
it
through
this
pound
box,
which
is
gonna,
be
very
interesting
and
yeah.
So
I
don't
know
when
the
this
whole
thing
is
gonna
be
stable
enough.
But
yes,
it's!
The
work
is
going
on.
A
I
I
Kind
of
a
discussion
we
had
on
the
last
meeting
about
the
phases
and
the
stages
I
think
there's
a
little
bit
of
a
little
bit
of
confusion
here
about
some
of
the
terminology
and,
and
there
been
a
little
bit
misrepresentation
and
the
part
of
some
some
media,
or
something
about
it
being
a
bit
further
along
then
than
it
actually
is,
and
so
I
think
just
that
we're
still
kind
of
it's
still
kind
of
quite
early.
But
but
things
are
going
well,
that's,
yes,
I!
That's
all
I
have
on
the
research
side.
A
Was
talking
and
I
was
on
mute,
I'm,
saying
I
was
saying
yeah.
There
was
some
confusion
from
a
coin
desk
article,
but
there
are
some
some
people
trying
to
clear
that
up
and
some
of
the
reddit
threads
so
I
think
that's
that's
passed,
but
in
the
future
we
can
try
to
be
more
definitive
with
some
media
outlets
about
what
what
stage
were
at
with
that
so
yeah
thanks.
Yes,.
A
I
It
so
I
one
other
thing
came
to
mind.
It
may
be
worth
mentioning
as
well
that
I
I
also
understand
that
there's
a
little
bit
of
trouble,
as
was
discussed
last
time,
getting
some
of
the
Casper
tests
and
stuff
working
on
piyah,
theorem
and
Piper.
You
may
be
able
to
speak
to
this
a
bit
better
than
I
can,
but
if
any
point
it
would
be
possible
to
move
that
stuff
over
2pi
EVM
I
know
we're
kind
of
not
there.
I
E
Something
that
we're
like
basically
validating
and
part
of
the
basically
we're
working
on
validating
that
we
can
sustain
a
healthy
network
using
the
Trinity
networking
code.
And
if
that
turns
out
to
be
the
case,
and
we
can
validate
that
base
assumption
that
I
think
that
the
Kasper
research
is
going
to
migrate
over.
But
we
want
to
validate
that
initial
assumption.
First,
to
make
sure
that
we
don't
do
the
migration
work
and
then
have
the
same
problems.
A
C
C
No
just
asking
that
if
you
are
using
a
yes
well
for
one
thing,
Elias
one
will
probably
we
did
release
soon,
so
the
front
don't
use
that
one
as
for
Elias
to
if
you
have
actually
a
client
running
or
the
usable
I
would
really
appreciate.
If
we,
if
you
could
sum
us
and
usage
issues
or
anything
that
you
see
to
happen,
absolutely.
C
C
J
So
at
the
moment
it's
the
numbers
are
kind
of
unrealistic
so
because
they
do
require
you
to
have
a
huge
amount
of
memory.
However,
I
do
I'm
doing
some
testing
with
the
realistic
mods
memory
and
there
I'll
publish
them
later
because
yeah
so
I
agree.
This
is
this
is
unrealistic
thing,
although
I
mean
we'll
see
we'll
see
how
it
goes.
I
think
it
won't
be
too
too
far
ahead
so
far
off
from
the
current
numbers,
but
I
will
publish
when
I
have
them
mm-hmm.
C
Now
I'm
gonna
curious
about
that
one,
because
I've
had
a
lot
of
the
optimization
on
the
idea
that
you
had
two
really
nice.
Just
is
this
memory
footprint
really
scared
me
because
I
didn't
see
it
as
scalable,
but
if
you
are
actually
working
on
on
pulling
those
numbers
down,
then
I'm
really
curious.
Yes,.