►
From YouTube: Ethereum Core Devs Meeting #26 [10/6/2017]
Description
A
A
D
A
A
Okay,
he'll
probably
be
back
so
I,
don't
think
I
think
we'll
just
get
to
testing.
Whenever
KC
comes
back,
let's
see,
who
else
do
we
have
okay,
the
test
net
launch?
As
far
as
we
know,
things
are
still
going:
okay
on
tests
net.
Has
anyone
put
anything
else
on
the
tests
net,
that
tests
out
any
of
the
new
features
or
anything
like
that
that
are
coming
to
Metropolis
so
that
we
can
see
how
clients
react?
I.
E
A
A
And
yeah,
if
you
do
that,
just
let
us
know
when
you
push
that,
because
once
you
do,
we
want
to
have
all
the
clients
listening
in
or
that
I
guess
the
testers
looking
at
the
clients
and
seeing
if
there's
any
abnormalities
once
the
transaction
is
pushed
so
it'd
be
perfect.
If
you
can
or
like
just
let
us
know
the
transaction
that
you
pushed
it
to
or
any
other
information.
F
A
G
A
A
C
C
A
Great
always
perfect,
so,
and
actually,
if
there's,
is
there
any
more
updates
to
testing,
because
if
not
we'll
get
into
the
clients,
and
actually
with
this
for
every
client
I
go
through,
can
you
let
me
know
if
you
are
going
to
have
a
client
released
by
the
17th
that
would
be
compatible
with
metropolis
I
mean
I
already
know
a
few
of
you
or
either
have
or
will
but
I
guess
I
just
want
to
know
what
which
ones
will
be
ready
and
which
ones
won't
officially.
So,
let's
see
was
there
anything
else?
A
G
I
C
A
J
A
So
there's
basically
a
release
or
a
download
that
is
compatible
with
Byzantium.
That
has
the
block
number
and
everything
yes,
okay,
great
you
know,
Ichi
I
know
you
put
the
yellow
paper
changes
and
I
saw
that
Gavin
merge
some
changes
lately,
so
has
there
been
plans
or
communication
for
yellow
paper
update,
that's
not
as
necessary
that
I'm
just
more
wondering.
D
E
K
E
E
A
A
Okay,
great
yeah,
Part
D
was
make
sure
clients
are
ready
for
the
hard
for
and
then,
let's
see,
there's
only
two
other
ones.
One
of
them
was
one
that
Christian
wanted
to
discuss,
but
I
know
he's
gonna
be
a
little
late,
so
we
can
kind
of
start
that
discussion
and
then
recap
it
with
him
a
little
bit
or
just
I
can
do
notes
for
him
later.
This
is
about
account
abstraction,
so
let
me
make
sure
I'm
understanding
account.
Abstraction
was
actually
gonna,
be
an
EIP
86
right
or
this
the
the
start
of
it.
Okay.
E
I
think
so
there
were
a
couple
of
issues
right,
so
one
of
them
is
that
it
was
just
just
figuring
out
what
the
minimal
kind
of
combined
your
acceptance
strategy
would
be,
and
what
really
the
minimal
thing
to
do
would
be
to
just
roll
it
out
as
a
hearth
work
and
have
no
liner
acceptance
strategy.
Initially,
except
you
know
it.
Presumably
we
loved
contact
one
liner
and
just
ask
them
to
make
some
kind
of
just
like
make
some
kind
of
text
box
or
people
really
want
to
submit
transactions.
E
E
One
of
them
in
years,
so
this
issue
that
you
have
the
support
transactions
like
production
with
the
exact
same,
have
to
be
included.
Place,
which
is,
are
you
theoretically?
It
does
break
in
invariance,
though
it
does
so
at
the
call
and
I
think
as
I
might
have
said
before,
with
the
benefit
of
introducing
this
other
invariant,
which
is
a
purple
initi
of
a
block,
is
no
is
a
no
longer
it's
the
dependent
at
all.
E
So
that
was
one
of
the
challenges
and
then
the
other
challenge
has
to
do
with
things
like
efficiency.
So
basically
it
is
like.
We
don't
really
want
you.
It
really
wants
to
have
an
extra
two
or
three
hundred
bytes
so
lying
around
for
every
account,
and
you
know
what
that
turn
into
this
being
even
being
even
more
state
float.
I
mean
there
for
the
transaction
hash
issue.
E
Inclined
to
say
that's
more
something
for
the:
if
developers
say
that
that's
really
hard
to
handle,
then
we
can
try
to
work
around
it,
although
my
personal
preference
is,
that
is
to
try
to
move
toward
something
like
that,
eventually,
the
as
for
the
other
part
to
do
with
efficiency,
go
as
there
might
be
some
other
Yankees
that
could
be
included
at
the
same
time.
That
would
make
the
sort
of
thing
easier.
That's
it's.
E
Here
we
go
there.
Okay,
so
basically
issue
money,
fission,
see,
issue
two
minor
exception
strategies
issue
three
transaction
double
inclusion
issue
for
accounts
creation,
so
if
those
are
probably
the
main
barriers
that
I
think
that
I
see
so
hard
and
at
this
point
that
I
think
it's
still
worth
kind
of,
we
thinking
a
bit
more
and
actually
might
like
personally
I
would
even
say
that
at
this
point,
give
him
the
I'm
gonna
get
fairly
a
strip
given
the
level
of
just
difficult
evil.
But
seeing
you
happy
is,
in
general,
a
thank
you.
M
Yeah
I
mean
I
agree
with
a
prioritization,
but
the
parallelization,
the
EVM
performance
is
definitely
something
that
could
try
to
have
the
you
know
if
you
actually
try
to
get.
If
you
use
the,
if
you
ever
use
the
chain
for
anything
non-trivial
like
I,
don't
want
to
like
this
likes
your
stuff
and
they
and
it's
like,
starts
thinking
I'm
more
than
happens,
every
clinical
blog
face.
M
M
E
Let
me
see
if
I
can
just
peace
to
those
in
here
now
and
basically
because
I
feel,
like
especially,
was
the
increasing
amount
of
usage
that
we
have
so
far.
We
probably
have
a
huge
amount
of
dust
that
could
be
cleared
out
and
implementing
these
two
could
possible.
You
know,
and
we
could
try
to
measure
how
much
it
would
reduce
the
state
size,
but
I
have
a
feeling
it
would
be
by
a
fairly
substantial
amount.
H
Regarding
the
dust
accounts,
one
interesting
question
is
so:
if
we
kind
of
assume
that
dust
accounts
can
be
completely
deleted,
meaning
nonce
balance
everything,
then,
if
I
recreate
that
account
a
bit
later,
it
means
that
I
can
recreate
the
same
transactions
with
the
same
hashes
and
everything
and
those
will
actually
appear
multiple
times
in
the
chain.
Well,.
A
E
A
E
H
Just
wanted
to
give
an
example
that,
for
example,
one
way
that
dust
accounts
got
left
in
the
system
is
that
if
you
want
to
transfer,
if
you
want
to
sweep
a
walnut
contract,
basically
it's
impossible
to
sweep
it
because
the
outer
cold
to
just
send
it
through
somebody
else
will
retain
a
bit
of
gas.
That's
that
will
never
be
freedom.
A
M
Yeah
I
think
I
think
it's
also
worth
mentioning
it's
important
to
have
this
kind
of
mechanic
because
you
know
like
if,
whenever
like
with
Matt,
was
a
Miss
Fork.
If
people
actually
start
using
ring
contracts,
you
know
that
will
create
a
ton
of
got
ten
of
these
dust
accounts,
because
you
know
the
the
ring
contract
has
slightly
different
gas
usage
just
because
of
how
the
curve
operations
work
and
the
hash
to
lift
the
curve
point
so
yeah
it
alarms,
generating
contest,
accounts.
A
Christian
I
just
saw
you
joined,
we're
talking
about
item
2,
which
is
account
abstraction
and
metallic
posted
a
link
in
the
core
dev
chat
and
Peter
reposted
it
in
this
chat
that
kind
of
goes
through.
Some
of
the
abstraction
of
proposed
proposals
for
metallic
and
Matthew
metallic
talked
a
little
bit
about
what
to
make
priority
earlier.
So
yeah
did
you
have
any
thoughts
christian
specifically
and
if
they've
already
been
discussed,
we
can
just
kind
of
recap
them.
A
No
problem
yeah,
no,
this
was
just
posted
I.
You
had
just
posted
before
the
account
abstraction
discussion
and
it
said
I
think
we
should
slowly
bring
up
account
abstraction
again.
How
did
tool
sets
providers
think
about
it
and
do
we
find
solutions
that
are
better
in
the
meantime
and
tool
set
providers?
That's
just
like
developers
right.
L
A
A
A
O
So
just
reminder
from
last
court
of
call:
we
mentioned
that
there
will
be
difficult
to
adjustments
tests
which
we
can
turn
into
block
chain
tests,
but
they
live
now
and
have
a
blast.
Couple
weeks
lived
under
basic
tests
in
the
tempest
polar
and
they
have
been
regenerated
purpose
on
film
since
we
came
to
black
box
testing
on
them.
Each
time
needs
to
manually
put
them
into
whatever
test
harness
they're
using
so
GAF
has
certain
over
to
param
death
I
have
no
idea
status
for
a
third
day
and
therapy
yeah
just
shuts
up
about
that.
O
G
It's
yeah
I
must
not
have
the
sub-module
update
yeah.
Are
these
like
lots
of
randomly
generated
test
cases
like?
Would
it
be
a
problem
if
we
were
to
transpose
these
as
unit
tests
and
our
implementation,
or
do
you
think
it's
better
if
we
draw
them
from
the
sub
module
they'd
be
subject
to
change
very
often
I,
don't.
O
O
C
O
C
O
C
A
O
A
A
A
B
There
is,
if
you
have
like
two
strings
and
you
could
encode
it
at
least
in
two
different
ways,
and
it
would
result
in
the
same
decoded
data
also
caps
could
be
included
in
the
encoding,
so
they're
infinite
number
of
different
ways
to
encode
any
of
those
and
notice
came
up
as
a
concern
if
he
would
wanted
to
use
a
bi
encoding
input
in
pre
compiles.
Such
discussions
were
on
the
Blake
and
the
one
of
the
paring
discussions,
and
so
the
proposal
is
to.
B
Well,
basically,
use
a
define,
a
string,
constrictor
encoding
and
enforce
the
shrinker
encoding
in
if
it's
used
in
pecan
pies.
And
thirdly,
we
could
try
to
enforce
it
for
contracts
and
that
fair,
it
really
depends
on
I.
Guess
it's
not
really
part
of
the
EVM.
It
really
depends
on
language
designers,
whether
they
would
want
to
enforce
it
or
not,
but
we
could
definitely
enforce
solidity
to
only
output,
strict,
encoded
ABI,
which
probably
is
already
the
case,
and
it
could
have
a
mode
that
it
rejects
anything
which
is
anything
good.
It's
strictly
now.
B
O
So
yeah
I
have
a
question
on
the
comment
and
the
comment
is
that
I
think
it
would
be
really
good
to
Rick
picked
up
a
bit,
so
he
can
puts
up
a
wrap
around
the
offset
with
a
minus
1,
integer
and
stuff
like
that,
which
you
can't
today
I
mean
dynamic
right.
But
the
question
is
backwards.
Compatibility
if
there
has
been
like
serpent
versus
solidity
calling
contracts
and
they
have
used
different
ways
to
encode
the
same
content
and
yeah
take
advantage
such
issues.
B
Yeah
I
think
the
main
steps
we
could
take
is
actually
collect
all
those
cases
which
we
would
like
to
restrict
and
define
a
test
suite,
and
we
could
definitely
enforce
the
stricter
rules
for
the
new
pre-compiled.
If
you
choose
to
use
a
bi
encoding
for
them
and
we
could
definitely
enforce
maybe
solidity
to
encode
the
stricter
mode.
But
the
question
that
comes
in
for
the
inputs
for
solidity
contracts
or
serpent
contract
sifters
that
there
would
be
any
any
gold
usage
which
would
use
non-strict.
A
B
is
so.
L
Solidity
has
always
used
the
what
you
cost-effective
mode.
I
mean
it's
just
the
specification
itself
already
only
allows
a
strict
mode,
but
decoders
have
always
been
implemented
in
a
way
which
is
more
flexible,
so
by
just
taking
the
the
pointer
as
a
pointer
I
mean
enforcing
strict
mode
in
a
decoder
that
that's
a
certain
trade-off,
because
it
will
remove
or
destroy
one
of
the
performance
guarantees
that
the
ABI
encoding
has.
L
Maybe
that
accessing
a
single
element
in
this
encoded
structure
only
requires
as
many
lookups
as
this
element
is
deep
inside
structure,
and
if
you
want
to
yeah,
basically
check
the
validity
of
the
encoding.
You
need
to
access
a
lot
more.
Having
said
that,
of
course,
the
solidity
decoder
in
most
of
the
cases
does
a
full
decoding,
and
this
doesn't
make
use
of
this
property
anyway.
E
So
my
under
reading
this
VIP,
it
seems
like
one
thing
that
was
mentioned
his
preaching
miles
because,
like
that's
something
that
everyone
has
their
validate
in
the
exact
same
way,
although
the
thing
that
I
would
reply
to
that
is
that
so
far
look
we
do
not
have
even
a
single
precompile,
that's
actually
defined
in
history.
Now,
in
terms
of
accepting
inputs
in
the
EBI
format,
look
we
basically
take
care
to
define
in
the
end
the
way
every
pre-compile
accepts
input
exception,
but
all
just
very
explicitly
with
that.
E
E
E
Necessarily
one
of
those
cases.
You
know
there
might
be
mine,
there
might
be
more
spooky
or
encoding
so
like,
for
example,
bear.
But
you
have
to
a
point
like
if
you
have
to
variable
length,
numbers
and
or
two
variable
length
values
in
the
API
and
then
they,
the
pointers
both
point
to
the
same
thing
or
the
pointer
is
point
to
memory.
Basically,
that
memory
slices
that
all
of
that
overlap
each
other
or
intersect
each
other
surround
each
other
or
whatever
and.
L
So
I
agree
that
the
the
pre-compile
is
an
issue
and
we
should
probably
enforce
just
the
encoding
exactly
as
specified
the
other
risk.
I
mean
this
is
stuff.
Intersecting
yeah
I
mean
that
that
might
be
an
issue,
but
I
mean
one
thing.
I
see
is
I
mean
it
is
not
a
badge
active
encoding
right.
So
one
thing
that
might
be
dangerous
is
that
people
think
that
the
hash
of
MS,
tudi
theta
is
unique
for
for
the
data.
L
E
And
in
fiber
there's
no
chance
in
hell
I'm
going
to
expose
MSG
today
so
yeah.
If
you
general,
it
seemed
like
if
you
wants
to
know,
if
there's,
if
you
want
to
be
secure
with
this
sort
of
thing,
you
know
the
thing
that
probably
makes
sense
this,
which
try
to
just
make
a
tuple
explicitly.
You
know,
use.
A
I
So
I'm
preparing
a
full
test,
regeneration,
I've
added
a
new
feature,
so
we
could
not
check
that
every
test
that
we
have
is
actually
updated
with
the
test
filler.
So
now
test
has
a
hash
of
the
filler
and
one
was
updates.
One
of
the
reason
updates
was
that
me
now
check
that
there
are
no
tests
without
fillers,
so
overly
removed
some
of
the
outdated
tests
from
the
repository
and
right
now,
I'm
preparing
this
food
test
regeneration.
This
will
include
all
the
high
test,
regeneration
and
I
didn't
see.
Test
update
using
C
test
tool.
I
K
N
K
K
Yes,
I
just
wanted
to
make
sure
that
it's
there,
and
maybe
we
if
we
can
find
someone
from
either
scan
to
kind
of
update
the
UI
of
feathers,
can
if
it
detects
that
the
transaction
receipt
has
zero,
because
right
now
in
the
robson,
for
example,
it
doesn't
do
that
and
all
of
transactions
that
even
very
vertically
appear
to
be
successful
and
for
non-technical
users.
That
could
be
a
problem
because
they
would
see
a
Thurston
and
they
would
think
everything
is
fine.
While
actually
there
was
a
reverse
I
see.
A
A
F
A
Cool
all
right,
anybody
else
have
comments,
cool
last
thing,
EW,
merging
and
updates.
So
there
were
a
few
things,
including
snappy
compression
and
what
else
all
of
the
ENS,
ERC's
and
I
think
something
that
Alex
put
in
lately.
The
designated
Valdivia
instruction,
basically,
a
bunch
of
a
IPs
and
ERC's,
had
not
been
put
in
the
finalized
di
peas
table,
so
I
fixed
that
if
you
all
want
to
go
to
the
link,
if
I'm
missing
one
or
if
you
guys
have
an
EIP
or
ERC,
that's
been
approved.
But
it's
stuck
just.
A
A
A
G
H
Yeah,
so
felix
has
been
working
on
for
the
past.
Maybe
two
weeks
basically
is
focusing
on
on
the
discovery.
B5
it's
going
to
be
his
topic
for
Def
Con
and
he's
actually
hoping
that
he
can
prepare
all
the
documentation
for
Def
Con,
and
then
we
can
have
a
phase
discussion
at
Def,
Con
to
just
iron
out
all
the
bugs
and
stuff
like
that.
So
I'm
I'm,
not
sure.
Are
you
Artie
people
coming
to
Def
Con,
because
it
will
really
help
if
you
could
just
sit
down
on
a
table
and
just
have
a
discussion.
Yeah.
G
A
B
A
Four
five
I
see
okay
and
what
was
the
one
you
said
at
first
I'm,
just
trying
to
save
these
at
171
said
yep
it's
in
there
twice.
Okay,
thanks!
So
much
I
will
definitely
fix
that.
Oh
it's
finalized,
but
it's
okay!
That's
gonna!
Be
coming
in
to
Constantinople!
That's
right!
Perfect!
Okay!
I'll!
Take
note
of
that,
so
the
hard
fork
is
going
to
be
coming
up
before
the
next
core
dev
meeting.
The
next
coordinate
meetings
on
the
20th
and
the
hard
fork
is
on
the
17th
or
roughly
around
that
time
is
that
said.