►
From YouTube: Tech Session #3: Bisq's Trading Protocol
Description
Manfred provides a technical overview of the Bisq's trading protocol. Slides at https://goo.gl/CpqfQt.
A
A
A
I
think
I
have
a
separate
window
open
one
second,
okay.
Well,
maybe
we'll
cut
that
out
and
post,
but
anyway,
let's
try
that
again.
So
this
is
our
third
sex
session.
We've
been
doing
a
series
of
pieces
over
the
last
few
weeks.
If
you've
missed
them,
you
can
go
back
to
the
beginning.
We
have
a
new
playlist
here
on
YouTube,
where
you
can
catch
up.
The
playlist
is
named
Tech
session,
so
you
can
go
check
that
out.
A
The
first
one
is
a
broad
technical
overview
of
all
things
bisque
and
it's
a
great
place
to
start
and
the
last
one
that
we
did
is
on
the
peer-to-peer
network
bisques
own
bespoke
peer-to-peer
network
on
top
of
Tor,
and
now
we
take
it
up
one
level
this
week
and
we
talked
about
the
trading
protocol.
That's
implemented
on
top
of
that
peer-to-peer
network,
how
this
clients
talk
to
each
other,
orchestrate
with
each
other,
to
complete
the
process
of
buying
and
selling
Bitcoin
for
Fiat
a
Bitcoin
before
other
cryptocurrencies.
A
So,
if
you're
interested
in
seeing
really
how
does
bisque
work
under
the
hood,
how
do
we
implement?
You
know
non-custodial
truly
peer-to-peer
trading,
and
this
is
where
it
starts
to
get
right
into
the
meat
of
that
so
I'm
going
to
hand
this
over
to
Manfred
now
and
he'll
walk
through
a
series
of
slides
going
into
detail
on
all
of
this,
and
if
we
have
time
you
might
even
see
some
some
live
coding
and
some
hands-on
kind
of
stuff
toward
the
end.
So
Manfred
take
it
away.
Thanks.
B
Yeah,
thank
you
Chris
for
the
introduction.
I
start,
my
screen
sharing
I
hope.
It's.
We
Sabrina
yeah
yeah
welcome
to
the
cert
Aerotech
session
and
we
are
covering
this
time
another
very
important
area
of
the
bisk
network
protocol
framework.
Whatever
that's
the
trade
protocol
yeah.
That
kind
of
today's
to
get
fair
with
you
I
will
start
with
a
graphical
overview
about
the
trade
protocol,
so
that
everybody
is
on
the
same
page.
Then
we
talk
about
the
main
task.
B
We
look
a
little
bit
into
this
task,
run
a
framework
which
is
a
part
of
the
implementation
and
then
we'll
show
the
main
classes
of
the
protocol
to
see
a
little
bit,
how
it
how
it
really
looks
like,
and
then
we
open
for
question
and
answers,
and
of
course,
if
you
have
a
burning
question,
just
interrupt
me
and
I
will
try
to
answer
it.
Okay,
most
of
you
who
have
seen
there
who
have
read
the
white
paper
will
have
seen
this
graphical
high
level
graphical
overview.
B
B
So
we
have
Alice
as
Bitcoin,
buyer
and
Bob
as
Bitcoin
seller.
Alice
has
created
an
offer
with
we
are
not
talking
or
we
are
not
covering
this
process,
how
to
publish
an
offer
and
so
on.
That's
not
part
of
the
real
trade.
The
real
trade
happens
when
our
Bob
is
taking
off
from
Alice
and
yeah.
We
see
here
with
this
blue
line
that
Bob
is
sending
some
message
to
her
to
Alice.
It's
basically
their
intent
to
take
the
offer
he's
sending
some
initial
data
he's
doing
or
his
trade
fee
payment
alice
is
doing
some
verification.
B
They
exchanged
the
data,
what
they
need
to
do
for
creating
together
the
multi,
seek
or
the
deposit
transaction.
So
in
this
in
this
transaction,
where
they
are
locking
in
their
security
deposit
and
the
Bitcoin
seller,
Bitcoin
amount.
What
you
want
to
sell,
yet
they
create
together
a
transaction
and
because
they
are
not
on
one
place
or
so
they
have
to
exchange
in
in
several
parts.
B
Several
information
so
that
they're
able
to
to
sign
the
transaction
as
soon
as
this
is
done
as
soon
the
transactions
published
Alice
has
to
wait
or
for
at
least
one
blockchain
confirmation,
and
then
she
has
to
do
the
minerals
that
to
make
the
fear
transfer
or
when
she
is
doing
alcohol
and
it's
an
alkyl
ray
duder
Alcuin
transfer
after
she
has
done
this
on
her
onlin,
my
banking
webpage.
She
clicks
a
button
and
application
and
confirms
that
she
has
started
the
payment.
B
Beside
this
sending
of
the
notification
I've
done,
the
payment
she's
also
already
sending
the
signature
of
the
pay
up
transaction
will
explain
a
little
bit
later.
Why
and
so,
but
with
that,
we
are
boarding
an
extra
step
in
in
their
communication.
Then
Bob
sees
this
notification.
He
will
check
his
bank
account
and
as
soon
as
he
has
received
the
money,
he
will
create
the
payor
transaction.
That's
why
Alice
was
already
sending
before
the
signature.
She
cannot
lose
anything
she
want
or
the
Bitcoin
money
out.
So
she
has
nothing
to
know.
B
We
have
also
a
more
detailed
overview.
I
don't
want
to
go
through
all
the
steps
here,
partly
because
it's
not
how
to
percent
up
to
date
and
I
think
it's
a
little
bit
too
much
overview.
But
you
see
here
already
in
under
the
hood
it's
more
complex
like
in
this
overview.
We
have
just
the
very
the
most
important
part
with
all
the
details,
how
many
messages
are
sent
back
and
forth
between
the
users
to
ensure
that
everything
is
safe?
That's
not
covered
here!
B
B
So,
as
we
said
already,
the
main
task
is
to
create
this
Maltese
acres
of
the
deposit
transaction,
where
both
users
are
putting
in
their
their
security
deposit
and
the
Bitcoin
salad
or
the
amount.
What
he
wants
to
sell
into
this
multisig
transactions
or
the
money,
is
locked
in
there.
Nobody
can
spend
it
as
long
as
both
traders
are
not
providing
a
signature
to
unlock
this
money
in
the
pl
transaction.
At
the
end,
then
they
need
to
exchange
their
payment.
Account
data
like
for
a
few
payment
at
a
bank
account
number
and
all
the
data.
B
What
Ellis
needs
to
make
the
via
transfer
to
pop
or
in
case
of
al-quwain,
it's
just
alcohol
address.
Then
they
need
to
notify
each
other
when
they
did
some
use.
Actions
like
signaling
that
Alice
has
sent
the
fiat
money
to
Bob
and
that
bob
has
received
the
fiat
money,
honest
under
the
pair
transactions
and,
of
course,
the
creation
of
the
pair
transaction.
B
We
have
basically
to
make
yeah
also
on
a
very
high
level,
with
only
two
roles:
a
buyer
and
the
seller,
and
they
have
different
responsibilities
and
different
different
flavor
in
what
they.
What
they're
doing
when
you
look
a
little
bit
closer,
there
are
more
differences
or
when
the
buyer
is
the
taker
or
when
the
pie
is
just
the
maker,
always
created
all
four
Arab
terrorists.
Some
difference
is
not
too
much,
but
differences
enough
to
really
separate
these
roles.
B
Each
yeah
and
this
protocol
classes
taken
contain
a
list
of
tasks
which
get
executed
in
a
certain
area,
and
those
tasks
are
yeah
ever
every
every
unit
of
work,
every
every
logical
unit
or
is
encapsulated
in
a
task
like,
for
instance,
verifying
that
the
other
peer
is
not
banned
or
that
he
has
under
the
trade
fee.
Payment
were
publishing
or
a
transaction.
B
Every
such
an
action
is
a
task
and
it's
encaptured
in
one
class
and
their
execution
of
one
task
after
after
the
other
see
it's
executed
in
sequence,
it's
done
in
the
in
a
task
or
on
a
class.
It
has
nothing
to
do
with
Java
fix
concurrent
tasks.
We
are
here
in
sync:
a
single
threaded
environment,
yeah,
I
told
on
the
UI
thread.
There
is
no
need
for
having
having
extra
threads,
so
it
has.
The
term
task
is
a
little
bit
unfortunate
because
it's
overloaded
with
usually
tasks,
are
used
in
the
in
a
threaded
context.
B
If
anybody
came
up
with
a
better
name,
we
can
rename
this,
but
didn't
found
a
better
name
when
I
designed
it.
And
yet
it's
task
runner
framework
is
I've
written
it
by
myself.
There
might
be
some
or
existing
or
frameworks
out,
which
would
have
done
exactly
what
I
needed,
but
at
that
time
I
didn't
find
one,
and
it
was
actually
not
really
wicked.
It's
basically
a
list
of
tasks
defined
as
classes
which
you're
adding
here,
and
you
can
basically,
when
you
read
this
list
of
tasks,
you're
reading,
all
the
steps.
B
What
you
have
to
do
in
that
in
that
area,
the
trade
protocol
consists.
We
will
see
a
little
bit
later
in
the
code,
consists
of
different
areas
like
thirst
or
getting
in
touch
with
the
other
trader
and
signal
that
you
want
to
take
their
offer
in
Bob
side,
and
then
we
are
signaling
that
the
field
payment
has
started
and
all
those
areas
are
in
yeah
handled
by
one
task:
runner
with
a
collection
of
different
tasks
when
all
tasks
are
completed
or
we
get
result
handler
called
when
anything
goes
wrong.
We
get
default
here.
B
We
have
an
example
of
a
single
task.
That's
a
very
simple
one
published
rates
at
a
six
to
at
the
end
after
takeoff
approaches
when
the
trade
has
started,
their
taker
will
publish
or
trade
statistics.
So
he
creates
this
trade
statistics
of
object
with
the
day
ETA.
What
what's
required
and
publish
it
to
a
peer-to-peer
network
and
then
calls
the
complete
with
that
this
task
get
completed.
The
next
task,
if
there
is
one
in
the
list,
gets
executed
when
anything
goes
wrong,
it
calls
a
failed
method
and
everything
stops
here.
B
Yeah
for
exchanging
data
with
there
appear
we
are
using
trade
messages,
it's
like
always
over
tor,
hidden
services
using
our
European
Network
it.
The
take
off
for
protest,
yet
appear
has
to
be
online
later.
As
soon
der
the
deposit
transaction
has
been
created.
We
are
supporting
also
offline
peers,
as
when,
when
it
takes
a
day
until
the
money
has
arrived
on
pop
side,
he
don't
need
to
be
online
all
the
time
he
can
go
offline
and
when
Alice
has
sent
a
mess,
I
have
sent
the
money
or
and
Bob
is
not
online.
Here.
B
Everything
is
yet,
as
usually,
we
are
using
our
direct
messages
when
both
peers
are
online
and
they're
encrypted
by
default,
and
only
in
the
second
part,
or
we
are
also
supporting,
wait,
books,
messages.
The
reason
why
it
doesn't
make
sense
to
support
off
lumpier
to
take
off
approaches
is
just
because
it
would
take
too
long
and
Alice
when
Bob
is
taking
off
for
Alice.
Alice
will
reserve
the
offer
for
one
minute
or
so
and
when
Bob
would
fail
for
whatever
reason
at
this
time,
Topher
will
become
available
again,
but
we
want
to
avoid
that.
B
We
have
concurrent
access
to
one
offer
and
three
traders
are
taking
the
offer
at
the
same
time
and
Alice
could
not
handle
this
so
da,
forgets
ya
reserved
and
it's
basically
taking
away
from
the
network
for
a
short
period
of
time
and
when
the
trade
really
has
succeeded
in
this
time,
Duff
is
removed.
Otherwise
Alice
will
reactivate
the
offer
and
with
ya
with
supporting
all
flam
peers.
B
That
would
take
way
too
long
and
Alice
would
have
locked
up
here,
offer
wait
long,
and
so
it's
not
practical
and
yeah
all
the
trade
messages,
as
always
our
birth
of
our
encoded.
Here,
a
tater
is
mainly
encapsulated
in
the
trade
object
itself,
we've
also
for
different
types
of
trades.
So
let's
make
a
trade.
So,
let's
take
a
trade
buyers,
make
and
buyers
take
a
trade
there.
They
are
parallel
to
the
drake
protocols
and
the
trades
are
taking
keeping
track
of
the
of
the
state
not
only
of
the
trade
state.
B
The
trade
con
contains
a
process
model
which
which
handles
basically
all
the
data
which
are
not
directly
fit
into
the
into
the
domain
of
the
trade
and
like
and
also
access
to
a
domain
object
like
other
services
and
there
enter
the
protest
model
contains
trading
peer
and
the
trading
peer
contains
all
the
data
which
is
relevant
for
you.
Art
appear
like
the
only
address
from
your
appear.
You
are
storing
in
the
trading
peer
and
all
those
data
because
they
are
all
contained
in
the
trade
object.
The
trade
gets
persisted.
B
B
Yeah,
you
should
see
now
you
should
see
now
my
my
IntelliJ
screen
I
have
here
to
trade
protocols
open
a
seller
as
taken
and
the
pious
make
them.
We
could
also
try
the
other
one.
The
the
seller
is
maker
and
bias
take
about.
Let's
stick
with
this
and
let's
start
with
Aria.
We
here
we
have
all
read
the
comment,
start
trade,
let's
say
der,
yet
a
taker
is
taking
the
offer
at
this
moment.
B
A
B
Judy
yeah
we're
starting
here
with
take
away
your
offer,
so
we
are
starting
here
at
us
Corona
we
are
adding
all
the
tasks
required
and
basically
you
can
read
here
the
process.
First,
you
are
verifying
to
make
a
account
you're
verifying
to
make
a
payment
fee
payment.
You
are
selling
selecting
the
arbitrator,
the
mediator,
you
create
your
offer
fee,
the
taker
fee
transaction.
B
You
are
creating
the
input
for
your
deposit.
So
in
the
next
step
order
term
the
buyer
can
create
already
two
deposit
transaction.
He
would
not
be
able
to
assign
anything
before
knowing
your
input
so
you're
delivering
the
data
required
for
the
other
peer
that
he
can
construct
the
full
transaction
and
then,
at
the
end,
you
that's
usually
always
the
last
step
that
you
are
sending
a
trade
message
that
appear
and
when
we
are
looking
into
one
of
those
classes
like
which
one
maybe.
B
Yeah
here
we
are
creating
this,
as
we
are
preparing
all
kind
of
data.
What
we
need
for
sending
this
pay
deposit
requests
message,
Surya
appear
and
we're
filling
it
up
and
then
we're
sending
it
over
the
peer-to-peer
network
and
when,
when
we
see
it
in
the
listener
that
it
has
arrived,
then
we
call
down
complete
when
anything
goes
wrong.
It's
availa
and
yeah.
Let's
go
to
the
next
step,
so
the
pious
maker
is
what
appear
in
this.
In
this
trade.
He
is
listening
on
incoming
messages
and
when
he
received
hear
this
message,
pay
deposit
request.
B
That
was
what
we
have
send
it
here
in
the
last
in
the
last
task,
then
we
had
this
code
could
executed
starting
a
task
renege
and
with
those
come
task.
So
the
first
task
in
this
in
this
in
this
case,
when
you
receive
a
message
from
the
other
peer
you're,
always
processing
this
message,
so
you
are
verifying
you
yeah.
You
have
everything
all
the
data
if
they
are
valid
and
then
you're
putting
those
data
from
there
from
this
message
to
your
data
model,
you're
doing
all
kind
of
verification.
You
verify
that
arbitration.
B
A
mediator
selection
is
the
same.
Mediator
is
not
implemented
yet,
but
it's
prepared
for
the
next
version
of
the
arbitration
system
and
here
interesting
study
aware
creating
a
contract.
Oh
so
every
trade
contains
a
contract
in
the
contract,
basically
older,
and
let's
have
a
look
to
this
class
here,
we're
creating
the
contract
and
it
contains
all
the
relevant
data
of
the
trade.
So
we
said
it's
really
like
a
legal
contract.
B
B
B
It
would
not
be
well
it
yet
because
it's
missing
the
signature
of
Bob,
that's
an
accept
and
on
Bob
side
and
she's
also
set
up
a
deposit
transaction
listener,
so
in
case
she
would
not
received
and
the
message
from
Bob
when
bob
has
published
a
transaction.
She
would
still
recognize
that
the
deposit
transaction
has
been
published
because
she
is
listening
on
the
Bitcoin
network
for
this
transaction
and
as
soon
it's
published,
she
is
executing
the
code
to
go
to
the
next
step,
and
here
the
last
mess.
B
He
is
listening
after
he
has
sent
a
message.
He
is
listening
to
this
publish
deposit
transaction
request,
trade
message
when
he
has
received
this
is
executing
and
accepts
first
again,
processing
the
data
or
verifying
it
and
putting
it
to
state
the
models,
doing
all
kind
of
verification,
especially
verifying
their
contract
and
signing
the
contract.
B
B
Yeah
back
to
here,
as
when
Ellis
our
when
one
block
confirmation
has
arrived,
she
has
to
start
the
Fiat
payment
and
when
she
has
done
this,
she
is
clicking
this
button,
and
this
button
is
triggering.
This
method
is
on
Fiat
payments
started
and
she
doing
it
again
all
kind
of
checks
before
sending
the
message
and
then
sending
this
message-
and
this
message
contains
already
the
the
signed
payoff
transaction
because
we
said
already
before
she
has
nothing
to
lose
anymore.
On
this
side.
B
He
is
listening
for
this
message
that
Alice
has
started
the
fiat
payment
and,
as
soon
had
he
received
this,
he
got
UI
notification
that
or
he
has
to
check
his
bank
account
and
when
he
has
received
the
money
on
his
bank
account
he
is
clicking.
Then
the
button
I've
received
the
money
and
with
this
button
click
we
are
executing
this
task.
Runner
and
here
bob
is
signing
and
finalizing
the
payer
transaction.
B
So
he
has
already
received
the
signature
from
Alice,
so
he
has
everything
to
create
the
payer
transaction
which
uses
the
output
of
the
multi-sig
transaction
and
we
are
making
the
payouts
to
Alice
side
and
pay
back
the
security
report
deposit
to
pop
side.
He
is
publishing
the
payer
transaction
and
he
is
sending
a
message
to
to
Alice.
B
And
we
have
here
this
extra
security
that
Alice
were
setting
up
a
payout
transaction
listener
in
case
she
would
never
receive
this
pair
transaction
message.
She
would
get
notified
over
the
blockchain
that
she
see.
Okay,
there
is
a
pair
transaction
I
was
waiting
for
so
Bob
has
done
everything,
otherwise
he
would
not
have
published
this,
and
there
is
nothing
special
happening.
B
B
B
But,
of
course,
when
we
want
to
add
new
features
like,
for
instance,
automated
Alcuin
trades,
so
that
on
the
alkaline
side,
we
could
basically
look
up
at
the
alkaline
block
explorer
to
see
when,
when
yeah,
when
their
transaction
has
been
confirmed
on
the
alkaline
block
explorer
and
then
doing
these
steps,
which
is
done
manually,
that
yeah
signaling
the
same
descending
after
Alcuin
hands
and
confirming
the
receipt
of
the
alkaline
could
be
done
automatically
by
by
code.
And
when
we
supporting
this
new
feature,
it
would
require
some
some
additions
in
the
trade
protocol
to
handle
this.
B
So
and
of
course,
when
we
would
have,
it
has
always
had
room
for
improvements.
Maybe
some
data
can
be
optimized.
Some
I
think
that
cannot
be
messages
removed,
I
think
it's
already
very
optimized
and
not
too
many
messages
sent
around
and
I
think
you
cannot
go
lower,
but
yeah,
of
course,
there's
always
stuff
to
to
improve
here.
One
yeah
I've
listed
here
a
few
things
which
are
open
issues
in
that
area.
One
thing
is
that
the
trade
fee
is
not
verified
at
the
moment,
so
basically
people
could
could
cheat
here
about.
B
It
requires
quite
a
lot
of
engineering
knowledge
to
do
this,
and
probably
those
people
who
are
able
to
do
this.
They
don't
need
to
cheat
for
not
paying
the
very
low
trade
fee
but,
of
course
that's
an
open
task.
It
requires
a
little
bit
of
effort
because
we
need
to
make
a
look
up
in
some
block
explore
for
this
transaction,
because
the
trade
fee
of
the
other
peer
is
not
part
of
your
unit
or
getting
notified
about
this
transaction
because
not
part
of
your
wallet
so
in
bitcoin
chain.
You
don't
have
default
support
for
this.
B
To
make
the
messaging
a
little
bit
more
resilient
would
be
good
to
to
get
a
message
received
confirmation
message,
so,
every
time
when
you're
receiving
an
important
message
from
the
area,
you
are
sending
back
a
confirmation
message
with
that,
like
we
had
issues
with
the
network
had
issues
with
dos
attacks
in
December
January,
and
because
of
this
we
also
had
quite
a
lot
of
issues,
because
the
network
was
less
reliable
and
much
much
slower
and
then
sometimes
especially
the
mailbox
messages.
Sometimes
the
message
don't
arrive
and
there
are
issues
and
with
having
their
the
information.
B
B
Absolutely
yeah
would
be
good
to
handle
more
error
cases.
I
mean
its
handles
already
the
most
relevant
error
cases,
but
from
time
to
time
there
are
some
strange
bugs
and
then
the
trade
protocol
is
stalled
in
a
in
a
certain
state,
and
sometimes
it
requires
a
little
bit
of
extra
manual
work
to
fix
and
the
UI,
basically
that
that
failed
trade
is
not
dangling
in
the
in
there.
B
In
the
table
of
the
open,
trades
and
I
start
in
the
beginning,
I
tried
to
handle
all
the
errors,
but
it
turned
out
to
be
a
huge
effort
and
was
probably
not
was
to
really
handle
all
theoretical
errors,
but
I
implemented
a
small
mini
framework
for
doing
this.
It's
basically
a
it's
called
debug
view.
So
when
you're
in
def
mode
and
without
set,
you
can
open
this
tick
debug
view
and
you
get
a
combo
boxes
for
selecting
any
any
tasks
of
any
trade
protocol
depending
in
which
role
you
are.
B
B
It
does
not
handle
all
the
errors,
because
it's
you
Jeff
foot
but
off,
but
it
would
be
nice
to
have
here
more
resilience,
I
limit
it
at
the
end
to
those
error
cases
which
really
happens
in
reality,
and
not
only
those
which
could
happen
theoretically
but
in
fact,
never
happens,
but
that's
for
sure,
an
area
where
we
could
improve
the
resilience
after
after
application
and
then
to
recover
from
error
states.
There
are
some
error
states
which
are
not
perfectly
covered,
as
I
said
before.
B
Sometimes
there
are
happening
packs
and
then
office
is
sticking
around
in
the
pending
grades
and
not
moved
to
the
failed
trades
and
yeah.
That's
the
open,
open
issue
and,
of
course,
to
add
more
tests
here.
Would
specially
integration
test
would
be
good
to
really
test
bigger
parts
after
of
the
protocol,
but
also
unit
tests?
Have
the
smaller
errors
really
tested
well
and,
as
I
said
before,
yeah
new
feature
would
be
this
trade,
automated
trading
for
all
coins
with
as
soon
as
sequitas
implemented,
we
will
in
bit
country.
B
Yeah
here
are
a
list
of
some
references,
the
to
overview
images,
so
the
high-level
and
the
detail
overview-
and
here
is
there
the
package.
After
of
the
trade
protocol
in
the
code
base,
yeah
thinker,
we
are
more
or
less
through
everything.
Are
there
any
questions?
I
have
not
the
YouTube
channel
open,
so
I
don't
see
if
there
are
live
question
I
only
have
to
hang
out.
I
have.
B
Sorry
I
was
muted
yeah.
If
there
are
no
questions,
I
think
we
can
close
this
topic.
Of
course,
if
any
developer
has
questions
just
ask
on
on
the
slack
channel
and
I
think
the
next
important
topic
to
cover
would
be
the
Bitcoin
part,
maybe
for
next
week
so
bit
crunchier
and
the
way
how
bisque
is
integrated
is
working
with
Bitcoin
layer
and
if
you're
interested
error-
and
we
are
still
10
minutes
or
so
I
could
show
a
little
bit.
The
current
state
of
the
tau
that's
completely
non
related
now
to
the
trake
protocol.
A
B
B
Yeah
should
be
visible
now
here.
I
have
a
developer
instance
of
bisque,
with
the
Tao
enabled
and,
as
you
see,
Cena
tried
out
yesterday's
for
presentation
today.
If
everything
works,
I
just
show
very
quickly
the
overview
of
the
UI
and
then
make
a
full
cycle
of
making
a
request.
Making
the
boat
and
getting
the
issuance,
the
UI,
is
still
under
heavy
development,
and
many
parts
are
completely
missing.
B
So
I'm
not
interested
in
in
feedback
for
the
UI,
because
I
know
myself
way
too
much
what
need
to
be
changed
and
improved,
but
the
end
also
on
the
code
side,
I'm
not
asking
really
for
reviewer
for
too
much
feedback
at
the
moment,
because
it's
not
really
ready.
It's
a
cylinder
on
the
heavy
development,
and
we
require
probably
one
or
two
weeks
more
until
kind
of
like
ready
for
a
review
in
the
yeah
you
have
here
in
the
towel
or
menu.
You
have
two
different
or
three
different
aspect:
tabs
wallet,
the
proposals
and
the
voting.
B
The
proposal
and
the
voting
will
be
probably
just
one
tap,
that's
not
clear.
Yet,
and
in
the
wallet
you
have
an
dashboard
with
an
overview
about
your
available
balance,
the
unverified
balance
when
there,
when
you
make
a
transaction
you
you
don't
know
before
the
transaction
is
really
in
the
blockchain.
If
it's
well
it'd
be
a
skew
transaction,
so
it
will
be
an
unverified
the
balance
which
is
which
is
spent
from
your
transaction
and
which
is
not,
where
confirmed
yet
and
locked
in
voting.
That
will
be
when
you
do
a
voting.
B
You
are
voting
with
your
stake.
This
takers.
In
the
voting
we
have
to
transaction
a
blind
road
transaction
where
your
boat
is
encrypted,
nobody
can
read
it
and
then
a
second
transaction
where
you're
revealing
your
vote
at
the
later
period,
and
this
stake,
which
is
used
in
the
inter
blind
road
transaction,
is
locked
in
this
time.
So
you
you
cannot
use
this
for
making
a
normal
transfer
or
whatever,
and
that
will
be
also
showed
up
here
in
the
locked
for
voting
and
to
get
unlocked
and
in
the
reveal
transaction.
B
B
Then
the
number
of
BS
q
transactions
in
total,
the
unspent
outputs
we
are
all
kind
of-
and
when
there
would
be
some
trades,
then
it
would
be
the
price
it's
just
taking
the
latest
price
of
from
the
trade
statistics
on
bisque
and
depending
on
this
price,
we
could
calculate
the
market
capitalization.
So
when
the
price
rupee
want,
Allah
would
be
more
or
less
two
and
a
half
million
dollar.
B
When
you
want
to
send
esq
yeah
you're,
taking
the
address
from
a
receiver
application,
I
can
send
here
just
to
myself,
for
instance,
I
don't
want
to
do
it
now,
because
otherwise
I
need
to
wait
for
another
confirmation
and,
and
then
I
put
in
the
their
address.
Note
it's
it's.
Usually
it's
a
normal
Bitcoin
address.
So
technically
it's
Bitcoin.
It
just
contains
a
B
at
the
beginning
for
biscuit
or
for
vsq
to
avoid
our
mistakes
that
you're
sending
B
is
Q
to
a
Bitcoin
wallet.
B
Where
you
see
some
information,
which
kind
of
transaction
was
the
amount,
the
confirmations
and
here
the
types
their
Genesis
transaction
will
also
have
a
special
icon,
but
this
application
I
just
sent
over
money
from
another
deaf
application,
and
here
on
the
proposals,
we
have
a
dashboard
with
the
different
phases
I
have
here,
the
phase
is
justified,
or
so
the
phases
are
defined
in
blocks.
In
reality,
the
proposal
phase
will
be
something
like
three
weeks
will
be
few
hundred
blocks
for
testing
here,
just
use
very
short
blocks
or
two
blocks
and
and
Mon
block
break.
B
The
break
will
be
also
something
like
minimum
ten
blocks
or
maybe
even
one
day,
the
breaks
are
required
to
avoid
problems
with
reworks.
So
when
there
is
a
reorganization
of
the
Bitcoin
blockchain,
it
could
create
problems
when
you
have
created
on
the
last
block
a
proposal
and
then
after
the
rework
it's
not
yeah,
there
would
be
some
tricky
cases
and
to
avoid
this,
we
have
a
break
and
if
any
real
cabins
that
should
be
covered
by
this
breaks,
then
we
can
create
a
proposal.
We
will
see
active
proposals.
B
We
will
see
my
vote
so
if
you're
done
before
about
so
you
see
what
I
voted
and
there
will
be
more
details,
but
that
has
implemented
yet
then
that's
not
implemented
all
yet.
The
boats
from
the
networks
or
what
all
the
users
are
working,
which
get
published
a
blind
votes
and
reveal
the
votes
and
close
proposals
are
from
the
past,
which
are
not
in
the
active
period.
So
this
phases
are
yet
a
whole
cycle
of
which
is
something
around
the
months
which
is
similar
like
we
are
doing
now
on
the
spreadsheet.
B
Every
months
we
have
intuitions
and
and
at
the
time
for
proposals
and
voting,
we're
here
this
three
weeks
for
proposals,
then
the
voting
is
here
broken
up
in
two
phases:
the
blind
voting
where
you
are
doing
your
real
voting.
But
nobody
can
read
your
boat
data
because
it's
encrypted
and
then
the
reveal
phase,
where
you
don't
need
to
do
it
manually,
it's
just
your
applique.
You
have
to
be
online
because
your
application
is
as
soon
as
it's
entering
this
phase.
B
It's
creating
this
transaction,
where
you're,
putting
in
the
secret
key
for
decrypting
your
blind
coat
and
for
revealing
your
boat
and
a
little
bit
more
like
this
and
you're
publishing
this
to
the
network
and
then
after
another
break.
There
is
stations,
that's
just
one
block
and
when
their
data
gets
verified,
so
at
yeah
bisque
application
is
either
running
as
a
full
node,
where
you
have
your
local
Bitcoin
core
node
and
with
RPC
you're
receiving
every
block,
and
you
are
verifying
every
transaction
every
block.
B
If
it
is
a
PS
q,
a
valid
PS
q,
transaction
or
not,
and
we
are
executing
really
every
block
on
the
blockchain
they're
beginning
from
the
Genesis
transaction,
and
that's
why
you
don't
have
to
be
online
here.
It's
done
automatically
as
soon
as
you
go
online.
You
are
executing
this
special
block,
which
is
marked
as
the
issuance
block
height
hate
and.
B
Block
height
with
pronounce
it
wrong
and
there
you
were
basically
here.
The
magic
happens
here:
you're
printing
money
to
yourself.
So
when
your
proposal
get
voted,
ok,
you,
their
output
from
the
proposal
transaction
becomes
a
issuance
transaction.
You
have
created
new
bsq,
but
yeah.
Let's
see
how
it
works
in
action.
We
have
different
proposal
types
in
compensation
request.
B
B
B
A
Currently
we
do
them
every
month,
maybe
we'll
change.
How
often
we
do
them,
but
but
the
most
common
type
is
a
compensation
request.
Basically,
a
proposal
to
pay
myself
X
amounts
of
BS
cube
for
some
valuable
work
that
completed
over
previous
period
and
that's
what
everybody's
voting
on
but
other
proposal
types,
and
this
is
where
it's
like
useful
to
have
the
generic
top-level
idea
of
a
proposal
it.
So
it's
like
literally
any
change
imaginable
to
disk
or
the
disk
Val.
B
It's
a
little
bit
more
a
suggestion.
Eric
are
good
for
this.
It's
completely
true,
but
there
are
two
more
which
I
edit
just
as
kind
of
like
example.
Maybe
we
will
not
implement
it
fully
for
the
first
trees,
but
we
want
to
design
it
at
least
that
we
know
that
the
Tao
can
handle
it.
So
the
basic
idea
is
that
over
this
voting
process
we
can
change
anything
in
the
Tao.
Of
course
it
has
its
practical
limits,
because
yeah
some
things
will
be
really
complicated
to
change
automatically.
B
That's
why
we
have
this
channel
generic
proposal
type,
which
will
require
usually
deaf
effort
to
really
make
a
new
release
and
implement
the
changes.
But
there
are
some
other
really
smart
contract
changes
which
can
be
done
automatically
and
then
the
issuance
phase,
where
we,
which
is
used
for
the
compensation
requests
to
create
new
new
new
psq.
B
That
will
be
then
be
used
also
to
apply
those
changes,
and
maybe
I
go
a
little
bit
more
into
details
of
these
other
proposals,
as
one
is
for
changing
a
parameter
in
the
biskits
ow
like
the
trading
fee
or
the
proposal
fee
or
quorum
or
the
threshold.
What
you
need
is
a
core
room
for
any
vote.
You
have
a
minimum
amount
of
psq,
otherwise,
it's
ignored.
So
when,
when
when
there
is
a
proposal,
everybody
is
ignoring
it
and
only
one
they
called
always
500.
Ps
q
is
voting
on
it.
B
It
will
not
reach
the
quorum
because
the
quorum
will
be
maybe
5,000
BS
q
and
it
will
mine
a
completely
minority.
Stakeholder
cannot
do
any
change
by
himself
and
the
threshold
is
basically
how
much
percentage
you
need
to
reach,
or
so,
when
you
at
the
moment,
we
have
50%
for
compensation
request.
So
as
soon
as
you
reach
more
than
50%,
your
your
proposal
gets
accepted
or
your
compensation
request
gets
accepted,
but
there
might
be
different
thresholds,
especially
for
changing
the
parameter,
because
there's
quorum
and
threshold
our
parameters
itself
and
can
be
changed.
B
So
we
don't
want
to
easily
let
it
change,
because
then
people
could,
when
somebody
has
enough
psq
and
the
other
people
are
a
little
bit
lazy
and
observing
not
very
well.
Somebody
could
change
and
the
quorum
order
the
threshold
to
a
very
low
level
and
would
create
damage
basically
so
for
the
quorum
and
for
the
threshold
I
consider
a
initial
default
value
of
75%.
So
only
when
75%
of
the
voters
will
vote.
Okay,
it
can
be
changed.
This
parameter
as
well.
B
The
quorum
will
be
higher
like
10,000,
bsq
or
even
higher,
and
another
proposal
will
be
and
that
will
be
executed
out
matically.
So
there's
no
manual
work
needed
those
like
for
the
trading
fee.
For
instance,
we
are
starting
at
the
Genesis
height
we
are
chart.
We
are
starting
with
the
current
trading
fees
when
the
trading
fees
will
be
changed
over
time.
By
voting,
somebody
makes
a
proposal.
B
I
want
to
change
the
trading
fee
to
that
in
that
number
and
it
get
accepted,
then
at
the
issuance
or
a
block,
as
at
this
block
height
of
the
issuance,
we
are
applying
the
new
value.
So
in
the
past,
when
we
are
executing
the
code
or
everything
is
dealing
with
the
old
trading
fee-
and
at
this
at
this
moment
on,
we
are
using
the
new
trading
fears.
The
trading
fee
has
no
real
effect
in
the
in
the
Dow
protocol
but,
for
instance,
the
feast
where
the
proposals
are
verified.
B
So
when
the
feet
for
a
proposal
change
a
proposal
might
be
invalid
when
it's
in
the
wrong
face.
So
that's
really
important,
then,
to
keep
track
of
this,
that
at
this
height
there
is
a
new
fee
and
all
the
verification
so
is
using
than
the
new
fee,
and
that's
really
that's
a
smart
contract.
There's
no
manual
intervention
people
are
working
on
this
and
changing
some
parameter
in
the
Dow
and
then
the
new
parameter
is
is
well
again
disused
and
something
similar.
We
enter
parameters.
B
We
are
using
a
long
value.
There
I
think
we
can
cover
all
their
data
with
this
long
data
type,
so
it
want
to
avoid
double
data
type
and
but
we
also
have
binary
about
Slyke
and
the
example
for
this
is
for
removing
an
old
Queen,
as
we
have
defined
in
our
documentation
about
how
to
add
an
alt
queen
and
I'll
queen.
We
are
basically
adding
any
alcohol
without
applying
politics
or
we
are
not
deciding
if
an
alkine
is
a
scam
queen
or
not.
B
But
if
stakeholders
inked
an
alchemist
is
Camco
and
he
can
make
a
proposal
for
removing
an
out
win
and
when
it
gets
majority
votes,
it
gets
removed,
also
automatically
not
from
the
code,
but
in
the
display
in
the
what
the
users
see
in
the
outcome
is,
it
will
not
show
up
anymore.
So
basically,
we
are
deleting
an
altcoin,
so
that's
also
a
way
where
we
are
delegating
this.
These
decisions
to
the
stakeholder
holders,
hand,
which
gets
executed
automatically
in
code
without
any
manual
intervention
and
dictionary
proposal
are
different.
B
They
are
just
you
can
write
any
text
and
you
can
say
I
do
that
and
that
and
when
it
gets
accepted,
it's
basically
a
strong
signal
to
the
developers
that
they
should
work
on
this
and
should
implement
this.
But
it's
not
execute
I
mean
people
can
say.
I
would
like
to
have
support
for
lightning
next
months.
Yeah,
that's
nice!
Everybody
would
like
to
have
this,
but
it's
not
realistic
and
it
will
not
happen
because
it
takes
probably
half
a
year
to
implement
this.
So
yeah.
B
Let's
go
directly
to
the
compensation
request.
It's
the
only
one
which
in
place,
which
is
implemented
yet
I
fear
prefilter
with
a
mutator
sum.
But
of
course
that
has
to
be
filled
out
by
yourself.
The
important
this
or
the
descriptions
just
very
short
and
the
importance
is
the
link
to
a
detailed
like
the
github
issue
and
the
requested
amount
I've
here,
14,000
and
my
psq
address
that
will
be
probably
automatically
filled
with
a
new
psq
address
from
your
wallet
now.
B
I
click
make
proposal,
I
get
a
confirmation
screen
and
now
it's
published
and
now
yeah
it's
not
in
the
blockchain.
That's
why
I
don't
see
it
yet
I
create
my
req
test.
I
create
a
new
block.
So
after
this
confirmation
of
the
block,
I
will
see
here
my
proposal
as
long
we
are
in
the
proposal
phase.
We
are
still
here
in
the
proposal.
Phase
I
can
remove
my
proposal
as
well,
and
then
it
will
be
removed
from
the
peer-to-peer
network
and
that's
it
technically.
B
I
create
a
Bitcoin
transaction
where
I
put
in
the
OP
return
a
hash
of
the
proposal
later
and
the
proposal
Teta
will
also
contain
the
transaction
ID.
But
of
course
that's
a
chicken-and-egg
problem,
so
the
hash
does
not
contain
the
transaction
ID.
So
we
create
the
hash
of
all
there.
The
data
excluding
the
transaction
ID
putting
into
the
blockchain
and
then
the
transactionally
we
put
into
this
local
data
structure
of
the
proposal,
which
gets
published
to
the
peer-to-peer
network,
and
everybody
can
verify
that
there
is
a
transaction,
it's
also
a
fee
payment.
B
So
we
see
it
here
the
fee
for
the
computation
request.
At
the
moment,
it's
just
long
psq
and
when
yeah
we're
verifying
our,
so
you
only
will
see
proposals
which
are
correct
and
which
have
a
transaction
which
is
matching.
Now
we
are
creating
another
transaction.
We
are
in
the
break
and
in
the
next
transaction
we
end
about
in
phase
when
we
go
here
again,
we
see
the
screen
has
now
changed
or
we
can.
We
cannot
remove
it
anymore
because
it's
already
in
another
phase,
but
we
can
vote
on
it.
B
B
It's
only
thought
locally
as
long
as
I'm
not
creating
really
the
vote
transaction,
so
I
can
still
change
it
and
once
I'm
sure
I
want
to
publish
my
boat,
the
collection
of
all
those
proposals
and
my
votes
and
those
proposals
get
published
and
I
can
define
how
much
they
come
on
to
use.
For
my
for
my
voting,
let's
say
I
will
would
use.
B
Maybe
200
is
Q
and
when
I
click
here
we
don't
see
any
confirmation
yet,
but
or
we
see
here,
that
transaction
has
been
published,
it's
still
unverified,
because
it's
not
an
approaching,
we
don't
know
which
type
of
transaction
is,
and
we
see
the
also
here
you
have
voted
with
with
with
some
bsq
and
I
used
some
important.
That's
the
change
output
so
that
I'm
verified.
So
when
I
create
a
new
block,
everything
gets
resolved.
We
see
it
here.
200
PS
q
are
locked.
B
Invoking
we
see
here
this
transaction,
that's
the
fee
for
the
blind
vote
to
be
askew
and
yeah
and
in
their
face
we
we
have
to
wait
now
for
for
the
reveal.
Also
in
this
moment
everybody
receives
this,
those
blind
roads
which
are
encrypted
data.
You
cannot
read
anything
out
of
this
year.
The
only
thing
what
you
see
is
the
stake,
but
with
that
you
don't
know
much
that
this
blank
coating
is
important
because
earlier
we
didn't
have
this,
we
vote.
B
There
is
your
a
list
of
proposals
with
the
ball
things
which
is
encrypted.
That's
the
data
in
there
in
the
blind,
working
and
we
are,
and
the
blind
vote
is
also
a
peer-to-peer
message
or
which
gets
sent
to
the
network,
which
contains
the
ID
of
the
blind
rotator,
not
hundred
percent.
True,
if
there
is
a
hash
holds
in
there
in
the
operation,
but
they
don't
think
so.
We
are
creating
new
blocks
again
and
now
we
on
the
reveal
face,
and
you
don't
need
to
do
anything-
you
only
have
to
be
online
as
a
voter.
B
You
have
to
be
at
least
once
online
in
the
reveal
face.
So
the
reveal
face
will
also
be
something
like
two
or
three
days,
so
the
voters
have
a
little
bit
of
time
and
as
soon
as
it's
online,
the
application
will
create
this
revealing
transaction.
We
see
it,
it's
not
confirmed
yet
now
it's
confirmed
and
the
reveal
transaction
will
contain
the
secret
key.
So
there
everybody
can
decrypt
they're
blind
vote
and
will
contain
a
hash
of
the
list
of
all
your
blind
vote.
B
I
will
explain
this
a
little
bit
later,
because
it's
a
little
bit
tricky,
but
that's
something
important.
What
we
also
need
to
consider-
and
here
we
are
going
to
the
next
break
and
Absalom,
and
we
are
now
we
are
going
to
the
issuance-
and
we
see
here
it
has
not
changed
before
it
was
a
fee
for
compensation
request.
Now
this
transaction
is
issuance
transaction.
It's
a
it's!
A
district.
B
This
compensation,
request
transaction
which
happened
in
the
past,
has
one
output
for
the
issuance
with
this
output
is
or
Bitcoin
at
the
beginning,
and
only
at
this
issuance
moment
when
all
the
votes
are
calculated
and
it's
it's
clear
that
this
proposal
has
been
accepted.
If
this
output
becomes
B
is
cured,
but
it's
basically,
you
are
doing
the
same.
Like
a
Genesis
transaction.
You
are
creating
just
a
normal
Bitcoin
transaction
with
Bitcoin
input
and
you
diff
and
in
the
Genesis
transaction.
B
I
define
basically
that
this
is
now
BS
q
and
here,
with
the
issuance
are
by
by
voting
by
such
being
successfully
accepted
in
the
voting
process.
The
network
has
defined
that
this
is
now
well.
It
BS
q,
but
technically
the
input
was
Bitcoin.
You
have
created
vs
q
out
of
Bitcoin
and,
of
course,
the
Bitcoin.
What
you
need
to
put
in
is
very
it's
just
a
few
thousand
Satoshi.
So
that's
very
little
money.
There,
PS
q
will
have
a
high
value,
so
you
have
created
Roman
Eaton.
We
have
I
mean
here.
B
We
see
the
the
fourteen
thousand,
the
one
BS
q
for
the
compensation
request.
Feed.
Maybe
I
will
change
this
in
the
UI
to
make
it
a
little
bit
more
clear
and
have
it
two
entries
or
show
this
in
a
better
detail,
but
because
this
transaction
now
I
think
that's
just
a
glitch
in
the
you
are
that
balance
has
not
updated
happens
with
some
excellent
information.
B
Now
our
yeah,
we
see
dolls
in
a
balance
before
we
had
around
1,000
or
999
97
or
whatever
bsq,
and
now
we
has
nearly
15,000
ps2.
You
know
we
really
have
added
up
the
1000.
What
we
got
initially
lots
of
14,000
disease
and
I
explained
a
little
bit
more.
This
detail
with
the
with
the
hash.
After
after
voting
assume,
it
could
be
that
the
OS,
when
every
every
peer
is
creating
the
result
of
all
the
boats,
and
it
could
be
because
this
data
is
published
in
a
peer-to-peer
network
and
a
peer-to-peer
network
has
eventually
consistency.
B
What
they
have
received
make
a
hash
of
this
and
put
the
hash
in
the
OP
return.
The
Bitcoin
block
data
is
available
for
everybody.
Terry
should
consistency
problem
there,
so
when
I
as
a
normal
user
will
be
in
there
issuance
face
and
calculate
everything,
I
will
first
I
will
check
if
the
hash
of
the
blind
votes
which
I
have
received
is
matching
to
the
maturity
after
voters
of
the
hash
of
the
voters.
B
So
when
there
are
ten
voters
and,
for
instance,
one
of
the
ten
voters
have
only
received
nine
blind
votes
and
all
the
others
have
received
ten,
the
one
has
a
different
hash,
like
all
the
nine
others,
then
the
maturity
we
use
the
stake
for
the
maturity.
It's
not
the
number
of
voters,
it's
the
stake,
and
I
probably
did
this
single
one
witch
who
has
a
different
hash
will
be
the
loser,
so
his
state,
the
view
is
invalid
and
and
then
we
are
yeah.
B
B
Basically
my
data,
a
few
conflicts
and
as
long
as
the
maturity,
yeah
they're,
basically
I
mean
I,
don't
want
to
get
lost
in
too
much
details
here
we
said
mechanisms
we
and
sure,
basically,
that
everybody
has
the
same
data
viewer
which
is
used
for
calculating
the
total
result.
The
total
reads
out:
you're,
just
summing
up:
they're
accepted
and
declined
wrote
by
the
stake
and
when
you
read
reach
the
quorum
and
their
threshold,
it
gets
accepted.
B
Otherwise,
it's
rechecked
and,
of
course
it
doing
older,
older
verifications
with
if
the
vote,
if
the
transaction
have
been
in
the
right
phases
and
everything,
and
if
everything
match
together
between
the
peer-to-peer
network
data
and
the
transactions
and
yeah,
that's
that's
it.
Basically
from
their
two
main
side,
it's
already
pretty
good
in
a
good
state,
still
require
more
refactorings
and
more
tests
and
more
checks.
B
B
There
is
a
lot
of
work
of
open,
but
basically
it's
already
in
a
pretty
good
state
and
our
hope
more
or
less
in
one
months
it
might
be
kind
of
like
ready
for
testing
and
I
would
like
to
use
it
and
as
soon
it's
in
a
good
shape
to
use
it
on
test
net
for
replacing
our
spreadsheet.
So
we
have
account
like
a
real-life
test.
We're
still
when
there
are
boxes
or
nothing.
B
A
I
think
what
we
can
do
is
essentially
propose
and
vote
in
parallel,
probably
for
a
couple
months.
Right
use
the
existing
phase,
zero
infrastructure,
the
spreadsheet,
etc,
walk
through
that,
like
we
usually
do
and
then
like
repeat
the
process
in
in
the
app,
and
we
should
get
consistent
results
out
of
both
systems
right.
B
B
Multi
I
mean,
of
course,
it's
very
kind
of
like
we're
playing
with
fire
when
anything
goes
wrong.
It's
really
dangerous,
we're
printing
money
and
when
there
are
some
parts,
urk
can
be
a
disaster.
So
we
have
to
be
super
careful
and
test
it
yeah.
It's
will
be
the
most
critical
errand
application
at
the
end,
because
we
citrate
just
limited
damage
for
this
trade
amount.
What
can
we
have
the
arbitration?
We
have
a
lot
of
fall
backs
here
when
there
is
a
huge
bug
where
people
could
print
out
money
out
of
thin
air.
B
B
There
are
some
mechanisms
in
place
already
when
we
launch
to
limit
the
possible
damage,
but
we
don't
want
to
get
to
the
situation
of
course
or
to
be
super
careful
and
test
really
well
everything
and
would
would
enjoy
to
get
some
additional
help
at
a
certain
point.
But
at
the
moment
it's
still
not
still
too
much
prototype
level.