►
From YouTube: Filecoin Core Devs #46 (Meeting 2)
Description
Recording for: https://github.com/filecoin-project/tpm/issues/105
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
Follow Filecoin!
Website: https://bit.ly/3ndAg44
Twitter: https://bit.ly/3ObND0x
Slack: https://bit.ly/3HKfFy7
Blog: https://bit.ly/3HFZFNv
Reddit: https://bit.ly/39N4Jmv
Telegram: https://bit.ly/3bkP8Ly
Subscribe to our newsletter! https://bit.ly/3Oy8J9j
#filecoin #ipfs #libp2p #web3 #nft
A
All
right,
hi
everyone
and
welcome
this
is
file
coin.
Core
devs
call
40
number
46.
today
is
thursday
june
30th
in
the
united
states
july
1st.
For
some
of
you-
and
this
is
meeting
number
two
so
today,
as
always-
we're
going
to
quickly
run
through
updates
from
each
implementation
team
and
from
the
filecoin
foundation,
we're
going
to
briefly
touch
in
on
the
status
of
the
v16
network,
upgrade
which
is
coming
very
soon
and
then
check
in
on
the
status
of
our
scoping
and
planning
around
network
version.
17.
A
we'll
also
give
space
to
many.
If
you'd
like
to
talk
about
some
of
the
security
work
you're
doing
currently
and
then
vic
will
lead
us
through
a
fifth
presentation
for
the
sector:
duration,
multiple
multiplier
that
him
and
his
team
have
been
working
on.
A
So
stephen,
you
want
to
kick
us
off
and
share
venus's
updates
with
us
all.
B
Right
yeah
sure
yeah
previous
team
is
working
on
network
version,
16
and
yeah
in
a
few
weeks,
and
actually
we
have
done
the
butterfly
and
the
testing
and
the
calibration
they're
testing.
And
now
the
various
team
has
released
yeah
one
yeah
with
us
suite,
which
includes
all
the
components
and
yeah
the
number
yeah.
The
biggest
version
number
is
1.6
and
actually
to
support
version
16..
B
Yet
now
it
is
released,
so
the
community
can
take
that
to
this
and
to
install
and
upgrade
okay
yeah.
This
is
one
pixel
we
have
been
working
on
and
the
next
one
is
about.
We
have
a
free
function
and
the
yeah
which
already
yeah
deployed
actually
and
about
the
village
market
we
fixed
a
few
bugs.
Now.
B
I
think
there
are
a
few
storage
providers
are
using
this
one
and
which
is
good,
and
the
third
thing
is
about
the
cool
if
amsd
key,
which
is
still
going
on,
and
we
have
some
tools
actually
to
yeah
for
the
user,
to
you,
know
children
and
actually
to
have
some
after
templates.
The
user
can
use
this
tool
to
generate
this
code
automatically
yeah
so
that
they
could
move
on
with
that
code
to
yeah
to
write
their
logic
into
that
template.
B
Okay,
what
is
going
on
is
the
yeah
with
us
htm
this
we
had
kicked
off
two
weeks
ago
and
the
which
is
moving
on
kind
of
slower
stories,
because
that
the
whole
team
is
working
on
the
network
version
16
and
also
the
yeah
blocks
and
the
the
block
stick
team
have
some
vacation
actually
so
yeah
we're
moving
on
this
and
it's
all
good
method.
B
Yeah.
That's
all
right!.
A
Thank
you
steven,
so
the
lotus
teams
and
forest
teams
forest,
unfortunately,
haven't
been
able
to
get
their
updates
in
yet,
but
they
will
be
added
before
the
slides
are
made
available
in
the
six
notes.
Both
teams
are
working
on
final
small
bug
fixes
documentation
to
support
b16
and
most
interestingly,
the
lotus
team
also
just
released
an
updated
roadmap
for
the
next
couple
of
at
least
the
next
quarter.
A
So
there
are
a
couple
of
features
there
and
this
one
in
particular
split
store,
which
has
a
couple
of
features
that
community
members
have
been
asking
for
for
a
while,
including
online
garbage
collection.
It's
going
to
be
presented
at
our
next
core
depths
call
in
two
weeks
time
so
look
out
for
that.
A
Otherwise,
nothing
to
report
no
issues
and
similarly,
with
file
coin
foundation,
not
a
lot
of
changes.
We
have
a
lot
of
movement
in
fit
drafts
and
also
in
discussion
topics.
A
lot
of
this
is
related
to
the
work
that
alex
discussed
and
presented
last
week,
as
well
as
the
the
fifth
that
dick
is
going
to
walk
us
through
momentarily,
but
I
do
want
to
call
out
it's
not
represented
here.
A
Very
clearly,
but
or
at
all
actually,
but
we
do
now
have
a
folder
for
those
frcs
that
have
been
discussed
over
the
past
couple
of
weeks,
so
we
have
the
indexer
protocol
already
merged,
as
our
first
frc
ever
boost
is
going
to
be
in
there
in
the
next
couple
of
days.
I
hope
their
team
is
sort
of
finalizing
their
draft
and
as
discussed,
these
are
sort
of
network
standards
that
we'd
like
to
see
adopted
more
broadly
and
they
exist
to
exist
as
drafts
for
a
pretty
extended
period
of
time.
A
So,
as
we
sort
of
shore
up
these
changes
to
the
core,
devs
call
formalize
things
a
little
bit
better
and
get
a
little
bit
better
consensus
around
who
is
a
cordev
and
who
ought
to
be
attending
these
meetings.
Eventually,
there
may
come
a
time
where
core
devs
are
asked
to
officially
sort
of
approve
those
frcs,
but
this
is
pretty
far
in
the
future.
A
That
being
said,
nothing
immediate.
That
needs
to
be
flagged
but
happy
to
answer
any
questions.
Anyone
may
have.
A
All
right
and
manny
do
you
want
to
talk
about
some
of
the
fuzzing
work,
you're
doing
your
security
topics,
anything
else,
you're
working
on
yeah.
C
Thanks
caitlin,
so
the
reason
why
I
jump
I'm
jumping
on
this
call
is
to
essentially
ask
a
couple
of
questions
to
the
various
development
teams
involved
with
filecoin
we've
been
running
a
whole
bunch
of
buzzers
we've
written
about
15
different
fuzzers.
C
Each
one
supports
or
uses
two
separate
fuzzing
engines,
fl
and
lip
buzzer,
and
so
we've
been
collecting
a
few
crashes
started
investigating
them,
but
we
haven't
actually
pinned
a
commit
for
lotus
and
forest,
and
we
were
you
know,
tracking
the
tip
of
the
default
branch
for
both
repos
and
turned
out
that
at
some
point,
alpha
zero
started
behaving,
let's
just
say
very
differently.
C
So
my
question
is:
do
we
know
if
the
if
there's
like
dedicated
branches
for
the
v16
upgrade
for
these
two
clients?
So
looking
at
lotus?
I
believe
their
latest
release
officially
supports
v16.
C
However,
I'm
not
entirely
sure
where
forest
is
at.
So
I
think
caitlin.
You
mentioned
that
we
don't
have
forest
developers
on
the
call,
but
perhaps
someone
here
has
heard
an
update
from
them
and
could
potentially
point
us
in
the
right
direction.
A
Yeah,
we
also
don't
have
the
lotus
team
on
this
call.
They
joined
the
morning,
one
which
I
think
does
not
work
for
your
time
zone.
If
I
remember
correctly
so
you're
right,
you
have
v1.16
for
lotus,
which
does
support
fvm,
and
then
they
also
have
a
version
17
release
candidate,
that's
going
and
may
be
available
prior
to
mainnet
upgrade
so
both
of
those.
Maybe
candidates
are
fuzzing
currently
for
forest.
A
They
don't
know
if
it's
a
final
version
or
a
release
candidate,
but
they
do
have
like
an
active
version
which
exists
to
support
the
fbm.
Obviously,
but
I
can
find
documentation
for
you
if
you
need
to
be
pointed
to
it,
but
I
do
not
know
what
that
version
number
is
off
the
top
of
my
head.
C
That's
okay.
The
latest
release
that
I
can
see
for
forest
is
from
april,
so
I
wasn't
wasn't
too
sure
if
that
actually
included
the
v16
support
or
not,
but
I
can.
I
can
also
reach
out
directly
to
our
chainsafe
friends.
I
was
also
wondering
whether
venus,
because
we
were
thinking
of
starting
integrating
venus,
currently
supports
v16.
I
can
see
there's
a
release
from
a
few
days
ago.
V1.6
so
question
is
that
is
that
supporting
the
latest
v16
upgrade.
B
Yeah,
okay,
the
very
last
yeah
supported
operation,
16
yeah,
because
we
yes,
the
key
thing-
is
that
we
have
yeah.
We
have
dedicated
in
years
follow
up
all
these
changes,
including
the
fib
yeah,
the
discussion
and
h.I.p
the
whole
process,
and
also
yeah
some
yeah,
some
implementation
in
different
parts,
because
the
way
that
architecture
is
kind
of
kind
of
different
from
the
notice,
so
yeah,
basically
from
this
big
art
point
of
view.
Now
it's
yeah
now
you
change
it
to
the
building
actor.
B
Follow
up
and
to
have
a
kind
of
implementation
and
reference,
and
we
check
we
need
to
you,
know,
change
data
set,
and
sometimes
we
have
the
ffp
by
ourselves.
You
have,
for
example,
the
f5p
yeah
29,
and
we
we
will
have
the
first
implementation
in
and
also
yeah
to
have
this
as
a
reference
and
to
have
other
yeah
implementations
to
follow
this
one,
and
it's
kind
of
this.
So
I
I
was
saying
that
yeah
this
yeah
this
meeting
is
very
important
for
us.
B
You
know
for
all
of
us
to
to
discuss
and
we
need
to
keep
the
pace
of
all
this
upgrading
information.
It
seems
like
this.
C
All
right
so
we'll
just
target
the
1.6
for
venus
and
I'll
build
the
chat
directly.
If
we
have
any
issues
but
yeah,
that's
pretty
much
it.
I
just
just
wanted
to
get
these
points
clarified.
Apart
from
that
making
making
good
progress.
C
As
I
said,
we've
been
running
these
fuzzers
quite
extensively,
as
we
point
them
to
the
relevant
commits
in
the
coming
days,
we'll
be
able
to
triage
the
the
crashes
that
we've
been
seeing
and
I'll
be
reaching
out
to
the
various
client
teams
that
would
need
to
potentially
update
their
code
base
with
bug
fixes,
but
yeah
we'll
get
to
that.
A
Thanks
maddie
and
I
think
some
members
of
the
forest
team
may
soon
be
going
on
vacation
they'll,
obviously
still
mostly
be
around
pending
the
upgrade,
but
do
let
me
know
if
you
have
any
difficulty
getting
in
touch
with
them,
you're
right
that
they
haven't
had
like
a
new
version
release
for
quite
a
few
months,
because
they've
been
working
on
a
lot
of
the
after
structuring
and
testing,
but
they
I
I
want
to
say
that
they
have
made
a
newer
release
like
in
the
last
couple
of
days.
A
B
A
A
But
ayush
also
mentioned
this
morning
that
he's
going
to
begin
assembling,
not
a
war
room,
but
a
v16
party
or
jennifer
kept
calling
it
a
dance
floor
just
for
anyone,
who's
interested
during
the
actual
upgrade
epoch
to
get
together
and
sort
of
respond
to
any
needs
or
bugs
that
arise
in
real
time.
So
he
and
I
are
going
to
work
together
to
sort
of
solicit
participation
in
this
and
we'd
love
to
have
you
or
anyone
else
on
the
on
the
venus
team
join
us.
B
Yeah
sure
no
problem
so
yeah
is
there
a
yes
black
channel
for
this
or
any
anywhere
we
could
join.
A
Yeah,
I
think
he
and
I
are
going
to
talk
it's
going
to
be
quick
to
organize
we're
going
to
either
talk
tomorrow
or
monday,
hopefully,
and
just
spin
everything
up
right
away,
so
just
be
aware
that
it's
happening,
but
a
slack
channel
is
a
pretty
light
lift.
So
we
can
probably
just
open
up
one
this
evening
for
you
to
join.
A
All
right
so
on
that
note,
no
changes,
obviously,
fortunately,
to
the
network,
16
timeline
or
plan.
Everything
should
be,
as
everyone
expects,
and
fortunately,
with
all
of
the
sort
of
front-end
testing
work,
that's
happened
and
all
of
sort
of
the
deep
collaboration
that's
happened
for
this
upgrade
we're
all
expecting.
It
should
be
mostly
smooth,
don't
knock
on
wood.
You
don't
want
to
jinx
anything
but
excited
for
this
to
happen
next
week.
A
A
I
know
that
alongside
the
the
fib
34,
which
alex
wrote
up,
cuba
also
put
in
like
another
sort
of
like
forward
compatibility,
pre-commit
fix
that
will
probably
be
added
to
this
list
also,
but
please
know,
of
course,
this
list
is
very,
very
tentative
still
and
in
order
to
help
us
figure
out
which
fips
to
ultimately
include
and
how
this
is
going
to
help
drive
our
timeliness.
A
Go
around
later
this
afternoon,
I'm
going
to
send
around
documentation
to
all
of
the
implementation
teams
to
ask
that
you
begin
to
sort
of
model
out
what
requirements
you
would
have
for
implementation.
So
you
can
model
this.
However,
you'd
like
it
can
be
the
back
of
the
napkin
estimation
of
resources
and
requirements.
A
D
All
right
thanks,
I've
er,
not
really
a
question
but
jennifer's
been
on
my
case
to
try
and
get
the
the
one
more
fit
that
comes
after
decoupling,
four
plus
from
the
marketplace
to
do
the
design
work
so
that
we
understand
what
scope
that
would
have
as
well.
It's
been
my
goal
to
do
it
this
week.
I
don't
think
I'm
gonna
succeed,
but
there
is
one
more
potential
thing
that
would
come
sort
of
as
as
the
final
item
in
that
chain
of
storage
market
programmability
items.
D
So
I'll
do
my
best
to
update
the
design
for
that,
but
it's
so
sort
of
on
the
age
of
consideration.
I
would
say
at
the
moment.
A
Okay,
thanks
yeah
feel
free
to
flag
it.
I
do
appreciate
how
proactive
you
are
with
a
lot
of
the
documentation
you've
put
forth,
so
it
shouldn't
be
a
surprise.
It
was
presented
last
week
so
or
two
weeks
ago,
so
we'll
let
everyone
get
started
with
this
and
then
once
you
either
have
that
fifth
draft,
or
at
least
just
further
design
details.
We
can
add
it
to
that
sort
of
that
planning
document
and
flag
it
for
everyone
again.
A
A
All
right
steven
any
questions.
B
No
actually
so
yeah.
One
thing
I
want
yeah-
and
I
just
you
want
to
mention
here-
is
that
after
the
network
version
16
upgraded
and
we
will
start
to
yeah,
implement
the
fib
29
like
yeah
yeah,
we'll
we'll
take
this
after.
A
A
Perfect
yeah,
I
think
you
had
said
that
last
week
too,
so
I'll
add
that
as
a
note
in
the
docs,
all
right
cool
so
without
further
ado,
vic,
I'm
happy
to
turn
it
over
to
you
again.
Let
me
make
you
a
host
so
that
you
can
share
your
screen.
A
And
excited
to
have
you
present
the
fifth
that
your
team
has
been
working
on.
E
Great
thanks,
thank
you
caitlyn.
So
can
everyone
see
this.
E
Yeah
on
slideshow
there
we
go
okay,
great
thanks.
So
thanks
for
having
me
guys,
I
really
appreciate
it
speaking
on
behalf
of
crypto
econ
lab
at
the
moment.
As
a
quick
kind
of
summary,
the
idea
crypto
ecolab
once
online,
the
behaviors
of
network
participants
with
one
another,
and
you
know
the
larger
vision
of
the
falcon
network.
E
In
doing
so
when
we
introduce
kind
of
new
changes
or
modify
existing
incentives,
we
want
to
make
as
minimal
protocol
change
as
possible.
So
we
want
the
smallest
chain
service
change
service
that
will
have
the
maximum
impact
and
we
want
to
have
present
a
careful
and
transparent
analysis
of
you
know:
potential
scenarios
of
these
kind
of
of
these
changes
and
obviously
one
we
wanted
to
be
community
different
community
driven.
E
But
currently
we
see
potential
for
economic
improvements,
given
the
current
state
of
the
network
and
the
current
state
of
the
particularly
the
economics,
the
the
macroeconomic
conditions
of
you
know,
the
circular
supply
of
the
economy,
coupled
with
some
of
the
other.
You
know,
mechanisms
that
contribute
to
the
inflationary
and
deflationary
pressures
of
the
the
utility
token,
and
also
we
see
that
there
is
a
potential
to
better
incentivize,
persistent
and
long-term
storage
with
the
introduction
of
incentives.
E
With
that
in
mind,
juan
molly
encrypted
econ
lab
has
introduced
an
initial
draft
of
what
we
think.
Something
like
this
could
look
like.
We
posted
a
discussion
a
couple
weeks
ago
and
we
did
submit
a
pr
in
the
fifth
repo.
Just
the
biggest
caveat
here,
though,
is
that
this
is
just
a
draft.
It's
very
much
subject
to
change.
E
E
So
the
kind
of
idea
is,
we
want
to
add
a
sector
duration
multiplier
for
all
sectors.
This
includes
both
committed
capacity
as
well
as
sectors
containing
storage
deals.
E
The
primary
incentive
here
is:
we
think
that
there
is
kind
of
this
incentive
missing
to
align
the
goal
of
the
network
to
provide
persistent
and
long-term
storage,
because
miners
who
commit
resources
to
the
net
for
long
network
for
longer
do
take
on
added
liquidity
risks,
as
well
as
added
operational
risks
that
aren't
compensated
for.
E
We
want
to
compensate
miners
for
that
kind
of
added
risk
and
similar
to
the
way
that
fill
plus
kind
of
rewards
and
provide
gives
you
a
10x
consensus
power
for,
for
you
know,
storing
useful
data.
We
want
to
reward
storing
data
for
longer,
and
that
is
in
the
sector.
Duration,
multiplier
function
with
that.
We've
also
proposed
increasing
the
minimum
saturation
time
to
one
year
and
maximum
saturation
to
five
years
again.
These
are
tunable
and
subject
to
to
kind
of
debate
and
discussion.
E
But
this
is
our
initial
draft
and
we
we
think
the
same
policy.
This
policy
should
apply
at
sector
upgrade
as
well
as
extension.
So
you
can
see
here
that
you
know
this
equation
at
the
bottom.
Just
kind
of
gives
our
interpretation
of
sector
quality
right
now,
it's
determined
by
the
average
quality
times
the
sector
size.
We
propose
just
adding
on
this
extra
multiplier.
That
is
contingent
upon
the
time
at
which
a
sector
is
committed
for
so
that's
kind
of
the
broad
overview.
E
I
just.
I
really
want
to
make
sure
that
we
understand
that
these
improvements
are
very
much
in
the
discussion
phase.
We
do
think
that,
given
the
state
of
the
network
that
this
is
a,
this
is
an
issue
of
fair
importance
in
terms
of
time.
E
I
think
we
should
we
should
align
with
community
consensus
and
we
shouldn't
rush
things
if
there's
no
need,
but
we
do
think
that,
given
the
current
state
of
the
the
network
and
the
economy
that
this
would
is
preferably
implemented
earlier
rather
than
later
pending,
you
know
kind
of
alignment
with
all
parties.
E
We
also
are
definitely
open
to
considering
alternatives
to
the
initial
model.
We
just
wanted
to
present
something
that
you
know
things
could
look
like,
but
there
are
certainly
potentially
better
solutions
out
there,
but
remember
we
want
to
make
solutions
that
have
the
smallest
change
surface
possible
with
maximum
impact.
So
that's
one
of
the
you
know:
that's
a
constraint
that
we
want
to
keep
in
mind
right.
E
They're,
certainly
very
complicated
manners
of
kind
of
achieving
something,
but
if
it
only
has
an
incremental
improvement
with
a
huge
added
complexity,
we
prefer
to
go
with
something
slightly
easier
to
implement.
So
with
that
in
mind,
here
are
some
questions
we
have
for
the
for
the
court
devs.
We
we
presented
some
of
these
questions
at
the
meeting-
a
couple
you
know
earlier
this
morning
or
on
an
american
u.s
time,
and
we
got
some
fairly
positive
feedback
on
this.
But
how
difficult
would
would
this
be
to
implement?
E
Does
this
break
or
interact
negatively
with
existing
construction
to
the
protocol
and
as
discussed
in
the
in
the
meeting
one,
we
kind
of
came
to
this
loose
idea
that
we
would
like
community
alignment
by
end
of
july.
If
we
were
to
want
to
kind
of
include
this
and
then
that
in
the
v6
v17
upgrade,
but
you
know
these
are
that's,
why
we're
having
another
meeting?
That's
all
there's
another
discussion
to
be
had
here
but
happy
to
answer
any
questions
but
yeah
the
floor
is
floor.
E
Caitlin,
thank
you
for
putting
the
links
in
to
the
discussions
as
well
as
up
here.
Oh
you
are
most
welcome.
A
I
can
also
summarize,
like
broadly
what
we
discussed
this
morning,
obviously
alex
or
steven
your
perspective
and
knowledge
about
this
is
deeper
than
mine,
but
this
is
not
something
that,
in
terms
of
work
or
team
capacities
would
be
that
difficult
to
implement.
This
is
much
more
difficult
as
a
governance
issue,
because
again
the
code
is
pretty
straightforward.
A
I
think
vicky
made
a
great
point
to
say
that
this
is.
You
know
this
is
a
small
incentive.
It
doesn't
change
the
business
logic
at
current
scale
and
that's
important
for
people
to
keep
in
mind.
But
I
want
to
note
also
that
you
said
your
team
is
also
working
on
some
behavioral
modeling.
That
will
help
community
members
also
understand
what
the
presumed
impact
of
a
change
like
this
will
be,
and
that
will
be
available
next
week,
which
I
think
will
be
really
helpful.
E
A
D
Any
other
yeah,
obviously
like
important
points
here,
we'll
go
and
raise
in
written
form
as
well,
but
my
impression
is,
this
is:
is
going
to
interact
with
a
few
existing
constructions
of
the
protocol,
mainly
because,
when
the
reward
for
a
sector
increases
that
changes
its
initial
pledge
and
that
pledge
is
used
as
the
as
the
as
an
input
to
lots
of
calculations,
in
particular,
everything
to
do
with
penalties
ends
up
being
produced
out
of
this
as
well,
but
the
the
you
know,
the
the
magnitude
of
a
penalty
is
not
usually
related
to.
D
The
sometimes
is
related
to
the
duration
of
the
commitment,
and
sometimes
it's
not
related
to
the
duration
of
the
commitment,
and
so
they
need
to
be.
You
know
recalculated
to
understand
that
and
then
the
risk
of
penalty
through
operational
failure,
even
so
you're
well-behaved
minor
operators,
they
still
fail
sometimes,
and
so
then
their
your
expected
return
calculations.
I
need
to
factor
in
larger
penalties
if
penalties
get
bigger
depending
so
I
think
there
is
a
set
of
interactions
there.
E
When
you
say
we'll
need
analysis,
do
you
mean
from
like
the
perspective
of
how
this
affects
the
crypto
economics
like
or
from
the
perspective
of
how
this
would
be
implemented,
given
the
initial
the
the
constructions
of
initial
pledge
and
how
how
we
spec
out
slashing
just
so
I
understand
this
from
from
my
end,.
D
I
I
I'm
not
saying
the
implementation
is
going
to
be
particularly
difficult,
except
for
the
fact
that
we
may
have.
We
may
have
to
change
the
implementation
of
a
bunch
of
penalty
things,
because
the
naive
like
just
take
the
pledge
as
it
is
now
might
produce
the
wrong
result.
D
D
D
Obviously
we
haven't
seen
that
yet
I
think
that's
probably
the
reason
for
a
large
amount
of
community
concern
is
that
that
I
think
there's
a
perception
that
you've
thought
about
a
lot,
but
you
haven't
shared
any
of
that
thinking
with
us,
and
so
I
I
heard
caitlyn
refer
to
the
fact
that
this
is
going
to
be
hopefully
some
stuff
coming
out
next
week,
but
then
to
sort
of
address
the
like.
D
I
think,
the
biggest
the
biggest
thing
right
now
to
answer
the
question
about
like
what
would
we
need
to
see
to
see
this
ratified
for
the
next
network
upgrade
is
like
well
step.
One
will
be
that
analysis.
The
community
can't
really
engage
in
the
discussion,
yet
until
we
have
that,
I
mean
obviously
you're
really
interested
parties
could
go
and
try
and
redo
that
analysis.
But
that's
probably
a
waste
of
time,
because
we.
D
Probably
don't
a
good
job
of
it.
The
discussion
can't
really
start
in
earnest
about
you
know,
trade-offs
and
values,
and
until
we
see
that.
E
Yeah,
that's
entirely
fair.
I
think
that
we
wanted
to
make
sure
that
internally,
we
agreed
on
the
analysis
itself
and
we
were
fairly
careful
about
these
assumptions
just
because
of
the
sensitivity
of
kind
of
just
throwing
out
crypto
economic
assumptions
without
a
strong
basis,
that's
fairly
robust
and
something
that
we're
confident
in,
which
is
why
you
know
we've
been
working
over
that
we've
taken
a
lot
of
community
feedback.
E
That's
come
in
last
week
and
this
week
we've
been
kind
of
refining
and
working
on
our
models
to
answer
them
as
transparently
as
possible,
and
we
want
to.
We
want
to
get
this
out
next
week.
We
want
to
share
like
these
kind
of
these
the
scenario
analysis
that
we
think
will
actually
help.
The
community
have
a
more
fruitful
discussion.
D
Yeah
thanks,
so
let
me
see.
I
am
very
much
pleased
that
you
started
the
discussion
sooner.
It
would
be
an
anti-pattern
I
think,
to
have
not
even
produced
anything
until
after
you've
done
all
of
the
analysis
and
then
we're
sort
of
even
more
locked
into
the
like
convinced
that
your
own
ideas
were
correct
and
then
then
published
it.
That
would
be
worse
pattern
than
the
current
one,
even
though
the
current
one
feels
like
you
get
pushed
back,
because
you
don't
have
all
the
answers
straight
away,
it's
actually
much
better
than
the
pushback
you'd
get.
D
If
you,
if
you
thought
you
did,
have
all
the
answers
but
you're
without
involving
community
at
all.
A
I
fully
concur
because
of
the
way
we
we
design
this
consensus
and
how
soft
it
effectively
is.
It's
really
important
that
you
have
been
so
proactive
and
sort
of
sharing
these
things
early
on,
because
it
helps
us
sort
of
craft
a
more
desirable
outcome,
one
way
or
the
other,
rather
than
just
having
to
decide
yes
or
no
on
something
that
just
popped
up.
All
of
a
sudden,
fully
formed.
B
Yeah
sorry
yeah.
I
have
two
comments
here
and
yeah,
and
I
also
mentioned
in
lesson
mentioned
one
in
in
the
comments
you
know
discussing
here.
The
first
thing
is
that
I
was
saying
that
okay
in
this
meeting
yeah
because
yeah
this
meeting,
we
have
yeah,
we
call
it
date,
yeah
code
meeting.
So
we
have
the
implementers
here
so
yeah
from
the
yeah
implementation
point
of
view.
I
would
think
yeah.
B
This
is
one
thing
right
right,
so
we
could
yeah
connect
some
opinions
or
your
feedback
they're
from
designers
and
yeah,
but
and
on
the
other
hand,
we
need
to
give
some
feedback
from
other
and
other
community
members.
For
example,
we
could
yeah
collect
some
some
feedback
from
the
the
storage
provider
working
group
or
some
other
clients,
including
the
the
enterprise
clients.
And
yes,
it
is
because
one
thing
is
that
this
may
increase
the
cost
of
the
storage.
B
Actually,
yes,
this
the
service,
so
I
think
yeah
that
could
you
need
to
come,
consider
so
yeah,
it's
about
the
con,
it's
about
the
governance
and
we
need
to
get
more
feedback
yeah
from
different
different
community
members.
Okay,
that's
one
thing.
Another
thing:
yeah:
okay,
basically,
I
agree
that
we
need
to
encourage
the
storage
providers
to
save
the
data
longer
and
to
keep
the
the
little
stable
at
this
same
time.
In
principle,
the
initial
place
the
clutter
is
to
is
for
the
service
yeah.
B
They
they
yeah
is
for
the
service
quality
is
to
guarantee
that
service
yeah
could
be
yeah
fulfill
right.
So
I
would
like
to
think
from
the
service
point
of
view,
which
means
that
okay,
our
virtual
vision,
is
to
provide
the
secure
and
also
cheaper
yeah
storage
for
our
clients.
So
we
need
to
be
very
careful
to
design
this
kind
of
thing.
B
Well,
we
encourage
people,
the
stories,
the
providers
to
your
store
and
your
data
longer
have
a
longer
duration
sector,
but
and
at
the
same
time,
when
you
do
yeah
sim
class
to
keep
yeah
can
be
cheaper,
yeah,
keep
it
and
actually
affordable,
yeah
for
our
clients
or
the
the
storage
providers.
B
So
everything
that,
if
current
amount
of
initial
pledge
is
secure,
your
code
guarantee
is
because
we
have
the
policy
right.
We
have
the
collateral
and
power
to
to
guarantee
or
to
make
sure
that
the
service
is
stable,
so
we
we
should
maybe
keep
this
stable
right
yeah
if,
if
it
is
secure,
so
everything
that
if
we
have
this
sdm
introduced,
we
need
to
design
this
function
and
try
to
keep
the
average
initial
page
at
the
same
level.
B
Yeah,
if
that
is
not
secure,
if
we
think
the
initial
place
is
not
enough
yeah,
we
need
to
increase
it.
Basically,
we
will
come
back
to
think
about
the
the
principle
which
is
actually
designed.
E
E
So
so,
if
I,
if
I
understand
this
correctly
to
clarify,
I
think
that
the
intention
of
the
fifth
is
to
you
know,
increase
the
consensus
power
for
longer
deals,
but
that
would
require
a
higher
collateral
requirement
as
well,
which
I
think,
maybe
answers
your
question.
Maybe
maybe
it
does
not
but
yeah.
That's.
That
is
because,
like
similar
to.
B
E
For
example,
similar
to
how
fill
plus
deals
require
10x
collateral,
that
the
collateral
increase
for
a
longer
sector
would
be
proportional
with
relation
to
their
increased
consensus
power.
Maybe
I
didn't
make
that
clear,
sorry
about
that,
but
that
is
the
intended
goal
this.
This
fifth
is
to
also
increase
that
consensus
collateral
requirement.
D
E
I
see
if
consensus
initial
pledge
is
a
function
of
your
expected
block
reward
as
well
as
your
your
qap,
so
with
it
so
with
relation
to
other
sectors.
Yes,
their
initial
pledges
would
be
would
be
lower,
but
they
would
also
you
know,
share
it
unless
of
the
rewards
measure
commercially
right.
D
Yeah,
I
I
think
that
makes
sense.
I
guess
one
of
the
bits
of
analysis
is
like.
What's
the
effect
of
on
the
total
initial
pledge
lock
up,
I
think
stephen's
point
is
like
the
total
pledge
right
now.
We
believe
is
sufficient
to
secure
the
quality
of
service
that
there's
not
there's.
There
is
a
justification
for
increasing
the
pledge
on
a
per
sector
basis
for
the
higher
consensus
power.
If
this
affects
the
total
amount
of
pledge.
What's
the
justification
for
that,
I
don't
know
if
it
does
affect
the
total
pledge.
E
Yeah,
that's
something
that
we
are
working
on
and
are
happy
to
share.
I
think
the
intuition
is
that
it
what
it
would
kind
of
have
an
effect
on
the
total
amount
of
initial
fudge
locked,
but
remember
that
we
are
also
kind
of
giving
out
more
rewards,
because
we've
introduced
this
idea
that
we
economically
prefer
certain
sectors
that
are
longer
over
others
because
of
the
value
that
they
have
or
present
to
the
network.
A
Yeah,
it
would
be
great
to
stephen,
after
that
analysis
shared
to
sort
of
get
your
your
thoughts
and
feedback
on
it,
whether
it
addresses
your
concerns
or
if
you
have
a
particular
opinion,
one
way
or
another,
about
the
potential
impact
of
the
clip.
E
Okay,
sure
yeah,
so
stephen
another
thing
I
heard
just
to
make
sure
I
I
got
I
got
it
right
was,
I
think,
we've
talked
a
lot
about
the
supply
side.
Economics
I.e
like
what
it
would
cost
for
storage
providers
and
with
their
initial
pledge
and
stuff,
but
you
also
mentioned
stuff
from
the
client
side.
With
regards
to
potentially
data
costing
more,
I
think
I
think
I
think
you
said
something
along
those
lines
did
I
did
that.
E
Did
I
just
hear
that
I
think
the
the
initial
response
that
I
would
I
would
give
is
data
is,
is
fairly
fairly
free
now,
given
the
fill
plus
kind
of
program.
So
I
don't
anticipate
that
this
would
have
an
adverse
effect
on
on
something
like
fill
plus
just
because
they're
they're
they're
like
not
exactly
orthogonal
but
they're,
fairly
kind
of
independent,
and
so
those
incentives
to
exist
for
for
data
to
to
not
kind
of
cost
more.
But
maybe
I'm
missing.
E
Something
here
feel
free
to
like
put
your
thoughts
in
the
in
the
description
as
well,
but
we
can
continue
the
discussion
here,
I'm
happy
to
do
it
either
way,
but.
B
Basically,
yeah
we
can
discuss
more
offline
if
we
increase
the
initial
pledge
and
actually
the
capital
cost
is
higher
for
the
storage
provider
to
save
to
save
the
same
amount
of
data
yeah.
You
know
you
have
a
yeah
yeah
yeah.
B
For
that
know,
you
will
have
you
yeah
if
we
request
more
use
your
page
even
with
a
longer-
and
you
know,
but
actually
there's
a
cast
entire
phone
yeah,
because
you
need
to
have.
E
A
All
right,
so
it
sounds
like
for
us
next
pepper,
to
wait
for
vic
and
the
team
to
prepare
their
analysis
and
make
it
public
so
that
we
can
all
sort
of
continue.
A
The
discussion
vic
you
and
I
should
also
connect
offline
again
about
sort
of
continuing
to
share
share
word
of
this
fifth,
so
at
the
store
provider
working
group
meetings
that
steven
mentioned
in
other
places,
also
just
so,
we
stay
on
top
of
of
this
july
timeline,
which
summers
always
fly
by
and
this
one
in
particular,
as
we
move
from
one
network
upgrading
to
another.
We
want
to
make
sure
that
we
stay
on
top
of
this,
should
it
be
adopted
for
inclusion,
but
I
do
think
to
the
conversation
we
had
10
minutes
ago.
A
This
should
also
be
on
the
list
of
tips
that
we
ask
implementers
to
begin
to
sort
of
model
implementation
pathways
for
just
there's
no
surprises
and
that
we
can
call
attention
to
it.
I
know
you
presented
to
the
the
forest
team
this
morning.
I
think
the
lotus
team
had
to
drop
off,
but
it's
important
that
they
stay
involved,
especially
as
all
of
our
fifth
discussions
are.
So
essential
to
our
upgrade
planning
sounds
here
to
me.
A
A
A
The
plan
will
have
us
having
one
more
meeting
like
this
right
after
the
network
upgrade
and
then
moving
beginning
in
august
to
that
new
monthly,
much
more
formalized
format
so
be
on
the
lookout
for
that
it
shouldn't
be
any
surprises.
But
if
you'd
like
to
weigh
and
you're
welcome
too
otherwise,
we
will
see
you
all
in
two
weeks.