►
From YouTube: Node Operator Roundtable - June 7th, 2023
Description
This week's discussion is centered around the management of peer-to-peer connections. One proposed solution involves categorizing peers as internal or external to improve reporting and metrics.There's also a suggestion to limit data syncing to manage bandwidth usage, considering factors like trust levels, efficient syncing, and rotation of loads among peers.
00:00:00 Start
00:00:51 Peer 2 Peer Improvements
00:12:47 4.0.0 feedback
00:20:41 Peer Management
00:39:58 Node Configurations
00:47:30 Consensus Upgrades
00:58:26 End
The EOS Network Foundation coordinates financial and non-financial support to encourage the growth and development of the EOS Network. We’re harnessing the power of decentralization to chart a coordinated future for the EOS Network as a force for positive global change.
// EOS Network Foundation //
https://www.eosnetwork.com
https://twitter.com/EosNFoundation
https://www.linkedin.com/company/eos-network-foundation
https://t.me/EOSNetworkFoundation
https://discord.gg/eos-network
info@eosnetwork.com
#EOS #Web3
B
B
He
has
been
working
on
the
better
defining
an
Initiative
for
some
peer-to-peer
improvements
and
he
has
some
some
things
to
bring
to
this
group
for
feedback
and
get
some
answers
to
some
things.
So
I'm
just
going
to
hand
it
straight
over
to
Stephen
to
do
that
and
then
we'll
move
into
discussing
consensus
upgrades
after
that
Stephen.
C
Great,
hey,
everybody
been
a
minute
great
to
see
you
all
yeah,
so
one
initiative
that
We've
of
course
talked
about
in
the
past
and
that
we
are
working
to
prioritize
in
part
for
this
upcoming
release
and
likely
one
to
follow
is
some
various
improvements
around
P2P
protocol,
specifically
we're
interested
in
solving
just
any
sort
of
incremental
improvements.
We
can
make
around
the
stability
and
reliability
of
the
transactions
in
transit
across
that
Network,
and
also
just
improving
node
operator
quality
of
life.
C
The
first
question
I
had
was
just
really
around
whether
or
not
there
were
any
specific
peer
connection
behaviors
that
the
group
here
wishes.
They
had
greater
visibility
into
to
learn
about
their
connection,
help
or,
if
there's
any
sort
of
specific
peer
behaviors
that
outright
block
producers
would
like
to
more
easily
manage
some
examples
of
that
would
just
be
any
sort
of
instance
where
you're
consistently
receiving
invalid
transactions.
C
You
know
if
they're,
persistently
desynchronizing
in
some
sort
of
way
things
along
those
lines.
I
can
read
from
my
list
a
few
more
examples
but
I'm
interested
to
know.
If
there's
any
sort
of
gut
reactions
from
this
team
about,
like
oh,
my
gosh
I,
can't
stand
when
X
happens
or
I
really
wish
that
I
had
greater
visibility
into
X,
Y
or
Z,
so
that
I
knew
more
about.
D
Yeah
I
mean
we
want
to
be
able
to
connect
node.
That
has
the
blocks
that
we
require
so
some
kind
of
understanding
of
how
deep
the
block
blog
goes
on
the
pier
the
other
one
is
which
pier
are
we
pulling
our
block
log
from
they're
like
what
are
we
trying
to
sync
with
there's
a
whole
lot
of
black
detail
at
the
moment
we
don't
have
any
detail
as
far
as
I
understand.
Right
I
mean
we.
D
We
just
know
that
we've
got
some
peers
set
up,
you
might
get
something
in
the
logs
saying
you
know
it
goes.
Red
era
appear
tells
you
you
know
to
go
away
or
something
like
that.
I
think
it
actually
says
that
but
yeah
information
about.
Where
are
you
pulling
your
synchronization
log
from
and
don't
want
to
be
pulling
from
something
that
doesn't
have
the
the
blocks
that
we're
looking
for
I'm?
Looking
for
block
number
10
million,
something
10
million,
something
anybody
you
do
you
have
anything?
No,
no.
D
We
sit
there
and
I
know
it'll
just
be
like
stagnant,
why
it
waits
to
eventually
I,
don't
know
what
what
the
signal
is
for
it
to
go
to
another
node.
Sometimes
it
will
go
to
another
load
at
some
point,
but
I
don't
know
information
and
awareness
of
our
and
node
of
what
the
nodes
that
it's
connecting
to
have
available.
D
F
Basically,
I
agree
with
Ross:
it's
a
black
box,
we
don't
know
what's
going
on
so
and
the
the
big
Behavior
that's
a
problem
is
when
it's
not
syncing
or
Sinking,
slowly
right,
which
comes
down
to
peers
that
do
or
do
not
have
the
blocks.
I
remember
when
we
first
introduced
the
chopping
off
the
block.
Log
and
I
had
a
conversation
with
Kevin.
This
was
like
years
ago.
My
note
is
not
syncing
I,
don't
know
why
and
then
after
investigation.
Oh,
are
you
connected
up
here?
That
actually
has
the
blocks?
Oh
right,
yeah.
So
I.
F
C
H
E
E
If
it
was
yeah
one
coming
in
and
I'm
sinking
it
to
the
18
people
that
are
72
people,
200.
yeah,
you
would
think
that
it's
I'm
getting
one
in
and
I
would
see
it
70
fold
on
the
way
out.
But
it's
not
it's
in
lockstep,
so
it's
almost
like
it's
always
ping
pong
or
or
I,
don't
know
so
anyway.
I
would
say,
there's
definite
inefficiencies
in
just
how
it
tries
to
sink
and-
and
does
sync
also,
you
know
it's.
This
battle
of.
E
It
asked
the
same
five
or
three
servers
or
ten
servers
for
the
same
information
over
and
over
and
over.
So
we
always
say
you
want
to
sync
and
not
just
brush
it,
remove
it
out
of
one
peer:
that's
low,
latency
and
it'll
stream
in
comparison
to
10
periods,
I
mean
just
totally
counter-intuitive,
but
it's
because
and
you'll
watch
your
bandwidth,
Houston
20
mag,
tablet
too,
you
know
I
mean
so
things
like
that,
just
in
whatever
I'll
also
say
and
I
have
no
details.
E
Other
than
just
graphs
I
feel,
like
people
are
figuring
out
ways
to
come
in
through
the
peer-to-peer
somewhere
along
the
line.
Only
because
I
can
see
a
normal
peer
stays
connected,
I
mean
unless
it's
Disturbed,
it's
pretty
consistent,
I
mean
I've,
seen
issues
where
it'll
go
from
70
to
150
and
and
then
just
you
know
want
it
back
down
to
the
original
70,
and
it's
like
there
was
something
in
there
that
wasn't
a
normal
peer-to-peer.
E
It's
not
that
normal
Open,
Session,
continued
stacking,
so
I
mean
I
feel
like
and
I
have
no
clue
what
they
were
doing
now.
This
is
a
black
box.
We
were
just
getting
beta
and
sloughing
it
off
if
it
was
bad,
but
I
think
that
versus
an
API
which
I
have
way
more
control
over
and
it's
HTTP
traffic
and
I
can
sniff
it
and
roll
it
sure
this
is
the
merciles
wide
open.
Let
it
rip
a
CCP.
C
Are
there
any
specific
things
like
if,
if
we
were
to
shed
some
more
light
on
this,
that
you
would
assume
would
be
some
of
the
more
helpful
things
to
know
about
a
peer
connection
that
could
confirm
what
you
think
that
behavior
is.
It
sounds,
like
you
don't
quite
know,
what's
happening
here,
you're
saying
it's
abnormal
from
your
experience.
What
are
some
of
the
things
that
you'd
like
to
have
visibility
into
to
successfully
diagnose
this
and
then
maybe
even
support
future
development
to
better
manage
those
sorts
of
connections
or
behaviors.
E
Hey
I'd
say
on
that
one
I,
don't
I,
don't
know
the
best
answer.
I
mean
there
is
the
peer
plug-in,
so
I
mean
which
one
is
it
that
the
node
plugin,
whichever
one
it
is
where
you
can,
control
your
peers
and
see
your
peers
and
Status
like
that.
I,
don't
know
how
useful
you
know
it
is
for
chasing,
but
I.
G
Don't
know
exactly
it
would
be
great
if
we
can
have.
You
know
like
a
standalone
tool
that
could
be
part
of
maybe
reputil
or
something
that
can
deal
with
this
gear
plugin
and
show
you
something
like
an
edge
stop
or
like
a
top.
You
know
that
shows
you
all
your
connected
PS.
What's
the
current
bandwidth
being
used
for
each
one,
you
coming
or
outgoing,
what's
the
last
sixth
block,
what's
their
current
block
range
and
allowed
it
to
disable
or
or
add
peers
that
would
at
least
give
us
Insight
of
where
the
problem
is?
D
G
Does
in
a
way
right,
it's
like
shows
you
in
the
notice
message
like
the
range
of
the
blocks.
It
allows
you
to
limit
the
number
of
nodes
you're
gonna
connect
to,
even
if
your
list
is
longer
so
it
will
only
connect
the
nodes
that
actually
have
the
blocks
you
want
and
the
ones
and
like
sort
them
by
lowest
latency.
C
Exactly
and
it's
it's
a
build
measure
learn
process
right.
I
I
know
that
the
end
goal
shouldn't
be
that,
like
hey
it'd,
be
really
great.
If
Ross,
you
could
just
like
go
look
in
there
and
and
tell
me
how
we
can
fix
your
problems,
but
that
that's
that's
one
step
along
the
way
right.
We
we
start
to
increase
that
visibility,
so
we
can
identify
those
patterns
so
that
we
prioritize
development
work
to
make
it
that
easy
button
of
just
like.
D
D
C
G
Today,
yeah
well,
we
just
I
ran
an
issue
on
on
EOS
itself,
where
the
node
will
just
be
consuming
like
there
was
only
like
Upland,
mainly
transactions,
but
the
node
will
use
like
a
ton
of
CPU
and
it
didn't
make
much
sense
because
the
block
wasn't
very
full.
It
wasn't.
You
know
like
it
didn't
make
sense
to
me,
but
I
was
on
the
old
version
as
soon
as
I
upgraded
4.0.1.
G
It
was
using
like
two
percent
again
of
CPU,
so
that's
not
like
there'll,
be
a
specific
problem,
but
that
being
said,
we
are
finally
like
we're
testing
out
the
4.01
for
our
ux
Network,
with,
like
small
modifications
and
I'm
running,
like
some
tests
started
to
run
some
tests.
Many
on
like
parallelization
and
you
know,
return
value
and
read-only
transactions,
but
also
I'll,
be
able
to
provide
more
see
back
after
I.
Do
that.
C
Yeah
that'd
be
great.
Any
feedback
that
you
guys
do
have
excuse
me
is
wanting
to
steal
the
show,
but
as
that
feedback
comes
along
I'd
love
to
receive
it
and
be
kept
in
the
loop
around
that
is
there
any
other
feedback,
specifically
around
undesirable
behavior
that
we
may
wish
to
bring
greater
exposure
and
visibility
to
as
an
initial
step.
E
I'll
say
one
last
idea:
I'm
involved
in
it
was
on
that
inefficiency
of
sinking,
peers
and
catching
up
of
nodes.
One
thing
that
popped
into
my
head
is
that
maybe
when
you're
in
that,
what
I
call
the
the
Mad
Dash
to
catch
out,
the
you
know
when
you
know
you're
behind
lib,
you
start
sinking
in
mass
and
doing
whatever.
E
You
know
an
easier
win
instead
of
changing
the
whole
protocol,
as
it
is
to
any
other
Ram
applications
that
may
come
from
a
node,
not
spamming,
everything
to
try
to
keep
in
sync,
but
if
it's
in
catch-up
mode,
so
all
to
know
to
pull
this
up
back
because
yeah,
this
PR
says
default
three
or
five
or
ten
or
whatever.
You
can
manually,
manage
your
list
but
you're
having
to
manually
figure
it
out
even
anyway.
But
if
it
can
just
say,
look
I
just
need
one
of
you
guys,
that's
the
best.
C
E
To
that
inefficiency
of
the
peers
and
well,
if
you've
got
five,
it's
going
to
try
them
all
it's
going
to
keep
asking
them
for
the
same
info
and
and
yeah
visibility.
You
know
to
go
and
trim
them
down
this
one's
working.
These
aren't
whatever,
but
ultimately
all
we're
trying
like
Ross
said.
Visibility
is
great.
What
I
really
wanted
to
do
is
just
be
like
I.
Don't
need
to
look
at
it
Emmett,
just
like
an
ethereum
node.
E
Does
it
says
Who
the
hell's
out
there
got
my
data,
give
it
to
me
in
their
most
efficient
way
possible.
Oh,
that
Pier
went
offline.
Let's
try
to
find
another
one
in
the
list,
but
in
that
lib
catch-up
mode
is
really
where
that's
painful
and
you
don't
need
the
peer-to-peer
virus,
which
is
the
you
know,
it's
really
efficient
at
making
sure
everybody's
on
the
same
hey.
She
that's
I,
think
what
kills
it
when
you're
sinking,
300
million
blocks,
yeah.
C
Yeah,
so
what
I'd
love
to
transition
to
from
here
is
I
got
some
great
feedback
around
some
of
like
the
undesirable
things,
and
we
started
tapping
into
the
flip
side
of
that
and
that's
what
I'd
like
a
little
bit
more
feedback
on
is
what
are
some
of
the
desirable
behaviors,
obviously
like.
If
so,
and
so
has
the
data
I
need
I
like
them
better
right,
if,
like
like
what?
D
Stephen
I
feel
like
you've
got
like
you're
asking
these
questions.
I
almost
pointed
you
have
got
some
ideas,
there's
anything
that
you
wanted
to
share
with
us
about.
It,
there's
obviously
some
conversation
that
you
really
had
with
the
team,
because
I
feel
like
they're,
all
kind
of
loaded.
It's
like
hey,
you
know
like
you,
you
guys
have
got
some
ideas
well,.
C
C
I
will
be
transparent
and
say
that
the
Revival
of
this
conversation
is
a
bit
more
fresh,
so
I'm
taking
some
old
ideas
and
trying
to
get
some
more
material
feedback
from
the
end
user
here,
so
that
that's
what's
happening
here,
but
I
mean
what
we
want
to
do.
Obviously,
is
we
want
to
find
strategies
where
we
connect
to
the
right
pool
of
peers
to
make
the
sinking
process
as
efficient
as
possible?
C
We
also
want
to
slowly
clip
off
any
of
the
peers
that
are
problematic,
because
that's
just
a
form
of
waste
and
I
love
eliminating
waste
where
possible.
So
those
are
the
main
things
that
I'm
talking
about,
but
like
the
how
I
I,
don't
actually
as
a
product
person
own
like
the
the
how
I'm
much
more
of
like
the
the.
C
Why
and
understanding
the
needs
that
you
guys
have
and
that's
where
I
partner
with
engineering
to
actually
say
like
how
the
heck
can
we
do
this
thing
and
we're
kind
of
like
living
right
in
between
that
here,
which
is
helpful
so
I,
don't
I,
don't
have
anything
crazy
to
to
show
you
or
anything.
We
like
obviously
like
these
are
just
like
lists
that
we'd
want
to
manage
and
label
those
peers
in
some
sort
of
way,
so
that
we
can
better
control
them,
but
I'm
I'm,
honestly
not
qualified
to
say
what
that.
How
is.
F
So
is
there
any
advantage
of
like
labeling?
Certain
peers
is
like
this
is
an
internal
peer.
This
is
an
external
Pier
and
then
maybe
that
would
help
from
a
reporting
perspective
or
deciding
what's
to
do
lately
so
like,
for
example,
we've
got
a
whole
bunch
of
peers,
we
run
internally,
but
then
our
public
peer-to-peer,
node
and
Michael
showed
his
architecture
diagram
of
this
right.
We
have
all
these
massive
incoming
peers,
and
then
we
have
all
these
internal
ones
and
the
behavior
that
we
want
from
an
external
woman.
F
That's
our
one
may
be
their
difference,
or
maybe
you
know
if
we're
trying
to
collect
metrics
separating
those
two
things
you
know
is
a
different
thing.
Now
the
internal
peers
might
come
in
like
they
may
connect
as
well
or
we
might,
they
might
be
outgoing.
In
our
environment,
we
cross
connect
everything.
A
connects
to
b
b
connects
to
a
node
us
figures
out
that
there's
duplicate
connection
and
drops
one
of
them,
but
then
that's
like
a
bit
inconsistent
from
reporting.
Well,
is
it
an
in
or
isn't
out?
F
F
F
So
the
automation
writes
the
config
I
in
I,
and
then
we
have
automation
that
reads
it
and
we
can
build
nice
dashboards
out
of
it.
But
you
know
that's
a
hack
built
on
top
of
the
the
structure.
So
you
know
if
we're
trying
to
build
a
dashboard
or
some
comments
about
which
is
in
you
know,
this
is
the
public
seed
peers
and
this
is
the
internal
ones.
Maybe
we
can
distinguish
that.
G
C
F
Yeah
because
they
already
are,
they
are
different
right.
So
one
of
the
things
we're
talking
about
here
is
how
do
we
efficiently
sync
blocks?
Well,
let's
take
the
opposite
is
how
do
we
control
users
who
decided
that
we're
their
best
peer
and
they
want
to
take?
You
know
200
terabytes
of
okay?
Well,
it's
not
trying
to
terabytes,
but
you
know
the
block
logs
are
getting
huge,
so
well
now
they're
all
of
it
from
us.
Well,
that's
a
bit.
You
know
nasty.
Maybe
we
need
to
be
able
to
disconnect
them
after
a
while.
F
Well,
you
got
enough
blocks
for
now:
go
away,
come
back
in
half
an
hour
right,
try
another
Pier,
yeah
or
maybe
we're
being
malicious
and
sending
you
all
the
wrong
blocks,
and
you
just
got
the
most
from
us.
So
now
you
have
the
wrong
block
log
I'm
sure
engineering
has
already
thought
about
that
problem,
but
just
let
it
mention
here
and
there
so
yeah
so
in
the
ethereum
community,
I
can
see.
There's
tons
of
discussion.
People
are
creating
weird
peer-to-peer
clients
and
blocking
peer-to-peer,
legitimate
connections.
F
G
But
that
brings
me
to
like
think
this
new
sync
period
limit
idea
like
once,
it's
selects
based
on
lowest
latency
and
say
you
have
a
hundred
configured
peers
in
your.
You
know
in
your
node
EOS,
not
that
you
should
do
that,
but
say
you
have
a
hundred,
and
now
you
set
your
sync
your
limit
to
ten
or
five.
G
How?
How
often
do
the
others
get
re-evaluated,
because
in
this
current
scenario,
they'll
be
like?
Oh,
yes,
Nations
is
best.
It
has
all
the
blocks.
I
need
it's
going
to
just
keep
it
at
the
top
and
they're
going
to
get
abused
by
everybody
without
any
kind
of
rotational
mechanism
or
or
distributed
kind
of
load
on
on
the
other
players.
So
the
question
is
really
just
think
Theory
limit.
G
E
I'd
say
that
may
fall
into
Matthew's
comment
about.
Let
the
peer
try
to
do
the
most
efficient
think
it
can.
If
you
don't
want
to
get
ripped,
have
like
a
time
window
and
a
maximum
per
you
know
and
say,
look
I
see
that
this
pier
is,
is
already
downloaded.
Two
gigs
this
hour
tell
them
to
go
away
for
the
next
30
minutes,
which
should
then
trigger
the
client
to
be
like
crap
Mason
didn't
get
any
blocks
anymore.
Yes,
I'll!
E
Try
another
one
and
then
step
its
way
through,
because
otherwise
is
probably
gonna
have
to
do
a
lot
of
work
to
be
like
I.
Don't
want
to
make
the
operator
mad,
so
I'm
just
going
to
shift
over
nope
that
one
didn't
work,
that
one
didn't
work,
that
one
didn't
work
that
one
didn't
work
all
right
back
to
Nations
anyway,
you
know
yeah.
F
I
mean
like
I,
can
see
this
kind
of
behavior
like
I,
was
thinking
a
bunch
of
tendermen
chains
and
it
seems
like
if
I
don't
offer
any
blocks,
then
the
peers
don't
want
to
connect
to
me
and
once
I
got
a
couple
of
blocks,
then
the
the
number
of
peers
that
I'm
able
to
connect
to
seems
to
grow.
You
know
so
my
willingness
to
participate
in
the
peer-to-peer
Network.
You
know
incentivizes
other
people
to
connect
to
me
or
something
right,
because
this
is
a
behavior.
F
Well
especially
I
mean
nodius
doesn't
have
this
feature
but
like
in
like
most
of
the
other
blockchains,
you
know
they
they
will
automatically
contact
the
UPnP.
If
your
home,
firewall
router
thing
supports
UPnP,
it
will
automatically
open
the
firewall
port
and
then
allow
users
to
connect
in
I.
Don't
know
big
security
call
from
my
perspective,
but
anyway
great,
but
this
is
the
behavior.
F
D
D
So
when
there's
200
of
them
and
the
thing
is
going
ballistic
and
like
it's
the
decision
about
which
one
to
actually
pull
from
that's
the
thing,
you
know
what
I
mean
it's
like
it
could
just
be
absolute
chaos
and
I
I
mean
I.
I
know
that
I
can
see.
It's
total
chaos
on
our
published
nodes
on
some
chains.
Where
you
know
there's
you
know:
500
Mega
megabits
of
Internet
bandwidth
being
used
for
whatever
peer
whatever
and
that
nodes
actually
also
choosing
to
pull
some
of
the
blocks
from
some
of
those
Piers.
D
When
maybe
it
should
you
know,
and
as
far
as
this
config
goes,
maybe
it
should
choose
some
of
the
ones
that
you've
got
in
generally.
First
I,
don't
know
I
know.
Obviously,
you
don't
want
to
get
into
a
situation
where
you're
in
like
a
loop,
where
you're
only
looking
at
your
own
nodes
and
then
suddenly
you
don't
have
any
blockchain,
but.
H
E
E
Don't
the
number
of
blocks
may
vary
dramatically
right.
You
think
in
the
first
couple,
10
million
blocks,
cool
I
could
rip
that,
and
a
couple
of
you
know
think
spans.
Oh,
you
would
block
300
million.
Oh
no,
that's
a
whole
nother
level
of
you
know:
here's
10
megabit
for
the
next
30
seconds
yeah.
It's.
F
Really
a
bandwidth
damn
it
not
a
block
limit
right
yeah
so
like
for
all
these
internal
peers
like
if
we
go
back
to
my
labeling
or
tagging
thing
right,
I,
don't
care
they
can
suck
as
much
as
they
want
when
it
comes
to
an
external
connection.
Well,
there's
a
limit
now
or
maybe
there's
a
limit
for
that
group.
C
E
It
up
and
I
mean
it's
really
true
types.
I
mean
there's
your
peers
that
you're
connecting
to
so
you
can
obviously
label,
but
a
lot
of
what
we're
kind
of
talking
about
is
I'm
just
wide
open
until
a
limit
gets
hit.
You
know.
Yes,
there
may
be
an
agent
name
coming
in,
but
those
are
you
know
and
they
don't
have
labels.
They
don't
really
know
you
almost
kind
of
gotta
I
guess
treat
them
all.
F
C
I
agree
and
I
mean
we
are
definitely
like
wading
into
the
Waters
of
of
solution
in
here,
which
is
a
risk
to
do
too
soon,
but
I
think
it's.
It's
pretty
evident
that
I
as
a
node
operator
need
to
be
able
to
set
different
constraints
around
how
I
evaluate
the
quality
of
my
internal
versus
external
connections.
Like
that,
that's
pretty
obvious,
and
we
we
can
take
that
and
see
what
the
best
way
is
to
manage.
That
and
I'm.
C
Also
hearing
that
the
greatest
thing
that
a
node
operator
cares
about
is
bandwidth
consumption
from
external
peers
that
that's
something
that
we
need
to
better
manage
like.
If
there
was
one
thing
that
we
could
improve.
That's
the
thing
that
I'm
hearing
is
it's
the
most
important
for
us
to
to
make
some
change
on,
am
I
hearing
that
correctly.
E
I'd
say
yes
and
it's
piggy
back
in
on
the
previous
okay.
I've
got
better
control
of
three
peers
and
try
the
next
one.
Now
you
give
the
ability
for
the
node
operator
to
have
policies
for
a
go
away
message.
You
can
come
back
later
and
somebody
else
tells
you
to
go
away.
One
other
and
it's
a
very
very
you
know,
kind
of
granular
type
of
thing,
but
I
got
burned
on
Matthew
because
a
peer
being
relay
only
or
you
know
you
could
sing
for
me
all
day
long,
but
don't
try
to
shove
transactions.
E
To
me
there
you
know
I
mean
that
intelligence
or
a
flag
you
talk
about
how
it
maybe
checks,
latency
or
blocks
or
whatever
and
I
know
it's
extra
data
and
whatever.
But
if
it
knew
whether
on
the
remote
Pier
was
configured
to
accept
transactions
or
not,
don't
you
know,
I've
I
got
myself
into
a
situation
because
I
have
no
clue.
I
just
got
a
peer
list
right.
If
I
test
them
yep,
they
all
sink.
E
Oh
well,
you
know
I
mean-
and
it's
real
hard
to
know
until
after
the
fact
that
you're
just
shutting
transactions
into
a
black
hole,
because
it's
just
taking
them
and
being
like
so
thought
process
on
that,
obviously
a
much
more
selected
grouping
of
set.
But
that's
that
was
an
interesting
thing
unless
they
tell
you
and
you
know,
you're
trying
to
trim
it
down
and
all
of
a
sudden,
you
got
two
or
three
connections
you're
sinking
to
and
it's
like
cool
I'm
happy.
Oh,
that
was
a
read-only
note.
Did
you
mean
to
do
that
anyway?
C
F
If
we're
starting
to
do
this
Auto
thing
and
then
the
auto
doesn't
understand
whether
it
accepts
blocks
or
transactions,
that's
the
problem,
but
hopefully
you
you
know
it
will
it
does
now.
But
we
need
to
consider
that
even
if
the
the
peer
is
very
far
away
and
it's
the
only
one
that
accepts
transactions
well,
we
gotta
Pier
with
it.
E
Cares
correct
so
you
know
I
can
kind
of,
and
that's
where
I
I
wouldn't
hit,
that
way
up,
complicated,
yeah
and
and
then
your
will
is
a
node
actually
even
want
transactions.
Is
it
in
a
read?
Only
I
mean
you
can
really
go
down
the
rabbit
hole
and
that's
why
I
say
I
I
wouldn't
put
it
on
the
priority
list,
but
it
does
kind
of
tie
into
that.
E
Is
that
I've
backed
myself
into
a
corner
as
a
Blog
producer
which
was
really
bad,
but
even
as
an
API,
you
can
just
be
shoving
them
into
La,
La
Land
and
the
node
just
slucks
them
off,
and
you
never
realize
it
until
you
got
transactions
that
none
of
them
ever
get
to
change
because
they
all
look
successful
to
you.
Yeah.
E
G
Yeah
P2P
accept
transactions
was
around
from
version
two
or
even
before,
like
it
was
around
for
a
very
long
time.
I
don't
know
if
they
changed.
That
Kevin
is
talking
about
is
more
that
now
the
node
will
not
send
transactions,
but
the
option
was
there
like
in
you
know,
using
diffuse
since
the
beginning.
H
Yeah
yeah
it's
been
around
for
a
long
time,
but
it
it
simply
dropped
the
transactions
as
they
came
in.
The
change
in
4.0
is
to
actually
communicate
that
out
to
the
peer
and
tell
it
hey.
You
can
send
me
transactions,
but
I'm,
going
to
drop
them,
in
which
case
then
they
will
stop
sending
transactions,
but
it
turned
out
to
all
the
coming
there
to
make
that
happen,
and
so
it's
actually
backwards
compatible
without,
like
you,
don't
have
to
have
4.0
on
both
sides.
G
C
G
I
was
wondering
if
there's
a
way
to
deter
to
tell
the
node
or
to
configure
a
node
EOS
that
maybe
I
do
have
the
full
block
log.
But
now,
since
we
have
this,
you
know
splitting
of
the
block
log
and
some
users
may
be
like
okay,
you
know,
like
the
super
old
blocks.
I'm
gonna
put
on
a
platter
drive
that's
great
for
my
internal
consumption,
but
it
can't
really
serve
the
masses,
so
maybe
I
want
to
put
in
my
config,
like
only
sync
blocks.
You
know
that
are
maximum
one
million
blocks
away
from
head.
H
F
C
F
E
Correct
and
I
hadn't
quite
figured
out
the
best
way
to
fix
that,
because,
yes,
all
my
source,
that's
in
it
all
my
source
addresses
are
all
the
source
addresses,
are
the
local
network
right
but
again,
and
so
fine
if
you've
got
headers
and
stuff.
But
whenever
it's
you
know
just
kind
of
dumb
TCP
traffic,
it
kind
of
gets
lost
out
there.
Then
you
don't
really.
F
E
E
E
D
G
C
Yeah
I
I
would
dig
in
Absolution
and
trying
to
be
nice,
but
I
was
going
to
say
all
right.
Can
we
kind
of
take
this
back
to
the
needs
so
like
I
as
a
node
operator,
don't
want
to
add
complexity
to
to
nodios
get
it?
That's
fine
I
hear
this
challenge
in
terms
of
identifying
and
labeling
peers
that
are
being
managed,
yeah
a
load
balancer
trying
to
think
if,
without
just
supporting
the
solution
that
you
guys
are
presenting
how
we
could
talk
about
these
problems
a
little
more
foreign.
C
Will
talk
with
something
I
think
that's
great
thanks,
guys
for
all
that
feedback.
It's
very
helpful,
I
appreciate
it,
and
next
steps
for
me
is
that
I
I
will
return
to
this
meeting,
either
next
week
or
week
after
with
a
little
bit
more
cohesive,
Vision
around
what
we're
going
after
on
this
front
and
yeah
we'll
be
in
touch
but
I'll
kick
it
over
to
Daniel.
B
A
On
her,
using
these
things,
come
up
quick
time
flies
and
you're
having
fun
so
I.
Believe
5.0
is
expected
around
September.
Correct
me
if
I'm
wrong,
even
or
Brian,
and
is
that
when
the
final
release
is
expected
to
be
made
available
or
does
the
enf
have
any
strategic
need
to
add
the
features
activated
on
the
main
net
in
September.
B
I
B
You
don't
really
have
the
answer
right
now
and
any
dates.
I
throw
around
right
now
are
absolutely
tentative,
but
I
high
level
expectations.
We
would
hope
to
have
in
late
August
sort
of
like
release,
candidates
happening
and
then
in
September
October
timeline
for
consensus
upgrades
to
hopefully
occur,
but
that's
that's
all
rough
and
tentative
and
we'll
of
course
communicate
as
we
get
as
we
get
closer
and
and
our
confidence
increases.
A
Cool
well,
the
the
typically
then
we've
gone
through
a
few
of
these
now
and
the
biggest
challenge
with
the
consensus
upgrade
is
really
the
coordination
with
the
exchanges,
the
app
making
sure
everyone.
You
know
we're
pretty
well
connected.
You
know,
well
the
node
operators
we
meet
here.
We
have
to
also
be
the
monthly
BP
call
where
it's
it's
pretty
easy
to
coordinate
with
the
block
producers.
A
But
it's
the
challenge
is
making
sure
that
when
we
activate
the
exchanges
are
all
still
working
which
takes
takes
a
lot
of
lead
time
and
preparation
and
putting
together
all
the
materials
and
knowledge
giving
people
that
tests
met
they
can
test
on
and
in
the
most
recent
upgrade
we
did.
There
was
a
strategic
need
to
activate
sort
of
at
us
at
a
particular
time,
which
meant
we
have
to
sort
of
work
back
towards
that
date,
and
there
was
a
little
bit
of
a
scramble.
I
A
B
B
I
won't
go
into
all
the
details
there,
but
in
a
future
call
we
will
actually
go
into
depth
on
that
and
the
implications
of
that.
It
is
a
thing
that,
like
May,
with
a
huge
underscoring
on,
may
have
implications
to
like
how
coordinated
we
need
an
upgrade
to
be,
but
still
still
too
early
to
really
have
a
a
clear
and
concise
description
of
the
implications
there.
A
So
yeah,
ideally,
basically
from
the
time
everything
is,
we
have
a
final
release.
We
have
all
the
documentation
we
have
articles
explaining
here
are
the
new
features
and
why
you
should
care.
We
have
test
Nets
giving
about
two
months
for
the
the
exchanges
the
apps
everyone
to
prepare
for
that
and
test
is
seems
to
be
the
ideal.
A
So
again,
if
once
we
we
get
some
more
clarity
on
again,
do
we
need
to
activate
in
September
or
are
we
more
flexible
with
activation?
And
maybe
we
just
you
know-
maybe
the
final
releases
out
around
September,
and
then
we
shoot
to
activate
two
months
after
that,
and
then
we
would,
you
know,
we'll
get
the
EO
support
team
to
help
coordinate
communicating
with
all
the
exchanges.
A
We
would
work
with
all
the
BPS
to
do
all
the
testing
on
the
test
net.
Obviously,
we'll
have
releases
before
the
final
release.
We
can
start
testing
and
but
really
that's
that's
kind
of
the
main
thing
I've
been
dealing.
Giving
people
two
months
lead
time
with
us.
After
the
final
release
is
out.
We
push.
We
push
out
to
articles.
We
provide
links
to
here's
how
you
can
connect
to
the
test
net.
A
You
use
all
the
documentation,
knock
on
all
the
doors,
try
to
get
people
to
respond
to
acknowledge
that
yes,
I'm,
aware
there's
a
an
upgrade
coming
and
I'm
ready.
This.
This
upgrade
should
be
less
complicated
than
the
last
one.
We
don't
have
any
of
these
going
back
from
with
a
2.1
to
2.0
and
decommissioning
history,
services
and
things
like
that,
but
that
should
be.
E
As
long
as
there's
not
like
a
big
deprecation,
you
know,
I
think
a
lot
of
that
pain.
Can
they
keep
using
the
same
progress
going
forward,
makes
a
big
difference.
Now,
Brian,
you
mentioned
hey,
you
know,
CPU
OC,
something
like
that.
If
that
were
to
result
in
an
exchange,
you
know
not
billing
properly
and
not
having
a
transactions
percolate
its
way
down.
That
is
by
far
the
same,
not
single
words,
but
your
API
operators,
your
BPS,
all
of
us,
you
know
I
mean
we're
pretty
much
in
tune,
but
right.
B
G
I
was
saying,
if,
like
other
BPS,
enable
or
C
and
one
BP
or
exchange,
didn't
it's
not
going
to
stop
propagation
of
the
TX.
It's
just
going
to
be
charge
them
more
when
they're
producing
the
BP
that
doesn't
have
OC
enabled.
So
it
guarantees
that
the
user
have
enough
resources,
regardless
of
what
produced
The,
Block.
G
Small
thing:
sorry
matricail,
just
so
you're
aware,
like
a
lot
of
history-
Solutions,
for
example,
diffuse
angular,
instrumental
node,
EOS
or
with
deepmind.
Usually
these
are
not
accepting
transactions,
they
are
not
accepting
P2P
the
transactions
or
API
transactions.
They're
in
you
know,
read
mode
kind
of
thing,
so
these
ones
are
already
doing
OC.
We
already
have
OCD,
but
all
these
nodes.
So
if
OC
is
now
part
of
the
you
know,
normal
infrastructure,
yeah
and
people
start
abusing
it,
because
you
know
this
is
cheaper.