►
From YouTube: KZG-Ceremony Breakout Call #3
Description
A
Welcome
everybody
to
the
third
kcg
ceremony
call.
This
is
a
call
where
we
are
discussing
the
kcg
ceremony
for
preparing
the
wafer
tank,
sharp
protodank,
sharding
and
future
scaling
of
ethereum,
so
hopefully
you're
in
the
right
place
if
you're
attending
this
call.
A
This
is
a
bi-weekly
call,
meaning
every
two
weeks
for
updates
in
general,
progress
from
the
people
who
are
working
on
it.
Specifically,
I've
been
working
with
carl
on
sort
of
organizing
the
approach
getting
people
to
work
on
things
ahead
of
time.
We
want
to
get
this
done
by
the
end
of
the
year,
kicked
off
before
the
end
of
the
year,
and
that
includes
a
bunch
of
things.
So
we're
gonna
go
through
what
those
specific
things
are.
A
A
So
the
first
thing,
that's,
I
think
new
from
this
week
is
the
timeline
and
I'll
share
it
in
the
chat
carl.
Do
you
want
to
talk
about
that
and
we
met
with
maddie
yesterday
to
go
over
this
and
a
couple
other
things.
B
Yeah,
so
this
is
basically
what
I
was
presenting
last
week.
I
don't
have
transit
the
link
but
yeah.
Basically,
last
week
I
mentioned
some
timelines
of
roughly
where
I'd
like
things
to
happen,
and
this
is
just
sort
of
that
that
explained
out
in
in
yeah
in
in
in
visual
and
written
form
and
yeah.
Hopefully,
that's
just
for
everyone
to
sort
of
agree
on
and
or
complain
about,
slash
contribute
to
whatever,
based
on
what
you
think
is
and
isn't
reasonable
on
there.
B
The
audits
are,
of
course,
sort
of
fixed
dates
on
this.
So
that's
the
one
limitation
we
we
have
on
on
these
things,
but
yeah,
that's
that's
pretty
sure.
C
No
just
checking
my
microphone.
Oh.
A
Just
wanted
to
check
yeah
the
other
thing,
or
I
guess
next
on
the
agenda
is
website
interface,
so
we
want
to
start
getting
the
ethereum.org
team
to
allocate
some
of
their
their
time
their
resources
towards
this
as
well.
If
we're
going
to
have
them,
do
an
interface
jeff.
I
know
you've
worked
on
some
of
these
in
the
past.
Is
there
any
standard
things
that
somebody
implementing
the
website
would
need
to
know
about,
or
is
this
sort
of
you
know
you
approach
it
on
a
situational
ad
hoc
basis?
Each
project
is
different.
C
Oh
yeah,
so
so
it's
pretty
pretty
pretty
bog
standard
website
so
yeah.
I
thought
when
we
were
talking
about
ethereum.org.
We
were
talking
about
the
website
that
would
like
display
the
history
and
the
results
rather
than
the
the
website
that
actually
serves
the
interface.
So
are
we
talking
about
both.
A
Oh
in
my
in
my
mind,
it
was
the
website
serving
the
interface
where
people
participate
from,
but
I
guess
we
would
also
we
would
need
both.
Were
you
imagining
that
somebody
else
would
take
care
of
the
the
actual
contribution
interface
or
is
that
something
you
were
thinking
of
doing.
C
C
C
There's
there's
quite
a
bit
of
setup
in
service
yeah,
especially
at
the
moment.
We've
got
google
firebase
and
it's
fairly
complicated,
like
it's
easier
to
to
leave
it
where
it
is
and
just
redirect.
B
C
Oh
yeah,
yes,
the
the
dev
work,
yeah,
I've,
I'm
we're
assembling
a
team,
so
I'll
have
a
few
helpers.
D
B
Okay,
cool,
so
the
the
if,
if,
if
you
need
help
from
the
ethereum
or
team
they're
they're
more
than
happy
to
help,
this
is
a
sort
of
kind
of
project
that
they'd
be
happy
to
do.
But
they
are
like
again
it's
less
from
the
sort
of
like
devops
management
side
and
more
of
just
actually
having
having
a
code
base.
B
But
that's,
I
guess,
uniform
or
uses
the
sort
of
common
ideas
that
they've
been
going
through
and
ideally
we'll
include
some
translations
of
that
kind
of
thing
down
the
line,
but
yeah.
C
Yeah,
we
see
this
as
part
of
an
ongoing
sort
of
development
effort
for
the
for
the
pse
team
to
have
trusted
setups
to
cater
for
all
sorts
of
situations,
and
this
is
this
is
one.
You
know
one
particular
situation
that
we
can
draw
build
on
what
we've
already
got
and
we
can
build
stuff
that
we
want
to
carry
on
in
the
future
for
different
kinds
of
setups.
You
know
plonk
or
phase
two
or
whatever.
C
So
that's
where
we're
coming
from
that's.
Why
we're
putting
a
team
together.
B
Okay,
cool
all
right:
okay,
if
you're
talking
about
js
sdk,
do
you
mind
elaborating
a
little
bit
on
that.
D
Yeah
sure
sorry
saying
that
does
it
make
sense
for
basically
so
if
someone
creates
a
rust
client
and
maybe
a
client
in
c
plus
plus
they
both
convert
them
to
wasm.
And
then
there
is
a
common
javascript
sdk
that
that
connects
to
the
wasm
and
then
like
jeff's
website
could
connect
to
the
sdk.
And
then
he
knows
what
what
methods
are
available
and
maybe
the
ethereum
website
could
connect
to
the
sdk
and
they
know
what
methods
are
available.
C
That
sounds
like
a
an
api
that
sits
in
the
middle
between
the
like
the
user
interface
and
the
computation
code
was
right.
B
D
Right,
the
only
thing
that
would
probably
need
to
be
defined
somewhere
is
so
these
web
workers.
Maybe
the
sdk,
doesn't
even
need
to
worry
about
web
workers.
C
B
D
C
Yeah,
I
think
it's
it's
quite
a
good
idea
and
that
the
sdk
could
could
have
something
in
it
to
or
it
could
create
the
web
workers
for
potentially
create
web
workers
and
just
hand
it
over
and
over
individual
sections,
and
it
does
the
job
of
dividing
them
up.
I
think
all
of
this
is
kind
of
lower
priority
than
actually
getting
a
primary
api
set
up.
B
C
B
Yeah,
I'm
happy
to
help
working
on
that,
but
I'm
not
familiar
enough
with
web
workers
to
make
intelligent
decisions
on
that.
So
yeah
definitely
need
some
help.
D
B
C
C
And
and
the
normal
way
would
be
the
red
well
like
with
rust
and
rayon,
it
sorts
it
all
out,
so
the
the
sdk
would
just
be
handing
over
the
whole
job
to
it.
Okay,
but
yeah,
but
that's
one,
that's
their
approach,
other
other
approaches,
yeah
other
software,
uses
different
approaches.
C
B
C
C
C
D
B
C
B
B
C
B
Okay,
so
there's
a
there's,
a
debate
to
be
had
here
passing
in
the
entropy,
I
think
would
be
like
less
secure
because
there's
just
now
more
places
which
touch
the
the
secret
yeah.
But
that's
a
trade-off
against
things
like
allowing
the
user
to
keyboard
smash
or
whatever.
D
Are
you
suggesting
that
the
entropy
is
created
outside
of
the
sdk
and
then
you
pass
it
in.
A
D
I
think
that
I'd
have
to
check
on
wasm's
host
functions
because
because
wasn't
the
sandbox
yeah,
I
assume
that
sort
of.
If
you
pass
in
a
host
function
and
the
randomness
is
done
inside
of
the
wasm,
it
might
be
easier
to
clear
all
copies
of
it.
But
I'm
not
100
sure
on
that.
I
think.
C
And
it's,
but
it's
probably
just
easiest
to
derive
the
actual
entropy
and
pass
the
password
across.
D
B
D
B
I
mean
I,
I
think
in
general,
there's
a
lot
of
understanding
to
be
done
on
how
we
zero
eyes
everything
on
the
the
memory
side
here-
and
I
guess
now
the
sdk
is
included
in
something
we
need
to
worry
about.
D
A
B
B
B
Okay,
then,
let's
go
for
now.
I
think
we're
trying
to
pass
in
the
secret.
B
So
one
of
the
other
options
that
got
touched
upon
now
was
the
the
the
primary
api
and
yeah.
So
I've
done
a
fair
bit
more
digging
into
some
some
of
the
options
and
yeah,
I'm
still
not
an
amqp
fan.
They're
like
there
aren't
stable
implementations
in
many
languages
like
rust,
included,
for
example,
and
I'm
just
not
convinced
that
it's
like
the
complexity
is
is
is
worth
it
particularly
if
we
can
shorten
contribution
times
down
to
low
enough
numbers.
C
Yeah
yeah
fair
enough
comment.
Carl
I've
been
putting
it
together
and
thinking
about
how
look
there's
a
pure
rest
api
and
taking
some
inspiration
from
from
marius's
api
yeah
yeah.
It's
it's
mapping
a
a
asynchronous
process
onto
a
synchronous
call,
but
yeah
it
does
does
make
the
calls
simpler,
like
those
in
the
api.
B
I
I
certainly
agree
that
in
some
like,
if
you're
only
writing
one
implementation
or
it
was
the
sort
of
perfect
world,
we
can
achieve
pi
throughput
by
having
a
much
nicer
queuing
system
by
using
websockets
or
amqp
or
whatever.
But
I
just
the
the
simplicity
of
a
restful
api
really
appeals
to
me
and
from
the
standpoint.
A
C
So
I've
I've
I've
been
putting
together
a
draft
of
that
api
spec
on
that
basis,
and
it
looks
like
it's:
it's
going
to
be
feasible,
yeah.
B
Fantastic,
do
you
do
you
have
a
place
you're
working
on
that
you
can
share
either
publicly
or
privately.
C
So
you
can
yeah
yeah
sure
I'll
I'll
put
something
in
the
telegram
chat,
probably
tomorrow,
fantastic
thanks.
B
Like
on
that,
I've
been
thinking
about
like
a
little
bit
on
how
to
make
sure
that,
like
the
the
the
pits
we
take
for
this,
the
skewing
system
aren't
too
bad.
Then,
based
on
like
switching
to
a
a
restful
api
and
to
me,
the
main
thing
here
is
that
the
the
time
slots
for
when
you
are
going
to
participate
participate
become
fixed.
B
So
you
will
register
in
the
queue
you
get
some
token
back.
But
then,
after
that,
it's
there
is
no
fixed
point
in
the
future,
a
time
where
you
will
participate
and
we
can't
sort
of
move
that
up
or
down
very
easily,
and
so
I've
been
trying
to
think
about
like
how
like
hey.
What
does
that
mean,
and
how
do
we
minimize
mitigate
the
the
downsides
of
that?
So
one
idea
I
had
is
that
we
could
allow
a
parameter,
which
is
how
long
you
request
your
time
slot
to
be
so.
B
If
you're
going
to
attempt
to
do
this
single
threaded
or
you've
written
your
own
implementation,
that's
got
some
pretty
slow,
bls
library,
then
you
can
request
a
longer
time
slot
and
then
for
the
sort
of
like
primary
implementation.
That
everyone's
going
to
be
using
the
the
one
jeff's
working
on
we
can,
we
can
just
make
that
we
can
set
that
to
a
more
reasonable
number
based
based
on
how
long
it
seems
to
to
allow
participants.
B
So
we
can
have
say,
like
timeout,
is
30
seconds
up
to
2
minutes
or
something,
and
you
can
request
that
when
you
request
your
slot.
The
other
idea
I
had
is
that
we
are.
We
could
be
quite
strict
on
when
you
arrive,
so,
if
you've
registered
in
the
queue
and
you're
saying
like
five
seconds
late
or
something
then
you'll,
you
lose
your
slot
and
someone
else
can,
if
they
request
proquest
to
slot
in
the
queue
they
could
immediately
slot
in.
At
that
point,.
C
Yeah,
I
thought
we'd
a
couple
of
points
there.
There
will
be
a
lot
of
variation
in
the
computation
time,
even
with
even
with
any
particular
implementation,
because
people
have
different
number
of
threads
in
their
machines.
People
have
different.
C
I
do
have
multi-threading
running
with
wasm
and
I
ran
it
on
a
desk
desktop
which
has
a
fairly
recent
process:
toronto,
nate
threads,
and
it
got
down
to
like
25
seconds
the
competition
time,
which
was
not
as
great
an
improvement
as
I
was
expecting
like
on
a
single
threaded.
It
was
just
over
a
minute
but
yeah
there's
going
to
be
lots
of
variation,
so
yeah.
So
the
I
was
thinking
along
the
lines
of
the
client
checks
in
and
then
progressively
checks
in
to
assert
that
they're
alive.
B
Okay,
so
the
that's
that's
an
interesting
idea.
I
think
it's
a
the
philosophical
difference
between
that
approach
and
what
I
was
thinking
along.
The
lines
is
not
to
say
one's
more
correct
or
whatever
just
that,
so
you
might
understand
correctly.
Your
idea
is
to
sort
of
have
a
cue.
That's
where
your
position
is
important,
like
where
you
are
in
that
queue,
and
then
we
we
keep
updating
the
time
versus
a
thing
where
there's
a
fixed
time
that
you
you're
going
to
be
participating
in,
which
was
more
what
I
was
proposing.
B
B
So
the
the
the
the
thing
I'm
always
trying
to
optimize
for
is
like
a
person
writing
their
own
implementation
here,
and
I
worry
that
the
timing
requirements
are
a
little
bit
difficult
to
get
to
get
right
if
you're
doing
your
own
implementation,
particularly
if
we
don't
have
like
a
server.
You
can
test
with
to
make
sure
that
your
your
timing
is
good.
C
Oh
yeah,
so
I
wouldn't
be
too
precise
on
the
timing.
It's
just
like
a
deadline
where,
if
you
don't
check
in
by
that
time,
you're
assumed
to
be
no
longer
alive
and
it's
going
to
be
generous,
well,
yeah,
okay,
so
yeah.
C
C
So
then
you
have
to
take
some
sort
of
corrective
action
to
you
know,
allow
them
time
to
to
show
up,
or
else
to
just
abandon
and
go
on
to
the
next
next
person.
But
if
that
person's
not
expected
to
show
up
until
it
until
a
certain
time
slot,
which
would
be
later
then
you're
going
to
waste
that
time.
B
I
guess,
for
my
you
definitely
waste
that
time
but
like
in
terms
of
complexity
of
implementing
this,
it's
a
lot
simpler.
You
don't
have
to
worry
about
like
a
whole,
complicated
timing
mechanism.
It's
just
wait
until
like
you,
you
get
a
one
time
that
you
have
to
run
it
for,
and
you
can
just
put
an
infinite
for
loop
before
you,
so
in
an
infinite
loop
before
your
code,
that
just
checks
against
whether
the
current
time
is
like
wall
time
is
greater
or
less
than
your
participation
time
kind
of
thing.
C
D
B
All
right,
I
I've
been
to
okay
I'd,
be
interested
to
see
what
what
your
your
api
looks
like,
and
I
think,
let's,
let's
discuss
it
a
bit
then
async.
D
Just
on
a
side
note
jeff.
You
briefly
mentioned
that
you
got
25
seconds.
I
think
this
is
about
twice
of
what
I
got
on
my
laptop.
So
maybe
we
need
to
sort
of
have
standard
hardware
specs
so
that
the
benchmarks
can
be
normalized.
D
I'm
also
wondering
if
how
you
did
the
multi-threading
part.
I
used,
I
think,
comlink
library,
that
might
sort
of
be
a
reason
for
the
variants
as
well.
D
C
And
and
just
left
it,
I
need
to
decide
what
to
do.
D
I
remember
doing
another
step
where
I
had
to
install
a
library
called
comlink.
C
Yeah
yeah,
I
found
it
didn't
work
in
mozilla,
but
it's
definitely
multi-threading.
It
just
doesn't
seem
to
be
very
efficient.
D
D
Yeah
I
do
yeah,
I
do
still
think.
Maybe
we
need
standard
hardware
specs
in
order
to
analyze
the
benchmarks.
B
A
D
D
B
I
can
I
can
reach
out
to
our
devops
team
to
see
if
we
can.
We
can
organize
something
like
that
for
us.
D
C
Yeah
yeah
that'd
be
fine,
but
I
think
in
the
real
world
we're
going
to
have
a
lot
of
variations.
You
know
benchmarks
are
going
to
be
it's
going
to
be
a
widespread
from
yeah.
B
B
A
Yeah
one
thing
I
wanted
to
ask
jeff
is:
you
said
there
are
a
couple
people
from
pse.
That
would
be
helping
you
with
the
interface.
Should
they
at
what
point
should
they
start
coming
to
these
calls,
or
should
we
start
interfacing
with
them
like
getting
the
design
ready,
making
sure
it's
plugging
incorrectly
stuff,
like
that.
C
Oh
yeah:
well,
I'm
getting
one
guys
starting
in
a
week
or
so,
but
I
I
really
just
want
to
start
him
off
by
I'll,
have
a
bunch
of
github
issues
and
we'll
work
on
it
together.
So
I
don't
know,
I
think,
if
they
need
to
be
on
the
call
straight
away,
but
down
the
track,
we'll
get
them
involved.
A
Okay,
so
I'll
just
check
in
on
that
next
week,
then
or
sorry,
two
weeks
before
the
next
call
yeah
next
thing
on
the
agenda
is
that
I
know
the
spec
has
been
circulated
to
a
small
group
of
people.
But
carl
do
you
want
to
give
an
update
on
like
where
it's
at
and
what
we
need
to
do
between
now
and
the
the
audit
in
september.
B
So
I
mean
a
few:
there
are
a
few
things
there.
One
is
like
the
like.
We
needed
to
find
this
api,
which,
which
jeff
was
was
talking
about
the
the
one
he's
working
on
and
I'd
like
to
get
that
then
integrated
into
into
these
specs
and
now
also
include
this.
This
sdk
and
then
yeah,
the
the
obviously
between
now
and
audit,
then,
is
obviously
implementations,
which
would
be
the
the
big
thing
that
needs
to
be
done.
B
On
top
of
that,
the
specs
themselves
I
mean,
like
it,
sort
of
just
defines
the
the
computation
that
needs
to
be
done,
and
I
think
that's
that's
fairly
stable
as
to
what
what
what
needs
to
be
done
there
so
like
this
can
be
shared
and
people
can
work
on
it
or
whatever.
That's
that's
all
good.
A
Got
it
yeah,
I'm
pretty
you've
probably
done
this
with
with
some
people
already,
but
is
there
anybody
that
you
want
to
put
it
in
front
of
that
hasn't
seen
it
yet
just
to
review
it.
B
Yeah
not
think
of
anyone
off
the
top
of
my
head
now,
but
I'll
do
some
thinking
and
put
on
people's
desks
this
week.
That's
a
good
idea.
A
Sure
yeah
and
then
you
mentioned
the
implementations,
which
is
one
of
the
next
things
so
for
the
audit,
are
we
going
which
implementation
are
we
going
to
be
focusing
on
it?
Will
it
be
tess
or
a
different
one?.
A
B
So
I
mean
it,
it
sort
of
depends
on
where
we
are
benchmark
wise.
I'm
not
like
I'm
unsure
is
how
to
compare
the
the
stuff
kevin's
been
doing
versus
jeff's
thing
in
part
due
to
not
having
a
common
like
common
device.
We're
testing
on.
B
A
Okay,
does
picking
do
we
need
to
make
a
decision
now
on
which
implementation
we
use,
or
can
they
both
be?
I
mean
I
think
it
sounds
like
what
we're
working
towards
is
something
where
any
implementation
can
be
swapped
in.
Is
that
true,
or
am
I
mistaken,.
B
D
So
I
think
mine
and
jeff's
implementation
are
essentially
the
same
apart
from
like
a
bit
of
javascript
code,
if
I
understood
correctly
just
like
javascript
code
that
calls
the
the
wasn't
part
we
both
sort
of
rely
on
the
rust
library
now.
A
All
right
has
anybody
been
in
touch
with
the
circum
people
about
updating
the
library.
A
A
D
I
haven't
heard
from
them,
but
I'm
wondering
if
we
do
need
them.
I
guess
it
doesn't
seem
like
we
currently
need
them.
They're,
not
blocking
anything
than.
C
A
B
It
and
if
they,
if
they
do,
want
to
do
it
later,
if
they
do
decide,
this
is
something
I
want
to
get
involved
in.
They
can
then
quote
unquote,
implement
this
sdk,
and
that
would
be
fine.
D
C
Yeah,
yes,
that's
right.
The
the
snap
js
was
was
working
was
multi-threading
we
could
have.
We
could
have
run
with
that
if
we
were
going
to
if
we
wanted
to
get
going
in
like
in
two
weeks
or
a
month
or
something,
but
we've
got
a
bit
more
time
to
play
with.
We've
got
some
some
good
progress
on
the
rust
side.
So
that's
much
less
important
that
we
have
snap
chairs
as
well.
A
Okay,
that's
great,
and
we
already
touched
on
the
implementations.
D
Yeah,
go
ahead,
pretty
imp,
so
I
noticed
the
specs
were
using
a
python
code.
Do
we
need
the
python
reference
implementation.
B
I
can
add
one
if
it
helps,
and
I
guess
it
will
allow
us
to
do
things
like
differential
fuzzing,
so
I
can
sort
of
implement
the
sdk
in
in
python
if
it
helps,
but
the
the
specs
being
in
python
are
just
sort
of
because
that
seems
to
be
the
way
we
do
things
these
days.
As
in,
like
all
the
ethereum
consensus
and
execution
specs
of
now
being
written
in
python,.
D
B
So
the
the
the
the
way
we
can
do
it
is
base
is
what
we've
done
for
the
rest
of
the
specs.
There
is
like
the
consensus,
specs
or
whatever
is
that
the
the
specs
themselves
are
the
reference
implementation,
so
there's
a
script
that
sort
of
pulls
out
all
the
python
blobs
and
turns
that
into
and
into
executable
code.
B
It's
certainly
a
nice
to
have,
and
I
wasn't
exactly
planning
on
doing
it
mostly
because
I
was
feeling
lazy
at
touching
those
terrifying
scripts
for
for
for
turning
the
the
specs
into
executable
stuff.
But
it
sounds
like
it's
something
that
people
really
would
like,
and
it
certainly
would
help
and
allow
us
to
write
test
cases
more
easily
and
do
differential
fuzzing.
So.
B
I'm
more
keen
with
that,
particularly
if
we
have
an
sdk
defined
that
really
allows
us
to
have
very
nice
interfaces
so
sure
I
will
do
that
I'll
make
my
specs
executable.
D
B
D
A
Okay,
right
yeah,
we've
reached
the
end
of
the
the
things
I
had
on
the
list.
Is
there
anything
that
we
missed
before
I
go
into
like
what
people
are
gonna
be
working
over
the
next
two
weeks.
B
I
have
some
topics
I'd
like
to
chat
about.
If
other
people
don't
have
anything,
they
want
to
touch
on
first,
because
they
might
be
easy
to
derail.
Slash,
extend
discussions.
A
I
guess
the
only
thing
I
was
going
to
mention.
I
I
sent
it
to
you
in
chat
carl,
but
generally,
I
think
it'd
be
better.
If
we
try
to
move
more
of
these
conversations,
you
guys
are
probably
having
one-on-one
into
the
public
kcg
ceremony
chat
just
so
other
people
can,
if
they're,
if
they're
catching
up
you
know
after
a
month
or
so
of
checking
out
of
this
project,
it'll
be
much
easier
for
them
to
understand
why
decisions
were
made
in
certain
ways.
B
Agreed
particularly
haven't
been
good
with
that
I've
been
trying
to,
as
of
yesterday,
improved
that
a
little
bit
so
like
I've
opened
issues
on
my
specs
repo
for
discussions,
kind
of
things
on
on
apis
or
the
point
I
was
raising
earlier
on
optimistic
contributions,
etc,
etc.
So
yeah
between
the
chat
and
hopefully
issues.
We
should
have
a
better
history
of
this
and
agree.
That's
something
that
that
I'd
like
to
do.
D
Yeah
yeah,
so
I
was,
it
was
sort
of
related
to
what
you
just
said.
I
was
reading
the
specs
and
I
thought
that
it
would
be
good
to
have
this.
D
D
So
I
was
looking
to
sort
of
copy
some
stuff
over
from
the
notes
into
this
new
repro
or,
if
it's
not
being
made
already.
B
I
think
you're
not
doing
it
on
a
separate
repo
and
having
it
be
sort
of
attached
hack,
empty,
slash,
not
ethereum
nodes,
and
if
it's
more
explaining
how
to
implement
things
or
whatever,
then
we
can,
we
can
actually
put
included
in
the
repo
itself.
I'm
I'm
I'm
fine
with
that.
As
long
as
it's
in
a
separate
section,
but
yeah
no,
actually
I
I
think
I
prefer
to
do
it
that
way.
Otherwise
I
think
it's
a
little
bit
hard
to
track
across
multiple
repos,
exactly
what's
happening.
D
Yeah
sure
so
just
put
it
in
a
hack
md
for
the
rationale.
B
D
Right:
okay,
yeah:
I
was
more
thinking
the
latter's
and
this
is
why
you
need
to
do
this
check
and
stuff
like
that.
Yeah.
B
It'll
be
slightly
less
elegant.
It'll
have
a
little
bit
of
extra
files
lying
around,
but
I
yeah,
I
just
think
it's
easier
than
having
multiple
repos
and.
C
D
Yes,
yes
I'll
be
looking
into
doing
that,
it
mainly
will
just
be
like
a
copy
and
paste
and
refactor
and
stuff.
I
did
in
the
notes
that
initially
was
there
yep.
A
B
Carl
yeah
sure
so
I
guess
I'm
gonna
be
working
on
defining
that
sdk
and
trying
to
make
the
the
specs
implementable
and
also
reviewing
slash,
commenting,
slash
trying
to
make
final
decisions
on
the
api
which
jeff
said
he'd
be
he'd,
be
sharing.
C
Cool
yeah
and
yeah,
so
I'll
I'll
continue
on
those
specs
I'll
I'll,
announce
a
url
where
people
can
find
find
find
them
as
I'm
working
on
them
and
yeah.
There's
quite
a
bit
of
work
to
be
done
in
those
specs
and
I'll
get
together.
Some.
A
B
Yeah,
that's
when
we
have
the
the
secret
booking
right.
A
Are
we
still
on
track
for
that?
Like?
Are?
We
gonna
have
a
crunch
time
in
the
last
two
weeks?
How
do
people
feel.
C
D
I
think
I'd
be
a
bit
more
comfortable
if
we
had
something
like
what
marius
had
to
something
during
the
ceremony
very
quickly
and
then
sort
of
wreath
refactoring
that
just
have
everything
up.
So
I
don't
know
I'm
sort
of
in
the
middle
like
if
we
have
a
ceremony
running
with
what
we
like
just
a
ceremony
running
that
we
can
tear
down
and
keep
pulling
up
the
refactor
stuff.
C
Okay
would
be
quite
nice,
yeah
good
point
kev
I
can.
I
can
actually
release
my
my
my
test
site,
so
people
can
play
with
it
and
that'd
be
good
too,
because
we'd
see
what
sort
of
variation
yeah.
D
B
B
B
Because
I
I
just
wasn't
comfortable,
assuming
we'd,
have
a
robust
enough,
like
end-to-end
implementation,
for
for
these
first
audits.
But
maybe
I'm
wrong
in
that.
B
Because
then,
the
sort
of
order
to
the
full
system
would
be
based
on
discussions
with
sigma
prime
yesterday
yeah,
the
the
order
of
the
full
system
would
be
at
the
end
of
october.
A
Right
I
was
going
to
bring
that
up.
They
had
actually
offered
to
that.
They
had
a
slot
open
up
in
september,
but
carl
doesn't
feel
like
we'll
be
ready
for
that
in
time,
but
yeah
there
was
a
chance
that
we
had
been.
We
may
have
been
able
to
move
it
up
to
mid-september.
D
Right
yeah,
I
think
that
was
a
good
decision.
B
I
think
had
we
given
them,
something
that
it
wouldn't
have
been
complete,
so
it
would
have
been
like
try
ordered
this,
but
they're
one
or
two
things:
we're
still
trying
to
fix
and
like
some
of
the
feedback
they
would
have
given
us
would
have
been
obvious
feedback,
because
we
we
were
aware
of
these
weaker
points,
whereas
now
we
can
have
a
more
code,
more
solid
code
base.
We
present
to
them
right.
D
A
The
other
thing
which
came
to
mind
while
we
were
talking
is:
should
we
in
the
next,
maybe
in
the
next
two
weeks
for
the
two
weeks
to
follow
that
somebody
else
to
come
and
do
a
check-in
like
danny
or
dankerad,
or
somebody
who
can
just
give
who
hasn't
been
engaged
in
this
so
far
just
to
check
in
on
the
progress,
and
maybe
we
do
a
bit
of
a
presentation
to
them.
Would
that
be
useful
or
is
it
just
creating
unnecessary
work?
A
I
guess
I'm
so
I'm
pretty
far
outside
of
the
development
side
of
things.
So
I'm
would
be
curious
what
you
guys
think
about
if
this
would
be
helpful
or
not
see
if
we're
missing
anything
things
like
that.
D
A
Okay,
so
then
I
guess
we'll
just
the
next
thing
to
prepare
for
is
just
the
getting
ready
for
that
audit
in
august.
Okay,
yeah!
That's
that's
it!
For
me,
carl!
You
had
some
topics.
Sorry
I
took
up.
I
took
up
most
of
those
last
10
minutes.
B
No
all
good
is
everyone
fine
to
to
chat
a
little
bit
for
on
on,
to
run
over
time
a
little
bit
to
discuss
these
topics?
If
not
just
drop
out?
That's
that's
fine,
and
so
one
of
the
things
I
wanted
to
talk
about
was
my
black
optimistic
contribution
idea.
So,
basically
save
the
subgroup
checks
till
after
you've
already
returned
the
file
to
the
coordinator
as
a
means
of
speeding
things
up.
B
I
mean
it
doesn't
change
anything
from
like
a
security
standpoint,
but
it
might
change
things
from
an
optics
standpoint.
I
don't
know
if
anyone
has
read
that
idea.
Slash
had
any
thoughts
on
that
or
would
like
me
to
explain
what
explain
it.
C
C
B
Group
elements
to
like
basically
extract
some
information
about
the
secret
and
to
check
this
there.
We
either
need
to
do
subgroup
checks
or
a
pairing
check
with
some
extra
assumptions
on
the
pairing,
but
this
just
adds
computation
time.
So
if
we
remove
those
those
checks
or
do
those
checks
after
the
fact,
then
this
basically
means
that
the
participant
could
be
tricked
by
the
coordinator
into
leaking
some
small
amount
of
information
about
their
secret.
Assuming
that
the
coordinator
pulls
off
this
malicious
attack
with
low
order
elements
which
we
don't
know.
C
Yeah,
and-
and
can
we
assume
that
it's
going
to
be
quite
rare,
well.
B
D
Yeah,
I
guess
it's
on
the
assumption
that
you
have
a
honest
coordinator,
the
worst
case
for
skipping
the
checks
like
these
is
just
that
a
few
bits
of
the
secret
key
is
leaked
in
that
worst
case.
If
it
ever
happens,
I
guess
the
person
could
retry
or.
B
Yeah,
so
my
idea
here
is
that
you
don't
attest
to
like
this
being
your
contribution,
so
you
still
perform
those
checks.
You
just
do
it
after
you've
returned
the
the
updated
transcript
to
the
coordinator,
and
then
yes,
you
you
would
you
would
re-participate
at
a
later
date
slash
shout
about
it
or
whatever,
but
as
it's
like,
as
I
said
like,
I
don't
even
think
it's
possible
to
do
this
because
we
don't
know
any
low
order
elements
for
bls
and
requires
a
malicious
coordinator.
D
Right,
I'd
have
to
double
check
the
bls
part
about
the
low
orders
they
order
points
but
yeah
the
malicious
coordinator
yeah.
If
we
can
assume
that
the
coordinators
will
just
be
by
ethereum
tonight
is
that
is
that
a
correct
assumption.
B
Yeah,
so
it's
going
to
be
run
by
sort
of
trusted
community
members,
because
the
coordinator
always
has
the
ability
to
censor
you.
So
there's
there's
some
level
of
trust
here
anyway,.
D
Yeah
yeah.
I
think
this
is
a
good
idea,
then
just
do
it
after
yeah
and
yeah.
So
I
think
what
you
said
is
a
good
idea,
so
you
only
attest
if
the
subgroup
checks
pass.
So
you
optimistically
assume
everything
is
correct:
yeah,
yeah
yeah,
I
think
that's
a
good
idea.
Then
you
can
sort
of
do
the
full
subgroup
check
because
it
doesn't
hold
up
the
ceremony
exactly
yeah,
okay,
yeah.
B
I
mean,
as
you
say,
not
entirely
sure
about
the
that
my
my
my
claims
about
law
to
be
a
less
stuff.
I'm
also
not
entirely
convinced.
I've
asked
around
and
people
seem
to
think
this
is
the
case,
but
no
one's
yeah,
but
yes
I'll
operate
under
the
assumption
that
this
is
a
good
idea
for
now
and
implement
that
because
obviously
affects
the
sdk.
D
Yeah,
I
think
it's
a
good
idea.
We
should
probably
put
in
the
rationale
if
there
are
low
order
points,
how
much
how
many
bits
are
actually
leaked
to
the
coordinator
just
in
case.
But
if,
if
it's
what
you
said,
there
is
no,
there
are
no
actual
low
order
points
then
yeah.
We
can
just
remove
it
all
together.
B
I
mean
that
my
mind
decides
there
are
no
known
ones,
but
I
think
we
should
perform
the
checks
anyway.
Certainly
from
an
optic
standpoint,.
B
And
in
case
like
what
happens,
if
five
years
down
the
line,
we
do
find
something
now
do
we
trust
it
or
whatever
and
then
the
second
thing
is
I
off
the
top
of
my
head.
I
think
it's
2.2
bits
the
that
that
could
be
leaked.
D
B
D
Right
yeah,
I
think
that's
a
good
idea,
even
if
I
mean
as
long
as
it's
like
less
than
I
guess
eight.
This
is
the
worst
case
and
it
should
be
fine.
I
mean
if
it
just
leaks
the
whole
private
key,
then
that
would
be
a
really
bad
situation.
I
know
that's
not
the
case.
D
D
D
B
Okay,
I'm
liking
this
I'm
liking.
This
I'll
then
implement
that
and
then
the
other
thing
I
was
wanting
to
check.
So
one
of
the
ideas
I
had
was,
I
was
worried
about
the
file
getting
too
large.
After
some
of
the
discussions
we
had
with
marius
doing
some
back
the
envelope
calculations
last
week,
but
I'm
no
longer
convinced
that's
the
case.
So
I
was
going
to
propose
having
a
sort
of
truncated
ceremony
so
truncated
transcript,
where
you
don't
receive
all
of
the
sort
of
intermediate
numbers.
B
D
B
So
I
was
going
to
propose
not
doing
that
because
we
do
currently,
but
then
my
thought
is
like
is
it?
Is
it
worth
the
effort
so
like
just
the
just
the
the
piles
of
tile
sort
of
comes
up
to
to
seven
and
a
half
megs.
D
B
And
then
like,
if
we
have
say,
as
I
said,
a
hundred
thousand
participants
we'll
never
have
a
hundred
thousand
participants.
But
if
we
do
that's,
then
a
22
meg
file,
so
the
the
delta
there's
not
too
large.
If
we
have
ten
thousand
participants
which
I'd
be
ecstatic,
if
we
reached
then
the
files
nine
megs,
so
you
picked
up
one
and
a
half
megs
of
sort
of
fluff
and
I'm
not
sure
it's
worth
sort
of
making
the
distinction
between
truncated
and
non-truncated
versions
of
it.
D
I
was
also
under
the
assumption
that
you
don't
need
to
send
those,
because,
as
a
participant
you
receive
some
srs,
you
contribute
to
it.
You
give
your
witness
and
then
you
don't
really
care
about
the
previous
contributions.
D
B
So
I
mean
I,
I
agree
with
that
statement:
it's
not
necessary
but
like
if,
if,
if
for
ten
thousand
participants,
the
the
overhead
is
ten
percent,
then
like?
Is
it
worth
like
making
that
distinction?
It
also
means
that,
like
it
would
be
easier
to
verify
that
everyone's
that
you're,
like
other
people
being
included
before
you,
whatever
based
on
the
transcript
you
receive
at
the
time.
D
But
then
couldn't
the
coordinator
just
send
you
a
bunch
of
random
pub
keys
and
then
say
you
know
these
are
different
people
who
have
who
have
participated.
Yeah.
A
B
B
Okay,
then
one
of
the
other,
the
other
ideas
I've
been
having
is,
and
I'm
not
sure
about
it
is
so
what,
if
the
like.
So
if
you're
testing
to
something,
that's
basically
saying
that
you
think
this
is
your
your
contribution,
but
multiple
people
could
claim
the
same
contribution.
B
Which
could
potentially
like
cast
out
on
things,
so
we
could
sort
of
do
the
inverse
and
have
the
contribution
sign
some
of
your
own
information
so
like
we
use
the
the
secret
to
create
a
bls
signature
over
some
message
that
you
want,
which
could
be
your
ethereum
address
or
whatever,
and
so
then
in
the
transcript
would
be
a
reverse
link.
D
B
B
B
D
Right,
I
think
battalic
asked
this
question
before
somewhere
and
the
idea
was
that
sort
of
if
someone's
lying,
then
you
can't
really
trust
them
to
even
of
participated
correctly
in
the
first
place,
yeah.
D
So
I
don't
know
I
feel
like
it
might
add
extra
complexity
without
making
it
without
like
any
extra
security
being
added.
But
I'd
like
to
see
what
sort
of
vitalik
and
bankrupt
think
about
that.
B
Okay,
I
will
sort
of
re-raise
that
with
them
and
get
some
input
from
from.
D
B
D
D
B
D
D
Said
they
sort
of
put
in
I'm
vitalik,
everyone
just
says:
I'm
vitalik
yeah
yeah,
okay,
yeah
yeah.
B
Like
it
doesn't,
change
like
in,
in
that
case,
it's
all
just
malicious
participants
with
dishonest
participants
which
doesn't
change
the
security
assumption,
but
might
change
the
optics
on.
Oh
now,
one
person's
participated
multiple
times
like
do.
They
have
all
the
keys
kind
of
thing.
D
Right
so
I
don't
know
if
it
changes
the
security,
because
maybe
I
participate
properly
and
then
I
put
in
like
some
a
random
input
and
I'll
just
start
trolling
people
and
say
you
know:
I'm
metallic,
I'm
vitalik.
So
I'm
still
yeah.
B
Okay,
I'll
write
it
up
properly
and
as
a
github
issue
and
get
people
to
to
contribute.
B
Yep
yeah,
I
think
that's,
that's
all
that
I
that
I
wanted
to
discuss.
Yeah.