►
From YouTube: Streaming Money
Description
In this presentation from Day 2 of the #SwarmOrangeSummit, Dietmar Hofer from Artis, shares the interesting concept of streaming money. In the presentation he explains and proposes a method of money trasnfer that would reduce transaction costs, trust requirements and improve privacy.
A
A
A
So
streaming
money:
this
is
the
visualization
our
designer
came
up
with
by
the
way
I'm
not
presenting
on
my
computer
it
it
failed
me
to
connect
to
HDMI,
so
I
have
to
present
on
a
Windows
machine.
Let's
hope
that
goes
right.
I'll
try
so
first
a
bit
of
of
philosophical
background
thinking
about
thinking
about
money.
A
So
this
is
my
my
observations.
It's
not
some
scientific
classification.
There
is
money
which
is
self
contained
in
the
sense
that
it
has
intrinsic
value.
So,
for
a
long
time
we
had
these
coins,
which
were
either
of
gold
or
silver,
and
there
is
the
kind
of
representative
money
which
is
more
like
a
ledger
which,
by
the
way,
also
existed
already
long
time
ago,
I
think
in
Mesopotamia.
They
they
already
had
kind
of
ledger
entries
and
there
are
hybrids
like
I,
found
this
item
in
C.
A
A
A
A
A
So,
yes,
we
could
imagine
it
otherwise
the
problems
with
the
status
quo
in,
in
my
opinion,
if
we
emulate
continuous
payments
with
recurring
payments
that
increases
the
liquidity
requirements.
If
you
look
at
example,
dimensional
solutions
always
need
some
kind
of
upfront
deposit.
You
have
increased
trust
requirements,
because
if
the
payment
is
not
continuous,
then
either
the
paying
party
or
the
receiving
party
needs
to
trust
up
front
and
you
have
usability
and
caused
buyers.
A
A
There
was
a
talk
of
unless
Antonopoulos
in
2016,
where
he
talks
about
streaming
money
which
inspired
me
which
made
me
think
about
it
for
a
long
time
and
but
there
he
narrated
it
as
yeah.
We
can
basically
three
money
with
payment
channels,
and
you
may
know
the
rain'
demo,
which
took
place
a
while
ago,
where
they
paid
for
electricity,
and
there
was
our
micro
payment
every
two
seconds.
That's
a
screenshot
of
it
as
proof
of
concept,
but
I
kept
thinking
about
that.
A
If
we
cannot
do
that
in
a
more
real
way
and
I
came
to
the
conclusion
that
yes,
we
could
and
that's
how
it
can
be
done
on
chain.
So
right
now,
if
you
look
at
the
theorem
code
base,
the
balance
is
stored,
explicitly
per
account.
It's
I
think
it's
named
value.
They
are.
Instead,
we
could
make
this
implicit
and
define
a
function
over
time
and
the
balance
basically
is
always
a
function
of
time.
So
the
balance,
if
there's
open
streams,
the
balance
changes,
always
changes.
A
So
it
depends
on
when
you
check
it
what
the
balance
is
yeah,
basically
so
an
open
the
transaction
for
opening
a
stream.
Instead
of
defining
receiver
and
amount
defines
receiver
and
the
flow
rate,
and
we
get
the
state
change
because
if
the
balance
changes,
that
is
a
state
change,
but
we
can
get
that
state
change
by
leveraging
the
the
change
of
block
times
then,
because
that's
also
a
state
change
and
we
just
need
another
transaction
for
closing
it
and
that's
it.
A
It
can
run
for
as
long
as
we
want,
and
this
is
really
continuous
and
not
and
not
we
don't
settle
with
every
block
or
so,
but
it's
limited
to
the
granularity
of
of
the
blocks.
In
this
case,
I
made
a
proof
concept,
which
is
basically
an
extension
of
year,
C
20.
So
after
a
while
I
filled
out
that
could
even
be
done
for
an
ear
C
20
token,
and
we
named
that
stream
with
double
a
turn
which
is
similar
to
to
the
stream.
A
We
know
about
a
new
bird
because
I
think
that
often,
if
we
reuse
existing
words,
that's
dangerous,
because
we
have
this
leaky
abstractions
which,
where
things
behave
differently
than
we
may
expect.
So
maybe
thinking
about
it.
You
already
thought:
okay,
that's
nice,
but
what?
If
the
sender
runs
out
of
funds,
we
cannot
just
pretend
that
the
sender
will
always
be
solvent,
so
indeed
that's
the
most
difficult
part.
A
If
you,
if
you
build
that
in
an
unrestricted
way
where
we
can
open
streams,
however,
we
want,
then
we
can
end
up
with
a
graph
which
becomes
uncomputable,
because
in
order
to
calculate
the
balance
of
an
account,
I
need
to
calculate
the
balance
of
incoming
streams
and
in
order
to
do
that,
I
need
to
check
the
balance
of
the
sender
accounts
and
so
I
got
into
recursions,
which
may
go
on
forever.
I
can
have
cycles,
I
could
even
have
nested
cycles
etc.
A
So
that
said,
assuming
that
we
can
always
compute
that
we
have
a
guarantee
that
if,
at
a
certain
point
in
time,
we
calculate
the
balance
of
an
account,
we
can
be
sure
that
it
will
not
decrease.
So
if
I
have
a
certain
balance
in
an
incoming
stream,
that
stream
may
stop
stall
or
it
may
run
with
a
reduced
speed,
but
it
cannot
reverse.
So
that
means
that
the
fans
which
arrived
at
the
receiver
can
immediately
be
used
are
immediately
available.
So
I
don't
need
to
close
or
settle
or
something
the
stream.
A
A
So
advantages
over
recurrent
payments
because
we
have
this
simulation
and
I
found
something
interesting
again
Antonopoulos
on
his
battery
on
page
in
the
faq.
There
is
also
this
question:
why
aren't
you
fundraising
in
Bitcoin
or
another
cryptocurrency
and
he's
saying
yeah
because
doing
recurring
payments
with
crypto
is
currently
difficult
and
I?
Think
that's
a
pity,
because
we
have
now
programmer
programmable
money
and
I
think
it
should
not
not
just
be
as
as
the
legacy
systems
we
have
online,
but
it
should
actually
be
better
in
my
opinion.
A
A
Basically
that
means,
if
today
you
make
a
recurring
payment
on
the
internet.
You
always
need
some
kind
of
legal
agreement
because
of
this
and
I
would
say
that
if
we
have
something
like
streams,
we
could
maybe
get
rid
of
that
and
related.
We
could
improve
privacy
because,
if
I
always,
if
I
need
to
make
an
account
and
give
my
details,
etc,
that
always
means
I
lose
my
privacy
I
could
not
make
a
subscription
to
an
online
newsletter
or
publication
without
compromising
my
privacy
and
I.
A
So
at
the
left
side
we
have
the
status
quo,
how
how
it
works
now.
So,
let's
assume
we
come
from
Twitter
or
somewhere
we
come
to
this
page.
We
are
not
locked
in
or
something
and
we
say:
okay,
that's
that's
a
good
guy.
He
is
doing
a
useful
work.
Let's
support
that
and
at
the
right
side
how
it
could
be-
and
we
have
a
counter
time
and
counter
for
the
number
of
taps
on
the
screen.
A
So
maybe
you
notice
that
we
didn't
even
go
for
the
worse
case.
We
used
facebook
login.
We
had
the
the
field,
for
example,
for
paypal
already,
with
the
auto
completion.
We
had
a
bad
short
password,
so
the
worst
case,
I,
would
argue,
has
a
lot
more
tabs
and
takes
more
time,
but
I
think
it's
already
obvious
that
it's
pretty
painful.
A
A
A
So
this
would
be
a
native
component
where
the
the
key
for
making
for
signing
the
transaction
is
stored
safely
in
your
phone
and
depending
on
the
flow
rate,
you
could
say:
okay,
it's
enough
to
confirm
with
my
fingerprint
as
it's
done
here
or
with
a
pin,
and
you
could
say
if
it's
a
higher
amount,
maybe
you
need
additional
I
know,
maybe
a
second
factory,
etc
that
could
be
user
configurable.
The
point
is
that
the
website
doing
this
doesn't
need
you
to
register.
It
can
just
be
on
your
arrow,
which
calls
into
this
native
app
and.
A
A
Compared
to
payment
channels,
you
do
not
need
to
add
extra
infrastructure
of
payment
channels,
which
is
the
standard
needs
to
have
device
always
on
the
receiver,
needs
to
I.
Think
an
issue
which
is
maybe
not
enough
mentioned
is
you
need
a
hot
wallet
at
the
sender
side
if
you
want
to
keep
doing
small
transactions
and
especially
on
mobile,
be
difficult
to
always
be
always
on,
etc.
And
of
course
you
don't
need
this
upfront
deposits
and
overall
you
have
reduced
liquidity
requirements
and
I
think
there
are.
A
Just
this
days
there
is
a
lot
of
talk
about
subscriptions.
Maybe
you
are
aware
of
the
ERC
9
948
proposal
going
on
in
the
room
and
yeah.
Maybe
this
could
be
something
useful
there
as
an
option
and
I
think
that
subscriptions
are
a
good
thing
because
they
are
emerging,
as
maybe
the
only
viable
alternative
to
ad
based
online
business
models,
which
had
a
lot
of
bad
side
effects.
I
would
say
so.
A
A
So
briefly,
back
to
the
challenge
of
computability
I
believe
that
it
is
possible
to
to
have
a
design
which
has
low
restrictions,
but
where
you,
where
you
have
a
set
of
rules
and
decide
of
dynamically
adjusting
transaction
fees,
also
continuous
transaction
fees
which
would
keep
that
computable.
But
at
some
point
we
decided
that
that's
not
an
easy
thing
to
do,
and
it's
better
to
start
with
something
simpler.
A
We
introduced
three
account
types
where
there's
rules
who
can
stream?
Where
and
we've
moved
us
with
that
set
of
rules
which
we
call
basic
streams.
We
don't
have
the
problem,
we
can't
cut
into
endless
recursions.
We
cannot
have
cycles
and
I
think
it's
already
useful
enough
for
a
lot
of
use
cases.
So
that's
how
we're
starting
that's
what
we
are
now
implementing
artists.
A
A
A
A
Distribution
wise,
we
want
to
distribute
most
of
the
of
the
80s
to
so-called
anonymously
registered
unique
human,
so
we
are
working
on
a
registration
process
which
we
aware,
where
is
a
difficult
challenge,
but
we're
trying
where
humans
can
get
registered
without
leaking
much
information,
but
enough
information
to
be
able
to
duplicate
checks.
So,
basically
we
want
to
provide
everybody
who
is
interested
with
share
of
this
common
resource
so
with
the
80s
for
making
transactions
on
on
this
network,
and
we
want
to,
and
we
are
building
in
stream
support
and
related
to
swarm.
A
Maybe
this
kind
of
continuous
payment
could
also
be
be
useful
for
swarm,
because
our
cases
in
swarm,
where
you,
for
example,
for
long
term
storage,
where
you
have
have
this
kind
of
setup
where
you
need
to
continuously
pay.
So
if
that
sounds
interesting,
let
me
know
and
I
think
it.
We
are
also
interested
in
making
swarm
part
of
the
artists
Network.
We
have
a
hierarchy
of
nodes
where
the
so-called
free
nodes
are
supposed
to
provide
services
to
the
to
the
artists.