►
From YouTube: Filecoin Core Devs Biweekly #5
Description
Recording for: https://github.com/filecoin-project/tpm/issues/9
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
A
All
right
today
is
thursday
november
5th,
and
this
is
our
core
devs
bi-weekly
meeting
for
falcon
today's
agenda.
First
things
first
are
reviewing
a
number
of
open
or
recent
recently
recently
merged
draft
fips
or
kind
of
open
fit.
Pr's.
Then
talking
about
some
of
the
upcoming
state
upgrades
to
make
sure
that
we're
all
on
the
same
page
about
what's
happening
there.
A
A
test
factors
update
if
there's
anything
new
to
to
share
and
get
people
on
board,
with
general
updates
across
implementations,
loris
lotus
forest
fujon
venus
any
changes
to
the
fit
process,
which
I
don't
think
we
have
anything
new
since,
since
we
discussed
last
last
time
and
then
any
other
kind
of
logistical
questions,
I
think
maxim
was
highlighting.
He
might
have
a
question
about
craftsync
deep
should
be
joining
us
at
some
point
to
talk
a
little
bit
about
external
security
audits
for
the
various
different
implementations.
A
So
we
can
get
to
that
when
we
get
to
that
so
busy
agenda
lots
of
stuff
to
talk
about
first
things:
first,
reviewing
open
fit
pr's
one
one
one
fifth
that
was
recently
merged
to
draft
is
fip
six.
I
don't
know
if
folks
have
had
a
chance
to
to
look
at
this
one.
This
is
a
relatively
small
one.
I
believe
arena
proposed
this,
which
is
removing
the
requirement
to
repay
debt
from
when
for
when
you're
declaring
faults
recovered
iran.
A
I
don't
know
if
you
want
to
give
like
a
very
short,
like
quick,
brief
on
like
why
this
is
proposed,
or
anything
like
that,
just
so
that
we
can
yeah
sure.
B
Yeah,
thank
you.
Yeah,
the
the
fip
is,
as
you
said,
is
quite
quite
simple.
The
idea
is
to
remove
basically
now
there
is
this
mechanism
that
miner
has
sometimes
have
to
pay
fee
if
they
miss,
for
example,
windowpost.
This
can
be
the
case.
B
Consensus
fault
also
causal
fee,
and
if
they
don't
have
enough
on
the
balance,
bot
locked,
unlocked
and
found
what
happens
now
is
that
today
we
registered
the
missing
part
of
the
payment
in
a
variable
that
we
call
the
the
the
feedback
and
when
this
variable
is
not
zero.
Basically
miners
can't
do
some
me
can
call
some
meters
one
of
these
meters.
B
So
there
was
a
reason
for
this
basically,
and
the
reason
was
that
we
didn't
want
people
not
have
power
to
to
be
able
to
to
to
mine
blocks,
but
the
the
the
the
cons
of
this
the
bad
consequence
of
this
in
practice
was
that
people
that
are
in
depth
now
cannot
recover
from
that.
They
they
sectors
the
sectors.
This
are
40,
they
keep
being
faulty
and
unless
they
pay
the
debts,
they
keep
saying
faulty
and
they
keep
paying
fee.
So
they
accumulate
fee
and
they
go
even
more
in
depth
somehow.
B
So
there
was
this
bad
effect
of
like,
especially
for
small
miners
that
they
don't
have,
like,
maybe
other
funds
to
use
to
stay
in
depth
forever.
Somehow
and
clearly
we
don't
want
that,
and
so
we
propose
to
sacrifice
a
bit
of
security,
saying
like
we
risk
a
bit
of
power
table
inflation.
This
is
something
that
we
are
going,
hopefully
to
fix
with
another
fifth
soon
to
avoid
this
bad
situation.
B
Minor,
being
that-
and
you
know
being
that
in
a
very
like
a
bad
situation
where
they
keep
increasing
their
debt
and
the
changes
should
be
very
simple
because
it's
just
you
know,
there
is
a
check
that
we
do
when
we
call
a
meet.
So
that
is,
are
you
adapt
or
not?
If
you
remove
that
check,
everything
should
work
easily.
A
Much
yeah-
and
this
has
gotten-
I
think,
some
some
amount
of
review
from
the
the
mining
community.
Folks
who
have
commented
on
it
have
been
like.
Yes,
please,
let's
help
avoiding
help
avoiding
having
minors,
accumulate
a
lot
of
debt
and
have
this
like
time
sensitive
nature
of
like
I
must
get
funds
to
repay
my
debt
now.
Otherwise,
my
debt
gets
exponentially
bigger
every
single
day.
A
A
Very
thumbs
up
awesome.
Okay,
it's
a
lot
of
thumbs
up
cool,
well,
something
that
I
realized
like
over
the
course
of
the
last
two
weeks.
Is
that
the
the
fit
process
as
we've
described
it
actually
has
a
step
between
draft
chips
and
accepted
fips,
which
is
last
call
flips,
and
so
my
general
process
from
here
on
out
is
that
we
probably
when
we
generally
think
of
fip,
is
you
know,
well-approved
across
implementations
and
well-approved
across
the
community.
A
We
move
the
status
from
draft
to
last
call
and
set
a
deadline
at
which
that
last
call
will
end
like
a
week
or
two
in
the
future,
so
there's
space
for
everyone
to
submit
their
feedback
or
suggest
changes
or
modifications
if,
if
desired,
and
so
generally,
if,
if
folks
in
this
call
feel
good
about
it
and
and
the
community
feedback
has
been
positive,
my
next
step
will
be
moving.
A
These
sorts
of
things
to
last
call
and
setting
a
deadline
for
them,
which
I
believe
is
the
current
state
that
things
like
fit.
Five
are
in
just
went
through
last
call
it's
cool
logistics,
but
general
idea.
Awesome.
Thank
you.
So
much
rna
and
excited
to
help
miners
with
this
one.
I
think
the
the
next
step
there
as
well
is
to
get
an
implementation
of
it
to.
I
think
it's
relatively
tiny
of
an
implementation,
but
just
to
clarify
exactly
what
it
looks
like
awesome.
A
Another
open
this
one's,
an
open
pr
for
a
new
fip,
so
I
don't
think
it's
maybe
quite
ready
for
for
full
review,
but
a
nudge
for
folks
here,
if
there's
any
early
thoughts
or
if
you've
gotten
a
chance
to
look
at
the
add
minor
batch
sector
pre-commit
method,
which
is
a
new
fip
that
alex
north
submitted
a
couple
of
days
ago.
I
don't
know
if
there's.
C
A
Immediate
thoughts
or
or
feedback
here
on
that
fit
from
from
this
group.
D
I
I
think
overall,
this
is
a.
This
is
a
very
good
fit
for
those
that
haven't
caught
up
with
this.
The
pre-commit
operation
does
a
bunch
of
operation
every
single
time
you
do
a
pre-com
every
commit
does
an
operation,
and
instead,
if
we
were
to
do
a
single
pre-commit
message
with
multiple
pre-commit
sectors,
you
would
do
instead
of
if
you
say
that
you
want
to
do
this
for
100
sectors
for
100
sectors,
you
will
pay
this
a
constant
price.
D
But
if
you
do,
if
you
can
have
a
batch
per
commit
call,
then
you
only
pay
that
single
price
once
so.
This
drastically
reduces
the
gas
cost
for
pre-commits,
and
I
don't
know
if
you
saw
the
blocks
blocks
here,
pretty
full
of
pre-commits,
and
this
would
drastically
save
precompass
the
I
don't
know
if
this
is
the
place
where
we
can
have
short
back
and
forth
between
fox,
but
I
did
leave
some
comment
on.
D
E
Yeah,
I
could,
I
could
definitely
be
moved
so
this
really
came
from
alex's.
I
think,
just
like
security
and
practicality
assumptions.
If
you
see
the
link
I
linked
to
what
he
was
saying
for
the
reason
for
limiting
like,
I
think
we
could
go
higher,
it's
just
not
sure
if
we
need
to
based
on
the
growth
rate
that
you
get.
F
But
wouldn't
this
like,
I'm
not
sure
either,
but
wouldn't
it
favor
like
minor,
who
focus
on
fast
ceiling
and
then
like
put
miners
who
are
actually
onboarding
real
storage
at
a
disadvantaged
position.
F
Just
because
now,
like
the
because,
like
it
takes
time
to
to
get
rid
of
real
storage
use
cases
and
like
miners,
who
can
sit
very
fast
and
like
at
higher
volume,
can
stand
to
benefit
more
from
this
change
than
like
in
some
way.
People
bottleneck
by,
like
the
number
of
pre-commit
that
you
can
do.
G
F
F
Me
at
the
moment,
but.
D
F
D
We
can
discuss
there
because
I
think
this
may
be
a
longer
conversation
and
you're
saying
that
there's
an
advantage
and
what
we
should
do,
we
should
calculate
what's
the
advantage,
and
here
we're
talking
about
gas
cost
and
it's
like
in
the
grand
scheme,
there
are
other
parts
that
are
more
expensive
than
this
gas
cost.
So
in
my
opinion,
I
I
would
still
make
this
pass
just
to
save
chain
capacity,
which
everyone
will
have
problems
if
the
chain
the
blocks,
are
full
and
happy
to
discuss
this
in
more.
A
The
discussion
to
the
discussion
of
the
actual
pr
so
cool
sounds
like
there's.
A
Yeah,
so
the
next
item
we
had
here
was
some
of
the
up,
so
I
believe
that's
all
of
the
open,
fips
fit
prs.
We'd
already
discussed,
fit
five
and
moved
that
one
to
accepted,
and
it
just
finished
its
last
call
period
over
the
past
week.
So
that
one
is,
I
believe,
speaking
of
open
state
of
grades,
five
is
on
track
to
be
included
in
the
next
state
upgrade
that
is
happening
in
lotus
magic.
A
I
don't
know
if
now
is
a
great
time
to
talk
about
state
upgrades
or
if
you'd
rather
do
it
in
the
lotus
update,
but
I
believe
there
is
freedle
is
here
as
well
also
to
talk
about
the
proofs
update
going
into
our
next
state
upgrade
when
someone's
ready.
A
I
Yeah,
sorry,
you
had
a
hiccup
with
it
with
a
video
there.
We
are
so
a
little
progress
personally
me
personally
and
the
rest
of
the
team
are
dedicating
that
time
to
to
a
few
things
that
we
need
to
land,
but
what's
in
the
pipeline,
is
creating
a
few
more
tvx
commands
that
we
discussed
last
in
the
last
update
tbx
project.
Concretely,
that
is
gonna
that
that
is
gonna.
Allow
us
to
migrate
existing
test
vectors
to
new
network
versions
to
make
sure
that
new
network
versions
are
also
regression
tested
right
now.
I
This
is
the
missing
link
as
we
keep
adding
new
network
versions
and
we
keep
adding
protocol
versions
and
forex
and
so
on.
We
might
lose
coverage.
So
this
is
the
one
really
critical
aspect
that
we
need
to
land
and
we're
aiming
to
to
land
it
this
week
by
the
end
of
this
week,
there's
already
a
work
in
progress
here,
but
it
is
not
visible
because
it
hasn't
been
pushed,
but
this
will
hopefully
land
as
expected
by
the
end
of
this
week.
I
That's
pretty
much
it,
and
then
we
do
have
block
sequence
vectors,
which
are
constantly
being
deferred
due
to
other
priorities,
but
we
knew
that
we
know
that
they're
super
important
and
others
are
also
waiting
for
them.
So
hopefully
we'll
be
having
some
bandwidth
for
that
in
the
next
week.
A
Awesome
any
questions
for
raul
about
test
vector.
A
A
Awesome
cool:
actually,
let's
take
a
half
second
and
maxim:
do
you
want
to
maybe
ask
any
of
your
graphs
and
questions
now,
because
I
know
hannah
has
another
meeting
that
she
needs
to
run
to.
J
Yes
sure
I
think
we
have
an
islam
on
board
who
can
elaborate
a
little
bit
more
than
me
ruslan.
Please.
K
Hello,
so
we've
got
a
question
about
lip
b2p,
particularly
about
go
graphing
implementation
from
the
code
base.
K
We
see
that
go
graphic.
Implementation
has
a
listener
to
accept
the
incoming
connections
and
also
it
opens
the
connections
to
communicate
with
other
hosts.
So
the
part
that
accepts
connection
is
a
single
function
that
takes
the
incoming
connection
and
just
reads
the
messages
from
it
in
a
loop.
So
it
does
not
move
these
connections
in
some
other
place
like
for
caching,
the
existing
link
and
the
other
function
that
connects
is
using
the
newly
created
connection
only
for
writing
things.
K
L
Writing
yeah
that
that
you
are
correct
in
that
interpretation,
it's
possible,
you
could
hold
connections
in
terms
of
you
know,
making
sure
to
reuse
them.
However,
in
terms
of
making
it
like
more
request,
responsive,
like
there's
specific,
the
graphic
is
specifically
entire
designed
not
to
be
a
request
response
protocol.
L
Any
message
can
include
either
can
include
a
request,
a
response
or
multiple
requests
of
multiple
responses
or
both
and
so,
and
essentially
it's
designed
similar
to
go
bit
swap
in
that
way,
and
so
we
don't
hold
the
connections
so
that
we
can
attempt
to
respond
on
them.
They're
only
unidirectional
and
and
one
thing
when
you're
designing
in
terms
of
making
it
bi-directional.
L
That's
definitely
something
we
could
do,
but
one
thing
that
is
important
when
you're
designing
the
implementation
is
that
it
it
needs
to
be
able
to
process
multiple
requests
and
multiple
responses
in
a
single
message
and
there's
certain
implications
for
that
as
well,
namely
that,
like,
if
you're
sending
multiple
responses
at
once
and
they
contain
the
the
different
responses,
contain
the
same
block
they
may
they
can
choose
to
de-duplicate
it
and
and
only
send
the
block
once
there's
also
and
then
like.
L
If
you
have
two
responses
to
the
same
peer
going
at
the
same
time
and
you
cross
the
block
in
separate
messages,
you
need
to
at
least
be
able
to
be
able
to
handle
the
possibility
on
the
receiving
side
that
that
block
will
get
deduplicated.
L
K
I
K
I
The
reason
the
reason
why
I
was
asking
this,
because
we
have
a
bunch
of
test
ground
test
plans
for
testing
graph
sync,
which
currently
stress
test
graph.
Sync,
the
go
graph
sync.
I
know
it
would
be
a
little
bit
of
a
detour
for
you
guys
if
you're,
given
that
you're
implementing
in
c
plus.
I
But
if
you
manage
to
integrate
your
implementation
into
test
ground
using
a
c
plus
sdk,
then
you
would
be
able
to
benefit
from
all
the
test
plans
that
have
been
written
to
to
test
interoperability
of
of
only
graph
sync
without
having
to
do
kind
of
like
the
whole
deal
flow.
I
Just
just
a
thought
out.
There.
J
Okay
seems
like
definitely
a
good
point
that
you
can
investigate
moderately.
Can
we
I'm
not
sure
if
I'm
aware
about
the
test
ground
that
you
that
you
mentioned?
Where
can
I
take
a
look
on
it.
I
A
Okay
yeah
for
context.
Testground
is
a
project
that
we're
all
built
along
with
a
lot
of
other
folks,
which
we've
used
really
heavily
in
ipvexl,
pdp
and
now
filecoin
to
do
kind
of
simulation
of
distributed
networks
and
stress
tests.
A
lot
of
cases,
and
especially
it's
been
useful
in
fall
coin,
because
you
know
we
can
be
running
lots
of
awesome
test
nets
and
there's
some
things
that
we
still
don't
hit
on
chain.
A
Surprise,
surprise
and
we
want
to
test
those
edge
cases
as
well
or
at
scales
that
you
know
we
haven't
actually
reached
yet
as
a
as
a
network.
So
tescon's
been
really
useful
for
that.
A
Thank
you.
Thank
you,
then.
If
that
was
our
craftsman
question,
then
let's
hop
into
implementations
and
we
can
go
into
the
next
state
upgrade
for
lotus
as
well
magic.
Do
you
want
to
give
a
little
bit
of
an
update
of
kind
of
where
we're
at,
and
we
can
also
talk
through?
What's
coming
in
the
next
state,
upgrade.
H
H
E
It's
just
oh
circle,
yeah,
really
quick!
It's
just
a
few
bug
fixes
one
in
particular
is
going
to
migrate
state
to
make
the
power
actor
actually
reflects
the
total
number
of
storage.
The
total
amount
of
power
represented
in
the
power
tables
claims
a
few
bug
fixes
and
then
a
few
flips,
so
the
biggest
one
being
fifth,
five,
which
removes
the
unnecessary,
investing
and
pre-commit
that
we
went
over
a
week
or
so
ago.
So
that's
it.
H
As
in
terminated,
sectors
are
included
in
the
sector,
set
that
we
use
for
winning
post
and
we
will
drop
that
behavior
and
network
version.
I
think
seven
yeah
it's
affecting
basically
all
miners
who
have
an
non-tribal
portion
of
terminated
sectors
so
other
than
that.
H
A
Yeah
friday,
do
you
want
to
talk
at
all
about
the
proofs
component
of
the
upgrade?
I
think
magic
was
mentioning
it
a
little
bit.
M
Sure
I
can
mention
a
couple
of
things,
so
this
is
specifically
5.4
you're
talking
about
right,
the
the
one
that
has
actual
breaking
changes.
A
M
We
shipped
two
proof
releases,
5.3.0
and
5.4.0.
M
5.3
is
merged
onto
lotus
master
at
this
point,
unless
they
refer
to
the
last
24
hours.
I
hope
not.
5.3
brings
in
mostly
speed
improvements,
so
this
is
now
we
spend
a
lot
of
work
on
improving
verification
of
snipes,
which
you
will
see.
M
Those
improvements
are
on
the
order
of
10
8
to
12
x,
of
verification,
so
we're
down
to
2
milliseconds
for
a
winning
post
at
this
point
for
verification-
and
it
did
so
those
most
of
those
improvements
are
enabled
by
default,
important
for
everybody,
who's,
not
cons,
who's,
not
consuming
the
falcon
ffa
directly
using
the
rust
api
or
actually
building
the
ffi
themselves.
M
There
is
now
an
additional
flag
and
rust
it's
a
feature
flag
and
in
the
ffi
layer,
it's
a
it's
an
environment
flag
which
enables
blast,
which
is
a
new
backend
for
all
elliptic
curve
operations
which
uses
a
bunch
of
hand
optimized
assembly
to
make
it
go
fast,
and
it
has
it's
currently
supported
on
x86
64-bit
systems
and
arm
64-bit
systems.
M
So
if
you
build
for
those,
you
can
include
that
the
reason
it's
not
it's
the
default.
It
simply
is
new,
it's
still
it's
currently
undergoing
and
audit,
and
so
we'll
want
to.
We
want
this
to
be
deployed
and
tested
a
little
bit
before
we
switch
over
to
the
default,
but
can
enable
it
right
now-
and
this
roughly
gives
you
another
2x
of
performance
improvements,
usually
on
most
of
the
little
snug
operations
and
some
other
operations
that
will
use
elliptic
curves.
M
So
that's
5.3.
You
should
be
able
to
consume
that
other
than
those
additional
flags
they're
not
available
without
any
breaking
changes.
I
believe
5.4
has
the
the
braking
changes
that
were
mentioned,
which
require
active
changes
to
consume
them
so,
but
it
also
has
another
feature
that
people
might
be
excited
about,
which
is.
It
does
finally
include
proving
support
on
amd
gpus.
M
It
is
not
as
optimized
yet
as
this
code
that
we
have
for
nvidia,
but
it
is
the
first
release
that
finally
adds
that
with
some
issues
and
finally
getting
that
those
those
worked
out.
So
that's
included.
A
Yeah
cool
and
just
in
terms
of
that
state
upgrade,
I
think
magic
was
saying
that
I'm
kind
of
aiming
to
get
code
out
this
week
or
early
next
week
have
a
week
of
time
where
people
can
can
like
parse
and
integrate
that
and
then
have
the
actual
trigger
epochs
and
for
this
one
because
of
the
proof's
upgrade,
which
is
just
doing
some
bug.
A
Fixing
the
there
will
be
two
different
state
upgrade
epochs
for
introducing
the
new
proofs
and
then
deprecating
the
the
like
previous
version,
and
so,
if
there's
any
questions
about
that,
I
know
that
can
help
answer
that
or
probably
that's.
This
may
be
more
of
a
spec
actors
thing,
so
maybe
actually
why
it
would
be
a
better
person
for
the
exact
trade-off
or
change
over
there.
C
A
Why
friedel,
I
don't
know
if
either
one
of
you
two
want
to
talk
about
that
I
mean,
I
think
it's
just
based
on
the
the
computation
change
in
proofs.
Is
it's
it's
non-compatible,
which
is
why
there
needs
to
be
like
a
changeover
window.
M
Yeah,
the
the
the
the
ceiling
part
of
the
proof
has
an
incompatible
change,
and
so
that's
why,
unfortunately,
we
had
to
introduce
a
new
version.
N
So
is
this
a
change?
That's
gonna
have
to
happen
within
actors,
or
is
this
a
change?
That's
gonna
happen
like
with
the
actual
verifier
node.
M
This
happens
on
both
sides,
so
the
verifier
will
be
able
to
so.
The
proof's
code
is
able
to
verify
both
versions,
all
the
the
old
ones
and
the
new
ones
and
the
actors
need
to
make
sure
to
switch
over
to
the
new
ones.
But
of
course
you
need
to
trigger
the
old
verification
for
everything
that
exists
currently
on
chain.
N
E
E
A
A
All
right,
then,
maybe,
let's
hop
over
to
actually
let's
go
with
venus,
switch
up
our
order.
Go
ahead,
stephen,
if
you
guys
have
an
update
on
where
things
are
at
right
now,.
A
Yes,
if
you
guys
have
any
updates
on
kind
of
where
you're
at
or
what's
coming
next,
for
you.
O
O
Yeah
we
had
started
the
slap
shot
and
checkpoint.
You
notice,
and
we
implemented
this
in
guild,
falcon
yeah
I
mean
veras
and
now
the
betas
also
support
the
snapshot
and
we
could
synchronize
the
change
from
a
point
so
yeah
it
will
be
yeah.
A
O
Fast
than
before,
and
also
we
have
one
person
who
is
working
on
the
test
part,
we
fixed
a
lot
of
unit
testing
and
also
integrate
the
test.
Victor
and
now
I
will
say
that
we
have
passed
about
75
percent
or
eight
percent
of
test
cases
of
the
test
picture,
which
is
very
good.
A
O
Okay,
yeah:
no,
it's
yeah,
it's
okay,
okay,
so
we
also
impediment
and
the
network
versions
and
to
support
and
yeah
super
forks.
O
So,
based
on
that,
we
were
thinking
that
the
chest
organization
will
be
much
better
than
before,
and
actually
we
also
purchased
two
powerful
hardware
in
the
computer,
yeah
yeah,
it's
kind
of
slow.
Actually,
so
we
will
think
in
next
two
weeks.
Perhaps
we
will
have
an
achieve
a
milestone
to
you
know
to
sync
and
all
the
chain
and
yeah
to
the
minute.
Yeah.
K
O
The
latest
airport
yeah-
this
is
okay,
the
current
status
and
also
next.
We
will
support
something
like
to
support
the
json
api,
which
is
complete,
which
is
compliant
to
the
notice
and
those
minor
so
that
we
could
have
as
well
as
chess
anchor
and
also
to
work
with
doterra's
binder,
and
we
can
combine
them
together
to
to
have
one
system
and
for
many.
O
O
So
this
way
is
to
make
sure
that
messages
can
be
pushed
into
the
chain
and
yet
to
guarantee
that
and
also
yeah.
It
is
kind
of
independent
part,
and
it
could
also
a
saver
to
some
other
components.
You
know
to
just
push
the
message
to
the
messenger
and
yeah,
so
it's
like
this
is
because
the
principle
of
the
venus
is
to
is
to
separate
and
different
parts
of
all
the
yeah
and
into
different
implementation.
So,
okay,
so
the
next.
O
The
the
major
thing
is
also
the
chain
synchronization,
so
yeah.
We
hope
that
we
could
have
something
done
yes
in
next
two
weeks.
Okay,
that's
all.
A
Thank
you
awesome.
That's
super
exciting,
so
being
able
to
sync
to
the
to
the
current
mainnet
epoch
also
has
the
spec
actors
v2.
So
have
you
guys
actually
already
done
the
spec
actors
v2
upgrade
for
actors.
O
Not
yet
yeah,
but
right
now,
because
we
have
it
yeah,
because
we
have
the
slap
shot
and
so
we
need
yeah.
We
could
and
have
different
person
working
on
the
different
yeah
different
part
of
the
whole
chair
right.
So
yeah
we're
working
on
that
right
now.
P
Sure
they
give
you
a
quick
update,
so
we
basically
are
working
towards
like
three
major
goals,
one
being
just
initially
syncing
with
the
space
race
for
actors
v1
up
until
the
network
upgrade,
secondly
syncing
with
mainnet,
and
thirdly,
integrating
storage,
miner
and
markets.
P
P
Secondly,
we're
focusing
on
syncing
with
mainnet,
and
so
in
order
to
do
that,
we're
doing
the
actor's
v2
upgrade.
We
have
moved
all
the
types
into
another
crate
in
order
to
facilitate
this,
but
we
haven't
started
making
the
actual
changes
and
we'll
start
doing
that
most
likely
after
we
get
the
initial
sync
done.
P
Also
in
order
to
sync
with
mainnet
the
one.
Some
functionality
that
needs
to
be
done
is
basically
like
processing
the
blocks
that
come
over
gossip
sub
and
actually
like.
Staying
in
sync,
because,
like
our
primary
focus,
has
been
that
initial
sync,
we
are
working
on
this
we're
figuring
out
the
best
way
to
form
tip
sets
from
the
incoming
blocks
and
sync
towards
them.
So
we
have
somebody
working
on
that,
but
otherwise
yeah
that
definitely
after
the
initial
sync,
this
is
going
to
become
our
main
focus
and,
lastly,
markets
and
storage.
P
Finder
integration
have
we've
been
chipping
away.
We
finished
implementing
the
pay
channel
functionality,
but
since
it's
difficult
to
test
without
upgrading
to
v2
actors,
we've
just
left
that,
like
as
like
pr
open
and
after
we
land,
v2
actors,
we'll
test
that
more
thoroughly
and
then
merge
it
and
then
we're
working
on
getting
storage,
miner
and
forest
connection
working
just
been
iteratively
fixing
problems
we're
almost
at
the
point
where
we
can
get
it
initialized,
which
I
think
is
the
big
hump,
so
yeah,
pretty
close
feeling
feeling
pretty
good.
P
Overall
we've
been
chipping
away,
I
don't
know
austin
do
you
have
anything
to
add.
N
Oh,
that's
pretty
much
it
yeah,
just
the
reason
for
just
to
kind
of
clarify
the
reason
we're
holding
off
on
starting
the
v2
upgrade
is
just
for.
We
didn't
want
to
lose
the
test
coverage
of
all
the
conformance
vectors
we
had
so,
and
also
a
lot
of
just
like
making
sure
that
we
can
get
all
the
coverage
from
all
the
transactions
that
happened
during
space
race,
but
yeah,
we'll
we'll
transition
right
after
that
right
after
that
happens,.
J
Thanks
so
as
of
juan
we,
we
were
busy
with
more
generally
big
pr,
which
is
a
big
refactoring
of
the
changing
stuff
and
graph
sync
and
all
basically,
it's
a
big
layer
of
connectivity
which
was
not
yet
been
merged.
We
are
still
in
the
process,
but
a
lot
of
stuff
have
emerged
and
we
had
to
fix
it,
namely
the
graphing
update
issues,
also
the
changing
stuff.
J
We
have
also
integrated
spec
doctor
swig
2..
We
have
integrated
them,
but
not
yet
switched
basically
for
the
pretty
much
the
same
reason
as
the
force
guys.
We
are
still
need
to
test
all
the
integration.
Well,
what
basically,
how
good
it
will
work
after
the
integration
of
specter,
spec
actors-
v2,
I'm
not
sure
I
have
mentioned
previously,
but
we
are.
We
have
decided
that
we
will
move
on
with
the
developing
our
own
version
of
actors.
J
Currently
we
had
done
in
chrome
account,
and
just
today
we
have
finished
with
the
architecture.
So
we
still,
we
are
getting
close
to
really
big
ones.
The
minor
actor
and
all
the
other
big
ones
market
is
one
of
them,
but
this
is
only
the
first
one
and
what
we
are
currently
working
is,
as
previously
russell
mentioned.
J
We
are
debugging
the
33
value
and
making
it
work
the
whole
flow
and,
in
parallel,
still
working
on
updating
the
actors
to
be
compatible
with
latest
versions
yeah
and
as
we
are
implementing
our
own
version
of
actors,
we
are
switching
them
one
by
one
to
be
for
foohan
to
be
working
with
the
actual
version
of
on
written
on
c,
plus,
plus
and
not
imported
from
the
seagull
actors.
A
All
righty,
then,
all
right
next
on
agenda
was
to
review
any
changes
to
the
fit
process
itself,
but
we
don't
have
any
pr's
or
issues
for
that
so
moving
right
along.
Oh,
it
looks
like
we
don't
have
a
deep.
Maybe
we
have
david
just
to
talk
a
little
bit
about
external
security
audits,
for
the
various
implementations
and
kind
of
when
different
groups
feel
like
they
might
be
ready.
A
We've
been
chatting
a
little
bit
with
some
of
the
the
folks
that
we
work
with,
have
worked
with
on
auditing,
doing
security
audits
of
lotus
and
would
love
to
encourage
different
groups,
as
you
get
to
a
point
where
the
code
is
settling
enough,
that
this
would
be
useful
to
also
do
security
audits
so
david,
I
don't
know
if
you
wanna.
G
I
think
you
pretty
much
converted,
molly
and
so
just
like
to
give
just
a
little
bit
more
detail.
G
As
you
know,
and
as
you
can
see
on
the
spec
website,
we
actually
have
have
multiple
audits
by
different
security
firms
from
host
authority
to
ncc
to
sigma
prime
and
more,
and
these
audits
typically
come
when
there
is
a
any
significant
release
or
when
a
second
release
is
going
to
happen
or
when
we
make
a
significant
change
on
the
code
base
right
and
so
we
we
have
worked
with
multiple
security
firms
that
have
different
sets
of
expertise,
to
make
sure
that
the
the
right
code
gets
reviewed
by
the
right
people,
and
so,
given
that
well,
these
other
implementations
of
all
coin
are
emerging.
G
It
would
be
very
good
and
very
valuable
if
we
could
know
kind
of
like
the
the
the
timeline
in
which
we
want
to
announce
this
or
the
world.
As
in
here's,
this
new
implementation
to
haven't
had
it
beforehand
and
given
that
we
already
have
these
teams
that
are
ready
that
are
familiar
with
altcoin
that
have
audited
the
reference
implementation.
G
They
can
do
a
more
complete
job
auditing.
These
other
implementations
as
well,
and
so
for
us,
if
you
can
give
us
kind
of
like
a
month
and
a
half
heads
up
that
will
be
ideal
a
month.
We
can
also
try
to
make
it
work.
G
Ultimately,
we
are
always
very
dependent
on
the
security,
firm's
availability
and
their
team's
availability
as
well,
so
the
the
sooner
the
better,
and
if
there
is
already
like
a
timeline
that
we
could
like
try
to
align
and
then
try
to
adjust
as
things
progress
that
also
works
well
and
we
do
as
brooklyn
labs.
We
do
have
some
capacity
right
now
to
sponsor
these
audits,
at
least
like
a
first
iteration,
especially
given
at
the
net,
that
those
implementations
will
be
released
for
the
first
time.
G
So
they
ask
is
keep
us
on
the
loop.
Let
us
know
what
you
have.
Let's
make
sure
that
these
implementations
get
audited,
let's
make
sure
to
get
everything
fixed
before
releasing
the
making
the
release
and
then
like.
Let's
be
good
citizens
of
the
open
source
community
and
publish
these
reports
so
that
people
know
what
was
out
how
and
by
whom.
A
Yeah
and
I'll
add
to
that
that
you
know,
of
course,
all
of
the
work
that
we
are
doing
is
a
moving
target,
and
so
there's
never
a
like
great
we're
code
frozen.
This
blockchain
will
never
upgrade,
never
add
any
more
features
or
changes,
and
so
we're
you
know
since
because
we're
always
going
to
be
a
moving
target
and
that's
expected,
we
shouldn't
block
on,
like
a
finished
state
before
doing
a
an
audit.
A
We
should
you
know,
snapshot
as
of
a
time
when
we've,
you
know
the
code
base,
has
solidified
for
a
set
of
functionality,
audit
that
and
then
continue
having
additional
audits
that
kind
of
cross
over
whatever
has
changed
between
between
spaces.
So
lotus
has
done
that,
for
example,
of
having
lots
of
different
audits
at
different
times
which
cover
additional
functionality.
A
So
I
don't
know
if
anyone
has
any
early
signal
on
when
you'd
flag
that
you
might
be
ready
for
a
an
audit
that
that
covers
kind
of
you
know
either
through
actors
v2
or
through
some
period
of
of
time.
But
I
know
that
there's
maybe
some
availability
to
be
freeing
up
in
like
the
early
december
time
frame.
If
any
would
be
ready
around
that
time,
exactly.
P
I
I
think,
like
the
like,
thanks
for
sharing
all
that
information,
it
gives
us
a
lot
of
clarity,
and
I
think
you
know
we
don't
know
the
exact
timing
when
we'll
be
ready,
but
it
may
not
be
far
off
of
that.
But
yeah
we'll
have
to
discuss
as
a
team
and
see
how
we're
doing
but
I'll
be
in
touch
with
you,
and
we
can
organize
that.
G
Awesome
yeah
like
either
being
me
molly
or
deep.
He
typically
joins
these
calls
as
well,
and
so
we
can
then
take
your
signal
and
make
it
happen.
P
A
Thank
you.
That
was
a
quiet
anyways.
I
think
you
can
lip
read
what
I
was
saying
there
anyways
the.
What
I
was
trying
to
say
was,
I
don't
think,
they're
ready
and
yet
to
bring
to
this
meeting,
but
there
are
a
number
of
open
issues
in
the
fip
repo
that
are
discussing
some
proposals.
So
thank
you,
stephen
for
writing.
One
up
and
there's,
I
think,
also.
A
Oh
yeah,
there's
one
by
sarah
for
implementing
a
tiebreaker
for
forks
at
equal
weight.
So
there's
a
couple
of
open
issues
that
are
proposals
potentially
for
creating
a
foot
that
don't
yet
have
a
fip
so
nudge
for
this
group
to
kind
of
discuss
there.
And
if
you
have
any
questions
or
want
to
talk
about
things
real
time.
We
can
also
use
the
implementation
channel
and
phil
slack
to
coordinate
additional
discussions.
A
But
I
think
the
general
general
practices
once
things
get
to
a
fifth
state,
we'll
bring
them
to
a
forum
like
this.
But
while
they're
still
in
issue
discussion
space,
we'll
we'll
discuss
async
with
the
community,
there.
O
And
monique
yeah
excellent
for
the
issue
I
submitted,
which
is
about
the
return
value
you
have
to
add.
The
true
value
to
which
job
is
I
mean
alex,
has
a
comment.
Is
that
if
this,
you
should
go
through
the
fp
process
or
just
yeah
implemented
into
the
system?
So
when
you
think
is
a
process
issue.
O
A
Question
generally,
our
practice,
like
the
way
that
we've
been
thinking
about
the
fit
process,
is
that
anything
that
is
either
it
has
like
a
design
component
to
it,
where
it's
like
a
there's,
a
there's,
design,
questions
or
there's
security
or
crypto
economics
questions.
We
want
to
make
sure
that
teams
have
an
opportunity
to
to
discuss
and
review
on
that.
A
All
of
those
things
should
go
through
a
fit
process,
even
if
it's
you
know
a
small
improvement
or
or
a
small
optimization,
but
things
that
are
bug
fixes
or
things
that
are
like,
like
logistics,
but
not
not
not
features
and
and
wouldn't
have
that
level
of
like
discussion.
The
additional
effort
of
going
through
a
fit
process
is
like,
maybe
minimal,
versus
just
going
ahead
and
doing
it.
A
O
Yeah-
and
I
agree
that
yeah
but
okay
yeah
sometimes
you
know,
for
example,
like
this
issue-
is
yeah
kind
of
a
little
change
of
the
of
the
actor
and
actually
about
the
protocol.
But
yes,
and
also
yeah
very
minor,
and
it's
not
like
this
big.
Yes,
big
modification
updating
is
not
like
this,
but
so
yeah.
We
should
have
a
clear
and
a
definition
about
which
one
yeah
should
go
through
the
fab
process
and
which
one
which
yeah
for
this
one
yeah.
O
I
said
there
are
many
and
actually
the
yeah,
perhaps
zero,
five
zero.
Six
are
very
small
right.
So,
okay,
yeah.
A
A
I
completely
agree:
okay,
I'll
I'll,
try
and
add
something
to
the
to
the
fit
repo
itself
where
we
describe
like
what
should
go
through
a
fip
that
clarifies
that
stance
and
everyone
can
can
review
it
there
as
well.
That
like
tries
to
encode
our
existing
mental
model
for
things
that
are
like
bug,
fix
or
like
minimal,
like
small
technical
improvement
versus
feature,
it's
a
fuzzy
line,
and
so
we're
trying
to
walk
it.
A
I
think
we're
always
gonna
have
a
but
we'll
try
and
we'll
try
and
make
it
as
clear
as
possible
so
that
it's
easy
for
everyone
to
diagnose
that.
A
But
I
think
this
sounds
like
the
the
specific
change
you're
proposing
sounds
like
a
like
implementing,
like
a
probably
having
an
open
issue
for
this
in
the
sp,
the
lotus,
spec
actors,
repo,
and
then
we
can
all
kind
of
generally
change
to
have
that
correction,
improvement
accuracy
to
to
all
of
our
actors,
implementations
without
doing
a
full
flip
around
it
yeah.
I
agree.
I
agree
with
the.
A
A
Cool
we're
two
minutes
left.
Does
anyone
else
have
anything
they
wanted
to
discuss
with
this
group.
A
Alrighty
then
cool!
Well,
that's
that
is
the
end
of
our
meeting
for
the
week.
Then.
Thank
you
all
so
much
and
we'll
see
everyone
here
again
in
two
weeks.