►
From YouTube: Ethereum Core Devs Meeting #19 [6/30/17]
A
B
C
C
All
right,
I
think,
let
me
see
yeah,
we
have
enough
people
now
all
right.
We
can
get
started
good
morning,
everybody
or
wherever
it
is
in
the
world
for
you
for
the
agenda.
The
first
thing
is
metropolis
and
the
first
sub
item
is
Peter,
talking
about
a
I,
P,
86
or
208
transaction
abstraction
and
specifically
about
how
contract
addresses,
cannot
be
computed
without
a
live
blockchain
and
there's
no
guarantee
that
the
deployed
code
is
ours.
So
Peter
you
can
go
ahead.
C
B
Both
plane
account
I
sent
an
old
Dame
transaction
to
create
a
contract.
Then
the
address
of
that
contract
will
use
the
new
scheme
starting
from
an
office,
and
this
actually
has
quite
a
few
drawbacks.
One
of
the
drawbacks
is
that
this
new
contract
scheme
only
depends
on
the
unit
code,
so
the
currency
in
the
entire
ecosystem.
B
Out
there,
every
contract
is
based
on
some
form
of
the
owned
contract,
which
kind
of
just
takes
the
message,
sender
and
the
size
that
as
the
owner
now
since,
if
I'm,
for
example,
if
I'm
going
to
deploy
a
wallet,
that
means
that,
starting
from
metropolis,
if
I,
don't
specify
some
init
code,
that
explicitly
sets
me
as
the
owner.
Then
me
deploying
the
wallet
and
somebody
else
deploying
that
the
wallet
will
actually
result
in
the
same
address
same
contract
address
now,
of
course.
In
theory,
one
of
it
will
fail
for
one
of
us.
B
The
problematic
part
is
that,
for
example,
I
deploy
my
wallet.
It
succeeds,
then
the
malicious
miner
deploys
the
same
wallet
on
an
alternative
chain,
and
if
the
miner
gets
lucky-
and
there
is
a
reorg
happening,
then
that
would
actually
result
in
I'm
me
losing
ownership
of
that
address.
Now,
if
I'm
not
prepared
that
such
a
thing
can
happen
and
I
actually
might
end
up,
not
realizing
that
somebody
else
became
the
owner
of
the
same
contract
that
previously
I
was
rightfully
assigned
as
the
owner.
So
this
is
one
one
of
the
pramatta
quartz.
B
The
other
problematic
part
is
that
currently
there
is
a
lot
of
code
out
there
that
can
actually
calculate
contact
addresses
client-side.
For
example.
Our
repository
also
contains
a
code
generator
or
binding
generator,
which
has
a
deploy
function,
and
when
you
call
it,
it
will
immediately
tell
you
that
hey
this
will
be
the
address
of
the
deployed
contract
and
then
later
on.
You
can
eventually
pull
whether
some
contract
works,
whether
some
code
was
deployed
to
that
address,
or
not.
Now,
with
the
new
scheme,
that's
basically
not
possible
and
the
even
though
so.
B
The
problem
is
that
I'm
I
cannot
really
decide
if,
if
the
code
deployed,
there
is
actually
a
result
of
my
transaction
or
result
of
somebody
else's
transaction.
So
this
is,
and
I
cannot
actually
calculate
what
the
final
so
I
can
calculate
what
the
final
address
will
be
offline,
but
I
cannot
calculate
it.
I
cannot
you
for
sure
say
that
it
will
be
my
contract,
so
this
is
problematic
because
it's
going
to
break
every
single
client
out
there.
That
depends
on
such
logic
and,
furthermore,
I
had
one
more
problem.
B
Yes,
so
the
last
problem
was
that,
from
this
point
onward,
we
cannot
calculate
contract
addresses
without
having
access
to
the
blockchain,
because,
depending
on
whether
we're
in
metropolis
or
homestead,
the
contract
address
will
be
different,
and
this
is
again,
in
my
opinion,
problematic,
because
I
don't
think
any
client
code
out
there
that
does
contract
address
calculation
has
an
idea
of
what
the
blockchain
state
is.
Currently,
they
just
think
the
transaction
can
or
even
they
don't
you
don't
even
require
transaction.
You
just
need
an
account
and
announced
and
you
can
get
the
contract
address.
B
So
these
were
my
my
issues
that
I
see
with
with
swapping
out
the
contract,
deploy
address
for
for
old
plane
accounts
and
playing
deploy,
transactions
and
I
also
had
a
suggestion.
How
we
could
do
this
is
that
in
here
the
idea
would
be
that
if
the
sender
of
a
transaction
is
the
null
sender,
then
we
can
switch
the
new
scheme,
whatever
new
way.
Vip
figures
he
wants,
it
wants
to
be
generate
new
contract
addresses.
B
Even
if
metropolis
hits
every
code
out
there
and
that
exists
will
continue
to
function
properly,
because
the
only
the
only
account
that
will
actually
break
is
if
somebody
is
sending
from
a
no
sender,
but
to
do
that,
you
need
to
actually
send
from
Santa
new
abstract
transactions
without
without
the
sender
account,
and
to
do
that.
Basically,
then,
you
must
rely
on
the
init
code
because
there's
actually
there's
no
message:
sender
that
could
differentiate
the
owner.
B
Russia
but
I'm
guessing
that
eventually
will
be
retire
old
accounts.
Then
the
old
address
scheme
will
be
retired
at
the
same
time
because
you
won't
get
such
transactions.
So
it
just
answer
to
me
that
while
we
are
supporting
the
old
type
accounts
at
all
type
transactions,
it
makes
sense
to
keep
the
old
functionality,
as
is.
E
B
F
F
B
F
Well,
I
think
it's
well
it's
tied
in
anyway.
I
guess.
My
concern
is
that
we've
been
adequately
explored
the
consequences
of
breaking
a
couple
of
key
invariants
and
a
theory,
and
one
of
which
is
that
transaction
IDs
refer
to
and
using
zero
or
one
executions
of
the
transaction
and
one
of
which
is
that
addresses
that
have
code.
That
code
never
changes
except
to
be
deleted
and
I
I
worried
that
these
new
changes
will
have
a
big
impact
on
the
ecosystem,
particularly
the
one
about
transactions
between
having
multiple
executions.
E
E
I
B
B
And,
for
example,
if
if
a
minor,
Minds
transaction
that
essentially
reverse
now,
the
exchange
will
see
will
think
at
least
that
the
transaction
failed,
and
maybe
the
minor
will
add
it
half
an
hour
later.
And
if
the
exchange
doesn't
know
that
the
transaction
that
previously
was
failed,
could
actually
get
included
later
than
it
might
be.
Really
messy.
J
J
J
D
Here
one
real
one:
realistic
example
of
a
literal,
with
the
exact
same
transaction
being
executed
multiple
times
that
I
couldn't
see
happen
eventually,
as
if
there's
some
contract
that
triggers
the
alarm
clock.
So
let's
say
if
there
is
some
contract
that
basically
just
triggers
some
some
bounty
in
exchange
for
pinging
it
and
getting
it
to
do
your
stuff
and
then
the
party
that
would
most
efficiently
be
able
to
do
the
ping
is
basically
miners.
So
what
miners
would
do
is
they
would
just
include
a
dummy
transaction
with
no
signature.
D
E
D
I
know
that
in
G
in
general,
if
like
users
should
be
able
to
in
users,
should
be
able
to
insulate
themselves
from
the
possibility
in
a
lot
of
cases,
so
it
for
example.
If
you
have
a
regular
account,
then
none
of
your
transactions
will
have
multiple
canonical
executions.
And
so
what
could
happen
is
multiple
executions
of
a
transit
of
a
transaction
gets
sent
where
both
of
those
executions
lead
to
your
own
balance,
being
increased.
B
D
D
F
Think
it's
I
mean
the
thing.
The
main
thing
would
prevent
exchanges
from
adopting
more
sophisticated
ways
of
receiving
funds.
Is
that
most
wallets?
Don't
support
them
were
sorry
not
most,
but
a
significant
number
of
wallets
only
supports
in
India
transactions
and
historically
hasn't
done
a
very
good
job
at
seen
enough
gas
for
the
long
calls
to
execute,
and
of
course
they
don't
ones,
deploy
a
copy
of
the
contract
on
every
single
user,
a
trace
when
they
and
we've
done
this
try
and
seem
to
have,
and
then.
F
F
J
J
F
Don't
thank
you
well,
yeah
I.
Don't
think
you
necessarily
have
to
enforce
it.
They
have
good,
but
you
have
to
have
so
I
mean
you
need
you
don't
and
you
don't
necessarily
in
math
and
world
transactions,
but
it
means
you
need
something
like
a
nonce
or
a
hash
of
previous
transaction
or
some
other
field
that
can't.
D
Be
repeated
I
mean
the
other
thing
that
we,
the
other
approach,
is
to
try
to
resolve
this
at,
like
eventually
I
think
it'll
have
to
be
resolved
at
kind
of
higher
protocol
layers
at
some
point
so
like,
for
example,
ik
for
example.
Something
like
again
instead
of
just
providing
a
transaction
as
you
might
provide
a
transaction
hash
plus
what
number
in
transaction
index
or
something
similar,
though
like
I
mean
like
the
machinery
for
that,
would
take
a
would
take
longer.
But
it
does
seem
like
they're
sort
of
more
general
solutions,
but.
J
C
F
F
A
A
F
L
H
B
D
D
D
F
And
my
own
inclination
at
this
point
is
well.
It
may
be
possible
for
us
to
break
this
variant
of
our
transaction
IDs
in
the
future.
I,
don't
think
we
have
enough
time
tomorrow
before
metropolis,
to
consider
it
seriously
enough
to
make
sure
we're
not
going
to
break
things
and
I,
don't
think
the
community
places
like
exchanges,
Neath
the
scan
and
so
forth,
have
time
to
to
fix
their
assumptions
about
this
invariant.
D
C
D
I
D
What
one
question
without
up
with
that
approach,
though,
which
is
that,
if
let's
say
you
send
a
transaction
and
a
malicious
minor
in,
includes
all
right
know
that
never
mind
it,
but
if
you
send
the
transaction,
then
like
it
would
be
an
it
would
still
be.
It
will
become
invalid
to
do
things
like,
including
it
out
of
order.
Yes,.
D
Right,
yeah!
No,
so
this
this
definitely
is
a
concern.
So
what
miners
would
be
able
to
basically
include
m86
transactions
going
to
arbitrary
accounts
and
those
accounts
would
be
able
to
you
know
and
like
they'd,
be
able
just
like
arbitrarily
push
their
nonsense
up
in
that
way,
make
sure
it's
actually
would
require
people
to
resend
transactions.
C
C
C
All
right,
I
think
we
should
move
on
in
the
agenda
regardless.
Something,
though
I
think
as
we
go
on.
Let's
revisit
this
near
the
end,
so
that
if
anyone
else
has
any
further
comments
and
then
maybe
by
then
we
can
no
one's
gonna
have
a
full
solution,
I'm
sure,
but
we
can
still
move
on
from
here
and
then
come
back
to
it
to
say
what
we're
gonna
do
so
I
believe
that
goes
through
agenda
items.
1
&,
2
Peter.
Is
that
correct
that
cover
kind
of
all
your
comments?
C
Yeah
all
right!
Great
item?
Oh
well,
there's
a
second
two
in
the
agenda.
I'll
have
to
fix
that.
But
it's
the
EIP
86
so
same
a
I
P,
and
this
is
about
the
ECDSA
account
abstraction
and
transaction
origin.
I,
don't
think
Jeff's
in
here.
But
can
anyone
speak
for
any
progress?
That's
happened
on
that
discussion.
C
C
C
The
next
one
is
the
difficulty
bomb,
a
free
from
the
parody
team
and
Stack
Exchange
pointed
out
that
we
don't
have
an
EIP
for
the
difficulty
bomb.
So
does
anyone
have
a
recommendation
on
that
and
actually
before
even
that
happens,
can
anyone
answer
me
would
that
be
related
to
EIP
186
with
the
eath
issuance
or
is
this
gonna
be
a
separate
thing.
D
So
I
think
I
may
have
made
an
informal
proposal
at
some
point,
which
is
basically
that
we
substitute
in
the
formula
that
computes
the
difficulty
we
replaced
for
the
block
number
with
a
function.
That
says,
if,
if
premature
Oppel
is
takes
the
block
number.
If
post
Petropolis
take
the
block
number
like
two
million
or
two
and
a
half
million,
and
this
basically
like
just
cleanly
delays
the
thing
but
like
a
year
to
a
year
and
a
half
or
however
long
we
choose.
C
C
Mm-Hmm
cool
all
right,
any
other
comments
on
that.
Otherwise
we
will
get
a
PR
together
once
and
actually
you
have
the
Vitalik
if
you
could
summarize
that
either
just
in
a
comment
on
the
EIP
or
something
or
write
your
own
niar
for
it
that
I
write
a
comments
on
me:
I'd
be
649
exactly
or
or
open
a
PR
for
it.
I
didn't
know
if
a
free
was
going
to,
but
so
you
know
one
of
you
can
all.
C
C
K
K
E
I
can
show
him
in
on
that,
so
the
first
testing
is
basically
that
we
can
do
directed
passing
against
the
EBM
binaries,
which
or
there's
a
common
common
format
implemented
in
guest
and
parity
and
also
by
aetherium
without
house.
It
was
plus
yet,
and
this
test
will
be
a
lot
means
it
will
of
lighter
and
quicker,
and
then
the
existing,
as
processed
with
on
your
crafted
test
and
I'm,
hoping
that
Matthew
frontier
can
help
out
and
join
in
on
you
doing
this.
Setting
up
these
tests.
K
G
C
C
C
I
B
That's
best
for
us,
so
if
you
look
at
that
here,
it's
quite
a
massive
PR
from
Jeff,
and
so
it
began
reviewing
it.
It
turned
out
that
it's
a
bit
large
and
sing
up.
You
are
so
what
we're
mostly
splitting
it
up
into
smaller
pieces,
and
we
would
really
like
to
start
merging
in
the
individual
pieces
as
we
go
along.
So
basically
we'll
probably
speak
the
easier
PRS
which
probably
won't
change
I
mean
easier,
a
IPS
which
probably
won't
change
anymore
and
just
start
working
those
as
two
just
so
that
the
code
base
doesn't
diverge.
L
G
K
We
keep
the
new
test
in
the
develop
branch
of
the
testicle
story
in
form
of
general
state
test,
so
other
clients
call
running
tests
running
from
develop
and
there
are
any
changes.
So
you
could
ask
on
skype
that
channel
cosa
and
once
we've
been
updating
that
she'd
be
here
on.
We
also
update
the
test
and
you
could
see
if
you
have
any
changes
in
the
test.
Problems.
C
C
D
D
I
mean
it's
passing
all
pre
metropolis
tests
I've
also
used
it
to
implement
stuff
like
in
you
know
like
an
on
disk
state,
cache
and
state
tree
pruning,
and
that
seems
to
have
had
fairly
fairly
good
results.
And,
it's
surprisingly
not
that
complicated.
It's
I
mean
it
was
passing
a
lot
of
the
metropolis
s.
D
So,
though,
more
recently,
I've
kind
of
let
that
sweat
back
a
bit
on
that,
because
I'm,
basically
just
like
waiting
for
C++
to
her
for,
like
all
the
C++
tests
to
be
there,
so
I
can
just
try
it
against
all
of
them
all
at
once,
and
also
I.
Remember
that,
like
last
time,
I
checked,
there
were
a
few.
There
are
a
few
tests
that
I
ran
into
where
I
was
failing
and
when
I
dug
into
them.
D
D
Basically,
that
of
what's
a
new
conscience,
any
piece
of
contracts
go
it
in
place
and
a
like.
It
was
what
like
it
was
this
weird
it's
this
weird
edge
case
where
you
have
a
contract
with
code,
a
that
the
contract
suicides
and
then
the
something
else
with
code
via
gets
and
then,
if
both
of
those
operations
get
reverted
then
like.
What
should
happen?
Is
the
code
changes
from
B
to
a,
but
instead
of
change
in
C
bus
twice
it
changes
from
B
to
zero.
You
good.
C
All
right
cool,
so
the
next
thing
is
determining
gas
prices
for
new
opcodes
martin.
I
saw
you
were
starting
to
do
that.
I
think
someone
else
might
have
commented
on
that
to
our
Arkadiy
might
have
had
some
stuff
so
martin,
since
you've
been
talking
about
it,
the
most
I'll.
Let
you
take
it
away.
Yeah.
E
So
this
is
mainly
just
a
discussion
point
we've
started
getting.
We
have
some
benchmark
data
enough
for
go.
Ethereum
Arkadiy
reduce
some
similar
benchmarks
for
parity
I.
Think
someone
somewhere
generated
or
receive
a
key
and
kind
of
the
question
is:
how
do
we
move
on
and
actually
determine
the
gas
prices?
And
when
did
we
decide
on
that?
I
think
I
mean
it's
a
it's
an
implementation
details
for
the
client
developers
but
I
think
for
generating
the
test
cases.
It
would
be
good
if
that
could
be
kind
of
set
as
soon
as
possible.
C
As
far
as
organization
of
the
conversation
goes,
yeah,
basically
as
a
comment
and
the
EIP
might
be
okay,
as
long
as
we
stay
diligent
to
look
to
see
who's
agreeing
on
one
on
the
gas
prices,
is
there
any
others
so
Javon
for
something
like
this?
It
could
even
be
as
informal
as
just
being
in
the
core
devs
channel,
so
yeah
just
I,
don't
really
care
either.
One
would
work
for
me.
Does
anyone
have
a
preference
or
suggestion.
N
N
E
N
Okay,
so
I
made
a
comment
a
few
weeks
back
on
the
on
the
gas
price
of
the
modular
exponentiation
that
it
shouldn't
be
quadratic
in
the
modulus,
because
the
most
of
the
libraries
of
arbitrary
precision
arithmetic
for
the
kind
of
numbers
that
we're
talking
about,
they
use
the
karatsuba
methods
for
multiplication
in
exponentiation
as
well.
So
they
so
that
is
much
less.
N
E
D
D
D
Right,
okay,
so
we
have
some
tests
for
the
around
2
to
the
256.
We
have
tests
for
around
to
your
low
1024
I
mean,
like
basically,
I,
think.
The
simplest
thing
in
the
test
is
just
like:
make
a
make
a
ransom
number
of
n
bits
and
then
raise
that
just
like
I
mean
try
raising
it
to
the
power
of
2
treiber's,
get
to
the
power
of
3.
C
C
D
C
D
C
K
K
C
C
Okay,
I
think
that
oh
yeah
does
anyone
have
opinions
on
kind
of
a
release?
I
think
that
one
thing
that
might
help
is
to
really
wrap
up,
especially
EIP
86,
which
will
be
going
over
again
and
a
little
bit,
but
I
think
some
of
those
have
been
somewhat
dragging
on
some
of
the
progress
that
we
would
be
making
on
tests.
I
mean
I'm
not
actually
doing
the
tests,
so
I
might
be
completely
wrong
on
that.
C
But
I
think
that's
good
that
we
close
this
out
kind
of
like
the
EIP
freeze
that
you
she
was
talking
about
before.
But
more
of
an
informal
freeze
for
some
of
these
and
I
know
a
few
of
them
are
closed.
So
that's
that's
good,
but
the
the
IP
86
is
a
big
one
that
deals
with
a
lot
of
different
things.
So.
C
D
Yeah
I
mean
help
for
the
account
abstraction
yet
p.m.
you
know.
I
can
personally
dedicate
a
lot
of
times
of
thinking
about
it
and
giving
a
recommendation
which
will
possibly
be
either
introducing
it
in
a
limited
form
or
basically
advocating
for
going
all
the
way
and
removing
and
removing
at
exid
uniqueness,
but
delaying
the
whole
thing
until
until
the
next
hard
fork.
D
D
D
E
D
So
I
had
so
like
one
example
of
an
alternative
Road
for
AP
86,
and
this
is
one
that
I
would
early
came
up
with
during
the
course
of
this
call
is,
we
would
add,
an
invariant
that
says
you
can't
have
two
distinct
two
transactions
with
the
same
TX
ID
in
the
same
block.
Then
he
would
require
the
S
value
of
an
EIP
86
transaction
to
just
be
the
block
number,
and
then
you
would
basically
you're.
D
Just
four
people
are
using
the
ipv6
transactions
to
just
send
out
a
bunch
of
copies
for
like
block
numbers
that
are
beside
each
other.
So
like
there
are
those
kinds
of
options.
But
basically
my
concern
is
that,
if
we're
going
to
do
like,
if
we're
going
for
whatever,
if
we
end
up
doing
a
staged
rollout
of
the
IP
86
itself,
then
if
I'd
prefer
like
stage
like
stage,
one
should
be
forward
compatible
with
stage
two,
and
if
we
can't
achieve
that,
then
it
would
be
worth
like.
Basically
delaying
the
whole
thing.
D
C
H
C
But
I
like
the
idea
of
two
forks,
mainly
because
it's
editor
of
iterative
rollout
of
features-
and
this
is
a
real
big
feature
list
with
the
number
of
VIPs
we're
dealing
with
so
whoo.
Is
there
anybody
who
wouldn't
be
in
favor
of
splitting
metropolis
into
hard
Forks
and
mainly
to
get
the
difficulty
bomb
diffused,
but
to
have
a
pretty
a
pretty
firm
deadline
on
getting
the
second
one
out.
K
O
The
first
time
we
were
speaking
about
this
I
think
one
of
the
one
of
the
suggestions
was
to
focus
on
the
their
line
and
see
what
we
can
get
ready.
So
there
are
multiple
things
that
can
go
into
metropolis.
Some
are
simpler.
Some
are
more
complicated.
Can't
we
just
try
to
figure
out
what
what
we
could
start
testing
right
now,
so
that
we
will
be
confident
would
be
ready
by
September.
So
we
keep
the
city,
we
keep
the
date
fixed
because
that's
the
that's
the
ice
age.
O
We
know
that
at
minimum
ice
age
fusion
would
go
into
that
hard
for,
but
we
start
coming
up,
not
exact
with
all
the
changes
that
we
want
to
get
in.
Just
for
instance,
Zeki
is
not
a
free
compiler.
Is
that
something
that
relates
to
the
other
ones?
And
we
can
change
you
can
see
which
I
ideas
are
simpler
or
more
easy
to
test
and
make
sure
that
they
are
ready
by
September
and
to
be
ready
by
the
time
dirty.
They
must
be
testable
by
August
or
July
yeah.
C
D
Would
technically
make
some
of
the
privacy
feature?
Is
marginally
less
useful?
Basically
because
like
if
you
have
a
break
signature,
then
if
you,
if
there
is,
if
you
can't
do
things
like
spends
from
a
reg
signature
using
a
null
Center,
then
you
would
basically
have
to
have
ether
in
an
account
and
then
that
that
ether,
an
account,
could
be
a
privacy
leak.
But
like
that's
only
well,
that's
only
one
of
the
use
case
of
the
the.
O
O
Not
necessarily
because
it
is
already
possible
for
you
to
send
and
interact
with
a
contract
without
having
without
having
it
your
own
account
by
signing
a
message
and
having
the
net
contract
read
the
message
and
you
can
even
add
some
other
some
other
feature
where
the
contract
will
spend
a
little
bit
of
easier
to
the
person
selling
it.
So
this
is
yes
for
worried
about.
D
Yeah
no
I
mean
I
agree
that
that's
definitely
possible,
which
is
why
I
say
marginally
like
the
basically.
The
reason
why
that
approach
is
like
in
is
not
optimal
as
there's
two
of
them
right.
One
of
those
that
you
just
you
would
have
to
rely
on
some
third-party
intermediary
Taito
to
an
issue,
a
cough
up,
the
money
and
the
other
one.
Is
that,
like
you
still
incur,
I'm
easy
I
mean
efficiency,
because
you're
like
pointlessly
verifying
and
EC
recover
are
an
ECDSA
signature
on
top
of
the
rank
signature.
So
it
gets
not
optimal.
O
H
C
Okay,
so
yeah
I
think
that
I
think
y'all
are
both
saying
pretty
much
the
same
thing
that
it
would
just
provide
one
less
specific
use
case,
but
that
it
can
still
be
achieved
or
the
ring
signature.
A
situation
that
y'all
are
suggesting
could
still
be
achieved
through
a
different
means,
and
so
that
would
just
be
making
sure
that
that
the
community
and
anybody
who
is
implementing
these
is
aware
that
it
is
not
fully.
C
It
does
not
have
all
the
original
promises
yet
because
it
would
need
to
be
further
shirt
up
in
the
next
the
hard
fork
after
the
next
one
for
the
features
of
VIP
86
to
apply
to
the
features
of
the
pre
compiles.
That
effect
ring
signatures,
so
yeah
that
doesn't
sound
too
bad
at
all
yeah,
so
I
think
the
too
hard
fork
idea
is
good,
I
think
between
now
and
then
we
should
definitely
keep
discussing
EIP
86,
but
there's
enough,
that's
that
there's
enough
at
stake,
and
that
affects
enough
of
the
future
stuff
with
serenity.
C
G
To
the
heart
of
the
tests
should
be
fixed
for
that.
Currently,
all
the
tests
assume
that
there
is
only
one
heart
for
metropolis,
so
splitting
some
of
the
changes
away
would
mean
every
general
state
tests
will
need
to
test
more
network.
So
this
is
global
change
that
takes
maybe
a
little
bit
of
time,
maybe
a
week
or
so
digest.
G
So
Dimitri
has
already
given
an
estimate
that
the
read
is
a
time'.
Dvds
would
be
possible,
and
that's
assuming
only
one
kind
of
agree
with
that
so
I'm
not
saying
that
need
of
it
right
now
at
all.
I
might
mistake
that
86
is
not
so
problematic,
I
believe
so,
but
maybe
I'm
wrong.
If
there's
big
big
concerns
about
if
86
or
any
of
deep
some,
yes,
that's
an
option,
it's
an
option
to
split
out
data
yeah.
C
I,
don't
think
splitting
it
into
two
hard.
Forks
is
ideal,
but
it's
gonna
depend
on
between
now
and
the
next
core
dev
meeting.
How
much
gets
accomplished
with
the
dialogue
for
some
of
the
she's
brought
up
by
Peter,
Jeff,
Coleman
and
Nick.
So
I
think
that
my
suggestion
would
be
that
we
all
focus
on
e
IP
86
between
now
and
next
meeting,
because
I
think
there's
a
good
chance.
C
Right
great
so
yeah,
the
summary
of
that
is
there's
now
the
potential
to
be
too
hard
Forks,
that's
likely
not
ideal
for
rewriting
tests
and
a
few
other
things.
Timing,
wise-
and
it
would
just
kind
of
put
more
stress
on
having
to
do
that
just
because
hard
Forks
are
stressful.
Currently
until
we
get
on
a
on
a
rhythm,
so
yeah
we'll
talk
about
that
more
in
the
next
meeting
and
until
then
focus
on
e
IP
86
to
solve
some
of
the
problems.
C
I
might
even
try
to
make
a
list
of
some
of
the
unsolved
issues
and
questions
regarding
86
and
put
it
in
a
comment
and
put
it
in
the
core
dev
channel.
The
next
thing
is
the
oh
I
have
gas
limit,
increase,
update,
I,
think
everyone
knows
about
that,
though.
A
few
of
the
mining
pools
targeted
a
much
higher
gas
limit
in
the
six
millions,
so
the
gas
limit
has
been
rising
to
that
level.
D
So
I'm
not
I'm,
not
like
personally
worried
about
the
consequences
of
making
the
gas
when
we
go
up
the
as
far
as
mechanisms
go
like
basically,
I
think
the
concern
is
is
that
we
haven't
really
seen
the
like
the
automatic
adjustment
mechanism
doing
a
very
good
job
and
I
think.
The
reason
basically
is
that,
in
order
for
that
becket
ism
to
do
a
good
job,
first
of
all,
either
literally
everybody
has
to
be
complying
with
it
plus
with
the
watch.
D
G
I
D
C
Yeah
and
so
for
something
like
that,
that
would
just
be
like
a
new
EIP
that
would
could
eventually
be
put
in,
but
from
what
you
said
earlier
and
I
think
from
what
other
people
have
said.
This
isn't
something
that
is
bad
enough,
that
we
need
to
have
that,
be
our
focus
over
anything
else
in
Metropolis
right
now,
yeah
yeah.
So
it's
not.
B
L
B
Yeah
I
think
I
think
what
the
problem
with
that
is
mostly
because
so
mostly
fools
define
their
own,
because
the
defaults
are
actually
sensible
enough,
for
example,
during
the
dus
attacks,
there
are
problems
that
blocks
took
five
seconds
to
process
an
hour.
Obviously,
arriving
fools
are
angry
about
that,
but
if
the
algorithm
would
have
adjusted
automatically
I
would
have
brought
down
the
gas
price
gas
limit
to
half
of
it.
B
C
I
C
Great
I
think
there'll
be
more
discussion
on
that
than
any
other
comments:
okay
and
then
the
last
one,
the
IP
186,
reducing
the
etherium
issuance
before
proof
of
stake.
If
you
go
to
the
agenda
and
scroll
to
the
bottom,
the
last
comment
outlines
vitalik,
alex
van
descend
and
niks
comments
on
that,
so
the
talaq,
since
you
brought
up
that
and
chat,
you
can
start
with
your
ideas
on
it.
D
This
was
the
issuance
reduction,
yes,
exactly
yeah,
so
basically
I'm,
you
know
the
proposal
that
I
had
was
to
do
a
one-time
cut
down
of
the
of
the
issuance
and
target
the
target,
the
amounts
basically
so
that
the
amount
of
issuance
per
second
after
metropolis
roughly
equals
the
amount
of
issuance
per
second
right
before
metropolis.
So
in
practice,
if,
let's
say
the
block,
time
is
something
like
25
seconds.
When
we
do
the
switch,
then
the
drop
would
be
from
five
years
or
to
something
like
three
ether
and.
D
D
C
B
C
C
In
that
case,
there
might
need
to
be-
and
let
me
look
real
quick
I,
think
hunter
island
or
whatever
has
a
new
there
I
think
either
said
there
needs
to
be
a
new
AIP.
Oh
I
see
okay
nevermind.
He
just
put
a
different
thing
about
the
difficulty
bomb
diffusion,
so
yeah.
If
we
could
have,
we
could
either
use
the
CIP
or
write
a
new
one.
C
D
C
D
Mean
look.
The
EIP
ax
here
is
basically
very
simple
right.
It's
just
like
a
one-time
thing
that
says
if
the
block
number
is
greater
than
or
equal
to
the
metropolis
for
walk
number
then
replace
the
block.
Basically
multiply
all
block
reward
related
parameters,
including
beef
base,
block
reward,
nephew
reward
and
Uncle
reward
by
a
factor
of
X
where
in
this
case,
X
does
a
3
over
5
hello.
C
C
F
Is
that
up
until
metropolis,
it's
been
possible?
To
knows
the
feeling?
You
know
stare
surance
if
your
transaction
failed
or
not,
based
on
the
guess
which
in
which
people
rely
on
I
think
quite
heavily
with
the
introduction.
The
revert
opcode,
that's
no
longer
the
case
and
with
current
api's
have
be
very
difficult
for
people
to
determine
if
their
transactions
exceed
or
not
it's
possible
for
a
full
node
to
really
execute
the
transaction
and
tell
you
what
its
return
code
is,
but
that's
not
possible
for
fast
notes.
F
C
M
B
B
F
F
And
secondly,
if
it
is
a
good
idea,
should
we
store
the
actual
return
data
in
the
receive
field
or
store
a
hash
of
that
briefly,
storing
the
actual
turn
data
as
simplest
in
terms
of
accessing
it,
but
storing
a
hash
has
the
advantage
of
the
length
of
the
field
not
changing
and
the
type
not
changing,
but
the
disadvantage
that
you
can
have
yet
another
thing
you
need
to
sync
and
you
have
to
add
a
new
message
type
to
the
the
wire
protocol.
Mr.
Fitch
return
data
I.
B
Personally
prefer
if
only
the
hash
would
be
stored
and
the
reason
is
mostly
because
then
the
data
structures
don't
have
to
change,
because
so,
if
we
were
to
store
the
entire
error
message,
then
that
means
somebody
might
insert
an
arbitrarily
long
error
message
to
work.
We
need
extra
pricing
problems
so.
F
F
D
B
F
C
C
B
Just
to
highlight
the
problem,
imagine
that
you
issue
a
tract.
So
currently
you
create
a
transaction
with
two
hundred
thousand
gasps
and
then
you
look
at
the
receipt
and
you
see
that
hundred
thousand
gas
was
consumed
and
then
you
know
that
it
failed
and
then
you
might
want
to
trace
it
or
whatever.
The
issue
is
that,
if,
with
the
introduction
of
the
rebirth
of
code,
let's
say
that
two
hundred
thousand
gas
consumes
only
fifty
and
then
you
have
absolutely
no
clue
whether
it
was
successful
or
not.
Basically,
you
cannot
doubt
whether
it
was
successful
or.
G
D
So
one
very
simple
example
is
that
if
you
look
at
a
lot
of
recent
icos,
the
majority
of
transactions
end
up
coming
in,
like
after
the
ico,
hits
the
capper
after
it
expires,
and
so
they
fail
and
because
of
this,
these
transactions
often
ends
up
consuming
like
two
hundred
thousand
gas
and
when,
in
reality
they
could
have
gotten
away
with
consuming
like
half
of
that
or
possibly
even
lower.
But
possibly
it's
something
like
thirty
thousand.
P
I
would
I
would
I
would
make
one
comment
here
is
that's
a
virtual
shouldn't,
in
my
opinion,
revert
shouldn't
like
so.
If
you've
used
up
like
ten
thousand
gas
and
then
we
call
roburt,
the
cost
should
not
be
ten
thousand
gas,
because
you
are
doing
like
there's
a
there's
a
bit
of
an
extra
cost
to
actually
reverting
the
state,
so
it
should
be
like
1.5,
X
2
to
X
maximum,
you
know
or
up
to
the
gas
limit
on
the
amount
gas.
You
start
that
far
so
far,
I.
F
Say
I
mean
go
ahead:
oh
that's,
not
something
we
impose
at
the
moment
you
can
revert
when
you've
only
got
a
loss
rate.
You
can
fail
when
you've
only
got
one
guess
left
and
it
may
actually
be
cheaper
because,
although
you
have
to
rewind
things
in
memory,
it's
stuff
that
you
don't
have
to
write
such
as.
D
You
know
like
basically
in
all
major
Op
relations.
Well,
all
you've,
all
you're
doing
is
you're,
basically
just
going
back
through
the
journal,
you're
going
walking
backwards
through
the
journal
and
you're
doing
a
single
memory
operation
for
every
single
storage
operation
that
you
did
going
forward.
So
the
ratio
between
memory
and
storage
tends
to
be
very
high.
So
I
don't
think,
like
these
extra
expense,
you're
incurring
is
particularly
high,
yeah,
fair
enough
I
guess.
P
J
C
E
H
F
N
I
also
have
a
question
if
pretty
word,
every
word
wouldn't
return
any
error
message,
but
there
was
some
way
to
get
way
to
get
on
the
interface.
The
the
the
exact
revert
which,
which
ended
up
reverting,
wouldn't
a
annotation
just
similar
to
the
to
the
next
pack
or
actually
part
of
Matt's
back,
would
do
the
job.
N
F
F
F
The
one
I
just
proposed
6:58
would
be
to
simply
use
the
midstate
field
as
a
return
code,
zero
or
one
and
a
net
return
data.
I'm
loathe
to
do
that
personally,
because
I
think
it's.
It
would
be
very
useful
for
people
to
be
able
to
access
returned
data
from
a
transaction,
but
that
is
more
a
nice-to-have
than
essential
effects.
So,
if.
J
G
F
F
Well,
I
suggested
that
if
we
were
going
to
talk
about
adding
returned
data
field
later
than
in
the
meantime,
we
should
only
get
the
status
code,
not
the
hash,
to
return
data.
If
we
add
the
hair
should
return
to
anything,
you
have
to
be
you
have
to
where
they
get
returned
data.
Why
protocol
call
in
order
to
be
able
to
tell,
even
if
it
succeeded,.
F
F
B
Don't
miss
that
I
guess
this
is
an
implantation
video,
but
at
least
in
the
etherium,
if
the
field
size
is
validated
and
arathi
decoding.
So
if
you
were
to
say
that
the
our
opt-in
size
should
be
one
byte
exactly,
but
we
allow
unmarshal
anything
to
32,
bytes
and
I
can
see
something's
going
wrong.
Okay,.
F
F
E
D
C
F
D
B
C
Okay,
I
think
that
wraps
up
that
was
there
any
other
comments
Nick
or
can
we
bring
that
to
the
EIP
I
think
we
should
take
it
offline
I'll?
Take
it
home,
see
yeah
yeah
yeah.
If
you
could
do
any
comments
on
your
VIP
or
98
that
either
summarize
or
if
do
any
conclusions
that
partial
conclusions
we've
come
to
that
be
excellent?
Okay,
so
that's
pretty
much
it
I.
Don't
there
anything
else,
anyone
wants
to
say
or
anything
to
bring
up
all
right
so
before
we
go
focus
on
a
IP
86.
C
Let's
try
to
get
that
wrapped
up,
because
that'll
help
with
testing
and
making
sure
that
we
can
get
a
deadline
set
for
metropolis,
go
ahead
and
look
at
Nick's
proposal
and
also
a
TI
p
186
that
one's
less
controversial
186
as
far
as
metallics
formula
he
proposed
and
then
finally,
if
you
haven't
purchased
DEFCON
three
tickets,
go
do
that
and
yeah
just
like
reach
out.
If
you
need
to
know
the
website
or
anything
like
that,
but
go
ahead
and
get
them
before
they're
gone
all
right
thanks,
everybody
see
you
in
two
weeks.