►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
are
inside
of
consensus,
mesh
and
very
happy
to
be
supported
by
the
farcoin
foundation,
so
we're
a
team
of
software
developers,
researchers,
problem
solvers
and
we
specialize
in
state
channels
and
payment
channels
and
yeah
I
mentioned
we're
problem
solvers.
What's
the
problem
we're
trying
to
solve?
Well,
what
we
want
to
do
is
drive
adoption,
particularly
of
web
3
protocols
by
allowing
for
better
incentivization
for
participants.
A
So
how
do
we
incentivize
people
well?
I
believe
that
service
providers
should
be
getting
paid
by
users
and
that's
not
currently
happening,
and
it's
not
happening
enough
and
I.
Think
it's
a
necessary
step
to
give
the
retrieval
market,
for
example,
for
it
to
live
up
to
its
name
and
here's
another
quote
from
Juan
on
Monday.
He
said:
users
will
select
convenience,
so
better
incentivization
for
us
means
more
convenience
for
the
user.
It
means
lower
latency
and
lower
cost
for
the
transactions
they
want
to
make
and
that's
where
our
technology
can
come
in.
A
So
here's
a
diagram
I
stole
from
Patrick
credit
to
him
for
making
a
nice
diagram.
It
shows
the
Falcon
ecosystem,
I,
suppose
and
yeah.
Our
thesis
is
that
if
we
had
a
low-cost
low
friction
way
to
send
filecoin
around,
then
we
would
really
be
turbocharging
these
markets,
but
we
need
to
do
that
in
a
way.
Obviously,
that's
trust,
minimized
and
scalable
we're
not
about
to
install
some
centralized
service
to
make
this
nice
we've
got
to
keep
all
the
powerful
decentralization
properties
that
we
know
and
love
in
web
3..
A
So
one
way
of
doing
that-
and
this
is
actually
an
existing
mechanism
that
you
will
find
inside
the
firecoin
spec-
is
to
use
micropayments
and
they're
an
amazing
way
of
minimizing
trust.
Obviously,
there's
different
mechanisms
for
minimizing
trust
but
I
believe
micropayments
is
a
very
general
way
of
doing
it,
as
particularly
for
things
like
retrieval.
A
So
how
does
it
work?
You
have
a
service
provider
on
the
left
there
and
a
service
consumer
on
the
right.
You
could
call
them
the
payee
and
the
payer
or
the
provider
and
the
client
names
don't
really
matter
too
much,
and
in
this
example,
the
service
provider
is
streaming
bits
of
a
file
to
this
consumer
and
in
return,
they're
streaming
money
back
in
the
other
direction,
and
why
does
this
help
minimize
trust?
A
Well,
if
the
service
provider
stops
providing
a
service,
stop
sending
the
files,
then
this
guy
can
just
stop
sending
the
money
and
vice
versa.
If
you're
not
getting
paid,
you
just
stop
doing
the
service.
So
it's
a
kind
of
soft
way
of
verifying
the
service.
You
don't
have
to
do
any
cryptographic,
proof
or
anything
like
that,
and
that's
what
makes
it
very
widely
applicable,
particularly
to
Services,
which
are
provided
sort
of
continuously,
which
retrieval
is
one
of
those
one
of
those
use
cases.
A
So
could
you
do
microfayments
on
chain
on
L1
not
really
but
like?
If
you
tried
it
would
look
a
bit
like
this,
so
we've
got
our
oh.
This
is
not
very
visible.
Is
it
but
we've
got
three
actors
up
here:
the
PE
the
pair
with
the
star
and
the
L1
blockchain
could
be
far
coin.
Main
net
could
be
wallaby
if
it
was
working
and
yeah.
This
was
how
it
would
look
like
for
one
retrieval
deal.
You
could
send
money
I've
chosen
to
split
this
deal
into
four
payments.
A
In
reality
you
might
want
to
do
a
hundred
or
a
thousand
payments
and
make
them
really
granular
to
reduce
that
amount
of
trust.
If
you
like
the
more
payments,
you
have
per
deal,
the
less
trust
you
need,
which
is
what
we're
shooting
for,
and
if
you
did
this
on
the
Chain
as
I
said
it
would
be
super
painful.
Each
payment
you'd
have
to
wait
at
least
one
block
time
about
30
seconds.
It's
in
big,
bold,
red
letters
there
that
that
is
painful
and
it's
expensive,
and
that's
not
what
we
want
to
do.
A
It's
so
painful
and
expensive
that
you
just
wouldn't
use
micropayments
right.
You
just
wouldn't
go
there.
So
how
about
what
I
call
vanilla
payment
channels?
This
is
very
close
to
also
what
you'll
find
in
the
far
coin,
spec
on
payment
channels,
it's
not
quite
as
good
as
the
file
coin
payment
channels,
but
it
gives
you
an
idea.
So
what
happens
here
is
the
payer
puts
all
of
the
money
that
they
are
willing
to
spend
in
total
onto
the
chain
in
a
special
contract
or
a
special
actor
and
then
off
chain.
A
They
send
signed
vouchers
directly
to
the
payee,
and
that
is
incredibly
low,
latency
operation
as
many
times
as
they
like,
and
when
that
interaction
is
finished.
Maybe
the
retrieval
deal
has
been
completed.
The
payee,
the
retrieval
provider,
if
you
like,
can
take
the
best
voucher
that
they
received.
Take
it
back
to
the
chain,
unlock
the
money
and
they've
been
paid,
and
let's
say
the
retrieval
deal
stopped
halfway
through
then.
Maybe
they
only
get
half
of
the
money
and
that's
that's
the
the
beauty
of
micropayments.
A
So
you
can
see
the
separation
in
time
scales.
Here
we've
gone
from
something
that
takes
30
seconds
down
to
something
which
I'm
claiming
can
be
done
on
a
few
milliseconds
time
scale,
and
we've
got
another
talk
directly
after
this
one
from
Alex
and
he's
going
to
go
into
some
depth
about
trying
to
see
if
the
numbers
that
I'm
parroting
out
are
actually
accurate
and
lived
up
to
by
our
software
that
we're
building.
A
A
A
A
A
A
Those
are
the
regular
channels
which
are
funded
by
deposits
on
the
Chain
okay
and
they
allocate
money
to
Alice,
i1
and
I2
are
intermediaries
and
Bob.
These
are
the
people
who
want
to
have
a
direct
connection,
but
don't
obviously
a
and
i1
are
connected.
I
want
to
lie
to
a
connected.
I2
and
B
are
connected,
so
it's
very
similar
to
that
hclc
scenario
in
terms
of
the
connectivity
that
exists.
It's
just
a
different
kind
of
diagram
to
to
describe
the
same
situation
and
what
we
do
is
we
just
divert
money.
A
Instead
of
just
giving
money
to
the
people
in
the
channel,
we
now
give
money
to
a
new
channel
V,
which
exists
entirely
off
chain,
and
these
black
lines
mean
that
that
channel
will
pay
out
to
these
parties
and
the
dashed
line.
It's
very
similar,
it's
just
a
special
kind
of
allocation
that
we
need
to
do
in
our
system
to
make
this
safe.
If
you
can
imagine
these
lines
get
plumbed
in
in
different
orders,
we
need
to
make
sure
that
if
it
stops
halfway
through,
it's
all
still
safe,
that's
probably
more
detail
than
you
need.
A
The
main
takeaway
from
this
slide
is
that
virtual
channels
exist
entirely
off
chain
and
they're
funded
by
existing
channels,
and
the
big
Advantage
they
have
is
that
they're
going
to
scale
better
so
back
to
hclc
is
just
as
comparison.
It's
a
similar
diagram
as
before
we've
got
the
payee
the
pair
and
the
blockchain.
But
now
we've
got
this
new
party,
the
intermediary
and
they're
there
to
help
people
do
payments.
A
So
now
we
have
to
deposit
in
to
the
chain
and
that's
the
payer
and
the
intermediary
they're
entering
a
state
Channel
network,
now
they're
not
concerned
with
the
retrieval
deal
yet
they're.
Just
setting
up
the
system,
then,
when
a
retrieval
deal
starts
in
an
HDL
C
system,
the
player
like
I
said
before
is
going
to
send
money
to
the
intermediary
and
the
intermediary
is
going
to
send
it
to
payee,
and
that
should
happen
atomically
using
the
the
hash
locks,
and
that
can
happen
many
times
and
that's
really.
A
We
want
to
build
a
really
scalable
State
Channel
network,
and
here,
if
you
recall,
we're
doing
micro
payments
and
we
want
to
do
as
many
micropayments
as
possible
to
reduce
trust.
So
if
we
want
to
do
multiple
micropayments
per
second,
then
the
intermedia
has
got
a
lot
of
load
on
them.
They're,
processing,
a
lot
of
messages,
they're
doing
crypto
like
signing
hashes
and
things
like
that,
and
that's
not
great
so
with
a
virtual
Channel
Construction.
A
It
looks
like
this
very
similar
again,
the
pair
and
the
intermediary
have
entered
the
state
Channel
network
by
depositing
their
funds
early
on
that's
completely
separate
from
retrieval
deals
and
then,
when
they
decide
that
they
want
to
participate
in
a
retrieval,
deal,
the
payer
and
the
payee
and
the
intermediary.
They
execute
this
sort
of
it's
not
really
a
black
box.
A
And
now
the
the
payments
are
like
back
to
the
original
story,
almost
they're
direct.
They
go
straight
from
the
service
consumer
to
the
service
provider.
We
can
do
them
very
high
frequency
and
have
very
low
Trust
and
again
once
it's
finished,
we
can
unwrap
with
a
virtual
defund
protocol
and
go
and
do
more
retrieval
deals
and
we
only
need
to
go
back
to
the
chain
very,
very
infrequently.
A
So
this
virtual
fund
protocol
is
where
all
of
our
cleverness
all
of
our
complexity,
lives
and
Alex
is
going
to
talk
a
bit
later
on
about
how
fast
this
may
or
may
not
be
at
the
moment
with
our
current
iteration
of
our
software.
My
claim
is
that
it's
around
100
milliseconds.
So
if
we
think
back
to
what
harm
was
saying
earlier
about
content
delivery
networks
and
having
great
experience
for
the
user,
we
obviously
don't
want
payment
channels
to
slow
everything
down.
A
A
So
if
you
want
to
know
the
real
details
of
what
I
just
said,
look
inside
that
green
box,
you
can
go
to
our
brand
new
documentation
website.
Docs.Statechannels.Org.
We're
quite
pleased
with
this:
it's
got
a
lot
of
detail.
It
has
FAQs
code
Snippets
diagrams
and
more
so.
Please
check
that
out.
If
you're
interested.
A
And
now
I'm
going
to
switch
to
talking
about
progress
towards
this,
this
dream
of
virtual
payment
channels,
so
some
things
we've
we've
we've
gotten
over
the
line.
Very
recently,
we've
finished
our
on-chain
implementation,
so
those
are
contracts
written
in
solidity
that
we've
been
working
on
for
a
long
time.
We
had
some
help
from
colleagues
at
yellow
who
are
building
Financial
trading
platform.
A
They
helped
us
build
out
the
Unchained
component,
and
one
thing
I'd
like
to
highlight
here
is
that
I've
got
a
big
picture
of
gas
over
here
and
what
we
like
to
do
in
our
team
is
every
time
we
make
a
change
to
the
on-chain
implementation
of
our
system.
We
check
in
important
gas
consumption
numbers
alongside
it
and
that
is
enforced
by
our
continuous
integration
checks.
A
So
at
any
given
time,
we
can
tell
you
exactly
how
expensive
it's
going
to
be
to
do
a
deposit
to
withdraw
your
funds
from
the
state,
Channel
network,
or
even
to
walk
the
unhappy
path
and
retrieve
your
funds
when
things
go
wrong.
So
that's
something
that's
pretty
important
to
us.
We've
spent
time
again
trying
to
drive
costs
down
for
the
user
by
optimizing.
A
Our
source
code-
and
it
will
be
really
interesting,
I'm,
going
to
talk
in
a
minute
about
the
fem,
the
filecoin
virtual
machine,
to
see
how
these
numbers
change
and
to
see
if
there's
any
interesting,
increases
or
decreases
in
costs.
As
we
move
from
like
a
pure
evm
chain
to
a
far
floor
in
virtual
machine.
A
Another
big
thing
that
we've
been
working
on,
which
is
like
almost
finished
I,
would
say:
is
our
off-chain
go
Nitro
client?
So
this
is
a
piece
of
software.
It's
a
library
really
written
in
go.
You
can
see
the
API
there.
It's
designed
to
look
after
your
whole
state
Channel
story,
so
it
has
API
methods
like
create
Ledger
Channel,
which
is
our
name
for
your
initial
deposit
into
the
system,
and
it
has
another
API
method
called
create
virtual
Channel,
and
when
you
call
that
method,
our
client
software
will
do
all
of
this
stuff.
A
What
I've
shown
on
the
right
here
is
an
interesting
execution
trace.
It
looks
a
little
bit
like
those
diagrams
I
showed
you
before,
and
this
is
something
that
we
generated
by
instrumenting
our
code
to
see
if
it
was
doing
what
we
thought
it
was
doing.
So
we
can
see
messages
being
passed
between
various
actors
here
and
the
good
news
is
it.
It
went
mostly
to
plan
in
terms
of
thinking
about
the
correctness
of
what
we're
doing
again.
A
I'll
refer
you
to
Alex's
talk
which
is
coming
up
where
we've
really
kind
of
ramped
up
how
we're
trying
to
battle
test
our
system
and
make
sure
it
behaves
the
way
we
want
it
to
another.
Big
win
we
had
recently
is:
we
were
a
research
paper
in
collaboration
with
the
perine
team,
now
called
polycrypt.
These
were
the
guys
who
invented
virtual
channels
and
they
helped
us
refine
them
even
further
into
what
I've
just
told
you
about
today,
and
one
of
the
important
refinements
was
what
we
call
a
flat
multi-hop
virtual
Channel.
A
A
So
you've
got
existing
connections
here
and
you
use
those
to
set
up
virtual
channels,
and
then
you
use
those
virtual
channels
as
the
previous
layer
and
you
keep
going
on
and
the
problem
with
that
is
you
end
up
with
a
lot
of
channels,
a
lot
of
connections
and
it's
costly
and
not
very
nice,
to
use,
and
in
this
paper,
which
is
called
satp
for
stateful
asset
transfer,
protocol,
simple
and
scalable
protocol.
We've
flattened
that
all
out,
so
we
can
have
a
really
lightweight
lean
construction.
A
Now
for
multi-hot
payments
and
I'm
pleased
to
say,
not
only
have
we
figured
out
the
theory
for
this,
we've
actually
implemented
it
in
our
client
code
and
we've
tested
it
and
it
works
surprisingly.
Well
and
again,
Alex
will
tell
you
more
about
that
so
kind
of
stoked
to
get
that
working
and
Colin
actually
put
in
a
big
effort
to
engineer
that
in
the
last
few
weeks.
So
thanks
to
him
another
big
win
that
we
did
recently
was
integrating
with
f
VM.
A
So
here's
a
couple
of
screenshots
explaining
that
in
a
little
bit
more
detail,
so
we
have
something
we
call
the
fevm
chain
service.
Now
our
software
works
with
injected
dependencies.
So
it's
very
easy
for
us
to
swap
in
and
out
change
services
for
different
back
ends:
ethereum
farcoin
other
systems,
so
we
just
wrote
a
new
change
service
and
we
plugged
it
in
and
it
mostly
worked,
which
is
amazing
and
the
long
time.
A
The
long-term
sort
of
goal
is
to
actually
get
rid
of
this
fevm
chain
service
because,
as
Sarah
said,
you
know,
the
file
formed
virtual
machine
in
time
will
look
completely
transparent.
We
hope
and
look
just
like
another
ethereum
endpoint,
so
we
won't
have
to
even
worry
about
it
being
following
it'll
look
just
like
ethereum
to
us,
but
in
the
meantime,
before
that,
before
we
get
to
those
Sunday
Uplands,
we've
had
to
put
in
a
few
shims
and
workarounds
to
get
stuff
working.
A
So
if
you're
thinking
of
doing
a
similar
kind
of
thing
deploying
to
wallaby
in
an
in
the
short
term,
please
get
in
touch
with
us,
because
we've
built
up
a
little
bit
of
experience
now
with
working
around
some
of
the
quirks.
So
as
an
example
of
that
events
are
not
something
that
are
commonly
supported
and
our
system
relies
on
events.
We
need
our
go:
Nitro
software
to
watch
the
chain
and
pick
up
events
like
deposits,
and
things
like
that.
That's
not
currently
supported,
so
we
built
a
little
shim
for
it.
A
So,
instead
of
listening
for
events,
we
just
pull
the
chain
and
we
say:
what's
how
much
money
is
on
chain
against
this
Channel?
And
when
we
see
that
change
we
can.
We
can
move
forward.
So
that's
a
little
shim.
We
built
that
worked
really
well
and
Mike.
Kirzner
who's,
not
with
us
at
the
moment,
unfortunately
deserves
a
lot
of
credit
for
getting
that
to
work.
A
So
yes,
here's
our
kind
of
proof
that
it
was
working
a
few
days
ago.
This
at
the
back
here
is
a
logs
from
our
test
runs.
They
won't
make
a
lot
of
sense
to
you,
but
they
make
sense
to
us
and
it
shows
our
full
end-to-end
system
working
on
fire
coin
wallaby
test
net,
and
just
as
proof
of
that,
we've
shown
the
glyph
blocking
story
here,
and
you
can
see
our
deposits
going
in
to
our
contracts
that
we
have
successfully
deployed
so
very,
very
pleased
about
that.
A
A
We
need
to
work
on
cheaply
rebalancing
collateral
in
the
network
if
you've
kind
of
Switched
on
you'll
realize
that
all
the
money
at
the
moment
is
going
to
flow
from
clients
to
Providers
and
the
clients
will
have
no
money
left
to
do
payments
and
the
providers
will
want
to
extract
their
money
at
the
moment.
That
is
still
a
bit
of
a
painful,
slow
process.
So
we're
going
to
try
and
smooth
that
out
and
make
it
easy
to
rebalance
the
collateral
walking
the
unhappy
path
so
in
state
channels
and
payment
channels.
A
The
main
problem
you
come
across
is
when
the
people
you're
interacting
with
go
offline,
and
what
we
have
to
have
is
a
recovering
mechanism
for
that
which
involves
going
back
to
the
chain,
and
that
is
all
implemented
on
chain.
But
it's
not
implemented
off
chain
in
our
software.
So
we
need
to
get
that
working,
we're
looking
at
crash
tolerance,
as
I
mentioned
before,
and
data
persistence,
we're
looking
into
theme
models
for
intermediaries,
I've
kind
of
waved
my
hands
and
introduced
this
intermediary
who's
doing
things
for
free
at
the
moment.
A
A
How
can
you
get
involved
in
what
we're
doing
well,
if
you're,
building
something
in
this
ecosystem,
retrieval
provider
or
client
or
you're
building?
Another
application,
you
think,
might
benefit
from
virtual
payment
channels
or
you
just
like
to
contribute
to
our
project
in
any
way.
We'd
love
to
hear
from
you
so
reach
out
on
my
email
address
here.
Please,
and
that's
really.
B
Hey
it's
Andrea
from
Legacy
again,
so
when
you
make
the
Well,
when
the
person
makes
a
deposit,
where
exactly
does
the
money
go
and
are
there
any
regulatory
implications,
because
essentially
your
escort
service
right
for
that
money?
And
you
and
you
do
transaction
behalf
of
the
client
so
I
could
just
imagine
that
somebody
has
to
say
something
you
need
a
license
for
that.
Have
you
looked
into
that.
B
A
It's
it's
definitely
a
smart
contract.
So
in
our
system
we
have
a
Singleton
contract
which
we
deploy
as
a
team.
So
these
users
don't
need
to
worry
about
it.
We
call
it
the
adjudicated
contract
and
it
will
hold
all
of
the
funds
for
all
of
the
on-chain
channels
in
the
entire
system
and
we
spent
a
long
time
securing
that
making
it
you
know
safe
to
deposit
into
and
thinking
about
under
which
conditions
the
money
can
be
released.
So
it's
non-custodial
system,
it's
fully
trustless
smart
contract
that
manages
that
answer.
B
A
A
really
interesting
question:
we've
not
thought
a
whole
bunch
about
it
and
I'm,
not
a
lawyer,
but
we
and
you
know
I'd-
hope
that,
because
we're
not
actually
being
custodians
of
the
money
ourselves,
we
wouldn't
have
to
worry
about
that.
What
we
can
do,
if
we
were
worried
about
it
is
there
are
other
architectures
where
we
put
the
escrow
contract
in
the
hands
of
the
users
and
they
can
that's
how
file
coin
payment
channels
work
a
bit
more
like
that.
So
there's
a
new
contract
for
every
interaction
and
the
infrastructure
team.
A
B
A
A
This
is
something
that
Colin
has
been
thinking
about
on
our
team,
so
we've
got
a
few
ideas
of
putting
the
capital
to
work
more
and
and
related
to.
That
is,
as
you
say,
we've
kind
of
built,
really
a
zero
trust
system
at
the
moment.
So
that
means
a
lot
of
capital
needs
to
be
locked
up
because
we
have
really
powerful
invariants,
like
you,
can
always
get
your
money
back,
irrespective
of
the
actions
of
any
other
party.
There's.
A
very
strong
statement
requires
a
lot
of
capital
to
be
locked
up.
A
If
we
were
willing
to
relax
that
a
little
bit,
as
you
say,
using
a
little
bit
more
trust
building
up
relationships,
then
we
can
improve
the
story.
We
can
lower
the
capital
requirements,
we
can
reduce
fees,
but
that's
a
judgment
call
about
how
the
trade-off
you
want
to
make
between
trust
and
and
efficiency.
Hey.
C
Thank
you
for
the
presentation
tons
of
questions,
one.
If
you
could
tell
me
what
are
the
aspects
you
do
specifically
to
make
it
safe,
like
I'd,
love,
to
know
any
details
on
that
and
then
the
second
one
is
when
it
comes
to
custodial
like
abilities.
Does
the
virtual
Channel
act
as
a
custodian
like
of
either
token
smart
contract
Etc
and
like
do
you
connect
into
most
custodial
Services
digital
asset
providers,
like
any
detail
of
how
you
can
connect
into
multiple
different
digital
assets
like
either
holders
and
services
would
help
okay.
A
Thanks
yeah,
what
do
we
do
to
make
the
system
safe?
We've
done
a
bunch
of
stuff
on
the
on
chain
side,
so
we've
done
things
like
TLA
plus
modeling.
You
may
not
know
about
that,
but
it's
it's
a
kind
of
exhaustive
testing
framework
where
we
can
look
at
things
like
front
running
and
really
check
that
different
on-chain
transactions
coming
in
different
orders,
don't
lead
to
unexpected
problems
with
our
contracts.
Previous
revisions
of
our
contracts
have
been
security
audited
by
consensus
diligence.
So
that's
another
option
we
have
for
making
the
whole
system
secure.
A
Your
other
question
was
about
custody
again.
So
really
what
I
would
say
is
that
that
smart
contract
is
the
custodian
of
the
Unchained
funds
and
the
individual
actors
using
our
software
or
anyone
else
who
wants
to
build
software
to
our
specification,
they're,
the
custodians
of
the
secrets
and
the
keys
that
can
be
used
to
unlock
the
funds
on
chain,
so
there's
no
real
other
custodians.
In
the
picture
you
hold
on
to
your
vouchers,
your
payment
vouchers,
for
example,
you
can
use
those
to
unlock
funds
on
chain.
Does
answer
your
question
kind
of
okay.
C
Sort
of
a
little
bit
because
a
lot
of
times,
especially
from
the
regulatory
perspective
too,
the
actual
owner
of
the
asset,
let's
just
say
you
had
co-located
funds
with
someone
that
was
in
Terrorist
financing
or
something
like
that
right
yeah.
If
someone
were
to
go
to
you
and
say,
hey
I,
just
I
cut
my
my
my
funds
in
magmo,
and
you
know
they
were
the
custodian.
Would
you
be
how
liable
would
the
user
be
held
liable
like?
Where
does
the
liability
really
come
to
or
go
to
yeah.
A
I'll,
just
real,
quick
and
then
I
think
Mark
to
wrap
up
but
like,
as
I
said
before,
I'm,
not
loyal,
so
I
don't
really
know.
But
I
would
like
to
think
that
because
we
don't
have
any
power
of
custody,
the
custody
is
in
the
power
of
individual
users
and
the
smart
contract
code
being
written
correctly.
I
would
hope
that
we
wouldn't
be
in
hot
water
for
that
yeah,
but
we
can
talk
more
about
that
in
the
break.
Maybe
thanks
for
your
question.