►
A
Hello,
everybody,
this
week's
developer
session
this
week
we
have
mainly
two
or
maybe
three
topics
we
want
to
talk
about.
One
is
some
ideas
for
automated
all
current
ratings
and
I
would
like
to
discuss
a
little
bit
with
developers
who
are
joining.
If
somebody
would
be
available
to
work
on
this
so
the
first,
it
would
require
a
proof
of
concept
and
a
spec
and
then
into
the
development.
A
If
we
still
have
time,
I
would
like
to
give
a
little
bit
of
background
about
the
stuff
that
I'm
working
at
the
moment
for
about
for
proofing,
basically,
the
consistency
of
the
network
consensus,
so
that
every
node
has
really
exactly
the
same
state
of
the
DAO
locally
with
other
nodes,
and
it's
basically
it's
based
on
on
the
very
basic
idea
of
Bitcoin
hash
chain.
So,
every
at
every
block
we
are
creating
a
hash
from
the
current
state
of
the
tower
and
then
connecting
it
with
using
the
previous
hash
in
the
new
hash.
A
So
we
are
creating
a
chain
of
hashes
and
when
the
latest
hash
or
is
the
same
with
somebody
else,
you
can
be
sure
the
history
was
the
same
as
well.
Yeah
I
like
to
jump
into
the
into
the
first
topic.
If
you
guys
have
anything
you
would
like
to
bring
in
into
it
again
that
we
are
very
flexible,
we
don't
have
anything
pressing
this
week.
Do
you
have
anything
what
you
would
like
to
discuss.
A
If
not,
then
I
jump
right
into
the
into
this
topic
regarding
our
coin
trading,
automated
ultra,
when
trading
with
we
feared.
Of
course,
we
cannot
really
do
this
because
banks
not
offering
api's
and
if
one
or
two
payment
providers
are
delivering
modern
IT
21st
century
IT,
then
most
of
the
other
banks
will
not
do
it.
A
So
it
would
be
a
terrible
effort
to
try
to
support
it
for
all
the
banks
and
I
mean
maybe
at
some
point
in
five
or
ten
or
twenty
years,
the
banks
will
deliver
a
standard
for
API
so
that
the
application
could
basically
request
from
the
bank
API
if
the
payment
was
done
and
if
the
payment
has
been
received,
and
then
this
manual
clicking
the
button
that
we
have
sent
the
Fiat
or
that
you
have
received,
the
Fiat
could
be
done
by
software,
but
yeah.
We
are
not
there
and
banks
will
maybe
never
arrive
there.
A
So
we
don't
count
on
this,
but
on
the
output
side.
Luckily,
we
are
a
little
bit
more
modern
and
we
could
basically
integrate
the
lookup
austra
normal
alkynes.
You
can
verify
the
transaction
on
the
broth
Explorer.
It
has
a
little
bit
of
security
concerns,
of
course,
because
could
be
theoretically
with
some
small
out
point
that
where
somebody
runs
a
Prophet's,
Laurent
and
manipulates
it
intense
chemistry,
us
but
I
think
it's
a
very
limited
concern,
and
especially
with
with
the
highly
traded
out
coins,
probably
no
profits
were
provided.
A
Will
will
do
this
risk
but
of
course
there's
some
limitation.
You
cannot
trade
millions
or
billions
with
this
concept,
but
I
think
for
our
use
case.
It's
good
enough
so
and
we
could
we
could
leave
it
to
the
user,
which
floppy
flirt.
You
want
to
use
for,
delivering
the
proof
dater,
we
could
even
run
our
own,
integrate
our
own
profit
per
and
so
on.
So
I
think
that's
a
soul,
favorite
problem
and
it
can
be
also
optional.
A
A
Alcuin
transaction
is
confirmed,
of
course,
depending
on
Alcuin.
There
will
be
a
requirement
for
different
depth
of
confirmation
blocks.
Some
Alkaline,
especially
those
which
have
very
short
confirmation
times,
are
not
considered
safe
after
one
or
two
confirmations.
Maybe
you
need
to
wait
for
10
or
20
confirmations
and
on
the
receiver
side.
As
on
the
alcohol
receiver
side,
the
application
can
also
check
if
the
transaction
was
made
to
once
address
and
then
confirm
the
payment
receipt,
so
the
user
don't
need
to
click.
The
button
on
the
application
will
do
the
payout
automatically.
A
It
has
mainly
one
conceptual
problem.
It
can
be
that
a
trader
receives
on
his
Alcuin
addressed
exactly
the
same
amount
from
two
different
rates,
and
then
the
software
doesn't
know
which
which
trade
was
completed.
So
that's
a
little
bit
of
problem,
but
I
think
can
be.
We
can
work
with
this,
so
the
application
basically
could
check.
When
you
have
this
case
that
you
have
two
trades
open.
Where
you
expect
payments
with
the
same
amount,
then
you
need
the
manual
the
manual
confirmation
button.
We
have
the
same
problem
also
manually.
A
A
Like
payment
IDs,
where
you
could
add
the
trade
ID
as
a
extra
metadata
to
the
transaction,
but
that's
not
supported
now,
all
Alcuin,
so
that
will
not
work
as
well
about
I
would
not
consider
this
as
a
show
stuff
about
something.
What
we
have
to
keep
in
mind
how
to
deal
with
this
and
our
main
Alcuin
era
as
the
most
by
far
the
most
traded
outline
on
piste.
A
We
cannot
do
this
because
one
error
is
a
privacy
Cohen
and
the
look
up
in
the
block
Explorer
doesn't
give
you
any
information,
basically
about
if
you
have
received
a
transaction
or
not,
but
luckily
there
is
all
those
privacy
coins
and
especially
more
error.
They
have
a
system
broken
where
the
send
off
the
Monaro
fashion,
with
the
transaction
Kimmy
and
the
receiving
address,
and
the
transaction
ID.
With
these
three
pieces
of
data,
you
can
also
yeah.
A
You
can
either
use
it
in
the
Monaro
wallet
to
do
to
verify
the
ascending
or
you
can
go
to
a
webpage
which
is
offering
the
services,
and
by
this
you
can
yeah.
You
can
prove
that
an
error
has
been
sent.
The
receiver
cannot
deliver
any
proof
that
he
has
not
received
or
has
received
it.
So
it's
with
this
point.
A
It's
always
in
the
responsibility
of
the
Alcuin
of
the
Monaro
sender,
to
provide
the
proof
and
when
he
cannot
provide
the
proof-
and
there
is
a
real
dispute-
I'm
not
aware
that
I
have
been
such
a
case.
But
then
basically
the
linear
receiver
would
be
considered
that
as
the
winner,
because
yeah
it's
the
duty
of
the
sender,
to
provide
the
proof
and
it's
not
able
to
provide
the
proof.
Then
the
arbitrator
cannot
find
out.
A
Especially
with
money
arrow,
we
would
like
to
add
better
integration
or
more
integration
for
Monaro
traders,
because
it's
our
main
traded
currency.
So
there
are
a
few
ideas
around
this
there's
the
basic
idea
to
automate
the
Alcuin
trading,
and
then
there
are
a
few
additional
idea
of
how
to
integrate
Manero
into
bisque.
Our
basic
idea
is
to
have
a
API
with
I
think
have
some
noise
on
to
my
side.
Thomas.
Can
you
do
you
meet
yourself,
yeah
sex.
A
Yeah
to
integrate
basically
API
with
a
local
manera
wallet.
So
when
a
Manero
trader
has
running
his
local
Manero
D,
then
the
API
could
connect
to
this
and
you
could
make
the
Monaro
payment
or
confront
them
on
error
received
directly
from
bisque.
You
don't
need
to
switch
over
to
manera
I'm,
not
found
because
not
sure
if
it's
really
a
much
required
or
requested
feature,
we
didn't
get
too
much
feedback.
There
is
a
proposal
I
think
out.
A
At
least
eight
idea
was
communicated
a
while
and
we
have
not
found
the
Monaro
developer,
who
were
interested
to
work
on
this
I
mean
to
use
when
there
is
a
base
currency
that
highly
there's
much
demand
for
this,
but
that's
a
big
effort
and
basically
there,
no
it's
not
on
our
roadmap
for
the
next
half
year
or
so
to
get
into
this.
That's
a
big
effort
for
minimum
half
a
year
development
time,
and
it
got
also
confirmed
from
only
our
developers
that
ottoman
era
site
it's.
It's
quite
a
big,
complex
enterprise.
A
So
there
no
plans
no
concrete
plans
on
this.
So
the
easy
saying
we
had
to
get
them
on
era,
wallet
somehow
integrated.
There
isn't
a
Java
implementation
for
API
from
an
arrow,
so
it
shouldn't
be
really
too
hard
in
human
experience.
Developer,
who
knows
the
Monaro
side
well
and
also
travel?
Well,
could
do
it
maybe
one
months
ago,
something
like
this.
A
Maybe
a
little
bit
more
interesting
and
important
feature
would
be
to
integrate
this.
This
proof
for
the
transaction
sending
have
not
thought
about
details
how
to
it
and
about
complexity
and
context.
We
basically
miss.
We
don't
want
to
introduce
dependencies
on
other
service,
especially
not
direct,
HTTP
codes.
Everything
goes
over
to
our
many
of
those
api's
have
CloudFlare
and
you
cannot
yeah.
A
You
need
to
resolve
the
captions
on,
so
you
cannot
use
the
api
over
tor
and
our
solution,
like
we
do
with
the
price
feeds,
is
to
use
our
own
notes
where
you
connect
as
a
hidden
service
to
this
service
and
those
are
getting
their
data
from
services,
and
we
could
use
something
similar.
Basically,
this
to
a
proxy
on
our
side,
where
you
send
a
request
for
a
transaction
proof
with
these
three
different
pieces
of
data
and
yeah.
A
So
the
timoni,
our
sender,
could
transfer
this
data
to
the
receiver
to
the
Monaro
receiver
and
the
application
of
the
Monaro
receiver
can
make
the
net
request
for
the
transaction
proof.
And
when
this
returns
are
successful,
then
it
means
that
it's
basically
proof
that
Santa
has
sent
the
Monaro
and
then
the
the
receiver
of
the
Monaro
could
confirm
the
receipt
and
finalize
the
trade.
So
it
can
be
automated.
A
So
that
might
be
a
quite
interesting
feature
and
we
should
look
into
be
able
to
to
write
a
proposal
for
this
and
think
about
all
the
details
and
what's
needed
and
the
security
risk
and
so
on,
and
how
we
deal
with
this
I.
Think
all
these
features
where
we
are
changing
their
the
other
security
context.
A
Meet
again
need
to
be
communicated
to
the
user
and
should
be
basically
optional.
Let
the
user
make
the
decision
if
he
is
basically
willing
to
add
extra
trust
that
he's
trusting
on
the
one
side,
this
bisk
developers,
who
are
running
this
proxy
node
and
on
the
other
side,
this
services,
which
are
delivering
this
proofs
I'm
aware
of
at
least
two
web
pages,
which
delivered
is
serving
for
a
transaction
proof.
So
we
could
basically
use
posts
and
then
limiting
and
reducing
the
risk
exposure
on
this
side.
A
One
thing
to
consider
is
the
amount
of
number
of
transformations
a
user
want
to
wait
them
for
what
you
consider
that
it's
safe
I
think
it's
not
really
a
practical
issue.
At
least
I'm
not
aware
of
doubles
mint.
It
attacks,
at
least
not
on
the
big
al
Quint
like
Monera
and
Whismur
ero.
It
takes
quite
the
time
anyway,
until
you
get
the
confirmation,
I
think
usually
20
minutes
or
something
like
this
so
I,
because
of
the
way
how
the
ring
signatures
have
created
and
so
on.
Some
at
least
on
the
money
outside
I.
A
Don't
see
it
as
a
big
issue
and
basically
I
think
it
would
make
sense
to
when
we
work
on
this,
to
basically
really
focus
on
the
mone
arrow
usage,
because
that's
our
most
by
far
most
traded
out
Quinn.
When
you
check
the
statistics,
I
mean
in
overall,
they
have
much
more
or
less
90%
of
the
trade
volume
on
disk
and
from
all
the
alkenes.
They
have
another,
probably
more
than
ninety
percent.
All
the
alcohols
are
tiny
in
relation
to
this.
So
we
should
take
this
in
consideration
where
we
put
our
efforts
on
the
development
side.
A
So
after
this
broad
overview
about
this
basic
ideas
which
are
floating
around
this
topic,
I
would
like
to
ask
specially
Tomas
or
maybe
also
been
both
our
developers,
who
are
not
deep
in
a
in
a
domain
already
like
valid,
with
the
API
Oscar
with
Bitcoin
or
Florin,
with
European
Network.
So
I
would
like
to
ask
you
if
you
would
be
basically
interested
to
for
us
to
work
on
a
proposed
laws,
almost
specification,
basically
to
think
about
all
the
details
and
get
a
good
plan
how
to
implement
it.
What
needs
to
be
done?
A
What
meet
which
challenges
are
on
the
usability
side,
on
the
conceptual
side
and
so
on,
and
then
we
are
make
a
road
map
how
to
develop
it.
Basically
that
always
we
try
to
develop
it
with
the
Minimum
Viable
Product
to
do
the
absolute
minimum
what's
required,
which
makes
sense
from
the
user
perspective
as
a
feature
and
then
extent
doesn't
have
to
be
done
all
as
a
big
feature
shouldn't
be
done
in
this
way,
it
should
should
be
in
small
iterations.
A
A
Very,
very
valuable
contributions
on
the
outside
and
I
was
very
positively
impressed
how
quickly
he
get
into
the
code,
because,
quite
also
on
the
UI
side,
the
domains
are
as
a
domain
code
is
quite
complex
and
seems
that
he
found
very
quickly
his
way
into
it.
So
I
and
there
is
still
a
lot
or
I-
could
use
a
lot
of
help
still
especially
on
the
UI
set
and
Aries
so
I
would
maybe
yeah
went
almost
want
to
take
this
approach.
A
It
basically
I
would
prefer,
if
Venice,
okay,
maybe
to
keep
to
same
one
on
the
towel
on
the
Tao
area,
but
set
here.
We
can
discuss
late
a
little
bit
about
your
background,
and
whatever
are
we
go
on
basis?
Is
this
okay,
for
you
been
around
with
you,
also
be
super
interested
on
working
on
this
trade,
proper
Alcuin
automatic
elephant
riding
project.
A
A
Yeah
for
the
Sun
that
Alcuin
sits
basically
look
up
to
a
block,
Explorer
and
I
said
it
has
to
be
done
over
our
can
be
maybe
integrated
in
the
price
node
of
the
same
way
like
we're
doing
it
a
surprise.
Note
that
it's
that
it
goes
over
to
work
and
for
money
era,
I
think
we
need
this
transaction
proof,
API
services
and
long
term
when
it's
successful
and
it
really
makes
sense,
it
would
make
sense
to
extend
it
to
to
do
all
these
outcomes
which
are
traded
on
this.
A
Nobody
knows
who
is
running
than
this
explorer
and
if
they
are
trusted
or
not
so
we,
the
clear
goal
is
to
start
with
with
those
who
have
real
impact
for
peace,
which
is
one
error
at
the
moment
when
it
works
there,
and
everything
is
good
there.
We
can
go
to
the
next
most
traded
coin-
maybe
litecoin,
maybe
maybe
aterial.
A
So
it
will
be
always
the
optional
feature
just
enable
for
those
well
yeah,
we've
implemented
it
and
even
and
I
think
the
user
should
make
the
decision
the
maker,
basically
when
it
greatest
offer
to
enable
that
offer
can
be
like
we
have
now
with
this
incent
trade.
You
have
basically
at
second
like
a
automated
offer,
which
supports
automated
trader
to
take
me
to
know
it
when
he
takes
a
job
for
them.
He
agrees
basically
to
this,
but
all
these
details
should
be
worked
out
in
the
proposal.
A
That
would
be
even
better
when
we
run
a
basic
hour
on
exploring
the
way
it
can
be
done,
especially
for
money
era.
Maybe
it's
really
worth
it,
but
of
course
it
adds
more
wire
for
a
more
and
more
costs
earned
yeah,
but
of
course
that
would
be
more
secure,
like
just
trusting
another
service,
I
think
and
the
same,
but
I
think
a
hybrid
is
like
another
long-term
probe
yeah
proposal.
A
What
we
want
to
implement
someday,
which
is
already
out
long
term,
is
to
to
create
our
own
price
providers,
basically
that
we
are
especially
on
the
field
side.
We
are
very
dependent
on
it,
collaborative
to
have
been
one
or
two
times
technical
problems
on
their
side
and
then
all
the
percentage
based
offers
cannot
be
taken
when
there's
no
price
provider
to
have
basic
our
own
simple
price
provider,
which
is
a
mix
of
different
others,
and
when
one
is
feeling
we
are
offline.
A
That
has
higher
priority,
in
my
opinion,
like
like
going
in
that
road
in
that
direction,
but
that's
actually
some
other
topic
Thomas,
which
you
may
be
in,
could
have
look
I,
don't
want
to
mix
it
now.
It's
picking
up
this
project,
but
this
yet
we
have
our
own
price
provider
service
for
bisque.
We
are.
We
are
basically
getting
the
price
feeds
from
different
platforms
like
we
do
on
average,
but
also
from
other
big
exchanges
and
then
creating
our
own
price,
which
get
delivered
to
Rick
to
our
users
would
be
more
resilient.
A
We
are
growing
slowly
organically,
but
the
narrow
may
have
comes
up
and
down
very,
very
a
lot,
and
but
we
are
over
the
monthly
volume
we
we
are
losing.
So
we
have
to
take
care
to
keep
them
on
our
traders
and
deliver
a
good
trade
experience
and
good
service
goodie
anything
else.
Or,
should
we
jump
to
the
next
topic.
A
Then,
just
a
little
bit
quick
overview
about
our
roadmap
with
the
Dow
launch,
so
from
the
testing
everything
looks
good,
so
there
was
no
personal
problems,
discovered
small
bugs
on
the
UI
side,
but
nothing
critically
and
I.
Over
the
last
days,
I
started
to
work
on
this
idea,
which
I
had
long
since
long
time
to
add
a
chain
of
hashes.
So
at
every
block
we
are
creating
a
hash
of
the
whole.
Now
state
I
mean
the
I
have
to
give
a
little
bit
a
little
bit
more
information
to
understand
it.
A
Well,
so
the
Tao
state
consists
on
the
one
side
on
data
which
is
based
on
the
blockchain
dater,
like
transactions
and
on
the
other
side
on
peer-to-peer
network
data
like
the
proposal
data
which
we
are
publishing
in
a
peer-to-peer
network
or
the
blind
vote
data,
and
we
are
using
the
feet
rather
the
blockchain,
basically
to
make
sure
that
the
peer
to
peer
network
state
is
is
consistent
over
the
network.
I
don't
want
to
get
any
details
about
this.
A
It's
another
big,
complex
topic,
so
the
to
get
to
a
consensus
in
the
Tao
I
was
in
the
boat
result
face
basically
where
every
user
getting
all
the
data.
This
mix
of
peer-to-peer
network
data,
which
is
by
default,
not
work
not
guaranteed
to
be
consistent,
can
be
that
you
never
received
one
of
those
peer-to-peer
network
payloads
and
that's
a
valid
case
guarantee
that
the
delivery,
but
at
the
result,
phase,
because
we
have
additional
features
which
makes
it
makes
it
clear
that
there
is
consistency
in
the
network.
A
It
has
to
be
that
every
node
received
to
the
exactly
same
result,
and
this
result
is
basically
stored
in
in
the
model
class,
which
is
called
Tao
state
and
that
carries
basically
state
of
the
doubt
after
that.
One
part
is
just
a
block
so
that
these
cue
blocks
yeah.
It's
basically
a
filter
to
a
version
of
the
Bitcoin
blockchain.
But
then
there
is
a
lot
of
additional
data
like,
for
instance,
when
the
pond
has
confiscated.
A
This
data
gets
stored
there
and
the
UTF
so
said
that
this
block
height
and
because
all
this
data
get
verified
after
a
new
block
arrives
and
when
everything
is
processed,
the
block
get
passed
and
all
the
valley
verification
is
done
and
yeah.
When
you
end
a
new
phase
like,
for
instance,
getting
into
the
wolf
result,
phase
then
be
asked
you
get
issued
when
there
was
the
computation
request
and
such
stuff
all
that
changes
the
state
of
the
Tao
of
the
psq
and
that's
basically
represented
in
this
Dao
State
class
and
I
created
yeah.
A
We
are
we
creating
a
hash
and
at
the
next
block,
we
create
the
new
hash
of
the
new
State,
because
of
course,
that
has
probably
been
a
test
which
would
change,
because
there
are
new
blocks
added
from
Bitcoin
side,
and
maybe
they
have
been
issued,
some
bsq
or
some
trading
fees
and
some
ps2
background
and
so
on,
and
to
reflect
all
the
history
we
are
using
their
previous
hash
or
and
adding
it
for
creating
the
new
hash.
So
we
have
this
chain
of
hashes,
similar
like
in
Bitcoin
with
that.
A
You
have
to
feature
that
at
any
time
when
you,
when
you
have
the
same
hash
like
another
node,
then
you
know
all
the
history
is
the
same
as
well,
because
when
there
would
be
any
change
the
history,
it
would
have
led
to
a
different
hash
and
yeah
and
implemented
in
the
Europe
in
the
UI
and
new
page.
Basically,
where
you
received
the
hashes
that
was
by
default,
we
are
requesting
the
last
ten
hashes
from
the
last
they're
from
the
most
recent
blocks
from
the
seed
nodes.
A
So
you
are
you're
connecting
anyway
to
minimum
two
or
three
seed
nodes
at
startup
and
we're
using
this
also
to
request
the
hashes
from
the
seed
nodes.
So
you
will
see
already
if
you
are
in
sync
with
those
two
proceeded
nodes
which
gives
you
already
a
high
confidence
when
you're
in
sync
them
like
yeah,
it's
a
high
chance
that
everything
is
okay
and
with
every
new
block.
Every
peer
is
publishing
in
the
network,
his
hash
and
you
receive
it
from
your
connected
peers.
A
So
you
get
a
quite
big
number
quickly
of
hashes
with
every
new
block.
So
when
it
would
be
consensus
issue
at
the
next
block
yeah
you
would,
you
would
likely
see
it
and
then
you
would
see
there
the
peers,
which
are
which
deliver
a
different
hash.
And
then
you
can
select
those
and
you
see
over
the
previous
su
and
go
back
and
basically
find
out
at
which
block
the
different
happens.
You
can
regress
from
such
a
peer,
which
is
out
of
sync
with
you.
A
You
can
regress
than
all
the
ashes
from
back
to
the
Genesis
transaction.
With
that,
you
get
an
really
exactly
the
point
where
it
were
a
different
happened
and
I
tested
yesterday,
and
there
was
some
inconsistency
in
our
current
Dow
test
net,
but
nothing
critical.
It
was
just
the
sorting
of
some
lists
was
not
deterministic
and
what
may
be
missing
sweating
and
that
created
differences
and
I've
seen
it
and
when
I
requested
at
a
certain
block
time
it
changed.
A
It
was
actually
the
route
result
where,
when
we
can
edit
some
data,
there
was
some
in
country
there
was
some
non-deterministic
swatting
behavior,
because
we
used
edge,
sets
and
I
had
attended
watching
further
data.
What
we
are
storing
it,
then
it
became
consistent,
and
so
the
good
news
is
that
it
seems
so
far.
I'm
still
not
finished
with
this
project,
but
at
least
this
one
part
is
quite
finished
now.
Also
on
the
dow
state
side,
we
are
consistent.
It
seems
that
we
are
consistent.
A
I
have
only
tested
to
development
notes,
not
with
the
real
with
the
real
notes,
and
the
other
notes
are
not
supporting
this
feature.
So
we
need
a
new
release
until
a
few
tests
have
updated
and
so
on
and
I
want
to
be
more
sure
of
it
before
before,
releasing
it
and
before
asking
other
developers
to
use
it,
but
we
said
we
will
very
soon
see.
A
Then,
if
you,
when
you
run
the
note,
if
you're
a
really
hundred
percent
in
sync,
with
all
the
other
notes,
and
when
one
note
is
not
in
sync,
you
can
contact
the
developers
and
find
out
the
first
thing.
What
you
should
do
is
to
rebuild
your
doubt
state
that
might
happen.
Actually
when
we
are
releasing.
It
then
probably
everybody's
out
of
sync,
because
of
this
sorting
issues
and
so
on,
and
because
you
are
storing
your
house
now
state
and
reapplying
it
you're.
Only
creating
you
had
a
new
stuff
from
the
last
blocks
for
performance
reasons.
A
So
I
expect
that,
basically,
everybody
will
be
out
of
sync
with
everybody
because
of
this
sweating
issue
and
everybody
wins.
You
have
to
rebuild
the
Doucet
from
Genesis
that
take
a
little
bit
of
performance,
but
one
or
two
minutes
of
frozen
UI,
and
then
there
should
be
carousel
and
yeah
I.
Think
we
said
we
get
a
very
yeah,
very
strong
monitoring
about
any
consensus
issues,
so
when
there
would
be
an
issue
we
get
alerted
very
quickly
and
can
try
to
fix
it.
I
will
try
also
to
build
in
some
auto
recovery.
A
So
when
you're
out
insert
that
to
rebuild
the
dowse,
it
is
a
little
bit
costly,
especially
when,
after
a
few
months
or
so
when
the
data
get
much
bigger,
so
I'm
not
so
sure
how
to
deal
exactly
with
it
but
yeah.
It's
still.
It's
still
work
in
progress,
but
at
least
it's
already
quite
far,
and
the
second
piece
which
is
missing
at
the
moment
is
to
monitor
the
peer-to-peer
network
data.
That's
mainly
others.
A
Basically
only
the
proposal
data
after
the
proposal
phase
before
they
are
basically
non
really
contentious
critical
data
because
you
can
move
the
proposal
anyway,
so
they
are
temporary
data.
But
then,
after
the
proposal
phase
in
the
voting
face,
you
cannot
change
your
proposals
anymore
and
basically,
every
user
should
have
the
same
set
of
proposals
and
there
is
already
some
features
where
yeah,
when
you're
missing
proposals,
you're
requesting
it
from
the
network,
and
so
but
it's
still
not
really
100%
complete
and
enter.
A
And
to
avoid
all
these
problems,
we
are
waiting
a
few
blocks,
so
we
will
use
basically
the
same
concept
being
sure
to
be
on
the
same
page
when
creating
the
work
result.
We
are
using
here
for
the
monitoring,
so
we
do
the
monitoring
only
after
the
break,
so
we
avoid
any
issues
with
reworks
and
we
have
enough
time
that
the
data
get
well
distributed
in
the
network.
A
A
It
could
be
a
militia
theory
which
has
created
and
to
what
localism
a
proposal
but
has
manipulated
a
softer
to
never
send
it
out,
so
nobody
else
can
have
it,
but
he
locally
will
have
it
and
then
he
will
arrive
at
a
different
data
set
and
how
to
deal
with
this
to
not
cause
false
positives.
Basically
that,
then
everybody
in
a
network
would
get
a
consensus
alert,
because
this
one
peer
report,
a
different.
A
A
A
Alert
the
red
flag
alert
would
only
come
off
the
few
blocks
when
you
still,
depending
how
many
peers
are
reporting
it,
because
when
there's
one
peer
who
has
maybe
whatever
some
software,
whatever
anywhere,
has
not
updated
like
now
in
the
testing
when
he
had
not
rebuilt
his
doubts
it,
he
will
automatically
report
a
different
hash
and
we
don't
want
to
make
the
user
nervous
because
of
this.
So
we
need
to
figure
out
the
way
how
we
we
deal
all
this
is
either
take
some
priority
nodes
like
the
seed,
not
where
we
say.
A
Ok,
when
you're
in
sync,
with
the
seed,
not
everything
is
fine
when
there
are
some
other
nodes
which
have
which
report
a
different
hash
and
it's
a
problem,
it's
their
problem
of
your
problem
likely,
but
that's
still
a
little
bit,
not
hundred
percent
defined.
How
we,
how
implement
this
and
what's
the
best
way,
how
to
deal
with
this?
Another
small
thing
is
Chris
have
started
to
work
on
a
new
fume
in
the
UI
for
the
Tao,
where
we
want
to
represent
their
economic
aspect
of
the
Tao
in
a
better
way.
A
But
such
data
would
be
good
to
have
in
the
application
itself
as
well.
I
mean
there
will
be
a
additional
on
the
webpage,
also
some
data
about
the
specific
effects
and
figures
about
the
economic
aspect
of
the
Dow
and
beside
this
we
want
to
have
also
than
the
network
statistics
about
the
towel,
like
all
we
have
in
this
page
in
the
wallet,
but
in
the
wallet
is
not
really
the
right
place,
not
about
your
wallet
it's
about
network
and
in
that
area.
A
Probably
we
will
attend
this
consensus
part
as
well
at
the
moment,
I
have
it
in
the
governance
tap,
but
probably
better
to
move
it
into
this
new
tap
and
paid
share
and
for
the
network
yeah.
That
should
be
all
the
statistics.
How
many
transactions
are
there?
How
many
per
in
transactions
all
kind
of
how
many
YouTube
shows
and
so
on
all
kind
of
interesting
statistic?
Data
about
the
Tao
should
be
present
there
and
that's
something.
A
Then,
if
you
are
interested
to
have
to
help
me
there
that
that
would
be
a
great
help,
because
I
need
to
focus
on
the
core
stuff,
like
the
security
stuff,
that
we
are
running,
a
hundred
percent
sure
to
be
on
consensus,
and
so
and
all
you
are
related
stuff
has
lower
priority
for
myself,
but
what
a
user?
Of
course
it
would
be
a
great
benefit,
and
if
you
can
help
me
to
get
this
implemented,
error
would
be
great
beside
this
year
with
the
plans.
A
Also
when
everything
goes
good,
I
assume
in
one
week,
I'm
done
with
this
monitoring
and
consent.
This
hash
stuff,
then
my
something
which
I've
thought
probably
very
soon
is
to
start
a
main
net
testing
Genesis
as
a
Genesis
distribution
or
may
not,
but
just
for
testing
nothing
real
and
just
with
a
few
developers.
A
It
will
be
only
weighs
a
few
developers
who
really
actively
testing
it,
but
it
will
help
us
to
test
more
realistically
with
real
transactions
on
the
may,
not
with
big
blocks
and
especially
from
performance
side.
I
think,
that's
one
area
what
we
might
need
a
little
bit
more
effort
before
we
launch
to
avoid
any
any
performance
issues.
A
Maybe
it's
more
realistic,
mid
of
April,
but
it's
at
least
we
are
getting
close
and
there
are
no
big
showstoppers
visible
at
the
moment
and
a
general
start
achieve
for
the
release
is
that
we
don't
want
to
add
any
additional
risk
to
the
project.
So
any
bigger
changes
which
could
add
risk
for
this
itself
will
be
delayed
after
the
launch
or
the
one
or
two
months
after
the
launch
to
not
get
any
problem
into
that
into
that
time.
A
A
A
A
I
just
wanted
to
yeah
to
bring
this
out
that
around
at
our
launch
or
already
now,
because
we
are
getting
close
there,
we
shouldn't
have
any
bigger
risky
new
releases
or
features
might
be
one
exception
on
the
peer-to-peer
network
site
because
yeah
we
have
some
issues,
probably
a
little
bit
in
the
peer-to-peer
network
that
it
it's
under
two
heavy
load
and
messages.
Don't
arrive
and
floran
is
working
on
this
and
it's
probably
such
a
operator
that
we
and
it's
high
highly
risky.
A
So
that's
a
little
bit
of
a
dangerous
thing,
but
it
seems
that
we
have
to
fix
this,
and
it
would
be
also
very
bad
for
the
tower
when,
on
the
same
time
or
even
when
we
get
more
users,
maybe
which
the
tower
launch
can
attract.
Also
many
more
new
users
that
we
get
even
more
problems
than
other
peer-to-peer
network
site
and
especially
because
of
the
Tao,
is
using
and
depending
a
lot
on
the
peer-to-peer
network
and
also
adding
loads
on
the
peer-to-peer
network.
Not
much
I
think
that
it
will
add
something.
A
B
A
Yeah,
it
sounds
really
blessing
also
from
the
feature
set.
It
probably
won't
wait
what
time
the
features
a
little
bit
larger
and
it
makes
more
sense
for
the
users
to
use
it,
and
so
maybe,
let's
try
to
target,
maybe
so
one
or
two
months
after
that
out
depending
how
well
the
tower
launch
goes
if
there,
when
there
are
no
problems
at
all,
I
think,
one
months
after
the
tower,
we
are
basically
ready
to
for
the
next
adventures.
B
A
B
B
B
A
Judy
anything
else,
Minard
a
little
bit
up
it
with
some
bug
fixes
or
whatever
I
mean
there
was
a
a
pact
with
wallet
restore
it's
only
a
cured
after
when
you
have
the
wallet,
a
real
wallet,
basically,
which
has
a
certain
age
that
white
usually
didn't,
was
not
discovered
at
testing.
When
you
do
with
rectus,
just
a
new
wallet
and
restore
it
it.
What
was
working
fine,
it
was
the
balance
was
correct,
so
the
internal
balance
was
there
and
so
was
not
really
a
big
risk.
A
It
was
just
not
displayed
in
the
UI,
because
the
address
entry
database
file,
which
we
need
for
for
maintaining
a
data
structure
for
addresses
which
are
used
in
the
trade
that
they
are
reserved.
Basically,
when
you're
funding
your
offer
that
this
money
is
not
used
for
sending
Bitcoin
to
somebody
also-
and
this
wallet
database
file
was
not
updated
correctly
at
restore,
and
then
the
balance
showed
zero
Bitcoin
internally
to
follow
para
balance.
A
When
you
made
CMD
e
with
this
emergency
Balan
were
late
tool,
you
get
basically
internal
of
all
that
balance
from
Pitkin
trade
and
there
it
was
all
correct
just
for
the
user.
It
was
not
display
correctly
and
I
having
a
few
bug
reports
and
yeah
that's
fixed.
Now
we
improved
also,
if
you
are
the
things
in
that
era,
that
the
restart
is
now
automatically
done
and
not
optional.
A
That
was
basically
that
idea
to
leave
it
to
the
user
when
he
restart
after
he
decided
to
make
a
restore
and
the
sink
there
was
all
was
something
else
yeah
with
peer-to-peer
network
sinks.
There
was
some
issues,
so
anybody
any
developer
or
anybody
who
runs
from
Suez
code
be
sure
to
be
on
the
latest
master
version,
because
they
have
some
smaller
issues
which
could
lead
to
some
problems
some
bugs,
but
that
should
be
fixed.
A
It's
still
a
little
bit
Florin
it's
running
once
he'd,
not
with
his
most
recent
development
code
and
with
some
improvements
and
there
he
gets
much
more
data
like
who
the
other
seed
notes
and
the
normal
node,
and
it's
a
little
bit
yeah.
We
don't
know
yet.
Why
can
be
that?
In
the
worst
case,
the
peer-to-peer
network
is
really
in
a
bad
state
and,
and
certain
percent
of
the
messages
do
not
really
arrive
at
each
node,
but
I
assume
that
supplicates,
probably
some
at
the
end
in
his
new
version
of
decedent.
That
he's
not
deleting
data.
A
A
Beside
all
the
special
topics
of
the
working
on
regarding
bit
crunchy
fifteen
I
think
we
talked
last
week
a
little
bit,
but
just
a
quick
overview.
I
talked
with
Oscars
about
the
road
map
and
it's
not
really
thick
that
we
will
move
a
word
and
integrate
it
or
have
it
integrated
in
the
next
three
months,
at
least
of
the
minimum
three
to
six
months.
It
will
take
time
to
really
battle-tested
to
integrate
it
and
basically
provides
lots
of
changes
on
the
piste
and
on
our
side,
and
it's
likely
missing
missing.
A
Some
features
like
proper
support
for
both
legacy
addresses
and
the
new
addresses,
and
maybe
we
need
to
change
them
in
the
tray
protocol.
Maybe-
and
that's
maybe
an
important
issue
as
Whiston
planned
for
the
new
trade
protocol,
we
will
have
it
sort
of
hard
work,
so
new
users
who
have
updated
will
not
be
backward
compatible.
They
should
be
still
able
to
read
all
the
database
files.
Although
the
local
data
has
to
be
compatible
and
it
just
can
go
on,
but
then
they
cannot
trade
with
peers
from.
A
We
have
not
updated
and
it's
not
decided
yet
it
exact
details
if
it
will
be
really
a
different
network.
So
we
have
a
few
version
numbers
where
we
can
basically
separate
the
network
also
or
separate
on
the
trade
protocol,
that
you
cannot
trade
with
some
users
who
have
not
updated,
and
so
so
we
want
to
keep
it
as
minimum
as
possible.
But
the
good
thing
is
because
it's
account
like
a
hard
work.
A
We
have
the
chance
to
clean
up
stuff,
so
some
liquor
C
code,
which
was
only
kept
because
of
backward
compatibility
compatibility,
can
be
maybe
removed
at
this
time.
Maybe
not.
It
depends
on
the
concrete
situation
of
this
sort
of
hard
work
and
especially
with
trait
protocol.
Everything
was
related
with
the
trade
protocol,
because
that,
for
sure
will
be
a
half
work.
A
A
We
could
change
it
also,
but
yeah,
it's
something
what
we
should
keep
in
mind
and
everybody
in
his
domain
when
he
thinks
I
would
like
to
change
something,
but
I
cannot
because
it
would
break
backward
compatibility.
So
that
can
be
an
opportunity
in
the
next
three
four
months
we
said
releasing
the
new
trade
protocol,
where
we
can
do
this,
maybe
not,
but
it's
at
least
up
to
discussion
regarding
their
plans
for
a
new
trade
protocol.
Yeah
we
are
delayed.
Also
I
have
not
heard
back
from
Craig.
A
He
have
problem
with
his
back,
so
he
cannot
work
at
the
moment
and
Neyman
has
updated
improved
the
specification,
but
I
didn't
had
time
to
review
it,
and
we
have
discussion
between
the
next
days.
So
once
this
specification
is
really
more
or
less
complete,
then
yeah
we
can
have.
We
can
use
maybe
one
session
where
everybody
is
reviewing
it
and
we
have
a
discussion
about
it
and
after
the
towel
we
have
to
figure
out
how
we
can
with
development
on
this
sides
when
Craig
is
still
not
back
to
work.
A
Maybe
I
have
to
work
on
it.
Probably,
but
we'll
see
it's
at
least
delayed
at
the
moment,
and
but
it
is
still
a
high
priority,
because
that's
very
important
to
improve
trading
is
experience
with
one
important
feature
is
that
users
can
get
into
our
context
and
then
the
second
step
is
to
ask
a
mediator
which
doesn't
hold
the
third
key,
so
that
improves
about
security
concerns
and
decentralization
concerns,
and
then
arbitrations,
optional
and
yeah
to
get
in
the
details.
A
A
Yeah
by
the
way
Christophe
is
on
holiday.
That's
why
he
didn't
join
and
they
are
comparing
it
didn't
work
back
here.
He
is
sick,
but
yeah
I
hope
this
time
works
well
the
next
week
again.
So
we
sit
with
this
time
until
nobody
complains
very
bad
but
I
think
they're
in
the
only
timeslot
various
time.
The
problem
he
has
to
stick
with
this
and
yeah
then
I'll
leave
it
a
little
bit
open
with
Doug
and
before
next
week.