►
From YouTube: Ethereum Core Devs Meeting #42 [07/13/18]
Description
A
A
Hi
everybody
welcome
I'm
gonna,
pull
up
the
agenda,
but
we
were
just
talking
about.
He
was
them
and
basically
what
was
the
question
someone
had
like?
Should
we
implement
it
before
sharding
and
all
that
stuff
yeah
like?
Should
he
wasn't
be
available
in
Maine
that
somehow
so
is
anyone
from
uoit's
I'm
here
to
like
kind
of
give
an
opinion
I
could
if.
E
C
C
C
C
E
C
C
L
C
C
L
G
G
C
C
C
C
D
C
C
A
That
sounds
good
if
anyone
on
youtubes
hearing
an
echo,
it's
because
I'm
in
a
really
weird
conference
room
where
I'm
not
familiar
with
the
settings
so
sorry
in
advance,
I'm,
just
gonna
try
to
mute
when
we're
not
talking
cool,
so
I
guess
what
came
from
that
is.
You
said
in
two
more
meetings
from
now
acts
if
you're
gonna
have
something.
C
A
A
J
J
D
I
H
On
here,
I'm
here
with
Ben,
you
all
know
and
Matt
Halpern,
one
of
the
quartet's
working
on
Pantheon.
Thanks
for
having
us
to
talk
about
Pantheon
today,
I'm
very
excited
to
announce
that
Pegasus
is
planning
on
releasing
our
Molinet
compatible
with
Pantheon
at
DEFCON
4.
So
some
of
the
details
around
it
are
that
the
client
will
meet
the
requirements
of
a
well
behavior
here,
so
it'll
be
able
to
synchronize
the
entire
chain
through
all
the
hard
Forks,
mind
blocks
and
propagate
pending
transactions.
H
The
client
will
also
be
developer
for
friendly,
supporting
common
app
development
like
truffle
and
web
3
and
deployment
news
cases.
This
also
means
that
the
client
will
support
JSON
RPC
ap
is
used
by
the
popular
clients
such
as
at
net
debug
admin,
but
well
yet
have
technologies
such
as
whisper
or
swarm
as
we're
focusing
on
core
functionality,
robustness
and
modularity
we'll
be
providing
more
information
and
insight
with
what,
where
we're
at
in
the
coming
weeks,
and
we're
also
planning
on
being
more
active
in
the
community,
such
as
providing
feedback
on
the
attorney
reference
tests.
H
H
N
H
H
K
I
L
A
C
H
C
C
G
I
C
C
A
C
A
A
A
I
didn't
I,
didn't
see
anybody
I
didn't
see
anyone
from
aetherium
j/s
either.
Is
there
anyone
from
mist
here.
I
D
I
D
A
A
A
Nice,
okay,
so
for
research,
the
talaq!
Do
you
want
a
leader?
Do
you
want
Danny
to
start
with
ornate
or
anyone
else?
Well,.
L
Vlad,
Nate
and
I
have
been
arguing
about
chain
for
service
rules
a
bit
basically
trying.
You
know
the
gem
the
place
where
we
stopped
as
like
just
like
this
is
already
getting
into
optimization
territory,
but
trying
to
figure
out
like
what
are
these
issues
where
well
Nick
sure
does
sorry
just
to
kind
of
dial
back
a
bed
mobility.
We
look
Justin
and
I
am
at
Burley
and
started
thinking
about
one
issue
which
is
that
like,
given
that
using
like
pretty
much
every
random
beacon
scheme
has
its
own
flaws
of
different
kinds.
L
So
what
look,
for
example,
ran'tao
has
like
exploitability
the
threshold
VRS
and
have
this
like
hard
threshold
online
requirement
and
VDS
and
have
to
worry
about,
and
they
have
a
high
chance
of
being
monopolized
in
all
those
things.
So
we're
basically
trying
to
see
go
back
a
bit
and
see.
Can
we
make
the
algorithm,
like
the
the
beacon
chain,
algorithm
itself,
more
resistant
to
like
a
high
level
of
a
manipulation
of
proposal?
Selection?
The
basic
arguments
here
is
that,
because
the
a
tester
sets
are
very
large,
it's
just
basically
statistically
impractical
to.
L
Even
if
you
have
perfect
control
over
the
random
see,
it
is
statistically
infeasible
to
really
manipulate
like
more
even
one
a
tester
set.
But
the
number
of
proposals
in
one
epoch
is
like
100.
So
that's
totally
manipulable
and
if
you
have,
if
you
can
perfectly
manipulate
the
randomness,
so
the
issue,
the
thing
that
we're
trying
to
figure
out
is:
can
we
modify
the
algorithm
to
be
kind
of
much
more
robust
against
proposers
and
being
really
unreliable
and
the
security
assumption?
Is
that,
like
worst-case?
L
Imagine
that
within
one
epoch
there's
only
like
one
or
two
proposals?
That
are
honest
and
we
think
that
we
can,
but
it
basically
requires
some
fortress
rule
modifications.
So
the
problem
with
the
old
fortress
rule
was
that
the
old
fortress
rule
was
very
kind
of
proposer
centric
and
that
accounted
by
Heights
and
proposers
have
this
large
power
to
basically
prevent
Heights
from
incrementing
or
false
Heights
to
increment
and
the
scheme
that
we're
looking
at
basically
move
either.
L
Well,
one
option
that
I,
like
I'm
thinking
about
is
moving
fully
to
something
goes
to
like,
and
one
option
is
moving
out
of.
Partial
weight
is
something
that
partially
in
the
ghost
direction,
the
idea
being,
basically
that
these
kind
of
like
base.
If
you
have
like
chain
a
and
then
on
chain
a
proposers,
just
stop
showing
up,
then
you
have
all
of
these
dangling
at
the
stations
and
can
we
make
the
dangling
at
the
station
still
contribute
to
that?
L
Finality
gadget
and
budget
justification
and
I
kind
of
all
of
all
of
those
details
so
making
progress
but
still
wants
to
think
a
bit
more
and
also
thinking
about
knowing
making
like
the
design
space
between
sort
of
FFG
style
algorithm
to
see
this
new
style
algorithms
and
what
the
differences
are
and
what
the
intermediate
points
are.
And
so
forth,.
G
A
A
Is
there
still
interest
to
have
a
joint
test
net
like
a
Rob
Stinson
test,
some
of
this
new
stuff,
maybe
ewaz
and
other
things?
That's
the
first
question.
The
other
ones
are,
if
there's
an
interest
in
this
effort,
how
would
it
looked
like
if
there's
not
a
hybrid
Kasper
proposal
and
what
stem
should
we
take
to
in
the
meantime,
while
Casper
and
sharding
is
still
being
developed,
so
the
first.
L
Like
if
it's
in
the
ultra
short
term
like
a
couple
of
months-
and
it
should
be
a
joint
test
that
just
for
was
if
it's
some
longer-term
like
if
it's
longer-term
to
the
point
where
the
beacon
change
details
were
solidified,
then
a
joint
test
set
for
the
beacon
cherry
would
be
really
cool.
Yeah.
D
D
L
A
D
A
A
So
what
was
the
other
questions
on
there?
I
think
there
was
like
so
it
sounds
like
we
are
interested
in
an
effort
for
a
successor
to
rob
Stan.
It
sounds
like
if
we
were
to
do
that.
We
want
kind
of
something
like
he
wasn't
to
be
put
in
there
and
I
know
that,
there's
being
an
e
wasn't
s
net
developed
right
now
is
that
is
that
basically,
exactly
like
the
main
chain
that
with
wasn't.
D
D
I
D
I
C
C
C
C
L
Well,
no,
it
still
can
be
compressed
because,
like
if
a
zero
makes
up,
50%
of
the
compression
like
in
compression
algorithm,
that's
remotely
close
to
optimal,
will
assign
zero
to
the
zero
byte
to
be
like
less
than
one
bit.
So
the
like,
you
should
not
be
able
to
make
something
whose
compressed
value
is
like
more
than
twice
as
long
for
per
gas
than
just
random
bytes
I.
N
D
I
D
I
I
D
I
D
A
D
D
A
D
G
F
A
D
D
D
B
B
G
K
C
M
H
C
C
K
M
C
D
C
C
G
B
K
C
I
I
A
C
A
K
F
L
F
F
F
D
I
I
D
L
B
B
A
Thanks
Lexi
we're
finally
to
Constantinople,
so
what
I
want
to
talk
about
today
was
as
much
as
we
can
get
certainly
IPS
to
the
accepted
state.
Even
if
they're
not
they
don't
have
every
single
thing
to
find
get
them
to
where
we're
like
a
green
team,
put
them
into
Constantinople
and
then
start
to
talk
about
a
timeline.
A
So
first
off,
let's
just
go
through
some
of
the
e
IPs
and
make
sure
we're
kind
of
all
in
agreement
that
something
with
some
of
these
are
definitely
going
in
145
bitwise
shifting
we
approved
of
that
weeks
ago,
so
that
one's
definitely
going
in
the
IP
210
block
hash
refactoring
is
another
one
that
I
think
we
all
agreed
on
is
going
in
the
I.
Don't
remember
if
we
agreed
on
to
10:52
the
xt
code,
hash
or
not.
F
A
F
A
Cool
so
210
yeah
I'm,
pretty
sure
we
agreed
to
tins
going
in
so
1052
straightforward,
everyone
kind
of
wants
it
so
I
think
we
should
do
it.
So
we'll
say
right
now:
it's
going
in
unless
someone
comes
up
with
a
crazy
like
a
reason
not
to
mm-hmm
net
gas
metering,
4s
store,
I.
Think
everyone's
in
favor
of
that
Christian
yeah.
F
F
F
D
J
L
J
L
About
to
say
the
same
thing
like
it's
the
mean
complexity
that
I
see
about
this
is
that
you
don't
have
to
just
meet
yet
attorney
Matt,
but
you
also
have
to
maintain
a
journal
for
the
dirty
map
and
so
there's
risks
involving
like
what
happens
if
stuff
gets
reverted.
What
happens
if
there
was
like
stuff
gets
reverted
to
different
depths
and
then
rewritten
and
so
forth
and
like
we
had
to
fight
with
these
kinds
of
issues,
I
see
what
you
know
two
years
ago,
so
my
leg
ends
up
I'm
reintroducing
a
lot
of
trouble.
I
L
O
I
I
D
D
D
F
G
H
H
G
F
I
F
D
H
B
F
D
F
A
Okay,
so
that's
given
that
brought
up
some
questions
with
EIP
1087,
so
we'll
skip
that
one
for
now
and
not
say:
that's
gonna
go
in
or
not
because
we
stops
a
lot
of
open
questions.
1014
skinny
create.
Is
there
anything
on
that?
That
would
be
problematic
to
anybody
or
stuff
that
needs
to
be
flushed
out.
I.
F
L
A
N
F
F
L
L
Do
is
we
can
just
look
at
the
blog
sign
chart
on
ether
skin,
which
I'm
going
into
right
now
and
like
in
terms
of
block
numbers.
It'll
be
exactly
the
same.
So
if
we
pick
up
the
time
at
which
the
ice
age
kind
of
starts
happening
as
when
the
block
time
reaches
say
16
seconds,
then
that
would
be,
let's
see
it.
June
5th
2017.
L
L
L
I'm
hold
on
let's
check
right
now.
Six
point:
seven
is
still
pretty
far
away
all
right
now
we're
at
five
point
nine.
So
six
point
seven
is
eight
hundred
thousand
from
now,
and
one
day
is
six
thousand
blocks.
So
a
hundred
a
hundred
thousand
box
is
about
seventeen
days
felt
like
started
about
six
months
or
so
yeah
and
then,
after
that,
it'll
take
another
eight
months
or
so
until
it
becomes
like
really
serious,
so
I'm
doing
it
in
Constanta
and
in
Constantinople
log
seems.
L
D
A
A
A
It's
listed
on
the
agenda,
but
basically
finalizing
the
EIP
is
according
to
the
timeline
should
happen
today.
The
client
implementations
happen
for
roughly
a
month
between
July
16th
and
August.
13Th
testing
would
be
August
13th
to
September
10th.
The
test
net
would
be
September,
10th,
October
1st,
and
then
we
would
launch
October
8th.
That
would
put
us
like
20
days
before
Def
Con
starts
I.
Don't
think
this
is
necessarily
reasonable,
but
I
just
wanted
to
put
something
down,
and
then
we
can
start
estimating
how
long
it'll
take
for
things.
A
So
Alexi
had
an
alternative
timeline
that
he
posted
as
a
comment,
so
I'll
go
down
to
that,
and
that
puts
us
having
a
launch
in
January.
Most
people
don't
like
working
during
the
winter
time
because
they're
on,
like
family
vacations
and
stuff.
So
that's
why
I
was
willing
to
get
it
done
before
Def
Con,
but
I,
don't
know
if
that's
really
feasible
now,
depending
on
which
ones
go
in.
K
F
M
I
F
I
F
F
F
G
D
F
G
D
A
So
I
think
that
that's
similar
to
how
we've
done
it
in
the
past,
except
we've,
done
things
concurrently,
like
Martin
mentioned
so
like
we
are
implementing
it
in
clients,
while
we're
creating
the
test
at
the
same
time,
having
C++
be
the
first
implementation
that
everyone
copies
from,
is
kind
of
how
I
understood
it.
So
that's
similar
to
what
you
put
down
Alexi
and
I,
like
that,
you
did
it
the
way
you
did,
because
my
timeline
that
I
put
down
was
kind
of
waterfall
method,
where
it's
like
one
after
the
other,
whereas
really
it's
more
agile.
A
B
A
C
K
I
D
A
A
L
D
P
H
L
G
G
L
L
F
N
F
I
M
I
M
M
I
C
M
M
F
F
P
D
L
L
Run
it
against
all
the
clients
when
we
were
adding
IDIA
ec
pre
compose
for
Byzantium
for
the
first
time,
we
did
do
the
analysis
right
and
we
set
the
forty
thousand
like
and
what
eighty
thousand
gasps
busted
so
forth,
because
we
wanted
to
target
like
20
million.
Yes,
a
second
right
so
like
there
were
measurements
that
we
clearly
did,
and
you
can
just
read.
You
is
up
within.
L
F
N
N
N
D
I
D
I
D
A
So,
judging
by
how
we
have
how
we
haven't
really
gotten
exactly
what
GIPS
are
going
in
yet
and
the
timeline
is
getting
closer
and
closer
to
DEFCON,
it's
probably
going
to
be
posted
EV
con
before
this
is
released
unless
we
start
moving
here.
So
if
that's
the
case,
we
probably
should
delay
the
ice
age
in
my
opinion,
because
by
then
we'll
start
seeing
some
effects
in
2019
from
what
you
were
saying
right
for
the
ice
age,
okay,
so
and
with
the
earliest
we're
gonna
get
done
in
late
2018
early
2019.
A
G
F
F
F
I
L
L
A
What's
everyone's
thoughts
on
that,
does
anyone
think
that
it's
worth
and
it's
crappy
that
Nick's
not
here
to
defend,
defend
his
case
for
the
net
gas
metering
4s
store,
but
I
think
it
was
just
proposed
a
little
bit
too
late
in
the
game.
It's
is
what
it's
looking
like,
because
there's
a
lot
of
open
questions
about
it,
Wow.
D
P
N
M
I
O
L
Potentially
useful
right
like
it
would
be
nice
to
have
a
light
clients
that
can
sink
trust
us
away
in
logarithmic
time
so
like
if
you
want
to
actually
achieve
that
in
practice
of
requires
not
just
the
EAP,
it
requires
all
the
other
code.
So
my
it
may
well
be
the
case
that
actually
achieving
again
it's
not
worth
that
because
we
can
just
rely
on
the
existing
approach
until
he
gets
like
something.
But
through
those
stakes
are
like
client
functionality
order.
I,
don't
know
well,.
I
L
F
L
F
L
F
L
Dangerous
because
it
makes
like
it
could
make
life
a
lot
harder
for
like
clients,
and
it
basically
means
that,
like
the
entire
historical
set
of
block
chains
become
stuck
technically
part
of
the
state
and
like
it,
it
nullifies
the
benefits
of
kind
of
automatically
having
box.
Yet
like
get
hash
links.
The
blocks
that
are
much
older
than
they
are
like
yeah,
like
I,
see
the
primary
benefit
of
this
yep
year.
Kind
of
precisely
being
that
you
have
a
storage
tree
that
contains
like
some
subset
of
previous
block
hashes.
M
M
G
M
M
A
Good
I
would
say
that
I
I
think
I
agree
with
you
that
1:45
1052
and
1014
should
be
priority
because
they're
the
seem
to
be
the
easiest
to
implement
and
what
we
can
do
is
we
can
start
making
tests
and
start
implementing
those
three
and
then,
throughout
the
next
chord
F
meeting.
We
can
decide
on
the
other
two
and
talk
more
about
them.
I
think
that
would
be
valuable
and
also.
I
A
G
G
G
M
O
I
M
G
M
M
A
M
I
M
M
F
D
M
D
G
D
D
D
A
L
L
A
B
B
A
Okay,
so
we
can
look
at
that
and
discuss
it
for
next
meeting.
I'd,
say
sound,
good
sure,
cool,
okay,
so
I
think
we
have
some
good
conclusions
from
this
meeting.
Do
other
people
have
comments
on
this
and
that
we
don't
have
a
timeline
exactly,
but
what
we
do
have
is
we're
starting
stuff
and,
depending
on
how
fast
we
get
stuff
done
in
the
next
two
weeks,
we
can
actually
start
to
set
some
dates
and
finalize
some
things.