►
From YouTube: Filecoin Core Devs Biweekly #9
Description
Recording for: https://github.com/filecoin-project/tpm/issues/22
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,
good
morning,
good
afternoon,
good
evening,
everyone
welcome
to
the
ninth
file
calling
core
devs
by
weekly
meeting
and
the
first
in
2021
happy
new
year
today.
We're
welcoming
megan
and
philip
from
the
falcon
foundation
excited
to
have
you
folks
here
our
agenda.
For
today.
A
I
wanted
to
start
by
bringing
up
the
by
quick
briefly
discussing
the
chain
health
instrument
that
we
experienced
in
december,
that
some
folks
here
may
be
familiar
with
we'll
then
go
over
receiving
our
usual
updates
from
the
various
implementations
and
then
there's
at
least
a
couple
of
slips
that
we
should
talk
about,
and
maybe
we
can
talk
about
the
new
interop
network,
that's
being
launched
in
order
to
help
facilitate
the
testing
of
device
implementations.
A
Let
me
just
quickly
show
that
cool
yeah,
so
maybe
to
briefly
start
yeah.
So
on
december,
19th
we've
published
some
communication
about
this
already,
but
on
december
19th
the
falcon
mainnet
experienced
a
a
few
hour
outage.
The
underlying
incident
was
basically
a
bug
in
sex
actors
code.
There
was
a
non-determinism
in
in
one
of
the
actors,
so
the
incident
response
itself
was
I'd,
say
pretty
good.
A
On
the
whole
we
had,
then
we
were
able
to
be
alerted
and
resolve
the
incident
all
within
a
few
hours
and
for
more
details.
I
think
we're
putting
out
a
blog
post
fairly
soon.
I
was
wondering
if
anyone
had
questions
about.
B
B
I
mean
it's
not
a
question
about
that
in
particular,
but
yeah
we
were
discussing
as
a
team
as
to
how
we
wanted
to
handle
that
situation.
It
doesn't
seem
like
it's
something
that
we
will
be
able
to
match,
like
you
know
the
the
undefined,
or
rather
non-deterministic
behavior
pre
for
version
nine,
so
yeah.
I
was
just
wondering
what
what
the
I
guess
the
plan
is
for.
The
other
implementations
that
are
gonna
have
to
deal
with
this
as
well.
A
Yeah
for
a
question,
stephen:
is
it
clear
by
this
point
whether
the
other
implementations
will
have
to
implement
the
bug?
Essentially,
so
they
will
have.
C
To
implement
well,
no,
it's
not
clear,
they
may
have.
D
C
E
So
from
my
like,
I
I
don't
know
whether
it
happened
for,
for
example,
for
messages
in
size
of
two
or
three,
where
this
pack
was
triggered
with
two
or
three
deadlines.
But
if
it
was,
then
the
work
around
will
be
to
replicate
what
we
were
doing
and
what
would
most
of
the
network
would
do,
which
would
be
insertion
order.
E
C
I
just
want
to
clarify,
though
you
said
before
that,
even
if,
like
with
two
entries
there'll,
be
a
one
out
of
eight
chance
of
changing
the
order.
Correct.
E
Yeah,
that's
why
I'm
some
like
it's
there's
very
high
chance
that
there
was
no
no
instance
of
this
being
triggered
previously.
We
need
to
run
around
a
full
chain
scan
for
that.
We
should
probably
do
that
like
schedule,
that.
A
Yeah,
I
think
the
short
answer
is
with
high
probability
we
might
get
lucky,
but
with
further
analysis
is
needed
to
figure
out
exactly
what
what
messages
are
on
chain
and
how
implementations
will
have
to
handle
it.
We'll
we'll
we'll
do
that
and
get
back
to
you
before
the
next
core
week's
cortex
meeting
in
two
weeks.
B
Yeah
cool
thanks
yeah,
because
we
we're
debating
whether
like
we
should
just
start,
you
know,
being
v,
nine
and
four
compatible
or
if
there's
anything
else,
that
anybody
who's
implementing
actors.
I
guess
the
only
other
team
implementing
actors
is
the
is
the
fujan
team,
so
just
seeing
what
they
were
doing
and
how
they
were
handling
this,
but
yeah
that
that's
that's
great.
Thanks.
C
B
C
B
Oh
okay,
yeah
I
mean
so
that
that
kind
of
I
mean
obviously
we're
gonna
need
it
eventually,
when
we
upgrade
to
actors
v3
and
future
forks
going
forward.
But
if
you're
talking
about
pre
version
nine,
I
guess
that
kind
of
depends
on
whether
like
depends
on
when
we
get
this
analysis
of
whether
we're
gonna
hit
those
bugs
in
v9
like
where
it's
it's
not
entirely
clear.
B
C
B
Yeah,
I
don't
we
don't
plan
on
implementing
the
v1
or
v0
to
v2
actors
upgrade
because
that's
all
pre-made
net
and
there's
just
you
know
just
so
many
it's
a
it's
a
chunky
code
base.
I
I
was
talking
to.
I
have
a
thread
going
on
yesterday
on
how
to
generate
a
v2
genesis,
because
that's
kind
of
where
we
want
to
start
like
we
have
v1
actors
implemented.
It's
just
like
the
state.
B
Migration
is
a
lot
of
a
lot
of
work
that
needs
to
be
put
in
to
not
even
sync
mainnet.
A
Cool
okay,
yeah
thanks
for
that
discussion,
feel
free
to
ask
more
questions
at
any
point
regarding
the
incident
or
just
the
work
involved
with
just
my
questions,
let's
jump
into
updates
now
time
for
our
usual
game.
Maybe
we
will
hear
from
fujon
first
today.
F
Yeah
sure
thanks
everyone,
so
for
the
update
we
are
currently
were
able
to
download
all
the
data
from
the
minute.
Yes,
they
have
told
me
that
it
was
downloaded
from
the
like,
like
I
actually
downloaded,
but
I
have
really
checked
and
it's
actually
a
snapshot
so
just
to
make
it
clear
for
you
and
we
start,
we
have
started
interpreting
all
the
messages
and
gain
the
heat
up
to
the
current
main
net
height,
just
four
hundred
two
thousand
something
it
well.
F
It
was
yesterday,
so
we
are
currently
in
a
pro
in
the
process
of
interpreting
messages,
but
we
have
faced
an
issue
with
not
so
fast
the
pace
of
the
interpretation
itself
partially.
It
is
related
to
the
hardware
we
are
using,
so
it's
just
a
regular
laptop
and
we
are
currently
deploying
the
solution
to
the
more
or
less
viable
hardware,
but
we
also
going
into
the
profiling
and
seeing
what
exactly
are
the
bottlenecks
and
what
takes
lots
of
time,
the
most
time
during
the
interpretation.
F
In
parallel,
we
are
going
through
the
stability
testing
of
the
markets,
so
functionally
they're
ready,
and
we
have
figuring
out
whether
software
is
itself
stable
enough
to
run
this
miner
and
node
yeah,
and
we
have
two
actors:
two
major
actors
left
to
be
compatible
with
a
lot
of
c2
actors
which
are
storage,
minor
actor
and
market
actor.
F
So
the
storage
market
actor
is
obviously
the
biggest
one.
So
we
expect
it
to
be
either
ready
or
close
to
be
ready
by
the
next
by
by
weekly
meeting
so,
and
the
market
probably
will
also
be
ready.
But
at
this
point
so
either
by
the
next
bi-weekly
meeting,
we
will
have
all
the
ones
after
the
next
one
will
be
ready
to
conclude
the
video
actors.
F
A
No,
that
sounds
great
yeah.
So
that's
a
lot
of
work
if
2021
hard,
oh
yeah,
let's
hear
from
maybe
someone
from
venus.
G
Yeah
hi
everyone
and
welcome
back
yeah
back
from
your
holiday
and
we
are
during
the
holiday
actually
yeah
we're
in
china,
we're
not
in
jordi,
and
so
we
are
have
been
working
for
about
a
few
weeks
and
to
make
our
importation
workable
in
collaboration
and
network
and
the
main
network
yeah,
which
is
good,
and
we
think
we
we
have
just
passed
as
a
test
incorporation
network
and
we
have
set
up
one
node
today
in
the
main
network
yeah
I
can
put
our
load
and
yeah
minor
id
and
in
the
chat
room
yeah,
you
could
check
that
and
yeah
we
have.
G
The
message
is
the
pre-commit
sectors
and
the
proof.
Communicators
yeah
message
is
on
board
and
we
also
have
one
and
when
the
post
message
is
on
board
so
yeah,
you
could
say
that
we
yeah.
We
already
have
power
near
right
now,
so
yeah.
If
everything
goes
smoothly,
I
was
thinking
that
we
could
have
the
first
official
version,
which
is
workable
in
midnight
and
next
yeah
tomorrow,
yeah
we'll
do
that
and
we'll
have
this
announcement:
okay,
yeah,
which
is
very
cool,
I
think
so.
G
Well,
we
have
this
milestone
and
the
next
two
weeks.
We
think
that
we
will
do
something
to
yeah
to
stabilize
the
importation,
yeah
well
and
actually
well,
where
were
a
long
episode?
We
find
some
problems,
so
we
just
fix
them
and
we
should
use
the
first
thing
and
the
next
one
is.
We
need
to
have
some
documents.
G
First,
okay,
and
we
we
plan
to
have
english
and
chinese
version
of
departments
and
also
yeah
for
the
developers
and
users
based
on
that-
and
we
may
add
some
serial
comments
to
make
it
much
easier
to
use
yeah.
This
is
the
first
thing
we
need
to
do.
I
will
say
next,
two
weeks
and
after
that
we
will
start
our
milestone
two,
which
is
to
support
the
distributed
men
in
poor,
and
that
is
the
plan
so
yeah.
So
any
questions.
A
No
sounds
great.
Congratulations
welcome
to
mainnet.
That's
that's!
Absolutely
fantastic
news!
Shooting
it
at
the
minor.
The
id
is
f
zero.
One
two,
eight
seven,
eight
eight
and
I'd
say
that's
right
that
the
venus
created
minor
on
magnet,
which
is
which
is
great
well
done.
Maybe
let's
hear
from
someone
from
forest.
H
Hey
so
over
the
last
I
guess
month
or
so,
since
we
we
last
met,
we've
actually
completed
all
the
core
functionality
that
we
wanted
to
to
start
to
attempt
to
sync
with
mainnet.
So
a
couple
of
things
that
we
had
worked
on
is
finishing
our
like
staying
in
sync
mechanism.
So
you
know
what
we
do
sort
of
after
the
initial
sync.
So
just
the
logic
for
changing
the
syncing
state
to
chain
follow.
H
H
We
had
some
issues
generating
genesis
from
v2,
but
I
think
eric
figured
that
out
yesterday,
which
is
great
and
then
after
that,
like
we're,
excited
to
try
syncing
with
interop
cadet
once
that
is
up
and
then
finally,
once
we
get
those
two
working
just
syncing
with
mainnet
and
the
reason
that
we're
going
in
this
order
is
just
because
there's
so
much,
the
state
is
so
large
on
v-net
that
it's
hard
to
debug
using
on
on
mainnet,
when
there
is
a
discrepancy.
H
So
that's
why
I
was
kind
of
starting
with
local
devnet,
then
interrupt
net
and
then
mainnet
we've
also
been
updating
our
live
ptp
to
the
latest
version
and
yeah.
I
think
that's
that's
about
it
exciting
to
be.
At
this
point.
We're
also
have
been
talking
with
molly
about
setting
up
an
audit
at
some
point
in
the
next.
You
know
one
to
two
months,
so
yeah,
that's
about
it.
A
Fantastic
yeah,
if
I
remember
correctly
from
your
last
update,
you
had
a
set
of
goals
that
you
wanted
to
achieve
before
you
were
thinking
about
an
audit
and
based
on
everything
you
said,
I
think
you've
met
all
of
the
schools
already,
which
is
yeah.
A
I
love
that
yeah
fairly
brief
lotus
update.
Obviously,
we've
been
on
holidays
for
a
good
chunk,
but
for
the
most
part,
we're
continuing
to
be
somewhat
internally
focused
in
terms
of
making
making
the
lotus
functionality
better.
Some
focus
on
deal
making
focus
on
overall
performance,
so
we've
had
a
whole
bunch
of
improvements
going
there
we'll
probably
be
cutting
an
optional
one
for
one
release
next
week.
That
introduces
some
of
those.
A
Some
of
those
improvements,
the
rest
of
our
work
has
been
for
towards
the
next
network
upgrade
which
will
be
introducing
fip
10.
Is
the
plan
and
we'll
be
talking
about
that?
A
bit
more?
That's
hoping
to
go
out
end
of
january
with
an
upgrade
early
february
is
the
current
timeline,
so
yeah
cool,
very
cool
megan
and
philip.
A
I
was
wondering
if
either
of
you
or
both
of
you
would
like
to
do
an
intro
or
any
updates
from
the
foundation
that
y'all
would
like
to
provide.
I
Yeah
I
mean
we're
just
sort
of
chugging
along
at
the
foundation
kind
of
excited
to
you
know
finally
get
into
into
this
meeting
and
figure
out
where
we
can
be
helpful
with
with
fips
in
the
fit
process.
I
I
don't
know
if
philip,
you
want
to
talk
at
all
about
deaf
grants
or
anything,
but
you
know
we're
I
feel
like
we
have.
I
want
to
sound
frustrated.
We
spent
a
lot
of
time
trying
to
get
all
the
ducks
in
a
row
to
get
all
the
like
corporate
infrastructure
and
everything
in
place,
and
so
I
am
so
super
excited
to
actually
be
doing
some
of
the
work
that
the
foundation
is
set
out
to
do
as
far
as
being
involved
in
the
actual
governance
of
the.
J
Network
there's
so
much
more
to
add
to
that
really,
I
don't
think
that's
the
right
form
of
form
for
deaf
grants
or
anything
like
it,
but
just
piling
onto
megan
super
happy
to
be
here
and
we're
excited
to
be
participating
in
the
governor's
process,
and
I
think
I
hope
you'll
all
be
seeing
much
more
of
us
over
the
coming
months.
A
Yeah
sounds
great
we'd
love
to
you've
got
to
appreciate
when
setting
up
the
corporate
infrastructure
could
be
more
challenging
than
you
know.
Launching
a
blockchain
itself.
A
Yeah
yeah
welcome,
welcome
to
happy
folks
here,
cool,
I
think
the
next
probably
next
order
of
business
is
to
move
on
ship
10..
This
is
the
optimistic
window
post
trip
that
we've
kind
of
extensively
been
discussing
since
november.
A
G
G
Yeah,
okay,
yeah
just
one
one
concern.
It
comes
to
my
mind,
which
is
about
about
the
security
consideration,
I'm
thinking
about
the
dp
dispute
and
attack
so
yeah
in
this
mechanism,
and
I
would
think
one
could
send
out
a
lot
of
dispute
message
to
a
network
and
to
to
to
slow
down
the
chain.
It's
because
every
dispute
message
can
take
some
time
to
to
yeah
to
and
yet
to
verify.
G
C
So
the
dispute
will
currently
cost
normal
gas,
so
you
could
do
the
same
thing
by
just
sending
like
lots
of
other
messages.
C
The
let's
see
we
could
say
that
the
first
incorrect,
but
otherwise
correct
dispute
is
the
only
one
accepted.
I'm
concerned
about
doing
that,
though,
because
there
may
be
tricky
ways
to
like
submit
a
a
dispute
that
the
chain
thinks
is
like
correctly
formed
but
incorrectly
disproves
something
when
actually,
there
is
a
correct
dispute
that
actually
disputes
that
proof.
C
So
I'm
just
slightly
concerned
about
doing
that,
because
it
might
open
up
an
attack
where
you
can
like
incorrectly
just
be
your
own
proof
to
sort
of
delete
it
from
the
chain
and
then
anyone
else
could
just
like.
C
Bad
post
by,
I
don't
think
it's
yeah,
like
I
don't
think
it's
it's
like.
I
think
there
is
a
way
to
do
this,
basically
just
make
sure
like
you
get
all
the
way
down
to
like
the
dispute
part
and
then,
instead
of
so
like.
Currently,
what
happens
is
when
dispute
finishes
it,
if,
basically
sorry
when
it
gets
to
the
roof,
it
fails.
If
it
fails
to
dispute
the
proof.
C
Instead,
we
could
return
a
failure
value
instead
of
actually
just
like
aborting
and
then
actually
remove
it
as
people,
I'm
just
yeah
again,
I'm
still
concerned
that
we
there
a
lot
of
ways
that
can
go
wrong.
There
are
other
ways
we're
like
we
could
actually
update
the
state
where
we
think.
Oh,
it's
like
usually
when
we
do
like
this.
We
assume
that
the
method
only
completes
or
everything
finishes,
but
in
this
case
we
could
accidentally
like
mark
something
as
faulty
or
do
something
else.
I
guess
the
civ
should
catch
that,
but
yeah.
C
My
hope
here
is
that
gas
costs
should
cover
this.
A
Yeah,
this
is
good
to
flag,
though,
in
that
we've
talked,
we've
talked
about
the
high
level
idea
of
optimistic
or
afghan
window
post
verification,
but
it
would
be
good
to
go
over
the
the
details
of
how
of
like
how
it's
finally
been
sketched
out
in
the
fifth.
So
yeah
stephen,
if
you,
if
you
do,
want
to
share
that,
maybe
you
know
it'll
support
more
discussion.
G
Yeah,
I
have
a
little
problem
out
there.
The
whole
thing
is
good
and
yeah.
It
will
improve
the
yeah,
improve
the
bandwidth
and
which
is
very
good
for
yeah
for
the
yeah
to
get
to
mitigate
the
condition
of
the
current
state.
It's.
C
C
Okay,
I
can
give
a
very
short
one
then,
so
the
short
version
is
basically
the
two
parts
of
this
one
when
a
a
submit
with
a
post
message
goes
to
the
chain
as
long
as
it's
not
recovering
power,
as
long
as
just
proving
the
status
quo,
it
will
be
optimistically
accepted
and
stored
and
like
power
will
continue,
and
nothing
else
will
happen
later.
C
A
miner
can
or
some
other
miner
or
really
anyone
else
can
look
this
up
on
chain
and
decide
or
like
basically
test
the
proof
locally,
actually
validate
it
and
if
it
doesn't
validate,
they
can
submit
a
dispute
from
the
post
message.
The
dispute
window
post
message
contains
the
deadline
where
the
proof
has
been
stored
and
the
index
in
the
store
proofs
table
on
chain
the
chain
will
then
look
up
the
proof
of
that
index
fold
out
test.
C
It
basically
run
the
normal
window
post
code
determine
whether
or
not
the
proof
is
actually
correct.
If
it's
incorrect,
the
the
target
miner
will
be
fined
based
on
the
amount
of
power
they
correctly
approved.
C
The
sectors
that
are
incorrectly
approved
will
be
marked
faulty
and
the
person
submitted.
The
dispute
will
be
given
a
small
reward.
This
is
the
change
we
made
last
night
in
order
to
cover
the
cost
of
actually
submitting
these
disputes
because
it
does
cause
gas
yeah.
That's
the
general
idea,
the
couple
of
interesting
parts
here,
one
if
any
familiar
with
compact
partitions.
This
means
we
now
have
separate
distinct
windows
where
we
have
the
dispute
window
and
then
a
compact.
C
Window
because
the
compact,
like
compact,
partitions
command
or
method,
can
reorganize
partitions,
which
would
make
it
possible
to
actually
dispute
anything
because
everything's
moved
yeah.
So
now,
like
we
have
a
window
where
you
can
dispute,
and
then
we
have
a
window
where
you
can
rearrange
your
partitions.
Other
interesting
parts.
C
Thanks:
what's
the
current
dispute
window,
that's
perfect!
It's
1800
that
box
so
two
times
finality
cool.
A
Yeah
there's
a
question
from
raul
and
chat
that
we're
asking
so
as
a
network
we'll
incur
the
gas
cost
of
the
window
post
verification
only
for
proofs
that
are
being
disputed
right,
and
I
think
the
answer
is
no
right,
because,
because
at
this
point
the
windowpost
verification
gas
cost
is
always
paid
for
in
that.
Because
of
fip
nine,
we
never
we
don't
pay
for
the
actual
the
network
paid
thanks.
A
Currently,
in
flip
nine,
the
network
pays
for
the
cost
of
the
window
post
message
itself,
which,
with
adding
on
fib
10
the
dispute,
cast
cost
messages.
The
dispute
window
post
message
pays
for
gas
normally,
and
so
the
cost
of
the
actual
validate
post
cost
will
be
paid
for
by
that
message.
Right.
C
Yes,
one
tricky
part
here
is
recovering
power.
I
I
I
would
like
to
after
this
puzzle,
suppose
that
we've
removed
nine.
If
it
turns
out
that
this
makes
it
cheap
enough,
because,
like
at
the
moment,
the
network
base
could
pay
for
covering
power.
I
prefer
it
if,
like.
If
a
miner
has
a
fault
or,
if
like
in
this
case,
it
might
hurt
incorrectly
improves
the
sectors
that
they
didn't
have
to
pay
for
a
full
post
on
chain
to
actually
recover
the
power.
C
That's
just
something
I
didn't
go
over
really,
where
like,
when
you
submit
a
post
normally
to
the
chain
and
doesn't
recover
any
power
it
doesn't
you
don't
have
to
check
them
on
chain
if
your
coverage
power,
we
have
to
check
that
on
chain.
Otherwise
what
could
happen
is
if
you
could
spin
up
a
bad
post,
someone
else
could
disprove
it.
It's
actually
more
faulty.
C
It's
been
another
bad
post
to
mark
it
as
as
not
faulty
the
the
expiration
of
that
sector
gets
extended
again
because
it's
no
longer
faulty,
so
the
the
the
14-day
termination
overall
termination
epoch
gets
extended
again.
Someone
else
just
proves
that
the
post
again
gets
marked
faulty
you
keep
going
on
like
this
forever
and
basically
extend
the
sector
indefinitely.
This
is
the
primary
reason
why
we're
covering
power
requires
on
chain
proof.
B
Yeah,
that
makes
sense
just
one
question
just
going.
I
kind
of
didn't
really
understand
what
you
guys
are
talking
about
with
respect
to
raul's
question
in
the
chat
so
so
currently
like
as
ayush
said
right
now,
we're
not
paying
window
post
gas
fees
so
are
like
for
this.
For
fip
10
is
the
disputer
gonna
pay
the
gas
fee
or
are
those
still
waived?
They're
they're
yeah.
B
C
So
if
a
miner
is,
for
example,
lower
than
the
middle
power,
then
the
the
motivation
for
disputing
posts
is
is
relatively
low.
I
still
expect
that
parties
will
do
this,
even
if
it's
at
cost.
That
is
such
a
potential
attack.
That's
interesting
or
someone
could
just
like
try
to
fill
the
network
with
bad,
but
low
quality
data
it'd
be
interesting.
Actually.
B
Yeah
I
mean
I
was
just
kind
of
thinking
about
how
you
know
with
the
base
fee
increasing
or
decreasing
or
like
just
the
gas
in
general,
decreasing
or
increasing
it
like
seems
that
there
will
be
a
point
where
it's
not
rational
to
dispute
proofs
anymore,
unless
the
reward
is
also
dynamically
changed.
With
respect
to
gas
costs,.
E
There's
also
another
perspective
there
where
for
miners
in
the
network,
it's
always
rational
to
dispute
a
third
party
proof
because
it
increases
their
power
sure
so.
C
Slightly,
but
so
the
the
the
idea
is
that
we
sent
this
this
this
cut
off
to
be
enough,
such
that
yeah,
it's
so
easy
to
set
the
word
to
be
high
enough,
such
that
in
a
reasonable
base
fee
or
basically,
the
change
is
not
completely
like
swamped.
It
would
still
be
yeah.
It
would
still
allow
for
a
positive
forward.
That's
what
the
current
approach
is
like,
maybe
one
to
two
fill
or
maybe
like
fulfill.
C
We
have
to
figure
out
how
much
it
costs
to
actually
run
or
execute
these
few
messages.
Yes,
I
understand
that
that
is
concerned.
The
problem
right
now
is
that
the
runtime
does
not
have
access
to
the
base
fee.
That
is
something
we
could
do.
We
could
just
give
the
runtime
access
to
the
base
fee
and
compute
that
internally
cooper.
How
feasible
is
that.
E
A
The
other
thing
addressing
your
question
eric
is,
I
think,
a
lot
of
this.
A
lot
of
the
security
just
kind
of
gets
away
on,
and
all
you
need
is
one
approach
where
it's,
at
least
from
my
perspective,
it's
kind
of
okay,
if
it's,
if
it's
not
perfectly
rational
to
to
dispute
these
posts,
because
we
don't
need
every
act
on
the
system
in
order
to
do
it
so
long
as
one
person
does
it
and
everyone
else
is
willing
to
like
accept
and
like
minors,
are
willing
to
just
accept
the
message.
C
Yes,
and
no
there's
still
the
concern
of
like
you-
have
lots
of
really
really
really
tiny
miners.
This
is
the
problem
with
nine,
where
the
fifth
time
is
still
in
place,
they're
restoring
the
power.
C
Well,
actually
I
take
it
back,
just
restoring
power,
you
know
the
restoring
power
would
be
free
basically,
but
I
guess
I
still
have
to
have
the
storage,
but
I
can
just
like
I
can
try
to
attack
the
network
by
restoring
power
for
free
and
then
submitting
a
bad
proof
and
then
waiting
for
someone
to
try
to
disprove
it
and
just
keep
on
going
and
if
I
don't
even
have
any
like.
If
there's
no
money
in
my
account
for
a
reward,
then
I
can
kind
of
keep
on
doing
this.
C
Like
I
guess
at
some
point
you
can
say
that
well
like
if
the
minor
is
below
the
minimum
power
or
not,
they
don't
really
have
a
reward.
Then
there's
no
real
incentive
to
actually
dispute
their
proofs.
Maybe
that's
fine.
A
Yeah
there's
a
question
from
zx
in
chat:
is
the
software
to
verify
window
post
off
chain
available,
or
will
it
be
simple
for
the
community
to
come
up
with
that
software
kind
of
yes
to
both
questions?
Our
plan
is
to
just
roll
it
out
with
lotus
itself
and
have
it
like
easy
to
enable
so
that,
basically,
anyone
running
a
lotus
node
can
opt
to
also
be
a
window
post
validator
that
would
automatically
submit
dispute
messages
as
needed.
A
K
Also,
sorry,
sorry
if
I
missed
it,
because
I
showed
up
a
bit
late,
sorry
about
that
is,
is
there
anything
around
timeline
for
this
like?
Is
this
planned
to
be
its
own
network
version?
Is
it
going
to
be
grouped
in
with
d3,
or
is
there
any
any
plan
around
that?
Sorry,
if
I
missed
the
answer
by
the
way.
A
No
worries
the
plan
is
to
group
it
in
with
v3,
and
so
the
timeline
is
ideally
put
out.
Release
end
of
january
network
upgrade
early.
G
The
chinese
spring
festival
holiday
will
be
from
11th
february
to
15th,
so
I
was
thinking
that
that
the
best
timeline
will
be
the
yeah,
as
you
said,
the
yeah
end
of
january
or
early
february,
and
also
yeah.
Well,
we
have
this
new
version
and
we
need
to
yeah
imagination
into
other
clients.
Yeah,
for
example,
they've
been
asking
to
have
this
integrated
tool
and
also,
for
others,
know
forest
and
forehand.
G
So
when
you
I,
I
was
thinking
when
you
have
time
to
do
this,
you
need
to
have
this
3d
and
perhaps
one
week
or
10
days
before
yeah,
they,
they
yeah,
really
upgrade.
A
Yeah,
that's
good
note
yeah,
so
we've
definitely
been
mindful
of
upcoming
holidays,
which
is
why
the
plan
would
is
to
get
it
out.
You
know,
ideally
about
a
week
before
folks
go
away
on
holiday
so
that
if
there
are
any
issues,
there's
a
window
to
improve
them,
that's
a
good
note
about
other
implementations
needing
needing
some
some
room
as
well
yeah.
I
think
I
think
it
should
be
possible
to
give
about
about
ten
days,
which
I
think
should
be
sufficient.
D
D
I
don't
think
that
we,
we
weren't
quite
aware
that
you
guys
were
that
close,
which
is
awesome
and
so
part
of
we
definitely
want
to
move
towards
a
you
know.
Releases
come
out
in
coordination
across
all
implementations
for
an
upcoming
state
upgrade
so
that
miners
can
upgrade
all
at
the
same
time
and
continue
like
going
over
top
of
the
state
upgrade
epoch
together,
and
so
you
know
making
sure
that
we
have
communication
between
implementation
so
that
we're
able
to
coordinate
full
compatibility
ahead
of
a
state
upgrade
is
definitely
you
know.
D
That's
that's
what
we
want
the
process
to
be
like
I
don't
know
if
we
haven't
quite
had
that
planned
for
this
network
version
upgrade,
so
we
didn't
realize
quite
how
close
you
guys
were,
and
so
maybe
let's
check
in
on
that,
like
how
close
you
guys
are
for
actors,
I
guess
actors,
v3
doesn't
matter
so
much
to
you
guys
so
it'll
be
more
venus.
D
Integrating
the
actors.
Changes
in
this
network
version
ahead
of
time
to
put
out
a
coordinated
release,
especially
if
you
guys
are
starting
to
get
more
minor
adoption
by
that
by
the
beginning
of
february.
So
in
the
next
like
two
to
three
weeks,.
G
Yeah,
okay,
yeah
and
everything
we
could
do
that
in
the
in
a
calibration
network.
First
yeah.
If
we
have
that
yeah
interoperate
in
calibration-
and
we
have
all
this
integrated
yeah,
that
will
be
much
easier
to
put
it
into
the
minute.
A
Yep
and
we
will
be
deploying
the
the
the
upgrade
in
calibration
as
well
so.
A
Okay,
good
cool,
okay,
thanks
to
the
discussion
on
this,
has
been
really
helpful.
I
think
yeah
and
overall,
like
over
the
past
two
months
that
we've
been
talking
about
optimistic
window
post.
I
think
we've
got
a
lot
of
really
good
insight
from
from
this
group
and
from
the
broader
community.
It's
been
really
good,
any
final
thoughts
on
it
or
are
we
are
we
happy
with
with
booktime.
B
I
just
have
one
one
final,
quick
question
about
it,
so,
like
the
the
off
chain,
the
off
chain,
I
guess
verifier-
is
that
going
to
be
implemented
inside
of
like
the
lotus
daemon?
Is
it
going
to
be
a
separate
executable?
Is
it
going
to
be
part
of
the
minor
just
so
I
can
have
a
little
bit
more
context
if
whether
we
need
to
build
any
interfaces
to
this
or
we
build
it
directly
into
the
software
or.
A
That's
a
good
question.
Honestly,
we
haven't
figured
that
out
yet
I
would
think
he
would
build
it
directly
into
the
lotus
daemon,
but
it
could
be
its
own
process
if
there's,
if
that's
better,.
E
There's
there's
really
no
like.
If
it's
built
built
into
lotus
demon
directly,
I
would
expect
it
could
be
very
simply
extracted
out
of
lots
of
demand
and
be
separate
process
or
something
like
that.
It's
very
loosely
tied
like
in
essence,
you
you
want
to
monitor,
executed
messages
on
train
and
in
response
to
some
message.
After
verifying
and
the
verification
failing,
you
want
to
submit
a
new
message:
it's
not
a
complicated
process
right.
A
A
Fipten
all
right
sounds
good.
Obviously,
if,
if
you
have
any
future
thoughts,
especially
if
you
have
security
concerns
with
it,
please
let
us
know,
share
your
thoughts
or
are
you
gonna
hear
them,
but
but
we
will
probably
move
fifteen
along
in
the
implementation
and
the
fit
process,
which
is
great
all
right.
We
are
running
low
on
time,
but
I
know
folks
wanted
to
talk
about
the
interrupt
net.
Travis
isn't
here
molly.
D
Sure
this
is
just
something
we
talked
about
in,
I
guess
core
devs
meeting
in
december,
just
for
the
groups
that
are
getting
getting
closer
to
joining
the
magnet
but
they're
not
yet
there
and
just
as
more
implementations
are
preparing
to
join
the
magnet
making
sure
that
we
have
an
interop
net,
which
we
actually
had
one
back
in
the
day
in
testing,
interrupt
between
lotus
and
go
filecoin,
but
a
network
that
maybe
has
as
as
austin
was
messaged
mentioning
like
or
homer,
was
mentioning
less
chain
state
than
current
calibration
and
mainnet,
and
also
has
maybe
some
of
the
testing
parameters
that
make
it
fast
to
create
new
blocks
and
generally
test
that
things
are
working
properly.
D
So
I
think
the
discussion
in
the
phil
implement
mentors
thread
was
aiming
for
512
megabyte
sectors
so
that
people
can
test
things
really
quickly,
but
spinning
that
up,
I
think,
probably
it'll
be
next
week
at
this
point.
Just
since
travis
is
taking
the
lead
on
that
and
kind
of
pushing
that
forward,
and
the
aim
here
would
just
be
get
all
implementations
working
on
this
network
and
you
know
able
to
validate
and
move
really
quickly.
D
There
is
an
ongoing
conversation
about
making
sure
the
network
starts
at
spec
actors
version
two,
so
not
doing
the
state
upgraded
but
having
the
genesis
of
that
sounded
like
that
was
doable
on
travis's
side
from
the
fill
implementers
thread,
but
definitely
check
that
for
latest
status
and
otherwise
yeah.
I
think
yeah
as
soon
as
as
soon
as
we
can
get
all
of
the
nodes.
There
use
that
as
a
heavy
testing
ground
and
from
there
upgrade
into
either
calibration
net
or
mainnet
for
even
more
heavy-duty
testing
yeah.
D
I
don't
know
if
austin
had
a
particular
question
about
interrupt
net,
since
he
was
waiting
for
that
agenda
item
is
the
upgrade
plan
to
be
deployed
in
interrupt
net.
I
think
we'll
probably
be
planning
to
deploy
the
upgrade
in
calibration
net
and
not
yet
interrupt
that
and
focus
interrupt
that
on
on
getting
everyone
onto
the
network
and
like
deploying
the
upgrade
early
in
interop
net,
but
we
it's
up
to
us
if,
if
folks
want
us
to
to
do
the
upgrade
there
sooner
rather
than
later,
we
could
do
that
as
well.
A
Yeah,
I
was
just
going
to
say
like
that,
that
question
is
kind
of
like
what
do
you
want,
and
what
does
this
group
want,
whether
it's
more
important
to
fully
get
stable,
interrupt
on
v2
actors
or
kind
of
keep
up
with
the
latest
main
that
we
could
definitely
do
either.
K
D
A
Cool
any
other.
D
Questions,
oh,
I
had
one
other
thing
when
it
comes
to
interrupt
nets
and
testing
and
multiple
implementations
joining
mainnet,
something
that
I
think
would
be
a
really
good
practice
for
all
of
us,
especially
groups
who
have
kind
of
coordinated
mining
efforts
or
testing
mining
efforts
is
to
make
a
good
practice
of
running
all
of
the
implementations
that
are
ready
to
join
the
mainnet,
and
so,
for
example,
I
think
kind
of
each
implementation
committing
to
running
one
node
of
each
of
the
other
implementations
will
be
really
beneficial
to
us.
D
It
allows
us
to
do
much
faster
compatibility,
testing
locally
with
our
mining
setups.
It
gives
the
implementations
like
more
early
testers
across
different
hardware
configurations
to
find
maybe
bugs
that
you
wouldn't
otherwise,
and
so,
for
example,
having
the
like,
we
have
a
an
infrared
mining
team
that
should
start
running
not
just
lotus
but
also
venus
forest
and
eventually
fujon,
when,
when
all
those
are
are
ready
and
vice
versa,
I
think
venus
running
all
the
implementations
forest
running
patients.
I
think
that'll
give
us
better
cross
visibility
and
help
us.
D
You
know
debug
issues
faster,
and
so,
if
we
can
all
collectively
make
that
sort
of
a
commitment
to
each
other,
I
think
it
it
would
be
beneficial
and
give
us
also
a
couple.
A
couple
default
users
on
our
path
to
having
at
least
20
percent
of
network
power,
be,
you
know
well
distributed
across
other
implementations
than
than
lotus,
so
that
we
get
the
good
security
benefits
of
it.
A
B
Just
one
quick
question
with
respect
to
interrupt
net:
if
we're
all
expected
to
be
producing
blocks
on
this
network,
is
there
any
general
guidelines
on
what
kind
of
hardware
is
needed
like
is
this?
Is
this
runnable
in
the
cloud
for
example,
because
I
know
on
mainnet,
it's
like
you
basically
can't
really
do
much
unless
you
have
like
a
a
lot
of
ram
and
all
that
and,
like
you
know,
some
some
nice
beefy
graphics
cards,
so
just
kind
of
wondering
what
what
if
there's
any
hardware
requirements
for
512
make
sectors.
A
You're,
probably
not
going
to
be
able
to
run
it
in
the
cloud
kuba.
You
probably
have
a
better
answer.
E
I'm
not
sure
about
512,
we
rarely
use
it
so
yeah,
I
I
don't
know
where.
So
there
are
a
few
versions,
so
I
don't
know
how
512
proofs
are
proof
tuned,
whether
they
are
doing
first
security
or
development.
So
I
would
need
to
check
that
I
will.
I
will
ask
event.
A
We'll
get
you
an
answer
to
that,
I
don't
think
we
have
five-volt
megabyte
hardware
rex
published
anywhere.
We
probably
should
have
that,
given
that
we
can
do
that
on
calibration
too.
B
Yeah
I
mean
like
we
don't
necessarily
have
to
do
512,
meg
sectors,
but
just
finding
this
just
finding
like
a
sector
size,
that's
like
just
easier
to
for
everybody
to
run
like
I
don't
know
the
status
of
the
other
teams,
whether
they
have
any
nice
gear
to
you
running
this
or
you
know
all
of
that
stuff,
so
probably
good
to
coordinate
on
specifications
for
hardware
and
sector
sizes
and
all
that
good
stuff.
A
B
Big
chunks
is
always
running
so
yeah.
I
mean
I'm,
I'm
more
than
happy
to
donate
some
mining
power.
If
there's,
if
I
can
work
with
somebody
on
the
lotus
side
to
be
able
to
keep
big
chungus
running
on
mainnet
and
big
chungus
running
some
miners
on
the
devnet
or
the
interop
net,
rather
because
yeah
right
now,
we
aren't
really
sealing
blocks
at
max
capacity.
B
We're
kind
of
just
we're
just
working
with
the
small
groups
of
people
who
want
to
store
files
on
the
filecoin
network,
so
we're
just
kind
of
stealing
as
needed.
So
there's
definitely
a
lot
of
ceiling
capacity,
that's
unused
for
mainnet,
so
yeah.
I
I'd
be
very
open
to
working
with
somebody
on
the
filecoin
team
to
get
get
our
setup
to
work
on
more
than
one
network.
A
Awesome
any
last
anything
else:
people
wanted
to
bring
up.
F
I
have
a
brief
question
for
a
wool.
Actually,
do
you
have
any
dates
for
the
test
vectors
and
I
hope,
since
we
have
a
couple
of
issues
not
resolved.
F
Okay,
so
I
have
a
question
regarding
the
test
vectors:
do
you
have
any
updates
on
on
on
your
site,
and
we
have
couple
of
issues
submitted
as
long
as
well
as
one
from
austin?
Do
we
need
to
follow
up
on
this
or.
M
Not
and
not
right
now,
I
don't
have
any
any
updates.
The
only
update
is
that,
over
the
all
the
holidays,
we
merged
a
bunch
of
enhancements
on
the
bet
on
the
generation
side
of
base,
under
validation
for
tips
at
factories.
So
now
we
have
the
ability
to
extract
tips
and
vectors
from
chain
and
also
either.
M
So
you
can
specify
a
range
of
chip
sets
to
extract
and
you
can
specify
if
you
want
a
file
or
a
vector
per
tip
set
and
a
or
you
want
to
squash
all
the
tips
that
sent
to
a
single
vector,
and
then
we
added
some
functionality
for
for
adding
hooks
to
the
execution
of
chipset
vectors
such
that
we
can
intercept
every
time
that
a
vector
is
executed
and
then
run
some
logic
to
extract,
for
example,
balances
of
miners
and
things
like
that.
M
M
We
just
right
now.
Don't
have
a
capacity
to
look
into
that,
but
I
think
we
need
to
integrate
a
lot
better.
The
test
vectors
with
the
upcoming
forks
that
are
planned
on
the
fips,
because,
ideally
after
implementing
each
fit,
there
should
be
a
set
of
test
factories
that
other
implementations
can
use
to
verify
the
compliance
with
that
phase
without
fib.
K
D
K
How
it
hit
the
circ
supply
and
like
that,
obviously
wasn't
set
up
with
the
test
factor.
So
I
don't
know
if
anyone
else
has
run
into
that
issue
or
if
I
should
just
open
up
an
issue
on
test
factors
or
you
know,
start
the
discussion
somewhere
else,
but
as
far
as
I
was
able
to
test
like
the
new
v2
tips
at
vectors,
or
at
least
the
ones
that
call
into
search
supply,
have
been
pretty
broken.
So
I
don't
know
if
anyone
else
has
run
into
that.
M
It
looks
like
it
looks
like
either
yeah
I'll
look
I'll.
Look
into
that.
Let's,
let's
chat.
Let's
chat
again
on
on
the
slack
and
and
we'll
look
we'll
look
into
that.
Yeah.
A
All
right
well,
thank
you
very
much.
This
was
a
super
productive
conversation.
It's
nice
nice
to
nice
to
talk
to
everyone
after
the
break
and
we'll
be
in
touch.
Okay,
bye.
Everyone.