►
From YouTube: Filecoin Core Devs #35
Description
Recording for: https://github.com/filecoin-project/tpm/issues/88
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,
hi
everyone
and
thanks
for
joining
us
today.
This
is
file
coin
core
devs
call
number
35..
We
are
currently
joined
by
the
filecoin
foundation
and
representatives
from
all
four
filecoin
network
implementations,
and
today
we
actually
have
a
lighter
agenda
than
usual.
So,
as
always,
we
will
start
with
updates
from
any
of
the
implementation
teams
and
we
do
not
currently
have
any
standing
agenda
items.
A
So
if
anyone
has
any
walk-on
topics
or
other
things,
you'd
like
to
discuss
at
the
end
of
this
call
today,
they
are
welcome
to
bring
those
up
then
so
to
get
started.
Anything
that
any
of
our
implementation
teams
would
like
to
bring
up
for
group
discussion.
A
B
Sorry,
okay
yeah,
I
guess
from
the
forest
side
yeah
I
just
wanted
to
bring
up.
We
were
talking
a
bit
about
using
the
fvm
potentially
for
this
network
upgrade
within
forest,
and
I
just
wanted
to.
I
guess-
get
clarity
on
what,
if
we
did
that,
whether
we
would
be
using
the
whole
wasm
interpreter
or
if
we
would
just
be
kind
of
pulling
the
fvm
actors
as
a
dependency
and
what
kind
of
yeah
just
wanted
to
discuss
that.
I
suppose.
C
Yeah
I
see
that
neither
rebel
nor
steb
is
here.
I
can
slightly
speak
to
that.
I
think
it
would
be
the
former
it
would
be
using
the
actual,
wasm
interpreter
and
running
it
so
running
through
the
fvm
on
mainnet
is
the
proposal
I'm
not.
C
It
shouldn't
take
too
large
a
refactor
for
you
folks,
unlike
those
of
us
on
in
go
land
on
lotus,
so
I
think
the
id
the
questions
would
be
around
getting
it
done
in
like
having
things
ready
in
time
and
having
enough
confidence
in
it
for
that
to
become
your
kind
of
your
main
at
operation.
If
you
wanted
to
do
that,
yes,
I
think
that's
that's
the
proposal
that
answers
your
question.
B
C
Good,
I
would
also
just
yeah,
maybe
pull
raul
into
a
conversation
if
you
can
just
to
make
sure
everyone's
aligned
and
yeah
what
the
work
involved
would
be,
what
the
risks
would
be
and
what
timelines
could
look
like
and
so
on.
A
And
should
look
like
you
also
may
have
had
a
separate
issue
related
to
lotus,
specifically.
C
Yeah
I
wanted
to
give
a
quick
snap
deals
update,
so
we
have
our
dedicated
test
network
for
snapdeals
right
now
that
we're
calling
butterfly
net
snap
net,
something
to
that
effect.
We've
been
tested
like
it's,
been
live
for
a
couple
weeks
now
and
honestly,
it's
been
a
little
rough,
getting
getting
snapdeal
successfully
working.
We
do
have
some
successful
upgrades
on
the
network
by
this
point,
but
there's
a
few
bugs
being
ironed
out,
both
in
proofs
and
the
potentially
the
lotus
mining
to
fsm,
but
yeah.
C
It's
it's
it's
getting
better,
we're
we're
hoping
to
get
a
fairly
high
success
rate
soon,
but
we
definitely
have
some
more
kinks
to
be
ironed
out.
This
is
good,
though,
because
this
is
all
happening
kind
of
on
this
dedicated
test
network
and
now
and
we
are
coming
up
on
having
a
real
params
dragon-
can
talk
to
the
trusted
setup
process,
but
once
that
happens,
then
it'll
be
going
on
calibration
net,
which
is
our
real
test
network.
So
this
is
almost
like
pre-pre-testing
if
that
makes
sense.
C
A
D
Yeah,
you
just
gave
me
a
great
great
intro,
the
last
sentence
yeah.
So
we
actually
this
morning
started
uploading
the
params
so
preparing
everything
for
an
additional
round
of
testing
or
calibration,
but
trusted
setup.
As
a
ceremony
ended
yesterday
very
successfully,
we
did
all
four
circuits
and
thanks
to
everybody
who
helped
and
I'm
doing
like
a
blog
post,
to
share
more
details
about
it.
D
D
This
is
also
going
to
be
publicly
available
from
next
week
that
this
is
kind
of
the
the
what
you
do
after
a
trusted
setup,
but
this
and
the
params
upload
for
cal
ablation
are
now
the
two
next
steps,
but
everything
runs
smooth
in
terms
of
like
trusted
setup
apart
from
the
long
hours
and
multiple
zones
that
we
needed
to
cover
time
zones,
but
in
terms
of
getting
the
end
result,
the
end
result.
Is
there.
C
One
question
about
that:
I
realize
I'm
not
fully
in
the
loop.
I
know
that,
as
we
were
getting
trusted,
setup
started.
That's
kind
of
a
last-minute
idea
from
cuba
about
excluding
circuits
for
transformation
proofs
that
we
might
want
to
be.
That
might
be
useful
in
the
future.
Did
we
wind
up,
including
them.
D
Yes,
yes,
that's
what
we
did.
This
is
what
we
call.
We
are
calling
snapdeals
poseidon
circuits,
so
those
are
the
two
additional
circuits
next
to
the
empty
sector,
ones
for
like
their
unlocking
snapdeals.
This
is
kind
of
we're
also
seeing
into
the
future,
and
we
added
the
poseidon
circuits
there.
So
that's
why
I
said,
like
four
circuits
in
total
yeah,
that's
very
good.
A
And
I
wanted
to
check
so.
The
original
timeline
for
the
v15
upgrade
has
the
upgraded
cal
of
net
going
live
on
february
8th.
I
know
that
when
we
last
spoke,
I
think
venus.
Potentially
forest
and
lotus
were
all
planning
to
upgrade
on
february
8th,
but
we
had
also
previously
discussed
that
this
would
sort
of
be
a
soft
upgrade
and
we
wouldn't
ask
all
implementation
teams
to
try
and
sync
that
upgrade
together
to
make
space
for
snapdeals.
A
I
wanted
to
quickly
get
a
check
in
from
each
of
the
teams
and
see
how
you're
thinking
about
the
calendar
upgrade
process
and
what
your
rough
timeline
is
for
joining
that
upgrade
period.
C
Yeah
so
yeah
totally
yeah,
we
are
aiming
to
make
the
february
8
timeline.
Most
of
the
mining
power
on
calibration
net
is
lotus
based,
and
so
we
will
have
to
make
that
timeline,
but
we're
feeling
like
it
should
be
good,
barring
yeah,
the
bugs
that
I
mentioned
with
just
getting
things
working
more
reliably.
The
good
part
is
almost
none
of
them
are
consensus,
critical,
so.
A
Great
and
stephen,
your
icon
is
right
next
to
ish's
on
my
screen,
any
update
for
venus.
E
Yeah
virus
team
is
working
on
the
testing
and
butterfly
work
and
right
now
and
we're
testing.
I
think
all
other
functions
works
well
with
version
15
and
we're
working
on
the
yes
that
deal
in
testing.
E
Actually
we
experienced
that
the
yeah
very
large
memory
usage
and
that
are
expected,
and
so
we're
still
working
on
that
yeah.
We
know
that.
Okay,
yes,
that
deal
actually
yeah
did
yeah.
I
need
the
memory
actually
larger
than
128
gigabytes,
so
I
would
think
that
we,
when
you
yeah,
better
taste,
yeah
test,
fit
actually
yeah
we're
we're
working
on
that.
So
I
don't
think
we
we
we
don't.
E
We
have
some
problem
with
the
code,
but
we
need
to
your
test
to
go
through
yeah.
All
this
unique
space.
E
E
The
whole
team
in
china
will
be
a
holiday
from
the
day
after
tomorrow,
and
we
will
be
back
on
your
february,
8th
yeah.
If
everything
and
works
okay,
I
think
we'll
other
time,
yeah
february,
8th,
okay
and
otherwise
we
we
made
it
a
few
more
days
and
yeah.
That
is
the
case.
I
think.
A
Sure
that
sounds
great
and
I
hope
you
all
have
a
nice
lunar
new
year
and
that's
a
great
way
to
really
jump
right
back
into
network
ops
when
you
come
back
so
sounds
great
yeah
elizabeth
early,
any
update
on
forest
and
the
the
calibrate
sink.
B
Yeah
for
sure,
yeah
we're
still
just
continuing
to
work
on
the
fips
for
the
next
upgrade
and
then
as
well.
We
have
someone
working
on
the
cal
net
sink
for
the
current
network
yeah,
so
that
should
yeah
be
done
by
the
calib
net,
the
date
that
we
want
to
be
testing
on
calipnet,
ideally
yeah.
I
don't
know
so
yeah
looking
good
at
the
moment.
Yeah
I
just
gotta,
take
into
account.
If
we
wanna
do
the
wason
update
to
use
fvm
as
well,
but
yeah,
that's
about
it
yeah
lee.
A
Great,
thank
you
guys
and
a
little
bit
separately
of
maxim.
I
don't
know
if
you
have
any
updates
from
the
fucon
team.
I
know
you're
still
working
on
the
the
upgraded
minor
release.
Anything
you
want
to
share
with
the
rest
of
the
team.
G
Yeah,
so,
regarding
the
networking
shift
on
the
calipnet,
I
think
it's
possible
that
we'll
be
able
to
participate
from
node's
perspective.
We
most
probably
will
not
make
a
minor
work
by
february
5
8,
just
because
we
are
currently
still
testing
it
on
the
test
net,
like
without
v15
upgrades.
G
The
nodes,
however,
are
basically
incorporated
most
of
the
changes.
I
will
check
tomorrow
visiting
what
what
exactly
are
we
missing
if
any?
But
as
far
as
I
remember,
we
have
incorporated
most
of
the
changes
related
to
the
v15
upgrade
on
the
node
level,
so
we
might
also
consider
joining
the
caribnet
upgrade.
A
C
Yeah
I
wanted
to
get
back
to
what
stephen
was
lagging
about.
Memory
consumption
with
with
the
snapdeals
proofs
yeah,
definitely
not
a
bug
on
your
end,
we're
seeing
it
too
and
honestly.
I
really
don't
understand
why,
like
the
the
replica
update
of
512,
megabyte
sector
was
taking
more
than
128
gigs
of
ram,
which
is
crazy
to
think
about.
I
so
mostly
just
want
to
say
yeah,
it's
not
not
nothing!
On
your
end,
that
seems
to
be
the
case
right
now.
C
I'm
not
sure
how
bad
it
is
for
32
and
64
gigabytes
sectors,
especially
relative
to
like,
let's
say
the
proof
commits
snarks
that
we
calculate
but
yeah
some
optimizations
need
to
happen
there
dragon.
I
don't
know
if
you
know
anymore
about
why
it's
so
high,
especially
for
like
small
sectors,
but
it's
confusing.
D
Yeah
yeah,
sorry,
we
have
been
busy
with
trapping
the
the
trusted
set
up
verums,
but
I
raised
the
tread
with
with
the
guys
and
they
will
look
into
it.
So
I
will
come
back
with
an
answer
so
far
we
didn't.
We
don't
have
like
the
conclusion
why
it's
so
high
on
up,
like
kind
of
looking
into
it
with
fresh
eyes
from
today,
will
probably
give
us
better
results.
C
All
right
sounds
good
yeah.
Hopefully
it
doesn't
just
come
down
to
needs
to
be
better
because
everything's.
E
C
Down
the
bell
person
needs
to
be
better
yeah,
we'll
see.
E
Yeah
so
one
question
here:
yeah
from
the
from
the
limitation
point
of
view:
will
the
memory
usage
will
be
yeah
will
be
larger
if
we
use
larger
center
size
or
yeah.
It
will
keep
the
same
because
of
your
parameters.
C
I'm
not
sure
I,
but
I
think
it's
it's
it'll
be
roughly
the
same.
We.
I
need
to
confirm
that,
though
we
need
to
run
an
experiment
for
it:
okay,
sure,
yeah
but
yeah
right
now.
The
fact
that
a
512
megabyte
sector
is
using
128
gigs
of
ram.
A
H
Yes,
so
I'm
very
gracious
to
matthew
from
sigma
prime
is
on
the
call,
because
it
is
way
too
late
where
he
is
right
now,
but
he
is
leading
the
file
coin
buzzer
project
which
I
believe
started
maybe
a
week
or
so
ago,
and
he's
going
to
give
us
a
bit
of
an
intro
to
it.
So
thank
you
for
being
here.
I
No
worries
thanks
dudley,
hey
everyone,
a
bunch
of
familiar
names
and
faces
so
for
those
who
have
met
before
my
name
is
maybe
I'm
a
co-founder
and
director
of
sigma
prime.
We
are
a
blockchain
security.
Firm
we've
been
working
quite
extensively
with
protocol
labs
over
the
past
couple
of
years.
I
Reviewing
brand
file
coin
implementations,
forest
lotus
and
whatnot
very
happy
to
be
here.
It's
3
a.m.
For
me,
but
very,
very
happy
to
be
here
and
very
happy
to
introduce
this
project
that
we'll
be
working
on
over
the
coming
months.
Some
of
you
may
be
familiar
with
a
similar
initiative,
called
beacon,
fuzz,
so
sigma
prime
has
been
developing
and
maintaining
a
set
of
differential
fuzzing
frameworks
for
the
theorem
foundation.
I
This
had
led
to
the
identification
of
over
40
bugs
across
all
e3
clients
or
sorry
ethereum,
consensus,
clients
and
yeah.
So
we
thought
it
could
be
potentially
interesting
to
try
to
replicate
this
for
file
coin
so
we'll
first
start
targeting
and
lotus.
I
Ideally
we'd
like
to
expand
the
scope
of
this
activity
to
other
clients,
so
I'll,
probably
reach
out
to
venus
and
the
c
plus
implementation
at
some
point.
But
the
idea
is
to
use
a
combination
of
coverage,
guided
techniques
along
with
structural
fuzzing
and
differential
fuzzing
to
spot
discrepancies
between
clients
when
it
comes
to
state
transition
functions
primarily,
obviously
be
monitoring
for
standard
panics
and
crashes,
but
the
focus
here
will
be
to
try
to
dig
up
those
logic
flaws
if
that
makes
sense
logic
bugs
in
those
implementations,
so
yeah.
I
I
think
it's
probably
a
prime
candidate
for
differential
fuzzing
and
obviously
we'll
start
hitting
the
specs
actors,
implementations
and
the
actual
state
transition
that
the
at
the
consensus
layer
so
yeah.
We
got
started
last
week,
as
daddy
mentioned
just
getting
our
head
across
the
different
code
bases
starting
to
take
things
apart
and
no
outstanding
questions
at
the
moment.
You
know,
we've
been
in
touch
with
the
lotus
guys
and
the
forest
guys
quite
quite
a
lot
lately.
I
So
I've
got
contacts
directly
in
this
team,
so
I'll
be
making
sure
that
we
reach
out
to
these
people
when
needed.
I
can't
promise
I'll
be
attending
these
calls
very
regularly,
but
I'll
do
my
best
to
try
to
provide
updates
at
least
once
a
month.
This
is
expected.
I
This
is
expected
to
last.
This
project
is
expected
to
last
about
four
months,
so
obviously
we'll
yeah
keen
to
be
working
together
and
learn
from
each
other
and
hopefully
help
surface
some
interesting
behaviors
in
your
clients.
A
That's
great
thanks
so
much
for
joining
us
maddie
and
it's
nice
to
meet.
You
also
we'll
talk
about
this
in
a
second,
but
the
time
challenge
is
an
issue
for
quite
a
few
folks
who
regularly
would
like
to
attend
this
call.
So
if
you
would
like
to
come,
ask
questions
or
provide
updates
on
the
fuzzer
project,
as
your
team
continues
to
work
on
it,
we
may
be
introducing
two
meetings
in
the
future,
one
of
which
will
be
a
little
bit
more
hospitable
to
your
time
zone.
A
H
As
a
quick
note,
one
of
the
deliverables
of
this
project
is
going
to
be
a
docker
image
and
instructions
on
how
to
set
things
up
with
github
actions.
Obviously
it
might
depend
a
little
bit
on
how
people
have
actually
implemented
their
code
base
and
getting
that
set
up,
but
hopefully
we
can
kind
of
get
this
set
up
in
a
sort
of
id
again.
I
don't
know
enough
about
the
project
to
know
whether
how
fast
this
might
be,
but
in
a
continuous
integration
kind
of
way
or
get.
I
Hugs
yeah
totally
that's
the
end
goal.
Hopefully
we'll
leave
you
guys
with
a
nice
framework
that
you
can
continue
to
build
on.
H
Not
really,
I
will
say
that
we're
quite
we've
got
two
decent
candidates
for
a
security
operations,
engineer
a
five
point
foundation
which
will
hopefully
speed
up
a
lot
more
of
our
bug,
bounty
processes
and
things
like
that.
So
here's
here's
hoping.
A
Great,
so
I
will
jump
into
the
fifth
update
then
so,
on
the
flip
side,
we're
very
pleased
and
thrilled
that
both
the
data
cap
management,
fip
and
snap
deals
have
passed.
Their
last
call
status,
excellent
because
it
would
be
quite
an
issue
at
this
point.
A
Had
they
not
very
excited
that
we
actually
didn't
receive
any
additional
questions,
concerns
or
any
sort
of
more
negative
community
feedback
about
either
of
these
proposals,
so
they
did
move
into
accepted
status
unanimously,
which
is
great,
so
we're
ready
to
implement
them
on
chain,
obviously,
in
the
next
network,
upgrade
so
no
changes
or
any
specific
flags
in
regards
to
either
of
those
going
forward.
A
This
was
always
the
intent,
and
this
is,
I
think,
how
these
things
are
managed
in
the
past,
but
we've
gotten
away
from
that,
since
we
have
this
ad
hoc
upgrade
timeline
that
we
continue
to
work
around
and
since
we
all
obviously
work
very
closely
together
but
going
forward,
we
should
begin
to
think
more
about
timelines
in
terms
of
overall
team
needs,
and
then
we
can
use
this
call
to
identify
fips
that
are
possible
for
implementation,
see
what
team
priorities
are,
etc
and
sort
of
more
clearly
designate
sort
of
what
is
available
and
what
sort
of
community
consensus
exists
around
specific
issues
and
then
focus
on
the
implementation
process
and
if
you're
curious
about
this
or
you
have
questions,
obviously
I'm
happy
to
answer
them
now,
but
we
also
have
some
documentation
that
was
built
up
too
in
the
governance
section
of
that
fifth
discussion
forum
on
github.
A
So
I'd
be
happy
to
point
you
to
it.
That
being
said,
I
do
want
to
flag.
I've
had
some
conversations
privately
with
raul
in
the
past
couple
of
weeks
about
planning
for
the
v16
network
upgrade.
Obviously
this
is
a
priority
and
we've
known
that
there
would
probably
be
a
pretty
tight
timeline
between
v15
and
v16,
and
so
my
priority
is
to
know
by
the
next
cordov's
call,
which
will
be
mid-february
whether
or
not
we
can
confirm
that
timeline
and
begin
to
share
it
more
publicly
as
well.
A
So
in
the
past
I
know,
specifically,
it's
been
the
lotus
team's
preference
that
there'll
be
at
least
six
weeks
between
network
upgrades,
but
given
the
pressure
usually
more
is
preferred,
of
course,
but
given
sort
of
the
pressure
and
the
interest
to
make
sure
that
the
fbm
fips
are
available
to
the
community
and
that
the
actual
run
time
is
integrated
within
the
protocol
and
the
timeline
that's
been
projected
and
discussed
for
the
last
couple
of
months.
C
My
thought
is
that
that's
going
to
be
hard
to
achieve,
but
achievable
the
six
week
time
like
kind
of
the
six
week
timeline
was
a
hard
ask
from
lotus,
is
mostly
what
can
be
can
be
shortened
depending
on
how
well
we
can
parallelize.
Basically,
so
essentially
it's
more
it's
more
of
a
six
week
testing
window
as
opposed
to
six
week
between
upgrades
so
so
long
as
we
can
start
testing
our
v16
upgrade
and
everything
around
that
before
snap
new
snapdeal's
upgrade
before
osnap
actually
goes
live
on
mainnet.
C
I
think
I
think
that
will
be
workable,
whether
or
not
we'll
be
able
to
do
that.
It'll,
I
think,
will
become
a
little
clearer
in
the
next
couple
weeks.
As
you
know,
what
once
we
have
high
enough
confidence
in
snap
deals
and
that's
slightly
become
say:
okay,
you're
done
you're
you're
going
out
there
into
the
world,
and
we
can
switch
attention
to
focusing
on
fbm
and
spinning
up
another
test
network.
You
can
retire
this
one
and
create
a
new
one
and
so
on
so
yeah.
C
I
think
I
think
a
early
april
first
week
of
april
would
work.
We
just
have
to
be
have
to
be
good
about
running
many
things
in
parallel,
both
like
kind
of
the
lotus
team,
the
fbm
team,
the
really
everyone
involved,
the
infrastructure
for
these
test
networks
and
so
on,
but
I
think
we
can
make
it
work.
E
Yeah,
the
fvm
is
a
very
big
thing
is
because
that
we
changed
these
big
actors
and
also
we
changed
the
virtual
machine
totally
and
yeah
from
the
current
process.
We
have
yeah
because
the
an
fm
is
referenced
if
in
implementation,
just
open
source-
and
we
have
some
study
on
that-
and
we
say
that
actually
yeah.
Even
these
big
actors,
which
is
not
fully
complained
with
the
current
version,
we're
wrong
right
now
and
they're,
only
yeah,
which
is
still
old.
E
So
ever
since
that's
there
would
take
some
time
to
to
make
it
up
to
date.
So
our
sense
that
yeah,
if
it
it
depends
the
whole
fm
part,
the
testing
could
be
done
and
make
it
your
complaint
with
the
current
yeah,
with
a
network
version
15
after
the
15
is
on
board
yeah.
I
agree
that
we
we
we
need
at
least
six
weeks
after
that
and
for
testing
and
which
is
the
minimum
period
with.
E
A
F
Yeah,
for
I
think
whatever
elizabeth
mentioned
before
related
to
the
wasm
stuff,
I
think
that'll
that'll
affect
the
rest
of
our
timeline.
Like
ayush
mentioned,
it
does
seem
a
little
tight,
given
that
we
are
going
for
network
15
on
march
and
then
it's
like
four
weeks.
It's
definitely
tight,
however,
because
the
rest
factors
like
the
ibm
has
that
it
may
not
be
as
probably
a
big
of
a
challenge
for
us
compared
to
like,
let's
say
the
venus
team,
because
they're
in
different
goal
land.
F
However,
I
think,
depending
on
how
we
are
able
to
integrate
the
rough
sectors
along
with
the
wasm
stuff,
I
would
say
I
will
be
able
to
give
more
contacts
in
probably
the
next
core
dev
call
or
that's
that's
gonna,
be
my
thought
process,
just
not
sure
if
elizabeth
had
some
additional
input
on
that,
otherwise
that's
kind
of
what
our
input
on
this
is.
B
Yeah,
like
the
timeline
for
the
next
upgrade-
I
guess
yes
yeah.
I
think
it
kind
of
depends
how
much
effort
the
integration
with
fbm
turns
out
to
be
so
yeah,
I
think
yeah.
Ideally,
we
will
be
able
to
do
it
by
this
upgrades
and
by
the
next
upgrade.
It
wouldn't
even
be
an
issue
at
all,
but
I
don't
know
it's
yeah
really
depends
on
how
things
go.
So
it's
being
pretty
optimistic.
I
guess
so.
B
Yeah
I'll
yeah,
like
lisa,
will
probably
have
more
info
on
yeah
whether
this
is
gonna
be
feasible
or
not
by
the
next
call
yeah.
I
I
think,
yeah.
I
think
we'll
mention
that
the
interfaces
didn't
change
too
much.
So
hopefully
it
won't
be
too
painful
and
I
think
by
the
next
upgrade
we'd
definitely
be
able
to
do
it.
So
yeah.
C
Didn't
change
at
all,
I
think
so
that
should
be
good.
C
Yeah
sorry
a
bit
of
an
aside,
but
I
really
like
that
we're
getting
to
a
place
where
you
guys
have
the
easiest
job
after
like
two
years
of
it
always
being
you
know
the
lotus
like
everyone
and
go
having
their
own
bubble
and
you
guys
like
being
like
guys,
we
have
so
much
more
work
to
do
than
you
folks
and
now
we're
going
to
place
it
well,
it's
fine
rusty's
already
got
it
done.
You
guys
can
suffer.
A
Yeah-
and
I
do
want
to
say
that
in
all
these
conversations
I
mentioned
having
with
raul
when,
when
we
discussed
having
a
really
tight
timeline
for
v16,
it
was
on
the
preconditions
that
future
upgrades
in
general
after
the
fdm
go
live,
which
should
be
much
easier
on
all
implementation
teams.
Of
course,
right
so
potentially
a
short-term
stretch
for
for
long-term
ease.
But
stephen
did
you
have
something
you
wanted
to
add?
I
think
you
tried
to
jump
in
before.
E
I'm
sorry
yeah,
which
ones
yeah
sorry
I
I
didn't
get
here.
A
E
Yeah,
this
is
not
about
the
f-wing
yeah.
This
is
about
the
yeah,
the
faith
about
the
beneficiary
address,
and
are
you
talking
about
this.
A
Yeah,
I
think,
if
there's
any
final
notes
on
b16,
it's
not
clear.
I
was
hoping
to
have
a
list
of
potential
fifths
for
that
one,
it's
not
quite
clear.
Yet
what
those
might
look
like.
But
again,
I
think
it's
more
important
that
we
discuss
the
timeline
separate
from
potential
accepted
fips.
That
could
be
a
separate
conversation.
A
I
didn't
want
to
confuse
the
two
and
just
as
I
know,
our
next
core
devs
call
is
going
to
be
on
february
10th
and
at
that
point,
that
would
give
us
seven
to
eight
weeks
prior
to
to
the
expected
fbm
launch.
So
I'm
glad
we've
been
able
to
start
this
conversation.
A
We
should
continue
it
and
plan
to
have
more
of
a
confirmed
timeline
then,
but
just
keep
in
mind
and
flag,
as
as
things
change
and
dependencies
change
again,
if
any
concerns
do
bubble
to
the
surface,
you're
welcome
to
flag
before
the
next
call
as
well,
but
stephen.
If
you
want
to
talk
about
your
beneficiary
address,
that's
great
also.
E
Yeah,
I
can
yeah
take
a
few
minutes
to
talk
about
this.
Okay,
sure
yeah,
I
okay.
Actually
I
have
a
draft
of
the
fave.
I
can
put
it
into
the
chat.
I
E
Yeah,
if
it's
okay,
I
can
share
my
screen.
Okay,.
A
Sure
do
I
need
to
make
you
the
host.
E
Yeah
here
is
about
okay,
the
fave
I
yeah,
okay,
okay,
the
number
is
28,
but
I
don't
think
this
is
a
divided
number
right
now,
because
I
say
this
is
taken
by
another
one,
so
this
can
be
changing
later.
Basically,
we
have.
This
proposal
is
because
we
want
to
separate
the
beneficial
control
from
owner
is
because.
E
For
myself,
as
a
service
pro
as
a
storage
provider
and
a
software
and
a
service
provider
yeah,
we
say
a
lot
of
about
they
yeah
for
small
and
media,
yes,
providers
who
want
to
join.
You
know.
Falcon
network
parties
are
always
facing
about
the
your
funding
issue,
and
so
there
are
a
landing
market
for
the
falcon
which
is
existing
and
yeah
offline
and
offline
chair.
E
Actually,
so
here
we
will
propose
this
to
separate
the
beneficial
and
control
from
the
owner,
so
that
the
falcon
nodes
future
rewards
could
be
the
collateral
as
a
yeah
progress
yeah
to
support
lending
market
and
also
which
you
could
also
support
the
your
financial
control,
even
yeah.
E
If
you
maintain
a
kind
of
larger
and
a
niger
load,
and
you
have
a
team
actually
to
come
to
the
door,
you
have
some
maintenance
in
years
and
you
have
the
financial
part
and,
and
you
you
can
also
have
the
owner,
and
this
also
can
support
that
and
to
make
it
much
easier
to
control
your
load
yeah.
This
is
hopefully
this
so
here
in
the
proposal.
E
I
propose
to
add
one
to
a
node
and
yeah
because
we
have
the
owner,
we
have
walker
and
we
have
controllers
yeah
for
when,
for
one
storage
provider
node-
and
here
we
add
one
more-
we
call
it
beneficiary
and
to
be
the
distillation
of
the
withdrawal
and
measured
and
for
the
badness
to
the
beneficiary
and
address
and
yeah
to
be
yeah
to
be
back
compliant.
So
we,
you
know
once
we
have
this,
we
could
to
have
the
beneficiary
address
to
be
the
same
address
as
owner
and
well.
E
We
do
the
stage
transition
and,
after
the
upgrading
so
yeah,
which
could
be
yes,
the
same
okay
without
and
and
actually
from
the
functionality
you
know
will
to
maintain
the
same
address
and
we.
E
There
are
two
kinds
of
information
for
for
the
pediatrician
to
to
limit
the
beneficial
edges,
the
privilege
or
the
quota.
So
we
introduced,
we
introduced
the
beneficiary
infos
infrastructure
into
the
main
infrastructure
and
to
include
a
few
items
here,
and
one
is
about
the
beneficial
quota,
which
means
that
if
the
beneficiaries
is
not
the
same
as
ownership
and
it
could
and
have
a
court,
be
a
quote
happy
as
end
and
and
and
also
there
is
one
one
field
called
use
the
quota.
E
So
it
is
a
yeah
communicated
a
bonus
resort
to
beneficiary
yeah,
so
that
so
the
user
quota
must
be.
E
E
We
have
this
two
failed
to
and
actually
protect
the
owner
for
some
cases
and
yeah,
for
example,.
E
When
the
owner
to
have
a
deal
was
a
vendor
to
give
some
funding
of
the
falcons
to
fund
their
progress
as
as
clutterers
yeah,
it
may
have
an
agreement
of
the
of
the
quarter
and
they
will
have
a
timeline
to
yeah
for
the
agreement
so
yeah.
This
is
too
much.
E
Then
you
have
to
match
that
and
an
agreement
about
and
about
this
and
all
this
can
be
changed
with
a
change,
beneficial
mercer
directory
with
the
proposed
and
the
confirmation
process,
and
here
we
have
some
details
and
your
progress
and
designs
hair.
I
don't
want
to
go
through
this
hair.
You
just
meet
him
but
and
yeah
you
guys
can
go
through
this
and
yeah.
Please
provide
some
comments
and
for
this
one.
E
Okay
and
for
some
other
design,
rationals
and
at
least
some
use
cases,
and
they
benefit
and
yeah
that
could
you
know
bring
to
us
and
also
about
the
yeah
security
concerns
the
conservation
and
the
incentive
conservation.
There
are
yeah
contribution
about
this
and
yeah
and
overall,
it
should
be
okay,
and
I
discussed
with
a
few
yeah
a
few
people
for
this,
and
we
gave
some
comments
from,
for
example,
alex
and
jennifer
and
other
community
members.
E
I
think
we
agree
about
this
and
we-
and
I
also
welcome
more
comments
about
this
and
also
the
product
consolidation
and
also
the
implementation.
I
today
add
in
two
pictures
about
the
change,
beneficial
proposal
process
and
actually
it's
about
it's
almost
the
same
as
the
change
owner.
E
Command
with
the
same
parameters-
okay,
you
know
that's
all
about
this
any
comments
and
any
suggestions.
A
I
actually
think
that
the
way
that
you
guys
have
been
developing
this
is
a
great
model
for
other
fips
too.
There's
been
a
lot
of
back
and
forth,
and
some
really
good
feedback,
like
you
mentioned
from
alex
and
jennifer
specifically,
and
I
think
it's
been
great-
to
watch
this
sort
of
develop
over
time
and
the
level
of
detail
in
your
fifth
draft
was
great.
So
thanks
so
much
for
doing
this.
E
Yeah
yeah
and
by
the
way
and
we're
working
on
the
detailed
information
and
yeah
these
big
actors,
and
we
will
have
it-
will
have
a
pr
hours
and
obviously
yeah
within
one
week
or
two
and
yeah.
A
A
Great,
I
can
actually
flag
this
we're
trying
to
do
weekly
updates
on
governance
too
and
flag
some
some
fips
that
are
being
very
actively
worked
on
for
community
input.
So
we
can
flag
this
one
this
week
actually
and
stephen
you-
and
I
can
talk
offline
too,
about
how
you'd
like
to
schedule
that
last
call
status.
E
A
A
We
don't
have
much
time
left
in
the
meeting
we.
I
do
have
one
more
topic.
I
would
like
to
briefly
cover,
but
any
other
last
questions
or
comments
for
stephen.
A
All
right,
great
so
again,
of
course,
we'll
add
a
link
to
the
flip
draft
and
six
meeting
notes.
Everyone
can
find
it
more
easily
and
do
take
a
look
and
leave
comments
if
you
haven't
yet
this
is
a
pretty
large
and
detailed
fit.
But
again,
a
lot
of
really
good.
Work
has
gone
into
this
over
time,
so
it
would
be
great
if
everyone
is
able
to
let
them
know
what
you
think.
A
If
we
don't
have
anything
else,
I
do
want
to
briefly
return
to
what
we
discussed
last
week,
which
was
potentially
changing
the
way.
We're
scheduling
these
meetings
to
be
a
little
bit
more
effective,
not
only
in
how
they're
structured,
but
also
for
people
who
are
in
different
time
zones
who
may
have
to
join
this
at
really
in
opportune
hours.
A
I
posted
a
poll
in
the
phil
implementers
channel,
so
thanks
to
those
of
you
who
voted
and
it
looked
like
the
preferred
option
slightly-
was
to
actually
host
two
separate
meetings
on
every
thursday.
This
is
currently
the
model
that
the
file
coin
plus
governance
team
uses.
So
we
do
have
some
examples
of
what
can
make
that
work
effectively
and
since
it
can
be
a
little
difficult
to
visualize
scheduling
changes,
I
have
a
brief
slide,
just
one
that
I
hope
everyone
can
see.
A
So
the
proposal
is,
we
will
keep
our
currently
scheduled
meeting,
which
is
bi-weekly
every
two
weeks
at
8
a.m.
Pacific
time,
if
you
need
to
look
here's
a
quick
reference
for
what
that
may
look
like
in
your
time
zone
or
one
close
to
it.
A
This
is
why
a
lot
of
excuse
me
engineers
frequently
do
not
join
these
calls,
because
they
would
have
to
do
so
in
the
middle
of
the
evening,
and
we
know
we're
asking
a
lot
of
from
those
of
you
who
currently
do
steven.
I
think
that
may
be
you
as
well,
so
the
idea
is
what
we
will
do
is
have
non-mandatory
sessions,
another
one
hosted
at
4
pm
pst,
which
is
a
little
bit
more
conducive
to
folks,
who'd
like
to
join
during
regular
working
hours.
A
I
will
join
both,
of
course,
and
steward
information
between
the
two.
This
model
does
work
pretty
well.
It
is
obviously
nice
to
have
everyone
available
for
discussion,
but
asynchronous
updates
do
work.
The
only
requirement
is
that
the
meetings
would
have
to
be
pretty
structured
to
make
sure
that
both
groups
get
the
same
information.
A
But
the
key
point
here
is
that
for
regular
updates,
sort
of
just
open-ended
conversations
or
any
other
items
that
you'd
like
to
present,
we
don't
want
you
to
have
to
schedule
your
evenings
or
very
early
mornings
around
having
to
join
this
call.
We
want
it
to
be
a
productive
work
environment
for
you,
and
the
idea
is
that
if
we
host
two
calls
everyone
will
have
a
forum
that
is
a
little
bit
more
conducive
to
doing
just
that.
A
All
right,
if
not
because
we
do
have
a
pending
network
upgrade
what
I
would
recommend
we
do
is
continue
with
our
current
schedule
until
the
v15
network
upgrade
goes
live
so
that
we
can
continue
to
coordinate
the
way
we
always
have.
A
A
All
right,
if
there's
no
questions
comments
feedback,
then
we
will
we'll
plan
for
that.
So
starting
in
two
weeks,
which
is
february
10th,
I
believe
again
we'll
have
sort
of
that
new
presentation
structure.
A
You
should
see
an
updated
meeting,
invite
on
your
calendars
this
afternoon
or
tomorrow
morning,
depending
on
where
you
are,
and
if
there's
no
other
last-minute
items,
then
I
will
see
everyone
in
two
weeks.