►
From YouTube: Filecoin Core Devs #49
Description
Recording for: https://github.com/filecoin-project/tpm/issues/110
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
welcome
everyone
to
this
meeting.
It
is
file
coin.
Core
devs
number
49.
today
in
the
western
hemisphere,
is
thursday
september
1st
2022..
Thank
you
all
for
coming
some
great
conversations
already
going
on,
but
this
is
going
to
be
a
jam-packed
meeting.
I
think
today
so
a
reminder,
please
try
and
keep
focused
and
if
you
have
any
questions
as
always,
raise
hands,
feel
free
to
jump
in
etc.
A
Today's
agenda
a
welcome
which
is
this
and
then,
as
discussed
publicly
we're
going
to
have
discussions
around
product
requirements
in
fit
45
we're
going
to
have
a
discussion
of
fit47,
which
is
now
known
as
proof,
expiration
and
security
policy
and
finally
go
over
the
b-17
network.
Upgrade
plan,
look
at
some
hard
dates
and
also
discuss
the
remaining
governance
pathway
for
fifth
36
in
particular,
also
want
to
keep
it
very
brief,
but
do
want
to
draw
attention
that
we
have
a
new
person
on
the
call
today
in
particular
lucky
or
kayla.
A
He
has
joined
us
at
the
foundation
and
he
is
our
new
and
first
ever
governance
project
manager.
So
he
is
beginning
his
onboarding
now
hopefully
taking
part
in
launch
pad
in
this
next
cycle,
but
he
will
be
joining
us
going
forward
and
you
will
all
get
to
know
him
over
the
coming
days.
B
Okay,
thank
you
so
this
right.
So
recently
we
published
a
draft
actual
fit
for
something.
We've
been
working
on
for
some
weeks
now,
which
the
background
for
this
is
motivated
by
flip
36,
the
sexy
duration
multiplier
as
part
of
their
change.
They
proposed
increasing
the
maximum
sector,
commitment
duration
from
the
one
and
a
half
years
that
it
is
now
to
a
full
five
years,
so
that
yeah,
which.
B
Generally,
so
that
providers
can
make
long
commitments
to
storage
they'll
be
committed
to
the
network
for
a
long
period
of
time
and,
of
course,
also
included
multipliers
for
those
longer
commitments.
B
That
change
threatens
a
a
sort
of
security
mechanism
present
in
the
protocol
right
now,
which
is
a
mitigation
in
case
that
we
discover
flaws
in
the
proof
of
replication
theory
or
implementation
that
analyze
all
of
the
storage-powered
consensus
security
network.
Such
a
bug
has
been
discovered
before,
and
this
mechanism
was
effectively
used
to
mitigate
it
and
all
of
the
sectors
that
were
part
of
that
bug,
I
believe,
have
probably
rotated
out
of
the
system.
B
By
now,
I
haven't
quite
done
math,
but
they
were
unable
to
be
extended
and
knew
a
new,
more
secure
power
up
was
mandated.
B
So
this
proposal
separates
the
validity,
the
duration
for
which
your
proof
is
valid
from
the
duration
for
which
a
command
sector
is
committed,
instead
of
them
both
being
one
and
a
half
years.
It
now
allows
the
sector
to
to
be
committed
for
five
years,
while
the
power
rep
retains
a
one
and
a
half
year
for
would
be
period
and
needs
to
be
refreshed
every
one
and
a
half
years.
B
B
The
flow
instead
would
here
be
that
they
can
commit
up
front
for
five
years,
possibly
getting
a
multiplier
if
the
36
is
approved,
but
then
still
every
one
and
a
half
years
they've
got
to
come
in
and
tick
the
box
to
extend
their
profility
for
another
one
and
a
half
years.
B
The
point
of
this
is:
if
we
discover
a
flaw
in
poep,
we
can
disable
extending
ability
of
existing
proofs
and,
over
the
course
of
the
next
one
and
a
half
years,
all
of
those
proofs
all
of
those
sectors
will
be
forced
to
expire
and
be
replaced.
You
know,
that'd
be
optionally,
replaced
and
provided
discretion
by
a
new
sector,
sealed
with
a
new,
more
secure
power.
If
it
turns
out
that
we
can,
you
know,
implement
some
kind
of
you
know,
depending
on
what
goes
wrong
with
power.
B
If
anything,
if
it
does,
it
might
turn
out.
There's
tricks
where
we
can.
You
know,
leave
the
sector
in
place
and
just
fix
it.
You
know
essentially
reseal
it
in
place,
but
at
the
moment
we
have
no
known
techniques
for
doing
that,
and
it
will
depend
what
went
wrong
with
the
product
and
what
the
fix
was
as
whether
that's
possible.
B
So
the
base
case
is
that
we
that
those
sectors
can
no
longer
have
their
price
extended
and
the
provider
must
submit
a
new
one
and
the
basic
economic
policy
behind
this
is
sort
of
the
main
behavioral
change
from
the
status
quo.
B
Today,
the
economic
change
is
that
providers
medicaid
for
five
years,
and
then
we
disallow
their
proof
to
be
refreshed,
would
have
to
submit,
would
have
to
commit
a
new
sector
to
replace
it
or
they
would
face
a
termination
fee
for
their
old
sector,
not
meeting
its
commitment.
B
B
Yeah,
the
the
the
policy
difference
between
this
and
the
status
quo
is
today
the
status
quo.
A
private
provider
cannot
commit
to
five
years
up
front.
They
can
only
make
a
one
and
a
half
year
commitment,
so
at
the
end
of
one
and
a
half
years,
they're
never
facing
a
termination
fee
if
they
decide
not
to
refresh
the
sector
or,
if
they're
forbidden
from
refreshing
their
sector.
Because
proof
is
invalid.
With
this
new
one,
if
a
provider
makes
a
five-year
commitment,
but
then
we
disallow
them
from
refreshing
their
proof.
B
B
Which
is
a
bit
similar
to
the
replacement
mechanism
that
was
in
place
some
time
ago
for
cc
upgrade
before
we
implemented
snap
stamp
tips.
B
B
B
Change
is
required,
in
my
view,
if
we
to
accept
36,
because
otherwise
we
lose
this.
This
key
mechanism
that
allows
us
to
cycle
over
all
of
the
sector
proofs
in
a
one
and
a
half
year
period
and
gives
us
seven
your
worst
case,
one
and
a
half
year
period
to
flush
any
bad,
any
bad
proofs
out
of
the
system.
B
It's
also
independently
valuable
because
it
lets
us
do
you
know
one
out
of
the
three
pieces
that
fit
36
was
proposing
which
has
just
increased
the
maximum
equipment
to
five
years.
That
would
you
know
this.
47
on
its
own
doesn't
provide
any
incentive
to
have
a
long
commitment,
but
it
would
allow
providers
to
accept
a
deal
that
was
five
years
long,
and
so
there
would
be
an
incentive
to
seal
a
five-year
sector
if
you're
going
to
put
a
five-year
deal
in
it,
and
so
we
in
fact
end
up.
B
I
think
seeing
that
the
only
people
who
the
only
providers
who
use
this
functionality
would
be
those
providers
who
are
taking
full
plus
deals,
and
so,
if
anything,
this
makes
it
slightly,
you
know
makes
that
fill
plus
data
cut
more
valuable
because
it'll,
you
know,
it'll
be
a
five-year
term
rather
than
a
one-and-a-half
year
term.
B
That's
independent
of
545,
which
of
course
another
another
topic
here,
but
yeah
this
on
its
own
independent
of
any
of
the
other
proposals
has
this
benefit
of
his
letter
of
allowing
us
to
take
five-year
deals
by
by
making
mistake.
Government
yeah.
C
Just
have
a
question
just
like
look
at
this
flipper
loan
and
curious,
like
what
a
storage
provider
first
like
commit
like
a
sector
say
like
five
years
like
do
they
put
down
the
collateral
at
the
beginning
of
the
commitment,
or
do
they
put
down
more
like?
Do
we
recalculate
the
collector
when
you
extend
their
like,
you
know,
exploration,
like
commitment.
B
The
terminology
is
a
bit
off
there,
but
you
know
if
there
might
be
a
commitment,
then
they
just
they
will
put
collateral
down
once,
which
will
be
stable
for
the
whole
five
years
without
multipliers.
It'll
just
be
the
normal
collateral
for
that.
C
A
Lauren
go
ahead.
You
have
a
question
yeah
so
best
case
in
18
months.
E
A
F
B
I
know
the
the
proof
refresh
thing
here
is
merely
it's
just
a
token
message:
they
don't
have
to
do
any
work.
They
just
have
to
say
I'm
refreshing,
my
proof.
It's
more
like
asking
permission
of
the
network
to
refresh
their
proof.
They're
they're,
asking
permission.
Is
this
per
rep
algorithm
still
valid
for
another
one
and
a
half
years?
And
then
it
just
just
says:
yes,
there's
no
resealing
involved.
F
E
I
gotcha
so
that
does
put
more
risk
on
them
for
taking
a
five-year
deal.
F
B
Look
it's
relative.
The
concrete
write-up
for
is
relatively
new.
It's
been,
you
know
as
a
place
the
the
discussion
post
motivating.
It
is
now
some
weeks
old,
but
this
concrete
mechanism
is
relatively
new.
Like
I
said
it's
motivated
by
by
flip
36.
I
probably
wouldn't
have
got
at
this
concrete
if
56
wasn't
pushing,
we,
if
I
didn't
consider
it
a
prerequisite
for
36,
but
now
this
far
it's
independently.
We've
realized
it's
independently
valuable.
It's
not
mandatory
to
get
here
if
36
is
not
accepted.
It's
not
mandatory.
B
To
put
it
in
network
for
17
would
be
possible
to
wait,
be
slightly
annoying
to
the
implementers
since
we've
already
written
the
code
for
it,
but
it's
it's
possible
to
defer
it.
A
And
also
just
to
note,
this
is
the
name
of
the
official
fip
draft
with
the
fip
number.
This
was
previously
listed
as
the
po
rep
policy
and,
as
alex
mentioned,
has
been
available
for
quite
a
while.
Now
it's
also
previously
been
presented
to
core
devs,
and
if
anyone
wants
a
link
to
that
meeting,
recording
where
there's
greater
detail
added,
we
can
share
it
as
well.
I
think
it
was
meeting
43,
but
I'm
not
sure
so
I
can
follow
up
with
you
deep.
Do
you
have
a
question.
G
Yeah,
so
it
looks
like
in
the
chat
like
536
is
going
to
be
adjusted
down
to
a
max
duration
of
3.5
years.
Does
that
mean
that
this
would
also
be
adjusted
down
to
a
duration
of
three
point
five
years,
or
will
this
still
be
at
five?
And
if
yes,
then,
is
the
max
multiplier
for
a
sector?
Still
three
point:
five.
C
I
feel
like
is
your
question
related
to
47
because,
like
I
want
us
to
finish
this
and
move
on
to
flip
36,
which
will
be
a
bigger
thing
because,
like
I
think
the
whole
point
here,
the
fitbit
itself
without
fib
36,
if
it's
variable,
should
we,
you
know
yesterday
also
because
there
that's
a
priority
for
networking
either
lb70
or
the
upcoming
upgrade.
We
don't
know.
I
think
we
should
discuss
that
later.
G
F
B
B
There's
there's
jenny's
right
to
stress
that
we
should,
in
the
first
case,
consider
all
of
these
changes
independently.
Okay,
this
change
allows
a
sector
to
do
committed
for
five
years.
If
some
other
fip,
like
45,
demands
that
the
sector
not
be
longer
than
it's
deal,
then
that
constraint
will
also
apply
but
cool.
B
No,
I
well
if
it
makes
it
doesn't
make
it
doesn't
change
the
implementation
of
536.
It
removes
what
I
consider
to
be
a
security
flaw
that
fit
36
introduces
great.
A
D
Yeah,
I
don't
want
to
take
up
too
much
time
this
so
maybe
we'll
go.
We
can
take
a
discussion.
I
think
I
like
this,
but
I
like
this
proposal.
I've
always
liked
the
simplicity
of
it.
It's
a
nice
elegant
way
to
yeah
diffuse,
a
potential
bomb
and
so
yeah,
I'm
overall
favorable.
D
I
think
the
a
couple
of
thoughts
that
I
have
are
I
do
I
I
think
I
understand
why
it
has
to
be
the
case,
but
I
think
it's
unfortunate
that
a
sector
that
was
committed
for
a
five-year
period
and
then
rendered
unextendable
or
it's
poor
app
was
rendered
unextendable
has
to
face
a
termination
fee.
If
it's
not
resealed.
I
think
I
understand
why
that
has
to
be
the
case,
especially
if
there
are
deals
in
it,
but
I
that
feels
bad
it.
D
It
feels
a
little
yeah
difficult
to
request
source
providers
to
reseal
those
sectors
when
they
thought
that
you
know
they
were
sealing
them
once
and
would
be
fine
to
to
have
it
live
for
five
years.
So
yeah,
maybe
I'd
like
to
consider
the
possibility
of
waiving
the
termination
fee.
In
that
case,
if
possible,
number
two
yeah
go
ahead.
B
Yes,
I
agree.
We
need
more
modeling
to
understand
what
the
effects
of
the
network
would
be
of
various
penalties
applied
to
a
sector
in
that
situation,
where
we're
forcing
essentially
forcing
resealing,
I
think
I'm
not
I'm
not
convinced
that
the
domination
fee
is
the
right
value
and
that
that
a
smaller
value
wouldn't
be
better
for
the
network
as
a
whole.
But
we've
got
to
pick
pick
something
to
like
telegraph,
the
policy
to
providers
in
this
proposal
so
that
they
can
be
prepared.
B
You
know
they're
prepared
for
this
eventuality
if
they
do
go
and
make
a
five-year
commitment,
it
may
well
be
that
we
can
do
better
modeling
and
reduce
that
that
fee
in
the
future,
but
sure.
D
Yeah
I'll
do
that
now,
yeah,
I
think
that'll
be
good.
Second,
thought
is
so,
if
I'm
understanding
correctly,
this
is
going
into
the
details
of
the
system
a
little
bit,
but
the
expiration
queues
for
these
sectors
will
not
change
as
a
result
of
this
policy
like
they
will
still
be.
So.
If
I've
committed
a
five-year
sector,
they
will
still
be
scheduled
to
expire
1.5
years
from
now
and
the
re-extension
happen,
and
then
the
extended
sector
expiration
or
what,
if
there's
a
new
method,
will
will
we
move
that
forward?
D
If
that
is
the
case,
and
I
see
uniting,
would
it
be
possible
to
automatically
extend
so
that
search
writers
don't
have
to
explicitly
extend
these
sectors?
If
I
see
that
you've
committed
something
for
five
years
and
at
the
time
of
your
expiration,
I
check
I
can
check
the
system
can
check
that
the
poor
app
is
in
fact,
still
valid.
Can
that
just
slide
it
forward
by
another
1.5
years.
B
That's
a
really
good
question.
I
have
to
think
about
it.
It
may
be
possible.
That's
good
yeah,
jen's,
saying
no
more
crown.
D
F
But
I
strongly
prefer
this
interaction,
point
of
storage
provider
going
and
sending
this
message
and
getting
like,
like
it
being
an
interaction
point
that
and
that
interaction
being
disallowed
in
the
future,
because
it
clearly
signals
to
the
tooling
and
so
on
that
in
future,
when
when
a
extension
of
such
sector
is
disallowed,
that
some
action
should
be
taken.
A
C
F
Yeah,
okay
yeah,
I
had
yeah.
I
have
revealed
this
proposal.
I
think
it's
very
good.
It's
a
yeah
provides
a
provider,
the
flexibility
for
for
us
to
have
a
longer
duration
of
the
sectors
and
also
could
have
the
security
issue
be
handled
here.
Yeah.
One
thing
I
want
to
mention
that,
which
is
also
increased:
the
complexity
of
the
yeah,
the
proof
actually
and
especially
yeah
for
all
the
sps
we
need.
F
I
would
suggest
we
have
yeah
some
guidance,
yeah
some
setup
for
before
sps,
to
follow
to
these
some
scenarios
and
emailing.
Yes,
scenarios
they
and
the
storage
providers
can
you
can
follow
to
to
avoid
any,
for
example,
this
kind
of
yeah
penalty
yeah,
which
might
happen,
and
also
in
our
implementations
I
would
yeah.
I
would
like.
Firstly,
we
we
try
our
best
to
to
make
it
yeah,
make
it
a
bad
country,
bad
confidence.
F
I
mean
that
yeah,
for
example,
the
the
proof
expiration
and
the
secretary
expiration
will
be
the
same
right
and
later
on.
We
will
have
some
other
change
to
make
it
much
more
flexible.
B
I
don't
quite
understand
the
second
part
of
your
question
to
the
first
part.
This
does
this.
Does
it
this
does
change
slightly
change
the
operational
characteristic
for
a
provider
who
makes
a
commitment
that's
longer
than
a
year
and
a
half
right,
someone
who
just
does
one
half
of
your
commitments.
There's
no
change
here.
B
Their
proof
will
never
expire
before
the
sector
does,
but
if
they
do
take
on
the
one,
the
greater
than
one
and
a
half
year
expiration,
that
provider
has
to
be
online
to
to
make
the
proof
refresh
call
at
some
point
in
the
you
know,
four
months
before
the
before
the
proof
expires,
and
they
will
face
a
penalty
if
they
don't
do
it
now.
B
This
is
just
in
the
normal
case,
I'm
not
talking
about
in
the
case
where
we
have
discovered
a
bug
in
perp,
it's
difficult
to
precisely
describe
today
what
our
options
are
in
case
we
discover
a
bug
in
improv,
because
it
depends
a
lot
on
the
severity
of
the
bug
and
exactly
what
it
is
and
exactly
what
a
improved
would
look
like.
This
is
sort
of
the
the
shape
of
things
like
well.
Your
sectors
are
all
going
to
expire
and,
if
you
don't
replace
them,
you'll
probably
pay
a
fee.
B
A
Thanks
steven
and
thanks
alex,
I
think,
for
the
sake
of
time,
we're
going
to
jump
over
to
talking
about
fit45
if
there
are
additional
questions
about
the
parameters
or
specs
for
fit47,
definitely
take
a
look
at
the
existing
vip
draft
and
feel
free
to
comment.
Ask
questions
in
all
of
the
usual
places,
but
for
now
I
think
we're
gonna
jump
down
and
switch
topics
forgetter
for
bad.
I
think
it's
for
good
alex
this
one
is
also
yours.
B
Yeah,
so
the
45
draft
is
approaching
completeness
now,
with
sort
of
a
couple
of
with
a
couple
of
notable
pieces
that
are
not
fully
resolved,
and
so
I
want
to
raise
them
here
for
discussion,
make
sure
they're
part
of
the
discussion.
The
someone.
B
To
discussion,
313
there's
also
a
link
to
the
vip
draft
itself.
A
couple
of
points
are.
C
B
Of
the
one
of
the
points
is
what
policy
the
built-in
market
actor
should
take
when
creating
allocations
on
behalf
of
its
clients.
One
of
the
key
changes
that
this
fit45
introduces
is
that
the
term
for
a
full
plus
allocation
can
be
a
range,
so
it
has
a
minimum
and
a
maximum
duration
for
which
the
field
plus
allocation
will
be
about
valid
and
it
can
earn
the
full
qa
multiplier
throughout
any
part
of
that
that
range.
B
The
reason
for
this
range
is
so
that
deals
from
multiple
you
know,
so
that
deals
with
multiple
different
plus
allocations
can
be
packed
into
the
same
sector
as
long
as
their
ranges,
overlap,
they're
mutually
compatible
and
can
be
can
be
put
into
the
same
sector
because
the
you
know
the
key
mechanism
that
implements
an
upper
limit
on
the
on
the
life
of
a
field
plus
allocation
that
this
proposal
introduces
is
that
the
sector
must
expire
before
the
field
plus
allocation
expires.
So
if
you
have
a
field
plus.
B
B
Were
a
bunch
of
football
allocations
ahead
that
had
you
know
exactly
a
three-year
term,
but
if
a
bunch
of
field
plus
allocations
had
terms
that
were
different
but
were
specified,
exact
numbers
you'd
never
be
able
to
put
them
together
into
one
sector,
and
just
generally,
a
provider
only
has
limited
control
over
the
the
epoch
that
the
sector
activates,
and
so
they
need
someone
with
a
little
buffer
here,
all
right,
so
you
know
long
story
short.
B
The
built-in
market
actor
needs
to
have
some
policy
that
the
client
can
only
specify
one
number
for
their
deal.
Duration-
and
this
this
proposes
that
that
number
be
interpreted
as
the
minimum
term
for
the
for
the
deal.
So
the
data
must
be
stored
for
at
least
this
long,
and
then
the
built-in
market
has
to
has
to
pick
some
number
for
the
maximum,
which
is
some
number
larger
than
that
minimum,
and
so
one
of
the
policy
questions
is
how
much
larger
we
need
to
make
it
just
a
little
bit
larger.
B
To
be
practical,
we
could
make
it
a
lot
larger
one
of
the
arguments
for
making
it
a
lot
larger
is
that
most
clients,
many
clients.
B
We
evidence
suggests
that
many
clients
would
like
to
specify
really
long
deals,
but
they
can't
because
the
built-in
market
is
lame
and
can't
support
that
and
so
a
longer
one
is
a
better
representation
of
what
the
clients
actually
want
for
those
cases.
B
But
on
the
other
hand,
there
are
some
clients
who
don't
want
to
specify
really
long
term,
and
so
then
you're
not
not
not
not
increasing
the
term
maximum.
By
too
much
is
a
better
representation
of
those
clients
needs
all.
Those
will
be
fixed
six
months
from
now
when
we
do
the
final
round
of
changes
in
this
and
then
we'll
have
clients
that
can
specify
both
the
term
min
and
max,
and
you
make
their
own
arguments
about
this.
B
But
we
have
this
stepping
stone
where,
in
order
to
keep
all
of
the
client
facing
apis
and
tooling,
the
same
there's
no
facility
for
the
client
to
specify
the
term
range
and
they're
using
the
built-in
market
actor
is
acting
as
their
delegate.
B
So
I
think
I
can't
remember
whether
I
put
six
months
or
one
year
as
the
placeholder
value
for
this
in
the
fit
itself,
so
relatively
large
amount
six
months.
So
relatively
large
amount
in
order
to
you
know
to
make
deals
easy
to
pack
without
well.
You
know,
while
doing
a
pretty
reasonable
job
of
respecting
clients,
deal
terms,
we
could
possibly
make
it
shorter,
but
we've
got
to
pick
a
number
for
them.
The
other
big
question
here
about
is
actually
let
me
pause
just
briefly
I'll.
C
Yeah,
I
guess,
like
I
asked
you
indian
already,
but
like
we
have
product
people
here,
I'm
wondering
do.
Do
people
think
that
we
actually
need
a
message
and
to
allow
client
to
actually
reduce
the
term
max
if
they
want
to
right
now,
it's
not
intent
because,
like
we
do
believe
that
clients
wants
to
keep
their
data
as
long
as
possible,
as
some
people
suggested
in
the
discussion.
C
So
the
basic
protocol
is
making
decisions
for
them,
saying
you
definitely
register
we're
gonna,
add
six
or
one
year
to
that.
You
deep
suggested,
maybe
six
months
history
as
well.
Do
we
need
a
message
to
actually
allow
clients
to
reduce
that?
I.
G
G
I
also
think
that
in
general,
like
the
the
main
pushback
that
I
have
on
like
just
like
massive
extension,
is
that
there
are
explicit
clients
that
have
shown
up
that
want,
like
a
specific
term
for
where
they
care
their
data
is
stored,
but
that
term
tends
to
be
on
the
order
magnitude
of
one
year,
like
typically
the
clients
that
we've
seen
that
come
through
that
have
like
a
requirement
on
how
long
they
care
about
their
data
being
stored.
G
That's
like
a
12
month
horizon
and
so
like
tacking
on
you
know,
three
months
or
six
months
beyond
that,
I
feel
like
it's
relatively
justifiable,
not
super
unreasonable,
easy,
easily
defensible,
especially
given
that
it's
like
a
time-boxed
implication
on
the
network.
So
my
personal
vote
would
be
you
know
already
complicated
fib
already
got
a
bunch
of
different
changes.
I
am
more
of
the
opinion
that
I
think,
like
picking
a
reasonable
number.
G
If
that's
six
months,
that's
fine
if
it
could
be
even
shorter,
maybe
you
can
consider
three
months,
but
I
think
something
like
that
would
be
fine
for
the
time
being,
that
that's
my
opinion
and
not
like
necessarily
phil
plus
at
large
yeah.
I
don't.
We
did
talk
to
the
football
community
about
this.
It
did
not
seem
like
a
super
contentious
point
for
what
it's
worth
yeah.
B
Great
thanks
for
that,
reducing
it
to
three
months
could
well
be
reasonable.
That
should
be
enough,
certainly
enough
buffer
for
just
scheduling,
sector
commitments,
probably
enough
buffer
for
to
make
backing
reasonable.
Okay,
great,
oh
molly,
yeah
question.
E
Yeah,
just
to
jennifer's
suggestion
of
of
clients
being
able
to
like
go
in
and
change
a
max
duration
after
the
fact
over
time.
I
feel
like
there's-
maybe
some
like
concerns
there,
because
if
clients
are
able
to
change
the
duration
on
an
existing
deal
after
it's
been
packed
into
a
sector,
then
that
would
be
able
to
become
shorter
than
the
sector.
It's
in
and
potentially
cause
problems.
So
it
seems
like
that
that
pathway
might
have
issues
if
I'm
understanding
it.
B
I
think
it
correct
molly
that
that's
the
first
time
I've
heard
jen
say
something
like
that
that
you
might
have
I'm
not
sure
if
she
intended
to
say
what
she
said,
but
no
there's
no
facility
to
reduce
a
term
maximum
after
the
allocation
has
been
made.
B
B
E
Okay
and
maybe
the
side
question,
there
is
sorry
you,
you
said
that
from
the
phil
plus
side
of
the
world
like
if
all
deals
suddenly
got
increased
by
an
additional
six
months
of
duration
that,
like
filled
plus
the
fieldplace
community,
is
like
yeah
nope.
That
seems
fine
versus,
like
clients
explicitly
wanting
the
facility
to
state
like
yes,
I
want
my
deal
to
be
able
to
go
up
to
the
max.
Please
make
that
happen
like
the
opt-in
versus
locked
out.
E
G
G
The
main
takeaway
was
that
the
opt-in
opt-out
discussion
was
significantly
more
controversial
and
needed
when
it
came
to
the
migration
aspect
of
these
suckers
and
like
what
we'd
expect
to
see
from
the
ability
to
extend
to
like
sector
duration
lifetime
max
or
whatever
versus
like
some
like
blanket
amount
and
who
could
take
part
in
the
decision
of
moving
a
sector
over
and
so
in
general,
like
this
part
of
it,
which
is
just
like,
oh,
like
in
the
case
that
we
are
deciding.
G
G
Oh,
how
valuable
would
like
data
cap
be
for
us
a
year
from
now,
will
we
still
be
able
to
support
like
very,
very
cheap
deals,
yes
or
no
and
like
what
does
roi
look
like
for
an
sp
and
how
much
effort
does
an
sp
need
to
put
in
to
maintain
like
a
relatively
reasonable,
predictable
outcome
for
the
work
that
they've
done
right
now
in
terms
of
what
it
would
view
them
in
the
future?
And
so
based
on
that,
like
at
least
my
takeaway
from
that
conversation
was
like.
G
Let's
talk
about
the
process
that
we
want
to
have
for
the
migration
side,
because
I
think
that's
where
people
were
very
vocal
about
what
should
and
should
not
be
allowed
to
proceed,
especially
given
that
we
have
an
opportunity
to
cut
down
on
some
of
the
initial
abuse
and
potential
misuse
of
data
cap.
That's
happened
in
the
past
and
how
that
could
be
continually
leveraged
further
for
like
unfortunate
upside,
let's
say
and
less
on
this.
If
this
was
like
a
six
month
or
less
thing,.
C
B
B
B
Is
well
known,
which
can
be
a
client
who
definitely
wants
their
incentivization
to
stop
at
some
point,
should
just
specify
their
term,
as
you
know
three
or
six
months
prior
to
that
point,
and
then
exactly
that
can
be
usually
for.
B
Cool
okay,
so
the
other
topic
is
what
to
do
about
all
of
the
existing
sectors
and
deals.
The
simple
answer
here
is
nothing
and
we
leave
all
these
existing
sectors
and
deals
in
in
their
current
state
with
their
you
know,
spread
out
qa
power
and
their
existing
ways
of
doing
things.
B
However,
yeah
this
raised
the
question
that
perhaps
some
clients
who
really
wanted
long
terms
in
the
first
place
have
never
not
been
had
not
been
given
an
opportunity
to
specify
those
long
terms,
and
it
would
be
nice
to
give
those
clients
an
opportunity
to
specify
that
actually
they
wanted
five
years
in
the
first
place.
B
But
the
you
know
the
market
at
the
time
couldn't
support
that,
and
that
would,
of
course,
add
incentive
to
for
the
providers
of
those
sectors
to
keep
those
sectors
committed,
which
is
good
for
the
stability
of
the
network.
However,
so
that
suggests
some
kind
of
migration,
where
some
some
way
of
of
migrating
existing
sectors
into
the
new
world.
But
I
want
to
that.
Migration
has
a
lot
of
limitations
and
it's
not
obviously
a
good
thing.
B
It
has
to
be
opt-in
on
the
on
the
provider's
part,
because,
because
the
old
qa
power
mechanism
spreads
the
rewards
out
over
the
sector's
lifetime,
it's
possible
for
there
to
be
a
deal.
That's
already
expired,
which
for
the
rewards
have
not
already
been
earned
and
migrating
such
a
sector
would
cause
the
power
to
be
dropped.
It
would
cause
a
loss
in
power
for
that
provider,
and
so
we
can't
unilaterally
do
this.
B
It
has
to
be
opt-in
from
the
provider's
side,
at
least,
but
so
limitations,
because
we
have
this
constraint
that
so
a
migration
would
mean
creating
an
allocation
retrospectively
for
a
deal.
That's
already
been
sealed
in
order
to
maintain
the
invariant
that
the
allocations
that
the
you
know
that
a
sec
a
sector
cannot
contain
an
allocation
with
a
shorter
term
maximum
than
that
sector's
schedule,
expiration.
B
The
the
allocations
that
we
would
create
would
have
to
specify
that
the
maximum
you
know
the
minimum
term
for
the
allocation
would
be
whatever
the
deal
term
was,
and
the
maximum
term
would
be
whenever
the
sector
is
going
to
expire,
which
which
can
be
longer
than
the
original
deal
term,
and
so
the
effect
of
that
would
be
that,
instead
of
having
the
qa
power
spread
out,
you
know
spread
out
over.
B
However
long
the
sector's
life
is,
the
client
would
just
get
full
with
the
provider
would
just
get
full
10x
power
until
their
sector
expires,
because
providers
can
extend
their
sectors
unilaterally
by
one
and
a
half
years
already
today,
basically
assume
that
any
provider
who's
gonna
migrate,
such
a
sector
would
extend
it
to
live
for
one
and
a
half
years
first
and
then
migrate
it
and
then
get
one
and
a
half
years
of
full
10x
power,
regardless
of
whatever
term
the
deal
is
specified.
B
It's
also
likely,
and
so
so
this
is
not
necessarily
you
know.
It
depends
on
your
opinion
about
the
clients,
perhaps
as
to
whether
this
is
good
or
bad
clients
who
wanted
their
deal
to
be
short,
is
bad
and
for
clients
who
may
have
abused
the
fuel
plus
no
resistance
to
gain
data
cap.
It's
bad
for
the
network
that
we
extend
the
impact
of
that
for
a
bonus
one
and
a
half
years.
You
double
the
impact
of
it
more
than
double
the
impact
of
it.
Really.
B
It's
also
that
the
pros
also
specified
you
know
also
specifies
that
clients
can
increase
the
max
the
term
maximum
for
their
allocation
at
some
point
after
it's
been
created
up
to
the
five
years
that
they
could
have
specified
at
the
start,
if
this
system
had
already
been
implemented-
and
so
in
the
case
of
you
know
fraudulent
clients,
we
can
basically
assume
that
all
of
the
fraudulent
actors
will
increase
their
four
plus
allocations
to
five
years
after
migrating.
B
The
sectors,
and
so
the
impact
of
a
migration
is
that
all
of
the
bad
qa
power
lives
for
five
more
years
from
now.
Presumably,
some
of
the
good
qa
power
was
because
the
clients
actually
wanted
short
terms,
so
those
ones
are
not
so
either
both
we
both
we
violated
the
client's
term,
but
also
the
providers
of
those
have
less
advantage
than
the
malicious
or
the
intention
providers,
and
there
was
something
else
that
I've
lost.
My
train
of
thought
anyway,.
B
All
a
clear
win
for
this
for
this
migration.
On
the
other
side,
fip
36
has
a
big
problem
with
inequality
of
access
to
multipliers.
If
we
don't
allow
migration,
all
of
the
all
of
the
well-intentioned
providers
who
took
full
plus
deals,
perhaps
from
our
data
programs
or
so
on,
will
not
be
able
to
extend
this
extend
those
sectors
to
take
advantage
of
the
multipliers
unless
we
let
them
migrate
their
qa
power
into
this
world.
B
But
we
have
no
way
to
you,
know
distinguish
between
between
parties
here
and
I
don't
know
let
the
good
people
do
it,
but
not
the
bad,
bad
people,
if
I'm
to
massively
oversimplify
it
so
so
the
migration
has
been
compromised.
If
we
don't
implement
it,
it
seems
bad
for
536.
I
wish
they
would.
I
wish
there
was
another
way
to
resolve
the
inequality
of
access
that
536
has
so
that
we
wouldn't
have
wouldn't
face
this
decision,
but
the
migration.
B
If
we
do
allow
migration,
then
your
existing
deal
terms
will
go
for
at
least
a
year
and
a
half
more
despite
the
client's
term
and
fraudulent
data
cap
will
likely
be
extended
for
five
years.
So
also
the
migration
is
complicated,
so
there's
a
decision.
I
don't
have
like
a
clear
that
there's
not
a
clear
answer
for
this.
This
is
a
tough
compromise,
either
way.
C
Alex
I
have
a
question
like
you
mentioned,
that,
like
the
migration,
the
rp
migration,
it
must
be
triggered
from
the
search
provider
side.
I'm
wondering
why
that
is
the
case.
Why
can
not
because,
like
we're
only
talking
about
the
existing
deals
right,
like
existing
verified
deals,
why
cannot
be
a
thing
that
client
triggers
some
behavior?
C
B
Let
me
try
and
restate
so
it
must
be
that
the
client
that
the
provider
needs
to
opt
in
and
you're
suggesting
also
the
deal
clients,
opt-in
prior
to
a
migration.
We
could
implement
such
a
thing.
That
is
your
net
new
work
that
I
haven't
considered
yet
is
that
a
new
registry
for
existing
deal
clients
to
authorize
a
migration,
and
then
we
could
check
that
all
of
the
deals
have
migration
authorization
before
yeah
or
migrating
them.
C
And
whereas
can
that
be
done
by
so
like
client
just
make
a
new
allocation?
Oh
no
because
like
they
have
to
make
a
new
deal.
Okay!
No,
that
doesn't
work.
I
was
thinking
like.
I
can
make
a
vocation
to
the
city.
They
have
and
then,
like
one
story,
storefinder
extended
sector,
we
will
check
if
the
allocation
exists
and
we
will
claim
that
as
the
new
power.
But
again
that's
additional
engineering
work.
B
Yeah,
I
mean
look
basically
if
we
don't
do
a
migration,
we're
in
the
like
that
the
new
world
is
like
clients,
can
get
new
data
cap
and
make
new
allocations,
and
they
can
make
long
what
they
can
make
long
allocations
later
on
and-
and
you
know,
we
let
the
old
sectors
be,
but
your
data
that
is
valuable
can
be,
you
know,
can
feel
plus
again
and
be
committed
into
new
sectors.
It's
not
quite.
B
As
avoiding
the
reseal,
but
essentially
the
new
world
is
that
you
know
we
improve
field
plus
governance
in
the
future.
We'll
do
better
at
allocating
phil
plus
to
good
parties
and
they'll,
get
longer
terms
and
better,
better
rewards
for
it,
and
we
just
move
into
that
world
as
fast
as
we
can
yeah.
G
Yeah,
I
think
the
we.
This
is
a
very
lengthy
conversation
with
the
flip
plus
community.
I
think
the
the
main
the
main
actual
takeaway
was
that
people
found
it
really
hard
to
decouple
this
from
36.,
like
no
matter
how
you
paint
it
it
just
was
like
you
know
there,
it
was
like
clear
preference
of
hey,
let's
not
migrate,
any
sectors,
and
then
it's
like
well,
if
36
is
gonna,
let
cc
sectors
get
migrated.
G
Then
we
need
to
have
a
path
where
we
can
get
verified
deals
migrated
over
as
well,
because
otherwise
we're
gonna
get
screwed
or
like
governance
process,
won't
move
fast
enough
or
whatever
and
they'll
have
resulting
loss
in
ability
to
catch
up
to
how
quickly
that
network
will
grow
and
will
get
dinged
for
that
relative
loss
of
qap
for
the
amount
of
time
it'll
take
for
them
to
catch
up,
and
so
it
was.
G
It
was
a
tough
sort
of
thing
to
decouple
those
things
and
ultimately,
it
really
felt
like
the
feedback
that
gail
and
I
got
was
effectively
support.
No
migration
and
in
the
case
of
36,
passes,
please
support
migration
or,
like
we
really
want
some
kind
of
mechanism
for
migration,
and
so
I'm
kind
of
curious
on
how
we
can
better
educate
folks
to
like
decouple
those
things.
If
that
is
the
that
is
the
explicit
intent
or
maybe
can
we
explicitly
couple
those
things
and
what
would
that
look
like.
C
G
They
did
yeah,
and
so
I
think
the
the
decision
was
or
the
consensus
is
basically
if
it
turns
out
36
shifts,
we
need
somebody
to
migrate
sectors.
In
that
case,
can
we
have
a
mechanism
that
includes
sp,
buy-off,
client
buy-off,
so
sp
implies
that
they're
aware
that,
like
additional
collateral
is
needed,
client
buy-off
implies
that
hey,
like
you're,
still
interested,
and
you
know
this
deal
being
stored
for
like
a
significantly
longer
future
period
of
time,
and
we
also
entertain
the
idea
of
having
like
a
notary
buyoff
or
we're
like
what.
G
What
is
the
proposed
mechanism
by
which
we
can
actually
have
like
a
vote
across
the
community.
You
know
per
deal
is
difficult,
there's
about
just
shy
of
six
million
deals
in
the
field
plus
world,
but
maybe
there's
like
some
broader
stroke
mechanism
that
we
can
propose
for
like
some
sets
of
deals
can
get
extended.
Some
cannot
and
we
have
like
notaries,
vote
on
that
or
veto
that
and
that's
kind
of
where
the
direction
was
headed
today.
I
know
there's
a
couple
hands
up
dude.
I
don't
want
to
take
all
their
time.
D
It's
not
a
question,
but
yes,
I
guess
I'll
summarize
to
say
that
I'm
fairly
strongly
opposed
to
this
idea
to
date
of
an
opt-in
migration
and
I
think,
there's
kind
of
three
reasons
or
three
themes.
Why
number
one?
D
I
don't
think
we
have
a
clean
design
for
how
to
do
this
so,
and
I
think
you
you
hit
on
this
point
already
alex
like
it
just
feels
like
whatever
we
do,
wouldn't
actually
be
correct
in
some
sense
in
that
yeah,
if
you
can
extend
right
before
the
migration
that
just
feels
like
yeah
there's
a
pretty
big
way
to
game
the
system.
So
that's
reason
number
one
reason
number
two,
I
think
is
I
don't
know
that
it's
especially
well
motivated.
D
I
don't
know
that
we
I
I
feel
like
the
arbitrary
statement
of
there
could
have
been
clients
that
would
have
wanted
to
make
longer
deals.
I
don't
particularly
find
convincing
and
related
to
that
reason.
Number
three
is
that
philosophically
I
I
I
don't
know
how
much
I
agree
with
the
idea
of
trying
to
you
know
as
we're
changing
the
file
coin
protocol
in
some
substantial
way
to
try
and
accommodate
things
that
happened
in
the
past,
like
I
think
we
need
to
be
okay
with
saying
that
this
is
a
two-year-old
chain.
D
Now,
deals
have
been
make
been
being
made
on
falcon
for
about
two
years.
The
protocol
will
continue
to
change
and
you
know
we
can
try
to.
We
should
all
we
should
try
to
balance
incentives
across
when
these
big
changes
happen,
but
I
it
feels
a
little
bit
like
yeah
looking
back
in
the
past
and
trying
to
engineer
the
new
model
to
fit
that,
and
I
don't
know
that
that
almost
just
smells
bad
to
me
so
tldr.
I
don't
like
this.
Unfortunately,.
B
Good
night
before
gallon
goes
going
to
respond
to
a
message
from
zx
in
the
chat
he's
responding
to
the
unit
the
house.
He
says
I'm
not
sure
how
strong
the
fairness
argument
is
in
coupling
this
to
36..
It's.
B
Let
me
say
that
if,
if
536
was
not
a
thing,
then
I
would
prefer
we
did
not
do
a
migration.
I
think
the
complexity
is
not
worth
it.
Given
that
it's
very
unclear
when,
without
without
fib
36,
I
would
suggest
that
we
do
not
do
migration,
so
we
could
you
know
one.
One
point
of
view
could
be
that
we
declare
that
there
will
be
no
migration
and
then
36
has
to
deal
with
whatever.
B
Are
you
either
assert
that
the
fairness
is
not
a
big
deal
which
is
sort
of
what
zx
is
getting
at
in
his
chat
message?
We
decided
that
he's
good
anyway,
even
with
this
unfair
access
or
mitigate
it
in
some
other
way,
and
so
you
know
to
the
extent
that
zx
is
saying,
fairness
is
not
that
big
of
a
deal.
I
would
take
that
as
permission
to
not
do
a
migration.
B
The
the
only
the
only
the
strongest
motivate
motivation
for
a
migration
here
is
me
trying
to
unblock
fit36
so
that
it's
possible
for
it
to
be
accepted.
Despite
this
galen.
H
Thank
you,
yeah,
echoing
some
of
what
deepa
said.
I
think
that
the
sentiment
that
we
get
is
that
the
migration
plan
is
for
for
existing
verified
deals,
the
notaries
and
sps
and
people
that
we've
talked
to
are
confident
that
that
means
they
will
have
to
pay
more
collateral.
H
Based
on
that
extension,
the
amount
of
that
collateral
is
another
sort
of
sticking
point
for
them
in
how
much
lender
support
is
already
available
to
them
and
how
much
liquidity
they
will
need
to
get
the
lender
support
to
hit
this
new
convincer
amount
of
collateral
that
will
be
required
and
that,
if
the
sort
of
like
again
it
is
hard
to
separate
these.
H
And
is
there
a
way
to
say
you
know
no
migration
in
either
case,
and
it
is
only
the
net
new
deals
that
can
be
impacted
by
36
and
impacted
by
this
new
deal
length?
And
so
I
think
that
where
we
are
having
a
hard
time
is
you
know
if,
if
36
is
going
to
allow
like
longer
sector
multipliers
and
cc's
to
to
roll
into
that?
H
H
Do
we
need
to
allocate
new
data
cap
and
all
of
that
creates
sort
of
new
tech
debt
of
how
do
we
capture
all
those
messages
that
the
team
is
going
to
have
to
come
up
with
to
say,
let's
create
a
an
array
mechanism
where
a
client
can
send
you
know
a
very
more
complicated,
cid
array
somewhere.
That
says
these
are
the
deals.
H
If
we
roll
into
this
migration
plan,
are
we
going
to
be
trying
to
get
a
lot
of
sps
that
are
already
feeling
uncertain
in
the
future,
and
is
this
going
to
make
them
say
like
the
only
way
that
I
can
keep
playing
is
by
doing
yet
another
even
more
complicated
thing
to
migrate
all
these
existing
deals
that
were
already
difficult
to
get.
I
would
rather
just
take
new
deals,
but
I
can't
because
I'm
gonna
get
out
competed
in
this
other
arena.
E
There
are
a
lot
of
things
in
there.
I
was
going
to
actually
respond
more
to
a
usher's
point
of
what
evidence
do
we
have
that
sps
desire
a
longer
deal
range
than
1.5
years?
And
I
would
say
I
don't.
I
don't
see
your
skepticism
or
what
evidence
you
have
for
that,
because
I
definitely
know
of
many
clients
who
have
requested
like
10-year
or
permanent
or
infinite
deal
lengths,
and
so
I
think
there
is
actually
a
lot
of
demand
for
for
longer
storage
deals
and
you
can
actually
look
at
the
you
know.
E
What
is
the
the
average
length
of
a
deal
a
falcon
plus
deal
and
is
like
a
couple
of
days
short
of
the
maximum?
Is
the
average,
and
so
almost
everyone
is
setting
the
maximum
possible
storage
length
for
their
deals,
and
so
I
think,
there's
actually
a
lot
of
evidence
that
the
people
who
are
existing
or
doing
storage
deals
today
would
desire
that
data
to
be
stored
by
the
network
long
term,
and
they
do
not
want
to
reseal
it
or
go
through
the
overhead
of
like
refreshing
all
of
those
deals
if
they
can
avoid
it.
E
If
they
can
instead
focus
their
ceiling,
energy
and
capacity
on
new
deals
in
the
future
and
on
onboarding
new
clients,
and
that
they
can
minimize
the
amount
of
hardware
that
they
and
the
amount
of
energy
that
they
spend
on
making
sure
that
all
of
the
useful
data
they're
storing
today
continues
to
be
stored,
and
so
that's,
I
think
the
reason
I
I
guess
overall,
whether
or
not
this
migration
strategy
is
right,
and
I
think
I
think
that
I
think
this
one
is
not
optimal
of
like
sp,
triggered
with
like
an
unclear
how
clients,
client
asks
are
included,
but
I
think
we
are
going
to
want
ways
as
we
as
the
network
adjusts
its
duration
length.
E
Maybe
it
becomes
3.5
in
the
near
future.
Maybe
it
goes
to
5
after
that,
maybe
it
goes
to
10
someday
in
the
future.
I
don't
know
what
the
duration
that
we'll
be
comfortable
as
a
network
with
will
be
over
the
next
couple
of
years.
I
think
we
will
want
to
be
able
to
adjust
bill
plus
deals
that
were
created
in
the
past
to
meet
the
new
things
that
we
think
are
reasonable
as
a
network
right.
B
For
everything
that's
committed
after
this
45
so
so
retroactively
increasing
the
the
term
is
easy.
After
this
flip
45.
This
is
part
of
the
fit,
but
it
is
a.
B
Question
for
these.
E
D
Yeah
molly,
I
think
I
agree
with
everything
you
said
I
just.
I
think
I
strongly
disagree
with
the
line
of
reasoning
like
I
think,
if
we
have
interest
in
clients
having
longer
deals,
then
that
is
a
and
to
me
there
is
an
orthogonal
discussion
to
the
product
impacts
of
fib
45,
and
you
know,
there's
multiple
conversations
in
flight
about
how
to
support
those
kinds
of
longer
deals.
D
What
I
think
what
I'm
objecting
to
is
545
is
this
very
non-trivial
change
to
the
deal
making
process
on
file
coin
and
some
of
the
factors
in
place,
and
it
slightly
feels
like
we're
into
that
discussion.
We're
forcing
in
this
question
of
being
opening
up
the
possibility
of
changing
the
behavior
of
deals
that
were
made
in
the
past.
It
just
feels
like
two
different
conversations
to
me
and
I
don't
want
them
to
be
combined.
A
So,
as
pointed
out
in
the
chat
as
well,
we
are
really
running
out
of
time.
So
I
think
we
should
table
this
discussion
for
now
or
take
it
async,
and
it
does
sound
like
there's
a
lot
of
conversations
that
need
to
happen
around
this
tip
in
particular,
and
its
relationship
to
536
in
the
coming
days.
A
That's
really
been
the
case
for
much
of
this
governance
process
and
in
preparation
for
this
upgrade,
but
we
do
want
to
make
sure
we
have
time
to
discuss
that,
so
these
tables
show
updates,
based
on
what
we've
had
previously
and
many
of
these
things,
except
for
the
proposed
timeline,
are
ones
that
should
be
very,
very
familiar
to
core
devs
who've
been
involved
in
this
process.
A
A
That
is
a
tall
order
for
some
of
these,
and
the
interrelationship
between
certain
fips
complicates
that
further.
But
as
a
reminder,
many
of
these
drafts
have
existed
as
either
drafts
or
discussion
posts
for
many
months.
All
of
these
things
have
been
discussed
and
flagged
in
weekly
governance
updates,
as
well
as
decor
devs
previously,
and
so
the
threshold.
For
all
of
these.
A
To
begin
that
last
call
process
is
having
a
final
and
complete
draft,
which
cordevs
have
confirmed,
all
of
which
they
have
and
which
are
ready
for
that
final
sort
of
consensus
gathering
process
again
we're
tight
on
time.
These
updates
carry
over
async
much
more
easily
than
the
other
ones.
So
I
didn't
want
to
take
too
much
time
away
from
that
conversation,
but
are
there
any
concerns
or
anything
that
anyone
would
like
to
flag
immediately
that
they
think
is
an
issue
or
that
they
have
questions
about.
D
Yeah,
I
don't
think
the
list
of
things
that
are
that
we
have
on
the
left
side
of
the
table
is
achievable
in
the
timeline
that
we
have
on
the
right
side
of
the
table.
I
have
I've
partnered
with
jennifer
and
trying
to
create
some
of
those
timelines,
and
that
was
working
on
the
assumption
that
the
fibs
that
would
be
included
were
29,
34,
41,
44
and
45,
with
45
far
and
away
being
the
longest
poll
of
this
effort.
D
I
think
if
we
do
want
to
include
47
in
particular,
that
is
a
non-trivial
amount
of
work
that
that
I
don't
that
I
don't
think
is
happening
in
our
already
tight
timeline.
536.
My
understanding
is
the
implementation
is
relatively
easy.
It's
the
you
know,
consensus
side
of
things
to
complicate
things,
although,
as
discussed
36
does
have
interactions
with
45
that
threaten
the
long
rule,
but
right
now,
unfortunately,
I
don't.
I
don't
think
what
we
what's
on
this
slide.
A
Is
achievable,
that
is
the
exact
kind
of
flag
I
was
looking
for.
So
that's
really
important
to
know.
So
this
list
is
what
many
of
these
things
had
always
been
proposed
as
potential
scope,
but
again
right.
The
challenge
here
has
always
been
that
there's
been
this
sort
of
chicken
of
the
egg
tension
between
what
needs
to
be
included
and
what
can
be
excluded
alex
is
your
understanding
that
fit
47
must
be
implemented
if
fip
36
is.
A
C
I
want
to
confirm,
like
heavy
plus
one,
what
you
said
like
the
time
I
have
proposed
to.
You
is
based
on
my
understanding
on
the
scope,
unlike
today,
which
is
not
including
5th
36th
and
5487,
and
also
means
like
no
migration,
no
vibration,
outfit
45
alex
is
already
giving
me
the
engineering
estimation
that
adds
on
one
that
full
week
of
engineering
work
if
we
do
want
to
do
any
source
of
migration,
and
so
that
will
make
us
very
tight
on
the
on
this
proposed
timeline.
F
Okay,
and
also
for
45,
I'm
understanding
is
we
only
need
to
align
on
the
the
go
over
policy
right,
because
implementation
might
be
able
to
come
later.
C
F
47
is
the
private
policy
right,
the
policy
wise.
I
think
what
we
need
to
do
is
the
line
on
the
policy
the
implementation
can
come
after.
B
It's
that's
not
correct
cx,
so
eight
implementations
already
done
but
b,
it's
not
possible
to
implement
fib
47
after
someone's
already
made
a
commitment
to
a
sector
that's
longer
than
a
year
and
a
half
it's
necessary
to
implement
this
before
allowing
the
longer
commitments.
We
basically
can't
do
it.
In
retrospect.
F
F
That
was
in
in
reference
to
the
link
you
sent,
which
is
for
the
beneficiary
yeah
input
doesn't
mean
we
have
to
include
it
right,
like
I
don't
think
it's.
I.
C
F
C
E
Yeah
my
hand
was
actually
around.
I
know,
there's
a
set
of
proposed
changes
that
are
coming
to
fit
36,
which
have
probably
some
implications
on
what
is
and
isn't
required,
based
on
it
so
like,
for
example,
if
it's
going
from
five
year,
duration
to
a
three
and
a
half
year,
duration
max
that
has
implications
on
the
risk
profile
of
three
and
a
half
year,
sectors
versus
one
and
a
half
year,
sectors
versus
five
year
sectors,
right
and
so
potentially
that
changes,
whether
or
not
folks,
would
consider
fit
47
required
ahead
of
time.
F
C
A
I
agree,
and
I
think
that,
if
need
be,
there
seems
to
be
a
lot
of
uncertainty
still
about
what
needs
to
drive
planning
here.
We
may
want
to
especially
think
about
governance
timelines.
We
may
want
to
try
and
schedule
something
else
for
tomorrow
or
very
early
next
week
to
continue
to
discuss
this
further,
because
I
think
a
lot
of
this
has
been
async
and
it's
leading
to
still
a
lot
of
open
questions
as
work
continues
to
move
at
different
paces.
C
Casey,
what's
the
engineering
pathway
on
fib?
Oh
sorry,
the
governance
plate
I'll
clip
367.
A
Phew,
that's
the
only
one
I
can
answer
so
I
have
one
in
here
which
I'm
now
hesitant
to
share,
because
if
this
timeline
isn't
going
to
be
acceptable,
the
only
thing
that
that
certifies
more
so
is
going
to
be
dates.
So,
as
has
been
communicated
in
the
internal
coordination
channel
that
we
have
for
fifth,
thirty
six
which
exists
just
to
align.
You
know,
stakeholders
who
are
communicating
around
the
sip.
We
had
looked
into
doing
sort
of
following
precedent
for
phil
poll,
which
is
what
we
do
for
what
are
considered
emergency
fips.
A
This
fit
was
reconsidered.
It
is
not
an
emergency.
In
the
same
way,
some
network
security
issues
may
be,
and,
after
speaking,
in
consultation
with
different
flip
authors,
the
preference
is
to
sort
of
adopt
a
very
typical
last
call
process
and
be
very,
very
explicit
about
requirements
for
asking
community
members
to
either
address
their
acceptance
or
rejection
of
this
fip.
So
the
intention
was
for
last
call
to
begin
next
friday,
depending
on
how
the
fip
authorship
team
deems
their
panel
to
go
next
week.
A
This
is
still
being
worked
out,
obviously,
because
it
depends
on
timeline
for
the
entire
network
upgrade
and
obviously,
from
a
governance
perspective.
More
time
is
better,
but
insofar
as
we've
also
have
this
weird
coupling
between
the
timing
of
the
upgrade
and
the
timing
of
acceptance,
the
focus
is
really
on
beginning
that
last
call
and
being
very
explicit
about
asking
community
members
to
either
support
or
reject
the
fit.
A
E
Yeah,
thank
you.
Yeah
my
hand
was
just
what
you
said.
Caitlyn
on
felt
poles
are
used
for
emergency
fifths
and
I
don't
think
that's
the
case.
Often
an
emergency
fifth
like
the
the
timeline
to
get
a
poll
to
happen
versus
an
emergency
security
focused
fifth,
where,
like
maybe
we're
not
even
disclosing
the
bug
that
a
security
fix
is
you
know,
attacking,
etc.
E
Like
that
to
me,
a
the
field
poll
is
useful
in
times
where
there
is
contention
at
an
ecosystem
level
about
whether
or
not
to
accept
something,
and
it
helps
us
clarify
from
a
governance
perspective.
What
is
the
will
of
the
network,
and
I
think
it
is
actually
very
useful
in
this
context,
sure
if
we
want
to
do
an
equivalent
to
a
full
poll,
because
filter
itself
is
not
technically
working
for
the
things
that
we
want.
E
We
could
do
that
instead,
but
I
think
especially
given
like
the
the
movement
here
of
like
what
is
the
proposal.
E
Like
do
people
agree
with
the
most
recent
draft,
depending
on
what
the
most
recent
draft
is
etc,
and
the
timeline
here
on
making
a
decision
on
whether
or
not
to
include
an
mvp
of
this
proposal
in
a
final
in
a
last
call,
I
do
think
some
sort
of
whole
mechanism
that
takes
a
snapshot
at
a
given
point
in
time
of
community
will
is
really
important,
not
because
it's
an
emergency
or
not
an
emergency,
but
because
it's
really
difficult
to
get
clarity
in
a
moment
about
over
this.
E
Like
you
know
this,
this
has
been
a
discussion
and
debate
for
like
two
years
at
this
point
and
so
or
not
two
years
sorry,
two
months,
and
so
I
want
to
make
sure
that
that
we
have
an
accurate
vantage
point,
and
so
I
would
encourage
us
to
do
a
fill
pull
if
it's
technically
feasible,
if
it's
not
technically
feasible,
then
to
do
some
sort
of
slack
pull
or
something
whereby
we
get
like
deeper
vantage
point
into
what.
What
actually
is
the
will
of
the
community
about
this
and
use
that?
A
You're
right,
this
is
something
that
we've
gone
back
and
forth
to
with
not
you
and
I,
but
the
myself
and
others
who've
been
working
and
really
involved
in
following
this
fit
process.
What
we
need
to
do
right
is
move
from
having
this
like
soft
deliberation,
space
to
having
an
actual
decision
space,
the
framing
around
you
know
an
emergency
fit
whatever
it's
kind
of
unbounded,
you're
right,
but
it
was
really
in
this
context
of
do.
A
We
have
a
reason
to
change
the
process
for
this
fifth
in
particular,
and
what
we've
learned
through
this
process
is
it's
because
cryptoeconomic
fips
have
components
to
them
which
make
them
fundamentally
different
from
most
other
types
of
fips,
and
this
is
something
we
need
to
very
imminently
plan
for
going
forward
for
this.
You
make
a
good
point
that
if
we
can't
do
this,
you
know
emergency
fits
move
quickly.
How
can
we
do
fill
poll?
A
What
we
found
is,
we
do
not
even
have
enough
time
to
do
phil
paul
in
this
context,
and
there
are
many
many
reasons
why
there
were
also
many
concerns
about
how
phil
poll
is
natively
built
to
tally
votes,
which
I
agree
with,
and
so
what
we're
going
to
do
now
is
a
a
very
kind
of
explicit
ask
with
a
ton
of
communication
around.
Do
you
accept
or
reject
this
fip,
and
that
is
how
we're
going
to
carry
it?
A
I
can
write
up
and
add
more
detail
to
the
planning
document-
that's
already
tracking
this,
but
it
is
made
explicit
and
it's
supposed
to
be
a
more
black
and
white
way
of
saying
yes
or
no.
Here's
how
we're
going
to
move
forward
and
we've
already
begin
to
discuss
if
the
fit
were
to
fail.
Obviously,
authors
believe
there's
a
very,
very
good
and
time-bound
reason
for
this
fip
to
progress.
A
If
it
doesn't,
we
are
bound
by
that
decision
and
there
is
opportunity
for
them
to
reconsider
work
with
stakeholders
in
different
way
and
potentially
submit
a
new
draft
for
inclusion
in
an
nv18.
But
that's
a
bit
out
of
scope
for
what
we're
doing
right
now.
C
Like
I
haven't
should
be
accepted,
based
on
the
updated
draft
of
course
like
well,
should
this
fit
be
accepted,
and
obviously,
if
this
fit
the
pool
suggests
this
flip
should
be
accepted.
It
must
to
be
included
in
md17
or
like
fit
29,
which
is
accepted
way.
Earlier,
however,
was
not
included
in
the
like
the
16
because
of
like
a
timeline
of
the
upgrade.
C
Should
we
consider
this
as
well,
it's
like
this
can
be,
including
only
18,
or
it
should
only
be
because
it
or
like
the
if
pulley
is
accepted,
we
will
only
consider
including
a
v17
again.
This
is
a
huge
difference.
Right,
like
it's,
impacting
all
the
engineering
work
for
fit
40.
E
45.
caitlin,
sorry
jennifer.
I
think
I
think
it's
it
would
be
accepted
by
the
community.
That
does
not
dictate
core
dev
engineering
timelines.
It's
it's!
It's
the
will
of
the
network
to
accept
this
fit
and
then
it's
up
to
us
as
core
devs
to
try
and
act
in
faith
with
that
to
like
make
make
that
possible.
It
does
not
dictate
that
you
it's
impossible
to
ship
xyz
upgrade
without
that
fit.
E
That's
not
true
for
any
other
accepted
tip
as
well,
but
it
demonstrates
that
the
community
will
is
to
include
that
in
this
time
frame
I
do
want
to
double
click
on
zx's
question
in
the
chat
around
like
what
is
is
do
does
any
random
github
account
get
a
vote
on
this
or
like
who
who
does
like
you
know
the
reason
that
fieldpool
exists
is
because
it
allows
us
to
structure
the
people
who
kind
of
have
already
invested
and
contributed
and
participated
in
the
falcon
ecosystem.
E
A
I
don't
know
we're
still
figuring
it
out.
It's
a
good
question.
Adding
requirements
for
you
know
proving
your
engagement
linking
to
your
past
posts,
whatever
the
phil
poll
would
not
give
us
a
clear
yes,
no,
and
with
there
being
so
much
sensitivity
around
the
scale
of
miners
and
their
total
qap
on
the
network
there
we
would
have
a
very
difficult
time,
disaggregating
large
miners
from
small
miners
and
actually
demonstrating
that
this
was
like
a
very
legitimate
vote.
There
was
a
lot
of
concern.
A
The
second
like
phil
paul,
was
raised
as
we
began.
Exploring
this,
it
was
not
clear
that
this
was
something
we
could
even
achieve
in
the
three
or
four
weeks.
We
would
have
let
alone
the
time
we
have
now
and
what
it's
sounding
like
is.
A
There
are
separate
planning
processes
happening,
obviously
like
for
governance
for
engineering
timeline
and
then
within
individual
teams
themselves
that
are
working
on
the
content
of
these
fips
courthouse
is
a
good
place
to
surface
coordination
needs
here,
but
we
are
over
time
and
it's
quite
late
for
some
of
you-
and
I
don't
know
if
we're
going
to
reach
resolution,
rehashing
some
of
these
conversation
topics
now,
and
I
wonder
if
there
is
interest
in
having
I
mean,
of
course,
we
always
have
async
coordination,
but
if
there
is
value
in
having
another
strategy
session
tomorrow
or
discussion
session
around
the
network
upgrade
planning
in
particular.
C
A
Okay,
so
what
I
propose
we
do,
is
we
let
these
the
authorship
team
for
fip36
add
their
updated
draft.
It
will
be
a
friday.
Work
will
be
winding
down
before
the
weekend
anyway,
jennifer
as
usual,
you
and
I
should
coordinate
about,
needs
current
thinking
and
come
up
with
proposals
that
work
for
both
of
us
timelines
and
dates
for
both
of
us
and
push
forward
and
begin
to
share
them
async
and
decide.
If
there's
a
need
to
gather
everyone
together
again.
B
It's
very
difficult
because
there's
a
couple
elsewhere,
I
was
just
about
to
make
a.
B
Which
was
I
proposed
to
remove
the
migration
from
food
45
because
absent
for
36?
I
don't
think
we
should
do
it
and
then
push
that
to
536,
where
they
can
choose
whether
to
specify
that
we
should
implement
this
migration
for
old
sectors
such
that
they
can
have
new
new
allocations
or
not
that
decouples
it
scope-wise.
We
can
then
settle
on
the
scope
of
it45,
in
which
case
I
didn't
no
longer
need
a
decision
right.
B
There's
still
implementation
work
to
be
done
to
make
that
migration,
which
someone
has
to
do
probably
the
same
people,
but
we'll
couple
it
to
the
36
acceptance
instead
and
and
with
the
hypothetically
you're,
depending
on
chordae
scheduling.
If
56
comes
later,
the
migration
comes
later
with
fibonacci.
C
That's
a
great
proposal
sounds
good
to
me
so,
like
I
think
again,
the
proposed
timeline
likely
work
with
the
scope.
We
will
say
fifth
36
and
547
will
be
maybe
within
the
mv-17
scope
last
step
we
should
agree.
547
should
be
a
pre-request
for
36,
so
they
are
kind
of
coupled
together.
I
would
strongly
propose
that
we
don't
include
547
within
scope
unless,
like
fifth
36
is
using
scope.
Just
because,
like
the
current
timeline
is
already
tight,
we
will
revisit
the
proposed
timeline
hearing
work
again
once
the
pool
has
a
result
of
us.
B
A
We
all
right,
so
we
need
this
to
be
a
pax
meeting
thanks
so
much
everyone
for
your
engagement,
your
help
and
just
continuing
to
be
patient
and
to
stay
engaged
this
process.
I
think
this
is
the
most
complicated
or
unique
network
upgrade
I've
certainly
ever
gone
through,
but
that
may
not
be
true
for
all
of
you,
so
we'll
upload
notes
and
meeting
recording.
There
was
a
lot
here.
A
If
you
missed
something
make
sure
you
can
grab,
it
it'll
be
up
asap,
and
otherwise
you
will
be
all
in
touch
with
each
other
soon
and
also
hearing
from
from
me
very
soon,
as
well,
with
next
steps
and
additional
documentation
for
36
in
particular,.
F
Yes,
what
a
busy
call
yeah
governance
is
hard.
Isn't
it
I'll
make
it
very?
Very
quick?
I'm
sorry,
maybe
for
those
of
you
who
don't
know
me,
I'm
co-founder
and
director
of
sigma
prime
we've
been
hired
by
the
fivecoin
foundation
a
few
months
ago
to
build
a
set
of
buzzers
to
essentially
try
to
catch
bugs.
F
I
would
like
to
request,
if
possible,
a
representative
from
lotus
and
forest
to
reach
out
to
me,
there's
a
couple
of
things
that
we'd
like
to
disclose
and
I'm
not
entirely
sure
what
the
best
way
to
go
about
this
is.
We
are
also
finalizing
our
fuzzing
framework
and
it'll
be
good
if
we
can
hand
that
over
to
someone,
perhaps
from
the
file
coin
foundation,
so
yeah
just
making
it
super
quick.
Thank
you
all.
Perhaps
caitlyn
can
relay
telegram
user
handles
or
you
know
I'm
on
discord.
F
I'm
on
all
the
typical
communication
channels.
F
Well,
I'm
on
a
few
different
slacks.
If
you
can
find
me
on
I'm
on
the
five
foundation
flat
slack
and
the
five
one
slack,
please
feel
free
to
dm
me
and
we
can
take
it
from.