►
Description
This week the EOSIO Coalition Discusses market research, Coalition testnet, Faster Finality RFP, reviews the milestones, timeline and costs associated with deployment.
00:00:00 Intro
00:00:04 Rebranding name status by Jeff, Yves
00:02:06 Market research by Jeff
00:03:24 Scalability blue paper by Lucus, Yves
00:09:00 Status of the RFPs by Jeff, Aaron, Yves. Gnome
00:17:53 Coalition testnet question by Douglas
00:21:10 Proofs, analysis, and project management by Gnome
00:24:20 Aggregate signatures by Gnome
00:51:48 Faster Finality by Gnome
00:59:10 Coalition testnet and performance by Gnome
01:03:46 Deployment and support by Gnome
01:08:07 Time to deployment, milestones, and finance by Gnome
01:56:56 End
Everything EOS is the official media channel of the EOS Network Foundation (ENF). The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://eosn.foundation
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosn.foundation
#EOS #EOSIO #ENF
B
B
And
so
we
still
don't
have
a
follow-up
meeting
timeline
right
now,
but
we
don't
expect
to
be
able
to
report
anything
until
next
week,
seemingly,
but
even
next
week
it
wouldn't
be
ready.
So
maybe
two
weeks
three
weeks
seems
to
be
the
indication
that
we
got
they
while
we
were
just
what
they
mentioned
is
while
they
were
waiting
on
marketing
research
to
confirm
the
result.
They
kind
of
took
a
side
on
this.
They
didn't,
they
didn't
go
full
steam
ahead.
B
Now
that
they've
got
that
it,
I
guess
confirmed
what
they
had
also
done,
and
so
now
it's
back
full
steam
ahead.
On
the
on
their
side,
I
guess
the
coalition
had
determined
to
pause
or
postpone
the
making
public
of
the
name
until
the
extra
design
assets.
Branding
assets
were
ready
due
to
the
current
market
conditions,
and
that
should
we
be
releasing
at
this
time
the
the
announcement
would
likely
fall
flat
on
its
own.
A
Okay,
then
we
will
touch
back
next
week.
It
sounds
like
it's
going
to
be
a
multi-week
thing,
so
we'll
just
get
a
quick
status
each
week
until
that
resolves
next
item
the
market
research.
I
hope
everybody
saw
the
link
that
I
posted
into
the
telegram
channel
on
the
results
of
the
survey.
So
it
just
looks
like
inherently
when
people
who
are
not
within
the
blockchain
industry
are
thinking
about
what
they
would
want
in
a
blockchain.
Their
thoughts
gravitate
towards
security.
A
A
C
B
C
C
B
C
Yeah
we
could
so
for
each
of
the
items
at
the
end,
because
that's
where
the
projects
are,
we
could
essentially
provide
like
a
summary
of
like
here's,
the
one
paragraph.
That's
got
me
a
project
and
then
provide
timeline,
cost
and,
and
then
who's
gonna
be
doing
it,
for
example
right.
So
it
could
be
also
a
living
document
where
we
update
these
things
as
we
go.
D
B
B
That
would
be
okay,
even
not
including
that
in
there
necessarily
because
right
now,
the
way
it's
written,
it's
more
so
the
why
we
we
believe
that
those
items
are
particularly
useful
and
keeping
it
at
that
and
then
what
those
items
are
etc,
but
I
don't
think
it
needs.
In
my
opinion,
the
blue
paper
doesn't
need
to
say
the
who
and
the
how
much
if
they
were
included,
that's
cool
if
they
weren't
included.
I
think
you'd
almost
be
done.
C
B
There
was
one
general
comment
and
I
guess
you
can
just
comment
here
and
the
graphs
that
you
showed
for
dap
radar
in
in
the
three
or
four
instances.
It
was
always
eos
and
wax.
Do
you
know,
and
I
don't
know
the
answer
I
could
go
check,
but
do
you
know
if
ux
I
would
guess
not,
but
that
telos
was
one
of
the
options
that
we
could
highlight,
or
was
it
just
not
an
option
so
there's.
C
There's
so
there's
two
graphs
from
that
operator.
First
one
shows
us
io
chains
being
tracked
and
that
is
wax
eos
telos
and
telos
evm
and
then
and
and
I
don't
believe
they
actually
track
any
other
chains
yet
and
then
the
second
graph
is
top
five.
So
you
kind
of
have
a
view
of
eos
io
ecosystem
and
then
overall
ecosystem
as
a
as
a
as
a
second
graph.
B
B
C
A
All
right,
moving
on
the
next
one
status
of
the
rfps,
we'll
come
back
to
faster
finality
because,
as
we
discussed
we'll
be
reviewing
that
in
a
little
more
detail
for
the
sdks
actually
aaron,
this
is
to
you
that
you
are
going
to
come
up
with
a
suggested
list
of
three
components
to
be
created
in
each
category,
then
to
send
back
to
the
coalition.
The
coalition
would
say:
yes,
we
agree,
these
are
good
selections
or
no,
we
should
do
something
different.
Is
there.
A
B
If
I'm
not
mistaken
and
obviously
aaron
can
can
chime
up,
I
don't
know
if
it
it
matters.
If
we
go
through
the
sdks
today,
because
it's
not
ready
anyways,
so
my
preference,
knowing
that
is
that
we
should
go
to
faster
funality,
because
we
can
talk
about
sdks
another
time
unless
aaron
you
need
the
information
from
that
sooner
rather
than
later.
B
A
All
right
so
perfect,
so
aaron,
if
you
can
just
post
your
suggested
list
to
the
channel,
and
probably
we
could
do
this
all
through
telegram
if
we
just
get
each
of
the
chains
to
kind
of
either
comment
or
give
a
thumbs
up
on
it.
And
if
the
comments
look
like
more
discussions
needed
we'll
we'll
just
table
and
come
up
with
the
new
agenda
item
for
next
time.
G
A
No
problem
so
guillaume
we're
ready
to
look
at
the
proposal
that
you
sent.
So
would
you
like
to
share
your
screen
and
you
can
take
us
from
the
top
but
go
through
the
major
items
and
then
we
can
have
open
q
a
as
you
go
through
the
whole
thing
and
then
at
the
very
end,
once
there's
some
serious
discussion
about
pricing.
A
B
B
I
A
A
B
B
Oh
really,
because
I
need
yom
there
and
ideally
jessie
will
be
joined
by
them.
Okay
got
it.
It's
it's
going
to
be
somewhat
of
a
it's,
not
that
it's
that
big
of
a
heavy
topic,
but
it's
quite
important,
okay
sounds
good,
so
I
would
rather
wait
and
if
it's
not
in
this
call,
we
can
do
another
ad-hoc
call.
That's
that's!
Okay
with
me.
D
H
H
I
also
highlighted
which
elements
referred
to
which
of
the
of
the
like
requirements:
business
requirements,
technical
requirements,
performance
and
deployment
and
maintenance.
So
I
got
I
got
like
all
of
these
in
basically
like
separated
in
sections
like
the
first
one
is
general
like
proofs
and
analysis
project
management
tasks.
Second,
one
is
the
aggregate
signatures.
H
H
Then
coalition
test
net
and
performance
analysis,
so
I
think,
as
opposed
to
most
of
the
other
changes,
this
one
is
quite
quite
disruptive,
so
it's
not
it's
not
something
you
can.
You
can
test
necessarily
on
jungle
or
kyle
and
at
least
not
at
least
not
as
a
first
draft
like
it
has
to
be
tested
thoroughly
in
a
test
net.
K
Then
can
I
can
I
jump
in
with
a
question?
Yes,
so,
first
of
all
sorry
to
be
late,
I
was
on
the
I
had
started
another
one
and
I
was
on
there
and,
secondly,
real
quick.
I
wanted
to
introduce
sean
who's
here
from
good
block,
but
he's
been
he's
been
a
long
time
involved,
not
only
in
telus
but
also
ux.
So
guillaume,
you
probably
know
him
and-
and
so
my
question.
D
K
H
H
So
it's
not
it's
something
that
you
know
like
when
we,
when
we,
I
guess
like
bring
it
to
production
on
any
of
these
chains.
Yes,
ux
delos
wax.
It
has
to
be
activated
through
a
vertical
activation
feature.
It's
a
hard
phone
technically
and
the
the
the
nodes
will
also
have
to
upgrade
like
full
nodes
will
have
to
upgrade
in
due
time
as
well.
So
it's
it's
it's!
It's
really
for
the
development
of
the
feature
and
the
testing
that
we
required.
K
Later
on
on
that
surface,
I'm,
I
think
I
think
we
should,
I
think
when
we
come,
you
know
we
should
have
a
test
net
right,
it's
good
branding.
We
can't
assume
the
jungle
and
everything
else
is
gonna.
Do
what
we're
gonna
do
and
I
think
it's
fairly
inexpensive
for
us
to
find
you
know
people
to
to
run
it
so
right.
H
Yeah-
and
I
mean
it's
not
like,
of
course,
some
questions
will
arise
as,
for
example
like
which
system
contracts
we're
gonna
want
to
run
because
all
of
different,
like
all
of
our
chains,
have
different
system
contracts
and
they
might
have
like
separate
little
features
here
and
there,
but
it
may
make
sense
to
have
something
like
a
generic
test
net
that
that
kind
of
carries
like
the
minimalistic
system
contracts.
Just
too,
we
can
figure
that
out.
I
think
yeah
absolutely,
but.
J
H
H
It's
the
finality
violation,
proof
so
essentially
like
the
the
idea
is
we
want
to
be
able
to
demonstrate
that
in
case
a
block
producer
double
signs,
a
block
like
two
different
blocks
at
the
same
block
height.
We
want
to
be
able
to
demonstrate
that
that
final
finality
violation
occurred,
and
I
believe
eric's
idea
was
that
there
could
be
slashing
consequences
attached
to
that,
so
so
that
that
kind
of
that
kind
of,
like
also
a
little
like,
fits
a
little
bit
in
this.
H
This,
like
proof,
analysis,
because
we
also
have
to
demonstrate
that
such
a
financial
violation
could
be
demonstrated.
Cryptographically
and
would
would
be,
would
be
part
of
that.
That
section,
there's
there's
also.
He
also
asked
for
a
network
latency
analysis.
So,
under
this
new
faster
finality,
there's
gonna
be
there's
gonna,
be
like
a.
I
guess,
like
a
difference
in
the
load
of
the
of
of
nodes,
bp
nodes,
but
also
api
nodes,
because
now
they
have
to
communicate
these
block
messages
between
each
other.
H
So
you
wanted
to
also
have
a
theoretical
analysis
of
how
much
that
would
impact
general
network
latency
overhead,
like
like
how
much
data
that
represents
and
whatnot
it's
it's.
It's
not
not
very
significant,
but
I
think
I
think
the
a
lot
of
this
had
to
do
with
opening
the
possibility
for
more
block
producers
than
the
21
that
we're
currently
aiming
to
support.
So
we've
built
this
proposal,
I
mean
the
rfp
and
the
proposal
reflects
that
as
well.
H
You
know
number
of
blood
producers
up
to
100,
so
it
would
essentially
expend
that
quite
significantly
compared
to
to
the
previous
the
current
esio
consensus
model,
then
I
did
also
general
project
management
coordination,
communication
with
the
yes
io
plus
coalition.
So
that's
that's
part
of
them
of
that
section.
Here
then,
the
two
main
sections
for
the
actual
work
itself
are
the
aggregate
signatures
that
essentially
is
a
kind
of
a
standalone
module
that
that
we're
proposing
to
add
in
there
and
then
faster
finality
itself.
H
Now
the
aggregate
signatures
is,
I
think,
in
the
in
dan
larimer's
proposal,
early
on,
like
yeah,
when
he
was
talking
about
faster
finality.
He
was,
he
didn't
include
anything
that
had
to
do
with
aggregate
signatures,
but
the
problem
with
that
is
essentially
like
it
increased
the
size
of
the
black
headers
dramatically.
H
If
we,
if
we
don't,
have
these
aggregate
signatures
in
there-
and
it
also
increases
the
validation
time
for
the
verification
of
these
signatures
quite
dramatically,
especially
as
a
scale
to
a
higher
number
of
block
producers.
So
I
mean
a
lot
of
this
again.
Like
I
mean
I,
eric
has
been
kind
enough
to
provide
quite
a
bit
of
of
work
in
the
drafting
of
this
rfp,
and
it's,
I
think
he
was.
H
He
was
aiming
for
a
a
little
bit
more
flexible
consensus,
algorithm
like
moving
away
from
21
the
requirement
of
21
block
producers
and
allowing
the
support
of
up
to
a
hundred
blood
producers.
And
that's
that's
that's
part
of
the
reason
why
we're
essentially
going
at
it
this
way.
So
the
aggregate
signatures
and
faster
finality
both
of
them
share
some
of
the.
I
guess
like
kind
of
basic
work
that
includes
specifications
and
unit
tests
for
these
modules
in
the
case
of
aggregate
signatures
we
want.
H
We
also
are
reviewing
existing
schemes
that
are
currently
in
existence.
There's
there's
a
few
of
them
like
there's
snore,
there's
a
schnoor
ns,
there's
bls,
there's
a
few
others
like
threshold
signatures
and
whatnot.
Currently
we're
leaning
quite
heavily
towards
bls
and
there's
there's
good
reasons
for
that,
one
of
which
is
it's
quite
battle
tested.
It's
been,
it's
been
in
existence
for
a
while,
there's
been
a
ton
of
research.
That's
been
done,
there's
a
number
of
very
good
implementations
that
already
exist
just
to
answer
douglas.
H
Yes,
we
would
be
able
to
increase
the
number
of
block
producers.
It
would
not
impact
the
time
to
lib
having
more
block
producers
necessarily
because,
essentially
the
you
get
you
get
like
the
the
way.
The
way,
the
way
our
proposal
is
the
way
we're
planning
to
address.
This
is
essentially
block
producers
when
they
receive
when
they
receive
a
block
from
block
producers.
H
The
other
block
producers
that
receive
that
block
now,
instead
of
instead
of
waiting
their
turn
to
produce
to
to
essentially
indicate
on
which
fork
they
are.
They
immediately
send
a
message,
a
confirmation
message
that
in
which
they
sign
a
the
the
blood
digest,
and
essentially
they
broadcast
that
to
the
rest
of
the
network
and
then
every
full
node
can
start
aggregating
all
of
these
signatures
together
and
create
one
aggregate
signature
that
can
be
verified
at
any
given
point
for
that,
two-thirds
plus
one
requirement
bft
requirement.
H
K
D
K
A
bit
probably
above
everything
else
without
without
overloading
the
channels,
so
I
actually
had
wanted
to
do
that
when
we,
when
we
launched
telus,
increase
it
to
42,
but
but
the
problem,
the
slowing
down
the
lib
to
six
minutes
was
what
you
know:
yes
not
accessible.
So
I
think
this
will
be
great
and
I
think
this
will
shut
down
a
lot
of
people
in
the
who
criticize
eocio
as
having
as
having
too
few
validators.
So.
L
One
thing:
no,
no,
I
want
to
clarify
when
we
talk
about
consensus
and
not
changing
the
consensus,
algorithm
you're
talking
about
bft
and
two-thirds
plus
one
correct,
not
we're
not.
I
mean,
because
within
the
system
contracts
is
where
right
now
we've
maintained
dpos,
you
could
change
it
to
proof
of
stake.
You
could
change
the
proof
of
authority
via
consortium.
You
could
there's
all
these
things.
You
could
do
within
the
system
contract
level
that
some
people
might
describe
as
the
consensus
algorithm,
but
there's
two
different
things
we're
talking
about
here.
Yeah.
H
L
H
H
Exactly
and
that's
like
quite
a
bit
of
care,
went
into
completely
separating
these
two
functions
so
that
essentially
like
we're.
We
still
allow
maximum
flexibility
for
things
like
that,
like,
for
example,
with
you
guys
at
telos.
You
have,
I
think,
this
standby
rotation
that's
built
in
that's
not
affected
by
what
we're
doing
here.
This
is.
This
is
completely
separate
and
you're
still
able
to
do
that.
No
problem
you're
also
able,
of
course,
to
increase
or
decrease
the
number
of
block
producers.
As
you
see
fit.
H
This
only
affects
essentially
like
the
like
the
yeah,
the
byzantine
fault,
tolerance
of
the
system,
at
which
point
can
you
ascertain
a
particular
block?
Is
final
and
won't
be
reversed,
so
it's
it's
strictly
limited
to
that
part,
so
it
sits
kind
of
a
one
layer,
one
level
below
the
the
actual
consensus
model
right.
K
H
So
it's
it
depends
on
a
number
of
variables
like
it's,
not
it's
not
going
to
be
necessarily
like
fixed
at
x
number
of
blocks.
It
depends
on
essentially
like
how
many
like
how
big
these
blocks
are.
How
many,
I
guess
like
how
fast
the
the
network
can
propagate
these
plugs
and
get
gather
enough
signatures,
and
so
on
and
so
forth.
So
there
is
a
logarithmic
increase
in
the
finality
with
the
number
of
blood
producers,
but
it's
legarrette.
So
it's
not
it's
not
like.
H
K
H
F
I
C
K
B
B
H
And
we're
we're
targeting
we're
targeting
a
range
of
let's
say
between
one
and
a
hundred
block
producers.
So
the
this
this
is
kind
of
optimized
for
that
particular
range
where
you
probably
get
the
quote
quote
best
bang
for
your
buck
around,
like
yeah,
like
probably
around
like
what
douglas
was
saying
with
his
napkin
matt,
like
probably
already
yeah
and
then
and
then
like,
but
it
would.
It
would
also
possibly
be
able
to
push
it
a
bit
further
than
that
by
like
making
some
like
changes
to.
H
J
K
H
About
the
trade-offs
because,
obviously
like
if
you,
if
you
increase
the
number
of
validators,
then
you
have
to
either
decrease
the
throughput
or
the
time
the
finality,
and
vice
versa
like
for
for
any
of
these
three.
So
like
it's
always
like
between
these
three,
you
decide
like
how
many
validators
you
want,
what's
the
faster,
what's
the
fastest,
the
finality
time
time
to
finality,
and
then
the
true
put,
and
if
you're,
if
you're,
increasing
one
you're
like
decreasing
the
other
two
and
so
on
and
so
forth.
So
it's
kind
of
always
always
like
that.
H
To
rest
yeah,
exactly
yeah,
yeah
now,
and
so
so
anyway.
So
that's
with
regards
to
the
the
different
aggregate
signature
schemes
like
I
was
saying:
we're
probably
gonna
go
with
bls.
One
of
the
reason
also
is
I
mean-
and
this
is
this-
is
speaking
for
ux.
The
the
main
reason
why
we
as
ux
are
so
interested
in
fast.
Fidelity
is
because
this
essentially
is
critical
for
interacting
with
ethereum.
H
H
You
know
like,
of
course,
now
it's
a
bit
lower
because
transaction
volume
went
down,
but
let's
say
like
for
the
past
year,
where,
like
gas
fees
on
ethereum
were
often
like
five
like
fifty
dollars
a
hundred
dollars
or
whatnot,
I
approved
verification
would
be
like
almost
ten
thousand
dollars
in
gas
fees.
So
that's
that's.
That's
completely
ludicrous
and
that
doesn't
make
any
sense,
and
this
is
because
the
proof
size
under
the
current
bft
protocol
that
underpins
esio
is
quite
big.
H
It's
essentially
about
like
12
kilobytes
of
data
and
takes
and
takes
quite
a
bit
of
cpu
to
verify
so
faster
finality
allows
us
to
shrink
that
proof
to
a
much
smaller
number
like
a
much
smaller
size
and
bls
is
the
aggregate
signature
scheme
that
ethereum
2.0
is
is
using
so
essentially
like.
As
I
mean,
we
don't
know
when
ethereum
2.0
is
going
to
be
out,
but
that's
that's
the
the
target.
H
B
K
D
K
H
The
the
but
the
caveat
is
that
for
each
signature
scheme
you
want
to
be
able
to
support
you're
going
to
have
to
have
a
different
signature
field.
That's
going
to
be,
I
mean
it
doesn't
necessarily
need
to
be
in
the
block
header,
but
it
has
to
be
made
available
to
to
other
nodes.
Essentially
that
would
want
to
create
these
proofs
so
essentially
like.
H
If
you
there's
there's
there's,
I
guess,
like
a
case
could
be
made
for
supporting
also
standard
ecdsa,
which
means
that
ecdsa
would
essentially
means
that
you
need
to
keep
one
signature
per
block
producer.
So
imagine
now
you
have
21
block
producers.
That
means
that,
for
every
block
you
need
to
maintain
21.
H
H
So
it's
probably
not
a
good
idea
to
put
them
in
the
block
headers
directly,
but
it
makes
perfect
sense
to
put
them
in
my
my
makes
perfect
sense.
In
my
opinion,
to
put
them
in
the
block,
header
state,
which
is
essentially
typically
dropped
after
lib,
has
been,
has
been
received
or
could
be
probably
kept
in
memory
for
a
little
bit
longer
by
the
node,
so
that
it
can
still
provide
that
data
that
other.
H
H
H
Exactly
so
so
under
under
the
current
assumption,
we're
not
doing
that,
but
if
this
is
something
that
the
coalition
feels
should
be
supported,
then,
like
there's,
there's
there's
probably
good
reasons
that
we
would
want
to
include
that
as
well.
So
if
this
is
something
that
the
coalition
want,
we
can
definitely
look
into
it
as
well.
It.
H
Okay,
exactly
and
then
reviewing
comparison
of
existing
c
plus
plus
implementations.
One
of
the
reasons,
as
I
was
saying,
bls
was
quite
high
in
our
initial
research
is
that
they
have
very
strong
implementations
already
so
ethereum
2.0
has
an
implementation,
there's
also
chia
network,
that's
built
by
bran
cohen,
the
guy
from
bittorrent
that
has
a
very
solid
implementation
of
of
bls
and
so
far
so
far
it's
I
I
believe
it's
the
most
advanced,
but
we
will
also
par
as
part
of
the
of
the
of
the
work
here.
H
Yeah
and
there's-
and
it's
always
again,
it's
kind
of
always
straight
ups
like
where
some
schemes
might
be.
You
know
like
a
result
in
shorter
signatures,
some
might
take
longer
or
shorter
verification
times
you
might
have
like
difference
and
the
time
it
takes
to
actually
sign
these
messages
with
these
signature
schemes
and
whatnot,
and
all
of
this
is
kind
of
part
of
that
that
research
like
we
need
to
kind
of
like
measure
these
trade-offs
and
determine
which
one
is
is
the
most
suitable.
H
One
key
factor
in
favor
of
bls,
as
opposed
to
schnorr,
for
example,
is
typically
schnorr.
Signatures
are
interactive,
so
that
means
that
block
producers
need
to
essentially
exchange
information
between
them
before
they
can
actually
sign
that
thing
that
that
that
that
transaction,
so
there's
additional
potential
chatter.
If
we
use
schnorr
or
threshold
signatures,
bls
is
non-interactive,
so
you
don't
need
to
have
that
additional
layer
like
rounded
communication
between
signers.
H
So
that's
why
that's
also
like
kind
of
reduces
the
network
congestion,
if
you're
using
bls
compared
to
snore-
and
it's
it
see
it
seems
like
this-
is
also
like
what
like
therium
2.0.
For
example,
they've
been
doing
a
lot
of
research
on
these
questions,
and
I
like
I
would
I
would
I
guess,
like
my
hypothesis,
is
they
settled
on
bls?
For
that
reason,
as
well?
H
H
H
Spares
representation
means
that
this
map
identifies
which
block
producers
are
present
in
that
aggregate
signature
or
actually
not
spares.
It
means
that
which
ones
are
are
present
or
absent
as
part
of
the
signatures,
and
then
dance
represents
like
just
a
list
of
all
blog
producers
that
have
signed
that
message
so
like
with
the
an
aggregate
signature
essentially
for
for
those
who
might
not
know
the
terminology,
an
aggregate
signature
essentially
represents.
H
Is
you
have
a
blog
producer
that
has
a
public
key
that
is
known
in
advance
and
then,
when
they
sign
a
message,
they
generate
a
signature
that
of
course
matches
the
private
key,
the
the
public
key.
So
you
can
recover
the
public
key
that
was
used
for
to
sign
a
specific
message,
so
just
just
like
typical
ecdsa
works,
the
same
way
but
aggregate
signatures
have
that
additional
property
that
you
can
combine.
H
Multiple
aggregate
keys,
multiple
signatures
and
multiple
keys,
public
keys
into
aggregate
public
keys
and
aggregate
signatures,
and
the
mathematical
relationship
is
maintained.
So
so
what
that
means
is
essentially,
if
my,
if
I
block
producer,
a
signs,
a
message
and
then
block
producer
b
signs
the
same
message,
I
can
add,
like
block
producer
key
one
block
producer,
one
key
and
block
research,
key
blood
pressure,
two
key
together
and
add
block
producer,
one
signature
and
block
producer,
two
signature
together
and
my
aggregate
key
will
match
the
aggregate
signature.
H
So
essentially
you
can
you
can
just
do
that:
arithmetic
calculation,
where
are
you're,
adding
the
public
keys
together
and
the
signatures
together,
and
you
can
still
verify
that
that
aggregate
key
matches
that
aggregate
signature
which
is
not
possible
with
ecdsa
under
ecdsa.
You
have
to
essentially
compute
this
for
every
single
signature.
So,
like
you
have
21
producers,
you
need
to
verify
21
signatures,
for
example.
H
So
that's
that
saves
us
a
lot
of
space
a
lot
of
time
and
it's
quite
it's
quite
nice.
What
you
can
do
with
that
so
and
it's
not
limited
only
to
the
benefits
that
we
gain
in
faster
finality.
This
opens
the
door
to
a
lot
more,
including
like
privacy
applications.
You
know
like
things
that
that,
like
I
guess,
like
gains
of
performance
across
many
other
things,
you
know
like
there's,
there's
quite
a
bit
of
additional
stuff
that
can
derive
from
that.
So
it's
it's!
H
So
that
opens
the
door
to
even
more
flexibility
and
how
we
we
exchange
these
messages,
because
now
you
can,
you
can
send
that
compressed.
You
know
like
aggregate
signature
and
binary
map
and
then
start
removing
these
additional
look
like
these
additional
signatures
and
these
additional
keys
and
kind
of
work
backwards
to
identify,
for
example
like
which
signatures
are
missing
or
which,
which
keys
were
not
part
of
the
of
the
the
calculation.
H
So
that's
also
part
of
the
of
what
we're
suggesting
to
implement
that
that
opens
again
a
lot
more
doors
in
terms
of
especially
in
terms
of
like
confidential
transactions
and
various
various.
I
guess
like
privacy
features,
because
now
let's
say
you
have
a
multi-sig,
you
don't
need
to
even
reveal
which
parties
are
part
of
that
multi-sig.
You
can
have
a
multi-sig
that
that
essentially
is
or
keeps
the
the
participant,
private
and
potentially
even
like
keeps
whichever
participants
sign
the
transaction
private.
So
it
opens
the
door
for
a
lot
more.
H
So
and
then,
of
course,
these
aggregate
signatures
have
to
be
implemented
in
yes,
io
itself,
as
well
as
esio
cdt,
because
they
need
to
be
available
both
inside
the
context
of
a
smart
contract
and
outside
of
that
context,
and
then
there's
also
time.
That's
allocated
to
the
protocol
feature
activation
like
how
we're
going
to
do
the
the
actual
upgrade
and
how
that's
gonna
take
place.
H
H
Are
familiar
with
them,
the
other
extension
like
subsystem,
but
that's
kind
of
that's
kind
of
what
this
this
represents.
You
initially
can
all
of
this
additional
information
that
sits
in
the
in
the
block.
Header
can
be
added
to
a
to
to
a
header
extension
and
and
doesn't
require
the
heart
for
right
away
and
then
eventually
can
be
moved
to
the
block
header.
If
that's
where
it
ends
up
being
because
I
don't
think
we
need
necessarily
to
add
it
to
the
block
header.
H
H
So
obviously,
that's
it's
quite
an
important
part
as
well,
then
moving
fast
finality,
there's
there's
a
couple
items
there.
These
are
kind
of
the
high
level
ones.
So
we
have,
of
course,
the
change
to
the
black
header
data
structure,
again,
not
sure
if
it's
gonna
be
block
header
or
blockade
or
state,
but
we're
open
suggestion
there.
H
Then
the
binary
map
in
binary
map
functions
to
allow
for
a
quick
verification
of
these
aggregate
signatures.
So
to
know
for
node
to
be
able
to
know
rapidly
whether
or
not
it's
it's
like
a
an
aggregate
signature
is
valid.
Then
there's
a
p2p
block
confirmation
messages,
that's
a
new
message
type
that
now
will
reside
on
the
p2p
layer
where
block
producers
will
be
able
to
emit
these
essentially
confirmations
when
they
receive
a
blood
from
the
current
blood
producer,
they
will
essentially
say
yes,
I
vote
for
that
block.
H
They
will
sign
it
and
they
will
broadcast
that
to
the
network.
So,
as
other
nodes
are
receiving
these
confirmation
messages,
they
can
now
verify
that
other
block
producers
are
also
also
in
agreement
with
the
state
of
I
give
it
luck,
then
fork
ending
and
rejection
about
block
as
per
new
consensus.
Again,
consensus
is
probably
not
the
right
term,
but
as
as
per
bft
rules.
So
essentially
like
the
that's
part
of
the.
How
how
blocks
are
added
to
the
4db?
H
So
when
there's
a
when
there's
a
change
in
in
the
stakes
or
in
the
voting
that
triggers
a
change
to
the
top
21
block
producers,
there's
essentially
like
a
first
first
round,
the
schedule
goes
into
a
proposed
there's
a
proposed
schedule
that
is
proposed
and
now
block
producers
essentially
add
a
block
on
top
of
that.
That
block
that
proposes
the
schedule.
If
you
get
two-thirds
plus
one,
the
schedule
now
becomes
pending
and
there's
another
round.
H
That
goes
and
confirms
that,
and
then
it
becomes
the
active
schedule
now
with
this
fast
finality.
This
whole
process
will
take
potentially
like
just
just
like
a
you
know,
a
few
seconds.
So
if,
if,
if
we're
achieving,
if
we
achieve
fast
finality
between-
let's
say
one
and
six
seconds,
as
I
was
saying,
we
would
essentially
it
would
basically
take
about,
like
maybe
like
10
to
18
seconds
or
something
to
get
a
change
in
block
producers.
H
So
we
have
to
to
do
quite
a
bit
of
testing
around
that
now
same
thing
for
the
protocol
feature
activation.
This
is
this:
is
they
might
they
might
end
up
being
deployed
at
the
same
time,
although
it's
not
required
you
could,
you
could
potentially
have
one
update
that
would
activate
the
the
aggregate
signatures
another
one
that
would
activate
the
fast
finality
later
so,
but
it's
there's
also
like
an
item.
There
then
there's
a
light.
Client
support.
H
B
B
H
The
big
issue
that
they
had
first
of
all,
they
were
not
using
any
sort
of
aggregate
signatures
and
they
were
rebroadcasting
essentially
like
the
the
full
blocks,
or
at
least
the
full
block
headers
from
memory.
So
it
was
definitely
a
lot
more
like
there
was
a
lot
more.
I
guess.
Like
network
chatter
yeah,
there
was
a
lot
of
overhead.
J
H
J
H
K
K
H
K
H
Exactly
it
was
kind
of
a
hack
to
be
honest
like
and
say
same
for
their
ipc,
like
it
also
was
kind
of.
You
know
like
a
a
very
lazy
way
to
do
it
and
that
had
like
a
lot
of
overhead
and
everything
cryptography
was
good.
They
they,
like
that
yeah
the
cryptographic
proofs
were
good,
but
it's
just
like
it
was
you
needed
to
have
like
these
validators
that
were
essentially
like
synchronizing
the
chains,
all
the
time
and
like
they
were.
H
H
H
So
it's
not
it's
not
like
a
test
net
where
you
go
and
test
your
adapts
and
things
like
that,
it's
more!
It's
more
like
like
a
test
net
where
you
test
that
new,
that
new
bft
system
and
that
we
use
also
to
to
perform
like
performance
analysis,
making
sure
that
we
respect
the
the
performance
criteria
as
outlined.
Can.
F
K
B
K
K
H
I
mean
again,
I
all
of
this
comes
from
discussions
that
I
had
with
eric,
but
he's
really
the
only
one
that
kind
of
had
any
feedback
on
that.
So,
of
course,
as
we
kind
of
progress
through
that
through
the
process,
I'd
like
to
hear
more
from
the
wax
and
telos
guys
as
well,
I
mean
waxed-
I
guess
like
we
can.
H
I
kind
of
assume
that
stan
was
speaking
like
for
for
wax
quite
like
this
was
probably
representing
what's
interests
when
he
was
talking,
but
especially
from
from
telos,
because
most
of
these
scalability
calls.
I
don't
think
you
had
anyone
present
so
like
there's
I'd
like
to
kind
of
get
your
your
thoughts
as
well
douglas
and
jesse.
H
And
happy
to
have
another
separate
call
with
you
guys
to
kind
of
give
you
a
bit
the
tldr
of
what
was
discussed.
Of
course
we
have
the
recording
of
all
these
calls.
I
think
there's
at
least
like
four
or
five
that
that
contain
information
about
faster
finality
that
you
might
want
to
review,
but
I'm
available
as
well.
Just
pick
me
if
you
need
a
one-on-one
or
something
well.
K
H
So
I
think,
there's
a
big
opportunity
in
in
providing
some,
I
guess,
like
writing,
medium
articles
and
sharing,
why
it's
important
and
how
that's
gonna
work
and
things
of
the
sort.
So
I
mean,
of
course,
I
defer
to
to
I'm
a
developer
so
I'll
different
people
that
have
expertise
in
communications
and
in
pr,
but
I
think
there's
a
big
opportunity
there.
So
definitely
gonna
be
assisting
you
guys.
On
that
front,
we
also
have
an
item
for
an
external
audit
of
the
of
the
the
code.
H
I
had
a
discussion
with
eve
a
couple
weeks
ago:
I'm
not
I'm
not,
I'm
not
sure
if
an
external
audit
is
sufficient.
I
think
we'll
probably
want
to
have
an
internal
audit
as
well,
because
at
the
end
of
the
day
you
know
like
you
can,
can
give
that
to
sentinel
or
slomists
or
other
guys
like
that.
But
I
think
I
would
I
would
prefer
I
would
prefer
an
audit
by
the
enf,
for
example,
than
another
by
these
guys.
H
So,
but
but
up
to
you
guys
how
you
want
to
go
about
it.
I
think
it's
going
to
be
a
fairly
fairly
big
chunk
because
it's
yeah
it's
it's
quite
a
complex
change
and
it
has
a
lot
of
subtleties
and
a
lot
of
a
lot
of
considerations.
So
it
has
to
be
reviewed
and
audited
by
people
that
actually
really
know
what
they're
talking
about.
H
So
so
that's
a
that's
a
bit
of
a
challenge
here,
but
I
think
I
think
we'll
we'll
be
able
to
to
figure
it
out
and
that's
of
course
that's
an
external
budget.
So
I
mean
this
is
not
going
to
be
paid
to
origin.
So
it's
going
to
be
paid
to
another
organization
and
I'm
sure,
I'm
sure,
even
probably
douglas
and
lucas
as
well.
H
You
probably
know
some
of
these
auditing
firms
better
than
I
do
so
very
open
suggestions
there
and
then
additional
support
to
the
coalition
member,
as
they
will
deploy
this
to
either
their
test
nets
or
their
and
order
mainnet.
So,
of
course
we
won't.
We
will
be
providing
this
as
a
add-on
service,
as
you
guys
go
through
this,
so
that's
for
that's
pretty
much
it
for
the
cost
estimates,
if
you,
if
anyone
has
questions
happy
to
to
answer
another.
K
Question
about
what
you
you
just
covered
about
the
set
about
the
audit
yeah
does
so
when,
on
the
the
an
on
audit
invariably
turns
up
issues
that
need
to
be
addressed.
That
weren't
already
expected.
So
are
those
issues
are
so
I
don't
see
a
line
item
timeline
on
them
for
dealing
with
those
are
those
built
into
the
into
the
project
already,
and
is
that
why
it
doesn't.
H
Yeah
like
in
the
milestones
here
essentially
like
that's
one
of
the
items
here,
successful
audit
so
like
if
there
is
basically
like
completion
of
that
audit,
with
no
major,
no
critical
or
major
vulnerability
found
so
essentially
like.
If,
if,
if
there's,
if
there's
any
issues
there
like
that
need
to
be
addressed,
we'll
they
will
eat
the
loss
and
we'll
fix
them
with
our
on
our
own,
of
course,
okay
and
then
the
other.
All
of
this.
All
of
this
is
indicative.
H
You
know
like
the
number
of
hours
like
for
for
me,
like
I
just
just
put
that
as
kind
of
an
indication,
but
it's
not
it's
not
like.
I'm,
I'm
very
happy
to
just
put
this.
As
a
kind
of
you
know,
lump
sum.
This
is
the
amount
if
it
takes
twice
as
long
it's
it's
it's
like
we're
going
to
eat
that
no
problem.
I.
K
H
G
K
H
K
H
So
essentially
like
this
discovers
we're
targeting
eight
months
between
project
start
and
the
deployment
to
jungle.
So
that's
gonna,
like
the
the
I
guess,
like
the
main
deliverable
for
us,
is
the
deployment
to
jungle,
but
we
also
extend
this
there's
another
12
months
following
this,
which
is
essentially
consulting
and
support,
well
support
for
the
chains
to
deploy
this
to
their
respective
main
nets
and
then
an
extra
six
months
after
that
for
any
any
bugs
that
are
identified,
that
we
will
essentially
fix
as
part
of
that.
K
H
This
is
typically,
I
mean.
There's,
I
guess,
there's
that's
something
the
coalition
probably
will
address
at
some
point
right
now.
Documentation
is
kind
of
I'm,
I'm
personally
still
using
the
developer
portal
of
block
one,
the
yes,
I
o
thing,
but
sooner
or
later
we're
gonna
have
to.
I
guess,
like
have
a
have
a
the
esio
plus
documentation
portal,
that's
under
control
of
the
of
the
the
coalition,
and
I
mean
in
terms
of
the
level
of
the
documentation.
H
H
Yeah,
and
typically
this
is
you
know
like
this-
is
not
something
necessarily
that
like
it's,
not
it's
not
like.
Writing
a
smart
contract
where
you
have
to
explain
like
all
these
functions
and
how
they
can
be
used.
This
is
very
core
to
to
the
protocol.
So
documentation
is
more
about.
You
know,
kind
of
explaining
how
faster
finality
works
and
explaining
how
it
impacts
various.
You
know
like
performance
parameters
of
the
system
and
so
on
and
so
forth.
H
H
Oh,
it's
all
in-house.
The
the
the
caveat
to
that
is
of
course,
there's
like
we're.
Gonna
have
a,
I
guess,
like
a
liaison
with
the
with
the
coalition,
so
like
there's,
I'm
I'm
planning,
I'm
planning
to
have
like
something
like
weekly
or
like
bi-weekly
calls,
with,
with
representatives
of
the
of
the
the
all
the
chains
of
the
coalition
to
discuss
progress.
H
So,
of
course,
there's
I
mean
a
coalition
has
to
to
think
how
much
they
want
to
to
to
spend
on
that
like
if
how
many
people
you
want
to
assign
to
these
tasks.
If
any,
because
I
mean
I
I'm
not
sure
everyone
will
necessarily
like
do
that
at
that
frequency.
But
it's
it's
it's
up
to
you
guys
so
essentially,
but
we
would
yeah,
like
all
of
this
essentially
like
manage
internally
by
us.
B
H
So
that's
that's
the
theme
that
I'm
putting
to
work
on
that,
but
I'm
happy
to
provide
like
their
resumes
and
no
problem
and
some
of
them.
You
know,
there's
of
course,
like
some
of
them
that
have
been
have
been
quite
quite
public
part
of
the
yes
titan
team.
So
thank
you
so
so
yeah
with
regards
which,
with
regards
to
the
milestones,
I'm
sorry
was
it
was
it
jeff,
I'm
not
sure.
H
H
All
of
these
phases
happen
in
sequence,
but
element
within
one
phase
may
happen
in
parallel.
So,
for
example,
like
mathematical
proof
and
latency
we'll
be
working
on
that
at
the
same
time
that
we're
working
on
the
aggregate
aggregate
signatures.
So
so
it's
not
it's
not
like
we're
waiting
for
the
proofs
to
be
done
to
finish
the
signatures
and
so
on
and
so
forth.
H
This
is
the
one
essentially
where
once
that's
out
and
that's
working
like
people
can
can
probably
recognize
that
this
is
a
functional
solution
and
that
we're
at
least
not
too
far
from
a
from
from
something
that
would
that
would
that
would
work
across
the
board
so
and
that's
a
cumulative
payout
of
60
percent
give
or
take
so
there's.
That's,
that's
kind
of
how
also
like
you
guys,
can
mitigate
your
risks.
H
All
of
these
milestones
also,
they
all
typically
are
kind
of
self-contained,
so
meaning
that
we
deliver
this
one
there's
value
in
this.
Even
if,
for
some
reason
we
didn't
go
through
with
the
rest,
I
mean
not
that
we're
intending
to
to
stop
at
any
point
in
the
process,
but
basically,
if,
if
for
some
reason
like
whatever,
like
our
key
engineers,
get
hit
by
a
bus
or
a
coalition
runs
out
of
funding,
or
whatever
I
mean
each
of
these
milestones
has
a
deliverable
that
is
by
itself
useful
and
that
can
be.
H
You
know
like
work
kind
of
kind
of
serve
as
a
building
blocks
by
building
up
to
the
next
one
and
that
provides
value
by
itself.
So
that's
also
one
way
that
the
coalition
controls
their
risk
when
they,
when
they
approve
the
milestone
here,
there's
a
bit
of
code,
the
piece
of
code
that
is
useful
regardless.
H
L
I
was
wondering
on
the
previous
page
there's
a
couple
of
questions.
I
just
want
to
make
sure
understanding
what
you're
presenting
so,
for
instance,
jungle
deployment
and,
first
of
all,
I
think
this
is
everything's
great.
I,
like
the
thoroughness,
and
I
think
you
guys
are
more
than
capable
of
accomplishing
this.
L
I
like
everything,
I've
heard
I
just
you,
know
it's
a
big
bite
of
money
of
the
coalition's
money
and
I'm
trying
to
understand
where
we're
putting
it.
This
is
120
hours
at
350
an
hour.
So
that's
basically
saying
three
weeks
four
weeks
so
four
weeks,
three
yeah,
like
three
weeks
I'd,
say
three
weeks
yeah.
So
it's
like
suggesting
somebody
who
gets
paid
350
an
hour
because
gonna
spend
three
weeks
eight
hours
a
day.
So
so
I'm
just
trying
to.
H
See
where
we
can
tell
clarify
the
number
of
hours
and
the
rate
is
for
getting
it
done,
it
doesn't
necessarily
mean
that
there's
only
one
guy
working
on
it.
So
if,
if,
for
example
like
any
of
these
points
like
there
might
be
like
two
or
three
person
working
on
it
to
get
it
done,
so
it
depends
like
this
is
who
this
is
what
they
come
with.
H
Our
company
is
charging,
but
it's
not
necessarily
like,
doesn't
necessarily
mean
like
one
hour,
one
man
hour,
it's
one
company
hour,
for
example,
and
then
and
then
how
many
people
we
assign
to
it
and
what
what
gets
done
there.
Basically,
that's
and
of
course,
of
course,
like
there's
there's,
you
know
like
deployment
to
jungle
that
includes
deployment,
but
there's
provision
also
for
any
sort
of
issues
that
we
may
run
into.
H
If
there's
there's
like,
if
there's
a
you
know
like
a,
I
guess,
like
discussions
to
be
had
with
the
current
vps
troubleshooting
of
anything
that
may
that
may
happen,
and-
and
I
guess,
like
the
the
various
tasks
that
relate
to
also
analyzing
the
the
the
like
the
data
after
this
has
been
deployed.
For
example,
like
verifying
that
these
blocks
are
indeed
being
generated
being
validated
within
that
acceptable,
fast
finality
time
window,
verifying
that
we
don't
have
any
unexpected
micro,
forks
and
so
on
and
so
forth.
H
K
I
guess
there's
so
to
to
echo
sort
of
what
jesse's
saying
you
know
in
response
right.
It
totally
makes
sense
that
it's
not
one
person
spending.
You
know
three
weeks,
it
might
be
three
people
spending
one.
You
know
work
140
hour
a
week,
each
even
even
so,
on
the
surface
it
seems
it
seems
like
you
know
it
could
be
done.
It
seems
like
a
lot
of
hours
for,
for
that
and.
L
On
that
one
in
particular,
I
just
want
to
be
sure
we
weren't.
I
mean
I
want
to
understand
that
I'm
just
speculating
I'm
trying
to
see
how
we
get
to
such.
In
some
cases
it
seems
like
big
numbers.
Some
of
the
stuff
up
above
I
think,
is
totally
reasonable
to
build.
You
know
in
the
engineering
skills
it
takes
and
time
it
takes
to
do
those
things
above.
I
think
you
know
I'm
just
kind
of
questioning
like
that
one,
but
we're
not
paying
the
vps
there
for
their
time.
L
H
H
Mean
I
mean
yeah
they're
on
the
private
network,
but
there's
provision
for
that
as
well.
Obviously,
I
hear
what
you're
saying
like
to
deploy
to
deploy
like
a
new
new
new
version
of
this
doesn't
take
three
weeks
for
sure,
but
this
this
has
the
buffer
in
there
to
essentially
like
absorb
any
any
issues
that
we
may
have
to.
Also
I
you
know
like
any
discussions
that
we
may
need
to
have
with
the
bps
explaining
them
a
few
things
reviewing
their
their
meshing
and
like
analyzing.
H
The
time
it
takes
for
these
plugs
to
to
be
propagated.
Essentially,
like
jungle
is
going
to
be
our.
I
guess,
like
our
first
real
test,
because
there's
something
happening
on
jungle
on
our
private
test
net
is
going
to
be
a
private
test
net,
where
it's
just
meant
for,
for
the
the
I
guess,
like
the
deployment
of
the
solution,
we
only
have
like
50
hours
there,
but
on
jungle,
there's
there's
things
happening.
There's
already,
like
you
know,
like
a
it's,
a
it's
a
chain,
that's
already
live.
H
H
H
Yeah,
the
basically
like
we,
we
went
with
a
hardware
hardware
that
is
similar
to
what
block
producers
are
running
right
now
on
on
on
the
main
chains
like
ux,
delos,
wax
and
es
mainnet,
and
then
with
the
monthly
costs
of
vms
that
are
able
to
support
that
kind
of
that
kind
of
hardware
times.
21
block
producers
plus
associated
api
and
p2p
nodes
for
about
one
year.
So
that's
give
give
or
take
this
is
this
is
the
the
figure
that
we
we
arrived
at
because.
H
Right
and
that's
that's,
that's
that's
roughly
what
we
what
we
came
up
with
I
I
asked
our
guys
to
essentially
extrapolate
these
numbers
from
our
current
costs.
You
know
of
deploying
similar
hardware
and
that
we
cannot
we
kind
of
have
for
for
this.
We
kind
of
have
to
have
something
that
is
quite
representative
of
a,
I
guess,
like
a
of
an
esio
network,
because
this
is
this
is
like
you
want
to
test
this
against.
You
know
like
real
conditions,
not
not
not
like
just
two
nodes
talking
to
each
other.
L
H
Yeah,
it's
yeah
pretty
much
and
it's
there's
there's
a
bit
of
wiggle
room
there.
Of
course,
if
we
wanted
to
to,
you
know
like
test
with
a
few
more
nodes
and
just
like
just
like
some
of
them,
some
of
them
we
might
want
to
to
take
like
to
take
offline
after
a
certain
period
of
time
so
like
we
there
there
might
be,
it
might
be,
like
some
cost
savings
there.
H
L
You
mentioned
vms,
I'm
just
curious.
You
don't
plan
on
commit
all
transparency
for
rbp.
I
run
them
from
two
different
providers
bare
metal.
You
know
at
least
month
month
and
I
know
of
a
handful.
I've
switched
three
times
in
three
years.
You
know
I
know
a
handful.
You
can
get
bare
metal
servers
for
100
150
a
month
that
are.
H
L
K
H
Actually,
I
would
actually
probably
also
also
like
offer
to
the
coalition
members
first
if
they
want
to
to
take
that
responsibility.
For
example,
bps
that
already
have
racks
and
various
data
centers
that
are,
that
have
a
bit
of
excess
capacity.
I
I
prefer
like
paying
you
guys
to
run
these
these
notes,
and
rather
than
just
like
rent
new
ones
that
are,
you
know
directly
from.
K
The
providers
to
me,
I
don't
have
a
problem
with
that,
like
300
per
bp
month,
given
that
there's
most
people
are
going
to
be
running,
you
know
yeah,
you
know
it
takes
a
little
time
and
what
and
and
that's
that's
you
got
to
pick
a
number
right
yeah
I
have,
but
to
jesse's
point
so
there
are.
There
have
been
a
few
times
in
this.
When
I
look
at
it
and
I
go
okay,
you
know
what
350
dollars
per
hour.
I
don't
have,
and
this
is
not
a
negotiation.
K
It's
just
clarification,
so
I
don't
have
a
problem
with
that.
If
we're
paying
a
phd
20-year
senior
person,
but
I
I
feel
like
some
of
the,
I
wonder
my
question
part
one
is
some
of
those
are
going
to
be.
Some
of
those
hours
are
going
to
be
people
doing
documentation
and
doing
and
doing
you
know,
project
management
and
whatnot,
at
which
I
think
I
would
be
going
at
much
lower
than
350,
including
any
expected
overhead.
You
know
for
for
your
company,
how?
H
So,
as
I
was
saying
that
to
us,
it's
not
it's
not
like
a
it's,
not
the
cost
per
per
man
hour,
it's
a
customer
company
hour.
So
it's
a
it's
an
indication
of
time
more
than
anything
else.
Now,
of
course,
of
course
like
when
we
say
project
management,
there's
gonna
be
a
pm,
but
there's
gonna
be
also
like
assistance
like
providing
supporting
coordination
and
scheduling,
calls
and
taking
minutes
and
doing
that
kind
of
stuff.
H
Most
of
these
items
are,
I'm
actually
estimating
that
it's
gonna
be
more
like
two
or
three
people
working
on
probably
more
two
than
three,
but
still
it's
gonna
be
at
least
two
people,
and
it's
it's.
It's
also
like
we're,
not
we're,
not
consultants,
that's
quite
quite
important
to
to
express
as
well
we're
not
in
the
consulting
business.
I've
done
that
most
of
my
life
I
mean
before
I
got
into
crypto.
I
was
actually
doing
consulting,
but
this
is
not.
H
This
is
not
what
we're
doing
here
like
the
the
we.
We
raised
our
hand
for
faster
finality
because
it
is
quite
important
for
our
game
plan
because
of
ibc
and
and
whatnot,
and
we
were,
I
mean
we
would
have
been
happy
to
to
just
to
to
leave
it
someone
else
if
someone
else
had
a
a
plan
that
we
would
be
able
to
rally
behind,
but
unfortunately
that
was
not
the
case.
H
The
only
other
proposal
that
was
discussed
was
stan's
proposal,
but
stan
proposal
didn't
include
the
aggregate
signatures
and
the
cryptographic
proof
that
is
essentially
core
to
our
need,
and
after
these
scalability
plus
call
it
was
became
quite
obvious
that
this
was
really
important
for
everyone.
So
so
we
ended
up
like
just
just
I
guess
like.
Yes,
it
was
a
vacuum
we
stepped
up
and
for
us
we
we
feel
that
this
is.
This
is
quite
a
well
first
of
all,
it's
a
difficult
piece
of
software.
H
It's
not
not
a
walk
in
the
park
by
any
stretch,
and
it
also
especially
combined
with
with
ibc
it.
It
has
it's
very
foundational
to
the
the
new
esio.
Let's
put
it
this
way.
Moving
forward,
I
mean
there's
already
like
we're
already
competing
with,
say,
cosmos,
that
more
or
less
has
this
built
in
and
we
need
to.
We
need
to
be
able
to
to
be
at
the
at
their
level
and
and
beyond.
H
K
D
K
H
I
H
L
Ask
one
question:
let
me
put
my
okay
before
before
we
let
gnome
go
and
you
and
maybe
eve
if
I'm,
if
I'm
starting
to
negotiate.
You
just
cut
me
off,
but
is
there
anything
in
here
now?
First
of
all,
I
appreciate
that
you
stepped
forward,
and
I
have
a
cursory
understanding
of
of
stan's
proposal
in
comparison
to
what
you've
presented
here,
and
I
feel
we
would
be
doing
the
software
an
injustice
to
not
go
full.
L
You
know
comprehensive
implementation,
as
you
have
here,
the
you
know,
aggregate
signatures,
the
proofs,
just
everything
that
you
have
here
is
the
right
way
to
do
things.
So
I
I
don't
see
that
cutting
significant
corners
is
something
we
would
want
to
do,
but
I
would
just
ask
you
kind
of
in
the
context
of
what
douglas
said
as
a
member
of
the
coalition
trying
to
be
prudent
with
the
money
that
we
have
so
far
that
we've
committed
and
knowing
the
market
conditions
is
there
anywhere
in
here.
L
L
I
don't
see
anywhere
here,
like
you
know,
I
guess,
to
compare
to
aaron's
wallet
proposal.
That's
like
you
could
do
this
this
or
this
there's
not
a
menu
right.
It's
like
it's
all
of
it
or
or
none
of
it
in
in
this
presentation.
So
is
there
anywhere
that
you
see
if
we
needed
to
you
know,
is
there
anything
you
can
see
that
could
be
cut
back.
H
The
unfortunately
like,
like
you,
said
it's
not
it's
not
really
a
menu
for
that
one,
because
it's
gonna,
it's
gonna
like
a
binary,
pretty
much
thing.
The
only
thing
I
can
think
of
is
like
the
proofs
here.
I
I
do
think
they
are
very
important,
but
if
we,
if
we
want
to
skip
that
part,
that
could
be
done
other
than
that
I
mean
like
the
rest
would
be
like
dangerous.
Like
skipping
the
audit
like
dsla
and
things
like
that,
but
it's
it's
I
I
don't
recommend
doing
that.
H
So
my
my
short
answer
would
be
no
there's
not
much
that
can
be
can
be
trimmed
down.
Okay.
However,
this
being
said,
we're
quite
open
in
with
regards
to
structuring
this,
as
you
know,
like
stretching
the
payments
having
some
sort
of
downside
protection
for
you
guys
of
the
tokens,
token
tanks,
or
things
like
that,
like
we're
quite
flexible
in
the
way
that
we
can
structure
the
the
the
terms
of
the
payments
and
and
whatnot.
H
So
because
I
mean
obviously
there's
there's
there's
a
lot
of
considerations
between
you
know
like
at
which
price
do
you
convert
these
tokens
to
usdt
or
are
you?
Are
we
even
converting
these
tokens
to
usdt
first,
and
how
do
we
structure
this
in
light
of
the
broader
coalition
finances
and
so
on
and
so
forth,
so
we're
quite
quite
flexible
on
the
payment
schedule
and
on
the
the
modalities
we're
willing
to
take
a
bit
of
risk
with
the
price
of
the
tokens,
for
example?
H
K
I
I
think
that,
if
there's
any
other
kind
of
financing
would
be
a
you
know
could
be
a
completely
different
conversation.
I
think
that
the
the
way
we've
decided
to
finance
things
is
actually
fine
and
and
but,
but
that
that's
good
you're
open
to
that.
I'd
like
to
present
just
for
the
sake
of
argument
and
mind
your
own
understanding,
two
different,
totally
valid
sort
of
approaches
to
this
and
hear
where
you
know
which
one
you
feel
you're
closer
to
and
again
this
is
not
a
judge.
This,
it's
totally
valid,
totally
valid
viewpoint.
K
K
K
The
other
viewpoint
is,
is
you
know
these
are
big
round
numbers
it's
hard
to
it's
hard
to
figure
out
the
it's
hard
to
figure
out
every
last,
every
last
thing
and
some
padding's
required,
but
it
feels
like,
as
somebody
who's
made
has
been
a
contractor.
It
feels
padded
in
in
hours
and
and
and
sometimes
when
you
look
at
something
like
say:
well,
it's
350
hour
dollars
per
company
hour,
but
then
you
also
talk
about
well.
That
could
be
three
people
working
on
it.
It
doesn't.
K
You
know
you
know
padding
there
for
potential
losses,
but
also
maybe
or
potential
contingencies,
but
maybe
too
much
yes,
those
those.
I
think
I've
tried
to
really
capture
something
totally
fair
to
you,
but
also
somebody
totally
fair
to
who
is
like
trying
to
look
at
the
the
costs
of
these.
How,
where
do?
Where
does
the
reality
fit?
For
you.
H
So
I
mean
there's
obviously
a
lot
of
unknowns
in
this,
and
I
mean
most
of
them
have
to
do
with
the
the
state
of
the
code
base
and
the
in
terms
of
the
general
game
plan.
I
think
I
think
that's
quite
that's
quite
clear
from
our
standpoint.
What
needs
to
be
done,
but
there's
there's,
obviously
quite
a
bit
of
unknowns
and
fair,
like
completely
being
completely
transparent.
H
H
We
have
the
general
game
plan
figured
out,
but
it's
more
about
like
how
do
we
integrate
it
with
the
existing
code
base?
If
it
was
to
write
this
from
scratch,
it
would
probably
be
actually
easier
than
modify
which
we
already
got,
because,
as
you
guys,
I
don't
know,
I
don't
know
if
you
guys
look
at
much
of
the
at
the
co
base,
but
there's
a
cool
base
that
has
quite
a
bit
of
technical
depth
and
there's
there's
there's
been
there's
been
some
some
some
work
behind
the
whole
thing.
D
H
The
things
that
are
like,
if
you
were
to
start
from
scratch,
would
be
quite
quite
straightforward.
Here
we
have
to
be
very
careful
not
to
not
to
break
other
features,
we're
already
kind
of
like
initially,
as
we
started
discussing
this
game
plan
with
eric
and
matt
there's
already
a
number
of
features
that
have
to
be
deprecated
for
this
to
work.
H
For
example,
like
the
the
multiple
the
wt
mcig
feature
that
allows
block
producers
to
register
with
potentially
more
than
one
key
have
their
own
multi-sig
set
up
for
signing
blocks,
so
that
needs
to
be
deprecated.
Another
thing
that
needs
to
be
deprecated
is
the
ability
for
block
producers
to
use
a
a
public
key
that
is
on
the
r1
curve.
So
that's
that's!
That's
no
longer
going
to
be
supported.
There's
there's
things
like
that.
H
That
needs
to
be
carefully
determined
and
and
verified
before
we
can
proceed
so
there's
because
of
that
technical
debt
and
because
of
where,
like
we're,
essentially
like
changing
the
wheels
of
a
car,
that's
driving,
there's
significant
uncertainty
as
well,
and
I
mean
definitely
we're
very
confident
that
we
can.
We
can
do
the
work,
but
that
bad
thing
that
you're
referring
to
is
is
present.
Yes,
there,
some
of
these
hours
are
are
definitely
padded.
H
K
K
That
we
will
not,
we
will
not
come
to
a
point
we
would
not
be
coming
to
if
we,
if,
if
we
went
forward
to
this,
we're
not
factoring
in
the
the
idea
that
hey
guys,
we
just
didn't
know
how
many
hours
this
would
be.
So
therefore,
we
have
to
you
know,
even
though
the
scope
itself
hasn't
changed
the
hours
do,
because
we
really
came
into
this
big
problem
you're
trying
to
cover.
However
many
you
know,
there'll
be
three
or
four
of
those,
so
we're
not
gonna
we're
not
gonna
hear
back.
K
H
For
that
is
that
right
exactly
exactly,
and
I
mean-
and
I
mean
we
also
look
at
it
from
the
like
the
the
first
standpoint
that
you
were
describing
that,
even
though
the
amount
may
seem
high
in
terms
of
in
relationship
with
the
hours
and
whatnot
in
terms
of
value
that
it
provides
it's.
I
think
I
think
quite
quite
reasonable,
because
this
is
the
kind
of
stuff
that
I
mean
has
the
potential,
in
my
opinion,
of
proposing
these
tokens
to
a
much
higher
market
cap
that
would
exceed
this.
Hopefully,
hopefully,.
K
No
problem,
if
you
came
in
and
said
you
know
what
guys
it's
market
price
we're
the
only
ones
who
can
do
it,
you
got
one
thing
and,
and,
and
you
know
pay
us
or
not,
you
know
I
would.
I
actually
think
that
would
be
completely
valid.
I
just
wanted
to
see
where
you
are
and-
and
actually
your
answer
is-
has
clarified
some
things
for
me.
So
no.
H
G
Sure
I've
got
one.
So
it's
like
the
line
item,
for
you
mentioned
multiple
times.
Consulting
with
the
enf,
which
I
agree,
working
with
the
engineering
team
is
going
to
be
very
important
whenever
you
have
the
line
item,
just
for
example,
at
the
bottom
of
the
yellow
enough
consulting
code
review
74
hours
is
that
74
hours
collectively
between
paying
for
the
nf
engineers
time
and
your
own
time,
or
is
that
just
for
one
of
these.
H
H
Even
I
were
discussing
essentially
like
getting
eric
like
earmarking
eric
for
one
day
a
week
for
essentially
like
six
months,
give
or
take,
and
and
basically
like,
have
him
participate
in
this,
mostly
not
not
doing
the
grunt
work,
but
mostly
doing
you
know,
like
a
general,
like
strategy
overview
code
reviews,
this
kind
of
stuff,
like
the
reviewing
our
our
proposed
approach,
giving
us
some
pointer.
Where
should
we
focus
our
efforts
in
the
code
base?
H
Where
should
various
things
happen
and
whatnot
kind
of
helping
us
to
navigate
these?
These,
like,
like
very
specific
details
about
subtle,
behaviors
about
the
code
base
and
whatnot
and,
of
course,
reviewing
the
the
code
that
we
produce,
making
sure
that
this
this
you
know
like
matches
their
the
the
current
standards
and
procedures
of
like
processes
of
the
of
the
development
team.
So
part
of
that
part
like
this
is
this
is
like
strictly
going
to
the
enf,
essentially.
B
And
just
because
we're
coming
on
the
hour-
and
I
know
that
lucas
has
to
leave
as
well,
the
ensuing
discussion
will
last
quite
it's
going
to
be
quite
lengthy,
plus
I
added
an
item
on
the
agenda
to
discuss
treasury
as
a
whole
for
the
coalition,
which
ties
in
very
much
to
this
item.
I
would
suggest
this
if
others
are
comfortable,
that
we
have
an
ad
hoc
meeting,
ideally
before
next
thursday.
B
I
don't
think
there's
a
need
to
wait
till
next
thursday
to
continue
this
discussion.
If
some
folks
would
want
to
join
or
want
to
stay
right
now,
past
four
o'clock,
we
could
have
the
discussion
internally
without
the
ux
team.
Here
I
do
have
suggestions
on
on
some
of
the
finances
and
such
and
so
I'd
like
to
present
to
the
other
coalition
members.
B
You
know
and
you'll
see
why,
when
you
have
those
discussions
but
just
kind
of
said
that
we're
coming
on
the
hour,
I
I
know
that
lucas
you
have
to
leave,
and
so
whether
we
want
to
just
postpone
and
have
everything
together
on
an
ad
hoc
meeting,
or
we
want
to
continue
this
without
ux
and
lucas.
Here
would
really
just
be
telos
and.
B
C
We
didn't
have
a
much
larger
discussion.
I
I
do
think
we
need
to
have
an
ad
hoc
discussion
regarding
the
the
state
of
the
market
financing
and
the
overall
direction,
because
you
know
we
have
been
operating
from
the
you
know
when
we
started
this,
the
the
getting
was
good.
Well,
you
know
it's
no
longer
good.
The
the
market
is
it's
a
bloodbath
and
I
think
each
team
is
taking
a
very
hard
look
at
their
finances
and
survival.
C
C
H
Yeah,
like
it's
okay
for
lukas,
has
to
go,
because
I
already
had
that
discussion
with
him
in
private,
but
another
thing
that
we
as
a
market
was
kind
of
taking
taking
a
dump.
Another
thing
that
we
discussed,
I
discussed
individually
with
lucas
with
eve
and
with
jesse
separately,
is
the
potential
idea
of
switching
priorities
between
faster
finality
and
ibc
reason.
H
H
As
part
of
these
discussions
in
this
scalability
plus
group,
at
some
point,
we
kind
of
reach
consensus
that
faster
finality
is
really
a
precursor
to
a
better
ibc
and
that's
its
main
reason
to
be
there's
there's
little,
I
guess
benefit
in
getting
faster
finality
if
ibc
does
not
follow
suite.
I
follow
suit,
but
I
mean
there's
quite
a
bit
of
benefit
in
having
ibc
first,
even
though
it's
not
as
good
as
it
could
be
with
faster
finality.
It
still
is
pretty
good
and
it's
it
works
today.
H
K
K
B
B
I
believe
it's
next
tuesday,
so
yeah,
ideally,
instead
of
waiting
until
next
tuesday,
we
can
have
the
this
discussion
with
the
finances
for
faster
finality
without
ux
during
the
scalability
so
long
and
then
we're
gonna
have
the
overall
treasury
discussion
either
within
there
and
ux
comes
in
or
then
we
have
it
next
thursday
that
we
accelerate
this
process.
I
do
have
a
proposal
that
I.
D
B
So
we
could
have
the
this
discussion
of
what
I
would
propose
as
a
counter
offer
to
ux
team,
but
I
want
to
talk
to
telos
and
wax
first,
so
that
it's
not
three
different
negotiations.
It's
the
rest
of
the
people
negotiating
with
ux,
that's
one,
which
is
what
we
would
do
if
it
was
somebody
that
isn't
ux
right.
B
H
My
pleasure
and
yeah
just
don't
hesitate
if
you
have
any
additional
questions
or
if
I
can
clarify
anything
else.
Just
just
hit
me
up
and
also
I
want
to
reiterate,
especially
for
those
guys
if
you
guys
want
to
have
a
one-on-one
on
the
kind
of
a
tl.
Dr
summary
of
these
scalability
plus
calls
I'm
happy
to
to
do
that
with
you
guys
as
well.
So.