►
From YouTube: Ethereum Core Devs Meeting #124 [2021-10-15]
Description
A
A
A
B
B
So
basically
two
big
things
on
the
agenda:
one
updates
on
the
merge
and
then
second
decisions
about
the
aero
glacier
and
the
difficulty
bomb
push
back
to
start.
I
guess,
with
updates
on
the
merge.
We
had
a
face-to-face
meeting
last
week
with
most
of
the
client
teams
in
person
to
work
on
the
merge.
I'm
not
sure
if
someone
wants
to
give
kind
of
a
recap.
I
know
a
lot
of
the
people
on
the
call
were
here.
B
To
nominate
someone,
okay,
so
I'll
give
a
high
level
and
then
yeah
people
can
fill
in
the
technical
details.
But
basically
the
goal
of
the
event
was
to
try
and
get
the
different
team
on
the
consensus
and
execution
layer
to
interoperate
with
each
other
and
to
iron
out
any
kind
of
remaining
issues
in
the
spec
and
basically
the
the
consensus
back
execution,
as
well
as
the
the
api
between
both
layers.
B
So
we
set
up
several
devnets
during
the
week,
basically
starting
one
to
one
so
one
consensus,
clients
to
one
execution,
client
and
then
kind
of
growing.
You
know
many
to
many
or
passing
multiple
one-on-ones
and
yeah.
Like
I
mentioned
towards
the
end
of
the
week,
we
were
able
to
set
up
a
kind
of
temporary
devnet
which
had,
I
believe,
100
nodes
which
ran
10
000
validators
across
a
different
set
of
clients,
and
it
started
on
a
proof
of
work.
B
Network
went
through
kind
of
the
transition
to
proof
of
stake
and
then
managed
to
finalize
on
the
other
side,
so
it
was
kind
of
a
really
good
success.
In
that
you
know
it
showed
that
we
could
get
all
these
clients
interoperating
with
each
other,
that
we
could
get
the
spec
mostly
ironed
out,
and
that
we
had
kind
of
a
clear
set
of
of
things
we
needed
to
fix
going
forward.
Talking
about
that,
I
guess:
we've
launched
a
just
a
more
stable
version
of
this.
B
This
final
devnet
called
pythos
ptos,
I'm
not
sure
how
you
pronounce
it
which
people
can
join
if
they
want
to
kind
of
really
experiment
with
with
what
the
post-merge
infrastructure
would
look
like.
There's
still,
some
spec
changes
to
be
done,
so
this
is
probably
not
the
the
final
version,
but
I
suspect,
towards
the
end
of
this
month.
B
D
Hence
the
name
and
thanks
again
paratorch
for
helping
with
the
devops
here.
If
you
need
notes
or
need
keys
to
validate
on
this
network,
let
us
know
I'll:
try
facilitate
that
and
we're
trying
to
stabilize
the
remaining
clients.
So
far
we
have
three
consensus:
clients
running
really
stable
on
the
network
and
gaff
on
the
execution
side.
Then
we're
working
on
getting
bezu
and
netermind
running
though,
as
well.
E
F
B
D
G
D
B
Yeah,
that's
a
really
good
point,
so
I
think
yeah
I
was
talking
with
danny
and
mikhail
yesterday.
I
think
there's
like
at
least
one
more
large
round
of
changes
where
they
want
to
fix
a
bunch
of
small
things.
Once
that's
up.
We
should
probably
make
that
kind
of
the
next,
the
next
milestone
for
for
people,
to
aim
for
and
and
make
it
clear
that
you
know
this
is
the
point
where
we
where
we
head
towards
and
if
there's
other
changes
we
can
kind
of
implement
it.
B
One
thing
I'll
ask:
I
know
there
was
some
progress
on
the
sink
at
the
face-to-face
and
that
the
basically
the
the
implementation
is
quite
different
from
what
felix
had
proposed
a
while
back.
Is
there
like
a
repo
or
a
spec,
or
something
that
like
kind
of
documents,
that
or
is
it
basically
the
get
pr.
H
No,
there
isn't
yet
spec,
so
we
do
want
to
update
it,
but
I
kind
of
there
are
actually
two
steps
towards
that
one.
I
need
to
have
a
long
chat
with
felix,
be
aware
of
all
the
all
the
details
and
whatnot,
and
the
other
thing
is
that
we're
also
trying
to
figure
out
one
or
two
open
questions
before
committing
to
writing
it
down.
Okay,
so
we'll
try
to
get
it
up
somewhere
asap,
but
there's
no
updated
box.
Yet.
B
B
Blog.Ethereum.Org
cool,
so
the
other
thing
we
need
to
go
over
today
is
the
difficulty
bomb
pushback.
So,
as
we
know,
the
difficulty
bomb
is
is
gonna,
go
live
sometime
in
december,
and
so,
if
we
want
to
like
agree
to
how
far
we
push
it
back
and
and
when
we
do
so
and
put
out
client
releases,
that
needs
to
happen
kind
of
soon.
So
I
put
together
a
bunch
of
different
options
and
shared
them
on
github
and
basically
there's
two
kind
of
decisions
we
need
to
make.
B
One
is:
when
do
we
want
to
push
the
difficulty
bomb
back
to,
and
when
do
we
actually
want
to
have
that
that
upgrade
so
for
the
actual
ice
age
offset
I'd
first,
propose
kind
of
a
value
that
would
push
it
around
basically
mid
april
of
next
year.
You
would
start
to
see
some
noticeable
increase
in
in
the
block
times
and
then
around
mid
may.
B
You
would
see
like
a
second
or
more
increase
in
block
time,
which
is
which
starts
to
be
kind
of
the
point
where
we
absolutely
have
to
push
it
back
and
then
I
I
also
kind
of
got
tj
rush
to
to
sanity
check.
These
numbers
he's
done
a
lot
of
work
on
the
difficulty
bomb
before
and
he
agreed
that
this
you
know
this
would
have
these
numbers
were
right,
but
he
suggested
we
should
probably
push
it
back
a
little
bit
farther.
B
So
his
proposal
was
we
push
it
back
instead
of
10.5
million
10.7,
which
means
the
bomb
starts,
the
show
around
mid-may,
and
then
we
would
have
to
push
it
back
around
mid-june
yeah
and
then
there's
a
middle
value
there,
where,
if,
if
you
don't
want
to
do
10.5
or
10.7,
you
could
do
10.6,
which
means
early
may,
the
bomb
starts
the
show
and
then
late
may
the
bomb
the
bomb
would
have
to
be
pushed
back
yeah,
I'm
curious.
What
do
people
think
about
this?
Generally.
J
B
I
guess
does
anyone
feel
like?
Does
anyone
have
a
opposition
to
the
10.7,
which
would
mean
around
mid-may,
which
is
kind
of
the
farthest
we
we
had
there
but
like
would
people
want
to
go?
We
could
obviously
do
like
11
million.
Also-
and
that's
you
know,
every
every
100
000
blocks
is
like
very
roughly
two
weeks.
Yeah
are
people
kind
of
generally,
okay
with
say
10.7,
or
would
we
want
to
go
even
even
further
to
make
sure
we
don't
have
to
push
it
back
again.
H
K
Otherwise,
we
could
just
completely
remove
the
difficulty
from
and
say
we
do
the
merge
whenever
it's
ready,
and
so
if
we
wanted
to
keep
it
around,
as
it
is
some
token
of
our
promise
to
do
this
as
like
as
fast
as
as
a
safe
merch
can
be,
then
I
think
it
only
makes
sense
if
it
has
like
a
meaningful
timeline
attached
to
it
and
say
it
only
starts
to
come
into
effect
in
the
summer.
I
just
like
I
mean
I
think,
last
alcott's
there
was
still.
K
K
I'd
prefer
just
removing
the
difficulty
bump
all
together,
so
my
weak
preference
would
be
to
to
to
go
with
the
april
timeline,
and
then
that
already
gives
us
room
to
to
by
to
the
end
of
may
or
something
and
then,
if
we
really,
they
can't
get
the
merge
done
by
the
end
of
may,
which
I
mean
yeah,
that's
definitely
an
option.
But
then
I
feel,
like
it's
more
honest
in
a
sense
to
then
have
like
a
another
kind
of
like
chosen
delay
instead
of
just
yeah
effectively.
E
So
the
difficulty
bomb
has
two
purposes.
One
is
to
make
sure
that
we
are
regularly
exercising
our
release
process
and
getting
things
out
on
a
regular,
cadence,
etc,
and
the
other
one
is
to
make
sure
that
when
the
merge
happens,
if
you
want
to
run
a
fork
of
ethereum,
you
need
to
have
a
release
pipeline.
I
think
pushing
it
out
until
summer
addresses
the
any
competitor
or
any
fork
needed
to
release
pipeline.
E
It
still
addresses
that,
because,
even
if
you
do
run
your
run,
your
fork
of
ethereum
without
proof
of
stake,
it
is
only
going
gonna
last
you
for
you,
know
three
months,
so
it
doesn't.
Do
anybody
any
good?
You
need
a
release
pipeline
and
you
get
an
extra
three
three
months
to
get
the
release
pipeline
out,
but
you
still
need
it,
and
so
I
think
pretty
much
any
date
we
choose
in
2022
solves
that
second
problem.
B
I
I
would
plus
one
that,
like
I
think,
at
the
very
least,
you
kind
of
need
a
month
right
and
people
have
kind
of
complained
in
the
past
that,
like
where
those
delays
could
be
longer
so
like
yeah,
if
you
take,
say
the
farthest
option
right
now,
which
is
like,
which
is
mid-may.
That
basically
means
mid-april.
L
H
That
kind
of
means
that
okay,
you
need
to
upgrade
one
node
see
if
it
works,
then
just
spin
down
another
node
upgrade,
etc,
etc,
and
we
essentially
tell
them
that
we
expect
this
to
take
one
month
worth
of
effort
so
that
they
can
find
the
time
to
do
this,
which
is
a
relatively
simple
task
versus
with
the
merge.
All
of
a
sudden.
You
need
everybody
to
figure
out
how
the
beacon
clients
work
to
figure
out
how
to
set
up
one
and
the
other
to
figure
out
how
to
make
them
communicate
between
each
other.
H
So
it's
a
you're
a
session
you're.
Essentially,
all
of
a
sudden,
all
your
beacon
users
that
are
just
on
the
ethernet
chain
now
need
to
learn
how
to
run
a
test
election
and
all
the
consensus.
People
who
are
here
and
one
now
need
to
learn
how
to
run
a
beacon
chain,
client,
and
I
think
you
don't
want
to
rush
that
part.
B
Right
yeah,
I
I
definitely
agree
you
don't
want
to
rush
it.
I
think
one
thing
we're
planning
to
do
is
also
is
one
we
start
having
these
devnets,
hopefully
start
to
get
people
running
on
the
devnets
before
so
that
if
they
are
a
large
infrastructure
provider,
they
don't
learn
about
this
and
start
kind
of
setting
up
their
infrastructure
when
the
main
net
releases
are
out.
But
I
do
agree,
we
probably
want
like
a
longer
delay
and
there's
a
comment
to
the
chat.
Why
do
we
have
to
pick
a
block
number
now?
B
So
the
reason
for
that
is
based
on
the
bomb
going
up
in
december
and
depending
on
when
we
want
to
push
it
back.
We
also
need
client
releases
to
be
available
like
at
least
kind
of
a
couple
weeks
before
the
upgrade.
So
so
we
can
probably
kind
of
fork
anytime
in,
like
december
later
december,
will
be
a
bit
harder
because
the
bomb
might
actually
start
the
show
and
also
it's
the
holidays,
which
is
just
not
a
great
time.
So
that
means
that
you
know.
If
say,
we
wanted
to
fork
december
1st.
B
So
I
think
basically
making
that
decision
today
means
we
then
have
a
few
weeks
for
clients
to
actually
implement
that
change
and
write
tests
for
it,
and
you
know
make
sure
that
we're
in
a
good
spot,
whereas
yeah,
if,
if
yeah,
if
we,
if
we
wait
much
longer,
then
yeah
it
it
it'll,
just
be
a
very
last
minute.
Upgrade.
L
It
seems
like
there's
two
parts
of
work
that
need
to
be
done
before
the
merge
goes
live
and
one
is
kind
of
a
dynamic
amount
of
work,
and
that's
actually
finishing
all
of
the
things
that
need
to
go
into
a
code
release
and
there's
a
fixed
portion
of
work.
That
needs
to
be
done
to
allow
for
people
to
upgrade
and
to
upgrade
all
the
test
nets.
And
it's
not
clear
to
me
how
long
that
fixed
portion
is,
and
I
think
that
it
would
be
easier
if
we
defined
exactly
what
this
fixed
portion
is.
B
B
That
means
you
probably
also
want,
like
some
test
net
releases
a
month
before
that,
and
so
that's
like
three
months
before
the
actual
merge,
and
that
means
that
you
basically
want
to
have
the
code
mostly
ready
and
then
the
spot,
where
you
can
shift
it
again
say
like
a
month.
So
that's
like
four
months
before
the
actual
merge
on
magnet
very
roughly.
C
B
E
E
H
I
mean,
I
guess
both
so
at
least
currently
what
the
gas
does
is
that
in
for
normal
forms,
that
you
have
the
fork
block
number
and
it's
not
set
for
mainnet,
but
you
can
just
we
have
a
flag
override.
For
example,
we
had
override
london,
where
you
could
well.
The
point
of
the
flag
was
to
postpone
the
fork
if
something
goes
wrong,
but
you
could
also
enable
it
if
everything
goes
right
servicing.
H
E
So
the
the
concern
is
again,
maybe
I'm
a
little
out
of
date,
because
I
haven't
followed
super
closely
in
the
last
two
weeks
back
when
you're
talking
about
this.
Previously,
the
idea
was,
we
want
to
choose
the
tt,
the
total
total
difficulty
like
a
week
or
two
before
it
happens,
because
we
didn't
want
to
wait
too
long
because
we're
worried
about
that
could
like
the
further
in
advance.
E
We
try
to
guess
it
the
more
uncertainty
we
get,
and
so
we
wanted
to
wait
until
like
a
week
or
two
before
before,
to
choose
the
ttd
and
then
the
idea
was
is
that
we
would
just
announce
to
everybody.
You
know
two
weeks
prior
to
the
that
date,
whatever
that
is
okay,
this
is
the
exact
ttd
which,
in
the
the
discussion
was.
H
Well,
my
best
guess
is
that
it
could
be
both
so
100kgps
announced.
Clients
could
do
their
releases
because
for
most
people
it's
a
lot
simpler
to
just
update
than
to
mess
with
command
line
tracks.
But
I
would
definitely
say
that
the
command
time
flap
should
also
be
available,
because
it's
always
a
good
backup
to
if
something
happens.
E
Right,
okay,
I
just
the
reason
I
bring
it
up
in
this
context
of
this
conversation
is
just
because
it
does
add
complexity
to
the
entire
merge
process
for
integrators
and
so
for
for
people,
infrastructure
providers
etc.
So
when
they
are
getting
their
stuff
up,
even
if
we
release
the
clients
two
months
before
there
will
still
be
chaos.
You
know
near
the
merge,
as
people
have
to
do
that
last
minute
upgrade
or
config
change
or
whatever.
E
Yeah,
it's
just
like
in
terms
of
messaging
the
stuff
like
the
kind
of
the
more
we
drag
it
out
and
spread
it
out.
It's
just
easier
to
make
it
clear,
like
okay,
do
this
one
thing
this
week
and
then
next
week,
you'll
have
another
thing
to
do
versus
okay!
Do
this
today
do
this
tomorrow,
it's
more
complicated
for
people
as
well.
Yeah.
B
L
B
B
Yeah
so
as
I
understand
it,
you
know
there's
still
some
some
work
on
the
spec
that
hopefully,
should
be
wrapped
up
by
like
the
end
of
this
month.
Then
you
know
we
basically
have
like
all
of
november,
probably
like
half
of
december
before
people
start
going
away
and
if
we
also
have
kind
of
the
aero
glacier
fork
in
december
that
also
eats
away
at
kind
of
the
time
there.
D
B
N
N
Yeah
we
had
a
number
of
spec
changes
that
came
out
of
the
interop.
Most
of
them
were
actually
simplifications,
and
most
of
them
have
to
do
with
the
engine
api
and
we're
working
on
those
right
now,
I'm
doing
most
of
that
mikhail
is
on
vacation
this
week,
but
we'll
be
picking
that
up
and
the
target
is
to
be
done
with
all
those
changes
by
the
end
of
the
month
and
the
general
agreed
upon
target
by
client
teams
to
get
an
a
next
version
of
like
a
persistent
test.
N
N
N
E
N
O
So
for
from
my
side,
the
hardest
part
or
saying
when
what
will
be
called
complete,
ready,
etcetera
from
the
implementer's
point
of
view,
is
all
those
disaster
recovery
edge
cases
which
like
even
though
there's,
but
maybe
we
do
know,
but
we
might
miss
some
etcetera
and
that
those
will
just
come
in
in
testing
general
specs?
Are
you
can
more
or
less.
B
Got
it
there's
a
couple
comments
in
the
chat
about
like?
What's
worse?
Is
it
you
know
pushing
back
the
bombs
two
times
or
you
know
like
what
like
alienates
the
community?
My
opinion
there
is
like
a
bad
merge
is
what
alienates
the
community
by
far
the
most
so
like
that,
should
obviously
you
know
people
will
take
a
good
merge
with
two
difficulty
bomb
pushbacks
over.
B
And
yeah,
so
I
I
don't
based
on
all
of
this,
it
does
seem
like
trying
to
get
a
date.
That's
far
enough
in
the
future,
to
give
us
some
buffer,
ideally
not
far
enough
that
it's
like
completely
irrelevant,
and
you
know
that
that
we,
we
kind
of
forget
about
the
difficulty
bomb
and
I
don't
think
it
would
be
the
end
of
the
world
to
push
back
the
difficulty
bomb.
A
second
time
from,
like
the
community
point
of
view
where
you
know
anyways.
B
At
that
point,
it's
like,
if
we've
taken
a
reasonable
delay
for
the
difficulty
bomb
and
we
push
it
back.
It
kind
of
means
that
the
merge
is
late
and
people
will
be
upset
about
that.
Not
about
the
fact
that
we're
pushing
the
difficulty
bomb
back
so
yeah.
I
I
guess
this
is
like
a
long-winded
way
of
saying.
J
It
doesn't
mean
that
we
have
to
wait
with
the
marriage
until
until
august
or
something
like
that,
so
my
preference
would
be
to
have
it
to
move
it
to
mid
summer.
So
something
like
a
nice
number
like
11
million
would
move
it
to
mid-summer
and
we
can.
If
we
are
happy
with
the
notch
and
everything
goes
smooth
with
the
notch,
we
can
do
it
earlier
than
mid-summer
by
all
means,
so
the
bomb
does
not
doesn't
force
us
force
us
to
do
the
merge
late.
B
N
N
B
Yeah,
so
I
think
there's
like
two
ways
like
one:
it's
either
you
go
with
say
I
don't
think
it
matters
if
it's
like
late
june
or
july,
and
because
it's
kind
of
far
in
a
way
you
call
it
like
the
generous
bomb
or
you
have
like
a
very
aggressive
one
that
there's
like
a
a
a
high
chance.
We
we
push
back
if
we
don't
meet
the
optimistic
timeline.
Yeah
and
you
know,
like
you,
there's
kind
of
no
use
I
guess
debating
between
like
mid-june
and
july.
It's
like.
B
If
we
go
in
the
summer,
we
might
as
well
do
it
and
then
the
other
option
is
like
do
we
do
kind
of
more
like
april
or
may
right
and
then
assuming
we
don't
meet
kind
of
optimistic
to
realistic
timelines,
then
we'll
have
to
push
it
back
again,
one
more
time
yeah
and
I
guess
yeah
one
thing
also
worth
noting
is
right.
Before
you
came
danny,
we
were
talking
about
how
like
what's
the
delay,
you
want
between
having
the
actual
code
done
and
and
going
live
on.
B
Mainnet
so
ideally
say
you
go,
you
know,
live
on
mainnet
at
datex.
You
probably
want
something
close
to
two
months
of
like
having
the
releases
out
so
that
people
can
actually
upgrade
their
clients
and
like
run
an
execution
client
for
the
first
time
and
and
run
a
consensus
client
for
the
first
time
on
the
execution
layer.
B
If
you
do
that,
that
means
you
probably
want
to
fork
the
test
nets
in
like
the
month
before,
and
that
means
you
probably
need
to
put
out
the
releases
kind
of
a
few
weeks
to
a
month
before
that.
So
you
have
like
a
kind
of
generous
four
months
between,
like
the
code
is
done
and
we
go
on
main
net.
We
might
be
able
to
do
like
slightly
less
than
that,
but
that's
kind
of
the
yeah,
the
the
buffer
yeah
buffer
timeline.
That
makes
sense.
K
Yeah,
I
just
wanted
to
to
say
one
more
time
that
I
I
think
it
makes
total
sense
to
basically
on
the
on
the
code,
complete
side,
of
course,
that
we
think
there's
no
way
we
could
try
and
rush
this.
This
just
takes
the
time
it
takes,
but
then
on
the
I
just
don't
think
for
months
that
doesn't
seem
necessary
to
me
like
for
one
like
the
once.
We
have
the
test
net
releases,
that's
already
at
the
moment
where
people
can
actually
start
like
getting
used
to
running
both
clients
and
everything.
K
K
So
I
think
that's
just
like
another
extra
slack
month
that
just
doesn't
need
to
be
there
and
then
even
on
the
two
months
side,
as
michael
was
saying
right
like
if
we
only
choose
the
total
difficulty
relatively
close
to
the
merge
anyway
and
there's
like
the
need
for
another
update
anyway,
very
close
to
the
merge,
maybe
like
even
the
two
months
kind
of
slightly.
Don't
don't
really
make
a
lot
of
sense.
So
I
just
feel
like
the
four
months
at
least
a
month,
if
not
two
too
much
but
yeah.
N
In
conversations
is
that
running,
certainly
running
a
test
net
for
a
certain
amount
of
time
is
very
valuable,
but
one
of
the
most
critical
elements
of
this
is
likely
the
transition
process
itself
and
so
having
nightly,
builds
and
hive
and
running
it
through
the
ringer.
The
transitions
of
the
ringer
multiple
times
is
as
much.
B
B
H
H
B
You
know
like
it
that
you
know
if,
if
it
started
showing
up,
it
would
take
us
months
to
fix,
but
we
probably
want
like
at
least
a
couple
weeks
of
like
hash
rate
buffer
in
whatever
number
we
choose,
so
that
if
the
hash
rate
drops
and
we
kind
of
move
through
the
bomb
quicker
yeah
we're,
not
we're
not
stuck
and
is
your
hands
still
up.
Or
did
you
forget
to.
B
K
N
Definitely
I'm
I'm
a
bit
more
pro
putting
the
bomb
in
may
rather
than
june
or
july.
I
I
think
there
was
a
lot
of
general
agreement
last
week
that
a
moderately
aggressive
timeline
could
be
achieved,
and
I
I
don't
want
to
take
that
momentum
out.
You
know,
I
think,
if
we
set
the
bomb
to
june
or
july
then
like,
I
think,
that's
the
earliest-
that
the
merge
is
going
to
happen
just
because
that's
the
way
things
go.
N
I
got
a
lot
of
head
nods
of
something
of
a
persistent
test
net
at
the
end
of
november
for
current
specifications.
I
know
that
doesn't
mean
code
complete
and
I
know
we
have
holidays
then
after
so
then
it's
a
you
know.
Is
it
realistic
to
come
up
come
back
in
in
january
and
harden
things
such
that
you're
feeling
like
the
code
is
relatively
complete
at
the
end
of
january,
beginning
of
february.
M
From
from
a
basic
perspective,
I
think
what
we're
most
concerned
about
is
adversarial
conditions
at
transition.
I
think
we
could
be
code
complete
or
think
we're
code
complete
fairly
easily
and
not
necessarily
account
for
all
the
adversarial
conditions.
I
think
that's
that
plays
into
our
what
we
think
is
readiness,
more
so
than
having
code
complete.
B
E
B
Yeah
and
for
sure,
that's
something
we're
going
to
be
proactive
about
so
like
I
guess,
starting
in
the
next
couple
weeks,
we'll
already
start
to
reach
out
to
like
large
infrastructure
providers
and
try
to
get
them
using
ketos
and
see
what
like
their
feedback,
is,
and
you
know
what
breaks
when
they're
using
it.
And
what
not.
B
E
M
B
I
think
yeah
my
proposal
would
be
to
follow
what
tj
rush
proposed,
which
is
10.7
million.
It
means
the
bomb
starts
to
show
around
mid-may,
there's
a
world
in
which
the
hash
way
drops
and
it
starts
to
show
around
mid-april
and
we
need
to
coordinate
either.
You
know
pushing
the
bomb
back
or
releasing
the
merge,
and
if
we
really,
you
know,
if
we're
really
close
to
the
merge
and
whatnot,
we
might
be
able
to
wait
until
to
not
push
it
back
and
have
the
merge
happen
in
in
june
and
still
be
okay.
B
So
it
seems
to
me
like
a
sort
of
average,
of
the
different
opinions.
It's
obviously
something
we
can
push
back.
It's
not
you
know
and
again
I'll
stress
that,
like
the
most
important
thing
is
actually
getting
the
merge
done
well
and
like
out,
and
no
one
will
care
about
the
difficulty
bomb
if
the
merge
goes
sporty
and
no
one
will
remember
that
we
pushed
it
back
twice
a
year
from
now.
If
the
merge
goes
well,
does
anyone
feel
very
strongly
against
10.7.
L
How
how
distracting
would
it
be
to
have
discussions
about
diffusing
the
bomb
in
march
to
merge
work,
because
if
we
get
into
a
situation
where
we're
like
not
super
comfortable
about
hitting
the
target,
and
we
need
to
start
discussing
like
okay,
what
is
our
backup
plan
to
diffusing
the
bomb?
Is
this
something
that
we're
gonna
be
wasting
time?
That
is
a
really
important
moment
of
of
working
on
the
merge
and
we're
spending
all
court
that
was
talking
about
timelines
rather
than
issues
at
hand.
N
A
G
Yeah
finger
to
some
extent,
I'll
repeat
what
danny
said.
I
think
this
conversation
now
is
particularly
important.
It
gives
the
lots
of
information
to
how
confident
teams
are,
what
are
they
afraid
of
and
what
their
timelines
are
and
give
the
insight
into
for
the
community
to
to
understand
where
we
go
so
about
this
minute.
Obviously,
I
have
a
stack
of
emails
to
go
through.
G
G
B
Right
and
one
thing
yeah
so,
like
kind,
you
know,
you're
concerned
about
like
spending
all
the
time
on
our
core
devs
discussing
the
bomb.
I
think
that's
something
that's
also
kind
of
easy
to
discuss
out
of
band,
and
you
know
for
me
to
come
back
on
these
calls
and
summarize
you
know
hey.
I
talk
to
all
the
client
teams
and,
like
half
of
them,
think
this
makes
sense
and
the
other
half
is
not
ready
or
something
like
that
and
yeah.
B
B
Less
than
0.5
seconds
extra
per
block
and
so
point
10.7
million
means
we
start
to
see
the
bomb
in
may
10.8
million.
We
start
to
see
it
early
june
again,
assuming
a
relatively
constant
hash
rate.
If
the
hash
rate
drops,
we
might
see
it
before
that
yeah
and-
and
usually
it
takes
about
a
month
from
the
bomb
starting
to
show
to
the
to
the
delay
being
like
around
a
second
or
more,
which
starts
to
be
very
negative.
B
K
Yeah,
just
just
just
a
clarification
question
so
because
you're
saying
if
the
hasher
drops,
then
that
would
be
earlier.
But
my
understanding
is
that
the
because,
if
it's
triggered
by
a
block
height,
then
that
would
be
later
right,
because
it
would
take
longer
time
to
get
that
book
and
then
once
we
hit
it,
the
effects
would
be
more
severe
sooner
but
like
basically,
the
actual
the
moment
of
start
of
the
difficulty
one
would
actually
be
further
out.
Not
sooner
is
that
right.
K
Yeah
right,
but
the
adjustments
are
always
like
they're,
always
lagging
behind.
So
basically
just
this
right
now
we
have
like
a
14
seconds
or
something
right
roughly
block
time
instead
of
15
seconds.
So
then
we
would
have
like
a
16
seconds
or
something
approaching
the
the
merge.
So
I
don't
know
I
don't
think
it
makes
a
big
difference,
but.
B
H
B
So
yeah,
just
because
there's
like
a
pretty
wide
range
of
opinions
here,
I'm
kind
of
tempted
to
go
in
the
middle
with
10.7,
and
that
means
that,
basically,
in
february
we
need
to
have
a
conversation
about
like
how
ready
are
we
and
do
we
think
we
want
to
push
this
back
or
do
we
think
we're
on
the
right
track
to
not
push
it
back,
and
you
know
ideally
the
best
of
worlds.
We
obviously
are
ready
by
february.
B
Okay
last
chance
for
this
agreement.
Otherwise
we're
going
for
10.7
million
delay
to
the
bomb
and
having
aero
glacier
go,
live
on
block
13
million,
seven
hundred
thousand
seventy
three
thousand
seven
hundred
and
seventy
three
thousand,
which
should
be
midweek
on
the
on
december
eight.
But
obviously
these
things
are
hard
to
to
predict.
B
Cool
that
was
easy.
Those
were
the
two
big
things
on
the
agenda
today,
as
the
last
small
thing
was
eip3607
on
the
last
call,
we
said
we
wanted
to
move
it
the
final,
but
we
wanted
to
wait
to
make
sure
that
all
the
clients
had
implemented
it.
So
I
don't
know.
Do
any
client
teams
has
a
have
an
update
for
this.