►
From YouTube: Ethereum Core Devs Meeting #78 [2020-1-10]
Description
B
B
The
first
topic
of
discussion
was
the
eip
2387,
mere
glacier
updates
just
talking
about
how
it
went,
and
I
think
the
cat
herders
are
doing
a
review
of
it.
If
I'm
not
mistaken
and
we'll
have
puja
talk
about
that
a
little
bit.
If,
if
that's
happening,
but
first,
I
guess,
let's
throw
it
to
whoever
added
that,
so
that
would
be
okay.
I
guess
tim
added
that,
but
does
anyone
want
to
speak
on
it.
C
Yeah,
but
I
can
talk
about
it
great,
so
we
blocked
9
million
200
000
for
those
falling
over
home.
We
had
muir
glacier
activated
and
it
actually
went
off
that
while
there
was
quite
a
bit
of
drama
before
in
the
community
about
it,
technologically
speaking,
it
went
off
really
well
and
three
of
the
four
clients
were
perfect
and
nethermine
had
a
quick
update
that
happened
afterwards
without
any
negative
effect,
and
that
fork
included
the
eip
for
pushing
back
ice
age
which
now
block
times
have
reduced
to
fastest.
They
have
been
since
then.
B
D
D
C
B
B
F
So
this
is
a
proposal
to
try
and
move
the
fork
instead
of
picking
a
specific
block
to
try
and
get
some
methods
where
we
can
go
on
a
time
and
getting
a
time-based
fork
is
a
tricky
issue.
There's
plenty
of
ways
to
introduce
new
attack,
vectors
and
ways
to
basically
make
things
more
complicated
than
they
would
ordinarily,
just
by
saying
well,
for
you
know
next
wednesday,
at
noon.
F
F
F
Although
owners
is
also
a
very
subtle
issue,
if
we
work
on
a
specific
time,
what,
if
there's
a
reorg
that
includes
that
block
number,
that
also
gives
the
miners
some
opportunity
to
play
games
with
the
numbers
to
try
and
force
forward
to
the
fork,
although
geth
parody,
basically
that
I
know
of
only
accept
blocks
15
seconds
in
the
future.
I
don't
know
about
trinity
left
and
nether
mind.
I
don't
know
what
their
rules
are,
but
even
then
you
know
you
can
have
like
you
know
all
sorts
of
deep,
all
sorts
of
difficulty.
F
If
you're
trying
to
fork
in
a
specific
block,
that's
not
round,
it
could
be
random.
So
the
first
thing
that
I
proposed
is
that
the
transitions,
only
the
network
upgrades
only
transition
at
block
numbers
that
are
round
by
a
thousand,
and
the
second
thing
is,
I
propose
a
two-phase
commit
that
we
do
the
transition
at
the
second
opportunity,
where
the
block
number
that
is
around
thousand
is
after
the
fork
time.
So
that
gives
us
a
window
that
gives
us
a
trigger
event
about
a
thousand
to
almost
two
thousand
blocks
in
the
past.
F
If
there
was
any
additional
rules
that
might
change
the
header
validation,
how
they,
a
malicious
miner,
might
be
able
to
literally
armors
with
transition
eligible
blocks.
Luckily,
it
looks
like
the
two-phase
commit
on
round
numbers
is
going
to
limit
that
window
to
about
three
bucks
before
the
second
transition
that
they
could
fill
it
up
and
even
then
there's
you
know,
there's
there's
finance,
there's
economic
limitations
on
how
effective
that
can
be.
There's
only
so
many
over
blocks.
F
G
Peter
yeah,
I
just
wanted
to
ask
that
say
that
my
my
concerns
aren't
necessarily
malicious
minors
doing
weird
things.
Rather,
it's
just
just
the
complexity
of
consensus
rules
that
in
theory,
so
I'm
not
sure
how
the
rules
are
currently
laid
out,
but
in
theory
it
could
happen
that
along
so
you
or
one
of
the
blocks
already
fork.
A
F
I
F
Since
we
don't
know
the
future
block,
we
would
be
advertising
a
future
time
and
unless
we
then
update
our
record
at
the
block,
when
we
think
it
happens,
you
know
if
we,
if
we
stick
with
that
number
meaning
when
the
the
block
the
fork
block
is
we
don't
have
to
change
our
our
hash,
nearly
as
often
otherwise
there's
a
small
window
where
you
might
have
a
difficult
time.
Peering.
F
Based
on
that
identifier,
and
I
did
mention
in
the
block
that
clients
might
want
to
include
both
the
fork
number
and
the
fork
time
and
so
like
during
a
fast
sync,
you
could
use
the
the
block
number
as
an
aid
to
make
sure
that
you're
doing
it
correctly,
but
in
all
the
synchronization
methods
right
now,
everyone's
getting
all
the
headers
anyway.
So
you'll
have
time
to
validate
and
since
you're
only
checking
every
thousandth
header,
it
shouldn't
be
too
much
of
a
validation
burden
on
fastings.
G
C
F
So,
what's
hitting
us
what's
hitting
us
on
roxton
is
hash
rate
is
much
more
highly
variable
than
it
is
on
mainnet.
There's,
no
economic
incentive
to
keep
all
your
hashes
pointing
to
make
money
is
the
experience
with
istanbul.
Somebody
pointed
a
lot
of
hashtag
early,
because
I
guess
they
were
testing
a
new
rack
or
something
and,
and
they
like
you
know,
doubled
or
10x
the
hash
rate,
so
that
brought
brought
it
forward
three
days
sooner
than
we
thought
it
was
going
to
happen.
F
We
wanted
it
on
a
wednesday
and
it
still
happened
on
a
weekend
for
mainnet.
What
hit
us
with
istanbul
was.
We
were
not
sure
what
the
impact
of
the
ice
age
was
going
to
be.
We
didn't
know
if
it
was
going
to
be
a
half
a
second
impact.
Two
second
impact
10
second
impact.
I
think
our
estimates
for
getting
mere
glacier
on
the
sixth
was
based
on
a
22nd
block
time
and
it
wound
up
being
17
which
pulled
it
into
the
day
after
new
year's.
F
G
J
And
I
think
one
thing
that's
nice
about
this
proposal
is
the
fact
that
there's
like
this
thousand
to
two
thousand
block
delay,
which
is
like
I
don't
know
a
couple
hours,
so
you
can
imagine
a
case
where,
like
you,
do,
set
up
alerts
for
that
time
and
then
it
gives
you
like.
A
thousand
block
warning
to
you
know,
monitor
the
fork
so
that,
and
and
also
just
like
within
the
community.
You
know
it
gives
an
opportunity.
The
message
of
like
hey
this
thing
is
happening
in
a
couple
hours.
J
The
only
potential
drawback
I
see
is
whether
or
not
having
this
window
would
mean
that,
like
exchanges
and
whatnot
would
pause
deposits
and
withdrawals
for
a
longer
period
that
they
do
now
so
right
now.
I
think
they
only
do
it
for
a
couple
hours,
but
if,
if
this
is
like
a
thousand
blocks,
I'm
not
sure
if
that's
longer
or
shorter,
but
on
that
probably
it's
probably
good
to
give
this
like
two-step
warning
that
the
upgrade
is
happening.
G
J
F
J
H
G
J
F
B
B
I
I
So
I
use
the
rust
as
a
kind
of
metering
source
for
all
the
gas
estimates,
so
in
principle,
right
now,
what's
left
is
basically
how
I
should
integrate
it
into
a
few
existing
clients,
I'm
only
familiar
with
priority
and
gas,
and
there
are
a
few
options,
whether
to
use
kind
of
a
single
implementation
or
use
two
independent
implementations
into
independent
clients,
for
example,
and
with
all
of
this
because
well
for
priorities.
The
ras
library
is
easy
to
include
and
compile
for
gas.
I
So
all
those
advices
would
be
welcome
or
common
sense,
inspired,
also
to
simplify
alternative
implementations,
because
I
know
that
there
is
one
happening
right
now
in
go,
which
is
still
non-complete.
As
far
as
I
know.
Maybe
it
would
be
possible
kind
of
to
put
a
performance
margin
like
use.
The
current
numbers
for
gas
between
which
are
acceptable
for
rust
and
c-class,
plus
and
just
say.
Well,
alternative
implementation
in
gold,
for
example,
would
not
be
more
than,
for
example,
twice
slower
than
those
two
existing
ones,
and
so
I
can
incorporate
all
those
changes.
G
However,
we
cannot
integrate
rust
code,
so
the
only
thing
we
could
do
with
rust
is
to
have
a
sub
completely
separate,
rust
combination,
step
that
builds
a
shared
library
or
static
library
and
then
somehow
link
that
to
togeth,
but
that
completely
and
utterly
blows
up
the
entire
build
process.
And
then,
instead
of
using
go
as
a
build
tool,
we
would
need
to
have
make
files
and
custom
steps
and
that's
definitely
not
something
we
want
to
do
so.
Technically,
it
is
doable,
but
practically
it
just
nukes.
The
entire
project's
simplicity.
I
Yeah,
so
the
c
plus
plus
implementation
is
written
in
a
quite
modern
dialect
of
c,
plus,
plus
and
well,
not
even
the
library
itself.
It
also
relies
on
the
dependency
which
does
all
the
arithmetics,
so
the
arithmetics
implementation
is
not
done
by
by
me
in
c
plus
plus
code.
I've
taken
the
existing
ones
existing
one,
but
it
still
gives
me
the
same
results
as
in
the
rust,
where
I
have
re,
I
have
written
all
by
myself
and
those
two
require
c
plus
plus
17..
I
I
don't
know
what
containers
you
use
in
your
building
pipeline
and
just
depending
on
what
what
linux
edition
and
distributive
you
use,
you
may
have
or
may
not
have
a
modern
enough
compiler.
This
is
my
only
concern
for
c
plus
plus
side.
Otherwise,
if
you
say
that
you
can
easily
build
a
plus
where
I
had
some
problems
as
far
as
I
tried
the
last
time,
then
sure
it's
it's
as
good
for
me
as
any
other
version.
G
I
G
A
Yes,
sorry
for
making
noise.
So
what
I
I
read
on
your
comment
here
that
it
moved
to
move
to
ten
separate
operations.
That's
my
map
to
pre-compile
addresses,
and
I
looked
at
the
eep
and
I've
seen
no
such
changes
in
the
eep.
So
I'm
kind
of
wondering
where
this,
where
these
changes
are
taking
place
and
where
we
can
follow
the
progress.
I
Well,
there
is
a
kind
of
reference
rust,
well
reference,
github
with
all
the
rust
code
and
also
a
few
documents
which
describes
a
binary
interface
and
operations
which
are
now
10
separate
of
them.
I
just
didn't
make
the
the
can.
I
did
just
make
another
pull
request
to
the
eip
to
update
it
to
the
current
state,
but
I
still
maintains
the
list
and
kind
of
also
description
of
binary
interfaces
now,
with
10
separate
kind
of
operations.
I
I
would
also
need
to
change
few
config
files.
I
think
which
will
require
me
to
have
to
knows
addresses
for
all
these
10
pre-compile
functions
which
people
wanted
me
to
make,
which
should
be
mapped
to
10,
independent
recompile
addresses
and
just
to
finish
this
integration.
I
would
need
to
know
those.
B
I
Well,
I
mean
if
someone
would
want
to
integrate
it
into
parity,
for
example
himself
I
think
I'll
say
go
when
people
will
need
to
integrate
it.
They
will
need
to
know
this
information.
I
can
just
leave
placeholders
for
now,
just
not
that
important.
I
think
so.
The
second
question
is
kind
of
performance
margin
for
future.
I
If
alternative
implementations
arise
with
a
literally
different
performance,
so
right
now
the
difference
between
c
plus,
plus
and
graphs
is
ten
percent
within
and
kind
of,
plus
and
minus
in
different
parts,
just
more
like
a
deviation
so,
but
for
the
future.
If,
let's
say
there
will
be
some
other
implementation
notes
that
performance,
but
still
alternative
and
matches
to
existing
ones
completely,
and
someone
would
want
to
use
this
implementation,
for
example,
in
gas,
then
we
can
just
kind
of
give
the
performance
margin.
So
I
will
just
blindly
multiply
all
the
gas
prices
by
two.
I
Yeah
for
this
I
would
need
an
advice
I
can
do
the
I
can
just
do
the
comparison
with
the
current
bn
curve.
Right
now
for
most
of
the
operations,
it's
it's
cheaper.
I
just
didn't
try
with
the
pairing
operation
so,
but
even
for
example,
1.5
efficient
is
still
a
good
margin
anyway,
and
just
as
a
security
feature
too.
I
That's
it.
I
mean
it's
beneficial
from
both
sides,
so
it
will
not
make
free,
compile
completely
useless,
but
zeke
efficient,
whether
it's
1.5,
for
example,
or
two
I
also
wouldn't
want
to
go
above
2-
would
be
kind
of
a
way
to
allow
people
to
make
alternative
ones
in
other
languages,
which
will
kind
of
not
give
this
exact
performance.
I
G
A
I
A
I
I
A
G
A
I
B
F
That's
something
to
be
shorter.
I
just
want
to
point
out
that
I
in
the
ethereum
magicians
forum,
I
just
I
gave
responses
to
two
of
the
concerns.
The
first
one
was
about
validating
in
transactions,
and
my
principal
argument
was
that
the
contract
can't
be
too
long
because
of
the
gas
limits.
It's
either
gonna
be
two
and
a
half
if
it's
nothing
but
zeros,
two
and
a
half
megabytes,
or
something
between
half
and
a
full
megabyte
if
it
is
not
full
of
zeros.
F
So
I
put
some
numbers
in
there.
I
don't
know
if
those
will
address
martin
and
peter's
concern
about
the
attack.
So
this
is
a
request
for
comment
in
that
thread
and
also
the
second
concern
was
about
why
headers
and
why
not
some
other
mechanism
to
identify
contracts
that
are
subject
to
the
validation
rules?
The
strongest
argument
actually
came
from
some
of
the
work
that
wade's
been
doing
on
his
on
gas.
F
H
F
B
Okay,
the
eipip
ethereum
improvement
proposal,
improvement
proposal
meeting,
also
known
as
the
eip
improvement
processes
meeting,
is
going
to
start
happening
next
week.
I
need
to
still
schedule
the
day.
I
don't
know
what
day
is
best,
I'm
going
to
guess
wednesday.
That
feels
right
and
that's
going
to
be
organized
over
telegram,
but
I
might
do
a
chat
bridge
together
if
that'll
help
some
people
reach
out
to
me,
preferably
on
telegram
or
at
hudson
ethereum
dot
org.
B
B
They
did
that
hudson
to
connect
the
clients
to
get
the
latest
versions
of
mere
glacier
ech,
and
I
did
that
action
item
77.3
create
an
eip
ip
telegram
channel.
Yes,
I
did
that
and
again
you
can
email
me
at
hudson,
ethereum.org
or
chat
with
me
on
telegram
to
get
added
to
that
action.
Item.
77.4
is
for
someone
to
contact
eric
and
add
the
block.
Rewards
are
unchanged
line
to
the
eip.
I
don't
know
if
that
ever
happened.
I
did.
H
L
The
rest-
I
do
I
just
so-
I
just
want
to
bring
to
your
attention
there
was
there
there's
we
had
a
discussion
between
starkware
and
geff
about
the
maximum
transaction
size
of
in
the
bampoo
to
get
accepted
into
example.
We
this
has
been
even
in
being
resolved
with
the
f
team.
They
they
had
a
limitation
there,
and
I
just
want
to
bring
it
to
the
attention
of
the
other
client
that
this
limitation
or
other
limitation
could
be
a
problematic
for
many
layer.
Two
solution.
L
L
L
Default,
I
mean
they
can
let
martine
in
we.
This
is
getting
solved
on
their
own
on
this.
We
are
already
at
a
diary
discussion
for
a
few
months
and
this
is
getting
sold.
I
just
want
to
bring
it
to
the
rest
of
the
attention
that
this
sort
of
limitation
could
be
a
problem
for
l2
solution
in
the
future.
G
It's
mostly
the
work
was
because,
because
we
wanted
to
make
sure
that
no
denial
of
service
can
occur
due
to
transactions,
but
I
guess
the
important
memo
here
is
that
geth,
probably
from
the
next
release
guest,
will
also
allow
propagating
larger
transactions.
So
people
might
be
able
to
use
transactions
that
are
not
only
limited
at
32
kilobytes,
but
actually
at
128..
G
Yes,
actually
I
wanted
to
do
that.
Just
figured
I'd
wait
until
the
end,
but
I
guess
now
is
as
good
as
the
time
as
any.
So
currently
the
theorems
the
way
nodes
propagate
transactions
in
the
network
is
horrible,
actually
geth
relays
every
single
transactions
to
every
single
peer
it
has
in
theory.
It
would
be
enough
to
relate
to
a
logarithmic
number
of
peers.
H
G
Problem
is
that,
if
you
have
some
weird
connection,
then
it
can
happen
that
you
miss
out
some
transactions
and
the
theorem
protocol
currently
does
not.
I
mean
ethereum.
Networking
protocol
currently
does
not
have
a
means
to
request
transactions.
If
you
missed
something,
you
cannot
ask
your
peers
for
it.
E
G
E
G
L
G
Well,
this
is
really
kind
of
trivial,
so
it's
just
the
same.
So
currently
the
ethereum
protocol.
You
can
request
blocks
by
hash.
You
can
request
receipts,
you
can
request
everything
by
hash
except
transactions,
so
it
will
be
extending
that
and
the
same
way
that
you
can
announce
blocks
it
would
so
I
I
don't
I
mean
that
would
if
you
have
a
link
to
somebody
else's
work.
We
can
definitely
take
a
look,
but
this
is
really
something
super
trivial.
G
Yeah,
so
that
so
that's
definitely
also
something
that
we've
been
thinking
about,
but
in
reality
we
wanted
to
so
sorting.
The
transaction
propagation
problem
out
is
fairly
trivial,
so
just
a
tiny
addition,
we
can
get
a
new
protocol
version
released
and
see
that
it
actually
works,
and
then
we
can
look,
look
at
the
whole
block
propagation,
whether
that's
an
issue
or
not.
Generally,
since
we're
only
propagating
blocks
to
logarithmic
number
of
peers,
it's
not
really
an
issue.
In
my
opinion
I
mean
we
can
definitely
make
it
more
optimal,
but
it's
not
it.
L
On
that
specific,
I
completely
agree
about
the
block
propagation
itself.
I
mean
if
we
could
reduce
also
the
propagation,
then
time
which
is
roughly
today,
200
milliseconds.
If
I'm
correct,
it
would
be
something
that
would
be
compared
to
the
mining
time
of
of
an
ethereum
block.
It's
somewhat
still
significant.
I
mean
not
not
as
of
now.
Of
course,
I'm
just
like
in
the
future.
That
could
be
a
nice
improvement.
G
C
C
C
I
have
an
observation,
and
this
this
isn't
anything
to
do
with
this
doesn't
say
anything
about
your
eid
or
your
process
alex,
but
I
think
is
a
comment
on
on
the
process
in
general
and
possibly
one
also
focused
on
improving,
which
is,
if
I
think,
back
to
blake
2b
and
I
think
back
to
1559.
I
think
back
to
others.
That's
a
single
source
of
truth,
we're
keeping
up
to
date
and
where
that
is,
it
needs
to
be
a
difficult
thing
to
keep
track
of.
I
Yeah,
I
just
don't
know
if
I
can
just
make
another
pull
request
to
update
the
text
of
the
existing
eip
in
the
corresponding
repository.
I
just
don't
know
what
was
the
previous
standard
process.
I
can
post
it
in
both
places
or
just
continue
updating
it's
it's
like
eip
github,
which
is
like
whatever
we
decide
now.
I
will
just
do
this
way.
B
Yeah,
I
would
say
the
eip
github
in
combination
with
the
ethereum
magicians
thread.
If
you
have
one
already
that
should
cover
it.
In
my
opinion
and
that's
kind
of
what
we're
leaning
toward
or
were,
I
feel
like
we're
heading
that
direction.
Standards
wise.
It
was
kind
of
vague
before
what
do
you
think
james,
but.
C
I'm
I'm
just
I'm
noticing
that
there
is
a,
and
this
is
more
of
a
processing
unless
it's
not
on
your
actual
fpl
and
you're
doing
great
on
that.
But
the
there
seems
to
be
a
lot
of
tension
between
keeping
those
things
in
line,
whether
we
keep
the
amount
of
effort
required
to
keep
going.
Is
it
worth
it
or
try
it
in
a
way
that
has
less.
G
G
G
M
G
L
L
G
I
don't
think
that's
correct,
so
the
the
whole,
the
networking
protocol
was
pretty
much
standardized
even
before
frontier,
and
then
we
used
the
usual
eip
process
to
make
changes
to
it.
So
the
only
thing
is:
that's
not
standardized
is,
for
example,
lds
is,
since
it's
only
supported
by
geth.
It
was
kind
of
never
modified
through
the
all
chord,
of
course,
because
nobody
else
had
it.
G
So
there
was
not
really
a
point
to
to
have
to
introduce
all
that
bureaucracy
here,
but
with
regard
to
the
eth
protocol
or
the
deaf
pewter
peer
or
discovery,
all
of
them
were
pretty
much
made
here
against
once
something
that
was
not
not
designed
through
the
overlapped
work
at
all
code,
of
course,
was
the
discovery
v5
plus
the
nr
stuff,
but
that
again
usually
was
because
nobody
else
cared
about
them.
So
people
just
assumed
that
whatever
the
deaf
people
authors
come
up
with
is
fine
but
again
discovery.
G
V5
was
something
that's
completely
independent
and
completely
new
and
after
the
whole
initial
specs
were
done
even
before
implant.
We
started
implementing
it.
I
think
nethermind
already
jumped
on
it.
So
we
had
a
few
other
teams
collaborating.
So
it
wasn't
really
collaborated
through
the
awkward
of
course,
but
it
was
a
collaborative
thing.
E
There
are
multiple
things
on
networking
that
would
that
would
actually
benefit
from
being
standardized.
There
is
one
one
particular
example
that
you
can
give
from
another
mind
when
we,
when
we're
sending
requests
for
the
nodes
in
the
fastsync
mode,
the
requests
are
handled
both
by
parity
and
gif,
and
the
way.
G
E
Are
optimizing
it?
We
create
the
request
patches
first
and
then
we
decide
whether
to
send
it
to
parity
or
get,
and
the
limits
for
the
sizes
of
the
requests
in
parity
are
at
around
1024
and
you
get
and
they
are,
I
think,
get
handles
192
at
most
and
requests
up
to
256,
and
the
thing
is
if,
if
parity
doesn't
want
to
respond
to
a
big
request,
it
actually
just
sends
you
as
much
as
it
wants
to
send
you
back
and
you
can
handle
the
part
and
then
re-request
the
rest.
E
But
kent
actually
disconnects
you
as
a
punishment
for
requesting
too
much,
which
means
that
we
cannot
ever
use
the
fact
that
parity
can
give
us
more
data,
because
if
we
send
it
without
knowing
exactly
which
note
we'll
be
assigning
it
to,
then
we
might
be
disconnected
by
all
the
guest
nodes.
So
these
are
all
these
like
small
things
that
are
not
really
specified,
and
if
63
like
there
is,
there
is
no
definition
that
we
should
get
disconnected.
E
There
are
some
specific
behaviors,
unlike
when
the
null
headers
are
sent
by
get,
for
example,
which
was
not
following
the
protocol
and
not
specified
anywhere
and
they're
above
the
backs
reported
in
the
past
in
parity
and
in
nethermine,
when
the
special
condition
was
found.
So
any
any
further
specification,
like
very
detailed
specification
of
those
network
protocols,
improve
it
for
the
future.
E
G
Just
to
react
to
one
of
them,
so
you
mentioned
that
get
disconnected.
You
request
more
data
than
some
limit,
and
that
seems
so.
That's
definitely
not
something
we
want
to
do
so.
We
simply.
If
you
request
too
much
data,
then
we
stop,
I
mean
we,
we
have
limits
and,
for
example,
if
you
request
000
state
entries,
then
you
will
get
370
something
back
and
that's
it
and
you
can
request
that.
J
E
E
G
Yeah,
but
that
should
you
probably
want
to
open
an
issue
because
that's
definitely
not
the
behavior
we
intend.
So
we
don't.
We
never
intend
to
disconnect
just
because
we
requested
more
data,
so
it
should
be
a
clear
protocol
violation.
So
we
only
disconnect
if
you
send
something,
that's
definitely
junk
that
cannot
be
interpreted.
G
Yeah,
I
guess
the
here.
The
thing
with
the
festival,
fasting
and
863
is
that
when
we
implemented
this
whole
protocol,
essentially
geth
was
the
single
client
which
had
this
thing.
So
there
was
a
the
e63,
was
kind
of
just
packed
as
hey
kind
of
these
are
the
messages,
but
there
was
nothing
on
cpp3
implemented.
This
was
before
frontier.
I
think
I
think
this
is
like
a
common.
E
Pattern
when
you,
when
we
when
we
hear
what
we
are
saying
here,
that
like
fasting,
was
the
get
only
less
the
client
like
client
was
to
get
on
in
discovery
five
as
they
get
guess
only.
I
think
the
reason
they
are
remaining
for
so
long
he's
on
guess
only
it's,
because
because
the
spec
would
have
to
be
like
more
detailed
and
it's
it's
very
natural,
are
we
doing
the
same
whenever
we're
doing
something
that
only
we
do
at
the
moment,
then?
E
G
Yeah,
I
completely
agree
and
that's
pretty
much
the
reason
why
why,
instead
of
why,
we
came
with
this
whole
fork
idea
and
we
wanted
to
spec
it
out
as
an
eip
and
when
that's
specifically
the
reason
why
we
brought
it
up
today
to
that
hey.
We
have
this
whole
transaction
propagation
issue
and,
let's
back
it
out
properly,.
E
B
E
E
In
our
case,
it
was
slightly
different
thing,
so
we
we
missed
the
validation
on
some
of
the
incoming
new
blocks
and
we've
added
that
and
it
solves
it
as
well,
and
the
priority
already
has
a
fix
where,
where
that
cache,
actually
hashes
the
raw
content
of
the
blog
body
and
stores
it
separately.
So
it
says
the
block
is
only
discarded
immediately
is
invalid.
If
the
hash
of
the
content
is
exactly
the
same
and
not
the
advertisement.
G
E
Yeah
so
like
how
how
it
was
done
on
particular.
Actually
we
indicated
when
we
were
saying
that
guest
notes
are
actually
sending
that
every
now
and
again
guests
are
propagating
the
invalid
combinations
of
headers
and
bodies,
also
like,
for
example,
I'm
receiving
a
lot
of
invalid
nodes
from
the
get
node
data
from
from
gif.
Sometimes
the
hash
doesn't
match
the
content,
so
whether
these
are
specifically
designed
attacking
death
notes
or
just
some
bikes,
it's
hard
to
say.
G
M
E
Because
at
the
moment
we
have
code
that
says,
like
only
when
you
send
to
us
something
like
and
bad
things
in
a
second
and
only
then
we
disconnected,
but
literally,
we
have
to
be
very,
very,
very
like
soft,
on
behavior
of
other
nodes.
So
it
might
be
that
we
should
start
like
communicate
more
on
those
network
issues
and
then
raise
it
more
and
then
or
just
remove
all
of
those
problems.
A
So
guess
our
monitoring
guest
node
is
still
picking
up
these
bad
blocks
and
storing
them
in
the
bad
block.
Cache
so
geth,
like
parody
flags,
a
particular
hash
as
bad,
but
the
difference
is
that
we
don't
actually
use
that
as
a
blacklist
in
the
future.
We
do,
we
do
maintain
it.
So
if
we
want
to
analyze
it
from
the
outside,
we
can
retrieve
the
bad
blocks,
but
we
don't
blacklist
based
on
it.
So,
therefore,
later
on,
once
we
get
the
correct
body
content
for
that
header,
we
successfully
import
it.
E
A
G
E
E
Now
we
can,
we
can
try
to
like
copy
the
data
from
the
telegram
channel,
where
we're
discussing
it
with
the
mind
yeah,
with
a
priority
team.
Yeah
I'll,
send
a
few
questions,
a
few
answers
and
then
like
what's
more
than
but
like.
I
cannot
promise
you
that
it
will
be
very
quickly
done
on
the
like
formal
way,.