►
From YouTube: Merge Community call 6
Description
Agenda: https://github.com/ethereum/pm/issues/580
The Merge Playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqoLxXqZqT4hcYhoHoP6w12
A
Welcome
everybody
to
the
sixth
merged
community
call
we're
very
happy
to
have
you
here
we're
going
to
go
over
general
updates
about
where
the
merge
is
at
any
announcements
related
to
mainnet
timing.
If
you
haven't
seen
them-
and
there
will
be
time
for
questions
as
always
and
yeah
we
can
get
started,
I'm
just
going
to
do
a
quick
survey
through
the
members
just
to
see
what
client,
devs
or
researchers
are
here
tim.
Do
you
want
to
kick
it
off
with?
Yes,
I
wanted
to
chill.
B
A
B
Sure
I
guess
the
first
thing
we
can
cover
is
basically
the
the
the
last
test
update
and
mainnet
and
yeah
what
like,
how
we,
how
we
get
there
so,
as
people
may
have
noticed,
gordy,
which
is
the
most
used
test
network
for
applications
and
and
and
stakers
moved
to
private
stake
earlier
this
week,
good
question
by
trent:
was
there
a
gordy
retro?
Yes,
perry
had
a
dock.
B
Looking
at
the
various
issues
we
hit,
the
the
main
one
was
that
one
of
the
client
teams
who
run
a
lot
of
validators
had
had
an
issue
updating
their
nodes
and
that's
been
fixed.
Then,
since
then,
there
were
a
couple
issues
with
some
of
the
client
implementations,
but
they
did
end
up
kind
of
reorging,
back
and
and
and
kind
of
being
on
the
main
chain.
B
So,
given
all
of
this
client
team
still
felt
comfortable
moving
ahead
with
setting
a
date
for
maintenance,
and
so
yesterday,
on
the
consensus
there
call,
we
did
that
we've
now
got
an
epoch
for
the
bellatrix
part
of
the
upgrade.
Let
me
see
if
I
can
pull
up
the
number
real,
quick.
The
epoch
is
scheduled
for
september
6th.
I
don't
have
the
exact
number:
maybe
someone
can
find
it
and
put
it
in
a
chat
so
september.
6
is
when
we
expect
belatrix
to
hit
on
the
ethereum
mainnet.
B
Oh
actually,
yeah
daddy,
just
posted
his
his
link
in
the
chat
his
he
put
up
a
blog
post
today
with
all
this
info.
So
if
you
run
a
node,
validator
or
else
other
type
of
node,
you
wanna
upgrade
before
september
6,
both
your
el
and
your
cl
client.
We
expect
to
have
a
blog
post
with
all
of
the
the
the
proposed
versions
for
these
clients
out
around
august
23rd.
B
We
do
want
to
reconfirm
that
the
ttd
is
right
next
week
on
on
the
alcord
s
call,
but
there's
very
high
chances
that
it's
it's
not
gonna.
It's
not
gonna
change,
but
this
is
kind
of
the
the
cause
for
like
the
the
lag
there
so
next
friday.
Next
thursday,
we
confirm
the
ttv
on
our
core
devs
a
couple
days
after
that
client
teams
put
out
a
release
on
the
23rd
expected
blog
post
on
there'll,
be
something
on
the
ef
blog,
but
you
can
expect
announcements
across.
B
You
know
the
various
clients
themes,
communication
channels
and
whatnot.
If
you
can
download
these,
then
you
want
to
have
upgraded
before
september.
6Th
at
11.
34
am
utc.
B
At
that
point,
the
beacon
chain
will
upgrade
to
bellatrix,
which
just
gets
it
like
ready
for
the
merge
and
then
we've
set
at
ttd
dtd
value
starts
by
five
eight
seven,
five
and
zero
zeros
towards
the
end.
B
We
expect
this
to
hit
around
september.
15Th
ttd
is
a
function
of
the
difficulty
on
the
network,
which
is
a
function
of
how
much
hash
rate
there
is.
So,
if
there's
a
kind
of
increase
in
hash
rate,
then
we
would
hit
it
before
september
15th.
If
there's
a
decrease,
we
would
hit
it
after.
So
this
is
why
it's
it's
kind
of
hard
to
get
an
exact
date
and
then
trent
shared
in
the
chat
at
ttd
chat,
ttd
tracker,
which
updates
kind
of
based
on
the
latest
hashrooms.
B
And
then
the
last
thing
I'll
say
before
I
pause
here
is
between
like
the
original
announcement,
like
what
you
expect
on
august
23rd
and
ttd,
it's
expected
that
client
teams
will
put
out
other
upgrades
of
their
release.
So
you
know
with
either
stabilization
improvements
or
or
just
new
features
or
stuff
like
that,
so
you
probably
want
to
keep
an
eye
out
and
and
yeah
follow
whatever
client
you're
using
in
in
those
couple
weeks,
because
they
might
put
out
another
release
before
ttd
is
actually
hit.
B
Given
there
might
be
basically
almost
a
month
between
the
time
when
we
we
actually
announce
it
in
the
timer
and
when
it
hits
and
then
the
last
thing
I
will
say,
the
actual
last
thing
I
will
say
is
because
ttd
is
very
hard
to
estimate,
because
it's
a
function
of
hash
rates,
we're
in
kind
of
the
last
innings
of
proof
of
work
on
ethereum.
B
If
we
saw
that
the
hash
rate
would
like
drop
dramatically
and
that
instead
of
you
know
hitting
ttd
around
september,
15th
hashrate
drops
a
ton,
and
now
we
think
it's
going
to
be
like
october,
15th
and
and
and
kind
of
getting
later
and
later
we
could
coordinate
a
ttd
override.
We
did
this
on
the
robson
network
already.
B
Ideally,
we
don't
just
because
it
kind
of
forces
people
to
either
upgrade
their
nodes
again
or
run
a
special
command
to
do
this.
But
if
we
see
that
you
know,
bellatrix
is
activated
and
ttd
is
is
not
getting
any
closer
because
hash
rate
is
dropping,
then
we
might
make
the
call
to
to
do
a
ttd
override
and
so
again
just
please
pay
attention
to
either
like
blog.ethereum
or
your
clients
like
communication
channels,
and
this
is
where
this
stuff
would
be
announced.
B
A
B
A
A
A
It's
not
saying
it
won't
change,
but
this
is
the
time
where,
if
you're
validating
on
the
beacon
chain,
you
want
to
be
tuned
in,
you
want
to
be
aware
of
what's
happening
and
making
sure
that
you're
running
the
right
software
ahead
of
the
actual
merge
event
so
for
the
next
month,
or
so,
you
know,
don't
disappear
for
a
month.
Make
sure
that
you're
following
the
client
teams
that
you're
that
who's
software,
that
you're
running
we'd
hate
for
somebody
to
miss
it
when
the
actual
time
comes.
A
B
I
think
perry
is
here
I
perry.
Do
you
want
to
like
walk
through
the
dock,
that
we
shared
a
bit
more
and
kind
of
talk
about,
like
the
implications.
A
Yeah
and
generally
just
I'll
I'll
unmute
you
or
find
you
first,
but
generally
like
what
the
the
the
sort
of
class
of
issues
that
we
hit
over
all
of
the
test
nets
and
generally
what
that
means
for
maine.
I
think
I
immediately
perry.
Let
me
know
if
that
didn't
work.
C
Yeah,
hey,
I
think
this
should
work
now.
I
do
have
another
doc
that
might
help
with
that
hang
on.
Let
me
just
find
that
that
just
kind
of
goes
through
the
class
of
issues
that
one
might
face
during
during
the
march
yeah,
so
yeah.
So
we
had
the
girly
test
night
part
yesterday
and
a
decent
bunch
of
the
issues
were
just
attributed
to
a
client
team,
not
setting
up
the
jwt
authentication.
C
So
since
so
the
merge
is
introducing
this
concept
of
an
execution
layer
and
a
consensus
layer.
So
if
you
guys
are
used
to
running
ethereum
nodes,
what
you've
been
running
so
far
is
now
called
the
execution
layer
or
eth1
node,
and
you
would
have
to
add
a
consensus
layer,
node,
that's
the
beacon
chain,
node
and
in
order
for
these
two
nodes
to
communicate
with
each
other,
we've
introduced
a
new
port,
that's
the
engine,
api
port
and
by
default,
that's
port
8551
and
that's
an
authenticated
port.
C
So
you
have
to
configure
the
same
jwt
secret
on
both
sides.
There's
a
bunch
of
guides
online
to
guide
you
through
how
to
set
up
these
nodes,
as
well
as
what
the
secrets
mean
and
they're
extremely
good.
I
think
we
even
have
a
couple
linked
I'll
try
and
find
the
link
for
the
link,
but
that
being
said,
the
client
team
had
forgot
to
configure
the
jwt
token.
A
C
Once
they
did
that
the
notes
came
back
online,
the
other
issues
were
due
to
multiple
terminal
blocks,
and
that
essentially
means
the
merge
had
two
candidates
and
the
nodes
took
some
time
to
decide
which
of
these
candidates
they're
backing,
and
we
had
some
failsafes
built
in
and
the
failsafe
kicked
in
and
once
they
kicked
in.
Essentially,
the
chain
was
okay
again,
but
those
were
like
the
two
big
classes
of
problems
yeah
and
besides,
that
I'd
highly
recommend
that
everyone
on
the
call
look
through
the
checklist
for
the
merge.
C
It's
again,
not
not
an
exhaustive
document,
but
it
covers
most
of
the
pitfalls.
We've
seen
over
the
over
the
last
couple
of
merges
especially
have
a
look
at
the
common
pitfalls.
Like
almost
every
big
issue,
we've
noticed
has
been
because
there
was
the
wrong
flag
used
or
the
port
wasn't
configured
or
the
secret
wasn't
right,
or
people
just
forgot
to
run
one
of
the
two
pieces
of
software
needed
so
yeah.
Just
please
have
a
look
at
those
and
in
general
the
logs
will
tell
you
nine
out
of
ten
times
that
something's
wrong.
B
I
guess
you
have
just
more
questions
on
that.
We
can
answer
them
in
the.
B
I
guess
you
can
ask
them
in
the
chat
and
we
can
answer
them
as
a
follow-up
and
just
worth
noting
perry
posted
his
checklist
there
and
then
there's
a
like
similar
document
on
the
launch
pad
as
well
that
I've
posted.
So
if
you're
on
a
validator
yeah
just
running
through
those.
A
B
Okay,
oleg
has
a
question
about
ttd
sabotage,
so
the
only
there's
two
ways
you
can
affect
ttd
with
proof
of
work:
one
is
you
stop
mining
and
then
ttd
takes
forever
to
be
reached,
and
this
the
only
impact
that
this
has
is.
It
makes
the
merge
happen
at
a
later
date
than
it
otherwise
would,
and
so
if
this
were
to
happen-
and
you
can
think
there's
many
reasons
for
people
to
stop
mining
now
right,
it
doesn't
have
to
be
sabotage.
B
You
know
people
might
choose
to
sell
their
gpus
because
they
feel
like
their
return
on
like
the
rest
of
the
mining.
Life
on
ethereum
is
not
worth
it.
So
it's
not
necessarily
like
malice
that
triggers
this,
but
if
people
stop
mining
ttd
happens
later
than
it
otherwise
would.
What
we
need
to
do
is
basically
select
a
ttd
value
that
is
lower
than
the
current
one,
which
we
would
then
hit
quicker
kind
of
based
on
the
new
hash
rates.
B
So
every
single
client
has
a
flag
or
like
a
configuration
option
that
allows
for
this
and
clients
can
also
put
out
new
release
new
releases
overwriting.
This
we've
tested
this
procedure
on
robson
before
and
so
I'll
link
to
you
to
a
blog
post.
That
kind
of
shows
you
what
it
looks
like
and
kind
of
links,
every
single
client's
command
to
upgrade
to
update
this
value.
B
The
other
way
that
proof
of
work
and
ttv
can
kind
of
can
kind
of
get
get
tricky
is
if
there
is
so
much
mining
power
on
the
network
that
ttd
ends
up
happening
before
the
bellatrix
upgrade
is
activated,
and
this
was
actually
the
case
on
robson
on
robson.
We
didn't
have
the
case
where
there
was
not
enough
buying
power.
We
had
the
case
where
there
was
too
much.
B
The
reason
for
that
is
that
mining
on
test
nets
is
basically
not
a
profitable
thing,
so
the
hash
rate
is
quite
low,
and-
and
so
it's
quite
easy
to
raise
it
significantly.
B
So
when
we
chose
the
ttd
yesterday,
we
basically
chose
a
value
which,
if
you
wanted
to
make
it
happen
before
bellatrix,
I
believe
you
would
need
the
hashrate
to
have
already
spiked
back
to
the
all-time
highest
we've
seen
on
the
ethereum
network
and
to
keep
mining
at
that
rate
until
until
we
hit
ttd
and
then
the
closer
we
get
to
bellatrix
like
with
every
day
that
passes,
you
need
to
then
not
be
at
all
time
high,
but
you
need
to
have
an
even
greater
share
of
hash
rate
than
that,
and
because
this
is
something
we
see
on
the
network.
B
If
something
like
that's
were
to
happen,
you
know
we
wake
up
tomorrow.
There's
like
a
massive
supply
of
hashrate,
then
we
could
do
it
override,
which
pushes
the
ttd
back
to
a
higher
value
and
then,
as
soon
as
bellatrix
has
happened
so
which
is
scheduled
for
september
6.
Then
it
really
doesn't
matter
when
the
ttd
is
hit.
It
becomes
purely
a
sort
of
coordination
exercise
about,
like
you
know,
making
sure
everybody
has
the
same.
The
same
ttd
set,
but
there's
no
kind
of
impact
or
attack
on
the
merge.
B
Based
on
that,
so
basically
we
think
that,
like
yeah
choosing
a
value
where
you
know,
we
have
some
pretty
like
solid
bounds
in
terms
of
how
much
the
hashtag
would
have
to
increase
for
for
to
disrupt
things
and
then
having
like
code
and
and
kind
of
a
release
procedure.
That's
well
tested
such
that
like.
If
this
thing
happened,
we
could
we
could
counter
it
and
so
far
it's
not
looking
like
the
hash
rate
is
rising
like
basically,
the
all-time
high
was
like
something
like
1100
pair
peter.
B
I'm
not
sure
what
the
unit
is,
but,
like,
oh
sorry,
11,
giga,
hashes,
oh
sorry,
no
anyways,
the
1100
something
and
then
we're
at
about
900
now,
so
we've
dropped
since
the
all-time
high
by
a
fair
amount.
It
hasn't
risen.
Since
we've
we've
chosen
the
ttd
we'll
keep
monitoring
it,
but
then
you
know
a
week
or
two
from
now.
You
would
have
to
have
hash
rates
that
goes
past.
What
the
previous
all-time
all-time
high
hash
rate
was,
and
I
think
that
becomes
quite
quite
unrealistic.
B
And
then
maybe
the
there's
a
so
there's
a
follow-up
question
about.
What's
the
backup
plan
in
the
case
of
merge
trails
or
some
series
of
issues
happen,
so
there's
no
way
in
which
we
can
go
back
to
appropriate
work
once
to
like
activate
the
merge
sequence
and
the
reason
for
that
first,
the
code
does
not
allow
it,
but
like
the
kind
of
design
reason
is
once
you
move
from
proof
of
work
to
proof-of-stake,
and
even
once
you
like
signal
that
move.
B
B
We
assume
that,
like
that,
there
is
no
longer
security
on
the
proof
of
work
side
that
could
like
backstop
us,
and
we
need
to
ensure
that,
like
things
work
out
on
broomstick
and
obviously
you
know
we,
this
is
why
we
do
so
many
test
nets.
So
many
shadow
forks.
If
there
was
an
issue
that
happened
on
emerge,
which
we
did
you
know
which
we
hadn't
encountered
so
far,
the
solution
would
be
like
fixing
it
on
proof
of
stake
on
main
net
as
soon
as
possible,
not
going
back
to
cover
stage.
B
Effectiveness
remy.
I
see
you're
posting
about
this
in
the
chat
you
want
to
take
that
question.
A
I
will
try
to
unmute
him
can't
find
the
account.
Oh,
maybe
it's
because
I'm
a
special
character
or
something
yeah.
D
Hey,
hey,
hey,
so
effectiveness
is,
is
known
to
be
wildly
changing
on
tests
right.
So
I
believe
you
were
a
illusion.
You
were
mentioning
that
your
effectiveness
went
down
after
the
merge
and
I'm
guessing.
This
is
on
girly.
D
So
it's
it's
like
common
to
see
effectiveness,
changes
on
test
that
because,
like
there's
less
resources
being
spent
there,
people
don't
have
any
real
value
or
real
money
there.
So
it's
not
uncommon
to
see
like
effectiveness
goes
down,
but
I
posted
the
resources
on
effectiveness.
D
If
you
want
to
check
it
out
in
the
chat
suppose
by
a
testant
it'll
enlighten
you
on
like
how
it's
computed,
I'm
not
sure
exactly
how
it's
computed
on
the
beacon
chain
that
the
website,
I
can't
remember
how
it
is,
but
I
believe
it's
like
with
your
attestation,
if
you're
always
correct
in
terms
of
the
votes
that
you
do
on
source
target
and
head,
but
on,
like
I
mentioned
on
tests
that
it
it
widely
changes,
because
people
are
not
putting
the
same
resources
but
on
mainnet
it
should
be
quite
stable.
D
A
B
So
today
it's
oh
daddy,
you
have
the
idea
to
take
it.
Let's
see,
can
win.
B
A
A
D
Is
unlikely
to
support
that
directly
client
teams
may
add
support,
but
I
think,
or
some
sort
of
multiplexer
sitting
in
the
middle
is
a
better
generic
solution.
Gas.
I
think
cl
client
supported
it.
You
know
if
anyone
does
it'd
probably
be
very.
B
Okay,
so
short
answer
not
without
a
multiplexer
for
now
at
least
next
one
will
this
usage
increase
faster
after
the
merger?
Can
I
assume
the
same
size
increase
before
the
merge?
Summing
up,
the
usage
is
cl
and
el
client.
I
know
there
was
a
thing
here
about
like
the
blocks
being
stored
on
both
layers
and
prism.
I
know
had
like
looked
into
this.
B
I
don't
know
terence,
can
you
give
us
a
little
list
on
the
cl
side
like
whether
the
whether
the
storage
increases,
because
you
now
store
the
execution
paid
out
as
well.
C
D
C
B
D
You
store
the
header
and
then
because
there's
no
point
in
storing
like
payloads
in
two
different
locations
and
that's
cl
and
el,
because
el
is
storing
the
payload
already
so
then
so
then
the
ceo
could
just
store
like
the
blinded
version,
which
is
just
a
transaction
root,
and
if
you
need
to
retrieve
the
payload
you
can
just
get
you
can
just
get
it
from
the
el.
So
I
would
highly
recommend
you
guys
to
read
the
documentation,
I
think
for
prism.
It's
created
behind
the
flag,
it's
it's
not
enabled
by
default,
and
then
so.
D
B
B
B
If
not,
I
don't
see
anyone
not
of
mine.
If
there
is
please
let
yourself
known
in
the
chat
and
will
on
youtube,
if
not,
there
was
definitely
an
issue
that
was
found
with
nethermine
during
the
the
gordy
merge.
It
is
mentioned
as
part
of
like
the
dock
that
perry
shared
earlier
yeah.
I
I
don't
know
that,
there's
anyone
on
it
who
can
have
more
details,
oh
yeah,
exactly
so
in
this
dock.
There
are
some
some
issues
there,
yeah.
B
Yeah
exactly
this
is
literally
what
yeah
yeah.
This
is
probably
the
issue
from
the
dock
where
you
have
to
restart,
and
then
it's
back
to
normal,
so
the
nethermine
team
is
aware
and
they're
they're
working
on
this
right
now,
yeah
and
there's
yeah,
there's
there's
like
an
hive
test.
That's
also
gonna
be
added
to
hit
exactly
this
edge
case.
If
I'm
not
mistaken,
oh
they
already
have
a
fix
harry
says.
B
D
Yes,
so
there
will
be
another
workshop
in
about
30
minutes.
So
if
you
want
to
learn
more
about
the
details
of
that
workshop,
let
me
try
to
find
the
link
here.
D
I'll
post,
the
link
in
the
chat
so
in
in
about
30
minutes,
we'll
have
another
workshop
and
people
will
be
able
to
join
us.
I
believe
we
will
have
a
summary
sat,
giving
us
some
updates
about
his
guide
for
the
merge
and
we'll
do
a
bunch
of
different
stuff
in
in
order
to
prepare
for
the
merge
and
we'll
answer
everyone's
question
there.
So
if
you
have
any
technical
questions
with
your
own
setup,
please
join
us
and
we
will
be
happy
to
help
you.
D
Yeah,
I
believe
we
have
a
plan
to
have
another
workshop,
maybe
next
week
or
in
two
weeks,
let's
see
yeah.
B
Okay
and
yeah
link
to
link
that
in
the
the
comments
there
yeah.
A
Yeah,
it's
I'm
not
seeing
any
other
questions,
which
is.
I
guess
I
didn't
expect
that
given
this
is
like
even
closer
to
the
merge,
but
maybe
everything's
been
answered.
Oh
here
we
go
there's
another
one.
B
Yeah,
a
good
energy
boost
question:
is
there
anyone
from
flashbacks
on
the
call
or
who's
like
work
done
with
mbv
boost.
B
A
D
It
works.
Okay,
awesome,
sorry
about
that,
so
with
med
boost,
it's
little
trickier
because,
like
every
clan,
does
this
differently.
So
there's
like
it's
kind
of
hard
to
come
to
like
this
like
cohesive.
Like
point
like,
how
does
it
work
and
like?
How
do
you
know
who
is
working
right?
I
think
for
us,
it's
like
we
utilize,
the
health
endpoint
of
the
mvp
boost
pretty
heavily.
D
So
when
something
doesn't
work,
you
will
see
from
the
error
log
right
away.
So
at
startup
we
call
mvp
boost
to
check
the
health.
If
there's
some
work
and
then
you
unlock
the
arrow
and
then
before
the
blog
proposing
will
also
check
the
health
status
right,
but
at
the
worst
case
we
also
build
a
block
in
the
background,
in
parallel
with
the
local
ee
as
well.
So
it's
so
so
so
like
in
the
event
that
the
map
boost
doesn't
work
or
or
the
relay
is
done.
D
You
will
not
be
missing
blood
because
you
can
still
broadcast
your
personal
block,
that's
from
the
local
ee,
so
I
will
say
just
pay
heavy
attention
to
the
log
and
just
grab
any
error
that
you
can
find
and
that
is
related
to
to
a
math
boost.
A
Thank
you,
terence
aks.
Can
you
put
your
question
in
the
chat
first
before
we
unmute
you.
A
Okay
doesn't
seem
like
we
have
any
more
questions
coming
in
same,
were
there
any
topics
or
researchers,
client
devs?
Is
there
anything
you
want
to
say
specifically
to
this
audience
of
80,
wonderful
people
that
we
have
here.
B
I'm
I'm
actually
curious,
as
so
I
like
power
bowery.
Hopefully
I
got
your
name
right.
Why
do
you
think
the
gap
should
be
bigger
than
seven
to
ten
days,
given
that,
as
a
solo
node
operator,
you
sort
of
have
to
be
ready
when
bellatrix
hits
anyway,
so
once
pediatrics
hits
everything
should
be
configured
so
I'm
curious.
What
what's
the
thing
you
would
like
to
like
have
a
wider
gap
for?
What's
the
main
reasoning.
B
And
we
can
either
unmute
you
or
or
if
you
want
to
answer
in
the
chat
but
yeah,
I'm
just
curious
to
understand
better.
What's
like
the
constraint
there.
B
And
then,
while
I,
I
think
I've
yeah,
if
yeah
I've
asked
you
to
unmute
if
you
can
but
yeah,
while
we're
waiting
for
that,
micah
asks
us
to
reiterate
the
ttd.
Is
it
final?
So
it's
tentative.
B
So
basically,
if
yeah,
we
should
confirm
it
on
awkward
as
next
week,
but
then
even
then,
if
we
see
some
some
like
crazy
variations
in
the
hash
rate
or
whatnot,
we
might
we
might
change
it
once
more.
So
yeah,
please
keep
an
eye
out,
but
yeah,
okay
and
then
aks
has
a
question
about
miners,
turning
off
their
nodes,
much
before
the
ttd
target.
So
this
yeah.
This
is
basically
what
we
discussed
earlier.
So
what
would
the
the
first
impact
of
this
would
be?
B
It
would
make
ttd
hit
much
later,
so
that
would
that
would
kind
of
slow
down
the
merge.
There
is
a
point
at
which
you
know
a
significant
enough
part
of
hash
rate.
Leaving
makes
ethereum
kind
of
not
as
secure
by
by,
however
much
hash
rate
we've
lost,
and
so
I
think
those
are
all
cases
like
both
in
where
we
just
consider
making
the
lower
and
kind
of
pulling
the
merge
forward.
B
Based
on
the
new
the
new
hash
rate
levels,
there
is,
if
we
saw
like
that,
the
the
hash
rate
was
going
so
low
and,
and
you
know,
being
completely
unstable
or
being
attacked,
there's
another
like
override
method
that
we
can
use
where
we
actually
hard
code,
basically
a
specific
work
block
and
and
agree
on
it
as
the
the
the
final
proof
of
work
block.
B
This
is
really
not
ideal,
so
the
the
the
you
know
doing
that
would
kind
of
incur
liveness
failure
on
ethereum,
so
we
we
don't
want
to
get
there.
So
you
know
if
the
if
the
the
hash
rate
goes
lower.
The
the
main
solution
is
just
to
reduce
the
ttd
and
find
a
closer
target.
A
B
We
don't
have
like
this
hardware,
so
it's
really
the
the
best
tool
that,
like
protocol
developers
have,
is
just
changing
the
ttd
value
rather
than
trying
to
affect
the
actual
hash
rates
on
the
network
on
testness.
We
were
able
to
do
that
because
on
testnets
we
basically
you
know
for
like
a
couple
hundred
dollars,
so
maybe
a
couple
thousand
dollars
could
like
double
the
entire
hash
rate
on
the
test
net.
This
is
like
on
the
order
of
millions
tens
of
millions
of
dollars,
so
I'm
changing
the
dtd
as
much
is
much
better.
B
Oh
good
question,
bye,
bub.
What
happened
is
there's
multiple
miners
that
find
a
block
passing
ttd
at
the
same
time.
So
the
way
that
the
merge
is
designed,
any
block
which
passes
ttd,
which
is
obviously
a
valid
ethereum
block
and
who
is
the
first
block
in
its
in
its
fork,
retreat
to
pass
dtd,
is
a
valid
candidate
terminal
block.
B
So
it's
it's
very
much
possible
that
you
know
there's
there's
two
of
them
or
three
of
them
like
we
see
uncles
on
the
ethereum
network
right
now,
so
as
long
as
they
meet
all
those
criteria.
Basically,
the
validator
who
produces
the
block
after
is
free
to
choose
any
one
of
them,
and
then
it
might
reorg
until
this
block
is
finalized
and
like
justin
is
saying
in
the
chat.
B
This
is
sort
of
what
happened
in
gordy,
because
basically
like
yeah
until
we've
like
finalized
any
any
proof
of
work
block
which
exceeds
ttd,
whose
parents
does
not
exceed
ttd
and
otherwise
follows
all.
The
protocol
rules
is
a
valid
terminal
block
and
this
is,
and
so
it's
possible
to
for
a
validator
to
select
any
one
of
them
and
it's
possible
for
the
next
validator
to
select
another
one,
and
this
is
why
we
want
to
wait
for
the
network
to
have
finalized
before
we
consider
the
merge
to
be
complete.
B
B
Okay,
stable
coins,
migrations,
so
short
answer
is
at
at
the
like
at
the
application
level.
Nothing
changes.
Nothing
is
required
for
applications
to
migrate
to
the
merge.
So
if
you
have
usbc
now,
you'll
have
usdt
after
the
merge,
and
you
know
you
don't
need
to
move
them
or
do
anything
with
that.
So
you
know
there's
no
like
applications
where
you
should
have
to
to
do
an
action
in
the
case
where
there
was
a
separate
fork
around
the
merge
at
the
same
time.
B
So
like
a
proof-of-work
fork
in
parallel,
then
everything
on
ethereum
kind
of
gets
mirrored
on
both
side.
So,
if
you
have
say
usdt
balance
in
theory,
you
have
a
usdt
balance
on
both
chains,
but
then
because
say,
usdt
is
backed
by
like
actual
dollars
actual
dollars,
not
on
ethereum.
The
the
tether
like
the
issuer
will
have
to
recognize
like
this
is
the
chain
where,
where
these
usdt's
are
actually
redeemable
for
one
dollar,
I
believe
so
far.
B
Tether
and
circle
have
both
like
recognized
that
this
would
be
under
proof
of
stake
chain.
But
yes,
and
like
mike,
is
saying
this
is
the
case.
Every
time
there's
a
network
upgrade.
B
There's
the
you
know,
there's
the
opportunity
for
like
people
on
the
network
to
not
follow
this
upgrade
and
then
what
happens
is
like
everything
gets
duplicated
across
both
chains,
but
anything
that
has
like
a
reference
to
something
off
chain,
only
kind
of
gets
honored
or
like
recognized
on
one
of
those
two
chains
and
for
usdt
specifically,
and
I
believe,
like
pretty
much
every
stable
coin.
This
is
the
the
proof
of
stake
chain
and
like
yeah
caleb
has
an
important
clarification.
B
Like
you
know,
you
shouldn't
have
to
like
give
out
your
private
key
sign
any
messages
migrate.
Your
coins,
please,
please
be
like
on
the
lookout
for
that
we've
seen
like
some
really
good
phishing
emails
and
just
like
fake
emails
about
this
recently
so
like.
If
somebody
says
like
you
need
to
like
move
your
coin
or
you
need
to,
like
you
know,
sign
in
somewhere
to
activate
the
merge
or
anything
like
that,
it's
very,
very
likely
a
scam.
So
please
be
on
the
on
the
on
the
lookout.
B
Okay,
so
damian
has
a
question
about
basically
the
ttd
estimate
being
from
the
hash
rate
at
the
current
level
with
september
15th,
that's
correct,
and
so
this
is
why
we
tell
people
to
like
that.
It
is
variable.
So
you
know
our
goal
wasn't
to
reach
it
exactly
on
the
15th.
B
Our
goal
is
mostly
to
reach
it
after
bellatrix
happens,
and,
ideally
not
too
far
after
the
15th,
so
you
can
think
of
like
we
want
to
be
safe,
plus
or
minus
a
week
on
each
side,
and
this
is
roughly
why,
like
the
15th
was
targeted,
because
if
you
have
bellatrix
on
the
sixth,
you
know
you
would
have
to
have
a
massive
increase
in
hash
rate
for
it
to
happen
before
and
if
we
get.
B
You
know
to
the
sixth
and
like
close
to
the
15,
and
we
see
we're
still
very
far
out
that
we
would
just
do
a
ttd
override
based
on
the
hash
rate
levels
there
or
like
the
hash
rate
trends
yeah.
But
there
is
the
goal
isn't
to
like
absolutely
try
and
get
it
on
the
15th,
it's
first
and
foremost,
to
make
sure
it
happens
after
bellatrix
and
then
ideally
get
it
in
one
go
roughly
close
to
the
15th.
But
if
that's
not
going
to
happen,
we
can
always
do
an
override.
A
Made
a
meme
a
couple
months
ago:
I'll
try
to
I'll
find
it
well,
but
the
verbal
description
is
the
execution
and
consensus
layers
are
represented
by
a
white
player,
white
bear
and
a
black
bear
and
the
merge
is
done
coming
together.
A
A
Tldr
there
was
a
summary
of
gurley
francis.
There
was
a
summary
of
gurley
earlier
there's
a
doc.
If
somebody
can
show
that
again,
if
you're
joining
late,
I'm
not
sure
what
you
mean
by
resource
constraints.
You
mean
in
times
of
non-finality.
B
B
Was
it?
Was
it
basically
that
had
some
issues
during
the
gordy
merge?
Just
because
some
of
the
nodes
were
running
on
like
resort
like
in
sort
instances
with
two
small
resources.
B
C
Also
resource
use
tends
to
spike
quite
a
bit
during
non-finality
and
at
least
on
gurley.
That
period
was
just
a
couple
of
epochs
after
after
the
merge,
and
once
we
hit
finality
again,
resource
use
did
does
decrease
quite
a
bit,
so
we
even
with
the
previous
notes,
I
think
I
don't
even
think
they
had
to
upgrade,
but
I
think
it
sort
of
fixed
itself
once
finality
had
been
reached.
A
And
one
last
offer
for
any
client
any
client
types
or
researchers
who
are
on
the
call,
and
you
want
to
mention
something
that
wasn't
touched
on
before
feel
free.
To
raise
your
hand
if
you'd
like
to
talk
about
your
client,
anything
specific,
that
people
should
be
aware
of
any
resources
that.
B
Gonna
say
it's
not
because
there's
there's
like
been
a
couple
questions
about
like
estimating
the
ttd
and
whatnot
and
maybe
I'll
just
like
add
a
last
amount
of
nuance
on
there.
The
reason
you
know
you
could
imagine
a
world
where
we
just
have
bellatrix
happen,
and
then
we
decide
the
ttd
right,
and
this
is
what
we
did
on
a
couple
of
the
testaments.
B
The
challenge
with
doing
that
is
just
that,
like
you,
have
to
get
people
to
upgrade
their
notes
twice
and
because
this
is
already
like
a
pretty
complete,
complicated,
upgrade
relative
to
other
ones.
We
opted
to
like
optimistically.
Have
people
only
need
their
nodes
to
be
updated
once
and
to
kind
of
bake
in
a
ttd
estimate?
For
that,
usually,
when
we
ask
people
to
upgrade
their
nodes,
we
think
like
on
the
order
of
about
two
weeks
is
like
reasonable.
B
So,
like
we
put
out
the
software
put
out
an
announcement,
then
within
two
weeks,
usually
we
can
get
the
community
to
upgrade
their
nodes.
So
if
we
kind
of
hit
bellatrix-
and
we
see
it's
gonna-
be
way
more
than
two
weeks
to
hit
ttd,
then
it
probably
makes
sense
to
to
coordinate
another
ttd
and
have
have
it
lower
and
have
people
upgrade
their
notes
again.
But
this
is
like
why
there's
so
much
like
uncertainty
or
like
yeah
wide
estimates
around
it?
It's
just
because
we
need
to
predict.
B
Oh
sorry,
my
headphones,
my
headphones
went
off
for
a
second
but
yeah.
It's
just.
We
need
to
predict
this
value.
That's
really
far
up
in
the
future.
B
That
has
like
a
lot
of
like
unknowns
that
go
in
into
it,
but
if
we-
and
so
we
take
kind
of
our
best
guess
for
it,
if
we
see
that
this
best
guess
is
wildly
off,
then
we
can
correct
it,
and
the
only
downside
is
people
need
to
re-upgrade
their
nodes
or
run
an
additional
command,
and
this
is
what
we'd
like
to
avoid
in
like
the
happy
case.
But
it's
not
it's
definitely
not
the
end
of
the
world
to
have
to
do
it
and
we've
done
it
on
robsten
and
for
users.
B
B
And
then
there's
a
question
about
issuance,
so
issuance
is
basically
based
on
the
total
amount
of
validators
on
the
network.
So
if
there's
more
validators,
the
total
issuance
goes
up,
but
then
the
the
kind
of
rewards
to
the
validators
proportional
to
their
stakes
go
down
and
that
kind
of
targets
a
specific
amount
of
validator
yeah.
So
so
so
it's
confirmed
that
it
is
part
of
this
spec.
But
it's
not
confirmed
in
that.
B
We
don't
know
how
many
new
validators
might
want
to
validate
after
the
merge
and
that
impacts
issuance
and
I
think
ultrasound.money
I
believe,
has
like
a
a
nice
little
like
graph
that
you
can
you
can.
You
can
tweak
to
see
yeah
based
on
how
many
validators
and
whatnot.
A
All
right
looks
like
we're
actually
out
of
questions
now,
besides
from
some
ttd
panda
ideas,
but
I
don't
know
if
we're
gonna
be
able
to
include
that
micah
is
sad
for
some
reason
he
would
love
to
keep
answering
questions,
but
I
think
we
can
probably
wrap
up
here.
I've
done
the
last
call
like
three
or
four
times
now.
B
A
I
think
we
were
going
to
plan
for,
let's
see
wednesday,
the
7th
of
september.
Does
that
sound
right.
B
Actually,
yeah
there's,
oh
yes!
So
so
we
said
we
wanted
to
do
after
bellatrix
and
before
mainnet
right,
so
that
there
will
be
more
more
eat,
staker
events
before
bellatrix.
We
can
encourage
people
to
watch
those,
but
then
between
bellatrix
and
mainnet.
We
will
do
another
one
of
these.
So
okay,
so
maybe
that's
the
ninth.
B
Tentatively
say
september
9th
at
this
at
this
time,
so
like
four
yeah
four
weeks
from
now
exactly.
B
C
A
You're
interested
in
attending
that
it'll
be
in
the
same
spot
as
a
a
pr
in
the
the
ethereum
pm
repo,
with
an
agenda
and
in
10
minutes.
If
you're,
a
validator.
Remember
that
there's
a
an
east
staker
call
workshop
happening
in
10
minutes
and
where
remy
where's
the
best
place
for
people
to
jump
into
that.
Maybe
you
can
share
the
link
again
or
direct
them
a
certain
place.
A
If
you
already
left
just,
I
don't
know
where
I
would
point
you,
but
the
e-sticker
discord
probably
is
the
best
place.
B
Somebody
just
posted
the
the
youtube
link
again:
yeah,
oh
perfect
yeah.
So
oh
yeah.
B
A
One
last
question:
yeah:
I
don't
know
if
we
can
explain
replay
attacks,
but
I'm
not
gonna
get
into
like
how
to
financially
profit
from
this
upgrade.
A
B
Okay,
yeah,
I
think
we
got
it
thanks
everyone
for
showing
up-
and
yes
you
in
about
a
month
for
the
next
one
of
these.