►
From YouTube: Ethereum Core Devs Meeting #74 [2019-11-01]
Description
A
Hey
everybody
and
welcome
to
today's
core
developer
meeting
number
74
we're
gonna
go
through
the
agenda,
mostly
we're
going
to
talk
about
the
Istanbul
block
number
that
was
accepted.
That
was
suggested
by
dan-o
and
affirmed
by
a
few
others
in
the
gaiter
chat
and
we'll
also
go
over
the
Berlin
hard
fork
a
little
bit
to
talk
about
some
of
the
tentatively
accepted
EIP
s
get
some
testing
updates
out
of
the
way,
and
we
should
be
good.
So
this
might
not
be
a
huge
call
today.
A
A
Six,
nine
nice.
So
let
me
just
type
that
in
real,
quick,
okay,
I
have
that
for
the
record
and
whoever
note-taking
can
also
talk
about
that
in
the
notes
that
that's
the
number
we
picked
on
getter.
So
that's
one
of
the
decisions.
Are
there
any
other
Istanbul
updates
from
clients
or
the
tests
net
or
anybody
or.
A
Great
okay
and
then
coin
desk
did
correct
their
article
on
that
so
yeah.
If
there's
no
other
updates,
I
guess
another
thing
to
think
about
is
when
our
clients
going
to
release
their
updated
client
that
has
the
block
number
attached.
Is
that
gonna
be
kind
of
weeks
away
like
we
should
check
on
that
next
coordinated
meeting,
I.
D
A
A
A
C
A
A
F
A
I
A
F
E
A
B
F
F
The
this
is
the
VIPs
from
this
from
the
hard
fork:
Istanbul
EAP
1679,
that's
the
source
of
truth
from
that
and
they
included.
A
IP
is
re
IP
152,
which
adds
blake
to
compression
function,
e
IP,
1108,
reduced
alt,
BN,
128,
precompiled,
gas,
cost
ya;
13:44,
add
gene
opcode
ya,
be
1884
repricing
for
tree
size,
dependent,
op
codes,
VIP
2028
called
that
gas
gosh
called
got
call
to
call
data
gas
cost
reduction,
the
IP
to
two
zero
zero
rebalance
net;
metered
s
store
gas
cost
with
consideration;
wrestler
gas
cost
change.
A
Okay,
yeah
I
actually
got
off
an
e,
a
call
earlier
where
they
did
like
formal
stuff
like
III
I'm
like
gonna
table
this
meeting
and
stuff
like
that
and
I
was
like.
Oh
man,
we're
not
that
we're
not
as
organized
as
that,
but
sometimes
those
are
unnecessary.
It
depends
so
we've
just
moved
everything
in
the
Istanbul
meta
EEP
to
and
the
meta
EEP
itself
to
final,
it
looks
like
is
that
accurate.
A
A
F
A
C
J
K
J
Deb's
meeting
I
remember
us
at
least
talking
about
doing
the
EEP
centric
process,
which
implies
that
we
would
not
be
selecting
eeap's
for
the
next
hard
work
and
that
we
would
not
be
specific.
I
mean
we
can
set
a
date,
but
in
terms
of
selecting
eeap's
and
things
like
that,
I
was
under
the
impression
that
the
concept
of
the
EEP
centric
process
was
completely
opposite
of
that,
as
in
we
don't
select,
beeps
am
I
missing
something,
although.
F
That
was
also
kind
of
one
of
the
points
that
I
was
bringing
back
to
with
making
the
discussion
around
available
time
slots
and
in
what
are
the.
What
is
the
time
that
things
would
need
to
be
ready
to
get
into
any
of
those,
and
then
we
can
work
from
there.
Not
we
not
as,
and
we
as
a
group
decide
what
the
IPS
but
Wiz
and
the
entire
core
deaf
community
decides
what
the
IPS
get
in,
depending
on
which
ones
actually
get
done
in
time.
F
But
knowing
that
the
dates,
because
we
are
running
into
the
hardware
unit
above
the
like.
Yes,
it's
the
EIP
centric
model,
but
we
do
know
within
marched
to
June
we're
going
to
need
to
have
some
four
to
have
an
update
for
the
Ice
Age.
So
we
have
a
little
flexibility
on
when
exactly
that
happens,
but
having
a
good
time
line
of
this
many
weeks
before.
That
is
the
announcement,
so
that
or
what
are
the
steps
that
need
to
happen
before
that?
Then
we
can
work
backwards.
F
K
J
That
sort
of
is
like
okay,
we
have
a
hard
upper
limit
or
or
whatever
of
when
we
can
for
for
the
longest.
However,
that
means
that
we're
like
sort
of
sitting
on
this
concept
of
EEP
centric
working
for
months,
really
I
think
what
we're,
if
we're
going
to
like,
follow
this
eccentric
model.
Then
we
are
looking
at
clients
finishing
up
this
current
pending
hard
work
and
then
pretty
much
immediately
after
that
clients
can
start
signaling
that
they
support
the
new.
J
F
So
they're
test
nets
need
to
be
launched
for
a
certain
amount
of
time,
and
then
that
has
to
be
then
there
has
to
be
a
certain
amount
of
time
for
clients
to
upgrade.
So
we
couldn't
fork
next
month,
but
we
couldn't
fork
in
two
months
could
be
fork
in
three
months
so
having
the
upper
and
lower
bound
of
time
and
then
keeping
it
same
for
implementers.
C
It
seems
like
you're
kind
of
incurring
all
this
overhead
and
coordination
for
just
a
single
EEP
and
and
so
I
I
feel
like
it.
A
kind
of
middle
ground
approach
might
make
sense
where
it's
like.
Yes,
we
probably
want
to
set
some
dates
where
the
upgrade
happens,
but
we
probably
don't
want
to
move
that
date
based
on
things
not
being
ready
yet,
whereas
this
is
kind
of
what
we've
done.
Historically,
it's
like
we
say:
there's
these
five
beeps
and
like
one
being
late,
can
be
laid
the
whole
upgrade.
C
But
if
we
said
something
like
I,
don't
know,
we
have
an
upgrade
in
May
going
live
on
main
net.
Therefore
we
need
something
in
April
on
the
test
nets.
Therefore,
we
need
client
implementations
by
March,
something
like
that,
then,
whatever
is
not
implemented
by
March
is
just
not
included
and
and
and
then
the
community
can
use
that
as
a
signal
to
make
sure
they
have
their
implementations
ready.
But
we
just
kind
of
commits
they're,
not
changing
those
dates
based
on
on
the
amount
of
each
that
are
done.
I.
E
J
A
That's
fine,
so
basically
I
I
see
what
you're
saying
and
what
I
remember
from
the
step,
which
also
is
just
memory,
is
that
we
kind
of
decide
it
in
the
same
way.
We
would
normally
decide
an
EIP
as
far
as
should
this
go
in
or
not,
but
there
would
be
things
that
would
happen
beforehand,
like
it
being
fully
SPECT
out
a
conversation,
fully
happened
and
implementations
somewhat
started
right,
I
think.
E
My
understanding
would
be
similar
to
yours
had
some.
The
first
step
would
be
that
the
the
Aqua
devs
whenever
in
UAP
is
proposed.
Aqua
devs
would
give
an
opinion
whether
it's
a
good
idea
in
general
or
not,
and
that
is
practically
the
same.
What
we
have
under
the
tentatively
accepted
in
the
burden
list,
I
would
say
we
gave
a
blessing
that
those
generally
makes
sense
to
work
on,
but
then
those
who
propose
them
have
to
work
on
on
specking
them
out
creating
tests
and
likely
creating
the
implementations
and
I.
E
A
We
need
to
reconcile
with
the
fact
that
there
is
an
ice
age
and
that
we
need
to
have
some
types
of
timelines
for
when
the
ice
age
hard
fork
needs
to
happen,
but
then
for
other
AIPS,
it's
less
important.
So
and
then,
of
course,
the
like
Tim
was
saying
the
overhead
of
having
roughly
a
two
to
three
month
period
for
implementation,
testing
and
or
like
test
net
testing
and
then
deployment
by
major
providers
as
overhead
that
we
would
need
to
also
keep
in
mind
so
juggling
all
that
we
might
need
to
better
specify
on
paper.
A
J
Good
reading,
through
the
process,
the
suggestion
is
that
there's
the
blessing
that
there's
the
implementation
and
then
there's
clients
are
released
with
the
ability
to
turn
the
EEP
on
at
a
specific
block
number
and
then
there's
the
awkward
EV
sort
of
finalization
step.
That
happens
where
clients
are
capable
of
turning
it
on
their.
J
The
implementations
are
done,
testing
it's
done,
and
then
at
that
point
block
numbers
can
be
chosen
and
the
fort
can
happen,
and
at
that
point
those
block
numbers
can
define
multiple
eeap's
that
are
gonna,
go
on
or
just
a
single
one
or
whatever.
But
the
idea
there
is
that
we
don't
set
dates
at
the
beginning.
We
set
dates
at
the
point
at
which
there
is
fork
ready
material
ready
to
go.
J
F
So
you're
I
think
I'm
having
two
conversations
at
the
same
time.
I
think
it's
what's
happening
because
there's
among
us
core
dev
saying
when
are
we
going
to
fork
and
to
decide
it?
Isn't
it's
less
of
the
direction
of
at
the
same
time,
we
as
Cortese
are
speaking
to
the
community
saying
that
there's
this
real
that
there's
this
realistic
upper
bound
of,
say,
June
that
something
needs
to
be
done.
There's
a
realistic
three-month.
It
needs
to
have
three
months
before,
like
test
nets
are
alive
before
really
anything
can
happen.
F
So
if
you,
if
you
take
those
two
dates
together,
then
you
have
April
May
June,
that's
available
for
for
the
Istanbul
and
if
we
keep
to
like
one
thing,
I
really
like
from
Danis
proposal
is
keeping
to
the
third
Wednesday
of
every
month.
If
we're
going
to
have
a
fork,
it
should
be
on
the
third
Wednesday.
Then
we
have
sort
of
three
third
Wednesday's
that
are
available.
F
One
of
them
will
definitely
need
to
have
the
hard
fork
that
needs
to
have
the
update
for
the
ice
age,
but
as
far
as
the
state
of
all
the
other
AI
peas,
we
don't
want
to
make
the
decision
of
what
date
it's
going
to
be.
But
just
as
that
gets
closer,
we
will
have
to
make
a
decision
whether
or
not
we
wait
one
month
to
put
it
in.
So
we
can
have
something
else.
F
We
don't
want
to
wait
super
long
time
and
have
as
men
of
vips,
because
that
also
will
miss
throughput
so
somewhere
in
the
middle
of
hey,
let's
keep
to
the
third
Wednesdays
every
of
every
month
and
have
a
good
runway
that
is
like
the
most
the
best
runway
of
when
things
need
to
happen
of
previous
to
that
date.
And
then,
when
things
are
ready,
we
can,
as
things
become
ready
in
the
IP
centric
frog
process,
which
is
what
we'll
be
doing
as
core
devs.
A
J
Works
for
me
for
that
specific
conversation,
I
would
propose
whatever
that
first
one
is
so
basically
the
soonest,
seeing
as
we're
trying
this
new
process
out
and
quicker
iteration
cycles.
Basically,
anybody
opposed
to
that
or
opposition.
This
isn't
like
a
binding
thing.
This
would
be
more
just
where
we're
targeting
for.
F
A
Because,
realistically,
we
can
decide
on
implement
and
do
test
for
e
IPS
within
a
you
know,
three
to
four
week
period
right
is
that
is
that
actually
all
depends
on
the
EIP,
obviously
in
the
complexity,
but
for
a
lot
of
these
that
already
have
work
done
on
them.
It's
gonna
be
easier
to
get
that
done
sooner.
A
Yeah
and
the
champion
will
be
pushing
for
that
is,
that
is
that
we
also
came
to
the
conclusion
that
the
champion
will
be
more
coordinator
for
the
EIP
and
pushing
for
things
like
tests
to
be
created
and
corden.
Coordinating
that
right.
Yes,
okay
and
I
knowwe
said
that
they
want
to
remove
their
name
from
some
of
the
ones
they've
been
championing.
So
I
had
a
question
for
way
about
that.
A
Did
you
have
someone
in
mind,
or
anyone
who
stepped
up
to
take
over
some
of
the
e
IPS,
that
you
will
no
longer
be
championing,
or
is
that
something
where
we
should
just
ask
an
accord?
Dev
meeting
cuz
I
fear
that
some
of
the
IPS
I
thought
the
account
versioning
when
you
were
talking
about,
is
also
a
prerequisite
to
other
a
IPS
that
other
people
are
championing.
Is
that
accurate.
K
Six-Six
treat
unlimited
swipe
and
dual
instructions:
nice
talkin
versioning,
so
that
might
be
one
but
I
think
like
what
I
was
saying
is
just
it's
just
that
I
won't
be
able
to
do
the
the
champion
rule
like
I'm
I'm.
Just
don't
have
enough
time
to
do
all
the
coronation
and
take
like
he's
a
little
bit
too
policy
political
for
me.
So
I
think
it's
better
to
I.
Don't
have
any
anyone
to
Amman
to
champion
the
conversion.
A
Ok,
that
sounds
very
reasonable,
and
so,
instead
of
immediately
removing
it
I
propose
that
we
still
keep
it
in
there
and
to
see
if
anyone
wants
to
champion
it
over
the
next
two
weeks
before
the
meeting.
So
we
don't
remove
it
and
then
immediately
have
to
riad
it
cuz.
That's
just
annoying,
because
it
sounds
to
me
like
someone
will
step
up
if
it
affects
other
AIPS
that
someone
else
is
championing.
That
just
seems
to
make
sense.
Yeah
pour.
F
Some
context
for
that
there
were
a
bunch
of
VIPs
that
were
gated
by
some
kind
of
account
versioning
none
of
those
got
into
constant
noble.
So
that's
why
I
count
versioning.
It
was
pushed
till
when
we
need
it
so,
whether
it's
specifically
ways
or
something
else's
proposal
account
versioning
will
need
to
happen
for
certain
changes
to
be
implemented.
F
A
K
And
I
also
want
to
give
a
notice
conversion,
because
I
think
we
actually
have
I
mean
I
have
a
sophistication
that
I
try.
Some
of
the
previous
concerns
like
when
was
the
last
time
when
we
talked
about
our
conversion.
Ii
resistance
was
mostly
that
because
we
need
to
introduce
our
conversion
every
six
months,
so
that's
not
doable,
but
I
have
a
specification
that
basically
just
make
sure
we
can
change
gas
code.
K
A
K
B
That
we
would
benefit
from
a
validation
step
that
would
do
things
that
have
covered
a
lot
of
what's
in
there,
such
as
keeping
invalid
opcodes
out
including
begin
block
data,
but
there's
also
some
coordination
that
needs
to
go
on
with
the
solidity
community.
That's
there
at
least
to
make
sure
that
there's
warm
URLs
or
click
behind
or
there's
found
stuff
is
behind
that
call
data.
So
I,
don't
think
what
we
need
to
get
done
is
doing
in
the
Berlin
timeframe
is
reasonable.
K
A
A
C
Why
not
just
have
like
a
blessed
section
in
the
meta
like
you're,
literally
renaming
tentatively
accepted
to
bless
or
green
light
or
whatever
it
is
that
was
in
the
process?
I
think
it's
valuable
for
the
point
people
towards
like
you
know
this
is
likely
what's
going
in,
it
doesn't
have
to
be
a
super
strong
commitment,
but
otherwise
it's
already
hard
for
people
who
are
not
attending
this
call
to
keep
track
of
all
the
work
that's
going
on
so
I,
even
if
it
doesn't
purely
reflect
the
process.
C
F
F
A
F
Is
but
it
but
saying
that
it's
blessed
for
Berlin
is
no
longer
really
accurate
from
how
we
are
looking
at
e
IPS
from
the
forks
Hendrick
model,
but
Tim
is
pointing
is
pointing
out
a
very
good
part.
That's
missing
is
a
list
of
what
are
the
blessed
di
peas
in
the
first
place
for
people
to
look
at
so
that
should
exist
somewhere
yeah.
B
A
J
A
F
That's
I,
don't
think
we
that's
where
I
would
motion
that
we.
This
is
just
a
suggestion
that
we
have
the
list
that
it
was
the
list
of
tentatively
accepted
VIPs.
It's
not
so
important
that
we
go
through
each
one
and
talk
about
them
unless,
but
we
should
move
them
like
I
would
move
that
all
of
those
and
we
can
go
through
my
number-
get
moved
to
a
plus
state
and
then
I'll
create
a
an
EIP
for
bless
di
peas
and
then
put
they
put
those
in
there.
No.
A
L
If
you
track
the
discussion,
it
tapers
off
with
no
with
no
actual
consensus
on
whether
they
should
be
moved
forward.
Sometimes
there's
options
and
it's
not
clear.
An
option
was
actually
chosen
in
the
unlimited
swap
and
Duke,
there
appeared
to
be
a
show
stopper
on
the
preferred
option
and
I
didn't
see
any
any
way
around
that
that
was
presented.
A
Got
it
so,
for
today's
call,
there's
definitely
gonna
be
some
low-hanging
fruits
of
EITS
that
are
in
the
tentatively
accepted
list
that
have
agreement
and
implementations
that
we
can
say
are
blessed.
There
are
also
ones,
as
you
pointed
out,
that
still
have
disagreement,
may
not
be
blessed
or
because
that's
a
new
thing
we're
doing
or
might
be
in
somewhere
in
the
middle,
in
which
case
they
wouldn't
be
blessed,
and
they
would
stay
in
this
unknown
state
until
more
research
is
done
and
more
discussion
happens
on
them.
Yeah.
A
A
E
Well,
just
one
comment
regarding
the
blest
status.
My
understanding
of
that
is
it's
just
a
green
light
that
the
idea
in
general
may
be
good,
but
that
only
means
that
work
has
to
be
done
to
spec
it
out
properly,
and
it
doesn't
mean
anything
more
and
under
that
understanding.
I
do
think
that
663
does
fall
under
that
category
and
then
the
actual
update
I
wrote
this
a
couple
of
days
ago
on
the
Gator
channel
that
yes
Greg,
you
were
correct
here.
E
A
couple
of
options
and
the
preferred
option
had
an
issue
discovered
and
resolution
of
that
is
that
it
would
need
to
go
behind
account
versioning.
So
it's
basically
blocked
by
debt.
I,
don't
think
there
was
any
anybody,
preferring
any
of
the
other
options.
I
think
there
was
convergence
on
that
single
option
which
realized
in
account
versioning.
E
Last
call
process
had
it
applies
to
core
piece
in
general,
but
I
think
the
confusion
is
that
the
the
blessing
only
means
that
people
should
work.
I
mean
the
champions
here.
Whoever
wants
to
work
on
it
should
work
on
it,
but
it
doesn't
mean
anything
else.
We
don't
need
to
be
concerned
any
any
more
than
that
exists.
J
L
F
I
would
say
from
the
community
side:
they
also
have
a
problem
of.
Do
we
even
get
this
AI
pee
to
like
how
much
work
is
it
going
to
take
to
get
the
total
specification
and
the
test
done?
Is
it
even
worth
doing
so
for
them
validating
that?
If
they
went
through
this
work,
it
would
be,
it
would
be
at
likely
at
least
talked
about
seriously
that
and
that's
discussion
of
being
blessed.
It
doesn't
have
to
be
a
long,
drawn-out
discussion
about
specifications
and
such
it's
just.
F
L
You,
but
if
you
really
care
about
something
you're
going
to
put
the
work
into
it
and
you
can't
be
asking
the
community
for
for
blessing
for
something
they
haven't
seen
yet
yeah.
There's
is
sort
of
your
problem
to
feel
out
the
community
and
yeah.
If
you
really
need
to
push
it
to
our
level.
Fine,
but
mostly
I,
don't
think.
A
L
L
L
L
E
Partially,
but
I
just
wanted
to
reflect
you,
the
the
previous
conversation
that
the
under
Martin's
VIP
centric
proposal,
what
we
have
been
discussing
in
the
first
half
for
majority
of
this
meeting.
The
blast
status
only
means
that
nobody
objected
for
the
idea,
but
then
there
is
no
there's
no
work
put
on
the
shoulders
of
the
client
developers.
E
Having
these
blast
doesn't
mean
that
a
client
developers
have
to
work
on
this,
it
only
means
that
those
who
propose
them
where
I
interested
in
them
they
have
to
work
on
it.
Okay,
so
that's
the
status
of
the
particle
gas
ghost
as
well.
I,
don't
think
there
was
an
objection
to
the
idea,
but
now
it's
it's
it's
on
the
shoulders
of
those
who
proposed
it
or
are
interested
to
spec
it
properly.
L
A
C
Think
so
maybe
I
missed
this,
but
I
don't
think
we
actually
had,
like
a
final
say
on
1702
like
I,
feel
like
the
conversation
kind
of
got
sidetracked
and
it
seems
like
we
all
were
kind
of
agreeing
to
remove
it
from
the
list.
But
I
just
want
to
make
sure
that
you
know
it's
like
an
explicit
agreement
and
not
just
implicit,
not.
B
F
A
A
B
B
Presentation,
one
of
the
concerns
that
Martin
brought
up
was
that
it's
just
not
very
well
spec
and
it's
very
dependent
upon
a
single
implementation,
which
I
agree
is
a
huge
barrier
that
it
would
a
spec
says,
use
this
implementation
that
presents
a
systemic
risk
to
the
way
we
do
with
these
material.
So
I
think
it
would
be
good,
but
what
we
need
is
for
the
champions
to
go
through
and
give
better
specifications.
I
know
in
the
theory,
magician's
threat.
B
I
asked
them
to
split
out
into
about
four
different
pre-compiled
calls,
rather
than
jamming
everything
in
one
freaking
file
call
with
a
bunch
of
magic
set
up
in
the
in
the
call
structure
that
has
yet
to
be
reflected
to
the
EIP,
so
I
think
it's
a
good
idea
to
provide
it
general
interface
to
all
the
EC
curves
and
let
them
be
parametric
based
off
one
of
the
parameter
verses
which
curve
but
I.
It
needs
work
from
the
champions.
B
A
E
So
there
were
some
work
on
it.
Those
benchmarks
are
listed
on
the
e3
Magicians
links,
the
discussion
URLs
for
those
the
IPS,
and
if
the
defcon5
videos
for
the
workshops
go
live,
there
was
an
EVM
panel,
and
this
topic
was
discussed
there
for
a
couple
of
minutes.
So
that
might
be
interesting
to
watch
if
they
take
a
life.
E
I
feel
bad
speaking
again,
but
the
the
hope
with
that
is,
it
can
be
applied,
retroactively
Leigh
without
the
need
of
a
hard
fork,
and
there
was
only
one
one
I
think
one
limit
which
was
questioned,
whether
that
would
require
a
hard
fork,
and
this
discussion
is
there
on
the
human
magicians,
discussion,
URL,
I
kind
of
hope.
This
won't
even
need
to
be
part
of
our
effort.
A
E
B
B
Point
three
for
the
calls
that
operate
on
an
address-
sorry,
not
accounts.
I,
address
size
on
them.
Fraud,
proper
actions
operate
on
an
address
limits.
It's
165
bits
of
something
in
bit,
161
to
hire
as
part
of
that
operation
to
the
operation
fails.
You
did
ignore.
It
should
have
treated
as
zero.
There's
I
think
some
things
that
although
I'll
make
a
discussion
and
the
theory
magicians.
It's
very
technical
question.
A
A
We
did
my
bad.
Alright,
the
only
one
left
is:
oh
no
prog
pal,
so
yeah
prog
pals
on
here.
What's
everyone's
feeling
on
prog
pow,
we
kind
of
know
we
I
guess
we
all
agreed
on
it
a
couple
of
times,
so
we
don't
really
need
to
rehash
the
entire
thing,
but
there
has
been
some
community
sentiment
that
they
don't
want
it
in.
A
For
me
personally,
it's
hard
to
tell
if
it's
a
few
loud
voices
or
the
actual
majority
of
the
community.
That
would
you
know,
find
this
thing
to
matter
to
them
and
stuff
like
that.
Anybody
here
have
a
perspective.
They
want
to
share
on
that.
Otherwise
this
was
already
and
blessed
state.
In
my
opinion,
it's
already
been
implemented
mostly
at
least
the
zero
point.
Nine
point
two
version
implemented
so.
C
One
question
I
would
have
for
this
group
about
Prague
Pal
is
given
that
there
is,
you
know
at
least
some
controversy
either
way
and-
and
it
seems
like
some
of
it
also
comes
down
to
like
a
values.
Questions
like
some
people,
just
you
know,
seem
to
believe
that
basics
are
fine.
Some
people
believe
we
should
optimize
for
GPUs
and
you
can't
really
reconcile
those
two
things.
Just
like
a
fundament
know
like
difference
in
belief
if
we
were
to
implement
it.
Is
this
something
we'd
want
bundled
with
other
AI
P's?
C
Is
this
something
we'd
want
a
way
for
like
the
community,
the
signal
you
know
through
their
nodes,
whether
or
not
they
want
it
like?
Do
you
do
a
single
prog,
pal
yeah
hard
fork
and
that's
a
question.
I've
been
thinking
a
lot
and-
and
you
know,
do
we
value
sort
of
user
choice
maximally,
even
though
having
like
a
single
VIP
upgrade
would
like
increase
the
risks
of
the
network
spilling?
Do
we
value
keeping
the
network
together
so
like?
C
Even
if
we
include
prog
pal,
we
don't
give
it
any
special
treatment
and
we
include
it
with
the
other
heaps
in
the
hopes
that
people
just
upgrades
to
the
entire
upgrade
so
I'm
curious
with
people's
perspectives
are
just
on
that
like
if
you
were
to
go
through.
You
know
house
how
much
or
little
do
we
want
to
change
your
process.
Yeah
I'll,
stop
there.
F
J
Yeah
I
just
may
be
expressing
a
common
sentiment,
or
maybe
it's
just
my
own,
but
I
am
just
born
down
on
this
topic
and
mostly
don't
care
I'm
being
brutally
honest
and
I'm
willing
to
implement
it
in
our
client.
If
that's
what
everybody
else
wants
to
do,
but
otherwise
I
have
no
desire
to
put
energy
towards
it.
J
It
is
strictly
a
there's
other
things
that
are
higher
priority
and
it
seems
like
a
distraction
and
I'm,
maybe
going
to
get
railed
on
the
internet
for
saying
that,
but
but
that's
where
I
stand
I'm
not
opposed
to
it,
I'm
not
going
to
advocate
for
it
or
run
with
it,
unless
everybody
else
is
doing
it.
So
that's
where
I
am.
A
J
I
did
really
love
the
idea
of
if
everybody
really
wants
this
so
much,
and
if
miners
really
want
this
so
much,
then
shifting
a
percentage
of
minor
rewards
to
go
towards
core
protocol
development
as
part
of
it
sort
of
like
a
payment
for
the
time
and
energy.
That's
also
probably
an
extremely
controversial
idea
and
not
something
that
I'm
looking
at
us
hashing
out
on
this
call,
but
mostly
my
resistance.
Is
that
it's
a
distraction
for
me
and
there
are
other
things
that
feel
like
they're
more
important.
L
Think,
there's
anything
technically
about
it.
It
should
have
been
a
big
distraction.
There's
there's
algorithm,
there's
the
code,
you
write
it
and
you
plug
it
in
and
it
takes
some
time
but
yeah
and
I
think
we
are
all
completely
worn
down.
You
pretty
much
said
yes
at
this
point.
More
than
once
we
look
for
technical
problems.
We
haven't
found
technical
problems.
C
A
Yeah,
we
still
don't
really
have
a
way
to
reconcile
non-technical
concerns,
very
well
which
sucks
an
EF,
I
literally
I,
think
I
just
said
the
words
this
looks
blessed
to
me
and
I
bet.
That's
gonna
be
like
quoted
on
Twitter
and
everyone's
gonna
be
like
Hudson's
evil.
He
is
pushing
the
ip's
through
so
yeah
I'm,
ready,
I'll,
say
come
at
me
twice.
L
L
A
F
A
B
A
Would
say
that
we
should,
if
we
bless
it,
we
should
keep
in
mind
that
the
towel
did
just
release
something
called
slim
1559,
which
is
a
less
complex
implementation
of
it.
That
does
trade-offs
for
how
like
how
nice
it
were.
What's
it
called?
Basically,
the
improvements
that
would
provide
would
lessen,
but
the
complexity
would
lessen
as
well
and.
B
That's
why
I
think
it's
a
great
example
of
the
IKEA
hood
process,
because
you
come
up
with
an
idea
and
you
find
changes
that
you
should
make
along
the
way
before
you
come
back
with
final
approval.
So
I
think
that's
that's
great,
that
it's
going
through
these
evolutions
and
being
bought
through
and
we
get
a
prototype
that
reflects
what
they
think
is
the
best
idea
to.
A
C
A
F
F
A
B
M
B
C
J
C
L
A
A
E
B
Yes
and
I,
I
think
more
than
just
provisionally
I
think
we
should
also
list
for
the
DI
keys
lie
on
the
new
ie
IP
process.
So
whether
when
a
champion
says
that
there
is
a
prototype
ready,
they
should
update
it
and
punch
the
prototype
many
happy.
So
people
come
folk
and
review
it.
If
there
has
been
secured
reviews
done
about
it,
they
should
move
that
the
security
review
has
been
published
and
stuff
like
that.
B
If
there's
a
security
review
needs
to
be
done
or
or
things
like
that,
and
then
when
it's
ready
to
come
up
for
discussion
for
the
final
awkward
I
was
approval.
You
know
for
client
implementation
that
should
be
recorded
there
as
well.
So
I
think
you
need
an
information
elite
covering
these
new
stages
for
from
Aaron's
model.
A
This
would
also
go
into
EIP
one,
but
it
could
be
a
basically
a
sub
e
IP
to
e
IP
1
or
something
of
that
nature
a
whole
new
e
IP.
That's
one,
that's
active
informational
that
we
can
Linda
link
to
for
me,
IP
one
for
core
dev
stuff,
specifically,
and
then
e
rc
stuff
will
stay
the
same
for
now
with
the
last
call,
and
things
like
that
until
we
update
it,
which
I'm
hoping
we'll
do
at
some
point
so.
E
K
K
C
Sorry,
just
for
visibility,
I
think
it's
actually
good.
If,
like
we
have
this
master
dist
that
you're
able
to
see
stuff,
maybe
that
maps
to
the
various
stages
of
the
EIP
centric
process
but
like
if
I'm
able
to
pull
up
the
master
this
and
be
like
hey
the
IPX
like
has
an
implementation
and
testing
and
just
like
one-click
freedom,
I
think
there's
value
there
without
it
being
like
cluttered,
I,
guess
at
most
you'll
get
like
five
or
six
bullet
points
per
each,
which
doesn't
seem
like
it's.
You
know
too
much
overhead
I.
A
K
A
B
N
A
A
A
B
H
Meeting
and
okay
sorry
just
jump
in
really
quick
earlier
in
the
call,
you
said
that
the
cat
herders
would
be
putting
out
an
update
on
his
temple.
It
was
between
the
cat,
herders
and
the
etherium
org
Blagh,
Blagh,
I,
think
for
sure
100%.
It's
got
to
be
on
the
official
blog,
not
not
to
downplay
anything
that
the
caterers
are
doing,
but
this
has
to
be
super
super,
visible
and
I.
Think
there
should
even
be
weekly
tweets
from
the
etherium
account
just
to
get
people
aware
of
this.
H
A
Okay,
that
sounds
good
to
me.
Well,
we'll
definitely
push
a
blog
out
on
the
etherium
gorg
blog
I
think
we
might
have
a
more
detailed
blog
post
from
the
cat
herders
that
is
linked
from
the
etherium
blog,
so
the
etherion
blog
will
just
say:
hey
update
your
nodes.
Here's
all
the
clients
that
you
can
update
from
for
more
information
go
to
the
cat
herders
because
they
do
all
the
other
stuff.
That
might
be
the
best
compromise
there.
Yeah.
H
J
A
Especially
when
the
hard
Forks
happen
early,
we
might
actually
say
for
people
to
upgrade
by
the
second
instead
of
the
fourth,
since
it
could
happen
early,
ok,
the
upgrade
kind
of
much
before
death
mm-hmm.
We
should
look
at
future
upgrades
having
it
by
timestamp.
Is
that,
like
really
hard
to
do
client
people.