►
From YouTube: Filecoin Core Devs Biweekly #6
Description
Recording for: https://github.com/filecoin-project/tpm/issues/13
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
And
welcome
everyone
to
thursday
november
19th,
our
sixth
falcon
core
devs
meeting
cool,
so
maybe
starting
with
updates
from
various
different
implementation
teams.
I
think
I
always
make
forest
go
seconds.
You
guys
don't
want
to
go
first,
this
time.
B
Sure
yeah
we'll
kick
things
off,
so
we've
been
making
good
progress
with
interop
we've
fixed
all
the
interrupt
issues
we've
incurred
encountered
up
until
this
point,
so
we've
been
we're
now
sinking
up
to
height,
I
think
22,
000
or
so
and
rising.
So
it's
just
running
in
the
background
and
fingers
crossed
we're
more
than
halfway
to
the
breeze
upgrade
now
and
we're
feeling
pretty
confident
that
we
have
achieved
interop
with
v1.
B
I
might
eat
my
words
there,
but
I
it's
we're
very
we're
feeling
pretty
good
are
in
now
that
we've
kind
of,
I
guess,
dealt
with
most
of
the
issues
there.
Our
focus
is
syncing
with
mainnet,
so
upgrading
to
actors
v2,
so
we've
started
making
changes
here
and
we've
continued
implementing
what
we
need
to
for
staying
in
sync
with
the
network
rather
than
just
the
initial
sync.
B
So
that's
also
another
parallel
line
of
development,
that's
happening
and
our
third
goal,
which
is
markets
and
storage,
minor
integration,
we're
still
working
on
getting
the
first
block
produced,
but
we're
inching
closer
and
closer
every
week.
So
things
are
slowly
coming
together,
also
chatted
with
molly
last
week
about
an
audit,
we're
aiming
for
early
january
to
be
syncing
with
mainnet
and
ready
for
an
audit
we'll
keep
you
up
to
date
with
that.
B
Obviously
that's
just
a
target
for
now,
but
that
that
seems
reasonable
to
us
and
then
I
think
austin
has
a
couple
updates
as
well.
That
he'd
like
to
share.
C
Yeah
I
mean
I
I
I
guess
the
idea
is
just
to
share
the
reiterate
the
points
or
questions
I
came
up
with
in
the
implementors
chat,
which
is
around
the
amped
enhanced
updates,
which
I
guess
we
might
chat
about
later
and
then
the
other
issue
around
how
the
panic
handling
is
or
how
like
panics,
are
handled
within
the
protocol,
because
it's
very
hard
to
kind
of
match.
C
With
other
implementations,
I
put
all
the
information
in
the
implementer's
trap,
but
if
we
want
to
chat
about
that
other
than
that,
I
guess,
like
the
improvements
have
just
been
kind
of
performance
updates
for
for
our
client
like
we're
well
thinking
and
stuff,
we're
definitely
definitely
either
in
line
or
faster
than
lotus
and
in
some
cases.
C
But
I
guess
it's
very
like
it's
hard
to
test
the
two
and
I
haven't.
I
haven't
it's
definitely
not
toe
to
toe
yet
because
I
haven't
been
able
to
test
lotus
with
the
blst
feature
yet
because
that
just
came
out.
But
yeah
was
that
all
that
that
you
mentioned
that
I
should
cover
yeah.
A
Cool
awesome,
maybe
we'll
hop
through
other
implementation
updates
and
then
go
back
for
open
questions,
this
one's
okay,
cool
stephen.
Do
you
want
to
go
next
for
venus.
D
Sure
yeah,
I
think
we
have
made
a
very
good
progress
on
the
very
last
implementation
and
also
about
integration
with
lotus.
As
I
mentioned
in
last
week,
we
are
doing
the
thinking
from
the
height
zero.
Now
I
think
we
are
yeah,
it's
going
very
good
yeah.
We
are
almost
catching
up
at
the
minute
hey
and
we
are
also
working
on
the
the
chasing
and
with
the
snapshots
and
yeah
the
checkpoint
and
to
catch
up
the
the
speak
out
version
too
now.
D
I
think
we're
very
confident
about
this.
Yeah,
though
we
have
some
and
yeah
so
yeah
small
problems
as
some
more
issues,
we're
handling
right
now,
yeah,
but
within,
and
also
we
passed
all
the
tests.
The
unit
test,
and
also
this
is
vectors.
So
we
think
that
yeah
well
we're
pretty
confident
about
all
the
integration
yeah.
It's
because
also
the
notice
and
the
venus
catching
up
is
kind
of
slow,
so
yeah.
We
we
just
need
perhaps
a
more
few
days
to
catch
up.
D
Okay,
this
first
thing-
and
another
thing
is
that
we
are
finally
achieved
within
a
small
milestone-
is
that
merged
a
walking
branch
to
the
master?
And
this
afternoon
so
yeah
perhaps
and
I
can
share
my
screen
yeah
to
let
you
know.
D
Let
me
share
my
screen
with
a
moment
here.
E
D
Okay,
sure
yeah,
so
here
we
have
yeah
poor
request
about
the
okay,
the
current
version
of
yeah,
the
so
very
long.
Okay.
I
think
this
is
a
very
big,
merge
and
yeah
it's
because
we
we
have
all
the
changes
in
last
few
weeks
and
yeah,
maybe
more
than
one
month.
D
We
have
making
changes
to
be
and
be
complained
with
this
with
speak
and
to
fix
the
many
things
here,
including
this
big
active
version
to
the
test
vector
and
the
block
sync
and
protocol
support
and
upgrade
the
block
and
basically
validation.
So
yeah
there
is
one
problem
with
bet
is
that
this
goes
down
here.
D
Yeah
I-
and
I
don't
think
I
have
the
yeah.
I
have
the
privilege
to
change
to
change
the
setting
of
the
ci
and
also,
I
was
want
to
add
some
web
hook
application
to
this.
You
know
to
do
something
like
devops,
but
I
cannot
do
that
very
long,
so
I
use
some
help
from
this
to
to
make
this
pass
or
to
just
remove
this
so
that
we
can.
We
do
the
merge
reload.
D
D
Okay,
yeah.
Thank
you
so
yeah.
This
is
the
current
status
and
I
think
next,
we'll
do
some
yeah
two
more
things.
The
most
important
thing
is
that
to
integrate
the
minor
part,
okay,
so
so
that
we
could
do
the
yeah
power
growth
and
we
yeah.
We
already
have
working
very
less
load.
We
we
expect
that,
could
we
could
have
that
done
and
perhaps
in
two
weeks
or
yeah?
I
need
more
time
on
that.
D
To
have
the
yeah
to
have
the
main
impact
and
integration
together
so
right
now
we
will
only
have
the
changing
pad
as
a
virtual
machine
and
the
message
block.
Verification
is
something
like
this:
we
don't
have
the
ceiling
yeah,
so
we
yeah.
We
need
to
have
the
sailing
part.
F
Yes,
sure,
can
you
hear
me
well,
okay,
so
we
have
quite
a
separate
situation
from
the
rust
guys,
so
we
decided
to
take
a
little
bit
of
refactoring
of
our
code.
We
realized
that
our
implementation
of
the
nodesync
and
especially
graphing,
is
not
as
efficient
as
we
wanted
it
to
be,
and
we
realized
the
events.
F
Event-Based
architecture
will
suit
it
more
well
and
we
decided
that
as
we,
so
current
version
is
in
a
working
state,
but
we
haven't
tested
it
so
early
and
now,
as
we
see
some
flaws
in
it,
it's
easier
and
cheaper
for
us
to
to
go
to
the
event
based
architecture
straight
away.
F
So
we
are
planning
to
finish
with
it
by
the
next
week
by
the
end
of
the
next
week,
and
hopefully
our
version
of
note
will
be
working
by
the
end
of
the
month,
so
this
is
with
in
parallel.
We
are
doing
so
last.
On
the
last
meeting,
I
reported
that
we
have
gone
through
the
storage
deal
and
it's
it
works
well
and
we
have
started
working
on
the
debugging
and
making
retrieval
dual
compatible.
F
F
So,
as
I
mentioned
on
previous
meetings,
we
are
working
on
our
own
implementation
of
factors.
Currently
we
are
working
on
a
payment
channel
actor
and
I
think
the
storage
one
is
the
next
one.
Sorry
remember
so
these
are
tools
that
we
are
working
on
in
parallel.
F
A
G
Yeah,
yes,
lotus
had
a
relatively
quiet
couple
of
weeks,
at
least
based
on
our
usual
usual
cadence,
mostly
motivated
by
the
fact
that
folks,
in
the
community
miners
developers
etc
were
reporting
that
lotus
had
some
stability
issues.
So
we
kind
of
took
a
few
steps
back
to
make
things
more
performant
broadly
and
fix
some.
Some
stability
bugs,
obviously
doesn't
get
all
the
way
there.
G
The
chain
footprint
is
still
huge,
but
yeah
things
in
general,
work
faster,
run
out
of
memory,
less
require
less
memory
in
general.
So
that's
good.
That
was
last
week
this
week
we
just
shipped
our
120
release,
which
will
be
the
second
network,
upgrade
post
liftoff,
there's
more
moving
pieces
in
this
upgrade
consensus.
Critical
moving
pieces
in
this
upgrade
that
we've
had
in
a
while.
G
G
The
critical
piece
in
the
upgrade
itself
is
upgrading
our
proofs,
so
the
new
actors
version
that
we're
using
introduces
a
new,
fixed
proof
type
and
so
there's
a
window
in
which
both
old
proofs
and
new
proofs
will
be
accepted
and
then,
after
a
second
upgrade
also
introduced
in
this
release,
we
switched
to
only
accepting
the
new
proofs,
so
I
think
it's
it's
fairly
intuitive.
G
So,
but
if
you
have
any
questions
with
that,
I'm
happy
to
answer
them
in
terms
of
priorities
moving
forward,
I
think
lotus
will
kind
of
continue
to
be
in
maintenance
mode.
Basically,
for
the
rest
of
the
year,
we've
only
got
a
few
weeks
until
the
winter
break,
so
for
the
most
part
we'll
be
making
sure
this
upgrade
goes
well,
responding
to
any
issues
continuing
to
try
and
make
overall
ux
and
performance
a
little
better,
but
no
active
development
is
being
planned.
G
C
G
D
Yeah
and
I'm
sorry
I
may
yeah-
I
mean
yeah.
I
miss
that
you
do
have
a
plan
of
the
proof
upgrading
in
yeah.
When
will
do
that,
you
have
to
have
a
draft
plan.
A
This
isn't
the
upgrade
to
nse
steven.
This
is
just
a
a
bug
fix
around
proof's
code.
That
requires
a
new
proof's
version,
but
that
doesn't
actually
change
any
of
the
circuits
or
anything
like
that.
A
A
Cool
then,
maybe
we
hop
back
to
some
of
any
of
the
questions
that
austin
brought
up
if
any
of
those
needed
more.
H
I
have
like
a
question
about
like
implementations
in
general,
would
not
be
a
good
time
sure
connect
okay,
awesome,
and
so
my
question
I'm
happy
to
wait
for.
My
answer
is
just
like
how
everyone
is
approaching
about
the
messaging
layer,
so
gossip
sub,
how
robust
is
the
implementation
that
you
are
using
for
the
language
that
you
are
developing
your
implementation
of
falcoin
and
how
are
you
consuming
the
drain?
Randomness?
Are
you
just
consuming
it
from
http
endpoint
leveraging
ctns
or
are
actually
leveraging?
H
I
don't
know
some
like
compilation
from
the
go
version
to
some
other
language
so
that
you
can
access
also
to
the
randomness
through
gossip
sub
as
well
or
yeah.
I'm
just
like
interested
to
know
like
those
two
dependencies
that
falcon
heavily
relies
on.
How
are
you
dealing
with
them
and
is
everything
good
or
do
you
have
anything
on
on
plan
to
to
make
it
better.
C
Oh
eric,
do
you
wanna
you
wanna?
I
saw
you
unneeded.
I
I
On
the
p2p
side,
it
seems
like
most
people
are
using
a
very
vanilla
configuration
of
gossip
sub
and
all
of
that,
so
for
us
it's
like
it
works
fine
and
then,
in
terms
of
d
brand,
where
yeah
we're
just
consuming
it
from
the
the
cdn
on
the
http
endpoint
and
then
for
I
guess
also
with
respect
to
the
p2p.
I
I
H
You
yeah
for
sharing
the
extra
detail
on
bit,
swap
I
I
was
actually
not
familiar
with
that
variation
of
bitswap.
That
makes
it
incompatible.
Is
it
incompatible
like?
Can
you
just
dial
to
an
falcon,
node
and
and
like
use
bitswap
for
transfers
or
how
is
that
working
on
sorry?
What
what?
What
are
you
asking
exactly,
I'm
exactly
asking
like:
how
are
you
using
bitswap
and
like
with
the
rest
of
the
network.
I
Oh
yeah,
so
when
we
receive
a
gossip
sub
block,
it
comes
with
a
list
of
cids
for
messages,
and
then
we
add
that
to
our
want
lists,
and
then
we
broadcast
those
out
to
receive
the
messages
for
them.
H
Oh
interesting,
okay,
so
interesting
that
that
is
the
case,
because
gossip
sub
itself,
as
the
mechanism
for
lazy
pool,
which
should
be
able
to
pull
the
messages.
So
I
guess
I'll
need
to
dig
more
to
make
sure
I
understand
better
that
specific
use
of
it,
because
it
seems
that
the
the
message
is
also
being
published
through
just
like
the
the
the
file
transfer
mechanism,
so
that
it
gets
pulled
later.
H
A
C
C
C
My
my
knowledge
there
yeah
we
I
mean
we
check
locally
to
see
if
we
have
the
messages
before
we
look
over
bitswap
but
yeah
that
if,
if
that
fails-
and
that's
the
you
know
the
second
tier
and
as
far
as
as
far
as
the
dram
stuff,
we
definitely
do
like
it
would
be
nice
to
have
some
client
built
out
for
it.
But
we
just
don't
really
have
the
bandwidth
right
now,
so
we're
just
yeah
making
standard
http
requests
to
the
endpoint
gotcha
good
to
know.
Well,.
F
Yep,
as
for
the
forehand
implementation,
we
are
also
using
the
http
endpoint
to
get
the
data
from
the
direct
and
as
for
the
go
ships
up,
we
are
developing
it
by
ourselves.
So
we
are
the
maintainers
for
the
c,
plus
plus
liquidity
implementation,
which
is
also
used
by
polka
dots.
H
H
Even
if
one
fails,
you
can
always
use
the
other
and
like
for
a
cdn
to
fail
like
something
must
be
wrong
with
the
whole
internet,
but
back
in
the
future
is
still
good
to
think
about
just
like
to
have
the
the
real
client
so
that
you
leverage
like
you,
can
access
the
the
randomness
through
gossip
as
well
and
yeah
like
and
and
the
fact
that,
like
the
way,
pewdiepie
implementations
that
you
are
using
are
also
used
by
other
projects
that
also
invest
heavily
on
gossip
sub.
Like
yeah.
H
H
A
Austin,
did
you
have
a
specific
question
coming
from
the
phil
implementers
chat
that
didn't
already
get
a
reply
from
either
steven
or
a
north.
C
So
yeah,
I
guess
they
they
they
did
reply
to
them.
So
I
I
guess
we
can
just
leave
it
as
as
the
ones
that
were
you
know
chatted
about
there,
but
if
we
did
want
to
talk
about
the
plan
of
if
there
was
going
to
be
an
integration
of
it,
yeah
I'm
fine
with
leaving
it
as
the
way
that
in
leaving
those
discussions
on
the
implementer's
chat,
I
just
like
brought
it
up.
If
that
was
something
that
we
wanted
to
mention.
G
Yes,
I
guess
a
couple
things
first
for
background
for
anyone
that
might
have
missed
a
conversation.
Yeah
austin
raised
two
good
questions
around
one
one
around
the
ampton,
hampton
implementations
that
we
have
and
some
inefficiencies
in
them,
which
were
already
largely
in
the
actor's
team's
radar
and
is
in
progress
to
get
fixed.
G
So
if
anyone
missed
that,
take
a
look
at
that-
and
the
second
question
was
around
essentially
how
what
we
do
when
actors
panics
are
in
some
other
odd
error
situations
where
right
now
we
trap,
we
trap
all
panics
coming
from
actors
and,
I
think
usa,
says
a
reserved
exit
code.
So
those
are
the
conversations
being
referred
to
just
for
background
aspen.
What
do
you
mean
by?
And
it
might
be
good
to
keep
those
conversations
largely
in
the
implementative
channel?
G
Just
so
there's
a
a
threat
of
discussion,
but
I'm
curious
what
you
mean
by
integration
like
integrating
which
parts.
C
Oh
just
like,
if
there's
ever
a
plan
to
if
the
fixes
for
these,
like
the
the
optimizations
of
the
hampton
amp
to
reduce
gas
charges
like
that,
obviously
has
to
come
with
a
network
upgrade
like
if
there's
any
plane
around
that
or
for
any
case
to
change
how
the
panic
handling
but
like
the
panic
handling,
is
just
more
of
a
topic
of
conversation.
I'm
just
like.
As
I
said,
I
just
noted,
it
was
a
pain
point.
C
I
didn't
necessarily
say
that
anything
had
to
change,
but
yeah
I
just
I
just
bring
it
up
if
that
was
if
there
was
any
planned
around
around
that.
G
Yeah
no
no
plan
around
around
the
panic
handling,
as
far
as
I
know
so,
that'll
probably
stay,
as
is
for
the
time
being,
but
but
thank
you
for
flagging,
regardless
for
the
amped
enhanced
implementations,
we're
planning
on
yeah,
like
you
said,
that'll
have
to
go
in
behind
the
network,
upgrade
we're
thinking
january
for
that
which
hopefully
will
be
our
next
next
network
upgrade.
Unless
we
need
a,
we
need
one
more
urgently
for
some
reason.
So
that's
that's
the
current
plan
and
yeah.
G
As
you
said,
most
of
the
changes
don't
actually
need
a
migration,
but
I
think
I
think
the
actors
team
will
have
some
other
changes
that
do
require
migration
going
into
that
upgrade
as
well.
So
we
can
afford
to
be
a
little
more
aggressive
with
it.
So
january
is
when
that
should
happen.
B
Yeah
for
sure,
so
we're
actually
hosting
a
our
first
virtual
event.
I
think
it's
december
2nd
to
4th
so
about
two
weeks
from
now.
There
will
be
some
people
from
this
call,
giving
talks,
which
will
be
awesome
and
just
talks
coming
from
all
of
our
partners,
so
there'll
be
talks,
a
bunch
of
talks
from
the
falcon
ecosystem,
polkadot
ecosystem,
ethereum
ecosystem,
as
well
as
the
cosmos
ecosystem
and
more
raul
you're.
More
than
welcome
still
to
to
join
us
and
yeah.
B
I
just
wanted
to
to
mention
like
we're,
really
excited,
I
think
there'll
be
a
lot
of
great
talks
and
we're
all
definitely
missing
getting
together
in
person,
and
so
we're
hoping
that
this
is
just
an
opportunity
for
all
of
us
to
to
reconnect
and
and
learn
all
together
and
just
have
some
fun
so
yeah.
The
website
is
cscon.chain.
B
A
Fantastic
awesome,
it's
gonna
be
fun
cool.
I
think
I
just
mostly
gave
the
up
update
on
our
state
upgrade
that's
coming
up.
I
guess
a
week
from
two
days
ago,
and
so
that's
out.
I
believe
that
has
fixes
for
fips
five
and
six
is
that
right,
ayush.
G
A
They're
definitely
the
two
most
recent
ones,
which
I
guess
to
keep
myself
honest,
are
specifically.
A
You
five
is
the
the
vesting
investing
rewards
more
efficiently
and
six
is
when
you
declare
faults
recovered.
You
don't
have
to
have
already
repaid
all
of
your
fee
debt,
which
means
that
a
minor
who's
recently
gotten
into
window
post
debt
can
still
recover
their
window
posts
before
paying
off
all
of
their
debt.
M
K
Exact
date
is,
it
doesn't
create
problems,
it's
just
that
you
know
it
proposes
an
alternative
change
and,
and
it
we
we
can
always
integra
if
this
ship,
if
the,
if
this
shipped
already
that's
fine,
it's
something
that
we
recently
found
to
that.
We
find,
let's
say
a
better
way
to
fix
it,
because
this
issue,
fixing
as
it
was
within
the
security
considerations
that
we
were
accepting
before
so
we
were
fine
and
comfortable
with
that.
There
was
a
we
found
that
there
was
a
better
way
to
implement
what
what
was
proposed.
M
N
I
I
think
in
the
security
consideration
of
the
of
the
feed,
there
is
like
a
mention
about
this
this
this
issue
that
we
know
is
caused
by
this
flip,
that
is,
power,
table
inflation.
We
mentioned
two
fixes
one
and
two
like
we
thought
one
I
mean
one
is
very
easy
to
implement,
but
we
didn't
see
some
problems,
and
so
we
have
to
go
with
two.
That
is
a
bit
more
complicated
and
it's
more
time
for
brainstorm.
Brainstorming
about
the
implementation.
I
think
this
is
the
situation.
A
Of
the
forward
that
were
proposed
in
the
issue,
which
is
ship,
the
the
fix
to
the
fip
that
we
landed
on
and
then
identify
what
what
the
patch
should.
A
If
people
are
going
to
go
back
and
keep
discussing
it
note
that
the
longer
that
we
do
this,
the
longer
miners
are
in
an
unhappy
state
where
you
know
they
they
may
get
into
feed
and
then
end
up
unable
to
recover
quickly
and
accrue
more
and
more
debt.
K
Right
so
strategically
it's
up
to,
I
guess
us
and
the
implementers
to
to
to
say
in
order
to
solve
the
short-term
problem,
we
could
merge
this
and
then
we
plan
to
do
a
future
upgrade
which
which
avoids
the,
which
is
like
a
much
better
update.
That's
also
a
path
which
is
a
it
is
also
a
path.
It's
just
that
this
was.
The
idea
was
to
avoid
two
different
upgrades.
K
And
also
there's
a
co.
An
intermediate
sorry
is
to
avoid
an
intermediary
period
where
there
are
some
new
concerns
that
we
bring
on
the
power
table.
They
are
not
really
exploitable.
K
And
if
they
were
to
be
exploitable,
we
can
always
do
an
hard
forks,
hard
fork
and
fix.
K
A
A
I'm
going
to
if
you
can
confirm
that
this
isn't
in
the
current
state
upgrade
then
cool,
then
we'll
just
bump
this
back
to
draft
again
and
others
can
go
back
to
discussing
this
on
the
issues.
K
L
I'm
gonna
ask
on
slack.
A
L
G
A
O
Sure
I
could
do
that
latest
development
is.
Work
is
finishing
on
the
project
tbx
command,
which
is
gonna,
allow
us
to
boost
the
variant
coverage
of
all
existing
vectors
to
all
protocol
versions.
So,
basically,
what
this
command
does
is
it
takes
a
vector
that
has
specific
variants
and
you
give
it
a
target
protocol
version
that
you
want
to
rebase
that
vector
against,
and
then
it
runs
it
and
if
it
succeeds,
it
updates
and
that's
the
variant
in
place.
Saying
hey
this
vector
is
also
valid
for
this
version.
O
O
So
there's
some
trick
trickery
to
play
with
kind
of
like
some
clever
stuff
that
we
can
do
like,
for
example,
creating
a
synthetic
state
tree
with
the
actors
that
are
or
that
are
present
in
the
original
state
tree,
putting
them
into
that
new
state
tree
which
only
contains
those
actors
and
like
no
more
nodes
and
then
running
the
migration
of
that
state
tree,
allowing
it
to
fall
back
to
an
existing
client
that
has
any
cids
that
are
part
of
that
state.
O
That
need
to
be
migrated,
and
then
we
run
the
vector
with
against
the
new
state
tree
and
assert
against
the
existing
post
conditions.
This
is
kind
of
like
a
trick
to
play
and
it
requires
manual
review
of
the
result,
but
it's
a
nice
automation.
Essentially,
it
would
require,
in
any
case,
a
manual
a
manual
review
of
the
results,
because
gas
cost
might
change.
I
think
the
receipt
should
be
the
same
unless
the
functionality
like
the
the
status,
the
exit
code
should
be
the
same
unless
the
functionality,
the
the
underlying
functionality,
actually
changed.
O
Between
versions,
in
which
case
that
the
test
vector
is
like,
is
not
valid
right.
So
that's,
basically
what
I'm
working
on
and
like
building
a
lot
more
intelligence,
so
there's
there's
a
basic
project
command
that
is
already
super
useful,
but
I'm
building
more
intelligence
into
it.
By
doing
these
tricks
to
see
how
much
more
coverage
we,
how
much
more
reuse
of
existing
extractive
vectors
we
can
achieve
by
transplanting
them
using
clever
tricks
like
this.
O
Besides
that,
I'm
going
to
run
another
sweep
against
the
latest
chain,
epochs
just
waiting
on
some
sentinel
data
availability
to
identify
the
correct
messages
to
extract
from
from
chain
so
that
we
can
have
another
refresh
of
the
corpus.
O
A
Awesome
two:
next
things
are
to
review
open,
fit
pr's
and
reviews
to
changes
in
the
fit
process
for
open,
fit
pr's.
There's
one
pull
request
from
the
spec
actors
team
around
batching
sector
pre-commit,
but
it
hasn't
yet
been
merged.
There's
a
couple
of
open
comments
on
it.
Nikola
you
were
the
generator
of
a
set
of
these
comments.
A
A
The
batch
sector,
pre-commit
fip-
that
is
still
it's
still
a
draft.
We
don't
have
any
prs
or
we
don't
have
any
draft
fips
that
have
been
merged.
Yet
nice
apr.
A
My
question
to
you,
since
we
don't
have
alex
in
here
for
time
zone
reasons:
okay,
it's
from
your
vantage
point.
Should
this
one
be
merged
or
is
this
kind
of
still
still
collecting
feedback
and.
K
It's
still
collecting
feedback,
because
there
is
a
let's
say
that
there
is
a
conversation
between
zx
and
I
that
we
need
to
resolve
and
and
and
and
and
then
maybe
this
is
a
contentious,
a
contentious
one.
In
other
words,
we
would
like
to
just
to
clarify
this
issue.
25.
K
So
yeah,
unfortunately,
due
to
the
comments
in
25,
it's
still
a
bit
contentious
and
we
need
to
have
another
chance
to
convince
zx
and
or
or
alex
that
this
is
a
that.
This
is
a
good
idea.
I
mean
conversation
are
happening.
K
This
is
a
unclear
how
priority
is
this
in
comparison
to
other
things
that
may
come
up,
but
if
people
have
questions
on
this
one
I'm
happy
to
take
them.
I
let
me
say
that
tldr
is
the
following:
is
that
this
could
benefit
some
small,
some
large
miners
that
do
operation
in
bulk.
So
the
question
is
in
practice:
they
will
benefit
them
very
little.
It's
on
a
one-off
cost,
and
the
other
issue
is
that
this
could
help.
K
This
will
allow
miners
to
see
to
onboard
more
storage,
which
is
always
something
that
we
need
to
be
careful
with,
because
if
someone
can,
if
miners
can
onboard
more
storage,
I
think
it's
fine,
but
there
are
some
people
there
raising
problems
that
could
come
with
it,
which
we
need
to
understand
before
doing
such
a
large
change.
It's
a
small
change,
but
it's
a
large,
potentially
large
impact.
M
Yeah
the
changes
in
the
dynamics
on
the
network
and
I
think,
like
whenever,
there's
a
change
that
may
potentially
impact
that
we
should
take
more
time
to
think
through
the
different
impacts
and
my
understanding
is
the
next
release
would
be
in
january.
So
I
think
we
have
some
time
to
iterate
on
this
issue.
K
Yes,
exactly,
that's
that's
a
good
way
of
thinking.
I
think
the
the
this
wasn't
clear
to
me
that
until
january
I
mean
maybe
it
was.
But
now
it's
very
explicit
and
having
a
timeline
which
is
until
january,
gives
us
puts
it
in
a
different
mindset
of
doing
right
things
with
more
tests
and
and
that,
like
issues
like
other
issues
that
we
did
before
that
were
fine,
but
issue
like
this.
There
are
more
contentious,
they
mean
they
will
need
like
more
simulation
before
getting
proper
approval.
D
Yeah,
there
is
one
question
about
this
and
I
guess
that
yeah
and
this
this
change
may
may
be
helpful
for
the
yeah
for
the
gas
phase.
Yeah,
basically,
actually
yeah
keep
lower
yeah,
perhaps,
and
I'm
not
so
sure,
yeah
because
of
the
message
number
will
be
lower
and
yeah
was
it
be
helpful
for
the
yeah,
because
currently
the
the
base
phase
is
very
high
and
there
are
many
manners
want
to
yeah
sending
more
sectors
the
network,
okay,
yeah.
D
M
D
M
Definitely
you'll
be
very
welcome
for
minors
for
sure,
and
but
I
also
feel
like.
Basically
it's
a
social
problem
more
than
a
technical
one,
because
miners
have
full
control
over
what
base
view
should
be
right
and-
and
so
it's
more
like
a
social
problem.
Sometimes
you
are
being
short-sighted
right
now,
in
my
opinion,
doing
things
that
may
benefit
some
minor,
but
it's
actually
hurtful
for
themselves
in
the
long
term,
but
they
don't
realize
that.
So
I
think.
M
D
Yeah,
I
think
that
is
of
thing
but
yeah.
Technically.
I
would
think
that
yeah
this
will
improve
the
tps
right,
correct.
M
Correct
and
at
the
same
time
I
think
another
concern
there
is,
I
think
we
see
about
16
petabytes
a
day.
That's
a
lot
of
supply,
but
we
don't
have
much
like
the
storage.
Tooling
is
still
like
lacking.
We
don't
have
much
demand
on
the
network
and,
I
think,
just
giving
networks
some
more
time
to
grow.
The
other
side
before
we
pick
up
the
supplier
game
might
also
be
useful
for
the
network
in
the
long
run
in
both
the
short
run
in
the
long
run.
Yeah.
K
Yeah,
and
also
to
express,
like
my
opinion,
which
is
very
similar,
but
on
a
different
angle,
to
you
stephen,
is
that
in
practice
this
change
would
decrease
the
gas
cost
for
pre-commit.
So
in
theory,
you
will
have
a
less
in
in
theory,
you
may
get
blocks
being
less
full,
but
in
practice
people
may
take
advantage
of
this
and
just
seal
more,
and
so
it
may
have
no
impact
on
base
fee.
It
will
only
have
an
impact
on
improving
the
the
overall
cost
of
adding
new
storage,
but
it
will
not.
K
Yeah,
I
I
think
miners
may
be
very
myopic
about
this
and
they
will
say:
oh
it
costs
less.
Let
me
seal
more,
but
then
in
practice
they
end
up
doing
a
lot
more
proof
commits
which
are
a
heavy
weight
on
the
base
fee.
So
I
would
say
this
is
a
good.
This
is
a
good
change.
I
would
rather
see
before
this
something
like
a
batch
proof
commit
or
something
like
that.
K
That
would
make
the
cost
or
having
those
two
changes
coming
at
the
same
time,
so
that
maybe,
if
miners
are
willing
to
pay
more,
that's,
okay,
sorry
paying
the
same
and
and
selling
more
that's
okay
as
long
as
they
don't
they
don't
they
don't
clock
the
chain
with
weird
behaviors.
So
my
proposal
is:
let's
build
in
better
tooling:
let's
get
pre-commit,
let's
get
proof
commit
patched
both
of
them
and
then
try
to
get
them,
maybe
all
in
the
same
pr.
D
A
D
A
Of
batching
improvements
yeah,
definitely
I
think
ayush
was
showing
a
screenshot
of
someone.
Who'd
done.
I
don't
even
know
how
many
published
storage
deals
one
after
the
other
after
the
other
after
the
other,
and
it's
like.
Oh
no.
M
E
Yeah,
it's
not
exactly
trivial
due
to
how
we
discovered
the
ladies.
What
is
doable
yeah,
definitely
like.
We
should
try
to
have
it
in
the
next
version.
A
Maybe
cool
so
we
are
officially
off
our
agenda
since
I
don't
think
we
had
any
prs
to
the
fit
process
itself.
Is
there
anything
else
that
folks
wanted
to
talk
about
or
questions
for
each
other.
G
E
E
E
E
E
G
We
are
only
disallowing
sending
to
it.
Wait.
E
E
H
A
C
A
C
C
Gorgeous
actors-
v1,
there's
so
much
detail
to
it.
It's
it's
quite
a
lot.
A
A
I
think
all
right
well
we'll
start
taking
notes
on
this
in
future.
In
future
meetings
come
with
your
exact
current
height
synced
to
and
we'll
put
it
in
the
notes
so
that
we
can
have
our
unofficial
leaderboard
awesome
cool.
Well,
that's
it
for
today,
then,
thank
you
guys
so
much
happy
thursday
and
we'll
see
you
guys
after
the
american
thanksgiving
holidays.
A
I
think
ayush
is
going
to
be
leading
meetings
going
forward
from
here
to
save
me
part
of
the
time
zone
stuff.
So
thanks,
east,
that's
good
cool,
happy.