►
From YouTube: Bisq Dev Session: Bisq DAO
Description
Session about the Bisq DAO for developers who will do a code review.
Slides:
https://docs.google.com/presentation/d/1IhJpns3VyoTTDtmg_lOZzaazVz5_18f-sBsXztxXXHQ/edit#slide=id.p
B
Yep,
hello,
everybody.
We
would
like
to
make
a
short
or
probably
not
so
short
or
overview
about
the
Tao
about
you
have
a
technical
side
of
the
Tao
and
it's
mainly
intended
for
developers
who
will
do
a
code
review,
there's
Christopher
and
Chris
on
the
Hangout,
so
they
are
intending
to
make
a
code
review
it
you
conquer,
hear
about
the
doubt.
B
B
Okay
I
will
make
a
screen
sharing
one
second,
so
now,
yeah
I
think
it's
with
a
bit
now.
Okay,
let's
jump
into
in,
we
have
a
pretty
tight
akanda
I.
Will
you
give
a
row
with
you
about
everything,
just
a
disclaimer,
I
assume,
or
it's
expected,
that
the
listeners
are
are
no
we're
already
about
there,
the
tower
and,
of
course,
I'll
disk.
So
when
you're
completely
new
to
bisque
were
completely
new
to
that
pistol.
B
Please
read
up
first,
the
general
overview
documents
we're
on
the
web
page
or
its
intended
for
people
who
have
already
a
pretty
good
understanding
about
the
bisque
top
yeah.
We
give
her
overview
Dan
talk
about
different
phases
that
we'll
talk
about
later,
then
the
blockchain
paths,
the
peer-to-peer
network,
part
the
way
how
the
blockchain
get
passed
to
distinguish,
which
are
psq
transactions,
the
threading
model,
the
data
model,
the
resilience
of
our
different
data
sources.
There
are
activities
in
each
cycle
and
yeah
the
code
overview.
B
Then
general
challenges
next
steps,
yeah
how
we
go
on
so
overview,
yeah.
We
are
using
the
Bitcoin
blockchain
for
getting
consistent
data
and
we
are
using
as
well
that
the
European
Network
for
and
the
pure
pure
network
has
eventually
this
creates
some
challenges
and
we
have
to
deal
with
this
and
that
we
give
the
lake
a
little
bit
more
explanation
how
this
two
different
domains
are
linked
together
that
they
work
together
and
what
we
have
to
take
care
of.
B
We
use
the
peer-to-peer
network
for
distributing
the
rich
data,
for
instance
the
proposal
and
contains
out
all
kind
of
data
like
description
links
and
so
on.
We
cannot
put
this
into
the
operator
and
that
would
be
too
much
data,
even
that
was
the
early
approach
to
do
it,
or
at
least
the
voting
on
the
blockchain
directly
in
the
opportune,
but
that
would
have
been
much
more
complicated
and
would
have
had
other
side
effects
and
yeah.
B
We
linked
a
peer-to-peer
network
data
with
the
transaction
ID
of
a
transaction
and
there
so
every
yeah
like
a
proposal
when
it
get
published
to
the
peer-to-peer
network.
It
contains
the
transaction
ID
of
the
proposal
transaction,
so
there's
always
a
transaction,
and
then
there
is
a
peer-to-peer
network.
They
turn
whether
they're
specially
to
such
events,
where
this
happens,
one
is
the
publishing
of
the
proposal,
and
one
is
the
publishing
of
the
voting
to
blind
voting
as
an
invoking
yeah.
We
are
supporting
earlier
in
early
concepts.
B
We
had
just
a
normal
routine,
where
it
was
visible
immediately
what
people
vote
on,
but
that
carried
the
problem
that
with
late
board.
So
basically,
it
was
an
incentive
to
wait
until
the
last
moment
and
then,
when
somebody
has
lots
of
stake,
he
could
be
more
influential
in
the
last
moment
to
vote,
and
now
we
have
blind
voting.
B
So
during
the
voting
phase
the
boards
get
published
in
encrypted
way,
so
nobody
can
read
it
but
to
get
time-stamped
on
the
blockchain
and
then
in
another
phase
it
votes
get
revealed,
and
here
again
we
have
a
peer-to-peer
network
day
to
the
blind
vote
data
which
published,
which
carries
the
transaction
ID
of
the
blind
go
transaction
and
on
the
Bitcoin
inside
we
are
using
the
OP
return
and
put
the
hash
of
the
peer-to-peer
network
data
into
the
Opera
turn.
So
we
are
have
from
both
sides
a
link
to
the
other
domain.
B
As
on
the
Bitcoin
side,
when
you
look
up
their
transaction,
you
can
verify
that
a
certain
European
network
data
is
really
the
one
which
was
used
for
this
transaction.
By
checking
the
hash
yeah,
we
have
different
phases
which
separated
with
brakes.
The
brakes
are
important
for
avoiding
issues
with
reworks.
The
blockchain
can
be
reorganized
when
there
are
competing
chain
chains.
At
the
same
time,
and
to
not
get
in
troubles
with
such
situations,
we
are
using
breaks
between
the
phases,
which
are
something
like
minimum
ten
blocks.
B
B
You
are
requesting
all
the
blocks
from
Bitcoin
from
your
local
Bitcoin,
core
client
and
with
all
those
blocks.
You
are
verifying
which
which
transactions
are
psq
transactions
and
you
are
building
up
this
filtered
list
of
transactions
yourself.
The
light
node
is
also
doing
the
full
verification.
It
just
gets
the
pre-filtered
Bitcoin
or
input,
or
there
Bitcoin
transactions
from
a
signaled
as
when
there
are
usually
there
something
like
2,000
transactions
in
one
block.
B
Maybe
we
have
done
two
or
five
or
ten
bsq
transactions
in
one
block
and
the
light
note
will
receive
those
five
transactions
from
seed
note.
The
full
note
is
requesting
all
2000
transactions
from
a
local
Bitcoin
node,
and
this
idea
is
passing
all
those
and
then
we'll
find
out
that
only
five
transaction
where
relevant
for
PS
q
and
then
stores
locally
those
five
transactions.
B
B
B
All
those
data
will
be
subject
for
changing
and
or
in
the
book
they
can.
They
can
give
their
their
voice
on
that
their
data
will
be
encrypted
and
published
should
appear
to
peer
network.
So
everybody
can
see
that
somebody
has
voted
us
that
there
will
be
created
a
transaction
as
well,
but
nobody
can
read
what
has
really
been
worked
at
home,
but
the
voter
cannot
change
his
vote
anymore,
because
everything
is
hashed
in
there
in
the
Bitcoin
transaction.
B
So
it's
basically
time
stand
what
you
have
voted,
then
after
the
blind
vote
there
is
a
break
again
and
other
blind
good
face
will
take
a
few
days.
Maybe
three
four
days
something
like
this,
then
there
is
a
short
break
again.
What
are
avoiding
the
rework
problems,
and
then
there
is
the
vote
for
a
real
face
where
everybody
who
has
voted
need
to
be
online.
B
In
this
moment,
it
doesn't
have
to
do
anything
actively
the
application
itself
when
it
recognizes
that
it's
in
the
vote
revealed
face,
and
it
has
not
revealed
already-
that
it
will
create
a
transaction
and
send
out
this
transaction
to
the
Bitcoin
network.
There
is
no
peer-to-peer
network,
they
turn
in
that
face,
and
this
vote
reveals
transaction
contains
the
secret
key,
which
was
used
to
encrypting
the
blind
vote.
So
everybody
can
look
up
then,
in
the
from
the
blockchain
later,
the
secret
key
and
from
that
moment
on,
can
decrypt
this
blind
vote.
B
So
when
one
voter
has
have
been
online
in
this
face,
he
has
published,
or
his
transaction
with
the
secret
key
and
all
the
other
users
can
will
receive
this
and
can
decrypt
this
particular
vote
and
at
the
end,
after
at
the
end
of
the
face,
there
will
be
the
result
face
again
after
break
in
the
result.
Phase
every
node
is
collecting
all
those
blind.
Both
transactions
are
we'll
look
up
all
their
blind
boats
and
the
blind
road
transactions
and
and
then
can
decrypt
the
blind
roads
and
from
the
blind
votes.
B
They
see
the
proposal
and
they
see
in
the
plan
votes.
They
see
also
the
what
the
use
has
voted
on.
So
with
the
result,
in
the
result
phase
you
have
all
the
data
available
and
every
node
can
calculate
the
total
result.
After
after
the
voting,
there
will
be
a
threshold
for
a
quorum
and
for
if
the
would
have
succeeded
or
not,
that
will
be
different
for
different
types
of
proposal
like
for
compensation
requests.
Usually
it
will
be.
Minimum
50%
does
need
to
be
a
little
bit
more
like
50%
for
other
proposals
like
changing
a
parameter.
B
It
might
be
a
higher
threshold
like
70%,
and
there
will
be
a
quorum
in
bsq.
How
much
stake
there
have
yeah
how
much
the
stake
in
total
is
required
that
the
vote
is
considered
well
it.
So
when
a
minority
stakeholder
was
the
only
one
who
was
interested
in
one
proposal
and
has
voted
on
this,
it
will
not
be
accepted.
B
B
Then
there
is
a
blind
boat
transaction
where
again,
the
opera
turn
of
this
flying
goat
payload
is
indra.
The
hash
of
the
blind
book
payload
is
in
top
return,
and
then
there
is
a
boat
reveal
transaction,
where
the
secret
key
plus
the
hash
of
the
blind.
Both
lists
is
in
the
is
in
the
opportunity,
and
this
hash
of
the
blind
both
lists
a
little
bit
a
tricky
concept.
B
So
we
have
to
be
sure
that
everybody
has
exactly
the
same
date
of
view
from
what
what
they're,
using
for
creating
or
calculating
the
result
and
for
generating
a
consistent
and
a
well-defined
or
date
of
view.
The
voters
themselves
when
they
do
in
the
reveal
transaction,
are
doing
a
kind
like
voting
on
the
maturity
date
of
view.
B
So
every
voter
when,
when
they're
making
the
reveal
transaction,
they
have
received
a
certain
number
of
blind
boat
data
objects
from
the
peer-to-peer
network,
and
they
they
put
this
into
a
list
sorted
by
transaction
ID
and
create
a
hash
of
this
and
put
the
hash
into
their
reveal
transaction
and
with
the
stake
or
what
they
have
voted
on.
We
can
find
out
what
the
majority
are
of
the
voters.
B
Maturity
by
stake
has
seen
in
the
network,
so,
for
instance,
when
there
are
ten
voters
and
one
voter
has
only
received
nine
out
of
ten
blind
vote
data
objects
and
the
other
have
received
all
the
ten.
Then
the
majority
will
be
ten
at
the
hash
of
the
ten
blind
vote
data
and
the
one
with
the
nine
when
it
comes
to
the
result
face.
He
will
discover
that
his
hash
what
he
has
locally
his
stator,
does
not
match
with
the
majority
with
the
hash
of
the
maturity.
B
So
he
see
that
he's
in
an
invalid
state
basically
and
need
to
get
this
missing
data,
so
he
meet
and
request
from
the
pew
pew
Network
that
this
missing
blind
vote
and
maybe
proposal
datum
and
as
soon
as
he
has
all
the
tape,
they
can
also
participate
in
the
calculation
of
the
of
the
result.
So
that's
a
little
bit
of
tricky
thing
and
I'm,
not
hundred
percent
sure
if
it
was
too
fast
to
really
understand
it,
we
can
discuss
it
later.
Sorry,.
A
B
B
Everybody
has
the
same
blockchain
data
so
when
you
would
not
be
online
as
a
voter
and
would
not
create
your
work,
reveal
transaction
you
about
this
chest
invalid
and
will
not
be
considered
and
when
you
would
not
have
when
you're
a
peer-to-peer
network
data
would
not
have
been
published
because
of
bad
Network
situations
or
whatever,
and
only
that
transaction
would
be
there.
Then
it's
also
invalid,
because
we
are
in
the
next
step.
B
You
will
look
up
for
this
peer-to-peer
network
data
for
the
blind
vote
and
also
that's
in
the
plan
work,
because
the
revealed
transaction
doesn't
have
a
European
Network
date.
That
has
only
a
transaction
alone,
but
the
reveal
transaction
are.
There
is
an
important
link
between
the
blind
hole,
transaction
and
reveal
transaction.
This
is
you
are
voting
mistake
so
with
you
put
in
the
blind
mode
transaction.
B
Some
psq
are
into
the
transaction
and
in
this
in
the
output
of
this
blind
road
transaction,
this
bsq
are
locked
for
who
are
working
and
the
revealed
transaction
is
spending
this
lock
bsq
and
it's
unlocked
afterwards
and
with
yeah
with
this
output
from
the
blind
road
transaction,
which
is
the
input
for
the
reveal
transaction.
We
a
clear
link
of
those
two
transactions
on
the
blockchain
as
well.
B
I
need
to
be
the
transaction
to
need
to
be
the
peer-to-peer
network
data
and
only
if
everything
is
as
expected,
it's
considered
valid.
Otherwise,
it's
ignored
and
it's
not
considered
for
the
total
result.
So
when
there
will
be
inconsistency,
then
it's
just
erm
yep
there
is
one
vote
less
or
one
Prabhu's
less
and
in
the
total
result
calculation.
B
This
inconsistency
problems
are
more
theoretical
problems,
because
we
will
add
a
lot
of
resilience
that
they're
publishing
of
those
peer-to-peer
network
data
will
happen
multiple
times
and
it
will
be
very
resilient.
So
I
don't
expect
that
in
practice
it
will
happen,
but
of
course
we
have
to
deal
with
it
and
especially
could
be
an
attack
vector
or
a
malicious
peer
and
could
could
try
to
attack
them
that
our
by
when
there
would
be
some
weak
point
here
that
or
it
would
lead
to
inconsistency.
That
would
be,
of
course,
very
bad.
B
Okay,
the
only
the
only
open
problem
in
a
way,
but
we
don't
consider
this
as
a
it's.
A
problem
we
we
deal
with
is
a
majority
attack,
so
when
the
majority
of
the
voters
would
sabotage
the
tower
would
attack
the
Dow
by
holding
back
the
blind,
rotator,
let's
say:
I'm
the
majority
and
I
want
to
kill
the
Dow.
Then
I
could
make
a
blind
boat
transaction
with
my
own
client
boat
or
peer-to-peer
network
dater
included,
but
I
will
not
publish
it.
B
So
nobody
else
has
a
chance
to
receive
this
data
and
nobody
else
has
a
chance
to
get
to
the
same
or
hash.
I'm
or
maybe
a
group
of
people
are
the
majority
stakeholder.
They
can
create
this
maturity
date
of
view,
and
then
nobody
can
calculate
the
result,
because
nobody
has
this
blind
boater
data.
What
I
have
not
published
and
with
that
everybody
would
try
to
get
this
data.
B
Nobody
can
get
it
because
I
we
hold
it
back
and
then
it's
a
inconsistent
state
because
nobody
can
calculate
the
result,
but
that's
a
majority
attack
when
the
majority
of
the
stakeholders
want
to
kill
the
Dow
or
their
own
investment.
Okay,
then
they
can
do
it
and
somebody
will
work
the
project
and
will
take
over
so
I'm
there.
It's
the
basic
situation
in
a
Tao
or
when
their
majority
of
the
stakeholders
are
evil
and
want
to
break
the
Dow
yeah.
They
can
do
it,
but
the
worst
thing.
B
So
it's
not
really
rational
to
do
this,
and
also
by
voting-
and
here
also
with
the
stake
at
the
moment,
we
only
use
the
stake,
but
in
future
it
will
use
the
reputation.
So
the
more
a
stakeholder
has
earned
really
with
contribution
the
more
influence
he
will
have
in
voting.
So
we
will
have
a
different
or
a
secondary
influence
factor
for
calculating
the
weight
of
the
boat,
which
will
be
not
only
the
state
but
which
will
be
the
issuance.
B
What
are
what
the
rotor
has
created
for
himself
so
yeah
when
somebody
has
worked
already
one
year
for
a
bisque
and
has
issued
100,000
bsq
for
himself,
then
100,000
psq
will
be
or
a
big
part
for
his
boat
weight
and
yeah.
Probably
something
like
70%
comes
from
this
reputation
and
only
30%
comes
from
steak,
so
this
maturity
attack
will
then
be
even
more
limited
that
there's
a
whale
with
a
lot
of
money
and
who
buy-in
into
the
Tao
cannot
do
so
much
harm.
B
Only
those
who
have
really
worked
for
the
Tao
and
then
when
they
want
to
hurt
it.
Then
something
is
very
strange.
Probably
and
I
mean
this
with
this
maturity
date.
The
view
is
this
clear:
should
I
explain
a
little
bit
more
in
detail
or
a
little
bit
slower,
and
maybe
it
was
a
little
bit
too
fast.
Maybe
I
go
over
it
again
there
there
could
be
the
situation
that
are
yeah,
that
one
motor
was
very
badly
connected
with
Internet
and
his
blind
rotator
was
not
spread
in
the
network,
so
he
himself
sees
his
own
pride.
B
Won't
it
about
nobody
else,
so
he,
when
he
comes
later
than
to
the
results
this
he
has,
for
instance,
10
different
blind
road
transactions
and
data
and
proposals
and
so
on,
and
he
will
have
a
different
end
result
because
maybe
he
rejected
a
proposal
and
he
was
just
the
influencing
factor
if
proposed,
look
at
the
50
percent
or
not,
and
all
the
others
have
accepted
it
and
will
will
get
a
different
result.
So
all
the
other
in
the
network,
which
only
have
9
blind
vote
dater,
will
maybe
get
for
a
certain
computation
request.
B
B
They
tell
the
world
their
yeah,
which
version
of
the
data
they
have
so
or
all
the
others
have
only
nine
blind
vote
data
as
a
European
Network
data
and
create
a
hash
from
this
list,
and
this
one
guy
has
tens.
We
will
get
another
different
hash
and
he
put
on
his
this
hash
into
the
opera
turn
in
the
work
reveal
transaction.
The
others
do
that
well
as
well
and
on
the
blockchain
side.
We
never
have
this
problem
with
inconsistency,
because
everybody
has
exactly
the
same
view
on
the
blockchain.
B
The
only
risk
on
the
blockchain
side
would
be
with
reworks.
It
could
be
in
a
rework
time
that
you
are
following
in
the
chain
with
this
trend
with
this
block
and
the
others
are
following
a
chain
with
another
block,
and
this
block
contains
a
transaction,
the
other
block,
not
so
that
could
be
theoretically
a
difference,
but
that
avoided
with
with
this
breaks
so
for
before
we
are
starting
any
important
or
phase.
B
We
always
wait
the
few
blocks,
so
we
don't
have
any
reworks
problem
because
area,
because
the
data,
what
we
are
taking
out
of
the
transaction,
is
already
buried
deep
in
the
blockchain,
and
it
is
not
changed
anymore
and
because
this
hash
is
in
the
blockchain,
we
have
a
unique
few.
What
is
the
maturity?
B
A
B
Then
I
jump
to
the
next
part,
yet
a
peer-to-peer
network
data
we
covered
already
a
lot
of
this.
We
have
basically
two
data
which
are
published
to
the
peer-to-peer
network.
Once
is
the
proposal
payload
and
it
contains
there
I
call
the
payload
because
they
get
always
dropped
in
some
messages
and
some
or
it's
some
other
object
which
are
distributed
in
the
peer-to-peer
network
and
payload.
B
Is
you
have
the
name
to
to
to
keep
it
different
from
the
proposal
itself
as
a
data
object
yeah
it
contains
the
transaction
T
of
the
proposal
transaction
the
same
with
the
blind
vote
and
for
yeah,
as
I
said
for
the
book
reveal.
We
don't
have
a
peer-to-peer
network,
they
there's
only
the
transaction
where
the
secret
key
and
the
hash
is
in
the
operation.
The
secret
key
is
quite
small,
I
think
it's
16
bytes
and
the
hash
is
20
bytes.
So
it's
not
really
a
lot
of
data.
B
What
we
are
putting
in
there
and
it's
not
a
lot
of
transactions
it's
or
only
the
waters
so
like.
In
the
current
situation,
we
have
around
10
contributors
who
are
making
requests
and
who
are
working
so
that
would
be
proposal
transactions
and
then
ten
Blanco
transactions
and
10.
Then
10
reveal
transactions.
B
All
the
transactions
have
a
fee
attached
beside
per
blind.
The
work
revealed
that
comes
without
fee
and
the
fee
can
be
changed
also
at
the
beginning
it
will
be
rather
low,
but
it's
good
to
have
it
as
a
kind
of
like
a
regulation
element.
When
we
get
too
much
voters
who
are
not
really
well
informed
about
the
Tao,
we
can
increase
the
field,
we
will
can
use
a
management
function
and
not
democratic
right.
B
Here
at
the
passing
of
the
blockchain,
so
a
full
note,
we
are
said
before
we
have
a
full
note
on
a
light
note
model.
The
security
differences
are
similar
like
with
the
SPV
model.
There
the
light
note
model
or
the
light
note
is
trusting
the
full
note
which
is
delivering
him
or
filtered
psq
transactions
that
he
has
not
hold
back
held
back
any
psq
transaction,
but
he
is
doing
the
whole
verification.
So
the
worst
thing.
B
What
could
happen
is
that
the
seed
note
is
not
sending
some
vsq
transaction
and
then
there
will
be
a
problem
or
but
the
light
not
will
receive
this
from
several.
As
at
the
beginning,
we
will
use
the
seed
notes
for
this,
for
convenience
and
for
performance
reasons,
but
basically
it
can
be
any
specialized
note
and
of
course,
every
every
user
can
run
their
own
full
note
and
can
set
up
their
own
full
note
to
connect
to
so
but
for
convenience.
Most
people
probably
will
not
do
this
and
they
will
receive
this
data
from
multiple
notes.
B
So
when
one
seed
note
would
be
compromised
and
would
deliver
a
smaller
subset
of
transactions,
it
will
be
discovered.
Very
quickly,
and
then
that's
like
that,
will
start
over
again
and
yeah
The
Fool
not
run
spit.
Concur
with
our
PC
set
up
it
iterates
all
the
Bitcoin
transactions
and
filters
for
the
psq
transactions.
A
PA
children
section
is
the
transaction
which
is
which
has
any
PS.
B
Q
is
input,
so
the
only
exception
is
the
Genesis
transaction,
because
the
other
is
of
course,
no
PS
q
input
and
then
all
the
outputs
of
the
Genesis
transactions
are
potential
inputs.
When
you,
oh,
I
production
inputs
when
you
PS
q
transactions
and
are
all
the
other
relevant
or
pious
q
transactions,
for
instance,
for
paying
the
trading
fee.
B
They
carry
yeah.
They
also
have
the
PS
q
is
input,
a
single
all
those
transaction
FPS
q
is
input
and
as
well.
They
have
special
operation
types
where
we
can
verify
if,
if
a
special
transaction
might
be
a
PS
q,
a
transaction
or
not,
so
we
are
filtering.
Basically
the
Bitcoin
transactions
with
a
small
subset
of
the
PS
q
transactions,
and
we
are
storing
this
in
our
own
data
structure
and.
B
Yeah,
their
light
nodes
are
just
receiving
this
filter
block.
So
the
only
really
difference
is
that
the
lightener
is
doing
this
passing
through
all
the
transactions
in
the
blockchain
and
me
and
don't
need
to
get
all
the
transactions,
because
that
would
be
too
heavy
and
it's
doing
the
whole
orientation
said
already.
B
B
In
the
meantime,
you
were
passing
the
new
blocks
and
you're
changing
the
state
and
when,
when
it
comes
to
next
block,
I'd
hate
where
height
yeah,
when
you
come
to
the
next
block
height,
where
it's
triggering
a
snapshot,
you
are
persisting
the
next
snapshot
and
that
will
be
used
for
the
next
addict.
We
also
shipping
those
snapshots
in
every
release.
B
So
when
a
new
users
downloading
disk,
he
will
have
already
the
snake
snapshots
on
the
release
date
and,
as
we
have
usually
releases
every
months,
it's
more
or
less
maximum
one
months
what
he
need
to
pass,
I
tested
it
that's
more
or
less
4000
transactions
and
no
4000
block.
Sorry,
and
with
what
out
in
proxy
yeah
I
thought
to
have
not
estimated
it
with
with
rill
with
we
are
more
or
less
realistic
data,
but
with
more
or
less
empty
blocks.
It
takes
a
few
seconds
to
verify.
B
The
whole
month,
so
it's
not
really,
and
it's
only
a
one-time
effort.
It's
basically
when
you
were
starting
up
bisque
after
one
months.
It
also
takes
on
a
bit
coincide
quite
a
lot
and
it's
a
little
bit
heavy
for
one
of
the
community.
You
need
to
wait
until
your
sister
and
we
are
adding
a
little
bit
of
a
float
here
on
the
outside,
because
there
for
verifying
all
the
blocks.
In
the
meantime,
since
the
last
snapshot,
it
will
take
a
little
bit
of
float,
but
it's
not
terrible.
B
That
brings
us
to
the
next
topic
with
reading
in
yeah,
an
earlier
version
or
just
recently,
I
used
a
special
thread
for
the
passing
and
what
RPC,
but
at
the
end,
that
led
to
or
maybe
I
explain
a
little
bit
more
the
basics
about
this
reading
before
getting
to
the
problems,
as
the
RPC
part
is
really
slow.
We
sliced
it
those
ways.
B
B
That
code
is
much
more
simple
and
much
more
clear
and
much
more
solid,
so
consistency
and
correctness
is
the
most
important
edit
out
when
we
would
have
any
situation
where,
because
of
threading
issues
or
whatever
we
would
get
a
different
state
in
certain
situations,
it
will
break
that
out.
Basically,
it
will
break
at
least
for
this.
Use
of
this
user
will
get
a
different
view,
a
different
result,
and
there
will
be
inconsistency.
So
that's
by
far
the
most
important
thing
to
have
fully
100%
consistency
and
correctness
and
performance
of
course,
is
important.
B
That's
not
terrible
bad
in
my
opinion,
and
we
can
improve
this
in
future,
but
I
I
think
it
would
be
not
the
right
decision
at
the
moment
to
use
a
more
risky
model
and
risk
that
we
are
introducing
consistency,
problems
and
I
had
this
earlier
just
one
week.
Basically,
I
moved
to
this
model
and
before
there
was
a
the
passing
also
in
this
RPC
thread,
and
then
we
had
initially
we
had
locks
in
this.
B
B
B
It's
only
reading
from
there
from
the
state,
but
not
really
critically,
but
at
the
end
it
was
so
getting
super
complicate
and
and
slow
and
tricky
internet
tried
out,
occur
as
well,
but
I
think
I
could
would
not
be
the
right
model
for
what
is
because
we
don't
want
to
have
a
system
where
you
have
all
kind
of
independent
nodes
which
are
doing
their
stuff
and
are
very
not
not
connected
in
a
in
a
control
perspective,
they're,
very
independent
and
parallel.
That's
not
the
use
case.
B
What
we
have,
we
have
a
very
clear
flow
of
control
and
the
ordering
of
stuff.
What
need
to
happen
is
completely
clear,
defined
and
and
imp
and
relevant,
and
at
least
it
would
have
probably
required
the
you
try
factoring
and
different
thinking
without
grant
and
we
would
not
have
sold
em.
It
I
think
it
would
not
have
been
a
the
right
solution
as
well.
So
at
the
end,
I
went
back
that
I
only
use
this
one
thread
for
the
RPC
calls.
B
The
RPC
calls
could
be
easily
optimized
when
we
would
extend
the
RPC
API
on
the
Bitcoin
side
that
we
will
add,
we
would
add
a
new
call
where
we
get
all
the
transactions
with
one
call
for
one
block,
then
we
don't
have
2000
RPC
calls,
but
only
one-
and
it's
probably
instead
of
for
a
second
RPC
overhead,
it's
probably
something
like
0,
comma,
2,
second
or
something
or
even
faster.
So
that
would
be
a
very
low
hanging.
Fruit
for
for
huge
improvement
and
yeah,
of
course,
in
future,
can
be
improved.
B
When
somebody
comes
and
thinks
we
should
use
a
special
thread
for
the
passing
and
he
is
doing
it
in
a
in
a
hundred
percent
or
correct
way-
I'm
not
against
it.
I
just
want
to
lose
another
months
or
more
and
half
at
the
end,
the
model
which
is
more
vulnerable
and
maybe
a
little
bit
faster.
It's
also
not
clear
how
much
you
gain,
because
threads
has
overhead
and
so
on.
B
Yeah
and
it's
I
mean
now-
it's
also
not
hundred
percent
clear.
If
we
are
running
a
light
note
by
default
or
if
by
default
it's
off
and
only
when
a
user
is
using
disk,
he
will
become
a
light
note
because
yeah
it
doesn't
when
somebody's
not
interested
in
psq
at
all
and
doesn't
use
it
for
trading
fees.
B
Why
should
he
do
this
work
at
all?
So
probably
there
will
be
kind
of
like
a
mode
where
you
only
start
to
become
a
light
note
when
you're
actively
doing
anything
with
psq,
so
it
would
not
hurt
normally
area
I
mean
we
would
like
that
all
our
users
are
using
psq
for
paying
the
trading
fees
so
at
the
end,
yeah
not
clear
how
we
deal
with
this
but
I.
Think
it's
not
not
a
big
big
deal.
B
I
mean
it
would
be,
maybe
a
little
bit
a
problem
when
we
would
have
not
no
release
for
three
months
or
six
months
and
then
instead
of
four
seconds.
Maybe
it
takes
one
minute
to
to
do
the
passing
or,
if
you
10
or
20
seconds,
but
even
compared
with
bit
crunchier
I
mean
when
you
are
when
you
have
not
started
or
when
you
are
first
downloading
or
it's
different
with
this
country.
It's
more
yeah
when
you
have
an
old
wallet
and
you
have
not
used
it
for
a
few
months
and
then
you're
starting
it
again.
B
A
B
B
Maybe
we
call
it
PS,
q,
state
or
blockchain
state
or
whatever
at
the
moment
it's
called
state
and
it
consists
of
a
list
of
blocks
every
time
when
a
new
block
arrives
on
the
Bitcoin
blockchain
it
get
passed
and
filtered
for
PS
q
and
during
the
passing,
we
are
setting
all
kind
of
other
mutual
state
in
this
in
this
state
class
like,
for
instance,
unspent
transaction
output
map.
So
there
as
a
map
of
the
unspent
output,
when,
in
this
block,
one
of
the
previous
unspent
transaction
output,
was
used
as
input
for
him.
B
Please
queue
transaction,
it
changes
this
map
and
this
unspent
transaction
output
get
removed
and
a
new
one
when
several
new
ones
get
added
and
the
block
itself
contains
a
list
of
transactions.
Transactions
contains
a
list
or
lists
of
inputs
and
outputs.
It's
the
same
structure
like
in
Pritikin
itself
and
the
block
itself
and
all
inside
is
immutable.
So
once
a
block
is
edit,
it
cannot
be
changed.
The
lists
are
immutable
lists
and
so
on
only
they're.
B
The
root
level
of
the
state
data
model
is
mutable
because
yeah
we
want
to
add
new
blocks.
We
cannot
use
the
immutable
list
there,
but
once
a
block
is
added,
it's,
it
cannot
be
changed.
It
contains
also
the
sitings
a
cycle
contains
a
list
of
faces.
As
one
cycle
is
this
one
months
and
there
are
faces
our
proposal
and
under
the
voting,
the
blind
voting
and
vote
reveal
intent
a
result
face
and
because
the
duration
of
a
face
could
be
changed
in
future.
B
By
voting
we
we
we
have
to
keep
this
flexible
with
use,
just
a
enum
which
is
set
yeah,
which
is
static
so
yeah.
We
have
Tayna
basically
as
a
type
value
in
the
face,
and
then
the
duration,
which
could
be
changed
by
voting,
and
then
there
is
a
ballot.
A
ballot
is
a
collection
of
a
proposal
plus
a
vote.
B
So
when
you
are,
when
you
are
actively
voting
a
bond
proposal,
you
are
locally
creating
a
ballot
and
yeah
collects
the
data,
but
you
have
voted
on
a
special
proposal,
so
the
proposals
are
wrapped
in
those
ballots.
With
your
votes
on
that
when
you're
not
voting,
the
vote
is
set
to
null.
Otherwise
the
vote
has
the
value.
What
you
voted
on
and
the
blind
vote
contains
group.
That's
not
correct
anymore.
Here.
I
change
recently
changed
this,
but
I
don't
want
to
go
into
the
details,
but
basically
it
contains
their
encrypted
list
of
the
pellets.
B
So
what
you
have
voted
and
yeah
which
proposals
you
have
voted?
What
which
is
expressed
as
the
ballot
object?
The
list
of
those
ballots
get
encrypted
and
gets
published
to
the
European
Network,
then
the
mutable
path
have
said,
or
the
state
has
a
linked
list
of
blocks.
That's
basically
like
that
which
can
block
chain.
B
B
Okay,
input
is
now
spent
now
used
in
a
psq
output,
so
the
input
which
were
connected
to
a
previously
unspent
transaction
could
get
removed
from
this
unspent
transaction
output
map
and
then,
when
the
output
at
the
end
are
well,
it
to
output,
get
edit
and
so
on
and,
as
I
said
before,
we
are
using
our
snapshots,
which
get
persisted
to
disk.
To
avoid
that,
we
rerun
the
whole
validation
all
the
time.
It's
basically
the
same
like
in
Bitcoin
when
you
use
Bitcoin
core
the
first
time.
B
You
are
validating
everything
and
it
takes
quite
a
while,
but
the
next
time
you
started.
You
are
not
revalidating
everything
you
have
snapshot
of
this
latest
validation
state
and
only
new
data
which
have
arrived
in
the
meantime.
New
blocks
get
validated,
but
not
the
stuff
that
you
have
done
already.
B
But
of
course
you
can
always
rerun
it
from
the
source
when
you
just
delete
the
snapshot
that
will
be
able
to
feature
in
their
application
that
also
snapshots.
What
we
are
delivering
are
shipping.
With
the
code
you,
you
always
can
to
go
to
the
very
bottom
and
delete
this
and
go
back
to
the
Genesis
transaction.
Do
everything
yourself
and
don't
trust
anybody
yeah
and
there
is
different
resilience
from
the
data
sources-
think
it's
very
important
to
to
understand.
B
Well,
this
special
situation,
what
we
have,
what
makes
us
different
to
a
normal
blockchain
project
that
we
are
combining
two
different
data
sources:
one
is
the
Bitcoin
blockchain
and
the
Bitcoin
block
chain
has
ultra
high
resilience.
So
basically
we
can
trust
that
everything
which
is
deep
in
the
blockchain
will
not
change.
That's
the
promise
of
Bitcoin
and
the
value
of
Bitcoin.
B
We
have
this
special
mechanism
with
this
maturity
hash
to
make
sure
that
it
doesn't
cause
a
problem.
But,
of
course
when,
when
only
20%
of
the
votes
arrive
at
their
peers,
it
would
be
also
pretty
bad,
because
people
want
to
vote
an
older
or
the
proposal
and
not
only
small
subset,
but
luckily
the
peer-to-peer
network
is
very
stable.
The
only
problem
what
we
had
so
far
was
related
to
the
Tor
network
issues
a
few
months
ago,
but
even
there
it
was
not
terrible,
better
push.
B
There
was
issues
but-
and
we
will
add
extra
resilience
here-
that
we
are
publishing
or,
for
instance,
at
every
startup
when
you
create
a
proposal
every
time
when
you
are
setting
up
your
republishing
your
proposals
again
in
the
blind
vote
phase,
when
you
vote
on
a
certain
set
of
proposals
or
what
all
the
promotes.
What
you
see
you
re
publishing
those
proposals,
so
it
will
be
a
yeah.
We
will
add
a
lot
of
resilience
and
in
practice,
I
think
we
will
not
have
inconsistency.
B
But
of
course
we
have
to
deal
with
this
and,
as
I
said
before,
they're
blind
votes
get
decrypted
from
there
from
the
P
in
the
revealed
book
transaction
and
the
other
plan
code
containing
the
bailout.
Second,
the
ballots
contained
err
I
mean
that's
not
super
correct
anymore,
because
that
I
wrote
with
they're
a
little
bit
older
version
a
few
days
ago
were
really
encrypted.
The
whole
pellet
list
into
the
blind
wrote,
but
then
we
would
have
basically
published.
B
We
would
create
too
much
data
because
our
when
there
are
ten
proposals
and
ten
voters,
then
every
every
blind
vote
would
contain
all
the
ten
proposals.
And
then
we
would
have
in
the
network
100
times
the
proposals
we
only
needed
ten
times
not
hundred
times
now.
I
changed
is
that
only
the
transaction
ID
isn't
there
in
the
blind
vote
list
and
the
lookup
for
the
proposal
is
done
separately
and
or
it's
yeah.
It
scales
much
better
in
that
way,
but
yeah
from
the
conceptual
side,
a
blind
boat
is
containing
the
ballots.
B
B
B
B
Then,
when
we
entering
the
blind
vote
face
similar
happens
with
the
blind
vote,
you
yeah,
you
select,
you
have
a
list
of
the
proposals,
you
select
the
proposals
and
vote
on
every
proposal
when
you,
when
you
are
finished
or
when
you
think,
okay,
I'm
fine,
I,
voted
on
everything.
Then
you
create
the
blind
vote
transaction
and
your
blog
publishing
your
list
of
pellets
to
the
peer-to-peer
network.
B
B
So
when
you
create
the
offer
you
and
the
only
one
who
can
remove
the
offer
the
same
with
the
proposal
when
you
are
creating
a
proposal
you're
the
only
one
who
can
remove
the
proposal.
Additionally,
what's
not
used
in
the
office
as
the
office
are
only
held
in
memory,
they
are
not
persisted
locally
and
that's
not
required
because
they
are
short
living
objects
and
we
don't
actually
want
to
have
offers
which
are
not
life,
but
with
proposals
or
yeah.
B
They
live
for
three
or
four
weeks
during
the
proposal
phase
and
we
want
to
have
more
resilience
that
proposals
are
really
100%,
because
this
yeah
available.
For
this
reason
we
are
persisting
those
data
as
well,
but
are,
as
you
could
remove
this
data.
They
are
not
super
reliable,
so
we
don't
want
to
rely
on
this
data
structure
out
in
the
first
moment.
B
In
the
proposal
phase,
we
are
just
storing
it
in
the
European
Network
data
structures,
but
we
are
not
really
using
those
data
for
important
stuff
later
for,
like
for
calculating
the
result,
but
when
we're
entering
the
blind
would
face
the
use
case,
we're
removing
a
proposal
is
not
well
it
anymore.
So
the
third
guy
who
is,
but
we
have
no
guarantee
that
the
proposal
owner
is
still
online.
Maybe
it
was
just
one
time
online
when
creating
the
proposal
and
and
goes
on
one
again
it
at
the
end
of
the
result.
B
So
we
cannot
rely
sorry,
we
cannot
rely
that
he
will
republish
his
proposal
in
a
in
a
securitate
structure.
So
the
voters
are
doing
this
and
because
every
voter
will
publish
all
the
proposals
what
they
have
there
will
be
a
high
return,
Dhin
see
and-
and
this
data
now
will
not
carry
the
the
public
key
and
and
is
not
protected
by
a
signature
because
yeah
there
is
no
use
case
for
removing
this
data
and
for
just
adding
it
to
local
data
structure.
B
So
that
will
be
own
data
file
for
this,
for
the
proposals
and
then
later
for
applying
votes,
and
that
will
be
then
account
like
a
immutable
data
structure
with
which
can
be
only
appended
in
a
certain
phase
and
then
it's
frozen
and
or
cannot
be
changed
anymore.
Oh
sorry,
you
can
be
appended
anytime,
but
you
cannot
remove
data
from
this
yeah
when
we
are
entering
the
vote
reveal
phase.
B
We
are
publishing
the
work,
reveal
transaction
that
doesn't
contain
any
peer-to-peer
network
stuff
and
when
we
are
entering
and
the
application
is
doing
this
by
itself,
the
user
don't
need
to
do
anything
important
for
the
users
that
he
get
unlocked
his
stake.
So
when
he's
voting,
he
has
locked
his
stake.
What
he
was
used
using
for
voting
when
he
would
you
spent
this
stake,
it
would
render
his
vote
invalid.
B
B
The
only
thing
is,
the
only
requirement
is
that
the
voters
need
to
be
online
in
this
time,
but,
of
course,
we
need
to
communicate
as
well
in
the
application
that
they
know
about
it,
but
they
only
need
to
startup
concerned
once
you're
connected
to
the
peer-to-peer
network
they
can
shut
down
again
when
entering
the
results
phase.
We,
the
application,
is
calculating
the
result
that
happens
also
automatically
without
user
interaction
and
yet
they're
taking
all
the
ravine
transactions.
Then
all
the
blind
road
transactions
from
the
reveal
transaction.
B
There
is
the
connection
to
the
blind
road
transaction
because
it
uses
their
output
of
the
stake
as
a
one
input
for
the
ravine
transaction
will
be
the
output
where
the
user
has
put
the
stake
for
the
wilderness.
That
must
lead
to
the
correct
ground,
road
transaction
and
from
there
we
have
the
hash
to
the
blind,
rotator
and
the
blind.
Both
data
contains
their
proposals.
B
We
can
look
up,
then
the
proposal
transaction
and
the
proposal
transaction
has
to
hash
after
the
proposal
data-
and
we
know
the
proposal
and
we
yeah
in
the
blind,
boat
or
date
in
the
decrypted
blind
vote
data.
We
have
the
boats
and
we
have
all
the
data
basically
to
calculate
the
total
result.
We
are
checking
if
our,
if
we
have
all
blind
vote,
all
blind
boats
which
are
which
have
been
used
for
creating
this
hash.
B
Yeah,
we
are
calculating
the
result
at
all
covered
I
made
here,
a
small
drawing
about
the
phases.
I
said
beginning
here,
just
a
recap.
What
I
said
already,
but
maybe
visually
it's
a
little
bit
easier
to
follow.
I
will
show
afterwards
in
the
application.
It's
a
little
bit
more
concrete.
We
have
this
proposal
phase
where
people
are
doing
where
we
have
basically
are
yeah
three
use
cases.
One
is
creating
a
proposal
and
others
are
removing
your
proposal
and
the
other
is
receiving
or
collecting
proposals
from
the
network
and
creating
a
proposal
has
two
different
actions.
B
One
is
creating
a
proposal
transaction
to
the
blockchain
to
the
Bitcoin
network
and
one
is
creating
the
proposal
payload
to
the
peer-to-peer
network.
Then
we
entering
after
the
break.
This
is
a
blank
vote
face
here.
It's
similar.
We
are
creating
a
blind
boat
with
two
actions.
One
is
the
blindfold
transaction
and
one
is
to
create
the
publishing
of
the
blind
vote
payload
and
we
are
receiving
blind
both
payloads
from
the
peer-to-peer
network.
There
is
no
use
case
or
no
feature
for
removing
a
blind
vote.
B
We
will
not
support
this,
but
it's
a
possible
feature
in
future,
so
we
it's
all
built
in
the
way
that
it
could
support
it,
and
then
yeah
and
and
at
the
moment
when
you
are
publishing
your
blind
vote
payload,
you
re
publishing
all
your
proposals
and
then
it
gets
thought
in
a
different
data
structure
before
their
proposal
in
the
peer
to
peer
network
was
thought
in
this
state.
The
structure
which
is
protected
by
the
public
key
and
which,
where
you
could
remove
data
as
well,
and
this
removal
would
be
a
problem
for
later.
B
B
So
it's
really
important
that
we
are
taking
here
that
important
data
suus
further
consensus
is
immutable
stored
somewhere
and
the
Bitcoin
part
is
delegated
to
the
Bitcoin
network
and
the
peer-to-peer
network
part
is
consisting
of
those
proposals
and
the
blind
votes
and
I
said
before
we
are
using
now
this
append-only
data
structure,
where
there
is
no
technical
ability
to
remove
data
from
there
and
you
are
adding
as
the
water.
You
are,
adding
all
your
proposals
to
this
state.
B
The
structure
at
the
moment
when
you
are
creating
your
blind,
boat,
payload
and,
of
course
there,
because
when
somebody
else
has
the
same
proposals,
it
will
result
in
the
same
hash.
So
there
will
not
be
duplicate
of
this
data,
but
we
get
very
high
resilience
when
you
have
only
nine
out
of
ten
proposals
and
the
other
peers
have
all
tens,
then
the
missing
one
will
get
added
to
the
network
by
maybe
nine
other
voters.
So
it's
very
low
probability
that
some
data
is
missing,
then
we're
entering
the
ravine
phase
there.
B
We
are
only
creating
this
reveal
transaction
where
we
are
revealing
the
secret
key
and
doing
this
kind
of
like
voting
on
the
date
of
you
putting
the
hash
of
our
blind
vote
payloads
into
the
transaction.
At
the
same
time,
we
are
here
publishing
all
the
blind
roads
what
we
have
received
with
the
blind
roads.
It's
the
same
in
the
blind
boat
phase
itself.
The
data
are
collected
in
there
in
this
data
structure
in
the
peer-to-peer
network,
which
is
protected
by
the
public
key
and
where
you
theoretically
could
remove
it.
B
Also
there
from
there's
no
API
to
remove
it
for
for
the
towel,
but
malicious
user
code
could
do
it
technically
and
to
avoid
that
there
are
issues
at
the
reveal
transaction.
At
the
we
reveal
phase.
We
are
republish
engrossed,
blind
boat
data
into
this
append.
Only
data
structure
where
the
data
cannot
be
revealed
cannot
be
removed
any
more
and
then
at
the
end.
After
yeah,
when
we
entering
the
result
phase,
you
have
all
the
data
available.
B
You
are
collecting
all
the
peer-to-peer
network
data
only
from
this
append
only
data
structures,
so
you
can
be
sure
that
the
data
as
cannot
have
been
removed
any
more
and
yeah,
and
then
everybody
has
to
get
exactly
the
same
result
and
then
you're
applying
the
result.
For
instance,
when
there
is
a
parameter
change
in
the
towel,
like
changing
the
the
duration
of
the
face
or
changing
the
fee
for
the
voting
or
changing
the
fee
for
transit
for
trading
field.
B
Those
when
it
gets
accepted,
I
get
a
maturity.
It
will
become
valid
into
in
the
next
cycle.
So
after
there
yeah
at
the
first
block
of
the
next
proposal,
phase
those
news
values
get
applied
and,
for
instance,
when
the
fee
for
the
proposal
has
been
changed,
it
would
render
a
client
who
would
have
to
old
date.
A
few
oh
yeah
who
would
not
have
applied
this
result,
would
use
the
old
fee
and
would
have
invalid
proposals.
B
So,
of
course,
it's
very
important
that
that
you
cannot
skip
this
result
phase
and
that
you're
applying
the
result
to
the
new
state
and
are
building
everything
on
top
of
this
and
the
same
for
for
issuance
at
the
result,
phase
issuance
happens
and
with
the
next
block,
because
it
requires
a
block
confirmation.
This
new
vsq
are
issued
and
can
be
used.
I
mean
there
will
be
a
maturity.
B
B
You
can
try
it
right,
so
basically,
it's
already
working
I
will
make
a
quick
demo.
I.
Think
you
see
now.
Maybe
I
make
no
good
work.
I
think
there's
some
issue
that
some
pop-ups
will
not
be
or
some
program
menus
will
not
be
displayed
in
the
screen
sharing
yeah.
Here
we
see
the
different
phases
for
development.
I
made
the
phases
very
short
just
two
blocks,
but
in
reality
there
will
be
a
lot
of
flux
for
a
proposal
and
then
break
something
like
ten
blocks
or
maybe
half
a
day.
B
Then
the
voting
for
three
days
or
four
days
and
then
another
break
and
then
during
really
maybe
two
days
and
then
the
result
actually
only
need
to
be
one
block,
because
it's
only
one
block
where
the
application
triggers
the
result
and
then
or
it
will
be
applied
yeah.
Now
we
end
the
proposal
phase.
So
I
can
create
a
proposal.
Let's
say
I,
there
are
not
implemented
yet
so
I
create
a
compensation
request.
I
think
that's
not
visible.
Probably
at
this
pop-up
when
I
click.
Here
the
combo
box
I
see
the
compensation
request
generic
proposal.
B
B
It
will
be
removed
automatically
for
all
the
users,
because
yet
it
will
verify
this
data
when
it
comes
to
the
result
that
the
majority
of
stakeholders
don't
want
this
outcome
in
disk,
then
it
will
not
be
listed
anymore
in
the
fewer.
So
technically,
it's
still
in
the
code,
but
the
users
don't
see
this
outcome
anymore
and
so
that's
all
basically
kind
of
like
smart
contracts
or
so
that
will
be
all
executed
automatically
without
any
external
interaction,
and
there
are
any
any
extra
requirement.
B
B
So
the
second
block
in
my
very
short
proposal,
phase
now
I'm
entering
the
break
with
the
break
we
will
now
see
before
there
was
a
remove
button.
Now
the
remove
button
is
the
way
you
cannot
remove
it
anymore
and
you
kind
of
do
anything.
You
just
can
read
it
now.
We
are
entering
the
voting
phase,
the
blind,
hoping
phase,
and
now
we
can.
When
we
select
there
will
be
a
list
of
proposals.
B
You
can
select
any
proposal
and
you
can
vote
on
any
proposal
by
accepting
or
rejecting
or
when
it's
a
proposal
for
a
parameter
change.
There
will
be
data
fields
where
you
can
set
the
amount
of
the
fee.
What
you
think
should
be
the
amount
for
the
trade
fee
or
whatever,
and
let's
accept
this
proposal,
it's
accepted
and
now
I
could
go
on
with
voting
on
several
other
proposals
or
ignore
when
I'm
not
working
on
a
proposal,
it's
simply
ignored
and
then
I
will
define
the
stake.
What
I
want
to
use
for
my
vote?
B
Let's
say
about
with
thousand
psq
and
now
I'm
craving
this
blind
vote
transaction
and
publishing
the
data
to
the
peer-to-peer
network.
We
will
see
it
here
in
the
wallet
before.
In
the
beginning,
we
have
created
the
compensation
request
transaction.
One
second
I
think
there
is
a
buck
here.
Yeah
it's
a
new
park.
I
have
not
seen
before
here
should
be
minus
one
and
it
goes
the
fee
for
a
compensation
request
is
one
bsq
at
the
moment,
but
it
displays
14,000.
That's
some
pack,
but
yeah.
B
Now
I
created
this
blind
walk
transaction,
it's
not
confirmed
yet,
so
we
don't
know
about
the
state.
It's
not
passed,
so
I
create
a
new
block
on
Bitcoin
core
on
the
wreck
test.
Now
we
know
it's
a
it's
a
blind
voter
transaction.
So
it's
a
fee
for
the
blind
vote
were
two
psq
and
we
see
also
that
we
have
locked
the
psq
for
voting.
We
see
this
here
in
the
dashboard.
1000Ps
queue
is
not
locked.
We
cannot
access
this.
I'm.
B
Yeah
yeah
so
from
usability
with
our
need
to
be
done.
A
lot
of
course
that's
very
basic
at
the
moment,
but
you
will
see
all
the
transactions
in
the
Bitcoin
wallet
as
well
like
here,
transaction
fee
payment
for
psq
transaction
because
for
every
PSU
transaction
you
need
to
add
some
Bitcoin
for
the
mining
fee,
because
you
don't
want
to
waste
your
your
expensive
psq
for
giving
it
to,
and
so
yeah
there's
always
reflected
here
as
well
and
yeah.
It
will
be.
We
get
always
attack
and
maybe
some
extra
link
with
a
pop-up
there.
B
B
As
a
UI
still
yeah,
it's
just
a
very
basic
that
I
can
do
quickly.
My
my
my
tests
of
the
basic
use
cases,
but
why?
As
soon
as
the
data
at
the
core
is
it's
ready
for
a
code
review?
Basically
I
will
go
on
with
improving
the
UI
and
implementing
the
missing
stuff
yeah
then
I
created
as
we
are
now
exiting
the
voting
phase,
we're
in
the
break,
and
now
we
are
entering
the
ravine
phase
and
by
entering
the
ravine
phase
we
have
created
a
new
transaction.
That's
a
reveal
transaction
with
the
next
block.
B
We
get
a
confirmed
and
we
see
there
is
no
fee
attached
to
it.
Has
zero
amount
spent
or
received
and
the
others
types
always
here?
You
don't
see
this
in
there
in
the
screen
sharing,
but
this
I
can
see
are
different
for
different
types.
Their
compensation
requests,
the
blind
vote
and
outro
reveal,
and
the
reveal
transaction
is
containing
the
secret
key.
B
So
now
we
can
decrypt
the
blind
vote
from
this
voter,
and
now
we
are
entering
we
enter
break
and
with
the
next
we
will
enter
the
result
will
show
it
here
and
with
the
result
we
are
create.
We
are
issuing
our
psq
from
our
computation
request
so
watch
here,
because
it's
only
visible
here
because
we
are
not
creating
a
new
transaction.
It's
only
changed
icon
to
dollar,
sign
and
change
the
name
here
to
issuance
because
their
output
of
their
compensation
request
transaction
was
reserved
for
an
issuance.
So
you
a
sequester
proposal
maker.
B
B
So
you
need
have
Bitcoin
yeah.
You
need
to
have
a
Bitcoin
input
which
has
the
value
of
1
million
Satoshi
in
Bitcoin,
and
you
create
an
output
which
is
101
millions
of
Asha,
one
hundred
thousand
vsq
a
ten
thousand
bsq
and
during
the
whole
phase
before
the
result.
That's
just
a
Bitcoin
output.
It's
not
considered
psq
because
it
has
not
been
accept
it
yet.
But
after
the
voting,
when
your
compensation
request
has
been
accepted
by
the
network,
this
output
now
becomes
into
will
get
interpreted
as
psq
output
and
it's
basically
a
new
mini
Genesis
transaction.
B
Where
you
have
the
authorization
from
the
network
that
you
can
issue
new,
you
can
print
new
psq
out
from
this
Bitcoin
from
this
million
Satoshi.
What
you
have
put
in
and
ten
thousand
bsq
will
have
much
more
well.
You
like
this
1
million
Bitcoin
us
yeah,
1
million
Satoshi
in
Bitcoin,
so
you
have
created
value
yeah,
that's
it
basically
and
of
course,
our
close
probe
after
this
phase
yeah.
A
B
A
If
you
watching
him
yeah,
if
you're
watching
the
recording-
and
you
have
any
questions-
please
just
post
your
questions
in
the
comments
below
and
we'll
try
to
answer
them
as
soon
as
possible,
or
you
can
of
course
always
talk
to
us
and
to
Manfred
in
the
slack
channel
as
well.
Yeah
I
think
we
don't
have
any
questions.
Any
live
chat,
so
I'm
free
feel
free
to
continue
yeah.
B
I
hope
it's
up
getting
too
much.
It
depends
everything
I
know,
but
we
we're
nearly
at
the
end.
No
we're
getting
closer
to
the
end.
I
would
like
to
give
a
little
bit
with
you
about
code
or
structure.
I,
don't
want
to
get
too
deep
into
it,
because
it's
still
on
the
heavy
development,
basically
and
I'm
changing
everyday
stuff.
Just
to
get
us
Oh
a
few.
An
idea
and
I
think
screenshots
are
already
not
Welling
anymore.
B
But
when
you
in
the
core
project,
you
have
a
tell
package
it
contains
of
the
note
which
contains
then
the
passing
and
the
blockchain
stuff
and
so
on,
and
the
state
which
contains
the
data
model
like
the
blockchain
later
and
the
cycles
and
the
boating,
which
contains
the
proposals
and
all
motoring-related
soft
went
and
if
you
root
classes
like
the
choose
model
module
and
they
had
set
up
and
so
on.
So
just
like
we
go
with
you
about
the
note
package.
B
It
contains
a
full
note
for
the
full
note
and
for
the
light
note
different
versions
for
for
the
pass,
and
for
this
note,
which
is
notice
using
the
RPC
service
for
getting
the
data.
The
light
note
is
receiving
the
data
over
the
peer-to-peer
network
from
the
seed
node.
Then,
during
the
passing,
we're
doing
all
kind
of
validation.
B
Then
there's
a
state
package.
It
contains
the
blockchain
data,
which
is
the
block,
the
transaction
input
output,
basically
a
reflection
of
the
data
structure
in
Bitcoin
and
then
the
periods
which
is
basically
cycling,
which
is
this
whole
month
cycle,
which
contains
of
a
list
of
cows
faces
and
every
face,
has
a
duration
and
a
type,
a
name
or
a
number,
and
the
state
class
is
if
the
route
for
carrying
all
this
mutable
state
and
our
asset
before
inside
of
the
musical
stage.
B
There
is
immutable
data
like
the
list
of
blocks,
contains
only
immutable
blocks
and
the
block
contains
immutable
transaction
and
so
on,
and
as
a
snapshot
manager,
which
is
responsible
for
making
and
applying
the
snapshots
and
the
state
services
to
access
class,
where
you're,
writing
and
reading
from
the
state
and
there's
a
voting
there.
Yeah
there
is
a
proposal.
We
have
several
different
sub
classes
for
proposal,
like
compensation,
request
proposal
or
a
generic
proposal
or
remove
outcome
proposal
or
change
parameter
proposal.
Then
there
is
the
ballot
which
contains
a
proposal
and
a
vote
for
the
boat.
B
We
have
pooling
boats,
which
is
just
yes/no
or
parameter
value
boat,
which
contains
a
long
value
and
Wis
like
you're.
Setting
new
value
for
the
trading
feel
that's
the
satoshis
in
as
long
value
and
yeah
there
is
the
blind
boat
there
is
the
boat
reveal
and
about
result
in
a
boat
result.
You're
doing
all
this
verification
and
you're
yeah
calculation
and
you're
storing
in.
A
B
Data
structure,
your
result,
result
taped
up,
and
then
there
is
a
little
bits
more
local
data.
Like
my
vote,
where
you
can,
you
want
to
distinguish
a
little
bit,
what
what's
like
your
proposal
and
what's
a
proposal,
what
you
have
received
from
the
other
nodes
and
but
that's
not
very
relevant
yeah
I,
said
before
yeah,
it
still
I'm
pretty
close
already
to
get
to
it
kind
of
like
a
state
where
say:
okay,
I'm
on
my
side,
it's
okay!
Now
for
a
code
review.
There
are
still
a
few
things.
B
What
I
want
to
change
and
I
would
like
to
implement
also,
at
least
on
the
prototype
level.
Those
are
the
use
cases
like
changing
a
parameter
and
they
are
removing
Alcuin
just
to
have
it
bullet
proof
that
we
can
implement
it
in
future,
even
if
it
will
not
be
part
of
the
first
race
I
want
to
have
it
kind
like
working
and
be
sure
that
there
are
no
surprises
there,
so
that
will
take
probably
a
few
days
as
well
to
get
this
in
at
the
moment,
I'm,
improving
and
refactoring.
B
So
what
are
the
important
stuff
of
the
Tao
and
the
challenges
we
have
to
be
soup,
and
that's
why
I'm
really
I
really
would
like
to
get
deep
code
reviews
from
several
people
at
the
moment,
or
there
is
SQ
working
with
me
at
the
Taos-
is
a
great
input
for
rethinking
and
thinking
carefully
about
all
the
details,
but
the
more
eyes
are
on
it.
The
better
and
I
would
like
to
after
we
have
internal
code
review
and
we
are
basically
as
bisk
kind
of
like,
say.
Okay,
we
are
we
okay.
B
Now
I
would
like
to
get
the
external
code
review,
maybe
hopefully
from
Pizza
Hut
or
somebody
is
similar,
but
we'll
need
need
to
see
how
much
this
costs
and
if
this
person
will
be
available,
what
are
the
challenges
yeah?
We
need
to
be
very
careful
our
about
our
fundamental
design
decisions
and
what
can
what
cannot
be
changed
in
future,
so
there
are.
B
Yeah,
for
instance,
one
design
decision
is
that
we
have
this
face
is
relatively
fixed.
It
can
be
changed
by
by
duration,
but
it
will
take
one
voting
cycle.
You
cannot
just
say:
okay,
I
want
to
have
there's
something
really
important
that
we
want
to
react
very
quickly.
We
want
to
make
a
quick
vote,
and
in
two
days
we
have
to
result
that
that's
not
supported
in
the
basic
concept
and
it
that
will
be
very
hard
to
change.
I
mean
we
could
reduce
the
duration
a
lot
and
make
make
this
cycle.
B
As
short,
this
may
be
one
week,
but
at
least
there
is
some
lower
limit,
because
you
need
to
be
sure
that
everybody
gets
online.
You
need
to
have
this
minimum
blocks
for
the
breaks
and
so
on.
You
cannot
make
a
cycle
like
like
five
hours.
Our
was
that
for
sure,
a
fundamental
design
decision.
What
cannot
be
changed
in
future
will
rent
a
completely
different
concept
and
will
change
everything.
B
There
are
from
the
data
structures.
The
immutable
data
structure
probably
cannot
be
changed.
Maybe
they
can
be
extended,
I'm,
not
a
novice
and
sure,
but
there
yet
assuming
them.
It's
it's
tricky
to
it's
a
little
bit
like
in
pit
corners.
It
is
this
fine
line.
What
is
a
soft
work?
What
is
a
hard
work?
What
you
can
change
in
which
what
does
not
break
compatibility
or
consensus?
B
It's
it's
a
very
complex
area
and
there
might
be
some
areas
where
we
could
add
new
data
fields,
for
instance,
and
new
features,
and
then
only
update
it
or
clients
will
protest
this
data
because
we
have
versions
in
every
transaction.
Every
era
we
we
are
supporting
versions,
so
we
could
deal
with
it
when
it's
this
version
and
apply
these
rules
and
when
it's
a
newer
version
can
apply
that
rule.
B
But
we
need
to
be
sure
that
everybody
comes
to
the
same
result
still
so
when
it's
a
rule,
change
or
a
new
feature
which
creates
new
results,
and
this
results
are
important
for
the
towel,
then
yeah.
It
will
probably
break
consensus
for
nodes
which
have
not
updated,
which
is
also
not
as
critical
like
in
Bitcoin.
B
We
can
say:
okay
are
when
you
want
to
use
psq,
you
have
to
update
to
the
latest
version,
at
least
as
a
certain
point.
We
don't
want
to
host
to
people
that
everybody
has
to
update
immediately,
but
we
can
say
after
half
a
year
or
a
year
that
the
old
versions
are
now
not
supported
anymore.
When
you
are
using
this,
you
get
the
invalid
state
and
you
get
notified
in
the
UI
that
you
are
basically
on
the
old
version
and
your
few
on
the
data
is
not
correct
anymore
and
yeah.
B
For
instance,
one
decision
is
that,
theoretically
in
in
Bitcoin
you
you
could
make
several
operator
and
outputs.
Also
there
yeah
it
would
be
accepted
from
the
consensus
rules.
It
will
be
non
stun
standard.
So
usually
it
doesn't
happen
because
no
node
will
rely
relay
such
transactions,
but
you
could
create
a
transaction
with
two
outputs
of
return:
outputs,
I'm,
not
sure
if
you
could
put
a
value
in
the
operator,
not
good
I,
think
so
I'm,
not
because
I'm
sure,
but
yeah
we
have
defined
the
rule.
B
There
must
be
only
one
operator
on
output
and
and
the
amount
in
operation
must
be
zero.
So
that's
a
more
or
less
arbitrary
rule
because
it
doesn't
really
have
the
influence
in
in
the
biskits
system,
but
I
just
want
to
make
or
make
it
as
easy
as
possible
for
verifying
everything
and
the
more
possibilities
are.
We
are
the
more
special
cases
you
have
to
deal
and
the
more
attack
vectors.
We
would
have
like,
for
instance,
when
it
would
be
to
up
returns
and
one
would
be
a
correct
one.
B
What
expected
it
in
the
in
the
bisque
herb
Tao
like
a
compensation
request
up
return,
type
and
so
on
and
the
other
not
yeah.
You
have
to
make
the
decision
to
you
have
to
do
some
extra
work
and
you
have
to
as
I
just
sawed
it's
more
safe
for
the
Tao
to
be
as
narrow
as
possible
and
and
render
every
transaction
invalid,
which
is
doing
something
which
is
yeah,
which
is
defined
paths
to
not
be
supported.
B
It's
a
question,
if
that's
a
good
idea
or
not,
because
there
might
be
some
use
cases
where
it
could
help
us
theoretically
with
the
operator
and
when
it
would
not
be
at
this
problem
that
it
would
be
non
stand
up.
Yeah
we
could.
Maybe
there
is
a
use
case
where
we
want
to
put
more
data
into
the
blockchain,
and
we
need
a
second
operator
to
put
more
data
in
and
at
the
current
rule.
We
cannot
do
this.
B
So
it's
a
question:
if
it's
really
good
to
make
it
too
narrow
and
maybe
before
we
go
live,
should
reconsider
it
and
make
it
a
little
bit
more
flexible
and
analyze
it
more.
If
a
certain
rule
can
add
some
risk
or
not
like
supporting
multiple
operations,
probably
will
not
a
truly
risk,
but
at
the
moment
I'm
as
narrow
as
possible
yeah.
B
B
We
could
also
prune
it
the
state
tears
of,
but
basically
I,
don't
see
a
problem
there,
but
yeah
I
mean
this
append-only
data
structure.
This
data
will
be
stored
forever.
It's
like
the
Bitcoin
blockchain
and
there
we
would
have
scalability
issues
when
the
data
will
become
really
big
but
I.
Think,
realistically,
we
have
maybe
between
10
and
50
proposals
and
10
and
50
voters
per
month.
B
We
will
not
have
hundred
rows
I
assume
that
will
render
management
very
difficult
when
you
have
hundred
people's
to
vote
on,
but
just
to
calculate
simply
with
ten
proposals
and
ten
voters.
In
ten
months
roughly
one
year,
you
would
have
300
kilobyte
on
data
from
the
proposals
which
is
not
critical,
so
we
adding
basically
300
kilobyte
local
data
storage
per
year
with
hungry
proposals
and
hundred
blind
votes.
It
would
be
three
megabytes.
Also,
not
a
big
deal
path
might
become
slowly
a
little
bit
more
problematic,
but
I
think
a
hundred
proposal
is
already
a
ten.
B
Probably
we
need
to
increase
the
fee
that
we
get
less
proposals
or
or
partitions
at
our
several
smaller
projects,
because
I
think
it's
from
the
management
aspect
already
to
to
larger,
but
of
course,
everything
yeah.
What
the
performance?
What
I
said
before
with
the
verification
I
had
done
tests
in
the
early
days
with
using
main
that
data
and
to
catch
up
mister
with
the
main
that
block
data
for
a
full
note.
It
takes
a
while
a
few
hours.
B
Four
months,
for
instance,
I
think
it
takes
half
a
day
or
so,
but
that's
not
a
big
deal,
it's
like
with
the
Bitcoin
blockchain
when
you
need
to
catch
up
a
few
months,
or
so
it's
much
faster
than
always
new
versions
of
Pitkin
core,
but
a
few
years
ago
it
was
also
super,
slow
and,
and
nobody
is
worse
to
user.
Yet
those
who
are
running
full
notes
I
think
they
will
take
this
extra
cost
and
there
is
a
lot
of
improvement
possibilities
there.
B
You
cannot
change
or
you
should
not
touch
this
code
and
other
parts
are
more
yeah,
less
critical
like
which
are
just
collecting
data
for
displaying
it
in
the
in
the
UI
or
whatever
one
open
question
where
I'm,
not
very
sure
is
if
we
should
use
the
pro
to
buffer
data
structures
or
encoding
for
for
consensus.
Relevant
areas
like
we
are
using
we're
creating
this
hashes,
which
defining
the
majority
of
the
date
of
view
by
using
the
list
of
blank
votes
and
creating
a
prototype
object
out
of
it.
B
Serializing
it
basically
and
taking
the
pipes
from
that.
I'm,
not
sure
if
it's
really
good
to
use
brought
to
buffer
here
we're
a
little
bit
dependent
when
I
am
not
sure
if
it's
realistically
possible
that
Google
could
change
during
coding
versions
or
rules
of
protocol,
and
it
could
basically
break
with
render
different
fight
result
or,
if
they're.
B
When
there
would
be
any
any
risk
there
and
alternative
would
be
to
make
transfer
to
a
JSON
object
would
add
a
little
bit
of
effort,
because
we
have
already
all
the
data
structure
for
protobuf,
and
then
you
have
extra
conversion
through
two
to
chasten
or
to
build
our
own
binary
data
structures,
which
probably
doesn't
really
make
sense,
I.
Think,
but
that's
an
open
question.
B
The
way
how
we
are
flexible
is
updates
and
extensions
of
that
array.
We
have
version
or
bytes
for
all
important
stuff.
So
that
should
give
us
some
flexibility,
but
we
have
to
be.
We
have
basically
to
count
that
what
we
are
doing
now,
we
will
not
be
changed
at
least
for
one
year
and
when
it
will
be
changed,
it
might
be
a
pain
or
might
require
and
like
a
hard
work,
and
we
should
think
about
worst-case
scenarios:
protection
firewalls.
What
happens
when
there
is
a
critical
part
and
network?
The
consensus
would
have
two
different
versions.
B
What
if
somebody
find
out
a
weak,
quick
area
and
exploit
this
and
in
the
concept
and
the
basic
tower
concepts
are
already
a
few
ideas
like
that:
a
limit.
What
can
be
issued
per
month
a
hard
limit
in
the
code,
so
when
somebody
hacker
find
a
época
and
good
exploit
and
boot
create
a
million
bsq
would
not
be
allowed
because
there
will
be
a
limit
of
maybe
500,000
or
whatever,
and
then
it's
the
maximum
damage.
What
can
be
done?
B
We
also
will
define
clear
rules
how,
with
the
English
bucks,
not
like
the
Tao,
that
code
is
law
and
then
when,
when
their
code
was
buggy,
this
doesn't
is
not
valid
anymore.
We
will
yeah,
that's
also
in
the
concept
already
defined
this
make
clear.
When
there
is
exploit,
we
will
try
to
fix
it
and
when
there
is
a
possibility,
we
will
freeze
this
this
funds
and
we
will
lock
it.
We
will
have
some
peer-to-peer
network
messages
where
we
can
lock
trading
and
where
we
can
yeah.
B
We
can
signal
to
the
network
some
emergency
events
and
yeah,
whatever
I
think
we
should
think
carefully
about
all
possible
worst-case
scenarios,
and
how
can
we
deal
with
it
because
I
mean
when
we
up
the
Dow,
it
can
be
the
debt
of
the
project
itself
and
it
can
be,
can
be
really
we've
seen
it.
What
Dow
has
data
has
created
the
damage
for
IT
reom
and
we
don't
want
to
run
in
any
in.
A
B
Don't
want
to
get
in
this
danger
zone
yeah
the
next
steps,
yeah
I,
hope
or
that
I'm
getting
ready
for
this
first
internal
code
with
you
in
the
next
few
days,
I
mean
I'm
only
looking
for
developers
for
making
a
coat
or,
if
you
who
really
have
enough
time
to
get
really
deep
into
it
and
read
all
the
documents
and
really
understand
everything.
I
don't
want
to
have
a
broader
code
review
with
newcomers
who
don't
know
well
bit
disk
and
peer-to-peer
network
and
everything
I
don't
have
time
to
on
board,
and
it
doesn't
make
sense.
B
Yeah
should
be
only
really
we're
very
in-depth
code
review
of
people
who
already
know
everything
very
very
well,
and
it
has
to
be
very
carefully
as
who
yeah
it's
the
most
complex
and
the
most
dangerous
part
of
bisque,
and
we
have
to
be
absolutely
sure
that
we
there
is
no,
that
everything
is
perfect
and
there
are
no
I
mean
them
might
not
be
everything
perfect
on
the
engineering
side,
also
like
with
the
threading
and
so
on.
But
that
can
be
changed.
B
B
So
I
would
like
to
focus
first
on
more
the
contextual,
the
design
consensus
elements.
Also,
there
are
not
many
tests
or
not
everything
perfectly
well.
It
ate
it
at
the
moment,
I'm
doing
too
much
validation
repeated
all
the
time.
That's
also
on
my
to-do
list
to
improve
and
engineering
improvements,
yet
to
refactor,
just
technical,
refactorings
or
engineering
refactorings.
I'm,
of
course
that's
good
to
have
as
well,
but
my
main
request-
or
the
most
important
for
me,
is
to
get
everything
conceptually
and
architecture
and
design
wise,
really
solid
and
set
in
stone
and
yeah.
B
That's
the
first
iteration
at
least
and
then
late.
Of
course,
we
have
to
go
over
every
every
single
line
and
think
about
every
single
line
if
there
could
be
anything
what
breaks,
but
if
there
could
be
any
case
where
this
line
could
cause
a
problem
yeah,
I
have
to
implement
the
other
proposal,
types,
at
least
on
a
prototype
level
that
I'm
sure
that
there
will
not
be
surprises.
I
also
want
to
implement
the
bonding
basics
or
so
yeah.
We
use
this
bonding
schemes
for
securing
important
roads
like
the
arbitrator's.
B
They
need
to
put
up
a
pond.
They
are
locking
up
psq
for
there
for
undefined
time
and
then
unlocking
it
at
any
time
when
they
are
stepping
back
as
arbitrator
and
any
other
roles
in
peace
queue
will
be
bonded
as
well.
So
that
will
probably
not
be
part
of
the
first
release,
but
I
would
like
to
have
as
well
the
prototype
implemented
that
I'm
sure
that
there
will
be
no
surprise
when
we
implement
it
and.
B
The
UI
is
very
basic,
I
need
more
improvements,
and
yet
the
block
Explorer
for
psq
garage
screen
has
in
the
past,
already
done
a
lot
of
work,
but
it
needs
some
update
with
the
current
changes
and
with
all
the
peers
with
the
bolt
in
parts
and
I
talked
with
him
already.
He
will
be
available
to
do
it,
so
that
should
be
done
also
in
the
next
one
or
two
months
assume.
We
are
ready
from
our
side
with
a
code
review.
B
I
would
like
to
reach
out
to
somebody
like
Peter
thought
or
XML
code
review
and
when
we
are
ready
for
deployment
I
would
start
would
like
to
start
first
on
test,
not
only
that
we
are
doing
our
monthly
or
a
compensation
request
now
on.
Maybe
in
parallel
in
bisque
and
I
have
a
kinda
like
a
VI
testing
face
on
test
net
for
one
or
two
months,
and
maybe
there
will
be
even
more
it
more
extended
deployment.
B
Slowly
deployment
after
of
the
full
version,
but
has
to
be
defined
like
that
yeah
here,
a
few
links
to
references,
the
basic
overview
at
the
phasor
document
and
the
technical
specification,
the
technical
specifications
quite
up
to
date,
but
I
said
it
doesn't
cover
all
the
details
and
it's
a
clear
disclaimer
I'm,
absolutely
not
interested
and
will
not
support
anybody
who
is
intending
to
make
an
alternative
implementation.
That
would
just
carry
a
lot
of
risk
and
and
had
it
for
me,
and
he
only
the
code
is
a
specification
for
something
like
this.
B
Nobody
should
create
a
psq
transaction
on
their
own
that
that's
just
looking
for
troubles
and
any
small
mistake
can
render
your
psq
invalid
and
we
will
not
help
such
people.
When
somebody
is
doing
this
yeah,
then
he
has
burnt
his
peers
cube.
There
will
not
be
a
hot
spot
like
in
a
theorem
when
somebody
maker
packs
here
and
the
technical
specification
only
yes,
it's
it
doesn't
define
all
details
like
that.
There
must
not
be
multiple
or
operators
or
whatever
or
more
other
small
details
which
only
defined
in
the
code.
B
So
the
code
is
only
the
real
low
level
specification.
The
tech
spec
is
kinda
like
in
between
for
non
developers
to
get
the
deeper
understanding
and,
of
course,
the
code
I'm
working
on
a
local
branch
on
my
repository
and
it's
not
only
in
the
Peace
Corps.
It
of
course
touches
all
the
other
projects
as
well
the
peer
to
peer
and
the
desktop.
So
you
need
to
check
out
all
the
projects.
Yeah
I
think
that's
the
last
slide.
A
Not
from
my
side,
I
will
I
will
dig
into
the
document
documents
and
the
code
little
bit
myself
later
on
for
everyone
who
is
watching
us
live.
Do
you
have
any
questions
regarding
what
Manfred
just
presented
just
give
it
a
couple
of
seconds,
because
we
have
a
delay
also
in
the
Nvidia
stream,
so
for
a
timeline
Manfred
to
do
the
test
net
release?
What
you
think
is
realistically,
from
the
current
point
of
view
here.
B
Changes
all
the
time,
I
think
I
hope
at
least
that
I'm
getting
kinda
like
ready
for
internal
review
in
about
two
weeks,
I
mean
I'm
traveling
in
one
week,
so
I
will
use
a
few
days,
but
this
yeah
should
I'm
I'm
already
pretty
close,
but
all
the
time
there
is
something
new
and
I
want
to
get
really
I.
Don't
want
don't
want
to
make
compromises
here.
B
That's
the
best,
but
I
can
do
then,
of
course,
I'm
happy
to
get
input
from
you
and
from
Chris
and
ask
you
and
Neyman
and
anybody
else
who
want
to
contribute
in
a
deeper
review
and
and
maybe
you'll
find
some
flaws.
Maybe
we
will
do
some
changes.
Yeah
can
be
easily,
of
course,
because
or
quite
complex,
and
there
might
be
some
stuff
that
I
overlooked
and.
B
Then
and
of
course,
on
the
engineering
side,
that
can
be
done,
improvement
on
the
architecture
and,
of
course,
always
can
be
improved.
Then.
For
me,
it's
more
important
or
the
next
most
important
thing
is
you
have
to
get
really
the
tests
to
make.
It
really
bullet
proof
to
try
to
break
it
with
all
kind
of
crazy
transactions
and
all
kind
of
crazy
non,
possibly
use
cases
from
the
UI.
B
But
when
somebody
want
to
attack
it
on
the
code
side
and
at
the
same
time
to
it
current
UI
in
a
way
that
it's
good
enough,
it
will
not
be
perfect
UI
because
it's
mainly
for
the
contributors
but
for
the
mainstream
users.
So
it
will
not
be
super
polished.
But
it
should
be
clear
enough
at
least
that
people
can
deal
with
it
and
the
end
do
a
lot
of
testing.
And
then
we
should
be
ready
for
the
first
version.
A
A
Yes,
so
there
are
no
other
questions
in
a
live
chat,
so
I
would
say
thank
you
very
much
Manfred
for
taking
the
time
to
walk
us
through
the
current
state
of
the
deal
and
the
implementation
also
the
prototype
as
well.
So
if,
if
you're
watching
this,
this
recording-
and
you
have
any
suggestions,
questions
please
feel
free
to
put
it
in
the
comments
below
or
contact
us
on,
slag
or
github
to
talk
it
through
yeah.
B
There
is
no
single
element
where
I
mean
there
might
be
such
like
these
firewalls
that
I
can
send
up
blocking
messages
in
the
worst
case
that
we
can,
but
that's
also,
that
was
in
Bitcoin,
with
this
global
alert
messages
when
something
goes
wrong
that
you
can
stop
it
in
a
way,
but
beside
this,
that
thou
itself
is
really
hundred-percent
decentralized.
It's
in
the
hand
of
the
stakeholders
they
making
the
decision
and
everything
is
done
by
the
power
of
the
blockchain
in
combination
with
our
peer-to-peer
network.
B
I
think
this
combination
is
quite
interesting
and
it's
actually
it's
really
a
it's.
A
smart
contract
application.
It
executes
sir,
the
stuff
which
has
been
their
intention,
which
have
been
expressed
by
the
humans
by
voting,
gets
represented
automatically
in
an
automated
result
like
new
stake,
new
new
issuance
or
changes
of
parameters.
There
is
no
direct
human
interaction
there
pretty.