►
Description
Weekly meeting of the Grothendieck Team.
A
For
the
last
week
we've
been
working
on
transaction
executions.
That's
the
phase
that
we're
currently
in
and
we've
been
trying
to
get
our
code
complete.
So
there's
really
I
guess
two
things
on
going.
At
the
same
time,
one
is
trying
to
get
that
code
complete,
which
is
we're
not
quite
there,
but
we're
in
the
process
of
checking
and
I
think
the
last
of
it.
A
The
EC
IP
1010,
I
think,
is
probably
the
last
p
or
that
needs
to
go
through
if
it's
not
already
true
and
in
parallel
with
that
we're
implementing
a
a
test
and
and
fix
cycle
where
we
try
to
execute
all
of
the
transactions
in
the
blockchain
through
our
EVM
and
as
we
come
up
against
problems,
we
we
create
viewers
and
and
fix
them,
so
I'm
just
going
to
chat
about
I,
guess
two
things:
one
is
just
something
of
interest:
I,
guess,
Adam!
You!
A
B
So
it
all
starts
by
realizing
that
the
public
key
recovery
described
in
yellow
paper
assumes
that
there
are
only
two
possible
cases
for
public
key
recovery.
But
the
algorithm
that
is
used
with
the
specific
elliptic
curve
that
is
used
for
cryptography
allows,
in
some
cases,
for
public
keys
to
be
recovered
and
I
wanted
to
investigate
that.
B
Why
there
is
a
difference
and
while
searching
I
found
out
that
those
two
additional
cases
that
are
emitted
in
yellow
paper
are
actually
highly
improbable
to
a
cure,
and
even
in
the
oddity
implementation,
I
found
the
comment
that
negligibly
improbable
to
cure.
So
that's
somehow
explains
why
there's
no
recover
are.
B
There
are
only
to
recover
IDs
for
the
public
key
and,
besides
that,
it
turns
out
that
we
also
have
to
add
some
special
formatting
for
public
key
encoded
with
the
library
that
you
used
for
elliptic
curve
cryptography,
because
this
did
library
when
we
producing
a
public
key
to
later
generate
the
Kazakh
256
to
obtain.
The
account
address
adds
additional
bite
to
the
encoded
point,
so
that
this
is
the
another
discover.
A
B
B
A
B
A
No
okay,
so
the
other
thing
that
we've
been
doing
is
trying
to
get
through
all
the
transactions
in
all
of
the
blocks.
So
we've
made
several
breakthroughs
and
then
been
hit
by
a
other
issues
as
we
as
we
go
from
successful
blog
two
unsuccessful
block,
starting
at
zero
and
Radek.
What
is
the?
What
is
the
latest
news?
What
is
what
what
block
are
we
up
to.
A
Radek,
if
you
can
hear
me,
you
may
have
to
try
to
log
back
in
again,
the
connection
is:
is
you've
dropped
altogether?
Yes,.
C
A
D
D
A
Exciting
we
can't
get,
we
couldn't
get
a
status,
that's
more
up
to
the
second
than
that,
and
so
that
is
literally
exactly
where,
where
we're
at
but
roddick
I
wanted,
and
just
for
you
to
share
you
you've
done
some
debugging,
obviously
of
of
the
problems
that
we
run
into
it.
So
can
you
just
give
us
a
look
at
at
some
of
the
debug
information
that
you're
generating?
Yes
exactly.
I
want.
C
C
Yes
thanks,
so
he
here
I
will
be
running
our
client.
It's
I
have
a.
I
have
saved
the
state
on
a
on
a
previous
bug,
so
it
will
be
if.
A
C
The
gas
used
in
a
block
was
not,
but
that
we,
we
calculated
27,000
gasps
the
block,
but
it
was
expected
to
be
to
be
42,000
and
what
we
do
in
such
situations.
We
have
several
levels
of
logging,
for
example.
Here
we
have
traces
for
from
all
the
instructions
executed
during
the
execution
of
the
transaction.
C
So
what
we
do
is
we
use
this
very
helpful
to
live
either
camp
and
it
has.
It
has
information
about
all
the
blocks
and
transactions
ever
performed
under
on
the
chain.
So
here's
the
problem,
problematic,
block,
244,000
and
here's
the
sole
transaction
that
has
been
I
have
to
be
included
in
it.
So
we
can
look
at
the
vm
traces
of
the
transaction.
C
C
Take
too
much
time
this
is
complicated,
but
basically
just
this
information
that
there's
fifteen
fifteen
thousand
cast
difference.
It
is
expected
that
was
actually
calculate.
This
is
quite
telling
and
we
can
usually
have
some
suspicions
about
that
too
and
yeah.
That's
what
the
processor
looks
like
sand
and
also
whenever
we
we
fix
such
a
block.
We
we
log
it.
C
We
have
a
log
of
all
the
blogs,
that's
what
we
found
problems
for
and
showed
descriptions
of
the
fixes
and
I
think
it's
important
to
see
here
that
in
the
beginning,
those
those
gaps
between
consecutive
blocks
that
cause
problems
with
quite
small
like
a
thousand
so
so
and
right
now
we
are
moving
like
15000
block
at
a
time.
So
so
it's
growing
and.
A
Yeah,
good,
that's
I!
Guess,
as
you
say,
that's
that's
that's!
The
plan
is
to
that
we
should
hit.
We
should
have
bigger
gaps
between
between
the
problems
as
we
as
we
sort
of
get
through
the
more
common
problem
so
and
we
get
sort
of
I
guess
as
as
there's
more
experience
for
want
of
a
better
word
under
the
belt
of
the
vvm
processing,
yeah
I'm.
Okay,
thanks
Roddick
there's
anyone
else
have
any
questions
for
faradic.