►
From YouTube: Filecoin Core Devs Biweekly #18
Description
Recording for: https://github.com/filecoin-project/tpm/issues/40
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
Fantastic
all
right,
good
morning,
good
afternoon,
good
evening.
Everyone
welcome
to
the
18th
five
point
core
devs
meeting
on
thursday
20th
may.
Thank
you
all
for
being
here
hope
everyone's
doing
well.
Yeah
we've
got
a
fairly
packed
agenda
today,
we'll
start
with
our
usual
updates.
Then
we
have
some
stuff
to
discuss
regarding
v5
actors,
network
v13,
some.
A
I
know
why
zen
grant
put
in
some
items
that
he
wanted
to
talk
about
and
then
maybe
some
chats
about
a
new
fifth
that's
popped
up
and
also
some
conversations
have
been
happening
around
our
pc
interfaces
and
whether
we
kind
of
want
to
agree
on
a
core
subset
of
the
rpc
endpoints
that
that
we've
been
trying
to
standardize
and
whether
that's
something
we
want
how
we'd
want
to
go
about
it
kind
of
take
the
first
steps
of
that
conversation,
but
yeah,
that's
so
lots
to
talk
about.
B
Everyone
thank
you.
So,
unfortunately,
we
don't
have
our
work
on
stabilizing
solution.
We
have
definitely
done
a
lot
of
progress,
so
our
p2p.
Well
recently,
we
have
tested
the
epp
alone.
I
introduced
couple
of
year
fixes,
and
now
after
I
think
about
50
hours
of
working
alone,
straight
vp2p
doesn't
show
any
memory.
Consumption
like
it's,
basically
a
straight
line
with
deviation
in
couple
of
megabytes.
B
So
it's
at
this
point.
We
can
say
that
it's
pretty
much
stable.
We
have
also
identified
a
thick
fault
related
to
some
issues
in
during
the
noise
handshake.
So.
B
This
is
something
we
have
fixed
regarding
the
phone
itself.
We
are
working
on
the
last
fix,
which
will
definitely
contribute
to
memory
consumption.
B
Which
is
a
proper
chipset
index
handling,
so
it
will
not
be
stored
in
memory
completely
and
part
of
it
will
be
rotated
to
the
on
disk
storage
and
the
other
part
will
be
stored
in
memory
and
on
demand.
It
will
be
also
loaded
in
memory,
so
this
is
quite
a
big
fix,
we're
currently
working
on
it.
Actually,
it
is
coded
and
we
are
testing
at
the
moment.
B
As
for
foocon
itself,
we
have
also
identified
a
couple
of
sequels
and
well.
We
have
introduced
fixes,
they
don't
seem
to
be
repeating
anymore.
So,
hopefully,
our
plan
is
to
finish
with
the
with
testing
of
index
handling
early
next
week
and
restarting
out
for
the
linkedin
testing.
B
Give
it
one
to
two
weeks
and
see
what
will
happen
if
memory
consumption
will
be
stable
again
will
be
a
good
point
to
announce
publicly
that
you
know
it
is
available
and
for
everyone,
and
everyone
is
welcome
to
try
it.
So
that's
it
for
the
updates
on
the
fukon
site.
Any
questions
not
for
me.
A
No,
that
sounds
fantastic.
Anyone
else
have
questions
I
feel,
like
you
said
the
word.
We
found
an
issue
and
fixed
an
issue,
a
lot,
whether
that's
like
false
memory,
leaks
or
other
stuff.
So
that
sounds
really
good
cool.
Let's
hear
from
venus,
maybe
stephen.
D
Yeah
and
hello,
everyone,
okay
and,
as
a
last
update,
we
mentioned
that
we
we
have
received
the
initial
report
of
the
security
awarded
and
we
had
some
issues
reported
and
some
suggestions,
so
we
take
yeah.
We
took
some
time
in
last
two
weeks
to
face
the
issues
and
to
do
some
change.
According
to
the
suggestions,
and
now
we
had
yeah
feedback.
All
these
fixes
and
and
now
is
waiting
for
the
yes
audit
vendor
feedback
and
we
yeah
we're
hoping
to
get
the
final
value
report.
D
Perhaps
within
two
weeks
yeah
we
will
say
if
there
is,
there
are
more
issues
and
all
that
yeah.
This
is
one
thing.
Another
thing
is
that
we
are
yeah.
We
set
up
a
real
disputed,
remaining
pool
on
the
left
now
yeah
in
this
pool.
We
have
four
loads
and
we
also
announced
we
have
this
pool
yeah.
We
have
this
pool
running
and
we
are
asking
more
miners
to
join
us
to
do
this
kind
of
a
test
yeah.
D
This
is
only
a
test
for
it's,
not
a
an
official
pool
and
and
and
with
this
we
think,
yeah
we
could
perhaps
set
up
another
tool
and
another
pool
to
get
more
smaller
miners.
So
right
now
we
are
designing
a
plan
and
we'll
discuss
with
the
falcon
foundation
to
see
if
we
could
have
a
do
some
free.
You
know
free
service
for
some
super
minors
to
incubate.
D
Some
minors
and
to
to
enact
the
whole
ecosystem
yeah.
We
hope
to
have
some
minors
from
different
continents
and
join
us
yeah.
This
is
about-
and
we
are-
and
also
working
on
some
other
plans,
for
example,
to
to
write
down
some
rfps
and
to
see
if
any
other
developers
can
join
us
to
enhance
our
code.
D
And
another
thing
is
that
we're
working
on
the
video
smart
package,
which
is
for
the
real
data
storage-
and
this
will
be
it's
still
in
progress
and
we're
thinking
yeah.
If
we
could
provide
this
on
the
mining
pool,
they
will
instead
of
for
each
miner.
So
as
a
other
data
and
storage
a
new
table,
you
know
portal
for
all
the
manners
on
in
this
pool.
D
So
we
think
it's
very
interesting,
but
we
are
still
in
the
design
effect
and
design
phase
and
and
we'll
say
how
it
and
how
it
could
work,
because
we
have
discussed
with
some
small
minors,
yeah
they're,
very
interested
by
this.
So
I
think
that's
all
about
what
we
have
been
have
done
in
last
weeks.
A
Yeah
I
mean
first
off,
that's
great,
you
know
you
mentioned
security.
All
this
stuff
is
happening
distributed
mining
pool
stuff
is
happening.
Work
on
a
markets,
module
that
can
also
be
distributed
is
happening.
That's
a
lot
a
lot
of
trains
moving
at
the
same
time,
which
is
great.
I
think
that
I
think
that
idea
of
a
markets-
module
that
sits
on
top
of
a
pool
instead
of
a
single
miner
is
very
interesting.
A
Yeah
I'd
be
curious
to
see
kind
of
your
initial
design
of
that,
because
that
could
be
that
yeah.
That
could
help
a
lot
of
smaller
miners
service
storage
providers,
yeah
very
cool,
any
questions
that
everyone
has.
E
Hey
nice
to
see
everybody.
First
of
all,
we
have
a
new
team
member
which
is
awesome,
so
lee
has
joined
to
help
us
out
with
like
project
management
stuff.
So
yeah,
I
don't
know
if
you
want
to
say
a
quick
word
or
anything
lee
but
yeah.
It's
really
exciting
to
have
have
a
new
personal
team.
F
E
So
yeah,
that's
exciting
team's
been
growing
but
yeah.
I
guess
our
main
focus
has
been.
You
know
that
now
that
we're
doing
the
audit
just
responding
to
anything
that's
coming
up,
it's
been
a
little
quieter
than
we
expected,
and
this
is
the
first
time
we're
doing
an
audit
which
at
first
we
were
a
little
bit
worried
that
maybe
it
shouldn't
be
so
quiet
but
turns
out.
This
is
just
how
it
is.
E
So
that's
good
we've
been
addressing
any
issues
that
come
up
and
otherwise
we're
sort
of
thinking
you
know
ahead
towards,
like
you
know,
once
the
audit
is
done,
you
know
what
do
we
want
to
do
to
be
in
a
position
to
launch-
and
I
think
like
that,
some
of
those
things
are
like
becoming
more
full-featured.
E
So,
for
example
like
integrating
storage,
retrieval
markets,
and
so
eric's
been
working
hard
on
that
and
we're
still
kind
of
finishing
up
the
pay
channel
stuff
on
our
side
and
getting
the
go,
fill
markets
ready
to
actually
integrate,
so
that
should
be
done
pretty
soon.
Otherwise,
we
definitely
want
to
be
able
to
allow
people
to
sync
from
the
beginning
of
from
from
genesis,
and
so
we've
been
doing
state
migration
work.
E
E
Because,
as
we
move
towards
a
more
production
client,
we
want
to
make
sure
that
everything's
performing
well
and
give
any
miners
or
users
the
tools
they
need
to
really
understand
how
forest
is
performing,
and
so
that's
in
the
process
of
being
done
so
we're
using
prometheus
and
grafana
to
do
metrics
and
then.
Finally,
we
also
want
to
make
forests
more
usable.
So
we've
been
doing
some
work
on
the
cli,
just
kind
of
making
sure
all
the
important
commands
that
we
want
people
to
be
able
to
use.
E
Are
there
and
yeah
that's
about
it
at
a
high
level.
Eric
is
there
anything
more
detailed
that
you'd
like
to
share.
G
No,
nothing
really,
I'm
sure
we're
going
to
talk
about
active
version
5
when
zen
gives
an
update,
but
yeah
I
mean
we
haven't,
started
working
on
version
five.
Yet
because
there's
a
lot
of
other
stuff
that
we
wanna
do
before
we
get
into
production,
but
we've
started,
you
know
scoping
it
out
and
we're
probably
gonna
start
within
the
next
week
or
so
so
yeah
and.
H
There's
also
some
work
that
we
did
on
lowering
ram
usage,
improving
block
validation,
speed
and
fixing
a
seg
fault
that
kind
of
kept
us
from
running
it.
For
you
know
super
long,
so
I
mean
maxine
gets
to
brag
about
his
sec
fault.
You
know
we
get
that
we
get
to
do
so.
Yeah.
H
H
So
if,
if
I
want
to
forward
my
linux
to
not
well
just
to
work
so
anyway,
that's
really
cool
we're
gonna
have
to
invest
in
some
cloud
stuff
at
some
point
to
like
really
just
like,
like
see
how
how
like
this
works
as
an
archive
note,
it's
really
exciting
to
see
you
know
I
mean
I
want
to
see
like
how
big
the
right
amplification
factor
is
for
just
how
big
you
know
the
the
the
database
gets,
and
you
know
how
long
it
takes
to
sync.
H
I
don't
know
if
anybody
else
is
running
lotus
in
archive
node
capacity
or
how
large
their
their
you
know
say.
Their
database
or
their
snapshot
car
file
would
be.
A
Yeah
we
do
have
some
infra
running
lotus
as
a
full
archive
node.
I'm
not
sure
what
those
numbers
are,
but
we
can
definitely
get
them
easily.
Yeah.
A
Yeah
cool
update,
I'm
especially
happy
to
hear
about
the
state
migration
stuff
because
yeah
that
allows
you
to
think
from
genesis
and
also
importantly,
you
know.
Next
time
we
have
a
new
acura
version
and
there's
a
migration
you
all
can
stay
seamlessly
instead
of
having
a
little
break
over
there.
So
very
cool,
very
cool
glad
to
hear.
I
think
your
audit
stuff
is
going
well
and
there's
nothing.
Nothing!
Terrifying
has
been
discovered
so
far,
I'm
hoping
cool
jennifer.
Can
you
give
us
a
quick
update
on
like
lotus
one?
C
So
lolis
has
just
released
a
version
190,
which
indeed
introduces
like
various
improvements
like
to
the
cd
money
and
deal
making
process
highlights.
Are
we
integrated,
like
proof
b,
seven,
zero,
zero,
one
and
market
v,
one
and
two
five
and
now
gpu
two
is
now
enabled
by
default
in
lotus
and
which
results
in
like
way
faster
when
impulse,
pc2
and
c2
computation,
and
we
heard
from
some
like
community
members
that
their
pc2
computation
time
was
even
like
half,
which
was
great
news
and
yeah
and
now.
C
C
Hopefully-
and
you
know,
to
get
the
code
out
in
the
community's
hand
and
having
the
miners
to
test
in
the
calibration
net
as
soon
as
possible,
because
it's
going
to
be
a
huge
change
and
a
lot
of
like
configuration
that,
like
miners,
need
to
tweak
about
so
and
we
would
love
to
receive
feedback
from
the
miners
and
get
ready
for
the
actual
upgrades
before
then,
and
in
parallel,
like
to
everything
with
the
next
network,
upgrade
we're
also
working
on
re-architecturing
the
minor
wrong
hand.
C
So,
as
you
may
know,
since
there
are
more
like
demand
in
the
network
like
deal
making
and
everything
low,
this
manner
doesn't
necessarily
handle
that
really
well
like
when
a
deal
is
incoming.
C
At
the
same
time,
a
winning
post
and
the
window
process
is
computing.
The
the
process
like
may
impact
each
other.
So
what
we
are
trying
to
do
is
segregating
the
market
functionality
so
that
it
can
run
in
a
separate
physical
process
from
the
storage
and
block
mining,
and
we
believe
this
will
improve
the
robustness
and
resilience
of
the
managed
deployment
and
will
unlock.
You
know
the
new
heights
of
like
scalability
of
the
storage
and
retrieval
markets,
so
I'm
super
excited
about
that.
Yeah.
G
I
have
a
question
for
that
because
I
mean
I
don't
know
about
the
fujan
team,
but
for
us
obviously
we
don't
have
the
markets
module
and
that's
what?
Basically
we
we
created
a
go,
fill
markets
interface
like
last
year
and
that's
kind
of
what
we're
updating
to
get
working.
G
So,
if
you're
separating
the
markets
module
from
the
lotus
stamen,
how
is
what's
the
interface
going
to
look
like?
Is
it?
Is
there
like
a
page
where
you
know
like
that
sums
up
kind
of
the
changes,
because
it
kind
of
just
seems
like
we
don't
have
to
do
this
interface
work
anymore?
We
just
have
to
implement
some
rpc
endpoints
or
something
like
that.
Yes
is.
G
C
C
You
know
because,
right
now
it's
invited
everything
is
embedded
in
the
lotus
miner,
but
we
want
to
set
process
out
of
that.
It's
like
you,
have
sitting
workers
in
all
this
minor,
but
you
don't
have
one
worker
for
like
mark
like
deal
making.
I
think
that's
the
general
idea,
but,
like
you,
should
feel
free
to
cry
me.
If
I'm,
you
know
wrong.
A
G
Okay,
cool
yeah-
actually
I
remember
seeing
this
diagram
before
at
the
retrieval
market
summit,
I'll,
probably
reach
out
to
raul.
I
think
he's
one
who's
talking
about
this,
so
yeah
I'll
message
him
see.
What's.
A
Up
cool
yeah
there's
a
couple
more
things
that
we've
been
doing
specifically
on
kind
of
b5
actors
and
v13,
but
we'll
get
to
those
in
a
second
because
I'll
kind
of
segue
into
our
next
topic
of
conversation.
But
before
that
I
wanted
to
see
if
the
falcon
foundation
or
the
community
side
of
things,
if
there
were
updates,
we
wanted
to
share.
I
Yeah,
so
we
are
hoping
to
be
able
to
share
more
publicly
about
a
mining
working
group
that
is
being
set
up,
and
so
I
think
there
are
maybe
one
or
two
folks
on
this
call
that
are
involved
in
that.
I
think,
besides,
that
we
are
also
hiring
rapidly
for
a
number
of
roles,
and
so,
if
you
guys
know
great
people
in
your
network
or
if
you
personally
have
interest
join
us,
the
foundation
definitely
check
out
our
jobs
where
I'll
put
it
in
the
chat.
I
And
then
it's
also
on
our
website
under
our
careers
section.
So
that's
it.
C
From
the
community
set
of
the
scenes-
and
in
case
you
don't
know-
we
are
starting
to
accept
application
for
the
second
round
of
the
minor
x
fellowship
program
which
has
been
running
for
the
past
few
months,
and
we
see
like
great
outcome
of
this
program,
which
we
have
like
constant
and
close
feedback
loop
with
miners
to
improve
our
protocol
and
also
like
the
loader
software.
So
we
are
that's
why
we're
ex
we're
like
rolling
out
another
program
and
application
is
open
until
monday.
Utc
00
am,
I
believe.
C
So
if
you
are
interested
in
that
and
check
out
our
like
announcement
in
the
falcon
slack
and
I'm
gonna
looking
forward
to
see
all
your
applications.
Yes,.
A
Yeah,
can
you
quickly
drop
a
link
to
where
one
can
apply
or
get
more
info?
I'll
put
it
in
the
in
the
notes
of
the
meeting
yeah.
That's
fantastic,
also
quickly,
on
kind
of
the
community
side
of
things,
I
think,
there's
a
blog
post
coming
soon
that
talks
about
the
hyperdrive
upgrade
v13
network,
v13
and
v5
actors,
so
be
excited
for
that
too.
A
So,
yeah
quickly
on
yeah
on
kind
of
the
ongoing
implementation
work
for
that
zen
grand
white
will
kind
of
provide
a
lot
of
the
info
there,
but
a
couple
of
quick
things
to
flag
yeah
the
lotus
on
the
core
loader
side
of
things.
We've
been
working
on
integrating
flips,
thirteen
and
eight
so
actually
using
pre-commit,
batching
and
proof
aggregation
in
the
lotus
miner.
That
work
is
basically
done.
We're
testing
right
now.
A
We
also
finally
introduced
the
ability
to
create
genesis
files
for
any
actors
version,
so
we're
planning
on
using
that
to
start
an
interrupt
net,
probably
directly
from
b5
actors,
because
I
think
either
before
we
have
actors
depending
on
what'll,
be
more
useful.
I
also
want
to
quickly
introduce
alexander
wade,
alex
wade,
who's
kind
of
been
you
know,
part
of
the
file
coin
world
for
a
while
now,
usually
auditing
things
trying
to
find
security
issues
and
generally
making
sure
things
are
good.
A
He's
been
he's
been
doing
some
work
for
past
couple
weeks
now
and
will
be
for
the
next
several
months.
Just
making
sure
making
sure
filecoin
is
is
secure.
Alexa.
If
you
want
to
quickly
introduce
yourself.
J
Hello,
nice
to
meet
everyone,
I'm
from
consensus,
diligence
and
yeah.
I've
been
working
with
the
filecoin
team
for
the
past
six
months
or
so
yeah
and
I'm
looking
forward
to
helping
prep
you
guys
for
the
v5
release
for
actors.
A
Fantastic
yeah
thanks
for
joining
alex
yeah.
Okay,
so
I
think
it
does
a
good
time
to
jump
into
into
the
immediate
v5
microsoft
zen.
I
don't
know
if
I
know
you
put
some
stuff
in
in
the
agenda.
Do
you
want
to
take
over.
K
Yeah
totally
so
I
guess
at
a
high
level
to
make
sure
we're
all.
On
the
same
page,
v5
actors,
inspect
actors
is
roughly
implementation,
complete,
fips,
13
and
8.
The
bulk
of
the
work
is
done,
there's
just
some
parameter,
setting
finalization
some
final,
like
gas
measurement
too,
and
then
there's
some
last
mile
bug
fixes
and
just
release
maintenance
stuff
to
do
yeah.
So
I
have
a
few
call
outs
about
parameters
that
that
will
be
changing
or
might
be
changing.
A
lot
of
this
is
not
like
fully
firm.
K
I
just
wanted
to
call
out
how
far
certain
parameters
might
stretch
in
case
it
you
know,
causes
a
concern
or,
if
someone
you
know
has
has
thoughts
on
it.
As
I
I
left
in
the
the
tpm
issue,
I
left
four
changes.
I'll
go
over
them
briefly.
Now
also
repost
this
in
slack
to
make
sure
that
everyone
has
time
to
look
into
it
but
yeah,
just
in
brief
so
currently
like
in
the
in
the
current
fifth.
K
We
have
the
proof,
commit
aggregate
max
being
like
204
and
we're
thinking
we
might
bump
that
up
either
to
400
or
so
or
800
or
so,
and
in
order
to
unlock
small
miners
with
a
smaller
ceiling
rate
to
get
these
batch
sizes
in
we're.
K
Also,
thinking
of
increasing
the
max
proof
commit
duration,
so
the
time
between
pre-commit
improved
commit
before
pre-commits
expire
up
to
a
month,
so
that
those
kind
of
go
together
and
then
another
similar
change,
we're
thinking
of
increasing
the
max
pre-commit
batch
size
from
32
to
something
like
64
or
128,
and
this
all
just
allows
a
better
gas
savings
for
miners
that
are
able
to
yeah
increase
the
commits
that
they
they
send
up
on
chain
and
then
finally,
something
to
call
out
is
there's
some
new
behavior
on
expiring
pre-commits
in
order
to
make
error
handling
a
little
bit
better,
a
little
bit
less
damaging
so
now
we're
keeping
a
pre-commits
on
chain
for
another
eight
hours
after
they
expire,
so
that
proofs,
which
require
these
pre-commits.
K
As
you
know,
public
inputs
will
be
able
to
still
verify,
even
though
the
pre-commits
that
have
expired
won't
actually
be
proven.
The
rest
of
the
batch
won't
be
spoiled
by
a
few
pre-commit
expiring
up
to
eight
hours,
so
that
was
quick.
We
can.
We
can
talk
more
on
slack
heads
up
on
those
things.
I
don't
expect
any
of
this
to
be
controversial.
I
just
wanted
to
to
follow
up
here.
I'm
also
planning
to
update
fips,
13
and
8
with
the
new
changes
in
the
near
future.
K
So
that's
that
I
guess
I'll
give
space
for
any
questions
or
discussion.
If
anyone
has
anything
to
say
before.
Moving
on
to
the
next
thing,
I
wanted
to
bring
up.
A
Sounds
good
yeah
adding
those
changes
to
the
flips
themselves
sounds
good.
That
way
we
can
get
community
feedback
to
see
how
people
how
people
feel
about
these
numbers,
because
this
is
very
much
a
community
driven
thing
yeah.
Does
anyone
have
any
questions
for.
K
That
okay
awesome
all
right,
but
the
next
thing
is
it
shouldn't
be
a
big
deal.
I
just
wanted
to
call
it
to
the
forest
team
since,
since
you
have
mentioned
a
difficulty,
understandably
so
with
updating
hampton
amp
dependencies,
we
are
planning
to
update
the
specs
actors,
hampton
amp
dependencies
with
non-consensus
breaking
changes.
So
if
you
have
to
make
any
changes
to
your
implementation,
then
something
has
gone
horribly
wrong
and
we
would
back
out
of
it,
but
just
a
heads
up.
K
I
don't
want
you
to
see
us
merging,
updates
those
dependencies
and
you
know
start
getting
concerned
that
you
have
to
do
a
lot
of
work,
we're
just
adding
a
diffing
behavior
for
some
of
the
infra
for
the
purposes
of
some
teams
doing
infrastuff
on
top
of
lotus
us
we'd
like
to
add
that
directly
into
actors
again,
not
consensus
breaking
so
it
shouldn't
cause
any
work
for
you.
Just
a
heads
up.
G
A
Sounds
good
all
right
yeah,
who
who
has
questions
about
v5
actors,
whether
that's
impulse,
stuff
or
timeline
stuff?
How
are
people
feeling.
A
Eric,
I
know
you
said
you
wanted
to
bring
up
wanted
to
talk
more
about
it.
Anything
sorry.
G
Yeah,
well
I
mean
you
know,
I
don't
we
haven't
settled
on
a
date
yet,
but
I
mean
it's
the
20th
right
now
and
we're
targeting.
I
know
we're
originally
targeting
mid-june,
but
I
think
last
time
I
spoke
to
you,
you
said
you
wanted
to
push
it
earlier.
It's
I
don't
know
if
that's
very
realistic
for
us,
but
yeah
I
mean
yeah
mid-june,
probably
sounds
a
little
bit
better
for
us.
A
Yeah,
so
that
that's
still
roughly
what
we're
looking
at
honestly,
I
think
a
lot
of
it
will
come
down
to
at
least
from
my
perspective
kind
of
like
lotus
perspective.
I
will
commend
to
how
the
rc
testing
goes
like
kind
of
starting
next
week.
A
If,
if
things
look
smooth,
if
the
test
networks
look
good-
and
you
know
miners
that
start
experimenting
with
the
rc-
don't
have
too
much
of
a
problem
with
it,
then
you
know
we
can
potentially
move
from
mid
june,
like
from
like
third
week
of
june,
to
maybe
first
or
second
week
of
june
and
we'll
be
moving
by
much
more
than
that,
but
but
I
think
yeah
that
that
that's
kind
of
where
I'm
at
yeah
would
would
a
an
upgrade
date.
Let's
say
around
june.
A
I
don't
know
seventh
work,
because
jennifer
did
flag
that
a
good
chunk
of
china
or
east
asia
will
be
going
on
holidays
for
a
little
bit
june,
12th
or
so
so.
If
we
are
moving
it
up,
it
would
have
to
be
kind
of
before
that,
ideally
so
yeah.
How
do
people
feel.
G
G
It's
like
I'm,
not
sure
what
kind
of
tangible
benefit
that
you
know
these
two
weeks
of
not
upgrading
would
do
like
the
the
thing
is
for
us,
it's
really
hard
to
make
a
commitment,
because
the
audit
has
been
so
silent
and
it's
like
the
process,
I
think,
is
like
you
know,
within
a
week
from
now
we're
just
going
to
get
like,
you
know,
dropped
with
a
preliminar
pro
preliminary
report
with
like
a
bunch
of
things
that
we
need
to
fix,
and
it's
like.
G
We
don't
really
have
a
good
idea
of
how
like
what
kind
of
changes
we're
gonna
have
to
make.
It's
like
really
hard
to
make
a
time
commitment,
but
I
mean
june
7th
does
seem
early.
You
know
a
little
bit
of
a
squeeze
for
us,
maybe
even
more
than
a
little
bit.
G
B
D
Yeah,
okay,
I
think
I
don't
think
there
are
much
work
for
being
us
to
do,
because
we
just
integrated
the
speed
factor
and
package
and
yeah
to
some
changes
on
venus
and
changing
colony,
and
so
I
think
it's
okay,
you
know
just
need
yeah,
for
example,
one
or
two
days
after
this
uploaders.
C
D
A
Yep
sounds
good
yeah
yeah.
I
obviously
want
to
acknowledge
that
it's
there's
much
more
work
involved
for
the
forest
team,
because
they're
actively
re-implementing
actors
and
which
is
something
we
want,
and
so
we
don't
want
that.
Then
wind
up
becoming
you
know
a
punishment
but
yeah.
It's
a
group
decision
that
we'll
make
we
don't
have
to
make
it
right
now,
so
we'll
kind
of
see
how
how
things
shape
up
next
week
and
kind
of
discuss,
async
and
slack
and
try
to
try
to
pick
a
bigger
timeline.
A
But
what
and
sorry
to
answer
your
question
eric
like
yeah
you're
right
and
that
not
that
much
is
gained
within
two
weeks.
Honestly-
and
maybe
this
is
just
a
personal
thing-
it's
like
we
have
been
like
these
flips
have
been
around
forever
and
they've
been
sitting
around
forever
and
some
I
I'm
I'd
like
to
see
them
go
live
in
the
network
because
they
do
like
substantially
improve
things
basically
immediately.
A
So
that's
that's
part,
that's
basically
the
motivation
there
and
obviously
the
community
has
been
waiting
for
them
for
a
while
and
steph
kept
jumping
the
queue
ahead
of
them.
So
yeah
it'll
it'll
be
good
to
get
them
live,
but
you
know
two
weeks
one
way
or
the
other
does
not
does
not
change
anything
too.
Materially.
G
A
Fair
enough
watch
us
be
still
be
having
this
conversation
in
december
because
of
that
that
was
a
joke.
Yeah,
we'll
we'll
see
how
how
stuff
goes
next
week
and
agree
on
a
timeline,
probably
just
async
and
slack,
but
because
yeah.
A
Cool
sounds
good,
yeah
and
obviously
interrupt
net
and
test
vectors
are
kind
of
ongoing
efforts
which
which
I'm
assuming
will
help
with
a
lot
of
that
testing.
So
you
can
get
get
some
confidence
that
way
too
cool
anything
else.
On
the
on
the
hyperdrive
discussion,
whether
that's
implementation,
community
stuff,
any
questions.
A
Okay,
that's
good
can
always
take
additional
questions.
I
think
I
want
to
jump
to
15
real
quick.
This
is
one
that
the
discussion
had
been
around
forever.
We
only
actually
created
the
sip.
Let
me
drop
the
link
in
chat.
We
only
actually
created
the
fip
or
like
moved
the
flip
along
recently,
but
basically
it's
a
very
simple
proposal,
which
is
to
revert
fip
9,
which
was
the
kind
of
stop
gap
that
we
introduced
back
in
december
to
exempt
successful
window
post
messages
from
the
basic
burn.
A
That
was
always
supposed
to
be
a
temporary
thing.
While
we
worked
on
better
solutions,
we
since
have
three
better
solutions:
optimistic
window
post
and
now
it's
outlined
in
the
flip
but
yeah.
How
do
we?
What
are
we
thinking?
What
do
we
feel
like
with
optimistic
window
posts,
fips,
13
and
8,
all
of
which
kind
of
should
be
leading
to
an
overall
reduction
in
basically,
now
is
a
good
time
to
to
undo
this
thing,
or
would
we
want
to
wait
longer?
It's
not
it's
not
a
complicated
implication,
implementation
thing.
A
G
A
Yes,
so
yeah
the
yeah,
the
change,
I
think,
at
least
in
the
lotus
code,
basically
goes
if
you're
past
this
network,
don't
you
know,
don't
charge
for
the
the
base
view
burn
here
that
that'll
change
too,
if
you're
past
this
network,
but
before
this
network.
So
it's
it's
literally
a
net
zero
lines
of
code
aside
from
testing
one
of
the
motivations
here
that
I
should
mention
is
right
now
stephanie
alien.
A
A
Sometimes
or
some
minors
appear
to
be
doing
that
so,
like
you
know,
if
you
can
prove
five
partitions
in
one
post
message,
they're
choosing
to
instead
set
five
separate
posts,
submit
post
messages
just
to
avoid
a
all
or
nothing
failure
case
where
you
know,
if
you're
trying
to
do
it
all
in
one
post
and
they
fail
that
all
five
partitions
are
are
affected,
that's
or
how
many
other
partitions
that's
fine,
but
that
is
from
a
network
like
chain
capacity
perspective.
A
That's
not
ideal,
because,
obviously
you
know
if
we,
if
we
want,
if
something
can
happen
in
one
message:
that's
better
from
a
chain
capacity
perspective.
Obviously
people
are
more
willing
to
do
it
right
now,
because
window
post
messages
are
extremely
cheap
because
you
pay
nothing
for
the
base
fee.
We
could
so
there's
a
little
bit
of
motivation
from
there.
But
again
it's
not
it's
not
pressing.
G
A
Yeah,
the
lotus
miner
definitely
will
we'll
pack
them
all
into
a
single
message,
but
I
think
people
who
want
to
kind
of
take
a
more
have
a
lower
risk
tolerance.
I
guess
choose
to
send
individual
request
messages
which
again.
A
Can
continue
to
do
so
once
if,
after
we
undo
this
flip
as
well,
if
they
want
to
but
right
now,
it's
kind
of
like
artificially
cheap
to
do
so.
A
A
Or
at
least
we
have
any
objections
to
it.
Maybe
then
we
can
kind
of
get
community
feedback
and
make
a
decision
based
on
that.
A
Okay
sounds
good
cool
yeah,
we'll
we'll
see
we'll
try
to
get
some
community
input
on
it
and
make
a
decision
one
way
or
the
other
again.
It's
not
not
a
huge
decision
that
we're
making.
I
think
at
least
from
an
implementation
perspective,
and
yet
jennifer
adds
some
some
motivation
in
chat.
I
will
add
that,
to
our
notes,
all
right.
The
last
thing
that
I
had
in
the
agenda
is
there
anything
that
anyone
else
wanted
to
bring
up
by
the
way.
A
I
did
have
one
last
agenda
item,
but
if
people
have
more
interesting
things
or
more
pressing
things,
we
can
discuss
them.
A
Okay,
cool
last
item,
so
this
is
a
conversation
that
a
question
has
come
up
a
couple
times
in,
like
straight
conversations
around
rpc
standardization
and
again
came
up
in
a
conversation
with
eric
from
chainsafe
earlier
this
week.
Eric
honestly,
do
you
want
to
do
you
want
to
kind
of
leave
this
one
and
kind
of
talk
about
the
background
and
what
what
we
like
to
propose.
G
Yeah
sure
I
mean
so,
you
know,
since
you
know,
we're
building
pretty
much
just
a
daemon.
Currently
I
mean
we're
probably
going
to
start
building
a
bunch
of
the
other
stuff
too,
but
currently
we're
building
the
daemon.
So
that
means
we
rely
on.
You
know
like
the
lotus
miner
and
the
lotus
markets
and
stuff
like
that,
and
obviously
those
things
communicate
over
json
rpc.
G
G
It
changes
like
under
our
feet
and
like
one
day
like
things
just
stop
working,
and
so
I
guess
what
I'm
proposing
is
that
we
standardize
like
a
core
part
of
the
json
rpc
interfaces,
so
that
we
still
have
composability
between
all
the
different
pieces
of
software
and
in
addition
to
that,
it's
like,
if
we
don't
start
doing
something
like
this,
like
standardizing
at
least
like
a
core
part.
G
Because,
like
you
know
as
an
implementation,
you
can
start
implementing
other
json
rpc
methods
too,
but
like
we
won't
consider
that
as
like
a
core
part
of
like
the
falcoin
offering
like
the
importance
for
that
is,
is
like
you
know,
people
who
are
gonna
start
building
like
these
library
wrappers
around
json,
rpc
and
building
dapps.
So,
like
libraries
like
something
like,
you
know,
web3.js
on
ethereum,
like
things
like
that,
are
going
to
start
emerging
soon
as
more
and
more
like
people
start
building
dabs,
and
it's
like.
G
If
you
can't
use
this
library
against,
like
all
the
different
implementations
like
you're,
going
to
break
a
lot
of
dapps,
and
so
that
that's
kind
of
like
the
motivation
behind
it
is
like
I'm
not
advocating.
For
like
slowing
down,
like
you
know,
changes
to
the
interfaces,
but
it's
like
we.
We
should
have
like
a
version
like
standard
that
is,
you
know,
kind
of
like
discussed
and
agreed
upon
by
everybody
or
not
everybody.
G
But,
like
you
know,
people
who
are
implementing
like,
like
you
know,
just
relevant
stakeholders,
I
guess
and
so
yeah
like
yeah,
some
something
like
you
know,
all
the
other
blockchains
have
just
like
a
standardized
core
json
rpc
offering.
That
is
consistent
amongst
all
the
different
implementations.
A
Yes,
this
is
interesting
because
there's
a
really
there's
kind
of
two
things
to
threads
for
that.
To
what
you
just
said,
I
think,
where
number
one
is
yeah
lotus
is
working
on
its
v1
api,
which
we've
wanted
to
do
for
a
while
and
obviously
that's
a
change
that
you
know
will
impact
everyone
who
uses
lotus.
Basically
so
right
now,
the
v0
api
is
still
fully
supported
and
and
is
the
default.
A
And
so,
whereas
the
v1
api,
which
is
under
development,
is
like
highly
unstable,
but
where
internal
components
of
lotus,
such
as
the
markets,
module
and
the
miner
and
so
on,
have
already
switched
to
the
v1
api,
which
you
know
we
thought
was
fine
to
do,
because
we
are
actively
maintaining
those
things,
but
that
led
to
issues
because
those
sub
components
are
used
because
the
lotus
miner
is
not
only
used
by
lotus,
basically
and
so,
and
that
was
kind
of
a
bit
of
a
an
oversight
or
honestly
learning
for
for
us
that
we
that
we
can't
make
that
change
kind
of
assuming
that
that
it
won't
impact
anyone
else.
A
We
thought
it
was
only
the
fully
external
interface
that
matters,
and
so
I
think
so,
at
the
very
least,
we
now
know
to
be
mindful
of
that
and
to
at
least
like
yeah,
get
the
changes
better
and
like
announce
it
and
so
on,
because
we
thought
no
one
would
care
and
then
kind
of
the
second
so
and
that's
an
easier
problem
to
solve,
potentially
so
just
be
a
little
more
careful
slow
down
a
little
bit
with
those
changes.
A
The
second
problem-
or
the
second
thread,
is
yeah
around
this
idea
that
people
people
will
want
all
implementations
of
file
point
to
agree
on
some
to
ideally
agree
on
some
standardized
rpc
interface.
You
know
it's
not
consensus
critical
in
the
way
that
we
agree
on
the
protocol,
but
it'll
just
be
useful
for
a
lot
of
use
cases
and
yeah
and
yeah.
But
what
do
people
think
about
that?
Do
we
do
people
agree
with
that
idea.
B
Yeah
yeah
from
from
site,
I
can
see
that
we
are
differently
agreed
something
well.
The
changes
in
the
apis
is
something
that
we
have
also
faced
and
had
to
resolve,
and
it
is
clear.
Well,
we
had
understood
from
the
very
beginning
that
we
will
have
to
comply
to
lotus
api,
both
from
minor
side
and
from
the
node
side
be
compatible
with
in
in
four
components
to
be
compatible
and
inter
exchangeable,
so
basically
for
the
same
reasons
described.
A
A
Are
we
generally
an
agreement
that
we
that,
even
if
the
water
isn't
answered
there
should
be
question,
is
answered
as
ncs.
A
All
right
sounds
good,
so
at
the
very
least
kind
of
next
steps
will
be
the
v1
api
work.
A
That
lotus
is
doing
we'll
externalize
a
lot
more
because
again
we
were
kind
of
keeping
this
in-house
thinking
of
it,
as
only
something
we
need
to
talk
about
so
we'll
externalize
that
to
the
yeah,
the
core
devs
here,
and
also
to
the
broader
community
and
kind
of
get
their
input
and
hopefully,
within
a
few
months,
we're
in
a
place
where
we're
happy
enough
with
with
where
the
v1
api
is
that
some
subset
of
that
can
kind
of
become
standardized.
G
Yeah-
and
I
mean
just
to
like,
be
super
clear-
it's
like
I
know
we
all
want
to
move
like
super
fast
and
all
and
like
that's
cool,
it's
just
like
if
we're
gonna
do
that,
we
just
have
to
be
very
communicative
with
each
other,
because
I
mean
generally
like
I
don't
really
have
opinions
on
what
the
interfaces
should
look
like
or
anything
it's
just
like.
G
We
need
to
know
so
we
can
implement
it
and
then,
like
you,
know
all
like
making
it
pretty
and
all
that
stuff
can
come
like
later
when
we
actually
standardize
it,
but
before
we
standardize
it.
It's
just
like
really
good
to
you
know
just
have
like
a
place
where
we
can
talk
about
it
and
just
communicate
about
it.
Yeah.
A
Gotcha
yeah,
so
yeah
more
of
that
info
happening
asic
and
slack
will
be
good.
Also
more
of
those
updates
happening
in
these
calls,
I
think,
will
be-
will
be
useful.
I'll
make
a
note
of
those
things
all
right
and
yeah
any
other
questions.
There's
been
a
there's
been
a
meaty
meeting
talked
about
a
lot
any
other
points
of
discussion
or
questions.
I.
B
Have
a
small
question:
any
news
regarding
the
interrupt.
A
Sorry
any
news
about
it:
yes,
so
the
I
finally
opened
the
pr
and
lotus
that
allows
us
to
start
to
create
genesis
files
from
any
actors
versions.
So
with
that
we
will
be
able
to
launch
a
drop
net
like
basically
next
week
with
starting
from
any
active
version,
and
now
this
is
what
I
wanted
to
quickly
touch
on.
Would
we
prefer
for
that
to
start
from
v4
or
b5
like?
Would
you
prefer
start
from
b4
migrate
to
b5
and
then
run
with
v5
onwards
or
just
start
directly
from
b5
then?
B
Well,
I
think
it
makes
oh
sorry
go
ahead.
Yeah!
Thank
you.
So
I
I
don't
think
it's
it's
really
important
for
us
at
this
point,
so
we
we
can
go
either
way.
What
do
you
think.
G
Yeah
I
mean
my
my
thoughts
was.
I
don't
think
it's
like
super
super
important,
but
it
would
be
kind
of
nice
to
start
from
beef
forward
now
that
I
think
all
of
us
have
state
migration
functionality
and
it's
like
one
extra
thing
to
test
that
you
know
that
we
can
be
a
little
bit
more
sure
about,
although,
like
I
guess
like,
if
you're
starting
from
v4
and
migrating
after,
like
10
epochs,
there
won't
be
like
much
state
to
migrate
anyways
but
yeah.
So
I
guess
it
doesn't,
doesn't
really
matter.
A
Okay
sounds
good
yeah!
Well,
we'll
see
we'll
see
what
yeah.
If
we're
not
that
interested
in
testing
the
migration
itself,
then
maybe
we
just
started
from
v5
directly
so
that
we
get
to
it
right
away,
we'll
see
not
the
biggest
decision
to
make.
It
sounds
like
given
that
you'll
not
support
my
patients
cool
yeah.
So
hopefully
that
should
come
next
week
to
answer
your
question.
Maxine
anything
else.
G
Oh,
I
have
one
other
thing
just
for
us
specifically
since
we're
doing
the
state
migration
stuff,
but
it'd
be
nice
if
there's
a
way
for
us
to
get
like
state
migration
benchmarks.
I
guess
like
we're
running
these
state
migrations
they're
taking
some
time,
but
we
have
no
idea
if
it's
like
performant
enough
relative
to
the
other
clients
like
how
long
these
things
should
take.
So
it'd
be
kind
of
cool
to
see
some
numbers
that
lotus
has
crunched
out
before
just
to
see.
If
our
migrations
are
good
enough.
A
Yeah
seems
reasonable.
Zen
do
you
have
those
readily
available.
G
A
Those
are
not
easy
to
do.
I
also
wonder:
there's
just
a
straight
thought
then,
but
do
you
think
ent
will
be
useful
for
the
external
implementations
to
use
as
well
to
validate
some
of
their
stuff.
K
A
Basically
does
a
lot:
it's
like
sanity
checking
around
migrations
and
just
state
state
trees
in
general.