►
From YouTube: Ethereum Core Devs Meeting #66 [2019-07-25]
Description
A
A
D
C
D
Yeah
looks
good
to
me.
Probably
I
would
say
that
it's
safer
to
take
take
the
chain
ID,
that's
within
the
chain
and
not
the
transaction,
because
I
think
homestead
transactions
are
still
valid,
which
don't
have
a
chain
ID.
So
that
might
be
a
bit
of
a
surprise.
Your
smart
contract,
all
of
a
sudden,
can
or
can
have,
can
receive
different
chain
IDs
on
the
same
chain.
Yeah.
C
E
C
So
that
it
all
it
says,
is
that
there's
an
opcode
when
you
call
it
returns
a
number.
We
don't
know
what
the
number
is,
but
it
returns
a
number
and
the
implementation
detail
is
doesn't
come
from
transaction
doesn't
come
from
somewhere
inside.
The
client
sounds
like
it's
safer
and
just
generally
I
think
more
people
aren't
on
board
with
a
client
just
providing
a
number,
and
that
number
is
the
same
one
that
that
transactions
would
get
rejected
if
they
don't
have
that
number.
C
There
was
a
question
on
whether,
like
you
know,
you
want
to
go
deeper,
maybe
inside
the
different
EIP
about
actually
rejecting
transactions.
That
don't
have
that
number
at
some
point,
so
we
don't
run
into
the
situation,
but
there's
there's
so
many
ways
to
jump
down
the
rabbit
hole
on
this
one
I
think
just
you
know,
considering
it
a
number
that
is
provided
by
not
I.
E
Guess
the
last
clarification
there
was
some
discussion.
What
would
happen
if
there
is
no
chain
ID
in
the
transaction,
then
there
were
different
proposals
that
you
know
it.
What
what
would
be
the
value
returned,
but
all
of
these
issues
are
a
non-issue
if
the
value
comes
from
the
client
and
not
from
the
transaction.
That
is
correct.
Yes,.
E
A
A
The
agenda
so
on
github
and
so
1283
was
the
one
around
that
gas
metering
for
s
store
that
got
removed
from
Constantinople.
Then
1706
was
the
fix,
the
first
Ambo
and
then
on.
The
last
call
I
believe
why
I
had
proposed
EEP
2200,
but
that
might
still
be
a
PR
and
not
a
proper
EP
yet
which
was
basically
a
combination
of
both.
A
D
Think
I
guess
one
go
ahead.
One
one
thing
that
I
would
ask
is:
does
anyone
oppose
but
I
mean
accepting
some
variation
of
this
thing,
because
from
my
perspective,
the
thing
that
we
have
to
decide
is
whether
we
want
to
implement
this
feature
and
I.
Think
if
we
accept,
if
we
do
want
to
implement
this
feature
and
probably
kind
developers
will
start
hacking
on
it
and
there
will
be
minor
tweaks,
but,
to
be
honest,
probably
the
three
EITS
are
more
or
less
the
same
thing.
So
technical
variations
aside.
A
A
F
This
is
less
than
2300,
then
it
basically
fails
so,
which
is
basically
something
explicitly
depending
on
gas
left
and
I.
Think
there
was
a
bit
of
problem
with
that,
so
it
might
actually
preclude
certain
optimizations.
That's
what
I
understood
from
Farrell
and
so
I
was
suggesting
to
make
to
restructure
it
in
a
different
way
basic.
Is
he
charge?
F
Man
didn't
make
a
mandatory
charge
of
2300
in
the
beginning
of
the
opcode
so
that
it
doesn't
have
a
branching
on
the
gas,
the
remaining
gas
and
then
adjust
all
the
other
bits
to
refund
a
bit
more,
and
somebody
pointed
out
that
it's
it's
not
equivalent
because
because
of
the
refund
limit,
because
their
funds
are
limited
to
the
half
of
the
of
the
spent
gas
and
things
like
this
so
yeah
I,
don't
know
where
that
conversation
went
I.
Don't
really
have
a
strong
preferences
either
way.
But
just
that
was
my
suggestion.
A
So,
to
come
back
to
Peter's
point
around,
do
we
want
this
feature
and
can
people
just
hack
on
it?
You
know
that
get
to
something
given
that
we're
supposed
to
hard
fork
the
test
nets
on
I
think
it
was
August
14.
So
this
is
like
two
and
a
half
three
weeks
from
now.
Do
we
feel
there's
sufficient
time
to
resolve
those
issues.
D
A
Yeah
and
to
be
clear,
I
took
this
number
from
the
original
roadmap
we
had
first
amble,
so
I
think
August
14th
was
was
date
and
then
the
next
and
then
the
upgrade
was
supposed
to
be
right
after
Def
Con
I
I
don't
have
to
date
handy,
but
it
was
something
like
October
16th,
and
that
was
a
point
farther
down
the
agenda,
but
obviously
yeah
it
does
have
an
impact.
If
we
have
like
the
amount
of
time
we
have
to
to
implement
these
changes.
D
D
D
G
D
So
this
it
is
relatively
simple:
I
mean
I,
haven't
looked
into
the
technical
details,
but
the
previous
one
that
was
cancelled
in
the
end.
It's
it's
not
a
hard
G
I
P
to
code,
so
it's
maybe
50
lines
of
code.
So
I
don't
see
any
particular
issue
of
excluding
this.
Just
because
of
timing,
concerns
and
I.
Think
it's
a
it's
a
useful
feature.
So,
unless
there's
a
technical
reason
to
do
not
accept
it,
I
think
we
should
go
forward
with
some
variation
of
this.
E
We
still
talking
about
1283,
yes,
so
I
think
1283
is
implemented
in
most
of
the
clients,
but
last
call
we.
We
said
that
it
should
go
together
with
1706,
which
is
the
the
extra
check
for
for
the
course
with
the
stipend.
Only
I,
don't
think
that's
implemented
anywhere,
but
that's
where
Pavel
brought
up
his
other
option,
which
would
introduce
kind
of
a
new
semi
static
mode.
E
D
E
E
G
A
D
So,
just
just
to
react:
I
I
mean
I,
haven't
seen
this
semi
static
thing
up
until
now
or
I
somehow
missed
it,
but
personally
I
don't
really
like
the
idea
of
introducing
yet
another
internal
state
to
the
EVM
that
tracks
whatever
I
mean.
From
my
perspective,
it's
going
we're
going
to
shoot
ourselves
in
the
foot
eventually
with
the
more
these
behavioral
subtleties
we
introduced.
So
if
there's
an
alternative
that
can
work
around
not
having
these
special
cases,
then
I
would
go
with
that.
G
G
D
F
My
comment
on
the
the
versioning
IP
or
whatever,
whatever
number
was
I
sort
of
remember.
Originally,
the
reason
why
it
came
up.
There
was
two
reasons
why
it
came
up.
First
of
all,
was
the
IPO
615,
which
was
the
static
jump
and
other
and
other
extensions
to
the
EVM,
which
has
now
been
withdrawn,
and
so
and
then
another
reason
for
that
was
the
potential
introduction
and
she
was
mentioned
into
the
the
serum
10.0,
which
is
now
also
not
very
so
very
uncertain,
probably
not
gonna
happen.
F
G
So
that's
the
discussion
I
want
to
have
after
we
get
it
some
resolution
today.
Pisa
was
the
number
two
on
the
discussion
and
I
kind
of
agree.
If
we
don't
have
615
or
EVM,
do
any
versioning
now
or
do
we
bring
it
in
dad,
but
do
we
want
a
table
1283
and
discuss
versioning,
or
do
we
want
to
get
resolution
on
1283?
First.
D
Just
wanted
to
say
that
if
there
is
a
version
of
topic
III
that
that
can
solve
all
the
issues
for
all
the
counts
and
doesn't
require
versioning
and
doesn't
require
behavioral
changes
to
the
AVM
I
mean
adding
extra
subtle,
EVM
modes,
then
I
would
just
go
with
that
and
problem
soft
self-contained.
The
IP
done
I.
F
D
A
So
I
think
at
the
very
least,
it
makes
sense
to
use
2200
as
this
sort
of
going
forward
point
for
discussions
on
this.
So
at
last
week's
call
I
think
we
were
so
spread
out
across
all
these
different
oops.
Does
it
make?
Do
we
want
to
say
2200
is
accepted,
or
do
we
still
need
to
flesh
out
those
technical
details
before
we're
comfortable
accepting
it.
A
D
A
D
Well,
I
guess
it's
just
a
question:
I
think
the
the
hard
part
in
Cracow
is
actually
implementing
it,
but
as
but
as
far
as
I
know,
more
or
less
every
client
already
has
implemented
it.
So
I
guess
the
discussion
is
whether
we
go
ahead
with
it
or
not,
and
that
probably
depends
on
on
the
result
of
the
audit.
G
Right
and
I,
don't
think
you
got
it's
gonna
come
back
without
remediation
recommendations.
I
do
have
a
concern
about
the
hash
rate,
changing
at
the
fork
block
and
a
potential
change
stalling
issue,
and
that's
something
that
they're
looking
at
and
I
think
the
timing
that
the
auditors
coming
back
I,
don't
think
we'll
have
enough
time
to
fully
digest
or
mediate
it
before.
G
We
need
to
decide,
go
no
go
for
a
test,
then,
according
to
the
original
schedule,
the
test
that
should
have
been
launched
the
attest
that
putting
the
easiest
amel
changes
should
been
launched
by
the
time
the
audit
comes
back.
So,
for
those
reasons,
I
am
not
comfortable
putting
it
in
Istanbul
I'd.
Much
rather
see
something
like
this,
either
in
the
next
fort
in
April
or
on
its
own
work
independently.
If
either
developer
support,
it.
D
C
D
G
D
Well,
my
question
is
that
previously,
after
I
think
after
the
Byzantium
art
for
book,
I,
don't
know
which
I
know,
of
course
a
temple.
So
that's
where
we
have
issues
so
I
had
the
suggestion
that
instead
of
heart,
instead
of
working
off
the
test
that
what
we
could
do
is
create
the
so-called
shadow
fork
where
we,
when
we
essentially
create,
we
don't
upgrade
the
test
at.
Rather,
we
just
create
a
side
chain
for
the
test
that
so
we
still
propagate
the
same
transactions.
We
just
start
executing
with
a
new
rule
engine.
D
This
wouldn't
be
what
I
won't
say
that
it
wouldn't
be
public,
it
would
be
public,
but
clients
who
don't
buy
before
switch
over
to
it.
Rather
they
could
have
a
special
flag
that
says
play
around
with
this,
whatever
test
nut,
and
then
you
have
the
feedback
that
you
can
see.
If
the
clients
agree
between
each
other,
you
can
you
can
test
everything,
but
it's
it's
not
live
yet
officially,
so
the
chain
this
chain
would
be
discarded
anyway
for
could
be
discarded,
but
I,
don't
know
a
I.
H
And
we
also
haven't
for
the
test
nets,
yet
so
I,
don't
I
I
mean
I,
agree
with
Peter
that
we
should
continue,
as
the
cortes
have
already
said,
which
is
accepted
pending
on
the
audit.
Given
that
technically
pulling
it
out,
isn't
that
big
of
a
thing
then
I
don't
think
we
need
to
say
hey,
let's
stop
it
today
when
there
actually
isn't
anything
running
to
you
and
stop
it
from
being
in.
G
A
F
Can
summarize
what
has
been
done
since
last
week,
the
discussion
on
the
call
and
in
forums
we
integrated
the
suppose,
Faust
client
into
gas?
Now
it
compiles
seamlessly
so
tourists
have
a
choice:
whether
they
want
to
use
rust
with
some
additional
compiling
compilation
or
just
use
the
C++
version
just
make
it.
Then
we
have
wrong.
F
We
started
the
fuzzy
testing
and
running
for
six
days
already
now
with
32
core,
so
it's
like
over
over
a
half
a
year
as
a
testing
running
with
12
million
operations
per
hour,
and
we
indeed
found
four
cases
where
the
clients
mismatched
it
was
due
to
the
last
version,
not
following
the
input
specification,
precisely
which
was
corrected.
No
problems
in
the
arithmetics
itself
were
found,
and
finally,
we
have
implemented
the
Daniel
library
for
conveniently
calling
the
EAP,
which
is
what
you
just
referred
to.
You
can
take
a
look
at
the
examples
there.
F
It's
just
if
you
want
stuff
go
to
call
the
function.
We
have
some
further
questions
from
the
community
which
we
we
need
to
get
answers
to
understand
what,
but
what's
decided
to
do
so.
There
is
a
concern
that
we
should
have
multiple
separate
addresses
for
this
precompile.
We
would
like
to
understand
what's
to
take
some
decision
on
this,
and
we
can
do
either
version.
It's
it's
up.
It's
very
easy
to
adopt.
F
At
the
moment
the
library
hides
all
the
complexity
of
having
the
first
byte
determining
the
operation,
but
if,
if
you
guys
decide
that
it's
better
to
have
separate
errors
as
we
can
easily
sweetens,
this
is
the
first
question.
Second
question
is:
is
the
current
pace
of
fuzzy
testing
enough
or
do
we
need
to
increase,
add
more
hardware
to
support
more
than
32
parallel
processes
so
that
we
can
we
get
two
years
of
CPI
CPU
time
in
testing
and
yeah?
The
guest
metering
is
in
progress,
so
we
have
the
gues
metering
functions.
Are
there?
F
We
just
need
to
get
the
proper
constants
and
we
want
to
collect
more
data
for
this,
and
then
we
will
proceed
to
the
state
tests
and
implement
the
tests,
which
can
be
run
by
every
client
consistently,
and
there
was
a
concern
about
the
specification
we
wanted
to
prepare
it
for
this
call,
but
unfortunately,
Alex
who's
in
charge
compiled
got
sick,
so
he
needs
a
few
more
days
to
recover.
Then
we'll
all
do
the
the
second
part.
F
We
just
need
to
put
the
formulas
there
and
put
a
gas
meter
in
constants
in
place,
and
then
everybody
can
follow
the
instructions
and
implement
this
recompile
directly
from
the
specs.
It's
a
very
straightforward
process.
It
took
us
just
one
week
to
implement
the
C++
version,
so
I
don't
expect
much
difficulty.
We
are
still
happy
to
assist
in
anybody
so
yeah
to
do
to
come.
To
recap
the
questions
we.
D
F
I
think
the
main
reason
was
the
usability
of
calling
the
it's
more
natural
to
call
different,
become
files
for
different
operations,
although
they
are
doing
their
reasons
in
code
under
the
code.
I
think
this
is
addressed
by
the
library,
because
the
library
makes
it
very
easy
to
call
any
elliptic
curve
any
any
operation.
It
backs
all
the
parameters
together
with
nice
typing
with
every
entity
like
the
point
or
a
point
there
having
separate
structure.
So
I
think
this
is
addressed
by
this.
But
if
anybody
disagrees,
we
can
switch
to
also.
G
Having
different
addresses
so
I've
been
asking
for
the
four
addresses.
One
of
my
big
concerns
is
we
have
to
read
the
byte
stream
and
interpret
the
first
byte
and
based
on
that
branch
on
four
different
functions
for
the
gas
calculation,
if
we're
doing
four
separate,
not
just
constants
but
I
mean
straight-up
different
formulas
for
calculating
the
gas.
This
sounds
like
something
that
should
be
split
up
into
at
least
four
and
because
there's
a
g2
g3
separation
of
seven
methods
to
calculate
the
gas.
G
So
we
don't
have
to
basically
run
the
library
program
to
calculate
the
gas.
If
we
keep
the
gas
function,
where
there's
you
know,
the
seven
main
branches
get
seven
main
functions.
The
second
thing
this
also
matches
the
design
pattern
of
what
went
on
with
the
EC
with
the
RPM
128
functions.
There's
a
pad
I
multiply
and
a
pairing
check
this
one.
This
in
this
library
adds
an
exponentiation
step,
and
it's
also
for
G
1
and
G
2,
so
I
also
follow
what
we've
been
doing
with
our
other
pre-compiled
were
there.
G
There
is
basically
one
function
and
not
one
giant
sumption
hiding
seven
different
functions,
but
for
a
different
gas
calculation
formulas,
I
think,
would
be
a
better
reflection
of
the
true
complexity
of
what's
going
on
here,
I
think
parameter
rising.
The
particular
curves
is
fine,
but
I
think
the
operation
should
be
should
match
existing
pattern.
We
have
without
I,
actually.
F
Now
I
just
thought
about
it.
I
also
think
that,
from
the
point
of
view
of
the
I
mean
I
know
a
lot
of
people
read
the
read
the
bytecode
and
when
you
read
the
bytecode
and
you
see
the
pre-compiled
cost,
usually
that
basically,
you
put
the
address
of
the
caller
of
the
of
the
pre-compiled
onto
the
stack
and
you
do
another
six
things
in
a
stack
and
I
need
you
the
call,
and
usually
you
know
if
you
know
what
you're
calling
you
can
actually
see
from
the
bytecode
that
what
you're
actually
pulling.
F
However,
if
you
encode
the
function
as
the
first
byte
of
the
parameter,
then
it
actually
ends
up
in
memory
somewhere,
and
it
might
not
be
obvious
where
okay,
so
I
guess
from
the
EVM
byte
code
readable,
it
will
be
easier
to
identify
which
pre-compile
you're
calling
and
it
might
not
also
be
easier
from
a
static
analysis
point
of
view,
but
as
I
said
that
not
many
people
read
the
bytecode,
sometimes
I
do
so,
but
okay,
so
we
can
switch
to
this.
Does
anybody
disagree
with
switching
to
two
having
separate
addresses
for
the
operations.
F
F
So
if,
if
everybody's
sound
I
assume,
we
can
continue
for
like
this
for
now
I'm
like,
if,
if
somebody
has
a
concern
that
this
is
not
enough,
please
just
post
it
to
the
forum
or
the
chat,
and
then
we
can
increase.
In
my
opinion,
32
is
fine,
because
we're
gonna
run
it
for
several
month
and
it's
gonna,
be
over
all
years
of
CPU
run
time,
which,
with
12
million
operations
%
very
per
hours,
would
be
fine.
F
F
So
the
question
is
whether
whether
anybody
wants
to
it
at
all,
because
the
formulas
are
just
direct
like
it's
purely
functional,
there
is
no
state.
The
complexity
is
actually
much
lower
than
lower
complexity
functions
with
state
by
orders
of
magnitudes.
It's
people
can
just
use
what
we
have
with
a
choice
of
rust
or
C++.
F
F
F
The
end
of
a
six
is
like
1/2
years
right
so,
and
this
is
the
final
one
we
want
meet
any
update
on
this
until
we
have
a
like
fully
flexible,
wasn't
implementation
because
it
covers
all
the
cases.
People
who
want
to
do
anything
with
elliptic
curves
will
be
able
to
do
it.
If
we
find
a
new
curve,
people
can
use
it
and
so
on.
So
if
we
want
this
at
all
in
theorem
ever
we
should
just
define
criteria
and
say:
okay
when
this
is
fulfilled,
and
we
can
include
it.
F
If
we
don't
define
the
criteria
now,
then
I
mean
if
if
the
criteria
is
never
going
to
be
fulfilled
and
it
will
never
make
it
into
the
etherium
and
it's
gonna
be
a
pity,
because
people
really
know
this,
if
you
can
define
criteria
now,
then
we
can
see.
Okay
can
we
can
we
fulfill
them
by
for
this
hard
work?
So.
G
There's
a
criteria
that
beacon
chain
is
using
for
their
launch
and
that
is
to
independent
author
representations.
Folio
the
compatible
to
be
you
can
chain
so
I
think
that's
one
criteria
that
should
be
added
is
that
there
should
be
an
implementation
independently,
I'm
willing
to
do
that,
but
I
agree
with
Peter
the
deadline.
If
we're
gonna
fork,
pretty
schedule
is
where
the
risk
is.
I
mean
that
yeah
keys
are
supposed
to
be
finished
in
may,
not
continue
to
be
had
to
go
through
halfway
through
July.
G
F
Well,
you
know,
I
would
say
this
so
basically
after
this
process
of
weeding
out
and
I'm,
pretty
sure
that
most
of
the
IP
is
now
gonna
be
dropped
out.
And
if
we
say
that
this
is,
if
we're
going
to
stick
to
the
schedule,
then
it
looks
like,
for
example,
this
AIP
might
not
make
it.
Okay,
that's
fine,
but
we
basically
going
to
end
up
with
maybe
like
three
or
four
very
simply
a
piece
to
implement
and
that's
fine.
If
we
want
to
do
that
so
just
to
keep
up
to
the
schedule.
F
But
that
also
means
that
if
these
things
are
pretty
simple,
then
I
would
also
propose
that
to
do
another
upgrade,
maybe
shortly
after
that,
one
with
the
more
substantial
features,
because
basically
the
Easton
bow
is
going
to
be
pretty
much
chain,
ID
the
little
bit
of
gas
reduction
and
what's
something
else
that
was,
it
was
a
thing.
So
there
will
be
like
three
things
right
so
but
firm
for
me
now
that
the
the
one
that
this
precompile
is
actually
one
of
the
main
features
of
the
next
oh
of
the
next
function.
F
D
Yeah
so
I
kind
of
agree
there
that
just
for
the
net
gas
metering
and
414
ID
I
don't
see
a
reason
to
hard
fork,
because
it's
just
a
huge
coordination
and
I
mean
I,
don't
see
the
value
of
it.
But,
from
my
perspective,
I'm
perfectly
fine.
If
we
decide
that
we
want
to
have
I,
don't
know
profile
and
this
one
in
and
we're
going
to
push
the
fork
up
until
the
point
where
these
two
get
in
I.
Think
that,
from
my
perspective,
that
is
acceptable.
A
So
there
was
only
a
single,
more
EEP
that
someone
wanted
to
discuss,
which
was
1884
and
I.
Think
Alex.
You
asked
if
Martin
had
thoughts
on
that
and
he's
not
on
the
call,
so
it
might
make
sense
to
just
move
to
the
scheduled
discussion
now,
because
we've
been
kind
of
hinting
at
it
across
every
single
deep.
Does
that
make
sense.
F
D
F
D
G
Agree
with
that,
that
was
one
of
the
things
that's
on
the
agenda
right
before
the
schedule.
I
think
is
which
IP
is
going.
The
new
b1
free
account
versioning,
which
ones
don't
and
you're
right.
It
was
brought
in
for
615.
It
was
brought
in
for
you
watch
them
and
since
those
have
been
pushed
strongly
out
of
Istanbul,
the
authors
are
like
giving
up
on
it
because
of
funding
of
political
issues,
but
I
still
think
they're
valuable
and
I
particularly,
can
want
to
come
back.
G
B
I
I
The
conversion
in
testing,
because
that
would
be
really
I
mean
they
will
provide
a
stable
ground
because
there
are
other
use
depending
on
that,
for
example,
Citroen
the
IPS
and
also
if
we
want
to
like
do
some
other
stuff,
like
I,
also
have
some
other
yeah
ideas
that
have
yuppies
depending
on
a
conversion
in.
So
if
we
have
a
really
stable
ground
for
house
yeah,
curry
works
I
think
we
could
sing
so.
F
Wait:
I
don't
think
that
the
straight
versioning
sorry
state
ran
the
IP
is
actually
dependent
account
versioning.
They
actually
can't
the
the
the
snake
conflict.
Some
of
it
were
conflicting
with
it
so
which
means
that
they
are
basically
have
to
be
seasick
kind
of
made
in
sequence,
sort
of
way,
but
they're
not
depending
on
account
versioning.
I
D
Concern
against
against
this,
basically,
with
the
account
versioning
is
that
that
seems
like
an
abstraction
that
we
want
to
ask
so
that
later
we
can
be
a
stuff
on
top
of
it,
but
you
don't
have
yet
the
stuff
that
we
want
to
build
on
top
of
it,
and
my
concern
is
that
you're
going
to
shoot
ourselves
in
the
foot
by
deploying
an
account
versioning
that
later
may
turn
out
to
be
not
perfectly
suitable
for
whatever
use
cases.
That's
why
I
personally
would
say
that
account.
I
So
is
it
would
be
like
a
lot
easier
for
other
features
to
appear.
Appearance
have
a
conversion
in
like
like
if,
if,
if
we
only
like,
if,
if
we
don't
include
it
in
testing,
is
kind
of
like
because
it's
a
big
feature
like
it
kind
of
like
pushed
into
the
future,
and
then
those
features
depending
on
reversing
will
be
like
quite
hard.
I
F
Think
way,
I
bought
another
suggestion
on
this
line
and
then
also
I've
put
it
an
agenda
too.
You
know
two
times
in
a
row
for
the
meetings,
but
we
never
managed
to
get
to
it.
So
it's
called
the
pre-emptive
refactoring,
but
yeah
so
I
understand
what
you're
talking
about.
But
maybe,
if
we
get
to
this
point,
we
can
discuss
there.
A
Yeah
these
Pascal's,
we
haven't
gotten
through
a
lot
on
the
agenda,
so
in
that
spirit,
maybe
just
to
bring
back
the
conversation
around
the
roadmap
I
wish
we
wanted
to
discuss.
It
seems
there's
like
three
big
things
that
might
benefit
from
extra
time
on
the
road
map
so
1962,
which
we
just
discussed
Prague
pal,
because
the
audit
will
be
due
late,
August,
so
realistically,
mid
September.
You
know
everyone
will
have
wrap
their
heads
around
the
audit
and
then
the
third
one
I
know
LXi
we've
discussed
Europe's
and
you've
mentioned
before
that.
A
You
know
you
might
not
be
ready
for
the
actual
estate
of
all
deadlines.
So
I
guess
there's
two
sides
to
this.
One
is
how
much
extra
time
would
we
need
if
we
wanted
to
take
on
these
more
ambitious
changes
and,
second,
how
do
we
make
sure
that
if
we
extend
that
the
deadlines
were
not
in
the
same
position?
Two
months
from
now,
because
we
got
sort
of
an
whole
other
barrage
of
EPA
to
go
through.
G
If
we
delay,
we
don't
accept
any
more
ease
if
you're
not
on
the
list
to
come
on,
I,
don't
think
we
should
allow
any
more
open
calls
for
keeps
that's
gonna,
be
the
next
time
in
the
community.
Open
call
happens,
my
thought
is:
we
have
to
realistic
options
as
to
the
delay
one
month
or
two
delayed
three
months,
because
we
don't
want
to
be
trying
to
do
the
hard
work
over
Christmas.
That's
not
an
ideal
situation
or.
F
To
that
timeline
we
had
and
then
see,
because
it's
again
I
mean
this
is
the
another
experiment
to
we're
trying
to
do
here,
and
maybe
we
can
do
the
another
heart
for
up
shortly
after
that,
because
we
discussed
in
the
past
that
we
kind
of
want
it
to
be
I
mean
a
lot
of
people
wanted
to
make
it
the
hard
works
which
are
more
meaningful,
but
also
potentially
as
soon
as
something
is
ready
and
then
the
high
quality
and
is
really
in
demand.
Why
not
put
it
in.
A
So
you
would
have-
or
maybe
it
could
be
later
than
April,
but
basically
that
we'd
have
Istanbul
as
on
schedule,
whatever
it
was
too
big
for
Istanbul
in
another
hard
fork
shortly
after
and
then
a
bit
after
that
to
have
another
hard
fork.
That's
you
know
open
for
new
EEP
submissions,
which
would
basically
happen
in
parallel
to
this
Istanbul
plus
hard
fork.
I
Does
it
does
I
mean
we
have
a
hard
fork
coming
up
after
like
a
plan
after
some
board?
That
is
only
like
two
or
three
months
after
east
on
board,
so
like
I,
think
guys
fight
a
short
time
and
I
just
worry
that
we
don't
have
enough
time
to
like,
because
some
release
can
means
some
class
may
need
like
a
balancing
and
bounds
for
the
release.
And
then
we
still
need
a
lot
of
time
in
firm
the
community
and
to
gather
the
miners
exchangers
on
the
same
page.
D
The
idea
was
that
that,
for
example,
we
can
take
a
list
that
we
currently
have
and
shut
you
and
make
it
into
two
hard
Forks.
Essentially
everything.
That's
that's
simple,
and
that
can
be
finished
really
fast,
and
essentially
we
have
everything.
That's
accepted
up
until
now
goes
into
that
category
that
one
can
probably
be
implemented
fast,
and
then
we
can
get
this
studies
whole
procedure
of
testing
it
and
rolling
it
out,
etc.
But
concurrently,
we
can
already
start
working
on
on
the
second
part
of
that
list
and
say
proc
pal
or
the
crypto
stuff.
D
The
advantage
of
this
approach,
where
we
have
this
Istanbul
is
the
open
PR,
where
anyone
could
suggest
anything,
and
then
we
have
this
follow
up
PR,
which
is
just
hand-picked
heavy
modifications
where
the
teams
can
actually
focus
on
on
those
two
or
three
IPS
which
are
really
happy,
and
it's
not
opened
up
to
the
public
and
in
the
meantime,
yes,
concurrently,
we
can
already
start
planning
for
the
next
public
thing
to
get
extra
stuff
in
so
I
guess
we
can
do
do
these
Forks
on
two
threads.
That
was
the
suggestion.
G
A
A
So
does
anyone
disagree
with
this
from
a
schedule
perspective
to
break
a
stand?
All
out
into
two
parts?
Have
our
agreed-upon
schedule,
which
implies.
We
fork
a
test
net
in
two
weeks
or
three
weeks
time,
and
then
we
have.
The
extra
well
obviously
need
some
dates
for
the
extra
Forks,
but
the
main
net
upgrades
would
happen
in
January
and
July.
D
So
I'm
still
convinced
that
you
cannot
for
this
test,
not
in
two
weeks
time:
okay,
because
there
are
AI
PS
to
be
implemented,
those
need
to
be
implemented
just
need
to
be
somewhat
tested,
because
people
still
rely
on
the
test
nut,
so
you
can't
just
blow
it
up
and
after
it's
implemented
and
semi
tested
or
it
seems
to
be
solid,
but
then
clients
need
to
do
the
releases.
People
need
to
upgrade
to
that.
That's
not
people,
otherwise,
the
test.
That's
going
to
fall
apart
and
become
unusable.
D
You
need
I,
would
say
after
everything
all
the
IDS
are
implemented,
they
seem
to
be
working.
Okay,
cross,
client,
minitest
that
also
work
at
that
point.
If
clients
with
the
release,
I
would
say
you
still
need
two
weeks
to
convince
people
to
operate
and
I
think
shorter
is
not
really
realistic.
It's
just
going
to
be
chaos.
I
D
A
I
F
A
A
D
Yeah
so,
for
example,
I
would
I
think
sort
of
thing.
If
you
want
to
really
really
push
Istanbul
and
I
would
say
if
we
pick
late,
August,
ID
on
and
the
harvest
beginning
of
September
I,
don't
know
1st
of
September
in
a
Saturday
as
the
as
the
hard
fork
for
for
Istanbul
for
the
test
pass
co-op
stone
then,
depending
on
the
eyepiece,
if
the
Yankees
are
implementable
within
one
or
two
weeks,
and
that's
realistic,
that
weekend
will
release
within
two
weeks
and
I.
A
Would
it
make
sense
to
agree
to
that
for
Istanbul
test
net
then
keep
what
we
had
was
I
believe
October
16th
as
Istanbul
main
net
and
and
I
I.
Don't
know
what
the
next
work
looks
like,
but
maybe
sleep
in
our
back
pocket.
The
idea
around
potentially
having
your
January
/
February,
far
work
along
with
one
later
in
2020,
where
we
accept
new
eeap's.
Does
that
make
sense.
D
G
There's
a
meta
discussion,
I
think
as
to
how
we
want
to
handle
our
network
kind
of
creative
works
going
forward.
Do
we
want
regular,
predictable
force
or
do
we
want
to
have
Forks
where
we
get
that
you
know
what
we
think
the
demand
is.
Are
we
gonna
fix
the
date
or
are
we
going
to
fix
the
features
the
advantage
of
fixing
the
date
is?
We
can
do
them
more
regularly?
We
can
do
them
twice
two
three
times
a
year,
but
the
downside
is.
G
I
I
And
implementing
whatever
features
when
they
are
ready
and
then
they
deployed
to
exchangers
and
miners,
and
then
the
heart
fur
can
be
automatically
logged
in
whenever
enough
of
the
network
have
already
upgraded
their
chant
version.
So
so,
in
our
case,
you
will
be
raised
of
like
more
convenient
for
you.
G
A
So
because
there's
I
guess
clearly
a
lot
of
discussion
to
be
have
and
that
we
have
another
call
next
week
and
that
a
lot
of
people
are
not
on
this
call.
It
might
be
worth
punting
the
discussion
around
the
schedule
to
the
next
call,
but
perhaps
just
agreeing
to
move
the
test
net
date
for
Istanbul,
because
no
matter
what
we
will
have
to
do
that.
So
would
anyone
disagree
with
just
moving
the
test
net
date
to
Istanbul
and
at
to
September
4th
sorry
and
then
having
your
follow-up
conversation
around
the
hard
fork
schedule.
D
So
I
think
I
do
and
good
people
good
way
forward
if
we,
so.
The
problem
is
that
if
we
just
say
that
ok,
let's
discuss
it
next
week,
then
we're
going
to
be
in
exact
same
position
next
week,
just
before
movie
costs.
So
my,
in
my
opinion,
the
hard
work
in
the
festival
in
two
weeks.
It's
not
going
to
happen,
so
we
need
to
push
that.
D
A
H
H
D
But
we
do
have
I
think
it
was
a
list
of
five
VIPs.
That
seems
that
we
will
surely
accept
and
they
were
done
of
two
more
EITS.
That
would
be
really
awesome
to
have,
but
they
either
might
require
some
extra
input.
Auditors
or
they
might
require
some
extra
work.
That's
what
long
time
but
I
think
you
should
have
this
witness
that
unless
somebody
starts
yelling
really
really
loudly.
That's
what
we're
going
to
go
so.
A
Looking
at
the
PR
you
put
up
James
and,
and
my
notes
from
this
call
that
just
happened
right
now,
what
seems
to
be
the
list
of
stuff
that's
going
in
and
has
been
accepted,
is
1108
1702,
twenty
twenty
four
twenty
twenty
eight
and
then
thirty
thirteen
forty-four
was
added
on
this
call
and
then
on
this
call,
the
ones
that
are
seem
to
be
tentatively
accepted,
ie,
start
working
on
them
and
will
figure
out
if
we
can
put
them
in
seem
to
be
twenty.
Two
hundred
nineteen
sixty-two
Prague
pal,
which
I
forget.
D
A
H
A
H
A
G
I
Manet
at
this
moment,
but
I
still
want
to
propose,
we
included
in
testing
the
earliest
possible
date
might
still
be.
The
first
Eastham
were
hard
for,
because
at
this
moment
we
have
three
plant
implementations,
draft
implementations,
which
I
just
think
it
would
be
really
good.
It
doesn't
affect
my
night,
but
I
think
this
is
a
really
cool
thing
to
have.
If
we
kind
food
it
in.
You
know
it's
time
for
testing.
G
I
D
I
Because
I
really
like
urge
anyone
who
still
thing
like
that
who
like
try
to
keep
some
more
comments,
I
reveal
something
yucky,
because,
like
I
really
hope
that
we
have
a
stable
foundation
for
like
the
current,
the
current
description
of
the
IP
Santiago
is
really
lecture
bare
minimum
like
absolute
bare
minimum.
You
need
to
implement
a
conversion
in
and
I
just
think
it
would
be
really
great
if
we
can
have
this
so
that
we
have
a
really
stable
foundation
about
whenever
we
need
a
conversion
in.
G
A
G
A
F
D
Yes,
so
this
is
I,
guess
Martin's
PID,
and
he
is
not
here.
I
can't
say
just
a
couple
words
of
it,
just
food
for
thought
for
next
week
the
ideas
that
Martin
did
a
lot
of
benchmarks
on.
Essentially
he
was
measuring
how
much
time
individual
opcodes
take
in
the
gut
implantation
compared
to
their
price,
and
then
he
picked
out
that
there
are
a
few
hot
codes
which,
compared
to
the
other
ones,
are
really
cheap
gas
wise,
but
they
computationally
more
than
the
others
rather
need
us.
D
Try
to
balance
it
out
so
that
one
guests
approximately
can
require
the
same
computing
resources,
whether
that's
subtraction
or
whether
that's
data
retrieval,
and
this
is
essentially
a
trivial
VIP.
So
unless
there's
something
somebody
has
a
reason
not
to
do
it,
I
think
we
could
do
it,
but
I
agree
that
let's
postpone.
A
E
A
A
11:08
was
the
first
one
which
is
reduced.
Alt
b
and
128
precompile
gas
cost
20
24
/
152
was
Blake
to
be
20.
28
is
called
a
de
gas
cost
reduction
and
13
44
is
the
chain
ID
up
code.
The
one
that
was
contentious
is
1702,
the
account
versioning.
So
we're
not
sure
where
that
one
fits
it's
currently
it
accepted,
but
might
move
to
the
other
side
or
might
get
dropped.
So
we
still
need
to
have
that
conversation.
On
the
tentatively
accepted
side.
A
A
D
D
E
Have
two
comments,
probably
as
agenda
items
for
the
next
call
for
this
list?
The
first
one
is
for
Blake
to
probably
two
weeks
ago
there
was
an
issue
raised
by
one
of
the
people
close
to
Blake,
to
I
believe
where
it's
you
cash
and
that
hasn't
been
addressed,
yet
so
I'm
not
sure
if
Blake
you're
gonna
be
finalized
within
the
time
frames.
E
So
probably
it
is
a
good
topic
to
discuss
next
call
and
the
other
question
I
have
is
regarding
the
1960
to
1962
states
that
it
depends
on
a
gas
cost
reduction
to
precompile,
because
some
of
the
ability
reasoning
is
that
some
of
the
operations
are
so
cheap
that
call
cast
itself.
It
would
be
bigger
than
the
the
cost
of
the
operation
and
it
would.
E
H
A
Okay-
and
I
think
one
important
thing
also
that
a
lot
of
people
have
have
mentioned-
we
want
to
discuss
and
still
have
never
gotten
to
you-
it's
just
like
conformance
testing
and
and
initiatives
around
retest,
that
and
stuff
like
that.
So
it
might
be
worth
having
that
discussion
on
the
on
the
next
callers
off.
B
Sorry
you
clarify,
if
this
week
or
next
week
is
the
last
opportunity
to
get
on
the
tentative
accepted
list.
Next,
Friday,
expert,
okay-
and
you
know,
there's
still
a
couple
lurking
that
even
if
they
don't
make
it
into
you,
know
in
October,
it'd
be
good
to
target
them
for
January,
and
it
wasn't
clear
if
the
target
for
January
would
only
come
from
the
tentatively
accepted
list
or
a
broader
list.
B
D
No
I
just
want
Stan
so
that
I
would
say
that
if
we,
if
we
go
down
the
path
of
doing
the
double
work,
I
mean
splitting
out
some
EITS
because
we
want
them
in,
but
they
are
too
heavy
or
they
need
a
bit
more
work.
Then
I
would
say
that
for
the
set
for
that
second
Fork,
whatever
is
not
on
this,
this
list
won't
make
it
for
that
list,
because
otherwise
we
just
end
up
in
the
same
situation
where
we
have
all
these
tiny
stuff
that
we
discussed
and
the
other
ones.
A
Agree
so
basically,
if
anything,
that's
already
been
proposed
for
Istanbul
that
has
not
been
accepted
or
tentatively
accepted.
Yet
for
next
Friday
is
the
last
deadline
to
potentially
be
included,
but
we're
not
looking
at
brand-new
oops
and
a
note
about
next
Friday's
call.
So
we
have
a
weird
rotation
schedule,
but
next
Friday's
call
will
be
at
10:00
p.m.
UTC,
which
is
middle
of
the
night
Americas
and
man
I.
Think
morning,
Europe
and
I
forget
where
for
Australia
so
it'll
be
10:00
p.m.
UTC
on
the
Thursday.
A
E
One
last
comment:
we
said
we
tentatively
accepted
1962,
which
is
the
easier
ethnic
and
that
states
that
it
supersedes
1829,
which
was
also
proposed
and
and
has
maybe
a
smaller
feature
set.
Can
we
just
agree
that
1829
is
rejected
because
we
said
the
1962,
which
is
the
superset
is,
is
tentatively
accepted.