►
From YouTube: Ethereum Core Devs Meeting #52 [2019-01-04]
Description
B
I'm
just
gonna
start
now.
Actually
sorry
Greg
just
give
skip
to
one
anyways,
hello,
everyone
and
welcome
to
episode
52
of
the
core
developer
meetings,
I'm
Hudson
and
let's
get
to
the
agenda.
First,
we're
gonna
have
a
quick
announcement
about
note-taking
and
a
git
coin
in
bounty
associated
with
it.
So
I'll
have
Lane
go
over
that.
C
Welcome
everybody
happy
new
year
super
excited
to
kick
off
this
year,
yeah
and
find
health,
so
I'd
like
to
introduce
everyone
to
Anna
who's
on
the
call
Hudson
mentioned.
I
I.
Think
our
last
meeting
about
a
month
ago
that
we
were
kicking
off
an
initiative
to
help
to
have
some
bring
in
some
sort
of
external
project
management
talent
to
help
us
just
sort
of
run.
C
These
meetings
and
just
coordinate
hard
Forks
and
things
I'll
freeze,
also
kindly
volunteered
to
help
out
with
that
process,
and
one
of
the
things,
as
you
guys
know,
I've
been
taking
notes
for
these
calls
for
most
of
2018,
so
we're
gonna,
so
we're
gonna
sort
of
experiment
a
bit
going
forward
with
that.
So
Anna
has
kindly
offered
to
take
notes
for
the
meeting
today,
and
the
other
piece
of
this
is
that
we
also
set
up
a
git
coin
fund
as
a
massive.
C
Thank
you
to
get
coin
for
helping
us
out
with
this
and
for
funding
the
first
bounty,
and
so
there's
actually
gonna
be
a
bounty
for
note-taking.
This
is
something
that
we
hope
to
keep
doing
for
all
of
these
calls.
Basically,
so
we
may
have
some
other
fresh
faces
joining
us
to
take
notes
going
forward.
Thank
you,
yep.
B
Exactly
and
we
also
have
maratton
here-
he
is
also
part
of
the
group
of
people
who
are
it's
kind
of
right
now
called
like
a
project
management
group
for
the
core
devs,
which
is
a
group
of
about
how
many
people
something
around
seven
or
eight
people
who
want
to
kind
of
learn
how
to
navigate
around
either
the
e.I
peas
or
the
court.
Dev
meetings
or
note
take
or
help
out
in
some
way
or
another
may
be
hard
for
coordination.
B
Stuff
like
that
and
offeree,
is
going
to
be
leading
the
heart
for
coordination
paths
between
now
and
the
next
part
or
after
Constantinople,
but
also
I,
guess
leading
up
to
Constantinople.
Usually
that
role
was
taken
by
either
no.1
or
kind
of
taken
by
me
for
previous
hard
Forks,
but
he's
stepped
up
to
take
that.
So
thank
you
so
much
offeree
and
during
calls
for
hard
fork,
related
stuff.
I'll
probably
have
offeree
cover
a
lot
of
that.
So
just
a
heads
up
to
everybody
I
think
that's
about
it.
On
that
topic.
B
D
Okay,
hello:
everybody
welcome
you're
in
2019,
so
tests
focus
on
tests
now
more
to
validating
the
clients,
how
they
pass
existing
tests
generated
by
cpp
client
in
a
block,
sheen
test
form,
and
now
we
test
those
tests
on
hi.
Basically,
it
means
we
need
to
test
your
client
quality,
client
and
any
other
hive
compatible
clients.
So
far,
I
see
only
goal.
D
Client
is
working
on
hi
I've
been
on
a
maintenance
in
the
beginning
of
December
and
I,
see
now
it
worked,
go
client
files,
only
90
tests,
out
of
all
of
our
test
pool
and
most
of
the
failures
are
insignificant.
Is
it
because
of
configuration
errors
or
maybe
high
script
errors
and
rest
of
the
tests?
I
will
look
the
spoilers
and
investigate
why
and
and
I
need
to
contact?
Is
the
developers
cause
to
be
nice
to
her,
like
all
passing
without
any
issues?
D
D
E
D
D
B
F
F
F
We
discussed
those
previous
meetings
that
we
want
to
have
something
like
hybrid,
fast,
walk,
synchronization
and
future,
and
implementing
fast
sink
is
one
of
the
first
steps
process.
And
last
but
not
least,
we
start
looking
into
removing
counts
from
parity
in
general.
Account
management
of
transaction
signing
should
not
be
part
of
world
line
of
soup.
We
noted
in
attachment,
he
has,
is
something
we're
trying
to
figure
out
how
to
transition
best
to
I,
guess,
that's
it
so
far.
G
J
Hello,
so
I
was
mostly
working
last
for
last
couple
of
weeks.
I
was
mostly
working
on
these.
The
database
that
I
mentioned
in
on
DEFCON
4,
which
I
call
Morris,
which
actually
is
a
Latin
name
for
Marbury
I,
didn't
explain
it
very
well:
okay,
but
essentially
again,
working
on
the
most
most
complex
part
of
my
proof
of
concept,
which
is
the
reverse
kind
of
reverse
this,
for,
therefore,
the
footage
for
the
history
and
I
sort
of
made
it
work
so
far.
J
L
K
L
L
So
after
we
implemented
them,
we
also
focused
on
creating
a
benchmarking
framework
to
benchmark
all
these
pecan
pies.
We
have
been
done
benchmarking
every
single
one.
Yet,
but
at
least
we
have
a
framework
which
should
allow
benchmarking
different
implementations.
The
one
we
focused
on
is
benchmarking,
different
implementations
of
share
to
5/6
and
running
different
and
metering
strategies
on
them.
So
all
of
this
can
be
found
on
the
ewaso
morgue
on
github,
under
the
benchmarking
repo
and
the
second
focus
area
was
the
test
net.
The
public
tested.
L
We
also
have
decider
tool
called
wasn't
chisel,
which
can
which
can
basically
fix
any
kind
of
wasn't
binary
to
be
compatible
with
T,
wasn't
and
that's
coming
to
release
soon,
and
that
should
enable
different
languages
to
be
used
on
the
tests.
Now
last
note
on
the
tests
net
itself
so
far,
the
test
net
was
running
with
Kuwait
here,
and
this
is
c
plus
plus
VM
called
Hera.
But
in
the
last
couple
of
weeks
we
also
deployed
a
purely
go.
L
The
next
thing
I
wanted
to
mention
is
we
working
on
on
surveys
regarding
blockchain
platforms
using
web
assembly,
and
this
will
reveal
look
at
how
to
use
web
assembly.
Well,
not
only
platforms
which
used
web
assembly
would
also
address,
which
use
other
VM
similar
or
dissimilar
to
you
to
have
assembly.
But
of
course,
main
main
focus
is
on
assembly
itself
and
we
intend
to
include
you
know
best
practices
we
have
found
and
history
should
be
published.
I
think
that's.
M
No
features
or
something
like
that
we
are
working
to
pass
all
github
tests.
That's
why
edges
by
Dimitri
and
other
contributors
for
Constantinople,
and
we
did
it-
we
have
not
found
almost
any
bug
just
one.
We
compile
it
mod
X,
all
asses.
Other
heroes
were
only
associated
with
tests
like
one
with
empty
storage.
This
empty
account
with
storage,
so
we
are
passing
all
github
tests
and
we
are
ready
for
head
fork,
but
we
are
not
running
on
hive.
B
L
Can't
give
a
tiny
update
because
Holger
is
not
on
the
call,
but
I
keep
a
close
eye
on
it.
Yes,
and
what
an
important
thing
to
note
is
a
DEFCON.
There
was
some
discussion
and
that
maybe
some
hearts
should
be
written
in
typescript
and
that
work
has
come
to
fruition.
The
first
part
is,
they
are
LP
library,
which
has
been
written
to
tie
script
that
has
been
published
and
before
Christmas
and
now
work
is
being
done
on
rewriting
other
libraries
to
typescript.
B
N
From
our
side,
the
es
research
team
we've
primarily
been
focusing
on
refining
this
phase:
zero
spec
for
serenity.
Where
phase
zero
is
the
core
proved
mistake
chain
that
is
the
backbone
for
the
all
the
shard
chain.
We
are
moving
into
a
relatively
stable
place,
we're
still
refining
things,
making
optimizations
etc.
But
I
will
say
if
you
have
not
been
following
the
progress
on
this
side
due
to
not
having
the
the
time
to
dive
into
the
weeds,
and
things
are
constantly
changing.
N
Sometime
during
January
might
be
a
good
time
to
open
up
the
spec
and
to
provide
insight
into
you
know
the
things
that
you
have
expertise
in
we're
targeting
something
that
looked
is
relatively
complete
in
production,
ready
in
terms
of
the
spec
by
the
end
of
January.
Obviously,
as
we
do
implementation
things
might
change
bugs
we
fix
error.
But
again,
if
you
haven't
opened
that
up
some
time
over
the
next
two
or
three
weeks
would
be
a
good
time
to
open
it
up
and
review
and
see.
B
B
J
This
is
the
some
kind
of
so
split
it
up
into
much
smaller
pieces,
which
I
probably
would
call
cards
so
like
you
can
describe
one
of
them
in
one
one
slide
and
then,
instead
of
creating
like
Winchell
steps
like
once
one
two,
three
four
five
six,
essentially
there
would
be
some
dependencies
and
the
reason
I'm
I
want
to
do
this.
First
of
all,
these
cards
will
more
or
less
correspond
to
the
Future
II
IPs,
and
the
reason
I
want
to
do
it
is
that
I
started
to
discover
research
the
be
like
the
different
alternative
approaches.
J
Alternative
proposals
abut
or
some
kind
of
shorter
term
shorter
term
measures
that
we
can
deploy
to
to
set
of
stem
the
the
state
growth
and,
for
example,
one
of
them
I've
been
researching
is
D.
Is
the
stem
the
the
the
state
growth
while
increasing
the
block
size
limit,
so
I've
written,
Li,
small
post
about
it?
J
On
the
theory
magician,
essentially,
the
problem
that
I
see
is
that
if
we
are
ready
to
raise
the
gas
law,
gas
limit
and
problem
with,
that
would
be
that
we
would
unleash
more
rapid
increase
in
the
state
size
unless
we
simultaneously
somehow
restricted
but
they're,
restricting
it
simply
by
making
it
more
expensive,
as
some
some
some
side
effects
so
essentially
in
this
post
kind
of
goes
over
that
we
could,
in
a
short
term
decouple
the
blow
gas
limit
increase
from
the
state
rent.
But
it's
not
trivial.
It
requires
some
changes.
J
For
example,
one
of
them
would
be
something
that
metallic
proposed
to
change
the
fee
market
anyway.
So
this
is
the
my
current
thinking
and
so
I
probably
gonna
do
this
about
and
around
the
next
week
and
I
know
it's
a
bit
short
before
the
before
our
meeting
in
January
but
yeah.
That's
my
update
and
there's
another
post
about
about
the
dark
rent,
which
is
an
italic
suggested
solution
to
which
is
also
necessary.
J
Magician,
so
I
think
you
can
go
to
the
the
keyword
2d
to
the
tags
on
the
pseudo
magician
about
the
ECM
1x
to
find
all
this
post.
They
don't
actually
many
of
them,
basically
that
yeah,
that's
it
for
the
statement
and
for
the
other
working
group,
which
is
Peter,
Lee,
Peter,
I'm,
sure
he's
gonna
join,
but
so
for
the
cleaning
up,
the
sorry
pruning
the
the
other
types
of
information
like
blocks
and
receipts.
J
So
I
also
wrote
up
the
proposal
for
the
backwards
forward,
sink,
which
is
which
came
out
of
assembly
different,
but
essentially
the
idea
is
that
you
would,
as
a
lot
of
clients,
do
right
now.
You
would
do
some
sort
of
snapshot
sink
by
the
para
para
to
work
sink
or
fasting,
and
then
you,
instead
of
instead
of
basically
a
trying
to
reconstruct
the
the
prior
history
from
the
execution
transactions.
You
simply
download
the
prior
history
from
the
from
the
pier
nodes
as
a
reverse.
J
B
B
That's
pretty
much
something
that
consensus
has
graciously
volunteered
to
kind
of
take
on,
and
the
stemmed
from
the
ad
hoc
meetings
at
Def,
Con
I
believe
so
again
just
reach
out
to
me
and
we
don't
have
a
specific
venue
yet
as
far
as
I
can
but
that'll
be
coming
up
pretty
soon.
We'll
have
information
on
that
and
send
me
your
email.
If
you're
interested,
it
looks
like
a
Peter
or
actually
is,
was
there
any
questions
about
that
before
I
start
or
get
throat
to
Peter
Oh.
J
Actually,
you
can
just
a
very
quick
another
update,
I
forgot
to
say
sure.
I
have
found
another
person
to
help
me
with
the
with
this
kind
of
with
these
tasks,
and
so
he's
gonna
join
me
in
the
end
of
January
and
he's
also
gonna
be
coming
to
that
to
that
meeting
as
well
to
get
to
get
introduced
to
other
people.
So
I've
been
working
with
this
person
for
a
long
time
since
my
three
previous
jobs,
so
I
am
I'm
pretty
kind
of
sort
of
relieved
that
there
would
be
somebody
helping
me
with
that.
O
Yes,
my
vacation
was
great,
so
not
really
I
mean
I,
don't
have
any
particular
updates
regarding
Forks
or
what
not
one
nice
update
is
that
about
half
a
year
ago
we
were
working
on
pruning
and
we
found
there
was
some
fault
and
it
took
us
an
eternity
to
find
it,
and
it
turned
out
that
it
simply
was
not
a
fault
and
it
was
everything
is
actually
working.
So
now
we
have
a
fresh
energy
to
actually
do
pruning
properly.
Again,
so
that's
like
that's
good
news,
but
that's
about
okay.
B
F
B
Cool,
so
one
potential
concern
is
that,
according
to
a
website
and
I
guess
back
in
script,
running
the
Peter
Prechter
set
up
from
one
of
the
major
mining
pools.
Only
around
eleven
percent
of
the
nodes
are
on
the
latest
versions
of
Gaither
parity
that
are
able
that
are
compatible
with
Constantinople.
Is
that
a
concern,
and
is
that
something
that
we
should
be
proactive
about
as
far
as
trying
to
get
the
messaging
further
technical
reasoning
behind
that
I'm?
Not
smart
enough.
O
Q
B
Okay
and
the
next
item,
or
actually
I,
don't
yeah
I,
don't
think
there's
any
other
stuff
on
Constantinople
we
may
have
oh
the
next
meeting.
We're
gonna
have
it's
gonna,
be
post
Constantinople,
so
we'll
just
go
through
what
we
usually
do
and
talk
in
the
Chordettes
chat.
If
there's
gonna
be
any
problems
or
anything,
we
need
to
do
Oh
actually.
J
Hudson,
maybe
it
makes
sense
to
you
to
have
a
to
have
like
some
kind
of
around
the
fork
time,
maybe
to
make
sense
together
some
like
look
like
exceptional
meeting
or
something
we're
completely
optional,
but
just
to
talk
through
the
what's
going
on.
If
we,
if,
if
people
want
to
do
this
sort
of
to
monitor
the
transition
or
I,
don't
know
if
it's
helpful,
because
that
actually
kind
of
reaction
time
might
be
I,
don't.
B
J
Okay,
actually,
it
would
be.
It
would
also
be
useful
for
people
who
are
like
for
people
to
join
like
run
some
important
services
to
just
get
them.
Real-Time
updates
with
some
interpretation
rather
they're
just
sitting
and
watching
it
like
a
fourth
monitor,
because
people
have
a
different
sources
of
information.
So
if
we
can
just
throw
it
in
and
sort
of
explain
everything
as
it
happens,.
E
O
B
B
F
F
I
already
saw
some
discussion
to
have
it
shorter,
maybe
eight
months
or
six
months
or
someone
in
proposed
three
months
cycle
I,
don't
think
it
should
be
too
short,
but
yeah
we
should
discuss
what
a
reasonable
cycle
would
be.
I
was
running
numbers
against
the
nine
months
cycle,
and
this
would
mean
we
have
the
next
hard
fork.
I
caught
at
Easter
move
next
next
hot
pot
on
16th
of
October
2019,
it's
a
Wednesday.
F
F
F
F
B
B
B
F
What
I'm
doing
is
proposing
how
to
manage
protocol
upgrades
on
the
main
that
I'm
not
suggesting
that
we
force
our
set
to
fit
the
schedule
I
mean
I
would
recommend
that
we
stick
to
a
plan
in
generally,
but
if
the
group
of
quarter
limited
sites,
we
want
to
have
an
additional
hard-fought
in
between
then,
why
not
I
mean,
but
that's
not
relevant
for
my
again
that
item
right
now,
so
that
we
want
to
move
to
power
first.
Let's
just
talk
about
yeah.
B
Let's
do
Prague
now
first
and
then
we'll
go
back
to
the
proposed
rough
timeline
for
Istanbul
and
some
of
the
other
EPS
and
stuff
that
you've
been
working
on
for
the
formal
process
for
hard
Forks.
So
we
have
miss
if
and
mister
else,
from
the
Prague
POW
team.
Thanks
for
coming
back
you
all
and
they
can,
along
with
Martin
and
a
few
others,
probably
give
some
updates
on
Prague,
tau
or
actually
missive
do
you
do
you'll
have
any
particular
updates
for
the
specification
that
hasn't
already
been.
You
know
covered
by
any
of
the
Deb's
here.
N
Yeah
the
changes
that
we
published
in
early
December,
there
were
two
small
changes:
one
late
November
and
one
early
December
to
try
to
the
first
one
made
it
a
little
bit
harder
for
specialized
days
at
ASIC
to
be
made
the
second
one
stabilised
hash
waves.
Those
are
the
only
two
small
changes
we've
had.
We
don't
see
any
changes
going
forward
from
there.
B
E
N
E
Five
epochs
and
we
kind
of
from
that
from
the
outset.
We
knew
that
the
things
that
we
needed
to
tests
are
basically
the
epoch
transitions
because
yeah,
those
are
the
parts
where,
where
you
can
trip
and
fall
and
from
my
perspective
yeah
is
that's
basically
the
big
thing
that
needs
to
be
testing
and
regarding
this,
should
we
bundle
it
with
other
updates.
That's
my
take
is
that
the
the
transition
from
hush
mode-
it's
broad,
does
not
involve
the
EBM
or
state
transition,
mechanics
at
all.
E
It's
only
the
envelope
of
the
blocks
and
the
current
test,
the
the
extensive
test
that
we
need
to
write
to
all
be
due
to
the
normal
current
works.
We
don't
have
to
do
those
tests.
There
are
the
kinds
of
tests
they
mainly
really.
The
main
thing
to
test
is,
you
know,
can
we
switch
to
a
new
dag
at
a
certain
epoch?
B
Okay,
great
so
I
guess
what
we
want
to
decide
today
is
not
necessarily
when
it
would
happen,
but
if
it
would
happen
and
then
we
can
start
to
kind
of
formulate
what
that
entails.
If
we
decide
it's
gonna
happen,
I
haven't
heard
much
dissent
as
far
as
people
saying
they
don't
want
it
to
happen
very,
very
few,
just
a
couple
of
people
actually.
So
what
are
some
opinions
on
whether
or
not
this
should
go
forward?
Is
there
anyone
who
doesn't
I.
L
E
Some
facts:
we
know
for
a
fact
that
there
exists
basic
minors,
so
it's
obviously
profitable
to
manufacture,
and/or,
buy
and
use
acid
miners.
There
is
some
the
III
as
I
understand.
It
is
the
first
generation
assic
miners,
but
there
was
a
second
generation
asag
miners,
one
from
bit,
Maine,
which
I'm
not
sure
if
it's
even
publicly
released
yet
and
there's
also
some
other
companies
produced
some
acid
mining
for
thorium.
E
J
Well,
I
just
wanted
to
remember
Martin.
You
also
said
in
any
previous
or
something
that
the
other.
The
other
side
of
this,
of
course,
is
that
when,
if
the
such
time
comes,
we
would
postpone
it
for
one
year
but
after
that
year,
because
the
profile
is
a
bit
more
sophisticated,
then
you
see
hash,
then
obviously
making
Isaac
is
much
more
difficult,
but
if
somebody
does
manage
to
make
it,
then
they
will
have
a
very
good
advantage,
so
that
is
kind
of
the
coin.
E
N
I
would
I
would
interject
a
bit
that
the
etherium
Asics
that
exists
today
are
only
marginally
better
kirsta
watts
than
commodity
GPUs
and
the
way
that
hog
power
has
been
designed.
Yes,
of
course,
somebody
can
always
may
ASIC
I'm
a
GPU
is
an
ASIC,
but
the
amount
of
benefit
they'll
be
able
to
get
is
vastly
reduced.
So
even
after
a
year,
if
they
spent
millions
of
dollars
designing
an
ASIC,
it
might
only
be
10%
faster,
maybe
20%
more
efficient.
N
E
J
N
I
J
Of
what
I
would
like
to
find
to
find
out
before
we
make
a
decision,
is
that
whether
we
underestimated
the
the
actual
efforts
to
be
switches
switch
on
it,
because
we
know
that
there
is
algorithm
that
we
know
we
can
do
verification.
But
essentially,
what
are
the
things
we
need
to
do?
And
is
there
any
other
catches
that
we
haven't?
E
It's
gonna
say
that
that
was
one
of
the
reasons
to
spin
up
to
test
that
to
see
that
we
could
get
more
clients
on
board.
We
could
do
CPU
mining.
We
could
do
a
few
mining,
we
can
have
fast,
syncing
I,
don't
know
if
we
have
any
light
clients
on
it,
but
like
time,
verification
is
the
same
as
normal
verification.
E
J
G
R
Actually
they
share
the
same
that
memory
area,
which
is
generated
by
the
classic
80s
caramel
and
things
are
going
pretty
well.
Minor,
is
working.
The
test
net
is
working,
but
actually
is
a
too
small
test
net.
We
have
a
few
notes.
The
hashing
power
is
very
low.
There
are
not
particular
problems.
I
want
just
to
add
a
few
notes
about
the
addition
of
POW.
What
does
it
mean
for
minors,
while
it's
pretty
easy
for
AMD
users
to
switch
to
the
new
algorithm?
R
It's
a
bit
a
little
bit
trickier
for
NVIDIA
users,
because
the
run
time
compilation
of
the
kernels
requires
that
the
Nvidia
toolkit
is
on
board.
So
this
means
a
little
more
space
needed
on
rigs
which
are
driven
by
USB
sticks
or
whatever,
and
a
little
bit
more
of
computing
power
just
for
the
needs
of
the
compiler
to
switch
very
rapidly
on
profile
periods,
changes
under.
N
R
Actually,
all
the
implementations
have
a
little
hole
that
is
in
during
the
PAL
period
switches
all
the
miners,
stay
silent
for,
say,
half
a
second,
at
least
for
the
time
needed
to
compile
the
kernel.
I
think
we
can
easily
implement
an
async
precompilation
of
the
kernels,
so
we
can
give
continuity
to
the
mining
activity
on
the.
R
The
devices
and
one
last
thing
I
think
it
might
be
related,
even
if
it's
not
directly
related
to
theorem
itself
I
think
is
the
adoption
of
the
theorem
stratum
2.0
for
to
communicator
among
miners
and
poles.
We
have
reduced
significantly.
The
bandwidth
use
it
to
signal
all
the
words
and
might
also,
if
needed,
in
the
future,
integrate
the
revisions
of
the
programmable
protocol.
R
E
R
A
period
change,
epoch
changer
actually
cannot
be
prefect
unless
you
have
a
lot
of
very
consistent
space
on
the
GPU,
which
is
actually
possible
for
6
GB,
gigabyte,
GPUs
and
but
it's
half
a
second
in
period
changes.
So
50
bucks,
every
50
blocks
yeah
but,
as
I
said,
it's
quite
trivial
to
pre-compile
the.
R
J
R
New
etherium
2.0
stratum
proposal,
yes
does
supported,
actually
is
not
effective
in
user,
even
if
I
worked
with
Peter
Peter
Pratt
sir,
which
have
implemented
it
in
for
their
pool,
and
we
have
a
couple
of
tests
and
points
which
are
working
very
well.
Just
yesterday
with
a
collaborator
of
Peter,
we
have
tested
and
aetherium
stratum
2.0
all
in
bundle
with
profile
which
is
working
quite
fine.
R
J
Mean
so
my
question
to
basically
everybody
is
that
how
much
work
do
we
have
left
for
the
core
developers?
How
much
work
do
we
have
for
the
mining
pools
like
if
there
is
no
much
left
work
to
do
be
done
by
core
developers,
then
I'm
pretty
happy
to
just
sort
of
like
wait
to
add
or
other
people
just
finish
their
work
and
tell
us
when
they're
ready?
J
J
Well,
you
asked
me
not
not
just
you
but
everybody.
So
my
main
question
is
that,
because
this
is
the
court
of
calls,
is
that
how
much
in
more
more
time
and
efforts
or
the
core
developers
need
to
be
spent
on
this
change
and,
like
it
said
minimal?
Is
it
like
medium?
Is
it
large
because
I'm
pretty
happy
if
the
rest
of
the
work
is
proceeding
somewhere
else,
and
then
we
can
just
make
decision
on
that
basis?.
R
R
R
R
R
At
this
very
moment,
there
are
less
than
40
mega
hashes
and
my
rate,
my
test
rig
alone
is
producing
36,
so
actually
no
one
is
participating
actively
in
the
testing
of
the
network.
There
are
no
transactions
and
I
do
not
have
a
clear
idea
of
what
might
be
the
impact
for
large
pools
to
implement
all
the
stock
needed
for
prop
out.
I
can
tell
on
the
f
minor
side
that
95%
of
the
work
has
been
done.
R
R
O
One
thing
that
we
can
do
is
to
create
a
shadow
work
of
Robson,
basically
just
launched
a
few
notes
that
switch
over
to
prop
power
and
have
the
two
chains
coexist,
and
everybody
can
still
use
the
original
Robson.
The
original
Robster
will
still
have
the
exact
same
transactions,
but
we'll
just
piggyback
on
it
and
try
mean.
O
O
B
The
decide
today
is
more:
do
we
want
to
go
forward
with
prog
Pao
and
not
develop
a
timeline?
Quiet
yeah,
but
I
do
understand,
Alexi
that
your
concern
is
the
amount
of
effort
involved
across
teams
and
if
that
amount
of
effort
is
going
to
be
longer
than
the
effects
of
you
know
putting
it
in
in
the
first
place
or
what
it's
trying
to
prevent.
H
H
We
recently
added
block
number
to
the
to
the
respawns,
and
so
because
this
is
kind
of
the
connection
between
mining
pools
and
so
I'm,
not
sure
like
every
mining
pool
is
using
that
maybe
they
have
modified
clients,
but
anyway,
this
is
kind
of
the
connection
and
the
second
and
the
second
bigger
part
would
be
considering
block
verification.
So
what
clients
need
to
implement
protocol
block,
proof-of-work
verification,
because.
H
We
have
have
free
implementations
right,
it's
C++,
rust
and
go
so
this
can
be
exposed
as
a
library
whatever.
But
if
you
want
like
pure
Python
and
something
like
that,
it's
it's
not
done,
and
so
this
is
what
you
could
considering
as
something
we
want
to
have
or
like
it's
optional
and
I.
Also
I
also
proposed
to
to
add
other
language
bindings
to
my
library,
I
promise
to
this
sharp
sometime
ago.
It's
not
going
very
well
because
some
problems
with
figure
out
how
to
do
it
exactly
what
it's
doable.
H
If
that's
acceptable
solution,
so
I
can
I,
expose
Python
and
maybe
take
JavaScript,
and
something
like
that.
Maybe
javascript
will
be
more
problematic
because
it
might
be
useful
to
have
JavaScript
only
implementation
to
be
to
be
able
to
be
run
in
in
browsers,
but
I'm,
not
sure
if
we
have,
if
hash
implementation
of
that
anyway.
So
but
that
I
think
that's
the
biggest
and
like
something
this
weekend,
considering
not
to
be
mandatory
to
have
for
every
implementation
we
currently
considering
as
a
as
a
Chilean
client.
J
H
Yes
and
like
at
least,
we
should
like,
having
that
into
consideration
right
to
either
support
their
teams
on,
like
figure
out
approach
to
it.
These,
like
probably,
all
the
teams,
should
somehow
response
to
that
and
say
what
do
they
need,
what
they
think
should
be
day
way
of
implementing
blog
verification,
and
then
we
can
suggest
some
solutions
or
work
on
my
like
on
some
common
solutions
to
that.
H
B
Yeah
and
we
can
make
I-
mean
I,
guess
if
the
major
clients,
if
it's
possible
for
the
major
clients
to
code,
that
in
I,
mean
sorry
the
non
major
clients
to
code
it
between
now
and
the
time
that
we
would
potentially
launch
it,
which
would
be
what's
the
what
is
theoretically
the
soonest
that
we
would
want
to
do.
This.
Has
anyone
kind
of
thought
about
that?
Martin
I
thought
you
might
have
been
throwing
around
numbers,
but
that
might
have
been
someone
else
for
like
three
or
five
months.
B
So
let's
actually
I
have
a
question
for
Dimitri
from
the
harmony
team.
Have
you
all
looked
at
anna
grading,
prog
Pao,
and
or
can
you
estimate
or
give
us
an
idea
of
the
amount
of
work
to
be
done,
because
that
would
also
help
us
understand
where
Pantheon
might
be
at
and
I
can
also
ask
the
Pantheon
team
as
well.
I
B
I
E
D
D
J
And
I
have
a
suggestion,
I
think.
So
it
looks
to
me
that
we
want
to
hear
back
from
the
non
major
client,
but
at
the
same
time
we
kind
of
leave.
We
don't
want
to
procrastinate
too
much
and
just
leave
the
decision
hanging
in
the
air.
So
I
would
say
that
we
might
just
do
the
we
might
decide
kind
of
the
conditional
decision
kind
of
thing
this
might
decide
to
do
to
go
ahead
unless
we,
you
know,
there's
like
some
major
problem
found
with
a
non
major
client
or
something
like
that.
J
B
G
N
O
N
J
G
Basically,
it
means
going
over
to
different
trust
models.
Okay,
you
know
ultralight
clients
with
some
sort
of
staking
or
whatever
like
VIP,
no,
those
kind
of
solutions
which
are
like
on
a
powerful
device
like
an
iPhone.
You
get
away
with
it,
but
on
say
emerging
markets.
Typical
device
is
not
at
all
and
then.
J
G
E
G
G
J
G
G
J
What
I'm
thinking
is
about
is
that
you
basically
need
to
provide
two
proofs
of
work.
One
is
the
basement
rock
pile
and
another
one
based
on
let's
say,
shot
2
or
shot
3
whatever
and
which
is
much
slower,
lower
difficulty,
but
still
it
will
be
it's
booby
kind
of
hard
to
produce
not
as
hard
as
the
both
PUFA
works,
but
still
hard.
So.
N
If
half
actually
has
that
built
in
today
and
how
retains
that,
where
the
way
each
hash
works
is
there's
a
tech
AK
of
the
header
and
a
nonce,
then
the
East
has
loop,
runs
or
plug
power
runs
and
then
there's
a
keck
AK
of
the
result.
So
a
light
client
could
just
check
the
CAC
acts
and
verify
those
some
clients
use
those
for
denial
of
service
checks
that
you
can
check
the
CAC.
If
that's
wrong,
then
you
don't
bother
calculating
the
heath
hash.
N
H
H
B
Thanks,
okay,
cool,
so
that's
get
too
much
in
the
weeds.
It
sounds
like
what
we've
come
to
is
that
we
are
going
to
tentatively
go
ahead
with
prog
pal
and
by
tentatively
what
we
mean
is
we're
going
ahead
with
it
unless
there's
a
major
problem
found
within
the
testing
or
things
of
that
nature,
is
anyone
feeling,
like
that's
not
the
case
or
there's
different
feelings?.
J
B
F
F
Yeah,
maybe
it
wants
more
comment.
I
would
like
yeah
I'm
I'm
that
guy
again,
let's
not
rush
it
I
mean
when
we
are
ready.
That's
forth,
but
I
personally
sink
two
to
three
months
was
very
ambitious,
especially
if
you
have
to
consider
that
we
needed
six
weeks
between
all
client
releases
and
people
having
time
for
our
creditors,
then
we
maybe
need
to
test
my
heart
for
I.
Think
two,
two
bounces,
if
possible
and
three
months,
ambitious
I.
J
Think
now
what
we
can
do
now
is
that
we're
not
going
to
decide
at
the
timeframe,
but
we
sort
of
decided
we
are
going
to
go,
and
then
we
request
the
comments
from
all
the
people
that
still
need
you
to
work
on
this
about.
How
long
is
this
going
to
take,
and
then
just
based
on
that
information
we
can
decide,
because
we
do
want
everybody
to
be
sufficiently
prepared
right,
yeah.
A
B
A
B
B
Sounds
good
to
me
thanks
Greg,
okay,
so
we
only
have
a
few
minutes
left
and
I
wanted
to
make
sure
offer
you
got
some
time
in.
So
thank
you
miss
if
and
mister
else,
for
attending
and
answering
some
of
these
questions
and
I
look
forward
to
further
collaboration
between
you
and
the
other
core
dev
teams,
as
we
try
to
implement
this.
B
E
S
Support
the
general
idea
of
a
regular
I,
start,
Forks
and
also
I
think
what
I
think
is
better
than
just
a
regular
hard
Forks
is
the
rigor
we're
putting
into
the
milestones
such
as
making
sure
and
releases
her
six
weeks
before
the
any
hard
work
would
happen.
Having
a
time
frame
before
that
six
week
reminder
clients
and
other
people
come
in
and
commit
not
commit.
You
know
just
the
milestones
of
what
we
need
make
sure
that
we
have
our
ducks
in
a
row
before
we
basically
reboot
the
network.
S
C
Yeah,
just
adding
my
voice
of
support
as
well.
I
support
this
I
think
in
particular
having
a
regular
testing
schedule
and
right
making
sure
we
get
ample
testing
in
and
no
changes
or
landing.
You
know
kind
of
just
before
any
sort
of
a
may
not
hard
for
captain's.
I
think
this
is
a
great
idea
and
a
great
step
towards
more
maturity.
Project
management.
O
So,
from
my
perspective,
at
least
from
the
for
the
gas
team,
doing
regular
releases
scheduled
releases
worked
out
really
nice
a
lot
better
than
trying
to
cram
in
features
and
then
eventually
we
do
big
major
releases.
So
I
think
it's
a
from
a
community
perspective
to
it's
much
it's
much
better
to
be
deterministic
rather
than
having
to
wait
half
year
and
wonder
whether
bit
shifting
will
arrive
or
not
so
I'm.
All
for
regular
releases.
S
O
F
Yeah,
so
what
happened
was
constantly
knowbut
took
like
1.5
years.
I,
don't
have
to
exact,
you
know,
but,
having
like
a
strictly
defined
schedule
for
heart,
Fox
tries
to
shoot
this
goal
to
have
these
upgrades
deployed
regularly
to
may
not
that's
not
opposed
having
other
heart
faults
like
power.
Out
of
it
makes
sense.
You
know.