►
From YouTube: Ethereum Core Devs Meeting #27 [10/20/2017]
Description
A
A
Okay,
I
think
we're
gonna
go
ahead
and
start:
let's
do
a
test.
Someone
from
the
stream
talked
up
that
didn't
work.
Let
me
try
this
again:
okay,
great
we're
working
perfect,
all
right
so
to
the
agenda.
What
do
we
got
here
so,
instead
of
the
fork
review
going?
First,
let's
do
testing
first
cuz,
then
from
there
we
can
talk
about
the
review.
So
if
Martin
or
Casey,
could
you
go
over
because
there's
kind
of
some
confusion
amongst
people,
the
two
types
of
fuzzers
that
we're
using
if
we're?
B
Okay,
so
yes,
we
have.
There
are
two
different
tracks
on
the
post
testing
and
the
one
we
start
with
earliest
was
based
on
tests
of
generating
random
state
test,
and
then
we
use
that
to
execute
in
pi-theorem
cpp
parity
yeah,
and
then
we
compare
the
outputs
after
every
operation
because
with
there
have
been
modifications
made
to
the
clients
or
actually
to
the
raw
ibm's,
so
that
for
each
instruction
made
it
outputs,
JSON
blob
with
the
internal
state,
respect
remembering
so
forth.
B
And
yes,
we
just
do
that,
run
them
and
compare
out
that
notifies
of
everything
and
differs
and
that
enable
us
to
find
changes
that
might
not
have
been
consensus.
Necessarily
there,
it's
only
a
different
memory,
but
which
could
become
consensus
issues
a
lot,
the
first
approach,
it's
that
one's
pretty
slow
right.
Now,
it's
using
docker
containers
for
everything,
I'm
working
right
now
and
grew
up
in
your
own
that
died
in
your
system.
B
C
B
Earlier
written
process
for
a
Bitcoin
and
yeah
a
lot
of
stuff
and
it
is
using
instrumental
versions
of
gap
and
parity
where
it's
instrumented
them
to
master
code
coverage,
basically
so
live
constant
based
approach
is
that
the
input
is
guided
by
the
coverage.
So
it
makes
multiplication
so
it
sees
it
gets
better
path
coverage
from
anyway
important
and
it
kind
of
makes
better
and
better
inputs
to
get
really
good
coverage,
and
it
also
checks
for
minor
discrepancies
in
the
execution.
B
A
B
Not
that
long,
a
couple
of
weeks
we've
been
women,
basically
messing
with
the
higher
the
testifed
base
faster
since
before
the
summer,
but
there's
been
a
lot
of
work,
I'm
getting
all
the
courts
ironed
out
from
the
EVM
binaries
and
getting
the
and
the
individual
I
outputs
to
align,
because
there
are
differences
to
the
implementations.
Okay,
yeah,
okay,.
A
Great
so
that
yeah
that's
that's
kind
of
what
I
thought
and
I
think
I
think
we're
getting
donated
some
server
resources
soon,
so
that
should
help
take
the
load
off
and
so
that
that's
gonna
help
a
little
bit
so
yeah
any
other
comments
on
testing
and,
like
you
were
saying,
we're
just
improving
on
that
more
adding
more
servers.
Many
other
comments
from
you
or
Casey,
or
anybody.
D
E
E
At
the
end
of
the
of
the
tests,
and
since
state
tests
only
check
the
state
route,
they
don't
compare
the
the
traces,
the
execution
traces
in
order
to
convert
in
order
to
create
state
tests
from
bugs
at
the
buzzer
fines
they
have
to
be
manually
created
so
that
it
so
that
the
bug
ends
up
with
a
different
state
route,
and
so
that
still
needs
to
be
done.
For
for
the
bugs
that
it's
found.
A
Okay,
interesting
great,
so
it
sounds
like
we're
still
in
progress
on
some
of
those
things,
and
let
us
know
if
you
guys
needs
more
support
on
that.
If
we
can
call
in
people
from
other
teams
or
from
the
community
again
to
kind
of
help
with
some
of
that,
especially
the
manual
cases,
because
I
don't
know
how
many
volunteers
are
still
actively
working
on
that.
Since
the
last
time,
we
did
a
call
for
participation.
D
A
I
see
so
they're
not
urgent,
because
we've
already
fixed
the
one
they've
been
found
in
a
different
suite
and
we've
already
fixed
it
just
for
future
clients
and
stuff.
Okay,
so
yeah.
If
there's
anything
else
with
the
testing,
I'm
gonna
go
ahead
to
item
two.
If
you
want
to
refresh
your
agendas,
I
just
kind
of
updated
it
to
put
things
in
order,
so
this
is
just
a
review
of
the
Byzantium
fork,
so
just
kind
of
a
verbal
review
I
think
it
was
three
or
four
days
before
we
had
the
Byzantium
fork.
A
We
had
some
one
emergency
emergency
patch
with
parity.
We
had
a
few
more
in
the
days
following
I,
think
two
more
and
then
we
had
a
and
those
were
consensus
bugs
for
those
three
to
four
patches
and
then
the
day
before
or
two
days
before,
we
had
a
guest
denial
of
service
bug
that
would
have
taken
nodes,
offline,
the
1.7.1
notes
and
then
so
a
1.7.2
note
was
released
and
then,
in
the
case
of
parody,
they
released
one
point,
seven
point:
six,
which
was
bug
free
and
Byzantium
compatible.
They
also
then
released
one
point.
F
F
F
A
So
yeah,
so
that
was
kind
of
the
build
up
to
it
and
there
we
kind
of
got
some
feedback
from
the
community
and
from
Bitcoin
maximalist
and
people
who
hate
us
that
we
were
putting
out
a
ton
of
fixes
beforehand.
But
in
my
estimation
or
I
guess
my
opinion,
I
would
say
that,
because
of
the
way
we
were
running
the
fuzzers,
this
was
kind
of
not
even
expected,
but
this
is
something
that
definitely
could
have
happened
and
it
did
so
I.
Don't
really
feel
that
badly
that
we
had
some
releases
right
beforehand.
I
think
it's!
A
It's
not
good,
but
like
it's
better
to
do
that
than
to
you
know,
ignore
fuzzers
or
to
ignore
test
cases
so
that
that's
kind
of
where
I
am
on
this
granted
I
think
in
the
future.
We
should
definitely
have
some
provisions
to
run
the
fuzzers
for
a
longer
time
before
we
declare
the
hard
fork
in
this
case.
We
wanted
to
somewhat
keep
in
mind
the
block
times
to
make
sure
that
they
didn't
get
too
long
and
that
we
didn't
have
the
hard
fork
around
Devcon,
but
we
could
have
definitely
planned
this
out
better.
G
I
got
the
impression
that
you
know
and
when
I
before
then
suggested
three
weeks,
I
had
the
impression
that,
basically,
literally
two
days
after
the
meeting
on
September
22nd,
we
would
release
the
hard
work
version
and
like
actually
give
people
three
weeks
to
do
the
full
upgrade,
and
yet
somehow
this
just
ended
up
not
happening.
So
that
was
like
yes
in
the
future,
like
I,
would
prefer.
G
A
Okay,
something
else
that
I
heard
a
lot
and
I
know.
Gavin,
went
on
given
word
coin
desk
and
and
did
some
tweets
and
other
things
to
kind
of
argue
the
case
that
the
amount
of
time
between
bugs
before
the
hard
fork
warrant
a
two-week
stoppage,
an
emergency.
Basically,
an
emergency
stop
and
two-week
delay,
at
least
for
the
hard
fork.
C
A
H
I
think
the
ocean.
You
also
need
to
take
into
consideration
what
what
the
emergency
stop
means,
because
if
the
merchants
table
means
releasing
two
three
four
or
however
many
clients
and
convincing
the
entire
ecosystem
to
stop,
then
that's
a
completely
different
ballpark
than
if
the
emergency
stop,
meaning,
maybe
updating
a
contract
to
just
yeah.
A
B
A
H
It's
not
one
way
that
we
could
say
we
could
prevent
too
much
centralization
or
too
much
power
in
a
contract
is
maybe
just
so.
Instead
of
having
a
contract
that
kind
of
directs
when
the
whole
fork
would
happen,
you
basically
would
still
hard-code
the
four
o'clock
in
to
the
client
and
maybe
just
have
a
contract
that
could
just
stop
the
fork,
meaning
that,
basically,
if
the
contract
sugared
before
the
fork,
then
basically
clients
go
on
without
forking,
because
this
way
it's
it's
bit
less
control.
H
A
H
H
B
H
H
So
so,
if
if
there
are
light,
servers
available,
then
sure
but
I'd,
so
all
in
all
we,
the
other
thing
have
to
need
to
be
aware,
is
that
these
should
be
emergency
measures.
So,
for
example,
I
assume
that
if
we
postpone
a
hard
work
that
eventually
all
clients
will
issue
an
update
that
will
remove
the
four
clock
or
change
the
four
block
number.
So
we
only
need
to
have
this
emergency
break.
You'll
need
to
make
it
functional
for
a
few
days
if
there
is
an
emergency,
so
we.
A
Yeah
I
think
that's
a
good
idea.
I
think
that's
something
that
we
could
definitely
do
and
something
else-
and
this
was
actually
brought
up
in
chat,
which
is
another
good
metric-
is
the
like
the
rate
of
new
bugs
like
how
quickly
they
are
discovered
back-to-back.
But
is
that
actually
a
good
measure
of
how
ready
we
are
or
is
that
something
that
happens
very
randomly
because
we're
using
a
fuzzer.
A
A
Okay,
so
we
know
we've
kind
of
gone
over.
You
know
some
of
them
that
some
of
the
measures
that
we
need
to
take
potentially
so
the
contract
is
one
of
them,
something
else
the
metalic
mentioned
was
having
clients
have
like
a
cutoff
day
for
their
releases,
be
a
little
more
strict
about
that,
so
that
we
can
then
have
better
timelines,
for
we
have
X
many
weeks
for
testing.
B
But
what
the
test
Nets
deployment
did
was
force
the
client,
the
implementations
to
actually
include
the
byzantium
code
in
the
master,
which
enabled
us
to
do
fast
testing
and
not
have
to
use
rebase
brushes
on
everything
just
to
be
able
to
get
to
it.
So
I
kind
of
disappointed
in
I.
Don't
think
I,
don't
think
that
chestnut
deployments
give
a
lot
of
interesting
testing
for
consensus
stuff.
B
A
H
C
H
Consensus
tests
are
worthless,
of
course,
so
seeing
how
the
whole
network
behaves,
how
how
peers
start
dropping
off
or
not
dropping
off
when
they
split
different
change.
So,
for
example,
I
remember
in
Olympic
when
we
had
to
change
split
and
the
entire
network
fell
apart,
and
was
it
really
a
pain
in
the
ass
to
merge
it
back
together
and
I
think
that
that
test
networks
are
really
valuable
in
this
respect,.
E
A
F
F
F
A
Okay,
so
Peter
the
gift
team
I
think
in
the
past
has
been
reticent
to
have
a
feature
like
that.
But
what
see
what
you
guys
is
opinion
today
on
having
something
that
is
an
optional
something
kind
of
like
what
miss
does
where
they
have
a
protected
repo
that
has
like
a
file
that
has
the
latest
get
the
latest
get
release
that
they
can
sync
to
missed
from
people
who
download
it.
H
So
the
important
thing
to
know
with
missed
is
that
misty
has
a
user
interface.
So
basically,
when
you
start
mist
and
it
can
just
pop
your
window,
the
do
you
want
to
upgrade
or
not,
and
death,
on
the
other
hand,
is
meant
to
run
in
the
background,
probably
without
before,
possibly
without
even
having
any
user
interface
or
user
interaction
at
all,
and
that
means
that
gap
would
need
kind
of
to
figure
it
out
itself
whether
to
update
or
not,
update,
all
to
update,
and
that
becomes
a
bit
problematic.
I
see.
H
So
I
know
maybe
I
don't
know.
If
people
are
so
people
using
gas
or
art,
I'm
I
would
say
they
are
probably
either
running
mist,
in
which
case
you
do
have
the
auto
update
or
they
are
possibly
running
installs
from
Ubuntu,
BPA's
or
whatever,
in
which
case,
if
auto
updating
again
becomes
a
bit
messy.
How
do
you
update
it?
We
could
basically
download
the
binary
engine
just
switch
over
to
some
newer
binary
when
you
run
the
old
one,
but
I
don't
know
yeah.
A
I
mean
I
would
think
that
if
I
was
like
a
service
running
it,
either
having
a
message
pop
up
like,
along
with
all
the
like,
a
Furion
console
mode,
having
a
message
pop
up
or
having
it
as
a
command-line
option
for
those
who
don't
want
to
who
want
to
know
when
an
updates
happening
and
their
node
can
go
offline,
but
otherwise
they
just
want
it
to
be
up.
So
basically
for
those
subset
of
people,
it's
not
a
huge.
A
It's
not
a
huge
portion
of
people,
running
death,
I
would
say,
but
it's
enough
to
where
that
little
bit
might
help
people
who
cuz,
that
those
are
also
the
same
people
who
would
forget
to
update
in
the
first
place
the
ones
who
have
a
full
node
running,
and
they
just
leave
it
on
all
the
time
and
once
it
goes
offline,
they
just
restart
it
again.
It's
not
like
critical
to
their
infrastructure
or
anything.
Those
kind
of
people
might
be
benefited
by
something
that
actually
warns
their
node
or
stops
their
node
or
things
like
that.
H
Yeah
I
guess
so
for
quite
a
long
time
we
had
a
version
Oracle
and
guess
that
basically
every
hour
or
so
or
whatever
check
the
smart
contract
and
just
reported
if
there
was
a
newer
version
that
you
were
running,
but
it
was
kind
of
annoying
to
always
keep
bumping
the
version
numbers
and
we
didn't
really
see
the
benefit
as
basically
it
was
just
a
log
deep
inside
your
user
logs
and
then
I.
Don't
think
anyone
is
actually
looking
at
their
logs.
H
A
I
mean
like
I,
think
if
it's,
if
it's
a
command
line,
option
I,
think
it
I
mean
even
if
just
one
person
does
it,
what
are
we
at
like
10,000
nodes
or
something
like?
Even
if
just
a
subset
does
it
I
mean,
depending
on
our
growth
and
how
many
nodes
will
be
there
in
the
future,
like
that,
I
mean
it
might,
it
won't
hurt.
I
guess
is
what
I'm
trying
to
say
yeah.
A
A
Yeah,
okay,
so
yeah
yeah.
This
is
something
we'll
discuss
more,
probably
or
you
can
discuss
with
your
team
Peter,
but
yeah.
Just
kind
of
wanted
to
get
people
thinking
and
I
should
actually
also
say
Mikhail
at
the
Java
team.
What
what?
What
about
you
guys?
Do
you
all
have
any
kind
of
plans
or
ideas
around
an
auto
update
mechanism.
I
A
Cool
yeah,
yeah,
cuz,
harmonies,
a
front-end,
so
more
has
a
UI
so
that
that
would
be
really
cool
all
right,
so
we've
kind
of
gone
through
updating
we've
gone
through
some
lessons
learned
and
so
for
the
actual
for
any
future
hard,
Forks
or
major
protocol
updates
that
require
coordination.
I
think
that
we
should
have
an
EIP
in
place
that
designates
things
like
time
between
the
last
bug
found
and
the
hard
fork.
How
long
the
test
net
should
rot,
won't
run
things
like
that
and
so
I
think
Nick
mentioned.
A
He
wanted
to
help
with
that,
and
then
I
can
help
with
that,
I
talked
to
rob
at
ëthe,
Waterloo
and
I
think
he
also
mentioned
that
he'd
be
happy
helping
with
something
like
that.
So
an
Arkadiy.
If
there's
anyone
else
from
the
parity
team,
who
wants
to
feel
free
to
get
them
involved,
I'll
probably
be
starting
on
that
when
I
get
a
free
moment
which
will
might
not
be
before
DEFCON
but
we'll
get
it
done
in
the
next
will
at
least
start
on
it
in
the
next
month.
F
A
C
A
A
A
Okay,
great
the
next
item
on
the
agenda,
core
team
updates,
so
I'll
just
go
through
the
core
teams
and
if
you
have
anything
you
want
to
talk
about
for
parody,
I
know
they
just
had
a
major
release
which
has
a
lot
of
cool
features.
So
they
can
talk
about
that
if
they
want.
If
the
gift
team
has
any
major
fixes
or
releases,
they
want
to
discuss.
Anybody
has
cool
stuff,
we'll
start
with
guests.
A
F
D
A
G
So
we
just
released
a
look,
a
draft
which
is
B
of
the
Kasper
paper
and
I
can
actually
just
publish
that
ain't
in
here
so
like
basically,
theoretically,
a
Casper
may
well
be
at
the
stage
where
we
may
actually
just
wants
to
go
ahead
and
try
doing
it
in
the
doing
for
the
next
fork.
You
know,
even
if
that
sounds
ambitious.
Okay,.
A
A
Function
that
Zuka
wanted
to
put
in
as
well
as
Jaden,
so
we
will
probably
start
collecting
those
in
the
next
few
months.
Probably
PostNet
Khan
is
one
will
really
dive
down
into
that
yep
because
sounds
good.
So
as
far
as
Constantinople
goes,
we
don't
need
a
timeline
today
at
all,
but
if
you
wanted
to
include
the
Casper
and
the
finality
gadget
and
stuff
like
that,
the
first
steps
went.
When
do
you
think
that
would
be
done
or
is
there
any
kind
of
timeline
like
qq2.
G
Yeah
so
there's
a
so
there's
already
a
Python
implementation,
which
is
like
almost
done
well.
There
was
one
that
was
done
for
the
previous
version,
but
this
version
is
simpler
and
Karl
is
in
the
process
of
doing
switching
that
over
and
it
should
be
done.
I
would
even
say
very
soon,
and
the
other
thing
is
that
the
parts
that
aren't
done,
I
would
say,
but
basically
the
parts
that
aren't
done
Erik
find
details
of
the
contract,
and
so
it
like
the
actual
spec
of
the
fork
is
not
going
to
be
particularly
complex.
G
That's
basically
just
add,
add
some
Bal
and
increase
the
Bell
and
some
of
contracts.
Then
I
change,
the
fork,
choice,
rule
and
add
a
couple
of
by
adding
a
couple
of
function
calls
going
into
the
going
into
the
Casper
contract.
So
if
there
was
details,
change,
that's
technically,
it
just
would
not
affect
so
like
what
happened.
The
actual,
like
anything
of
the
clients,
implementation
by
much
okay.
A
Sounds
good,
so
the
next
thing
is
there
any
other
updates
from
anybody
that
they
wanted
to
shout
out
cool.
The
next
agenda
item
was
website
update,
so
some
people
were
discussing
if
there's
going
to
be
a
website
update.
That
website
has
managed
aetherium,
dorgon's
managed
by
the
etherium
foundation
and
there's
been
discussion
to
do
an
update
to
the
website
a
new
theme
and
new
content.
That's
gonna
take
some
time
to
curate,
but
just
so
everyone
knows
that
is
in
progress.
There
is
a
group
coming
together
in
order
to
you
start
to
accomplish
that.
A
A
So
this
is
the
most
important
item.
Obviously
number
one
will
quake
3
work
on
the
latest
operating
systems,
ubuntu
16.04
yeah.
We
will
have
to
check
that
out,
anyways
yeah.
Maybe
you
can
run
in
wine
or
something
anyways
yeah,
that's
kind
of
a
joke
one,
but
for
real,
we'll,
probably
talk
offline
about
getting
a
core
dev
meeting
set
up
or
something
at
at
the
Met
DEFCON.
Maybe
I,
don't
know
if
we'll
have
the
time,
but
if
we
can,
then
we
will.