►
From YouTube: Ethereum Core Devs Meeting #28 [11/17/17]
Description
A
A
Let
me
also
make
sure:
can
everyone
hear
us
on
the
YouTube
pulp,
so
the
first
one
is
testing,
that's
just
more.
If
there
are
any
updates
that
are
relevant,
I,
don't
really
know
if
there
are
for
the
fuzzer
or
for
any
of
the
test
cases.
I
think
here
each
is
the
only
one
who
might
have
some
insight
into
that
yuuichi.
Do
you
know
of
anything.
B
On
test
occasions,
I'm
doing
the
visibility
I'm
talking
some,
so
this
case
is
in
the
Google
spreadsheet,
in
turn
red
to
green.
In
some
cases,
I
see
a
test
case
and
I
find
it
already
in
the
repository
and
iconic
green
and
so
on.
So
some
bureaucracy
is
going
on
both
hazard
size.
She
actually
activities,
but
I
cannot
really
describe
it.
It's
the
best
place
is
the
fashion
channel,
but
okay,
it's
private.
Well,
no
I
I,
don't
see
anyone
who
can
explain
that
in
this
meeting
right
now,
unfortunately,
no.
A
Problem
we
can
just
talk
about
that.
The
next
meeting,
or
if
martin
ER,
dimitri
or
anyone
comes
in,
we
can
ask
them
all
right.
Moving
on
to
item
two,
the
Byzantium
fork
review.
So
during
DEFCON
three
about
to
air
I.
Guess
two
weeks
ago
we
had
a
meeting
with
some
of
the
court
developers.
We
announced
it
in
the
channel
and
it
was
an
in-person
meeting
with
about
oh
I'd,
say
at
least
ten
people,
where
we
kind
of
talked
about
the
issues
that
we
had
with
the
Byzantium
release.
A
A
There
was
a
lot
of
different
things
discussed
that
could
be
possible
future
changes
to
how
we
do
hard
Forks.
The
ones
that
were
most
discussed
is
having
a
dedicated
release
manager,
that's
something
that
that's
kind
of
a
role
that
I
served
last
time,
but
because
I
couldn't
dedicate
my
full
attention
to
it.
A
lot
of
things
kind
of
got
left
behind,
especially
the
EIP
surrounding
Byzantium,
so
I
think
that
having
someone
do
the
role
in
a
full-time
capacity
or
maybe
with
a
few
other
things
and
a
related
role
would
be
really
good.
A
So
that
is
still
a
ways
from
you
know
like
deciding
officially
on
that.
Finding
anybody
for
that
that
kind
of
thing
so
I
think
that
I
think
that
that
would
be
a
good
next
step.
The
other
thing
is:
oh,
maybe
having
a
cadence
for
hard
Forks,
so
there's
some
different
software
projects
that
have
release
cycles.
So,
like
you,
do
a
release
once
every
two
weeks
or
you
know
you
do
a
release
once
every
six
months,
Peter
I
know
guest
has
something
like
that.
A
C
Sure
so
and
of
course,
for
napkin
with
a
bit
out
of
control.
Now,
but
generally
we
try
to
do
bi-weekly
releases
and
the
idea
is
kind
of
simple,
whatever
makes
it
the
master
gets
released
in
after
two
weeks
and
if
your
feature
didn't
get
on
master
in
two
weeks,
then
no
problem-
you
have
the
next
set
schedule
next
to
release
to
get
your
stuff
in
and
as
long
as
so
this.
C
So
it
was
really
painful
if
your
stuff
was
at
half.
But
since
we
switched
over
to
this
release
model,
it
was
all
the
friction
cut.
Kind
of
just
got,
dropped
and
I
think
we're
discussing
during
Def
Con
that
this
might
be
an
interesting
approach
for
hard
forks
to,
because
currently,
what
happens
during
hard
Forks
is
that
everybody
has
their
petty
IP
that
they
really
would
like
to
get
included.
C
And
then
basically,
we
start
to
delay
the
hard
folks,
because
some
a
IP
is
missing
and
because
we
have
absolutely
no
idea
when
the
next
the
IP
will
be
so
one
of
the
ideas
was
that
if
we
could
do
a
more
or
semi
more
regular,
hard
Forks
to
the
protocol
updates,
then
maybe
we
could
just
say
that.
Well,
ok,
your
IP
wasn't
finished
in
time,
no
problem
it
will
be
in
the
next
one.
C
A
Know
that
was
a
great
explanation
and
exactly
it
wouldn't
be
something
like
a
two-week
release
cycle
it'd,
be
something
like
six
to
eight
month,
release
cycle
where
you
have
a
period
of
picking
the
EIP
s,
having
a
strict
cutoff
date,
having
kind
of
an
implementation
phase,
with
a
priority
order
for
the
e
IPS
and
then
a
very
conservative
testing
phase.
With
some
rules
on
when
you
know,
we
should
raise
a
flag
for
you
know,
postponing
a
hard
fork.
What
are
the
conditions
for
that
to
happen,
etc
after
I
see
you're
also
in
the
channel?
A
A
A
Even
so,
some
of
the
timelines
discussed
were
a
six
month
or
eight
month,
full
release
timeline
with
something
like
one
month
or
two
core
dev
meetings
to
decide
what
e
IPS
are
going
in
for
that
six
to
eight
month
period
and
then,
like
four
months
for
implementation
and
three
months
for
testing
or
something
like
that,
it's
still
very
very
early.
These
are
still
suggestions,
but
that's
kind
of
what
was
discussed.
C
C
Ok
is
ready,
but
there
were
a
lot
of
information
missing
and
it
was
really
really
hard
to
implement
it
and
really
hard
to
synchronize
between
different
clients,
because,
for
example,
parity
had
an
implementation
that
was
one
of
the
specs
and
the
mass
spec
was
updated,
and
then
we
employed
the
difference
back
and
it
gets
messy
from
there.
So
if
we
could
have
some
meaningful
cut-off
dates,
for
example
arbitrarily
many
weeks
to
define
what
the
IP
will
do
and
then
we
only
change
the
spec.
C
If
something
really
goes
wrong
with
it,
then
at
least
kind
developers
we'll
have
a
stable
thing
to
work
based
on,
and
then
we
don't
have
to
postpone,
because
somebody
implemented
a
difference
back.
Rather,
we
could
just
have
hard
deadlines
that
okay,
you
had
four
months.
Please
do
it.
It's
much
cleaner
from
an
implantation
perspective,
I.
A
Agree:
I
think
that
also
builds
on
stability.
Any
other
comments
on
kind
of
this
hard
fork
guidelines
or
future.
You
know
flags
we
put
in
place,
III
need
it.
I
know
someone
was
taking
notes,
I
think
it
was
Martin
and
he's
not
able
to
join
today
or
right
now.
So
a
lot
to
get
those
next
time
and
discuss
this
in
detail.
That
I
remember
there
being
a
few
conditions
for
delaying
a
hard
fork.
A
Okay,
cool
yeah,
if
Martin
comes
in
we'll
discuss
it
a
little
bit
more
we'll
back
up
to
that
topic
and
if
not,
then
we'll
just
discuss
it
next
coordinate
meeting.
So
the
next
item
movie
IPS
activated
and
Byzantium
too
finalized.
We
are
still
behind
on
that.
Additionally,
I
believe
that
Nick
savers
on
get
er
that
might
be
his
actual
name
I'm,
not
sure
he
had
a
PR
that
was
similar
to
a
PR
that
a
free
wrote
down
a
meta,
a
IP
that
described
all
the
Byzantium
changes.
A
A
A
F
F
A
Yeah,
that's
no
problem,
so
I'll
talk
to
you
on
get
her
after
this,
but
thanks
for
joining
no
okay,
so
Martin
we
were
talking
just
a
second
ago.
Let
me
just
run
back
to
the
agenda
about
the
hard
fork
guidelines
we
talked
about
during
Devcon,
and
we
kind
of
went
over
the
basics
of
the
potential
for
six
to
eight
month
release
period
per
hard
fork.
Some
of
the
like,
like
the
fact
that
we
might
have
some.
You
know
red
flags
that
would
stop
us
from
releasing
a
hard
fork
or
maybe
delay
it.
A
We
didn't
really
go
into
any
of
the
signaling
systems.
For
that.
We
also
said
that
it
would
be
something
like
in
testing
or
the
choosing.
The
EIP
is
implementation
and
release.
So
if
you
wanted
to
I
know,
you
took
notes
during
that
that
we
can
bring
up
for
next
week's
meeting
once
we
give
them
a
little
cleaned
up,
but
did
what?
What
is
your
opinion
on
the
kind
of
the
things
we
discussed
at
that
meeting?.
E
A
That's
a
great
idea
and
yeah
we'll
be
looking
forward
to
that,
especially
if
we
can
make
the
EEP
and
then
edit
early
work
on
it
together
as
we
kind
of
discuss
and
coordinate
meetings,
what
the
next
steps
will
be
and
hopefully
eventually
get
some
sort
of
release
manager
all
right.
So,
let's
move
on
to
the
next
topic,
which
is
the
proof
of
authority
test
net
unification,
Piper
put
that
in
and
I,
don't
think
he's
able
to
make
it
today.
A
So,
let's
I'm
gonna,
just
think
I'm
gonna
speculate
on
what
he
meant
by
that
I
think
that
currently
ranked
B
only
works
for
death
and
unpair
D.
There
covin
tests
net
only
works
for
parity,
so
I'm
guessing
Piper's,
probably
talking
about
that
either
that
unification
or
the
creation
of
a
new
proof
of
Authority
test
net
that
just
works
across
all
clients.
A
C
So
yeah
I
think
that
the
pain
point
is
probably,
and
everybody
kind
of
feels
the
pain
point
pain
point
in
the
community
too,
is
that
it's
kind
of
pain
to
actually
test
your
depth
across
the
stat
works
because
Rob's
done
is
yeah.
We
know
Rob's
done,
but
even
though
coupon
and
drink
we
are
both
potentially
better
alternative
to
Rob's
and
they
aren't
really
cross
compatible.
So
it's
it's
annoying
and
I'm
guessing
Piper.
C
The
reason
why
he
was
asking
to
unify
the
test
nut
is
because
they
started
to
pick
up
development
on
the
Python
client
again
and
I'm
guessing.
They
would
also
like
to
roll
out
a
proof
of
authority
consensus
engine,
but
I,
don't
think
they
want
to
implement
two
of
them
or
were
third
well
for
that
matter.
So
that's
why
I
think
Piper
brought
up
the
subject
now
with
regard
to
to
the
customers
engines
in
itself,
I'm
going
to
say
so.
Basically
current.
C
So
from
my
perspective,
I
do
think.
Click
is
simpler
now
regarding
whether
we
if
people
want
to
actually
do
a
combined
proof
of
authority
test,
not
whether
we
should
stick
with
click
or
maybe
dream
up
a
third
one,
that's
I
from
my
perspective.
It
doesn't
matter
that
much
but
I
kind
of
agree
that
it
would
be
nice
to
have
a
really
a
again
a
common
test
network
between
clients.
A
D
G
One
thing
to
keep
in
mind
with
with
a
two
different
proof
of
the
two
different
POA
protocols
is
that
the
parity,
one
as
I
understand,
is
contract
based,
whereas
the
guessed
one
rinkeby
is
header
based
and
ultimately,
as
clients
start
implementing
the
Casper
chest
net.
Those
will
be
contract
based
consensus
protocols.
A
Interesting,
it's
starting
to
sound,
like
a
good
move,
would
be
a
proposal
for
a
third
test
net
that
maybe
starts
to
mimic
some
of
the
things
that
that,
like
yeah
things
like
the
future
Casper
test
net
has
especially
I
mean
we're.
Definitely
gonna
have
to
go
through
the
pros
and
cons
of
both
of
those
approaches.
It's
way
too
early
to
do
that
yet,
but,
but
that's
interesting
and
something
we
should
think
about
for
the
future
coordinate
meetings
is
if
the
third
one
should
be
created.
C
C
So
one
thing
that
so
basically
adding
various
proof
of
authority
to
different
clients
will
be
a
pain
in
the
ass
anyway.
So
maybe
it's
a
long
shot,
but
maybe
we
can
try
to
instead
add
or
start
adding
Casper
just
play
around
with
that
idea
or
just
you
know,
a
subset
of
I'm,
not
sure
I,
don't
know
how
how
far
Casper
it
is
or
whether
it's
actually
usable
on
the
test
at
work.
So
maybe,
if
you
can
give
your
ideas
on
I'm.
H
Sure
so,
as
I
understands
the
like,
there's
already
a
fold,
a
Python
implementation
of
Casper
and
a
test,
the
network
is
well
there.
I
mean
there
have
already
been
kind
of
successful
moments.
The
every
test
that
works
between.
Basically,
what
2pi
you
thought.
No,
it's
running
on
the
same
laptop
and
we're
currently
trying
to
expands
that
and
actually
have
it
kind
of
run
across
the
internet
in
a
self-sustaining
way,
though.
Currently
the
obstacles
have
more
to
do
with
stuff
and
stuff
involving
pi
e
theft
and
stuff
involving
Casper.
C
H
So
the
way
that
Casper
works
rate
is
that
you
can
have
some
clients
that
that
use
the
Casper
fortress
ruin
some
clients
that
use
the
proof
of
work
for
a
stroll,
and
basically,
unless
there
is
an
attack,
then
the
two
of
them
should
always
give
the
same
answer.
So
you
can
look
like
the
way
that
the
Casper
test,
oh.
H
So,
first
of
all,
it's
only,
it
only
becomes
a
cow's.
Protest
like
the
Casper
part
of
the
algorithm
only
turns
on
when
the
Casper
contractor
the
watch
dinner
and
it
has
enough
ether
deployed
and
even
then,
if
an
individual
clients
is
not
Casper
aware,
then
they
can
just
keep
following
proof
of
work.
So
we
can
basically
have
a
test
that
work
and
literally
test
the
entire
trend.
And
if
that's,
what
we
want
to
do.
G
H
Okay,
so
the
properties
of
that
Casper
realistically
has
is
that
yeah.
If
an
attacker
has
more
than
fifty
percent
of
all
the
hash
power,
then
they
could
do
attacks.
That
would
prevent
you
and
you
blocks
from
being
finalized,
but
they
cannot
revert
any
old
blocks,
so
I
mean
you
do
have
this
kind
of
partial
guarantee
and
if.
G
F
C
You
maybe
should
explore
this
a
bit,
maybe
yeah,
so
the
reason
why
I
was
suggesting
that
maybe
we
could
go
down
this
path
is
because
if
we,
if
you
realistically
want
to
roll
out
Casper
in
whichever
heart
fork,
then
eventually
people
need
to
start
implementing
it
and
Olympic
Olympic
Network
possibly
have
fun
Network
that
fell
apart
quite
a
few
times,
while
implantations
got
it
right.
So
maybe
it
would
be
nice
to
have
a
have
a
test
that
for
this
one
that
people
actually
want
to
use
to.
E
C
A
A
A
A
The
fact
that
there
is
rinkeby
that
runs
on
click
and
covin
that
runs
on
Ora,
ranked
B
as
headers
based
Kovan
is
contract
based,
and
so
we
were
either
thinking,
maybe
having
a
third
proof
Authority
test
net
or
if
the
goal
is
to
have
a
cross
client
test
net
in
general,
maybe
moving
on
to
the
Casper
test
net,
that's
already
built
in
Python
and
having
that
be
one
of
the
second
option
for
a
cross
client
test
net.
So
when
you
put
in
that
agenda
item,
what
was
your
intention.
I
Yes
was
actually
just
to
form
a
small
group
out
of
this
route
to
figure
out
what
a
common
proof
of
Authority
based
test
net,
but
everybody
could
agree
upon
was
so.
I
was
hoping
to
get
somebody
from
the
parity
team,
somebody
from
the
DOE
team
and
somebody
from
who's
familiar
enough
with
the
Casper
research
at
minimum
and
then
and
then
we
could
sort
of
take
it
from
there
and
then
come
back
with
an
idea.
A
Yeah
I
think
that's
a
great
idea,
so
go
team,
parity,
team
and
Casper
team.
If
you
guys
could
go
back
to
your
teams
and
get
someone
to
reach
out
to
Piper
or
we
can
coordinate
through
the
all
core,
devs
getter
I
think
I
think
that
can
definitely
work
out
and
we
can
have
like
a
separate
Gator
Channel.
A
C
So,
for
now
we
are
just
so
the
most
interesting
update
that
I
could
give
is
that
Felix
is
working
on
on
somehow
figuring
out
finalizing
the
EIP
way.
Sorry
IP
proposals
for
the
for
the
new
discovered
protocol
and
I'm
kind
of
really
looking
forward
to
that,
because
that
would
actually
allow
notes
to
properly
find
each
other
instead
of
kind
of
looking
for
needles
in
the
haystack,
but
I
think
that's
the
and
that
doesn't
really
have
to
do
anything
with
coherent
development.
C
J
D
No,
not
really.
We
have
some
changes
in
our
team
structure,
so
some
core
developers
are
not
available
anymore
for
the
parity
serum
client,
but
we
probably
noticed
that
you're
talking
to
a
free
or
Mike
instead
of
Akari
and
on
the
code
side
we
are
doing
some
major
refactoring
and
we
are
having
some
upcoming
code
audits.
So
much
there's
not
much
as
I
can
bring
up
right
now.
Okay
sounds.
A
G
K
Actually,
we
are
doing
a
research
and
we
think
that
it's
a
good
time
to
switch
database
engine.
We
are
looking
at
drugs,
the
B,
so
this
is
the
most
important
and
the
only
one
I
think
we're
working
at
the
moment
yeah.
So,
in
the
next
release
we
will
have
we're
going
to
have
maybe
a
new
database
engine.
We
also
implemented
a
snappy
compression,
so,
okay,
something
like
that
awesome.
A
A
I
H
Pi
F
app
not
much
on
the
PI
you
that
front.
The
main
thing
that
were,
although
I
know,
that
the
guys
that
are
working
on
the
test
on
the
Casper
tests
that
are
working
on
the
test
that
and
that
will
involve
probably
some
improvements
to
PI
you
have
the
stuff.
That's
already
happened-
is
basically
Python.
3
compatibility.
H
Other
than
other
than
that,
most
of
what
I
personally
been
focused
on
is
more
Casper
and
sharding
research,
stuff,
which
is
nothing
very
big,
but
a
lot
of
progress
on
small
things,
including
like
Casper,
incentivization,
stainless
client,
design,
Merkle
tree
optimization
gas
rules
and
a
few
other
things.
There
is
like
about
5
or
10
threads
on
the
Youth
Research
Forum.
A
A
C
A
A
A
H
C
With
a
abstraction,
I
think
one
of
the
things
we
we
need
kind
of
to
debate
first.
Is
that
bothers
me?
The
most
is
whether
we
allow
a
transaction
to
be
included
multiple
times
and
what
the
cons
are
mostly.
What
I'm,
personally
worried
about
is
that
currently
at
least
a
single
hash,
so
every
transaction
is
uniquely
identified
by
a
hash.
Same
goes
for
a
receipt,
so
hash
can
uniquely
identify
when
it
was
included
in
a
block.
C
If
we
allow
a
transaction
to
be
includes
multiple
times,
then
in
theory
it
can
lead
to
multiple
hashes,
sorry,
no,
it
can
lead
multiple
hashes
mean
to
reference
the
same
transaction
or
oh
Jesus.
Christ
is
mixed
up,
so
it
can
lead
to
one
hash,
referencing,
multiple
transactions-
and
this
may
be
a
strange
thing
for
people
in
general.
It
may
break
software,
so
I
don't
mind
doing
this,
but
it
should
be
really
really
clear
that
we
want
to
do
this
and
what
effect
it
will
have.
G
J
G
C
H
C
Transact
abstraction
thing
also
required
the
blockchain
state
to
figure
out
the
deploy,
address
and
I
think
that's
problematic.
If
you
are,
for
example,
out
of
sync
or
if
you
are
signing
the
offline
transaction
or
stuff
like
that,
so
I
would
very
much
prefer
if
we
could
have
contract
address
is
generated
in
such
a
way
that
you
can
do
it
without
having
access
to
the
block
chains
of.
G
A
H
C
Right
here
there's,
if,
if
change,
is
really
warranted
for
I,
don't
think
it
should
be
that
much
of
a
problem
since,
for
example
with
in
Byzantium,
we
already
change
the
receipt
format,
which
means
that
clients
already
support
working
with
two
types
of
receipts
so
doing
the
same
thing
for
transactions
shouldn't
be
technically
too
hard.
But
of
course
it's
nice.
If
we
don't
it
yeah.
A
C
A
So
getting
them
in
on
the
conversation
I
think
would
help
a
lot.
I
I
know
that
Lee
and
the
team,
from
my
ether,
wallet
I'm
sure,
would
love
to
be
involved
in
the
conversation,
so
once
an
EIP
is
that
I'll
pass
that
along
to
them,
if
they're,
if
there
does
become
an
EIP,
the
specific
to
modifying
modifying
that.
A
All
right
cool
that
was
the
last
agenda
topic,
any
other
agenda
topics
or
things.
Anyone
wants
to
bring
up,
I'm
refreshing
the
agenda,
I
think
Tim
was
saying:
maybe
discuss
a
three
to
six
month,
roadmap
for
feature
and
priorities,
but
I
think
it's
still
a
little
early
for
that,
since
we're
still
trying
to
come
up
with
a
better
process
for
that
and-
and
we
just
discussed
Constantinople,
which
would
kind
of
be
a
road
map
in
a
way
for
the
next
hard
fork.
A
So
I
think
that's
fine,
and
then
some
people
are
interested
in
discussing
ether,
recovery
or
ether
rescue
or
whatever
people
want
to
call
it
options.
My
understanding
is
that
parity
is
still
wanting
to
take
point
on
coming
up
with
some
of
the
either
a
IPS
or
strategies
surrounding
that.
So
at
this
point,
I
think
it's
a
good
idea
to
wait
for
parity
or
other
people
who
have
a
high
stake
in
this
to
come
up
with
public
proposals.
A
Okay
sounds
good
all
right
since
there's
nothing
else,
I
think,
then
that
can
be
the
end
of
the
core
dev
meeting
thanks
everyone
for
coming
and
we
will
meet
again
in
two
weeks.
Take
note
that,
because
of
different
time
shifts
or
daylight
savings
time
or
whatever
across
certain,
you
know
countries
to
adjust
it,
because
it's
still
1,400
UTC
for
the
time
that
the
meetings
happen
see
everybody.
In
two
weeks
everybody
have
a
good
day.