►
From YouTube: Retrieval Market Builders Demo Day - Magmo, 25 May 2022
Description
Every other week, the Retrieval Market Builders get together to share progress in their projects in a demo format. We want to sincerely thank all of our collaborators for demoing their developments and helping to improve the FIL Retrieval Markets one demo at a time.
May 25, 2022, Demo Day: In this video, you can find quick demos from -
• Magmo
A
Hello
and
welcome
to
this
week's
retrieval
market
demo
day.
Today's
date
is
wednesday.
The
25th
of
may
2022..
We've
got
a
great
schedule
today.
We've
just
got
the
one
one
speaker
which
is
george
knee
from
magma
speaking
about
the
multi-top
payment
channels
for
the
far
coin,
retrieval
market.
If
you
have
any
questions,
please
add
them
to
the
slack
thread.
So
we
have
them
into
perpetuity
and
over
to
you,
george.
B
Thanks,
patrick
yeah,
as
said,
I'm
george,
I'm
part
of
the
magma
team
and
we've
been
working
on
multiple
payments
for
the
popcorn
approval
market.
So
I'll
just
jump
straight
into
it.
I'm
hoping
to
keep
this
kind
of
informal,
so
I'm
happy
to
be
interrupted
with
questions
as
we
go
through
or
through
the
chat,
whatever
you'd
like
to
do,
and
that's
it
from
your
next
slide.
B
We've
got
some
of
the
team
on
the
call.
Today,
andrew
and
colin,
I
can
see
we're
five
developers
inside
of
consensus.
Mesh
we've
been
working
on
state
channels
for
a
number
of
years.
We've
maintained
estatechannels.org
site
and
a
lot
of
our
code
you'll
find
under
that
github
namespace,
so
we've
been
working
with
lots
of
other
state
channel
teams,
mostly
in
the
ethereum
ecosystem,
but
we
just
we
kind
of
dug
into
far
coin
and
realized.
It
was
a
really
compelling
use
case
for
our
particular
flavor
estate
channels.
B
B
One
of
the
things
we
did
relatively
recently
was
a
web3
torrent
application.
So
this
was
a
state
channel
application.
We
made
as
a
kind
of
proof
of
concept
in
typescript
and
with
this
application
you
can
earn
cryptocurrency
for
seeding
files
for
uploading
files
for
other
people
to
download.
So
our
heads
are
already
in
this
kind
of
incentivized
file
delivery
space
so
that
that's
why?
Hopefully,
the
segway
into
the
far
cry
retrieval
market
we've
got
a
bit
of
a
head
start
on
that
stuff
yeah.
B
So
the
actual
problem
that
we're
trying
to
solve
is
that
the
file
point
retrieval
market
requires
low,
latency
micropayments
between
retrieval
providers
and
clients,
and
that's
not
something
that's
really
available
today.
So
if
you
use
a
vanilla
payment
channel,
you
need
to
do
an
on-chain
interaction.
Every
time
you
want
to
connect
a
new
payer
and
payee.
So
there's
a
high
latency
expensive
cost
to
setting
up
an
unchain
interaction.
B
Now,
there's
something
called
a
multi-hot
payment
which
doesn't
require
that
on
chain,
interaction
and
I'll
explain
a
bit
more
about
how
that
works,
but
that's
also
something
that's
not
available
on
filecoin.
Yet
so
that's
where
we're
going
to
come
in
and
provide
a
solution,
so
some
of
you
may
know
more
or
less
about
payment
channels,
but
I'll
try
and
explain
from
the
ground
up
there's
something
called
an
htlc
approach
which
is
used
in
the
lightning
network
on
bitcoin
and
the
way
that
works
is
instead
of
alice
and
bob.
B
They
use
a
pre-existing
channel
that
they
each
have
with
some
intermediary
who
we're
going
to
call
irene,
sometimes
I'll
call
irene
the
hub
or
the
payment
hub,
but
someone
sits
in
the
middle
of
alice
and
bob
and
helps
them
to
pay
each
other.
So
in
the
hclc
approach
effectively,
what
happens
is
alice
plays
irene
and
irene
pays
bob
and
those
payments
are
locked
together
or
unlocked
by
the
same
secret
revelation.
So
the
atomic
is
the
idea,
so
you
can
see
irene
sitting
in
the
middle
she's
got
three
coins
in
step
one.
B
So
time
goes
down
here.
This
is
like
step,
one
step,
two
step
three
step:
four
irene's
balance
stays
the
same,
but
alice's
three
coins
each
get
transferred
through
our
interval,
so
money's
moved
from
alice
to
bob
through
irene.
B
A
small
extension
to
this
that
you
can
imagine
is
that
irene
actually
screaming
off
a
little
bit
of
a
service
fee
as
she
passes
the
point
on,
so
she
can
get
incentivized
to
provide
this
service
to
the
network,
so
that's
kind
of
how
it
works
in
lightning-
and
you
know
it's
a
great
system.
You
can
have
multiple
hops
in
here.
You
can
have
ivan
a
second
hub
or
second
intermediary
sitting
in
there
and
exactly
the
same
thing
can
happen.
B
You
just
have
to
lock
more
payments
together
in
an
atomic
way
and
you
can
get
that
to
work.
The
big
downside
here
is
that
irene
and
ivan
if
they
want
to
spin
up,
you
know
large
sur
provider
service
to
lots
and
lots
of
alice
involved
pairs.
B
You
know
in
a
very
kind
of
healthy
large
scale,
retrieval
market
they're,
going
to
have
to
do
a
lot
of
work,
they're
having
to
process
every
single
payment
and
what
we're
really
hoping
to
achieve
is
micro
payments,
meaning
very
small
amounts
of
of
money
moving
with
very
high
frequency,
so
there
might
be
a
small
amount
of
cryptography
to
do
on
every
single
micro
payment.
B
So
our
solution
and
I've
just
lifted
this
from
our
crown
proposal
just
to
just
to
sort
of
like
hold
us
to
account.
There
is
a
set
of
executable
protocol
specifications
that
implement
the
off
chain
component
of
an
efficient
multi-hot
payment
channel
protocol,
as
well
as
some
glue
code.
That
makes
it
all
work
so
efficient
here
is
going
to
mean
this
low
latency
idea
and
the
idea
that
those
payment
providers
in
the
middle
the
intermediaries
aren't
having
to
do
so
much
work.
B
A
B
Having
to
go
on
chain
and
the
difference
this
time
is
that
they
are
going
to
execute
a
joint
protocol,
which
we
call
virtual
fund,
where
they
all
have
to
send
messages
and
do
a
little
bit
of
crypto
and
signature
recovery
and
that
sort
of
thing,
but
once
they've
done
alice,
can
send
money
directly
to
bob
and
irene
doesn't
need
to
know
about
it.
She
doesn't
need
to
see
the
messages
she
doesn't
need
to
verify
them.
B
She
only
gets
involved
right
at
the
end
when
they're
finished,
so
you
can
see
that
irene's
very
happy
now,
because
she's
got
a
lot
lower
load
on
her
machine
on
her
services
and
again
this
will
equally
work
with
two
hops
or
more
than
that,
depending
on
who
you're
connected
to.
So
we
actually
think
two
hops
is
kind
of
interesting
alice
might
be
connected
to
irene
her
payment
provider
in
europe.
B
Bob
might
be
connected
to
his
payment
provider
ivan
in
asia
and
iron
and
ivan
will
need
to
be
connected
too.
They
might
have
a
very
sort
of
big
high
traffic
connection
intercontinental
connection,
and
if
you
had
something
like
that,
you
could
imagine
you
know
across
the
globe.
People
wouldn't
have
to
have
too
many
hops
to
get
to
someone
with
a
file
that
they
want
to
pay
for
and
to
be
retrieved.
B
B
There's
some
very
faint
lines
on
here
which
might
make
it
hard
to
see,
but
I
will
just
try
and
explain:
what's
going
on
the
current
payment
system,
if
you
like,
so
we've
got
retrieval
providers
here,
on
the
right
hand,
side
retrieval
clients
here,
on
the
left
hand,
side,
the
providers
have
the
files
they're
going
to
be
uploading
them
to
the
clients.
The
clients
will
be
sending
payments
back
to
pay
for
those
files.
B
This
big
circle
here
is
supposed
to
represent
the
blockchain
and
what
this
visualization
is
showing
that,
under
the
current
system,
when
a
client
connects
to
a
provider,
they
have
to
go
on
chain
and
you
might-
or
you
might
not
see
little
red
flashing
lines
connecting
the
clients
to
the
hub.
Sorry
not
to
the
hub
to
the
blockchain.
That's
what
this
big
circuit
is.
So
those
are
the
kind
of
high
latency
operations
that
we
really
don't
want
to
have.
If
we
can
avoid
it.
B
So
once
you
start
putting
intermediaries
into
the
mix,
you
still
have
to
use
a
blockchain
to
set
up
connections
between
clients
and
hubs
and
providers
and
hubs.
But
then,
after
that,
all
of
the
messages
are
off-chain.
So
you
just
see
flashes
between
these
connections
here,
they're
not
going
to
that
high-latency
blockchain
they're,
relatively
low
latency,
and
as
I
try
to
explain
with
the
with
the
virtual
channel
approach,
not
only
are
we
taking
load
off
of
the
blockchain,
we're
actually
taking
the
load
off
of
the
hubs
as
well.
B
So
how
does
the
virtual
fund
off
chain
protocol
work
in
a
bit
more
detail?
It
works
a
little
bit
like
this.
Don't
worry
if
this
doesn't
make
too
much
sense,
but
I'll
give
it
a
go
anyway.
So
we've
got
our
same
actors
alice,
irene
and
bob.
Here
we
start
off
with
alice,
rheem
and
irene
and
bob
each
having
a
two-way
channel.
B
We
sometimes
call
that
a
ledger
channel
it's
a
sort
of
long-running
connection
with
a
decent
amount
of
cryptocurrency
backing
it
stored
on
chain
and
alice
and
bob
want
to
play
each
other
directly.
As
I
keep
saying,
without
opening
a
new
channel
on
chain
and
depositing
more
money.
So
what
they
do
is
they
set
up
a
three-way
channel
with
this
intermediary
and
then
they
each
update
those
existing
two-way
connections
to
pay
money
into
this
new
three-way
connection.
B
So,
instead
of
that
channel
paying
money
out
to
end
users,
it's
actually
paying
to
another
channel,
which
is
a
three-way
channel
once
they've
done
that
everybody
can
agree
to
sort
of
cut
irene
out
of
the
execution
of
that
channel.
For
us
for
a
length
of
time,
and
then,
as
I
mentioned,
alice
and
bob
well
alice
in
this
case
was
going
to
send
money
directly
to
bob
in
this
space.
B
That
just
sends
one
coin
might
send
a
thousand
micro
payments
or
something
like
that,
and
when
they're
finished
we
can
defund
the
channel
virtually
which
you
can
see
happening
here
so
that
in
this
example
it's
one
coin,
when
the
channel
is
defunded,
you
can
see
the
the
individual
two-way
connections
are
resolved
in
the
following
way.
Alice
has
won
less
coin.
Bob
has
one
more
coin.
Irene
has
got
one
more
in
this
connection,
one
less
than
that
connection,
no
she's
neutral.
B
So
that's
how
virtual
channels,
work
and
that's
our
job
in
in
this
project
so
far
is
to
write
the
off
chain
code,
which
will
send
all
the
messages
to
all
the
signatures
that
will
enable
this
to
happen
securely
and
enable
it
to
happen
in
a
way
where
irene.
Well,
none
of
these
actors,
funds
are
ever
at
risk.
So
if
any
actor
starts
behaving
maliciously
or
stops
responding,
we've
designed
our
protocol
so
that
there's
always
a
route
to
every
participant,
getting
their
funds
back
in
a
fair
way.
B
So
here's
another
complicated
diagram.
I
don't
want
folks
to
look
too
closely
into
this
one.
It's
not
super
important
the
details,
but
this
is
just
an
example
of
how
we
start
designing
these
protocols
on
pen
and
paper
as
it
were.
So
we
have
these
messages
that
get
sent
from
one
actor
to
another
one.
This
is
alice
proposing
that
virtual
channel
and
a
bunch
of
other
messages
get
sent,
and
by
the
end
of
that,
we
hope
that
we've
got
a
funded
virtual
channel
ready
to
make
payments.
B
That's
how
it
should
work
in
principle
and
I'm
going
to
return
to
this
in
a
minute
once
we
show
you
what
the
software
does
and
we
can
compare
an
actual
execution
back
to
this
diagram
and
see
if
we've
kind
of
lived
up
to
our
own
plans,
if
you
like,
and
the
sort
of
spoiler
alert,
is
that
this
part
here,
where
we
fund
so
this
step
here
where
we
fund
the
three-way
channel
using
these
two
two-way
channels,
turns
out
to
be
a
bit
more
complicated
than
you
might
imagine
on.
B
So
what
have
we
built
so
far?
Well,
we've
built
a
go,
go
module
called,
go
nitro
and
it's
not
really
ready
for
production
usage.
Yet
that's
what
we're
going
to
work
on
next,
but
it's
a
really
nice,
like
proof
of
concept,
testing
ground
for
all
of
these
things,
and
we've
concentrated
so
far
on
having
these
virtual
fun
protocols
working
off
chain
and
that's
that's
the
killer
feature,
that's
what
we've
concentrated
on
so
at
some
point
in
the
future
in
the
near
future.
B
We
hope
this
will
become
much
more
like
something
that
will
be
ready
to
integrate
it
into
another
retrieval
market
project
and
we
should
be
able
to
get
payments
running
in
those
virtual
channels.
B
So
and
here's
just
a
flavor,
a
flavor
of
what
the
api
currently
looks
like
it's,
not
a
brilliant
developer
experience
at
the
moment
for
someone
consuming
this
code,
but
this
this
gives
you
an
idea.
I
think
so.
B
This
is
taken
from
one
of
our
integration
tests
there's
a
whole
bunch
of
setup,
but
essentially
you
have
to
spin
up
a
nitro
client
here
you
have
to
pass
in
some
services
like
messaging,
something
that
talks
to
the
blockchain,
some
kind
of
storage
module
and
some
logging
and
then
you're
going
to
call
nitroclient.createvirtualchannel
passing
in
all
the
data
that's
required
for
that.
So
I
want
to
interact
with
a
certain
counterparty.
B
I
want
to
go
through
a
certain
intermediary
and
I
want
a
certain
amount
of
money
in
that
channel
and
so
on.
That's
what
we
have
at
the
moment
and
we
can.
We
can
test
that
all
out
and
it
works
really
well
in
the
future.
As
I
mentioned,
you
will
get
a
response
here,
which
is
a
virtual
channel
id
and
you'll
be
able
to
use
that
to
make
payments.
B
B
Detail
because
I
promised
a
deep
dive
on
what
what
you'll
see
inside
our
code
base,
there's
kind
of
two
parts
to
this.
We
tried
to
build
our
system
as
a
functional
core
with
an
imperative
shell,
so
with
a
large
amount
of
functional
code,
that's
implemented
as
pure
functions,
and
then
we've
got
a
relatively
small
amount
of
imperative
code
that
actually
does
stuff.
B
So
if
you're
in
the
protocols,
package
and
you'll
see
all
these
things
like
virtual
final
virtual
defund
and
each
one
of
those
is
an
attempt
at
an
executable
specification.
So
it's
trying
to
describe
the
messages
that
need
to
be
sent
in
order
for
this
protocol
to
be
successfully
executed,
and
it
doesn't
actually
do
anything.
It
just
describes
what
should
happen.
B
So
these
two
methods,
update
and
crank
and
crank,
is
really
the
interesting
one.
It
takes
your
store,
your
selection
of
states
that
you've
got
in
your
in
your
client
and
it
computes
like
what
the
next
thing
to
do
is
effectively.
It
might
declare
a
message
that
needs
to
be
sent,
for
example,.
B
B
So
every
time
you
crank
an
objective
you're
trying
to
make
progress
on
a
protocol,
so
you're
going
to
flow
down
this
flow
flowchart
and
you're
going
to
keep
asking
questions
about
your
data
that
you
have
and
if,
if
you're
stuck,
if
you're
blocked
on
another
party
performing
some
kind
of
action,
you
might
hit
one
of
these
exit
points.
B
Sorry
and
then
eventually
you'll.
The
data
will
come
in
from
the
counterparty
and
you'll
be
able
to
get
over
that
hump
and
onto
the
next
thing
and
you'll
keep
flowing
down
here
until
the
protocol
is
complete,
and
this,
as
I
said,
is
implemented
as
a
pure
function.
So
it's
relatively
easy
to
test
without
having
to
spin
up
lots
of
fake
databases
and
all
that
kind
of
thing
and
then
the
other
part
of
the
story,
the
other
layer
of
the
onion
is
this
imperative,
shell,
that
we
built.
B
So
this
gives
you
a
bit
of
an
idea
of
like
how
this
all
fits
together.
I
showed
sorry
to
keep
jumping
around.
I
showed
that
api
of
our
software,
which
is
this
line
over
here
previously,
so
there's
a
number
of
things
that
happen.
When
you
call
an
api
method,
the
consuming
application
makes
that
call
it
gets
sent
into
the
engine
on
a
go
channel.
The
engine
is
then
going
to
fetch
any
existing
data,
that's
relevant
from
the
store
and
bring
it
back.
B
It's
then
you're
going
to
do
one
of
these
cranks
that
I
mentioned
to
decide
what
to
do
next.
Those
cranks
declare
side
effects
which
might
be
something
to
send
to
the
blockchain
like
a
blockchain
transaction
might
be
a
message
to
appear.
The
engine
is
going
to
execute
those
side
effects
and
then
recommit
the
data
back
into
the
store,
and
then
it
might
also
send
a
message
back
to
the
application.
B
We
recently
added
this
little
arrow,
which
is
interesting
so
when
the
engine
makes
progress
on
one
objective,
that
it's
trying
to
achieve,
one
of
the
side
effects
can
be
that
it's
unblocked
a
different
objective.
So
it
can
go
around
again
and
make
more
progress
on
something
else,
and
that's
kind
of
interesting.
B
Yeah,
so
those
are
the
the
components
inside
our
software
at
the
moment,
and
I
promised
that
we
could
look
at
an
actual
execution
and
compare
it
to
our
compared
to
our
sorry,
patrick's
just
asking
questions:
does
that
mean
crime
course
prank?
Yes,
crank
doesn't
actually
call
crank
in
the
kind
of
call
stack
sense.
That's
one
way
it
could
happen,
but
we
should
recently
change
it.
B
So
what
crank
does
is
it
schedules
some
more
work
that
will
get
cranked
at
some
later
point,
so
it's
a
slightly
more
asynchronous
thing,
but
yeah
that's
effectively
what
happens
yeah.
So
what
we're
going
to
look
at
next
is
how
the
executions
actually
play
out
in
reality
compared
to
the
way
we
designed
them.
B
B
So
that
means
that
when
all
these
messages
are
getting
sent
around,
we've
used
the
library
that
we
found
that
will
wrap
the
messages
in
these
little
counters
and
there's
a
vector
clock
algorithm
that
runs
between
all
the
participants
and
they're,
basically
counting
events
and
running
a
little
algorithm
on
top
of
everything
else
that
we're
doing,
and
that
enables
us
to
infer
which
events
came
before,
which
other
events
get
a
partial
order,
and
that
means
we
can
go
to
this
website
here.
B
That
makes
nice
little
visualizations
from
the
logs
that
get
output
by
these
instrumented
clients.
So
this
thing
on
on
the
right
here
is
I've
got
three
actors.
I
should
have
probably
written
alice
iron
and
bob,
but
I've
used
more
retrieval
market
terminology
here.
So
there's
rp,
retrieval
provider
ph
is
a
payment
hub.
B
So
that's
our
kind
of
new
actor
that
we
introduced
to
get
our
virtual
channels
going
across
the
hop
and
rc0
is
a
retrieval
client
and
what's
happening
here
is
a
message
is
being
sent,
is
being
broadcast
really
from
this
client
to
the
other
two
players:
that's
the
kind
of
proposal
that
they
want
to
open
a
virtual
channel
and
you
see
a
response
in
kind
from
the
other
two
actors,
so
this
is
broadcasting
to
the
other
two.
This
is
broadcasting
back
to
the
other
two
saying:
yes,
we
all
agree.
This
is
something
we
want
to
do.
B
So
that's
a
very
basic
motif.
You
can
see,
and
that
happens
exactly
as
you
would
expect
it
to
so.
I
hope
that
makes
sense.
So
on
so
far,
the
next
thing
we
can
look
at
is
funding
a
virtual
channel,
so
this
happens
also
exactly
how
you
expect
it
to
do
it's
a
bit
complicated.
B
It
looks
a
bit
complicated,
but
what's
actually
happening
here
is
on
the
right
hand,
side
once
everyone's
agreed
to
fund
this
virtual
channel,
the
retrieval
provider
messages
the
payment
hub
to
say,
let's
fund
this
new
channel,
and
if
we
ignore
what's
happening
on
the
left,
we
get
a
response
here
and
as
soon
as
that's
happened,
this
v1
message
goes
out
which
saying
from
ph
and
rp's
point
of
view
that
virtual
channel
is
funded
and
we're
good
to
go.
The
same
thing
happens.
B
B
B
Messages
in
this
visualization
there's
no
sort
of
odd
temporal
ordering
between
them.
We
can't
say
which
one
really
happened
first,
but
by
the
time
they
get
into
the
other
players
there
is
an
order
so,
and
they
cross
a
little
bit
here.
So
the
message
from
rc2
happens.
First
then
rc1
is
received
first
then
rc1
and
rc0
that
could
have
happened
in
a
different
order.
B
We
can't
build
our
system
in
such
a
way
that
it
depends
on
the
order
of
those
messages
being
received
and
that's
something
that's
taking
us
a
little
bit
of
time
to
sort
of
engineer,
a
solution
for
so
yeah.
What
I'm
going
to
do
next
is
go
to
the
actual
visualization
software,
which
is
a
bit
nicer
in
the
browser
here.
So
I
mentioned
that
things
don't
exactly
play
out
the
way
you
might
imagine
here.
So
these
proposal
messages
up
here
aren't
super
interesting.
What
is
the
interesting
bit
is
down
when
we
get
to
here.
B
What
we
have,
as
I
mentioned
before,
is
three
clients
all
trying
to
connect
to
the
same
provider,
and
what
that
gives
us
is
competition.
It
gives
us
a
lot
of
traffic
in
the
connection
between
the
payment
hub
and
the
retrieval
provider,
and
we
realize
that
that
is
a
potential
problem,
because
our
system
is
such
and
probably
any
simple
system.
Any
payment
channel
system
is
such
that
the
order
in
which
these
virtual
channels
are
funded
is
really
important.
B
That
can't
happen
in
any
order
has
to
happen
in
a
consistent
order
on
this
machine
and
this
machine,
so
they
somehow
need
to
synchronize
what
they're
doing
they
can't
just
do
it
in
all
in
a
completely
asynchronous
way.
So
our
solution
to
that
is
to
send
a
little
bit
of
extra
information
the
whole
time.
So
the
first
message
that
gets
in
here
is
that
the
provider
is
proposing
to
the
hub
that
virtual
channel
v2
is
funded.
B
So
v2
is
the
channel
that
connects
rc2
with
rp,
sorry
about
all
the
acronyms,
but
there's
there's
a
virtual
channel
trying
to
be
created
and
funded
between
each
of
these
clients
and
the
provider.
B
So
this
message
is
saying
to
the
hub:
let's
fund
v2,
this
message
is
saying:
let's
find
v2,
then
fund
v1,
and
this
one
says:
let's
find
v2,
then
v1,
then
v0,
and
because
we
never
get
a
reply
like
the
retrieval
provider
is
kind
of
impatient.
It
doesn't
get
a
reply
to
that
proposal,
so
it
sends
the
next
one
and
then
it
sends
the
next
one
and
each
time
it
sends
a
new
one.
B
It
sends
all
the
previous
proposals
as
well
and
having
that
redundancy
in
there
enables
us
to
synchronize
what's
going
on
and
make
sure
both
parties
include
all
of
those
funding
requests
in
the
same
order
so
that
that
was
pretty
complicated.
So
if
you
followed
that
I'll
be
really
happy,
but
I
can
have
a
look
another
go
explaining
it.
People
didn't
quite
understand.
A
So
yeah
that's
can
I
can
I
ask
a
question
on
that
one.
Yes,
please
please
jump
in
so
just
to
say
why
why
that's
needed?
Is
it
because
if
you've
only
got
a
certain
amount
of
funds
between
the
payment
hub
and
the
rp,
so
if,
if
you've
got
to
max
it
out
on
the
first
on
the
first
channel,
then
the
second,
the
second
two
aren't
going
to
be
able
to
be
created,
so
you
have
to
you,
have
to
be
able
to
only
send
in
ones
like
below
your
limit,
your
payment
limit.
B
There's
actually
a
couple
of
reasons:
there's
some
other
reasons
around
the
fact
that
we'll
very
often
end
up
like
hashing
the
list
of
virtual
channels
on
chain.
So
if
the
order
changes,
it
might
not
mean
anything
semantically
different,
but
it
might
end
up
giving
us
a
different
hash.
That's
not
super
important.
What
you
said
is
much
more
important
which
is
like
you
know.
B
C
Well,
actually,
I
had
a
question
on
that
too
yeah,
so
I
mean
I
could
definitely
see
from
a
point
of
like
fairness
and
for
humans
to
be
able
to
understand
what
went
wrong.
The
funds
run
out
it's
better
to
like
do
them
in
order
right.
So
so
I
can
definitely
see
that
beyond
that
I
mean,
if
you
really
didn't
care
about
making
kind
of
comprehensible,
it
doesn't
matter
which
channel
fails.
C
If,
oh
sorry,
which
request
fails
like
it,
could
have
been
that
the
most
recent
one
in
kind
of
a
last
in
first
out,
one
is
the
one
that
gets
funded
and
then
the
earlier
ones
fail,
but
yeah
I
can
see
in
in
that
case
everyone
would
be
kind
of
scratching
their
head
they're
like
we
had
money
when
we
submitted
it
and
then
that
one
failed,
but
one
later
succeeded.
So
I
mean
I
yeah.
C
B
We
do
have
some
other
ideas
actually
to
be
fair
around
doing
some
of
this
stuff
in
a
slightly
different
way,
which
wouldn't
necessitate
this
system
that
we
have
now
we've
actually
spotted
using
this
debugging
system,
we've
spotted
that
our
messages
are
actually
growing
at
the
moment,
which
is
a
bit
of
a
problem,
so
the
more
clients
we
have,
the
bigger
our
messages
will
get
if
it's
this
kind
of
topology
here.
So
that's
something
we
need
to
revisit.
B
The
messages
should
go
a
bit
and
then
start
shrinking,
but
they're
not
at
the
moment,
so
something
we
need
to
look
into
yeah.
So
this
is
pretty
much
the
end
of
my
presentation
really.
So
the
main
things
I
want
to
sort
of
signpost
that
we're
going
to
be
doing
next
is
essentially
features
and
performance.
So
big
feature
we
don't
really
currently
support
is
actually
doing
payments
and
we
need
to
test
that
out.
B
We
also
want
to
have
channels
with
real
phil
in
them.
So
at
the
moment
we've
got
a
lot
of
mocks
around
the
blockchain.
We
don't
have
real
assets
being
deposited,
so
we're
going
to
hopefully
be
working
with
the
fem
team
to
try
and
get
our
on-chain
code
fully
written
and
deployed.
So
we
can
use
real.
You
know
fargo.
B
Another
thing
we
need
to
do
is
to
have
a
recovery
protocol,
so
I
mentioned
that
we
design
things
so
that
all
participants
can
get
their
money
back
effectively.
We
don't
have
the
code,
then
it
would
do
that.
We
can
wave
our
hands
and
say
there's
everything
in
your
store
needed
to
do
this,
but
we
actually
want
to
write
a
protocol,
so
your
wallets
like
so
your
your
great
natural
client
is
really
like
looking
out
for
you
and
enabling
you
to
recover
your
funds.
B
If,
if
that
should
happen,
and
then
there's
some
performance
things,
you
want
to
look
at
so
things
like
crash
tolerance.
B
If
you
need
to
restart
your
computer,
then
you
pick
up
where
you
left
off
getting
the
time
to
first
payment
down,
so
in
a
very
basic
model,
where
you
have
the
payments
and
the
retrieval
going
on,
you
might
say
I
need
to
have
my
payment
channel
set
up
before
I
start
doing
any
retrieval,
and
because
that's
such
an
important
metric
in
the
retrieval
market
did
that
translate
for
us
into
what
we're
going
to
call
time
to
first
payment,
which
is
how
quickly
can
we
get
this
virtual
fund
protocol
to
be
completed
and
that's
going
to
depend
on
the
number
of
network
messages
which
we
might
be
able
to
optimize
a
little
bit
the
amount
of
crypto
that
goes
on
things
like
concurrency
control
inside
the
payment
hub,
we'll
be
working
very
hard.
B
So
we
plan
to
deploy
a
sort
of
test
network
where
we
can
start
measuring
these
things
and
trying
out
different
optimizations
and
basically
getting
the
whole
thing
ready
for
integration
and
yeah.
If
anyone
wants
to
reach
out
on
email
or
in
the
slack,
my
details
are
there
and
yeah,
we
can
do
questions
now.
C
C
My
suspicion
here
is
that,
like
especially
if
this
network
ends
up
being
between
kind
of
secondary
retrieval
market
providers,
who
are
a
little
bit
better
known
and
maybe
not
end
end
users,
there
may
be
certain
types
of
users
that
retrieval
providers
in
the
filecoin
network
are
willing
to
start
sending
data
to
while
the
payment
is
being
set
up,
so
that
that'll
be
interesting
to
kind
of
explore
to
like
what
extent
there's
some
reputation
system
that
allows.
A
Yeah
for
sure,
I
think
that
yeah,
we
definitely
do
some
kind
of
pre-pre-steps
just
to
try
and
get
that
time
to
first
time
to
first
fight
is
essentially
what
we're
trying
to
minimize
in
the
retrieval
networks,
and
if
we
can
make
that
independent
or
at
least
not
not
not
definitely
longer
than
time
to
first
payment,
then
then
that'll
be
yeah.
That'd
be
interesting.
To
look
into.
A
There
was
a
yeah,
a
question
which
I
remember
speaking
about
a
few
months
ago
and
just
be
interesting
to
hear
what
your
thoughts
are
on
it.
Now
we
spoke
about
how
this
is
like
two-way
payment
channels,
so
alice
and
bob
can
can
make
micropayments
to
each
other.
Quite
often,
in
a
retrieval
network,
we've
got
clients,
let's
say
it's
a
browser
who
is
only
going
to
be
on
the
retrieving
end
in
terms
of
the
data
and
we'll
be
making
the
micropayments?
A
If
we
did
one-way
virtual
payment
channels
would
would
that
reduce
the
number
of
steps
or
round-trips
that
have
to
be
made
before
you?
Can
you
can
start
doing
your
your
payments.
B
Yeah,
I
think
the
answer
is
yes.
I
don't
know
if
andrew
wants
to
jump
in
on
this,
because
I
think
he
knows
this
best,
but
I
think
that
there
are
optimizations
that
we
can
make
that
by
by
leveraging
that
assumption
of
a
unidirectional,
channel
and
yeah.
That
seems
to
totally
fit
the
use
case
here.
So
that's
definitely
something
we'll
look
into.
B
If
it's,
I
suppose,
that's
why
I'm
keen
to
get
this
like
testing
set
up
with
you
know
first
thing,
because
we
need
to
know
sort
of
how
you
know
how
much
of
an
axe
we
need
to
take
the
different
things
or
how
hard
we
have
to
try
in
different
areas
to
get
that
latency
down,
but
yeah.
That's
definitely
an
avenue.
We
can
go
down.
B
Andrew
says
he's
in
his
construction
zone.
B
I'll,
just
in
terms
of
optimizations
on
unidirectional
payments,
patrick
there
is
another
one
that
we
can
definitely
do,
which
is
the
storage
of
the
payments
themselves.
So
payment
will
be
something
like
a
digital
signature,
plus
some
other
data.
B
If
you're
sending
payments
you're
decreasing
your
balance,
so
you
don't
really
need
to
store
those
payments.
They're
not
critical
to
you
when
you're
receiving
payments
is
more
importantly,
you
you
save
them
to
disk
in
case
you
need
to
take
them
on
chain
so
that
that's
one
other
example
where
you
can
like
save
some
disk
space
effectively
or
save
some.
I
o
operations,
if
you
don't
need
to
receive
any
money.
A
Okay,
yeah
andrew's,
coming
on
the
chat
which
I'll
read
out
loud,
the
main
intuition
is,
if
bob
doesn't
deposit
funds
into
the
channel,
then
bob
doesn't
need
to
sign
off
on
any
changes
to
any
outcome.
Changes
when
setting
up
the
virtual
channel,
so
yeah
yeah
yeah.
That
makes
sense
oh
and
some
more,
as
as
long
as
the
rules
of
the
channel
enforce
that
bob's
balances
don't
decrease
during
these
set
of
actions.
A
Cool
and
then
yeah,
I
just
have
one
final
question,
which
is
you
mentioned
that
there's
just
the
whole
kind
of
crank
decision
tree
that
you've
got
of
how
far
through
you
are
is
any
sort
of
you
said
it
was
like
that
you'd
written
it
as
like
pure
functions.
Is
there
any
states?
Does
that
mean
that
you're
not
holding
any
state
about
how
far
through
the
crank
you've
got
when
you
do
a
crank
that
you're,
starting
from
the
top
of
that
decision
tree
every
time
and
working
your
way
through?
Yes,.
B
B
That
is
because
we
have
like
what
I
call
extended
state,
which
is
like
your
big
old
bag
of
data
in
your
store,
like
signatures,
probably
lots
of
extended
state,
that's
potentially
infinitely
big
and
we
didn't
really
want
to
put
another
layer
of
finite
state
on
top
of
that,
so
you
might
have
a
finite
state.
That's
like
I
am
waiting
for
a
message
from
alice,
but
really
you
can
tell
that
just
by
looking
at
all
this
extended
state
by
looking
at,
I
don't
have
state
number
zero
with
a
certain
signature
on
it.
B
So,
instead
of
having
a
finite
state
machine,
we
just
have
this
big
old
bag
of
data,
and
that
does
get
updated
each
time
we
do
a
crank,
so
state
is
being
updated,
but
it's
not
like
a
finite
state
with
a
name.
B
It's
just
like
some
states
might
get
a
signature
added
to
them
and
then
we
do
another
crank
and
we
look
at
that
set
of
data
and
these
kind
of
pause
points
kind
of
play,
the
role
of
finite
states,
but
we
don't
actually
save
them
and
we
don't
actually
have
any
logic
that
depends
on
them,
they're,
just
kind
of
like
almost
like
debugging
information.
They
tell
you
where
you've
got
to,
but
we
don't
really
use
it.
Does
that
answer
your
question.