►
From YouTube: Ethereum Core Devs Meeting #43 [07/27/18]
Description
A
A
A
B
Evm
of
course
receive
you're
able
to
find
more
bugs,
and
you
could
possibly
write
manually
so
as
I
just
do
that.
I
use
a
new.
Of
course.
This
time
of
Awesome
create
two
of
code
is
about
to
be
merged
to
CBP's
here
and
I
will
be
ready
to
start
compiling
some
tests
on
it
and
external
code
hash
is
seems
to
be
pretty
easy
to
implement
yeah.
What?
What
else
do
we
need?
What
what
kind
of.
C
C
B
This
this
change
will
at
least
required
to
regenerate
all
of
the
tests
cause
current
tests
using
storm
writes
to
stores
actual
value
for
more
than
just
testing
the
store
up
code.
Every,
of
course,
that
I
test
I
use
store
operator
to
put
something
into
the
state
and
see
whether
the
hope
could
worked
correctly
or
not.
I
think
its
effects,
all
of
the
tests,
probably.
D
I
can
add
on
regarding
post
testing.
Air
will
be
starting
to
restart
processing
again
yeah.
We
needed
some
updates
both
to
the
lib
foster
based
testing
and
to
the
test.
F
/,
eb
m
la
base,
random
generator,
passing
to
make
sure
that
we
get
the
new
op
codes
and
everything
and
yeah
so
and
that
part
requires
the
I
mean
it's
differential
testing.
So
it
requires
that
implemented
a
taste
into
clients
and
preferably
gas
and
parity
and
dif,
with
testing
between
those.
D
E
A
That
sounds
good,
okay,
we'll
run
through
client
updates
and
then
before
we
get
to
research
updates.
What
we'll
do
is
we'll
talk
a
little
bit
about
the
1087
and
whether
or
not
it's
gonna
go
into
Constantinople
before
we
go
into
other
things,
because
peter
has
to
leave
a
little
early
so
for
client
updates,
let's
start
with
parody
I
think
that's
Fredrik
or
a
free.
F
Yeah,
that's
me
I,
guess
almost
yeah,
some
release
parity
serum
2.0
last
week
just
finally
concludes
what
we
have
been
preparing
for
a
while
to
have
a
pure
blockchain
client
for
IBM
and
wasn't
be
unbiased.
Hence
we
stripped
out
or
installed
us
or
wallet
user
interface
and
strong,
and
that's
basically
where
we
are
now
was
our
2.0
release
and
yeah.
We
slightly
rebranded
the
client.
It's
called
Elysium
now
just
to
distinguish
it
from
other
very
Oh.
F
F
G
It
I
think
it's
a
simple
enough
PR,
but
I'm
kind
of
holding
out
with
merging
it
until
it's
actually
decided
whether
we're
going
to
ship
it
or
not,
because
I
don't
want
to
go
back
and
try
to
extract
it
out
its
if
we
decide
against,
but
essentially
these
for
a
IPS
are
mostly
done
of
course,
testing
pending
and
that's
for
the
220,
the
block
Hoshi
IP.
It
would
be
nice
to
figure
out
whether
we
go
with
two
sorry
not
to
28
to
10.
G
So
it's
really
nice
to
figure
out
whether
we
go
to
be
the
original
block.
Hoshi
IP
metallic
at
a
certain
point,
suggested
a
simplified
version.
It
would
be
nice
to
just
arrive
at
a
decision
whether
we
are
doing
this.
Because,
again,
it's
insane
in
theory,
it's
a
bit!
It's
relatively
simple
AIT.
In
practice
it
introduces
a
new
type
of
account.
It's
super
user
stuff.
It
it
marks
around
a
bit
with
gas
gas
allowances,
because
the
the
contract
calls
get
special
gas
allowances.
So
anyway,
it's
not
on
it's
not
particularly
hard.
G
But
again
it
will
be
nice
to
have
a
confirm
that
we're
going
with
it
before
blowing
up
everything,
so
yeah,
that's
about
the
gas
status
on
the
car,
setting
up
of
work
as
to
I
think
that
was
also
mentioned
previously,
whether
we
want
to
do
ice
age
and
either
issuance
stuff
for
that
I.
Don't
particularly,
we
don't
have
anything
to
add,
but
whatever
is
decided
we're
going
to
roll
with
it.
Okay,.
A
Sounds
good?
We
can
try
to
make
some
more
decisions
today,
hopefully
nick
and
peter,
as
far
as
implementing
the
esthe
or
the
net
s
store
AIP.
There
was
comments
last
time
about
the
need
to
maintain
a
journal
for
the
dirty
map
and
what
happens
if
stuff
gets
reverted
and
increasing
complexity.
There
is
that's
something
that
we
have
more
information
on
now
or
anything
like.
H
G
So
I'll
go
first
thing
so
essentially,
as
the
quick
recap:
dn't
net
storage
as
storage.
So
the
crux
of
the
EIP
is
that,
instead
of
if
instead
of
charging
a
lot
of
gas
for
every
operation,
we
kind
of
charge
a
really
small
amount
for
every
operation
and
only
charge
a
big
amount
if
we
actually
end
up
modifying
the
state,
because
otherwise,
if
we
just
keep
overwriting
to
stay
to
the
same
thing,
then
there's
no
really
point
no,
not
much
point
to
overwrite.
It
implementation
wise.
This
kind
of
entails
two
things.
G
One
of
them
is
that
we
need
to
track
the
original
value.
So
whenever
a
new
slot
is
his
rent,
we
kind
of
need
to
put
that
in
some
map
and
keep
it
around
unto
the
transaction
finishes
executing
and
the
other
one
is
that
we
actually
need
to
be
able
to
track
whether
slot
is
dirty
or
not
dirty,
because
the
gas
price
has
changed
a
bit
whether,
for
example,
if
I,
if
I
override
a
slot
with
the
exact
same
value,
then
it
shouldn't
get
dirty.
G
So
that's
why
we
kind
of
need
to
have
dirty
tracking
now
implantation
wise
in
gas.
It
turned
out
that
it's
relatively
straightforward,
because
we
already
had
the
dirty
tracking
done
for
optimization
reasons
so
that
we
don't
update
the
try
only
if,
if,
if
the
value
actually
changes
so
implantation
wise,
we
only
needed
to
add
three
pieces
one
to
track
the
original
values
when
you
first
access
it.
So
that's
straightforward.
G
All
the
accounts
that
we
touched
and
iterate
over
all
their
dirty
state
items
and
just
see
whether,
but
do
we
need
how
much
we
need
to
charge
or
how
much
we
can.
We
can't
recover
gas
wise
due
to
essentially
overwriting
with
the
same
thing,
so
what
it
is
most
probably
a
bit
it
not
too
understandable,
but
all
in
all
implementing
it
in
gas
was
pretty
straightforward.
That
would
be
my
conclusion,
but
we
did
the
dirty
tracking
already
I'm,
not
sure
how
other
clients
did
a.
D
C
C
C
The
way
Peter
implemented
it
have
to
change
me.
Basically,
the
all
the
new
state
is
scoped
to
a
call
just
like
existing
dirty
tracking
or
existing
state
tracking.
So
all
of
the
effects
of
have
and
should
also
be
scoped
to
the
cool
little
thing
so
I,
don't
think
they're
gonna
be
edge
cases
around
destroying
stuff.
C
G
Just
to
just
go
ahead,
add
to
that
Martin's
question.
I
think
the
two
things
that
but
I
wouldn't
call
them
edge
cases,
but
we
definitely
need
to
test
them.
Is
that
yes,
one
when
you
suicide
the
contract,
then
it's
a
valid
question,
whether
the
storage
slots
for
those
do
they
return,
refund
gas
or
don't
they
refine
gas
and
all
in
all
I
would
say
no,
but
I
guess
either.
Behavior
is
valid
as
long
as
it
is
backed
out
and
the
other
interesting
thing
that
again
means
the
test
is
what
happens
with
reverts.
G
So,
for
example,
if
I,
if
I
modify
a
storage
slot,
make
it
dirty
and
then
revert
then
does
that
revert
the
dirtiness
to
or
not
and
a
more
optimal
solution
would
be
that
it
does
not
revert
the
dirty,
but
with
make
we
kind
of
agree
that
okay,
let's
revert
the
dirtiness
to
simply
because
then
it
is
much
more
much
better
scoped
so
that
we
don't
have
these
weird
effects.
That
revert
old
nonetheless
has
a
side
effect.
So
that's
I.
G
In
my
opinion,
it's
not
it's
kind
of
logical
but
again
I'm
speaking
based
on
on
our
code,
so
it
was
easy
to
implement
him
to
our
code
base.
I
cannot
speak
for
other
kind,
so
maybe
I
would
suggest
that.
Maybe
if
another
client
wants
to
take
a
stab
at
it,
then
they
should.
Then
maybe
you
can
be
evaluated
after
second
implantation.
A
A
A
G
Know
one
suggestion
that
I
could
make
for
for
parity
and
harmony.
Is
that
so
I
pasted
the
link
to
our
poor
request
and
I
think
the
code
is
really
clear
as
to
how
how
it
can
be
injected
and
our
obviously
the
cocodes
I'm,
not
I,
don't
know
how
how
how
familiarities
or
how
easy
it
is
for
you
guys
to
read
it,
but
maybe
it
will
be
a
bit
of
a
help
to
just
look
at
it
and
see
if
it's
it's
horribly,
complicated
to
port
this,
to
your
code
bases
or
not,.
E
E
A
A
Okay,
cool
close
enough
to
rough
consensus.
For
me,
we
should
put
it
in
and
test
it
on
parity
and
harmony,
or
not
test
to
implement
it
on
parity
and
harmony,
to
see
how
it
looks
and
if
there's
any
things
we're
missing,
Dimitri
blasting.
What
do
you
do?
You
have
an
opinion
on
this
as
far
as
from
a
testing
perspective,
or
do
you
need
to
look
into
it
more.
D
C
G
One
comment
that
I
would
add
regarding
dirty
tracking,
so
one
thing
that
so
up
until
now,
dirty
tracking
in
in
the
collision
code
waste
was
more
like
an
optimization
so
that
we
kind
of
tracked
whether
other
stores
thought
was
modified
and
if
it
was
modified
at
any
other
end
of
the
transaction.
We
updated
the
storage
try,
but
we
didn't
care
at
all
about
three
births.
I
mean
we
as
in
we
didn't
care
about
on
marking
and
feel
dirty
if
it
was
ever
returned
and
even
if
it
was
over,
which
can
be
the
same
thing.
G
We
just
did
a
stores,
try,
update
and
it
wasn't
Noah
and
who
cares
and
that's
one
thing
that
we
actually
had
to
pay
attention
to
that
now
we
actually
correctly
track
the
dirtiness
and
revert
the
dirtiness
so
that,
if
any
client
does
have
optimizations
already
for
dirty
tracking
them.
This
is
maybe
the
only
case
where
you
actually
need
to
pay
attention
that
the
roberto's
have
done
correctly.
But
if
you,
if
anyone
who
has
a
journaling
in
place,
it
should
be
fairly
straightforward
to
just
conjure
a
flag.
A
Okay,
that
makes
sense,
sounds
good
there,
let's
see
and
then
I
guess.
What
we'll
do
is
what
we
kind
of
jumped
around
here,
but
since
a
few
people
have
to
go,
I
think
I've
just
been
told
the
block
cast
refactoring
EIP
to
ten.
Where
did
we
land
on
that
last
time?
Is
that
something
where
we
said
there
were
too
many?
Let
me
actually
just
look
at
the
notes.
Real
quick,
so
batalik.
D
D
Okay
and
in
both
cases
there
have
been
some
discussions
about
how
to
actually
use
that
thing,
because
the
block
hash
is
a
little
bit
dynamic
and
overwritten
in
time,
so
it
I
suspect
it
may
be
kind
of
difficult
to
make.
A
smart
contract
rely
on
earlier
block
hashes,
since
at
the
given
point,
you
can't
really
tell
what
block
hashes
would
be
there
and
which
ones
will
be
stored,
which
won't
sleep
over
it.
G
Yes,
so
just
to
expand
on
that,
I
would
say
that
it
would
be
before
going
ahead
with
the
IP
2:10.
It
would
be
nice
to
have
a
reason
for
going
ahead
with
it,
because
in
the
IP
we
have
Vitalik
did
enumerate
a
couple
of
ideas
of
where
that
might
be
useful,
but
given
the
nature
of
how
we
store
and
what
we
store,
I'm
wondering
whether
it's
truly
useful
to
do
it.
J
A
D
A
K
A
Sounds
good
anyways
while
he's
moving,
we
got
1:45,
we
got
10
52
or
we
got
bitwise
shifting
EXT
code
hash,
we
got
skinny
create
2,
and
then
we
tentatively
have
net
gas
metering
for
s
stores,
1087
right
now,
210
block
hash
refactoring
we're
still
trying
to
decide
the
purpose
of
it
kind
of
reap
rekindling.
That.
K
If
we're
not
going
to
have
EDM
contract
for
protocol
level,
instead
we're
gonna
move
to
word
wazza-wazoo,
X
being
both
in
a
protocol
level.
Then,
if
we
want
to
get
the
benefits
of
it,
it
probably
makes
sense
to
just
extend
it
in
a
way.
That's
like
written
in
native
code
and
much
simpler,
which
is
what
12-18
does
and.
D
K
So
the
overwriting
is
kind
of
necessary,
because
otherwise
this
whole
thing
would
have
event
storage
overhead
if
we
want
to
like.
Basically
the
idea
is
that
if
you
want
a
use
case
that
has
like
some
larger
range
of
durability,
then
you
would
basically
use
a
block
hash
that
is
that
has
like,
or
is
he
was
a
block
number
that
has
a
larger
number
of
zeros
and
it's
binary
representation,
and
that
we
have
a
larger
span
of
time
within
which
you
can
submit
the
block
hash
right.
That
means.
K
Yes,
although
that's
ok,
so
if
you
want
to
like
certainty
that
you'll
be
able
to
use
the
same
block
cache
for
a
year,
then
you'll
have
to
wait
a
year.
If
you
have
one
application,
then
one
thing
that
you
could
do
is
you
could
just
have
a
feature
that,
what's
that
calls
the
contract
once
and
then
just
like
basically
stores
that
particular
block
hashes
up
really.
E
D
K
A
Wonderful
and
if
you
can
mute
when
you're,
not
oh
great
yeah!
Well,
if
you
give
me
when
you're,
not
talking
with
Alec
that'd,
be
great
I
just
saw
you
did
okay,
so
we'll
talk
about
EIP
to
ten
more
next
meeting
right
now,
there's
or
not
to
ten
we'll
talk
about
the
new
number,
twelve
eighteen
or
whatever,
and
we
will
follow
up
on
that.
A
Let's
see
but
right
now
it
looks
like
it's
not
going
in
until
we
have
more
information
and
stuff
like
that,
I
think
that's
actually
all
the
constants
and
Oakland
A's
we've
talked
about
a
lot
of
them
are
implemented.
I'll
make
that
Mehta
chart
that
I
talked
about.
That
shows
which
clients
have
implemented,
which
E
is
and
doing
that
I
was
gonna.
Add
all
the
like
death
parity
harmony,
I
was
wanting
to
add
Pantheon,
but
his
Pantheon
still
closed
source.
L
E
H
So
we
published
our
seconds
kind
of
major
named
release
this
week
and
while
we're
still
waiting
for
the
client
to
finish,
we
think
we
have
a
client
that
fully
syncs
with
the
main
net
right
now
so
another
day
or
so
state
syncing,
and
then
you
think
we'll
be
there.
So
lots
of
improvements
on
performance
and
syncing
reliability
yeah
thanks
for
coming
along
quickly
and
really
nicely.
We
have
not
started
on
any
constant
Constantinople
leaps,
but
we
have
issues
open
for
all
of
them
and
we'll
probably
start
biting
into
them
very
soon.
H
H
A
B
Is
kind
of
new
information
available
to
contract
because
it
was
not
directly
exposed.
The
the
only
thing
the
contract
could
could
see
before
is
different
call
cost
in
case
the
account
existed
or
not,
and
that
this
allows
actually
it's
like
more
direct
access
to
this
information.
If
the
contract
would
like
to
check
whenever
the
account
is
empty
or
doesn't
exist,
at
all,
I
mean
it's
yeah
mostly
can
check.
If
the
account
exist,
however,
I'm
not
sure
like
that,
the
definition
of
existing
account
is
is
very
precise.
Within
the
or
ethereal
specification.
G
No
III
didn't
I,
miss
miss,
remember
something:
I
was
just
checking
how
we
implemented
it,
because
I
know
that
we
we
had
a
back
and
forth
on
exactly
the
differences
because
empty
accounts
down
existing
accounts,
empty
pre-cum
files,
etc,
but
I
yeah.
We
just
keep
doing
things
in
the
index.
If
the
account
doesn't
exist,
we
just
return
zero
and
if
you
do
that
dispute
and
the
empty
Co
and
for
pre-compile,
we
return
the
empty
Co,
they
do
exist.
G
Yeah
exactly
so,
this
is
actually
a
very
good,
very
good
corner
case
marking
that
you
brought
up
that
our
implementation.
Currently
just
does
yes,
if,
if
the
account
exists,
but
there's
no
code
in
it,
then
return
the
empty
code
hash
that
for
pre
compares
to.
However,
if
the
pre-compiled
does
not
exist
because
it
doesn't
have
balance,
then
we'd
return
zero.
So
this,
in
my
opinion,
this
is
a
good
behavior,
because
otherwise,
all
of
a
sudden,
this
opcode
will
need
to
be
aware
of
whether
something
is
a
pre
compare
or
not.
G
G
Know
that
that
was
the
time
when
both
parity
and
gas
implemented
different
things
wrong
and
then,
in
the
end
we
went
with
parities
so
to
say
bug
because
it
was
easier
to
reproduce
the
bug
than
to
fix
everything.
But
I.
Don't
remember:
I
know
that
it
was
some
something
after
the
the
cleanups,
the
Shaka
and
cleanup
set
it.
So.
G
L
This
is
actually
as
someone
implementing
a
client
and
coming
online
to
Maine.
That
I
actually
had
some
questions
about.
So
you
know
you
can
find
out
about
this
transaction
at
block
two
point:
six:
seven
million
in
the
yellow
paper,
but
in
terms
of
you
know
the
actual
behavior
being
locked
into
an
E
or
somewhere
else,
we'll
get
a
specification.
It
doesn't
seem
like
it's
ever
really
been
finalized,
and
so
I
was
wondering
if
for
Constantinople,
maybe
we
could
get
some
closure
on
that
I.
Also
think.
L
A
Cool
yeah
I
remember
there
was
actually-
and
you
probably
still
have
this
Martin
there's
a
long
document
that
either
yo
Ichi
or
you
and
you
know,
Ichi
created
I
was
just
a
gist,
but
it
had
like
the
whole
story
and
like
what
ended
up
happening
and
why
the
yellow
paper
is
written
as
it
is
so
that
that'd
be
helpful.
I
think
yeah,
fine,
wonderful!
A
L
Don't
forget
about
us,
though
Pentiums
at
the
point
where
we
can
connect
to
main
that
in
the
stable
way,
so
discovery
layer
seems
to
be
working
pretty
well
same
with
our
LP
X
and
we're
at
the
point
where
we're
able
to
perform
full
syncs.
It's
not
optimized
at
this
point,
but
we're
well
into
block
or
well
past
bought
like
two
point:
four,
eight
million
so
right
in
that
transaction
attack
chain
segment,
so
we're
letting
it
run
were
singing
far.
L
A
Okay,
there's
a
brand-new
client
that
I
haven't
been
able
to
reach
out
to
but
I'm
gonna
post
the
link
to
it.
It's
called
nether
mind
it's
a
full
death,
aetherium
client.
So,
unlike
nathie
areum,
which
is
a
dotnet
integration
library,
this
is
actually
a
full
client,
so
I'm
gonna
invite
them
to
the
meetings.
If
I
can
get
a
hold
of
them.
Does
anyone
know
the
person
who
does
this.
A
A
J
I
can
give
the
details
Angelica
buildings
and
the
Casper
starting
version
2.1,
there's
kind
of
a
working
spec
that
is
getting
close
to
complete
this,
that
combines
cross-links
and
anta
stations
for
a
cleaner
design,
introduces
a
new
fork
choice,
rule
recursive,
proximity
justification,
which
is
still
pending
a
little
bit
more
peer
review,
Vitalik
posts,
a
proposed
ethic
with
caspere
on
each
research
recently,
and
the
intention
is
to
introduce
this
design,
but
it's
still
pending
some
more
peer
review.
At
this
point,
we're
doing
a
sharding
implementers
call
the
first
one
on
Thursday.
J
So
week
from
yesterday,
we
talked
about
that
on
the
sharding
getter
if
anyone's
interested
VDS
are
being
supposed
to
be
using
in
the
sharding
iron
G
adjustment,
some
of
the
security
grammars
and
upon
how
much
an
attacker
can,
how
much
advantage
an
attacker
can
gain
I
like
producing
it
in
hardware
to
do
this
suggestions
getting
some
real-world
and
so
on
with
a
hardware
manufacturer
own
on
some
of
that.
So
that's
that's
mostly.
What's
going
on
Vitalik,
if
you
have
any
other
notes.
K
Yeah
I
think
so,
like
the
two
key
things
that
I'm
working
on
from
my
side,
one
are
that
debacle
is
Casper
and
which
basically
is
an
improvement
on
Casper
that
allows
any
ebook
to
be
justified
and
finalized
and
so
takes
the
time
to
finality
down
to
I'm,
basically
equaling
the
optimum.
So
what
we're
as
below
it
was
like
twenty
five
percent
above
optimal,
and
it
also
like
basically
simplifies
the
algorithm,
because
we
don't
have
to
separately
worry
about
like
what
happens
inside
an
epoch
versus
what
happens
across
a
box.
K
K
The
next
step
at
this
point
is
to
try
to
take
both
that
and
epochal
is
Casper
and
formally
prove
some
properties
about
it
and
mail
down
more
details
of
the
protocol
and
at
that
point,
like
the
main
reason.
The
main
reason
behind
this
work
is
basically
to
it's
a
separate
line
of
research
from
Justin's
vdf
work
where
we're,
then
the
purpose
of
this
is
to
make
the
algorithm
highly
resistant
against
even
the
vdf
feeling
horribly.
K
So
basically,
the
algorithm
is
robust
against
the
long
sequences
of
bad
proposers
and
it's
in
mathematics.
So
far
it
seems
like
it
does
the
job,
but
you
know
like
once
again:
we
do
need
more
thing:
okay,
to
kind
of
spend
more
cycles
like
working
out
the
details
and
ideally
getting
mr
and
getting
some
kind
of
formal,
formal
proof
of
it
out
for
various
different
properties.
A
There
was
also
a
theory
of
Jess
which
I
skipped
because
holger's
not
here,
but
he
did
put
a
comment
that
said
they
just
did
their
first
release
series
version,
two
point
four
point:
X
where
they
have
partial
Constantinople
support
and
some
other
cool
things.
They're
gonna
write
up
issues
for
Constantinople
IP
soon,
and
they
have
a
reddit
follow-up
call
for
participation
because
they
don't
have
enough
people
to
implement
it
all
themselves.
A
D
D
We
can
really
can't
really
lower
the
cost
of
modok's
and
we
can
definitely
not
lower
the
cost
of
pairing
as
it
stands
right
now,
I
guess
would
make
it,
but
parity
would
have
some
serious
problems
with
that
on
the
upside
parata's
looked
into
the
feasibility
of
improving
that
I
know.
Do
you
guys
want
to
talk
about
it
yeah
so.
I
Henry's
been
working
on
it
for
about
a
week
and
we
have
a
PR
in
now
that
doubles
the
performance.
So
it's
a
2x
speed-up,
but
not
really
close
to
the
10x
that
we'd
need,
and
the
problem
here
is
sort
of
Gathol
eyes
on
this
cloud:
filler
library
that
has
super
specialized
assembly
for
64-bit
architecture,
zombie
and
128
and
256,
and
it's
not
really
something
that
we
can
like
we've
dug
in
to
try
to
see
if
we
can
use
that
somehow
or
into
a
tit
or
like
what
our
options
are.
I
I
I
I
D
D
H
This
is
Piper
with
Trinity
I'm
kind
of
coming
into
this,
without
a
lot
of
homework
being
done,
but
I
know
that
our
implementations
of
those
are
extremely
slow,
their
implementations
that
are
done
in
pure
Python
and
as
far
as
I
remember,
when
I
was
implementing
those
pre
compiles.
There
were
no
other
options
that
I
could
find,
but
they
all
so
and
I
don't
really
know
what
other
language
ecosystems
are
looking
like
as
well,
but
I'd
be
wary
of.
A
D
A
F
A
C
A
D
A
C
D
C
H
I
Yeah
I
mean
then
like
it's
theoretically
possible
for
us
to
do
that.
So
it's
it's
just
a
matter
of
getting
the
right
person
to
be
able
to
do
it,
but
then
that
the
question
is
really
just
like.
Do
we
want
to
depend
on
on
having
these
hyper
optimized
assembly
implementations
with
parings
available
for
our
call
clients,
yeah.
B
But
we
are
using
that
already,
so
so
having
different
implementation
of
the
same
cryptograph,
it's
I,
don't
think
it's
it's
it's
better,
because
you
can
make
mistake
differently,
but
I'm,
not
security
expert.
So
yeah
I'm
I'm
open
for
comments
in
this
case,
but
happened
that
we
we
used
the
single
library
into
every
every
software
for
14
clients.
D
K
E
I
E
B
I
I'm
not
I'm,
not
really
sure
how
that
would
work
either
I
think
you
run
into
that
and
then
there's
like
the
issue
of
the
the
thing
that
I
mentioned,
that
this
library
is
not
actually
allowed
to
be
used
for
commercial
usage.
So
and
that's
something
that
we
apparently
want
to
still
keep.
So
we
couldn't
use
the
library
directly.
B
L
A
D
A
A
For
now
we'll
leave
it
out,
then
thanks
for
running
those
benchmarks,
though
Martin
that
helps
a
lot
welcome.
Okay.
So
the
next
item
on
the
list,
which
actually
goes
back
up
to
four,
is
the
there's
four
AIPS
to
either
delay
or
completely
remove
the
difficulty
balm
and
or
reduce
the
block
reward.
So
there's
eight,
fifty
eight
twelve
twenty
seven
one,
two
three
four
and
twelve.
Forty
that's
on
the
agenda.
A
B
A
D
H
N
Just
a
related
question,
as
you
said,
Hudson
in
Dimitri
I
think
in
the
first
I
was
first
introduced.
It
was
sort
of
specifically
around
the
group
of
state,
but
what
Piper's
alluding
to
here?
What
I
think
we're
kind
of
alluding
to
is
that
it's
more
just
it's
not
for
any
particular
move
or
switch.
It's
just
around
participating
in
hard
forms
and
removing
the
default
option.
So
it's
just
a
general
thing.
Is
that
kind
of
what
we're
saying
right
now.
H
K
A
A
A
Yes?
Okay?
So
now
we
get
to
the
point
where
there's
some
AIPS
that
do
a
combination
of
delaying
the
bomb
and
changing
the
difficulty
reward.
I
was
gonna.
Wait
for
the
end
to
kind
of
suggest
this,
but
I
think
we
should
separate
the
two
I,
don't
think
I
think
traditionally,
we've
had
it
in
the
same
EIP,
but
I
think
decoupling
them
would
help
us
create
priorities
where
we
have
one
thing:
that's
a
economic
and
technical
change
and
the
other
ones
appear
technical
change
that
doesn't
have
to
do
with
as
controversial
other
thing.
A
So
as
far
as
reducing
the
reward,
there's
people
who
say
that
it
should
be
actually
reduced
or
increased
some
people
say
it
should
be
reduced
to
1/8.
Some
people
says
it
should
be
changed
to
2,
wiith
and
others
should
be
said.
It
should
be
changed
to
5s.
I
can
go
back
with
between
atthenes.
Is
it
3?
Is
it
3
right
now
there's
the
reward.
K
N
We
can
also
make
the
general
statement
that
if
we
do
delay
the
Obama
do
not
change
the
block
reward
than
overall
inflation
over
time
increases,
and
so
there's
sort
of
this
I
guess
maybe
philosophical,
maybe
economic
question
about
which
is
the
intended
issuance
schedule.
Is
it
kind
of
the
issue
and
schedule
it
exists
with
the
bomber
without
it.
J
Think
what
he
was
implying
is
on
a
chain
that
has
the
difficulty
upon
issuance
actually
goes
towards
towards
zero
and
so
changing
the
disc
aging
they
block
reward
to
two
or
two
smaller,
while
at
the
same
time
delaying
the
difficulty
bomb
actually
increases
issuance
or
like
stabilizes.
This
ruin,
which
is
different
than
what
would
happen.
If
you
did
nothing
I,
don't
know
if
I
necessarily
agree
with
that,
but
I
think
that
was
his
intention.
N
Hear
you
now
go
ahead,
I
got
a
phone
call,
I'll
input.
Some
reason.
My
audio
cut
out.
Sorry
about
that.
I'll
repeat
what
I
said.
If
someone
else
wants
to
clarify,
please
do
I
was
just
saying
that
if
we
were
to
make
the
decision
hypothetically
to
postpone
the
difficulty
bomb
but
not
to
change
the
black
rewards,
then
if
you
kind
of
look
at
overall,
if
their
issuance
overall
time
going
forward,
it
goes
up
as
a
result,
because
the
block
times
come
down.
Does
that
make
sense,
I
see.
A
N
But
so
then,
this
leads
to
this
very
interesting
sort
of
economics
lesson
what
question
which
is
like
what
is
the
quote:
unquote
intended
issuance
schedule.
You
know
that
the
market
is
factoring
in
so
to
speak.
Is
it
the
issuance
schedule
with
or
without
the
difficulty
bound,
and
this
goes
back
to
the
question
I
asked
before,
which
is
like:
do
we
intend
to
keep
it
forever
or
not?
So
it's
all
kind
of
tangled
up,
but
I
would
be
very
curious
to
hear
what
vitalik
and
others
have
to
say
about
that
yeah.
J
Argument
to
afford
the
reduction
I,
don't
know
if
that
completely
I,
don't
know
if
that's
the
original
intent
of
the
difficulty
mountains,
but
the
original
just
in
terms
of
the
difficulty
Vaughn
was
to
mood
for
the
steak
which
would
ultimately
and
greatly
reduce
issuance.
So
if
you
want
to
piggyback
on
that,
this
is
kind
of
in
the
spirit
of
the
original
difficulty
balm,
because
it's
a
reduction,
but
it's
not
the
move
to
prove
mistake.
So
you
know
it
is
very
tangled.
J
I
think
that
with
the
IP
1011,
I
did
put
out
kind
of
an
analysis
of
the
etherion
mining
reward
and
how?
If
you
look
at
it
in
comparison
to
some
of
the
other
block
chains,
especially
even
like
Bitcoin
Bitcoin
cash,
that
we
are
overpaying
and
that
a
reduction
we'd
still
be
extremely
competitive,
proof-of-work
blockchain,
but
some
of
that
was
some
of
that
analysis
was
one.
It
was
to
move
two
to
one
ether,
and
it
was
also
with
the
assumption
that
we
gained
security
with
proof
with
the
overlay
of
proof
of
stake.
J
J
Think
that
the
conversation
they
need
to
be
talked
about
at
the
same
time,
I
think
at
least
a
lot
of
people
in
the
community
wanted
to
be
talked
about.
At
the
same
time,
the
the
fear
would
be
if
you,
if
there
are
a
lot
of
Asics
my
network
and
you
do
reduce
the
block
award,
then
that
would
increase
that
would
reduce
kind
of
the
consumer
minors
and
essentially
just
have
more
and
more
a
secure,
Network
I,
don't
know
how
much
validity
there
is
sex
I,
don't
nominate
they're
out
there
and
what
the
exact
specs
are.
N
Interesting,
okay,
just
one
thing
to
add:
you
had
suggested
decoupling.
These
two
and
you
said
I
think
you
said
on
the
grounds
that
one
is
sort
of
purely
technical,
meaning,
postponing
the
bomb
and
the
others
economic
and
technical
I.
Guess
what
I'm
suggesting
is
that
they're?
Actually
both
economic
and
technical
and
I'm,
not
personally
convinced
that
it
should
be
decoupled
but
obviously
open
to
what
others
have
to
say
about
that
yeah.
A
F
Yeah
sure
I
just
stepped
up
to
write
this
proposal,
a
templated
based
on
six
for
nine,
which
we
used
for
the
Santiam
fork.
It's
basically
the
same,
mechanics
delaying
it
by
three
million
blocks
and
decreasing
block
reward
by
roughly
thirty
percent
and
I
have
actually
a
strong
opinion
on
not
separating
block.
F
This
means
we
significantly
changed
issuance
model
officer
and
inflation
model,
and
that's
why
I
think
they
have
to
be
in
one
proposal.
This
does
not
mean
I'm
super
convinced
that
the
numbers
I've
chosen
for
this
proposal
are
the
best
numbers
I'm
up
for
suggestions,
but
I,
guess
it's
a
good
start
to
discuss
it.
M
Have
one
just
stepping
into
the
sentiment
and
especially
what
piper
mentioned
that
it
is
a
force
that
we
do
something
every
certain
amount
of
time,
and
especially
I,
don't
know
the
number,
but
the
proposal
from
a
free
says
that
the
the
timelines
are
shifted.
I
had
to
like
mid
2020
and
I
wonder
if
there
is
any
sentiment
to
if
any
change
is
made.
It
should
only
give
us
time
for
12
months
so
there's
at
least
one
change
every
12
months,
so
practically
a
heart
for
every
12
months.
Or
is
there
any
such
time?
A
A
H
There
was
a
discussion
at
Def
Con
last
year
and
I
think
we
were
tossing
around
numbers
between
9
months
and
18
months
with
nine
months
feeling
way
too
short
and
18
months,
sometimes
feeling
long.
So
one
year
is
something
that
I
at
least
could
get
behind,
but
I
agree.
There
should
be
discussion
because
this
affects
everybody
and
we're.
A
Yeah,
that's
true,
actually
yeah
it's,
but
it
would
be
about
a
year
interesting,
I
think
having
them
once
a
year
is
probably
an
okay
thing,
even
if
we
especially
if
we
decided
to
have
two
in
a
year
or
something
that
could
also
be
a
posit.
That
seems
a
little
short
though
actually
yeah
having
them
once
a
year
is
not
a
bad
deal.
I
think.
F
We
have
two
unrelated
discussions
here
right
now,
because
we
don't
want
to
delay
its
difficulty
bump
twice
per
year,
I
guess
or
once
per
year,
I
just
just
I'd
say
we
want
to
just
delay
it
or
disable
or
whatever
we
decide
in
future
whenever
necessary,
but
not
certainly
with
every
fork.
So
it
might
be
a
good
thing,
a
good
practice
to
say:
okay,
that's
just
delays
a
bomb
by
another
18
months,
for
instance,
so
we
have
like
a
buffer
of
time.
In
case
we
have
longer
schedule
to
do
hard.
Forks
delayed,
I
think.
H
A
J
A
A
Devs
call,
even
though,
generally
I
wouldn't
like
something
like
the
fellowship
of
a
theory
of
magicians
updates
to
be,
and
the
core
dev
meeting
I
think
that
this
gathering
they
recently
had
is
important,
but
the
IP
one.
Thanks
for
sharing
that
I
agree,
we
should
discuss
this
more
in
the
next
call.
One
super
super
quick
thing:
that's
just
maybe
worth
mentioning
is
that
the
Fellowship
of
the
theory
of
magicians
is
planning
another
gathering,
I
believe
in
Prague.
It's.