►
From YouTube: Filecoin Core Devs Biweekly #7
Description
Recording for: https://github.com/filecoin-project/tpm/issues/15
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
Record
on
this
computer,
thank
you
cool.
All
right
today
is
december
3rd
2020.
Welcome
to
the
seventh
wildcoin
core
devs
bi-weekly
meeting.
We
have
a
fairly
compact
agenda
today.
I
will
go
through
updates
from
the
various
teams
as
as
always
discuss
any
upcoming
state
upgrades,
which
the
next
one
is
still
just
being
fleshed
out
and
then
go
over
open,
fips,
zen,
ground
or
wyatt
from
the
actors
team
has
some
some
changes
to
the
hampton
that
you
want
to
talk
about
which
will
be
going
into
the
next
state
upgrade.
A
So
that's
something
we
should
discuss,
but
which
team
wants
to
kick
us
off
with
updates
what
we
hear
from
forest
first.
B
Yeah
sure
so
our
updates
from
I
guess
our
last
call
would
have
been
now
we're
sinking
to
the
breeze
fork,
so
full
v1
actors
compatibility
we're
going
to
skip
over
the
state
migrations,
though
so
now
we're
working
on
the
actors,
v2
upgrade
and
handling
supporting
multiple
actors
versions,
which
is
a
little
bit
of
a
tedious
process,
but
yeah
we'll
get
them
through
that
and
then
other
than
that.
Just
solidifying.
The
syncing
process
improving
the
chain,
follow
protocol
and
just
making
sure
everything's
very
solid.
B
Now
that
we
have
like
interoperability
and
then
just
getting
closer
to
minor
integration,
so
we're
just
kind
of
working
through
the
the
small
issues
with
you
know,
rpc
and
our
internal
code,
to
just
you
know,
chugging
along
towards
block
production.
So
that
should
be
coming
very
soon
within
the
next
week
or
so.
A
Sounds
good
venus?
You
want
to
go.
C
Hi
yeah,
since
last
core.
We
had
working
on
a
few
things
in
that
two
weeks
and
have
a
very
good
progress.
Firstly,
and
firstly,
is
about
the
chance
of
relation.
C
We
actually
set
up
three
instances
of
venus
just
to
test
different
period
of
different
forks,
actually
at
different
heights,
and
now
we
could
pass
all
the
focus,
which
is
very
good
and
yeah,
including
the
latest
change
and
and
of
course,
is
about
the
and
speak
actor
version
2
and
also
including
the
last
change.
We
had
done
that
and
in
the
latest
upgrade
last
week,
and
secondly,
and
we
we
successfully
set
up
a
private
network,
including
the
notice
and
awareness
together
and
do
some
testing.
C
And
yes,
we
have
done
some
testing
by
sending
messages
and
from
notre
dame
all
the
venus
and
to
have
the
tunnels
same
together
and
it
works.
Well.
It
brings
us
your
confidence
to
have
our
made
us,
though,
to
set
up
in
the
main
network
and
right
now
we're
working
on
the
json
api
support.
C
There
are
a
lot
of
changes
of
the
api
to
support
the
minor
part,
including
the
proving
the
pro
rape
and
the
post,
which
is
still
in
progress
and
another
thing
where
what
we're
currently
working
on
is
about
the
basic
poor
and
the
basic
basic
selection,
which
is
very
important,
is
because
yeah.
There
are
many
many
messages
we
need
to
carefully
handle
this
okay
and
regarding
the
next
plan
for
the
next
two
weeks
or
three
weeks,
we
are
still
focusing
on
two
things.
C
One
is
about
the
chance
acquisition
and
we
plan
to
set
up
note
in
the
calibration
network
and
also
have
one
with
the
main
network,
and
this
is
one
thing,
and
another
thing
is
that
we
want
to
integrate
the
minor
part
with
the
chat
ankle
pad
so
that,
hopefully
we
could
see
a
venus
miner
in
the
main
network,
perhaps
in
streets
or
two
weeks,
yeah
yeah.
If
we
can
do
that,
and
it
will
be
wonderful.
Thank
you.
A
Yeah,
all
that
sounds
great.
I
think
I
think
running
a
private
network
with
lotus
and
any
of
the
other
implementations.
Interoperating
is
a
really
good
idea
and
hey
if
a
venus.
If
a
venus
miner
can
join
mainnet
in
a
short
timeframe,
that
would
be
that'd,
be
amazing,
good
work,
let's
hear
from
fucon.
D
Thanks
so
as
other
guys,
we
are
also
aiming
to
have
our
note
thinking
with
the
mainnet.
D
We
were
planning
to
reach
at
least
some
hate
on
the
main
net
by
today's
medium,
but
unfortunately
we
have
faced
some
issues
with
the
pure
discovery
on
our
node,
so
we
are
currently
on
another
way,
so
we
are
using
our
own
node
as
a
stable,
a
node
for
the
as
a
node
which
provides
us
with
within
information,
but
I'm
not
sure
we
have
already
have
some
hit
there,
or
not
so
probably
by
the
next
week
we'll
we
will
either
resolve
the
issue
without
pre-discovery
or
reports.
D
We
have
made
some
fixes
well,
we
have
found
couple
of
bugs
here
and
there
on
in
our
note
version
regarding
the
actors,
integration
now
everything's
fine
is
working.
So
another
point
is
that
we
are
still
working
on
implementing
on
our
own
actors,
and
now
ejectors
v3
was
released.
D
It's
getting
a
little
bit
trickier,
so
we'll
be
probably
will
fix
to
our
own
our
own
version
of
actors,
implementation
to
be
only
v1
and
v2
compatible
as
of
now,
and
then
we
will
build
up
from
from
this
point.
A
Yeah,
oh
yeah,
that's
sounds
good,
then
I
can
see
why
v3
actors
might
seem
a
little
further
along.
So
I
think
getting
v1
and
v2
nailed
will
be
will
be
the
real
challenge.
I
will
talk
about
v3
actors
a
little
bit
some
more
yeah
regarding
lotus.
I
can
provide
a
quick
update
so
the
past
couple
weeks.
The
large
thing
that
we've
been
focusing
on
was
the
network
upgrades,
seven
and
eight
that
we
just
had
network
version
seven
and
eight
that
we
just
had.
A
This
was
mostly
just
introducing
a
new
version
of
actors,
actors
232
as
well
as
some
other
small
kind
of
edge
case
consensus
things
that
we've
documented
the
network
upgrade
went
successfully,
so
that
was
good.
This
also
introduced
a
new,
a
new
version
of
the
sdr
proofs
that
fixed
a
small,
a
small
vulnerability.
A
So
yeah
all
else
that
was
successful
apart
from
that
we've
kind
of
just
been
focusing
on
making
lotus
better
is
what
we're
calling
it.
So,
that's
writing.
More
tests,
improving
improving
the
mining
logic,
improving
the
storage
deal.
Success
rate
a
lot
of
that
stuff
kind
of
yeah
kind
of
the
core
of
lotus,
but
doesn't
doesn't
affect
consensus
and
the
other
implementation
is
too
too
much
yeah.
A
So
that's,
I
think,
that's
the
highlights
of
what
lotus
has
been
has
been
busy
with
cool.
The
next
agenda
item
I
have
is
just
for
upcoming
state
upgrades,
so
we
don't.
We
don't,
have
the
next
state
upgrade
planned
out
yet
we're,
but
we're
hoping
that
we
won't
have
another
one
in
2020.
So
the
plan
is
that
the
next
state
upgrade
will
be
early
2021.
A
So
let's
say
yes
sometime
in
january,
2021
is
a
plan,
we'll
probably
be
we'll,
probably
have
the
release
itself
ready
earlier
and
kind
of
test
it
over
the
christmas
break,
but
we
definitely
want
to
get
it
done
before
holidays
in
china
and
february.
A
So
that's
kind
of
the
timeline
that
we're
looking
at
what
will
change
in
that
is
mostly
introducing
v3
actors.
Why
I
can
talk
a
little
bit
more
about
what
will
be
happening
in
b3
actors,
but
the
idea
is
mostly
that
it'll
be
a
faster,
better
version
of
actors,
but
that
does
mean
that
lotus
side,
integration
or
integration
from
the
other
implementations
shouldn't
be
too
complicated,
and
the
the
scope
of
changes
between
v2
and
v3
actors
for
those
who
are
re-implementing
actors
will
be
much
smaller
than
the
changes
between
v1
and
v2.
A
E
Is
not
the
right
time
for
wyatt
to
jump
in
and
give
the
lowdown
yeah
yeah
sure.
F
E
A
F
Time
to
go
over
the
the
hamped
fit,
or
should
we
do
that
in
the
next
section.
A
Yeah,
I
think
that
would
the
nazi
get
time.
Maybe
yeah
give
a
give
a
description
of
kind
of
v3,
actor's
goals
more
broadly
and
then
yeah
feel
free
to
jump.
F
Yeah
that
sounds
good
thanks
yeah,
so
as
as
I
you
said,
you
really
nailed
that
v3
will
be
much
less
extensive
than
v2.
It's
closer
to.
I
guess,
somewhere
in
between
what
you've
seen
with
some
of
the
minor
version
bumps
plus
in
terms
of
like
scope
and
the
huge
v2
so
yeah,
the
the
general
idea.
Again,
as
I
you
said,
is
increasing
performance
and
the
the
big
areas
where
we're
doing
this
and
are
the
data
structures
of
the
hampton
the
I'll
get
into
this
proposed
fip.
F
In
a
little
bit,
I
can
link
an
issue
to
the
discussion
issue
in
the
fit.
Repo
is
right
here
yeah.
So
there
are
some
just
straight
up:
improvements,
breaking
changes
in
terms
of
the
ham
format
and
then
there's
also
some
work
tuning
hand,
parameters
and
then
also
kind
of
separate
from
this
there's
some
at
some
specific
markets,
improvements
that
we're
trying
to
make
because
of
goals
trying
to
keep
the
gas
cost
down.
F
There's
some
again,
like
kind
of
obvious
wins,
we
can
make
directly
in
the
architecture,
logic,
yeah,
okay,
so
looking
at
the
hamped
fip,
let
me
also
link
the
pr.
F
So
these
are
basically
changes
that
have
been
brewing
for
a
long
time
and
they're
just
finally
landing
now,
because
we
have
time
to
do
them
so
the
first
so
the
the
fifth
that
I'm
linking
has
like
two
sub
proposals,
the
first
one
you
probably
will
mostly
recognize
austin,
has
been
hammering
on
this
one
for
a
while.
It's
a
breaking
change
because
it
changes
the
way
that
gas
is
accounted
so
so
right
now
the
hams
does
redundant
reads
and
writes
from
the
ipod
block
store,
which
we
don't
need
to
do.
F
So
we
got
rid
of
them
and
there's
an
implementation
right
now
and
go
I'm
guessing.
People
are
either
aware
of
it
or
maybe
have
already
implemented
it,
but
there's
some
details
there
links
to
the
implementation,
so
you
can
take
a
look
at
that.
F
Just
by
like
selecting
on
the
major
type
when
you
decode
so
we're
saving
bytes
that
way
so
yeah
popping
up
again
to
the
high
level.
The
the
first
step
proposal
saves
gas
by
reducing,
I
believe,
puts
it
gets
the
second
saves
bytes
on
chain
by
just
compacting
things
in
a
kind
of
straightforward
way.
Okay,
yes,
so
that's
the
fip
and
it's
still
not
passed
yet,
but
there
are
some
implementations
you
can
take
a
look
at
I'm
hoping
that
this
will
get
through.
It
should
be
pretty
uncontroversial
and
then
yeah
yeah.
F
The
other
thing
that
I
probably
haven't
talked
too
much
about
is
the
so
the
parameter
that
we're
tuning
is
hampton
amp
with
the
bit
width,
so
basically
the
branching
factor
of
the
trees.
So
we're
doing
some
just
empirical
work
trying
to
project
out
what
the
sizes
of
different
trees
will
be
in
a
few
months
when
we
expect
this
to
be
running
and
just
doing
some
experimental
work
to
tune
things
so
that
the
like
the
cost
in
terms
of
message
processing
time
is,
is
kept
low.
F
We
don't
have
those
numbers
yet,
but
we'll
be
posting
them
soon.
Yeah.
I
think
that's
it
anything
else.
Any
questions.
G
Do
we
have
a
sense
of
which
methods
will
be?
The
mo
will
be
most
affected
by
these
changes.
F
Yeah,
I
don't
have
any
anything
I'd
like
to
share
right
now.
We
have
some
yeah
that
we
do
have
some.
We
have
ways
of
seeing
that
I
want
to
take
a
look
at
the
last
like
we
haven't
measured
a
lot
of
these
things
quite
yet,
but
the
very
preliminary
results
were
showing
window
post
getting
a
lot
of
benefit,
but
yeah
we'll
have
more
to
say
about
that
later
great
great.
A
Sounds
good
yeah
like
thank
you
right,
yeah,
like
you
said,
a
lot
of
this
has
been
discussed
in
in
slack
already,
but
the
folks
from
the
other
implementations
have
feedback
or
concerns
with
the
proposal.
E
A
fit
process
perspective,
I
think,
maybe,
if
zx
nikola
and
any
others
can
review
the
fitbit
itself.
Why
is
this
ready
for,
like
moving
through
the
approval
process?
Now.
F
E
G
E
All
fips
start
out
in
draft
it
gets
merged
as
is
and
and
then,
if
everyone
it
gets
brought
to
this
forum,
and
if
folks,
in
this
forum,
we
have
a
conversation
about
it
and
we
agree
on
it.
So
this
can
be
relatively
fast
to
merge.
It
be
like
okay
cool.
We
already
discussed
it
in
this
form
and
everyone
agrees
on
it.
There
were
no
meaty
changes
between
now
and
when
it's
merged,
then
we
would
make
the
pr
that
changes
it
from
draft
status
to
accepted
status.
A
Great
great,
thank
you,
and
the
next
step
will
be
actually
a
second
change.
A
second
merge,
almost
that
takes
off
the
draft
status.
Once,
though,
was
formalized,
that's
good.
That
makes
sense
beautiful.
Thank
you,
excellent
yeah!
That's
that's
exciting.
I
think
I
think
there's
lots
of
folks
in
the
community
who
are
excited
for
for
the
changes
coming
in
actors.
V3,
so
that'll
be
good
cool.
That's
all!
That's
all
that
we
have
on
the
agenda,
but
we
have
lots
of
time.
A
H
Anything
I
just
have
a
quick
question:
there's
been,
you
know
quite
a
bit
of
activity
in
the
slack
channels
with
respect
to,
and
you
know
the
the
the
the
challenging
mechanism
for
window
posts.
I
was
just
wondering
like
what
the
status
of
that
is
like
what,
when
can
we
expect
a
fifth
or
something
like
that
for
that.
H
A
A
So
I
think
that
that's
the
status
of
where
it's
at
currently
I'm
not
sure
what
his
timeline
is,
but
I
think
it's
it's
pretty
close
to
being
laid
out
as
an
actual
proposal,
it's
kind
of
just
being
written
out
and
some
some
smaller
details
being
thought
about
right
now.
E
Anyone
is
welcome
to
file
afip
with
the
with
the
proposal.
My
question
was
about
fip
six,
which
was
the
no
not
repaying
debt
in
order
to
declare
false
recovered.
This
wasn't
in
the
last
state
upgrade,
but
was
previously
in
last
call
and
had
made
it
through
last
call.
E
Is
there
an
update,
maybe
nikola
or
yeah
yeah,
on
the
research
side
about.
I
That
so
there
is
a
a
new
ffp
coming
up,
which
is
what
is
so
in
that
comment,
we
left
a
comment
in
there
saying
that
there
are
better
ways
to
do
this
and
we
are
writing
up
an
fip,
but
it
is
low
priority
in
our
list,
and
so
so,
to
give
you
background,
this
fib
is
okay
to
merge
if
there
are
a
lot
of
miners
running
to
a
lot
of
issues.
I
Otherwise,
if
we
can
hold
it
and
have
a
much
better
proposal,
then
we
should
probably
postpone
it
and
we
that's.
This
has
been
our
plan.
I
don't
know
how
many
miners
are
in
trouble,
but
if
this
would
would
be
like
a
substantial
amount
of
miners,
then
I
already
in
that
situation,
then
then
we
should
merge
it.
I
didn't
have
time
to
look
into
how
many
miners
are
in
that
situation,
but
otherwise
we
should
instead
of
doing
a
patch.
E
I've
gotten
onto
this
issue
proactively
and
avoid
these,
but
I
think
it's,
it's
still
a
very
it's
a
scary
part
of
the
design
space
for
miners,
and
so
we
should
work
to
fix
it
as
as
soon
as
we
can.
I
Yeah-
and
the
question
is
if
this
is
a
high
priority,
then
we
could
get
this
fix
in
and
then
the
next
fix
will
like
reverse
this
change,
but
I
it
isn't
I
mean
I
can
spend
more
time
to
analyze
how
critical
this
is,
and
you
know
my
expectation
is
a
large
miner
missing
one
single
window
pause,
because
this
is
how
this
starts.
It's
not
going
to
be
affected.
I
They
will
have
to
miss
another
win
the
post
and
will
they
have
enough
money
to
go
and
repay
their
fault
before
they
hit
in
they
get
full
to
that
one
more
time
and
on
the
same
item,
and
so
I
think
we
can
go
down
to
numbers,
but
I
don't
think
it's
a
and
think
whoever
is
a
large
miner
has
likely
the
money
to
repay
a
failed
window
post
in
less
than
a
day.
G
Yeah
and
I
think
they're
out
of
protocol
fix
if,
in
the
event
that
this
happened,
I
think
there
are
the
protocol
fixed
that
we
can
consider
pulling.
But
I
agree
with
nicola
on
the
front
that
I
think
it
seems
that
most
manners
are
doing.
Okay,.
E
Yeah
we
can
so
logistics
wise.
We
should
effect
pause.
This
fip
move
it
back
to
draft
wait
for
a
new
fib,
we'll,
hopefully
replace
this
and
allow
us
to
not
have
multiple
fips
patching
the
same
thing
and
reverting
previous
fips
this
early
in
our
life
cycle.
Since
you
know,
I'm
sure
we
will
have
that
that's
going
to
happen,
but
we'd
like
to
defer
it
as
much
as
possible.
A
Cool
any
other
points
of
discussion.
B
Yeah,
I
actually
just
have
one
quick
question
that
came
to
mind
so
this
this
for
the
the
hamp
changes
are
included
that
we
talked
about,
but
the
improvements
to
the
caching
of
the
amp
has
already
been
made
to
the
go
implementation.
But
I
I
don't
know
if
there's
a
fit
coming
with
it
or
are
we
just
kind
of
assuming
that's
all
along
the
same
stream,
because
I
know
it's
been
merged
into
the
goans
implementation.
But
I
don't
think
it's
an
actress,
v1
or
v2.
Is
that
correct.
F
Yeah,
that's
that's
right!
That's
a
really
good
question.
I
think
that
yeah.
So
it's
something
that
I
just
overlooked
when
filing
the
the
hampship
it
might
make
sense
to.
I
guess:
there's
two
approaches,
so
we
should
we
we
yeah.
So
we
probably
since
we
were
flipping
the
hemp
one,
it
would
make
sense
to
50
amp
the
amps
one.
I'm
thinking
that
just
bundling
it
up
with
the
current
enhanced
fip
would
make
sense.
Yeah
any
objections
to
that.
A
B
F
C
Hi,
I
have
one
question
about
yeah
and
actually
is
about
the
gas
phase
and,
as
you
can
see,
that
we
have
a
very
high
base
fee
and
in
the
in
the
current
network,
and
we
have
some
effects
to
improve
this.
Perhaps
I
want
to
know
if
we
have
any
plan
and
in
our
links
to
this
and
to
mitigate
this
kind
of.
I
Right,
I'm
gonna
touch
on
this
one
because
you
know
there
is
a
this
is
a
complicated
problem
and
I
cannot
guarantee
that
any
solution
that
we're
trying
to
do
will
lower
base
fee,
but
what
I
can
guarantee
is
that
will
reduce
the
gas
cost
for
operations
which
are
essential
in
the
network.
I
For
example,
windowpost
is
essential
that
it's
very
cheap
proof
commit
and
and
and
pre-commit
it's
okay.
If
and
sometimes
they
are,
they
are
expensive,
but
the
idea
is
also
to
reduce
those
numbers.
So
in
terms
of
scale,
I
want
win
the
post
and
publish
deals
to
be
as
slow
as
possible,
and
then
the
goal
is
to
lower
proof,
commit
and
pre-commit
and
so
on,
and
we
do
have
multiple
approaches
right
now.
I
My
personal
focus
is
not
on
published
storage
deals,
but
it's
mostly
on
windowpost,
and
there
is
this
optimistic
windowpost,
which
is
the
proposal
that
eric
mentioned
before
that
alex
is
writing
down.
I
think
that
would
be
a
major
saving.
We
do
have
other
ideas
for
reducing
windowposts,
but
I
think
that
they
are
there.
They
have
a
different
scale
in
comparison
to
this
idea.
That
alex
is,
is
writing
up
is
writing
down.
So
we
are
like
betting,
a
lot
on
on
this
one
and
then
for
proof
commit
and
pre-commit
we're
doing
some
experiments.
I
It's
it's
not
gonna
happen
this
year,
but
we
have.
We
have
multiple
lines
of
work
to
to
improve,
to
improve
the
reducing
the
cost
of
pre-commit
improve,
commits
and,
like
we
discussed
last
time,
there
was
a
fip
from
alex
that
was
on
reducing
the
pre-commit
cost,
and
we
will
agree
that
we
would
postpone
that
until
we
can
also
reduce
proof
commit
cost,
because
otherwise
miners
could
run
in
a
situation
where
they
think
pregnant
is
cheap.
I
They
do
a
lot
of
pre-commit
and
then
they
do
proof
commit
and
then
basically
it
goes
to
x
where
it
is
today,
and
so
this
changes
for
pre-commit
and
proof
commit.
There
are
many
ways
from
which
we
can
do
it
and
one
approach
is
this
a
batching
techniques
which
we
already
use,
but
we
have
another
approach,
which
is
a
changing,
given
the
ability
to
generate
a
single
proof
instead
of
multiple
proof
for
pre-commit.
I
This
is
a
bit
of
a
larger
change,
but
we
believe
that
this
change
will
massively
reduce
the
on-chain,
the
on-chain
presence
of
through
coming
messages,
which
is
what
is
making
this
fee
going
up.
So
what
I'm
trying
to
say
without
giving
any
hope
is
that
windowpost
is
essential
to
lower
down,
and
that
may
happen
as
soon
as
possible.
I
Maybe
early
generally,
I
don't
think
like
molly
said
anything
will
happen
this
year
so
early
generally,
I
have
the
confidence
that
we
will
get
windowpost
very,
very
low
in
a
way
or
another
way
for
base
fee
being
high.
The
only
way
forward
that
I
see
for
base
fee
is
to
reduce
the
cost
is
to
change
strategy
on
proof
commits
instead
of
having
one
proof
commit
per
per
sector,
adding
one
proof
commit
for
multiple
sectors.
That's
that's
the
strategy
but
too
early
for
fip.
I
Commit
is
gonna
happen,
window
pass
is
gonna
happen
early
january.
I
don't
want
to
do
any
promise,
but
maybe
february
could
be
a
good
time
for
lowering
downproof
commits,
and
you
know,
a
lot
of
these
things
will
depend
based
on
how
much
storage
is
being
onboarded.
If,
in
january,
miners
decide
to
onboard
much
more
storage
that
they
are
onboarding
today,
for
example,
today
we're
on
board
15
to
20
petabytes.
I
If
that's,
if
at
any
point
the
the
storage
on
boarded
is
100
petabytes
per
day,
then
we
may
have
to
reassess
priorities,
but
in
my
expectation,
is
that
basically
will
go
up
and
down
until
january,
maybe
it's
going
to
lower.
I
I
don't
know,
I
think
realistically
is
the
best
path
forward.
I
don't
know
if
this
answers
your
question.
C
Okay,
yeah,
that
is
very
good
yeah.
We
said.
Okay,
based
on
my
calculation,
I
was
saying
that
okay,
the
window
post,
is
a
very
important
part
for
the
basically
going
up.
Okay,
I
was
thinking
that
okay,
the
major
part,
will
be
the
province
and
the
approved
sector
and
also
the
pre-committee
sector.
The
two
parts
are
also
a
very,
very
important,
okay
yeah.
C
E
E
If
you
do
it,
you
know
not
not
in
the
sustainable
way
or
not
in
a
way
that
that
that
doesn't
relatively
improve
some
parts
of
the
network
so
like,
for
example,
this
relatively
improving
window
posts,
storage
deals
other
actions
that
we
need
it
to
be
cheap
for
the
network
to
do
relative
to
other
other
actions
in
the
network,
like
onboarding
new
storage,
and
so
we
need
to
both
look
at
the
relative
cost
of
these
things,
as
well
as
the
the
overall
total
cost,
because
you
know
it's
optional,
whether
or
not
you
spend
time
adding
new
storage
to
the
network.
E
It's
not
optional,
whether
or
not
you
continue
proving
it
to
the
network,
and
we
need
to
make
sure
that
the
balance
there
is
effective,
and
so
that's
why
we're
spending
our
energy
on
kind
of
one
versus
the
other.
First,.
G
G
But
it
could
still
be
a
case
that
the
demand
for
using
a
network
is
still
very
strong.
The
basic
continues
to
be
very
high,
even
though
we
optimize
for
different
methods
and
I
think
the
biggest
pain-
it's
not
really,
basically
is
high.
Basically,
it's
high
because
I
mean
miners
as
the
population
controls
the
base
fee,
miners
push
it
to
be
very
high,
because
you
want
to
use
a
network
which
is
very
good,
but
the
problem
there
is.
It
will
affect
smaller
miner
in
a
disproportionate
way,
and
we
want
to
fix
that.
G
C
C
Okay,
yeah
and-
and
you
totally
agree,
and
about
that,
okay
yeah-
I
will
send
that
yeah
what
yeah
it
would
be
good
to
try
the
best
to
to
to
optimize
yeah
the
resource
usage
and
to
reduce
this
and
basically.
G
Okay,
yeah,
definitely,
I
think,
I
think,
the
the
pr
the
hand
pr
will
also
likely
also
help
yeah.
C
Okay,
okay,
yeah
and-
and
I
have
another
and
another
proposal
about
the
about
the
fip
and
naming-
and
I
put
the
link
here
every
time
I
go
to
the
fip
list-
I
don't
know
which
one
is
for
what
so.
I
would
suggest
that
the
the
name
of
the
faith
to
have
the
title
of
the
faith
and
into
the
failure
which
you
it
will
be
better
for
us
to
to
to
yeah
to
know
which
is
for
what
yeah.
Well,
we
are
searching
something.
H
In
the
list
I
mean,
I
don't
think,
there's
anything
wrong
with
like
the
naming
on
github,
but
you
know
for
the
ethereum
eips
they
have
a
website
for
it.
I'm
not
sure
if
we
have
that
set
up
for
the
fips
process,
but
yeah
having
something
that's
pretty
much
exactly
the
same,
as
that
would
be
very
useful
for
people
who
just
want
to
view
fips.
C
J
E
J
A
A
Cool
this
is
really
good.
More
do
people
have
more
thoughts,
suggestions.
B
I
just
have
one
small
thought.
I
just
said
I
just
out
of
curiosity:
is
there
any
plans
to
get
community
input
on
the
fip?
You
know
process,
it
would
just
be.
I
don't
know
it
seems
like
it
would
be.
Maybe
a
nice
thing
to
get
a
better
idea
of
the
stakeholders
of
the
network
for
the
you
know
approval
process,
even
if
it
doesn't,
you
know,
block
or
whatever
at
least
to
take
it
into
consideration.
So
it's
not
just
approval
based
on
you
know,
I
guess
the
people
here
making
the
decision.
B
It's
I'm
not
exactly
sure
how
everything
gets
exactly
approved,
but
just
is
there
any
plans
to
get
like
community
input
on
this.
A
Yeah,
that's
a
good,
that's
a
good
question,
I
think
so
I
think
we're
definitely
getting
so.
All
of
this
is
obviously
happening
publicly
in
the
phil
phipps
channel
and
on
the
fifth
github
repo
as
well,
and
we're
definitely
getting
a
lot
of
community
feedback.
That's
driving
the
process
kind
of
before
we're
getting
to
the
approval
stage.
I
think
where
minors
in
particular
are
definitely
letting
us
know
what
flips
they
want
and
massaging
some
of
the
conversation
and
like
providing
their
feedback
there.
A
E
Yeah,
I
think
one
the
discuss
issues
associated
with
a
particular
fip
like
do
get
comments
from
the
community.
Some
get
more
than
others.
It'd
be
awesome
to
have
more
discussion
there
on
places
where
things
are
controversial.
That
being
said
kind
of
understandable,
like
yeah,
please
give
us,
you
know
performance
improvements,
so
controversial
pips
will
create
more
discussion.
E
E
Community,
where
you
don't
just
want
to
have
you
know,
here's
a
long
stream
of
discussions
with
no
ability
to
visualize,
like
miners,
think
this
is
a
good
change,
but
this
is
really
bad
for
clients
and
clients
need
an
important
change
or
alteration
to
this,
because
it's
going
to
decrease
the
value
of
the
network
for
storing
data
and
and
being
accessible
to
them.
E
That's
a
really
important
thing
to
visualize
since
we're
working
on
a
kind
of
pulling
tool
that
will
will
be
usable
in
that
way
and
we'll
be
able
to
kind
of
weight,
different
opinions
in
a
graphical
view
by
the
type
of
group
they
are,
so
you
can
be
like
great.
You
know,
50
of
clients
are
in
favor
of
this
weighted
by
a
number
of
deals
that
you've
made,
and
you
know
30
percent
of
I
don't
know.
Ecosystem
partners
are
doing
this
other
thing
or
ecosystem
developers.
That'll
allow
us
to
visualize
it.
I
don't
think.
E
Similarly
to
many
other
groups,
you
know
a
lot
of
this
is
kind
of
organic
and
the
depending
on
the
fip
there'll,
be
different
feedback
loops
that
happen
there,
and
it
is
really
the
responsibility
of
the
fip
holder
and
the
fip
creator
to
build
support
and
adoption
for
for
a
fip
as
it's
going
through
the
approval
process
and
then,
as
it
lands
here
and
gets
kind
of
approval
from
this
group,
we
should
review
any
controversy
with
the
community
if
there
is
any
before
making
some
of
those
decisions
on
whether
or
not
we're
going
to
spend
our
time.
E
Implementing
it
into
four
different
implementations
or
not
so
that
that's
kind
of
how
we
expect
that
to
fit
into
the
process,
but
we're
still
kind
of
working
on
that
iterating
on
it.
I
think
it'll,
probably
not
be
we'll,
probably
be
ready
to
beta
test
it
sometime
in,
like
the
beginning
of
q1
timeframe,.
A
That's
good
yeah.
I
really
like
the
idea
of
that
polling
feature
to
see
what
folks
are
saying.
A
Suggestions
all
right.
I
think
this
has
been
really
good.
I
think
yeah,
some
of
the
some
of
the
questions
and
suggestions
raised,
have
been
really
really
useful.
Thank
you.
Everyone
also
fantastic
progress.
God
I
love
hearing
everyone
get
so
much
closer
to
the
ultimate
goal.
Every
two
weeks
we
talk
cool.
I
think
I
think
we
can
wrap
up
for
today.
Molly
sure.
Are
we
having
another
one
of
these
in
two
weeks
right
before?
Can
the
christmas
break.
E
That's
a
good
question
are
people
that
would
be
the
17th
of
december.
I
believe
yes,
yeah.
All
right
are
people
thumbs
up
if
you're
going
to
be
present
and
would
like
to
have
this
meeting
thumbs
down.
If
you
are
not
going
to
be
present
and
would
prefer
to
defer
this
meeting
until
january,
with
an
understanding
that
there'd
be,
you
know,
proper
sound
fit.
E
I
think
if
you
can't
attend-
or
if
you
know
the
timing
isn't
great,
feel
free
to
send
an
async
update
in
the
fip
issue
itself
and
happy
holidays.
If
we
miss
you.