►
From YouTube: PEEPanEIP #16: EIP-1559 with Tim Beiko
Description
EIP: https://eips.ethereum.org/EIPS/eip-1559
Discussion to: https://ethereum-magicians.org/t/eip-1559-fee-market-change-for-eth-1-0-chain/2783
Slides: https://docs.google.com/presentation/d/1f2JMtKZNMDc9jnG3R-40m-NZp8RhcHkhZbIBimY4-QU/edit#slide=id.g8cb00373fc_0_96
Topics covered:
1:05 - Introduction
1:36 - Overview EIP-1559
4:30 - Transaction & block format
6:36 - “200% Full” blocks
9:26 - Fee burning
11:47 - EIP-1559 Misconception
13:18 - Current status - Client Implementation
16:16 - R&D and Simulation
18:14 - Next Steps - The road to mainnet
20:14 - Questions
20:40 - How has 1559 evolved since the initial proposal? What are the unexpected discoveries?
22:30 - About mining algorithm - Would it be profitable for miners to delay mining in order to get to a profitable transaction with a higher tip?
24:33 - What makes it harder to sort for a miner?
27:04 - Base fee + tip, should those be lower than gas prices at the time of congestion?
28:33 - Since the first-price auctions, users are overbidding, could you describe more how users are overbidding right now?
30:40 - How Tim Roughgarden got insight on Ethereum at the protocol level?
31:32 - Timeline for shipping 1559 v1?
32:52 - Which proposals are coming with Berlin upgrade?
36:36 - How easy/difficult is the 1559 implementation in the Ethereum chain as compared to other projects?
38:38 - Outreach & effect on legacy transaction users?
40:07 - Is there any plan to transition from the old pool to the new pool? How that is going to happen?
40:38 - EIP status - is it the right time to move it to the “In review”?
Follow at Twitter:
Tim Beiko @TimBeiko | Pooja Ranjan @poojaranjan19 | William Schwab @William94029369 | Dragan Rakita @rakitadragan
Check out other exciting EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
Discord: https://discord.gg/sgdnxZe
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders/PM
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Eip1559
is
a
standard
track
code
proposal
in
draft
status
so
generally
in
this
show
we
invite
the
author
of
a
proposal
to
get
an
overview
and
answer
the
questions
that
we
received
from
community.
But
eip1559
is
one
of
a
kind
proposal.
So
for
this
episode
we
have
invited
the
champion
of
the
proposal
tim
baiko,
who
is
heavily
engaged
in
community
interaction
for
this
proposal.
A
B
Sure
so
yeah,
my
name
is
tim
baco,
I'm
a
senior
product
manager
working
at
consensus
there.
My
work
is
on
the
protocol
team,
so
we
built
the
eth1
client
called
hyperledger
basu
and,
as
part
of
that
work,
the
bayesia
team
has
been
leading
the
implementation
of
eip
1559,
and
this
is
what
I'll
talk
about
today,
so
to
give
a
bit
of
background
on
the
eve
itself
and
share
where
we're
at
and
what
the
next
steps
are
for
1559..
B
So,
starting
with
the
overview,
what
is
eip1559
at
a
high
level?
1559
is
an
eip
that
was
put
forward
by
vitalik
in
2019,
and
it
has
two
main
goals.
The
first
is
to
make
the
ethereum
fee
market
a
bit
more
efficient
and
the
second
one
is
to
improve
the
transaction,
sending
ux
it's
at
a
high
level.
What
it
does
is,
first
of
all,
a
hard
code.
The
minimum
fee
transaction
needs
to
pay
to
be
valid
in
the
block
header,
and
this
is
what
we
call
the
base
fee.
B
So
any
block
will
then
will
then
be
able
to
specify
how
much
a
transaction
needs
to
pay
at
a
minimum
to
be
valid.
In
that
block
and
the
way
that
the
base
fee
is
set
is
by
looking
at
how
full
the
blocks
are,
or
more
specifically,
how
full
the
previous
block
was
and
then
in
order
for
this
base,
feed
to
actually
be
tamper
proof
and
to
not
be
to
not
be
changed
upwards
or
downwards
by
miners.
B
We
have
to
burn
that
part
of
the
transaction
fee,
because
otherwise
we
could
have
off
chain
agreements
happening
or
just
minor,
stuffing
blocks
into
transactions,
to
get
the
feedback
and
and
then
raise
the
basic
for
everyone
else.
So
that
means
we
end
up
burning
the
base
and
to
give
a
bit
more
detail
on
you
know
how
we
actually
go
about.
Setting
that
base
fee
is
that
under
1569
we
allow
blocks
to
be
up
to
200
percent
full.
B
B
The
second
is
tim
ruff's,
garden's
economic
analysis
of
the
eep,
so
tim
rofgarden
is
a
is
a
computer
science
and
game
theory,
professor
from
colombia
and
he's
put
together
a
really
extensive
analysis
of
the
eep
so
reading
through
that
will
give
you
context
from
a
more
from
the
fee
markets
perspective
and,
finally,
if
you're
interested
in
more,
I
guess
the
project
management
aspect
of
it
and
how
it's
coming
along.
I've
been
putting
together
updates
that
I've
shared
on
hackmd.
B
So
looking
at
1559
in
more
detail,
we
mentioned
earlier
that
we
are
adding
this
basic
field
to
the
block
header,
so
just
trying
to
go
over
all
the
changes
we'll
be
doing
that
both
the
block,
header
and
transaction
format.
The
the
base
fee
goes
in
the
block
header
and
specifies
the
minimum
fee
transaction
needs
to
pay
to
be
processed
and
then
on
the
transaction
side.
There's
two
new
fields
that
we
will
add.
The
first
is
called
gas
premium,
which
represents
a
tip
to
the
miner.
B
So
in
order
to
circumvent
that
we
add
a
gas
premium
which
goes
directly
to
the
miner
and
then
because
the
base
fee
can
move
from
block
to
block
we
let
the
transaction
specify
the
fee
cap,
which
means
the
maximum
it's
willing
to
pay
for
its
entire
transaction
fee.
So
that
means
that
if
the
basic
goes
up
between
the
block
and
the
next
one,
you
have
a
bit
of
leeway
with
regards
to
how
much
you'll
be
paid.
B
And
then
you
can
set
a
free
cap
pretty
high,
because
whatever
the
difference
is
between
the
fee
cap
and
then
the
base
fee
and
the
gas
premium
gets
refunded
to
you.
So
if
you
set
say
a
fee
cap
of
like
I
don't
know
one
eath
and
then
your
base
fee
is
like
10
and
your
gas
premium
is
one
guy
everything.
That's
not
like
that.
B
So
to
make
this
a
bit
more
concrete
right
now.
The
way
the
base
fee
updates
is
that
if
a
block
is
200,
full
it'll
increase
by
12
and
a
half
percent
in
the
next
block,
so
at
that
rate
it
would
take
roughly
20
blocks
for
gas
prices
to
go
up.
10X
40
blocks
for
them
to
go
up
x
and
60
blocks
to
go
up
a
thousand
x
and
60
blocks
is
roughly
15
minutes
on
the
network
and
to
give
you
an
idea
of
scale
in
like
all
of
ethereum's
history.
B
We've
seen
basically
a
thousand
x
range
in
gas
prices,
so
that
means
that
you
know
in
15
or
at
the
very
least
20
minutes,
we've,
we've
kind
of
provided
an
increase
in
in
fees.
That's
you
know
bigger
than
all
of
ethereum's
history,
so
that
means
we
won't
get
twice,
200
full
blocks
for
for
for
longer
than
that,
and
then
what
happens
is
once
the
base
fee
has
has
risen
high
enough
to
process
all
of
the
the
new
demand.
B
Users
won't
want
to
pay
that
so
that
will
result
in
blocks
not
being
full
anymore,
meaning
that
the
base
view
will
start
dropping
again,
all
the
way
until
blocks
are
100,
full,
again
and
and
and
yeah.
So
that
means
that
if
you
have
like
a
large
spike
in
demand,
so
say
a
new
defy
pool,
icos
or
whatnot
this
piece,
the
fees
will
spike
up
really
quick
and
then
once
those
high
paying
transactions
have
been
processed
they'll
lower
back
to
where
they
they
were
originally.
B
And
one
thing
that's
also
nice
about
these
200
fall
blocks.
Is
that
if
we
have
blocks
that,
are
you
know
100
full
on
average
like
they
are
today?
We
kind
of
have
this
extra
100
of
capacity
that
we
can
use,
and
that
means
that
the
average
transaction
always
gets
included
in
the
next
block
by
paying
the
base
fee
and
maybe
a
small
tip,
which
is
really
nice.
B
And
the
last
big
part
of
1559
is
the
fee
burning.
So
we
touched
on
this
a
bit
in
the
first
slide,
but
in
order
for
1559
to
work,
you
can't
have
the
base
fee
go
to
the
minor
of
the
block
and
there's
two
reasons
for
that.
The
first
is
that
if
we
don't
burn
the
base
fee,
the
miners
can
then
fill
blocks
with
their
own
transactions
and
that'll
push
the
base
fee
up.
B
But
then
they'd
get
the
base
feedback,
so
they
don't
mind
for
their
own
transaction
fees,
and
everybody
else
on
the
network
would
have
to
then
pay
those
high
fees.
So
that
would
not
be
great
and
then
the
second
thing
that
that
could
happen
is
that
users
could
pay
miners
off
chain
or
unchained
with
another
token
than
ether
to
include
their
transactions
with
a
lower
transaction
fee,
whereas
if
they
do
that
after
1559,
the
miner
still
has
to
go
and
buy
ether
to
pay
for
that
transaction
fee
because
it
gets
burned.
B
So
it
kind
of
cements
ether's
role
as
the
only
asset
you
can
use
to
pay
transaction
fees
on
the
network
and
then
obviously,
if
we
just
burnt
all
of
the
minor
revenue,
they
wouldn't
have
an
incentive
to
process
transactions
at
all.
So
this
is
why
we
have
the
gas
premium,
and
it's
worth
noting
that
the
gas
premium
is
not
only
useful
for
miners
to
to
keep
transactions.
B
But
if
we
have
periods
where
there's
a
lot
of
demand-
and
you
absolutely
want
to
be
in
the
next
block
and
blocks-
are
already
200
full,
then
you
can
pay
a
large
premium
to
be
included
quicker
or
if
you
have
a
transaction
that
has
like
a
really
high
value
and
a
very
specific
time
at
which
it
can
be
executed
like,
for
example,
a
defy
arbitrage
trade.
Then
you
can
also
put
a
large
tip
on
that
transaction.
B
B
B
B
So
first,
if
we
look
at
the
client
implementations,
you
know,
most
teams
have
started
their
implementations
of
1559
and
almost
all
of
the
ones
that
have
started
have
implementations
that
are
live
on
a
new
test
net,
which
is
only
being
used
for
1859.,
there's,
obviously
still
a
lot
of
open
issues
on
the
engineering
side,
and
we
have
a
full
list
of
of
things
that
need
to
be
solved
that
I've
linked
in
in
the
dock.
But
here
are
like
a
couple
of
the
big
ones.
B
The
first
is
just
large
state
testing.
So
right
now
we
have
a
test
net,
but
it
has
a
very
small
state,
there's
barely
any
transactions
on
it,
so
that
doesn't
tell
us
a
lot
about
how
1559
would
work
on
an
environment
like
mainnet
and
in
order
to
test
this,
the
basic
team
has
built
a
large
state,
testnet
generator,
which
can
create
a
new
network
with
a
very
large
state
and
a
large
number
of
accounts.
So
we
can
see
how
1559
works
in
conditions
similar
to
mainnet.
B
Right
now,
with
the
current
update
rule,
you
have
you
have.
If
the
base
fee
is
risen,
super
high
and
you've
processed
all
these
high
paying
transactions.
If
you
want
it
to
lower
again
and
process
kind
of
the
transactions
that
are
in
the
transaction
pool,
you
might
need
to
mine
a
couple
empty
blocks
or
mostly
empty
blocks
to
lower
it
quickly
enough
to
get
back
to
that
equilibrium.
B
So
this
is
not
optimal,
but
it's
not
a
it's,
not
a
blocker,
and
then
you
know
I
have
my
last
category,
which
is
everything
else
so
1559
that
shows
almost
every
part
of
ethereum
clients.
So
there's
a
ton
of
things
we
need
to
update.
So,
for
example,
we
need
that
json
rpc,
specs,
tooling
the
testing
infrastructure
and
whatnot.
So
this
is,
you
know,
just
work
that
we're
slowly
working
through
as
we
we
get
kind
of
these
other
pieces,
a
bit
more
finalized.
B
Then
we've
been
doing
a
lot
of
r
d
and
simulations
from
1559
as
well,
so
the
the
gist
of
it
is
to
prove
that
1559
is
actually
better
than
our
current
status
quo
or
that
other
alternatives
and
to
simulate
some
of
these
scenarios
before
we
deploy
it
on
on
public
networks.
So
the
first
thing
I've
mentioned
this
in
the
in
the
very
first
slide
was
a
proper
economic
analysis
of
1559.
B
B
Third,
on
the
simulation
side,
barnaby,
mono
and
and
his
team
from
the
ef
have
been
working
on
several
simulations.
Looking
at
how
different
types
of
user
behaviors
could
could
result
in
different
types
of
outcomes
in
terms
of
transactions
inclusions
under
1559
and
finally,
the
nethermine
team
has
just
started
looking
at
how
would
legacy
and
1559
transactions
work
side
by
side
on
the
network?
How
did
they
get
included
in
blocks
under
different
conditions
and
whatnot?
B
So
in
terms
of
next
steps,
here's
kind
of
my
rough
list-
you
know
it
might
still
change
as
as
we
get
it
done,
but
we're
at
right
now
is.
We
need
to
finish
testing
on
these
large
state
test
nets
to
make
sure
that
1559
works
as
intended,
and
you
know
that
every
kind
of
small
tweak
we
make
to
it
works
in
in
a
in
a
condition
similar
to
mainnet.
B
Then
we
need
to
do
another
kind
of
significant
change
to
the
spec
to
add
eip2718
support,
which
is
an
eep
that
provides
arbitrary
transaction
types
on
ethereum
and
we'll
be
introducing
that
in
berlin.
So
once
it's
done
we'll
want
to
add
it
at
the
1559.,
then
we
need
to
ship
berlin.
So
this
is
the
other
upgrade
that
alcor
devs
is
really
focused
on
right
now.
B
You
know
some
ephemeral
test
nets
in
conjunctions
with
other
apes,
like
we've
seen
for
berlin,
and
once
that's
done,
we'll
push
it
to
the
test
nets.
So
rob's
then
ring
could
be
gordy
and
whatnot
and
assuming
everything
goes
right,
then
it
would
be
deployed
on
mainnet
and
again.
All
of
this
is
assuming
we
don't
have
anything
going
majorly
wrong
along
the
way
and
that's
what
I
had
I'm
happy
to
take
some
questions.
C
D
C
B
So
I
think
the
biggest
takeaway
is
how
little
has
had
to
change,
so
I
think,
there's
kind
of
a
slope
of
understanding
1559
we're
like
it
sounds
like
a
really
good
idea
at
first,
then
you
start
understanding
better
and
there's
like
all
these
weird
quirks
about
it
and
they
sound
like
pretty
bad
ideas.
And
then
you
understand
why
they're,
actually
there
and
and
it's
you
know
it's
actually
kind
of
the
least
worst
design
we
can
get.
B
And-
and
you
know
it's
weird-
that
you
have
to
couple,
for
example-
burning
the
base
fee
with
a
ux
improvement,
but
all
those
things
are
actually
needed
with
one
another.
So
that's
I
think
my
biggest
takeaway
is
is
how
little
kind
of
the
the
general
design
has
had
to
change
and
and
how
I
guess
expensive
or
burdensome.
B
Other
changes
are
to
do
so
like,
for
example,
adding
escalator
fees
adds
a
lot
of
complexity,
but
doesn't
provide
that
much
value
so
yeah,
I
guess
my
biggest
takeaway
is
how
kind
of
sound
the
initial
mechanism
is.
Despite
it's
not
not
necessarily
appearing
that
way
and
in
terms
of
specific
changes
you
know
we.
I
mentioned
the
update
rule
is
something
we'll
look
at
changing,
so
there's
a
bunch
of
like
small
parameters.
We
we
can
update
and
change.
B
C
Interesting
about
the
mining
algorithms
also,
so
I
guess
this
is
probably
more
of
a
general
client
question.
You
mentioned
that
these
days
for
a
miner
to
sift
through
the
pool
they
basically
can
just
look
for
places
where
they
get
the
the
gas
being
paid
by
the
submitted
transaction
is
higher
and
they'll
understand
that's
more
profitable
for
them
to
mine
that
transaction,
but
that
with
1559.
C
You
end
up
with
sort
of
a
different
outlook,
because,
if
they're
going
to
have
to
burn,
actually
I
don't
know
if
I'm
going
to
say
this
right.
I
think
I'm
going
to
say
this
a
little
bit
wrong.
So
just
correct
me
on
the
parts
of
this
that
I
say
wrong,
but
it
may
become
more
profitable
for
them
to
delay
mining.
A
a
a
transaction
with
a
higher
tip.
Is
that
correct.
B
No,
so
it
wouldn't
be
profitable
for
them
to
delay
mining,
but
it'll
be
more
computationally
expensive
to
sort
the
transaction
pool
in
a
way
that
shows
them
the
most
profitable
transactions.
So
what
I
guess
there's
a
few
outcomes
that
that
can
result
from
that.
First,
you
know:
maybe
they
put
sub-optimal
transactions
in
their
blocks,
so
that
means
that,
like
they
could
have
filled
the
block
with
you
know,
a
better,
a
better
set
of
transactions
that
would
have
generated
more
money
and
we're
aiming
to
avoid
that.
B
C
C
B
C
B
No
problem
yeah,
it's
that,
because
you
set
a
fee
cap
and
a
tip
if
the
base
fee
rises
and
it
rises,
it
rises
more
if
the
basically
rises
and
your
feet
cap
is,
is
close
to
the
base
sheet.
It'll
start
healing
into
your
tip.
So,
for
example,
if
your
fee
cap
is
10,
the
base
fee
is
five
and
your
tip
is
four.
You
know
you're
yeah.
That
means
that
you
kind
of
have
a
budget
of
six
gwei
for
your
for
your
your
base
fee
before
it
starts
eating
to
the
tip.
B
B
B
With
heuristics
about
which
transactions
are
likely
are
unlikely
to
change
between
two
blocks,
you
know
and
and
not
sort
those
but
just
sort
the
ones
just
sort
the
subset
that
have
changed.
Then
you
save
a
lot
on
on
the
sorting,
but
that's
like
the
gist
of
it.
It's
just
like
yeah,
because
the
base
fee
moves
that
can
lower
the
effective
tip
and
you
need
to
find
out
which
transactions
have
had
their
chip,
their
tip
changed,
and
how
do
you
resort
them
efficiently
compared
to
all
the
other
transactions
in
your
transaction?
For.
C
C
B
I
think
they'll
they'll
be
slightly
lower
and
by
slightly
you
know,
think
10,
not
10x,
and
the
reason
for
that
is
that,
because,
during
congestion
you
can
you
can
double
the
blocks
block
size,
it
means
it
takes.
You
less
blocks
to
process
all
those
transactions,
and-
and
you
know,
transactions
are
paying
kind
of
like
a
lower
base
fee,
because
it's
just
spread
across
it
a
fewer
number
of
increases
and
then
because
you've
processed
twice
as
many
transactions
that
spike
only
lasts
for
half.
B
You
know
the
amount
of
blocks
and
then
the
the
fees
start
falling
again
so
it'll
like
impact
it
a
little
bit,
but
not
a
ton.
In
his
paper,
tim
roughgarden
has
a
table
that
shows
you
know
kind
of
mathematically.
What
the
difference
would
be.
If
you
had
like
a
spike
in
the
man
under
1559
in
our
current
model
like
yeah,
it's
just
it
makes
it
short
a
small
impact,
but
it
doesn't.
If
you
have
more
demand
than
there
is
supply
on
the
network.
You're
always
going
to
see
a
massive
increase
in
fees.
C
Interesting
and
it
could
be-
I
should
ask
this
before,
but
you
mentioned
during
the
presentation
that
one
of
the
advantages
is
that
being
that
right
now,
the
amount
of
gas
that
users
are
willing
to
pay
for
transactions
involves
a
lot
of
over
bidding
or
maybe
just
in
slightly
more
technical
language.
Since
it's
a
first
price
auction
users
are
over
bidding
often
could
you
could
you
describe
that
a
bit
more
like
how
we
know
that
users
are
over
bidding
right
now.
B
Yeah
and
I
I'll
take
again
I'll
steal
from
tim
rufgarden's
paper
here,
the
way
he
describes
it
is
like
the
difference
between
buying
a
house
and
buying
something
on
amazon
when
you
pay
for
a
transaction
fee
on
ethereum
right
now,
it's
the
similar
experience
of
buying
of
house
right.
You
don't
know
how
much
other
people
are
bidding
for
the
house.
B
You
don't
know
how
much
you're
gonna
pay
for
the
house
until
you
know
whether
your
bid
has
been
accepted
or
not,
and
once
you
paid
for
the
house
at
least
on
ethereum,
you
get
to
see
what
other
people
have
paid
and
whether
you
kind
of
overpaid
or
underpaid.
So
there's
just
like
a
lot
of
uncertainty
in
that
which
leads
people
if
they
really
want
to
be
included
to
like
over
bid
just
like.
B
If
you
wanted
to
buy
a
house,
you
really
like
you
know
you
might
over
bid
relative
to
the
house's
value
and
under
1559,
because
we
have
the
base
fee
in
the
block
header,
it's
more
like
buying
on
amazon,
where
the
block
header
gives
you
a
price.
It
says
you
know
this
is
the
price
to
be
included
in
the
block
and
you
either
take
it
or
you
leave
it
so
that
when
you're
paying,
you
can
quickly
estimate.
B
C
Cool
one
side
question
that
I
have
to
admit
like
really
piqued
my
curiosity,
going
through
the
tim
ruff
garden
report,
I
was
really
struck
by
how
proficiently
he
could
talk
about
ethereum
on
the
protocol
level.
Do
you
have
any
insight
into
how
he
got
that
proficient
in
ethereum,
I'm
assuming
just
because
of
1559.
B
And
I
mean
you
know
he
spent
a
bunch
of
time
for
1559,
specifically
talking
with
the
teams
working
on
it,
the
researchers
and
what
like
not
to
make
sure
he.
He
understood
it
well,
but
he
he
had
some
prior
experience
and
I,
like
I'm
pretty
sure,
ethereum,
but
definitely
bitcoin
at
the
very
least.
If.
A
B
B
What
I'm
aiming
for
is
the
fork
after
berlin
and
again
this
is
not
like
dependent,
not
me
right
like
it
could
not
happen
and
then
historically
you
know,
forks
and
ethereum
have
been
between
like
six
and
12
months.
I'm
hoping
we
can
get
closer
to
six
months
for
this.
So
if
burden
goes
out,
you
know
in
like
january
or
february,
then
I
suspect,
like
my
hope,
would
be
somewhere
in
the
summer
to
see
1559,
but
this
is
assuming
everything
goes
right,
assuming
there's
no
major
delays
and
whatnot.
C
B
C
B
B
B
So
we
have
this
under
2718
which
allows
us
to
have
arbitrary
transaction
formats
and
so
and
so
because
we
we
had
2930,
which
changes
the
transaction
format
going
into
berlin.
We
decided
to
also
have
2718
right
now
to
only
support
the
20
29
30
type
transactions,
but
in
the
future
it'll
support,
different
types
of
transactions
as
well,
yeah
and
2718
is
also
going.
C
B
Ssz
encoding
is
yeah,
it's
what
it
too
uses
and
it's
like
I'm
not
extremely
familiar
with
the
detail
of
it,
but
it's
like
a
more
efficient
encoding
scheme
than
rlp,
but
it's
a
ton
of
work
to
change,
because
basically,
everything
in
the
clients
is
encoded,
so
we're
not
doing
that
for
berlin
and
it's
also
a
pretty
significant
change.
So
if
you
change
how,
like
all
the
data,
is
kind
of
encoded
in
the
clients,
there's
a
lot
of
opportunities
for
bugs.
C
B
For
ssd
at
the
networking
layer,
and
the
reason
for
that
is
that
the
networking
clients
support
multiple
protocols,
so
they
can
support.
They
could
support
both
the
rlp
and
the
ssd
version,
and
so,
if
there's
a
bug
in
ssd,
it's
not
the
end
of
the
world,
you
can
just
you
know,
keep
using
rlp,
whereas
at
the
consensus
level
we
don't
have
that
freedom
like
once
we
make
a
consensus
change.
Everybody
has
to
do
it
exactly
at
the
same
time
and
there
can't
be
bugs.
C
B
D
D
A
B
B
The
other
big
challenge
with
1559
ethereum
is
the
network
is
already
live
and
changing
into
that.
So
a
lot,
if
not
all,
of
these
networks
that
have
implemented
1559
they've
implemented
it
since
the
start
of
the
network.
So
it's
not
like
they
have
a
transition
to
think
about
and
and
making
sure
that
things
don't
break
because
it's
it's
always
been
that
way
and
that's
another
thing:
that's
like
a
big
kind
of
area
of
concern
in
1559.
Now
we
want
to
get
right
and
I
think
kind
of
related
to
that.
B
A
B
So
anyone
will
be
able
to
send
a
transaction
with
a
legacy
wallet
or
if
or
you
know,
even
if
you
had
already
signed
a
transaction,
you
know
before
1559
you
want
to
send
it
after
that'll
be
fine.
The
only
downside
is,
it
might
just
cost
you
more
gas,
so
it
won't
be
as
gas
efficient
as
1559
style
transactions
and
there's
ways.
B
I
guess
if
you
wanted
your
legacy
transactions
to
be
as
gas
efficient,
there's
ways
you
could
do
it,
but
they're
very
kind
of
complicated,
and
at
that
point
it's
probably
just
easier
to
use
a
1559
transaction,
but
there's
no
there's
no
transaction
that
was
previously
valid.
That
would
become
invalid
after
1559.
D
B
So
right
now,
there's
only
one
transaction
pool,
1559
and
legacy
transactions
will
be
in
the
same
transaction
pool,
so
we
don't
need
to
keep
them
separated.
What
we
do
is
at
the
client
level.
We
interpret
the
15
the
legacy
transactions
as
though
they
were
1559
style
transactions
with
specific
conditions
like
at
the
bottom
of
the
slide
here.
So
I
don't
see
so
you
know
we
could
decide
to
remove
support
for
legacy
transactions
but
like
that
would
be,
I
guess,
another
hard
fork
and
another
eep.
B
I
don't
see
why
we
would
do
that
at
the
very
least
until
the
merge
of
eth1
to
e2,
because
all
of
the
eth1
clients
already
support
legacy
transactions.
I
think
that
you
know
if
you
made
an
argument
like
once
each
one
merges
into
e2.
Maybe
you
don't
want
to
support
legacy
transactions
in
just
1559
because
it
makes
developing
new
clients
easier
like
I
can
see
that,
but
I
I
personally
would
not
advocate
for
it
before
that,
especially
given
that
all
the
code
for
legacy
transactions
is
already
in
the.
A
So
one
last
question
that
is
coming
from
the
theme
of
the
show
about
the
eip.
The
present
status
of
the
eip
shows
that
it
is
in
the
draft
status
I
mean,
like
my
understanding,
is
now
that
we
are
doing
a
lot
of
stuff.
We
are
also
on
the
you
know,
test
nets.
So
is
it
the
right
time
to
move
the
status
to
interview,
if
not
to
the
last
call.
B
I
think
it
would
probably
make
sense
to
move
it
in
review.
The
reason
it
hasn't
been
done
is
just
because
we've
been
so
busy
with
other
stuff,
it's
more
oversight
but
yeah.
We
can
definitely
follow
up
on
there
and
move
it
in
review.
I
don't
think
it.
It
makes
sense
to
move
at
the
last
call
yet,
like
I
think,
once
it
goes
through
the
all-core
devs
process,
we
probably
want
to
move
it.
A
Great,
so
that's
all
from
question
point
of
view.
I
hope
that
today's
episode
will
be
really
helpful
for
our
community,
who
are
new
to
the
proposal
and
wanted
to
have
a
quick
summary.
We
also
touched
on
some
of
the
good
and
a
little
technical
questions
that
that
are
useful
for
on-chain
projects
and
wallet
and
other
infrastructure
provider.
A
A
This
proposal
can
also
be
followed
on
ethereum
rnd
discord
server
so
for
people
watching
us
on
youtube.
If
you
like,
this
episode,
don't
forget
to
hit
like
share
and
subscribe
ethereum
cat
hoodies
channels,
you
may
find
twitter
handle
for
today's
guest
and
the
presentation
link
in
the
description
section
below.
A
If
you
have
question
comment
or
concern
about
this
or
any
other
proposal
feel
free
to
leave
a
comment,
and
if
you
have
suggestions
on
which
proposal
we
would
like
to
include
in
the
show
next,
let
us
know
you
can
join
the
discord
of
ethereum
cat
herders.
The
invite
link
will
be
provided
below,
see
you
next
time
with
another
proposal
till
then
keep
sharing
your
love
with
ethereum
cat
header.
This
is
host
pujaranjan
signing
off
cheers.