►
Description
Topics covered
-----------------------------
1:58 - Guest’s introduction
3:18 - Presentation
3:38 - What are signatures?
4:20 - Signature : An anatomy
5:55 - Canonical Signatures
07:00 - Canonical Signatures: Consequences
7:30 - Putting it all together
8:50 - Size comparison: Solidity
10:22 -Size Comparison: Transactions
11:28 - Backward Compatibility
12:20 - Questions
13:30 - Support for canonical signature
14:56 - If 2098 gets a lot of traction, many DeFi wouldn’t work for 2612, what do you have to say about that?
19:38 - Ethers tooling - how does it work under the hood?
22:58 - Biggest advantage of the proposal in Ethers?
26:04 - Are you aware of other implementations?
27:38 - How does Firefly work?
29:40 - Any plan of ENS integration?
31:18 - Type of the proposal - Why Informational not Standard Track ERC?
34:36 - Are there other EIPs that you are looking to see in Final status?
40:28 - Thoughts on the present EIP process? Any suggestions & recommendations?
Resources:
-----------------
- EIP - https://eips.ethereum.org/EIPS/eip-2098
- Discussion-to - https://github.com/ethereum/EIPs/issues/2440
Follow at Twitter
-----------------------------------------------
Richard Moore @ricmoo | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
ERCs playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqXee9EMQDIEz2CslTnsW0K
PEEPanEIP playlist - https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.io/EthCatHerders
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herders
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
To
talk
about
the
proposal
we
are
joined
by
one
of
the
co-authors
of
the
proposal,
richard
moon,
richard
goes
by
rick
moo
on
some
of
the
social
media
platform.
He
is
the
lead
developer
of
ethers
and
firefly.
The
dollar
five
diy
ethereum
hardware
wallet
welcome
to
the
show
rated
google
thanks.
This
could
be
on
yeah.
I
was
super
fascinated
with
the
diy
hardware
wallet
just
a
little
backstory
here
personally,
my
team
was
working
on
development,
hd
wallet
at
the
time.
B
C
A
Eip2098
is
a
compact
signature
representation.
This
is
an
informational
erp
documented
in
march
2019
and
currently
is
in
the
last
call
with
13th
february.
As
the
deadline,
we
will
learn
more
about
the
proposal
with
richard
in
a
while,
but
before
we
get
there,
may
I
request
richard
to
share
a
bit
of
his
background
and
his
journey
with
the
ethereum
and
ethers.
B
I'm
sure
I'm
not
sure
how
much
depth
I
should
go
into,
but,
like
basically
2013,
I
think,
is
around
there.
Maybe
even
earlier
I
was
at
some
hackathon
and
my
friends
were
just
like.
Oh
there's,
this
bitcoin
thing
that
just
popped
up
in
toronto.
Do
you
wanna
go
see
it
so
we
went
out
and
looked
at
it.
We
went
bitcoin
atm,
of
course,
the
building
we
wanted
to
see
it
in.
It
was
all
locked
up
because
it
was
a
weekend,
and
so
we
didn't
see
much
more.
B
But
there's
like
a
piece
of
paper
in
the
window
saying:
oh,
we
have
weekly
meetups,
and
so
I
started
one
of
those
weekly
meetups,
which
is
where
I
met
vitalik
and
like
a
bunch
of
other
random,
like-minded
crypto
people
and
it
just
kind
of
took
off
from
there
like
it
was
just
an
exciting
world
to
be
part
of.
So
that's
what
really
got
me
into
it's
not
like
a
there's,
not
a
lot
going
on
it's
just.
It
did
not
take
much
convincing.
It
just
seemed
awesome.
A
B
Absolutely
so,
as
a
quick
warning,
this
is
a
fairly
short
presentation,
but
this
is
what
I've
got
to
show
off.
If
anybody
wants
to
pay
attention
to
it.
So
should
I
just
dive
in
then
sure,
let's
peep
in
okay,
okay
peep
in
peeping,
I
like
it
so
basically
compact
signature
representation
I'll
go
through
pages
I'll
go
through
this,
my
slides,
I
often
over
talk
my
slides,
not
realizing.
B
I've
already
mentioned
something
that's
coming
up
later
on
that
sort
of
thing,
so
I'll
just
start
going
through
and
we'll
see
what
happens
so
first
of
all
water
signatures.
So
signatures
is
part
of
the
proving
system
which
is
are
used
extensively
through
so
like
every
transaction
you
send
is
signed
by
a
by
a
private
key
which
gives
you
a
signature,
I'm
also
not
exactly
sure
the
target
audience
level.
So,
if
I'm
speaking
too
low,
please
tell
me
to
speed
up
through
the
list
or
too
fast
slow
down
that
sort
of
thing.
B
Some
also
a
lot
of
smart
contracts
use
signatures
because
it
allows
you
to
prove
that,
like
the
the
private
key
of
an
account
signed
some
piece
of
information,
which
is
probably
an
agreement
that
the
contract
that
the
contract
itself
understands
on
how
to
perform
that
action
or
some
action
so
signatures
to
give
you
an
idea
of
what
they
actually
include.
It
includes
an
r
and
s
and
a
v,
so
the
r
is
actually
the
x
coordinate
of
some
reference
point.
These
are
effectively
created
at
random.
B
So
there's
there's
no
interesting
aspect
to
this.
Really,
the
s
is
the
important
part
that
you
take
an
r
and
you
do
a
bunch
of
maths
to
it,
and
this
s
is
something
that
only
the
original,
only
the
owner
of
a
private
key
could
actually
have
generated.
So
these
two
values
together
are
kind
of
what
allow
you
to
prove
that
a
piece
of
information
was
signed
by
specific
private
key
now,
one
of
the
cool
things
we
do
in
ethereum
is:
we
don't
actually
include
the
from
address
in
the
transaction.
B
B
One
caveat
of
this
is
you
don't
need
just
the
x
value
of
the
r
you
need
both
the
x
and
the
y
value
of
the
r
and
so
for
any
given
x
value
is
very
complicated,
but
I'll
try
to
skim
over
it
for
any
given
x
value,
there's
actually
two
possible
y
values.
So
in
order
to
get
the
entire
r
back
from
just
the
x,
you
need
to
know
whether
you
took
kind
of
like
the
top
y
value
or
the
bottom
y
value,
and
so
that's
what
the
v
is.
B
B
We
basically
just
forced
it
has
to
be
one
specific
one
of
the
two,
so
this
was
originally
introduced
in
bitcoin
because
they
were
having
a
big
problem
transaction
malleability,
which
is
that
someone
could
take
your
transaction.
Your
thing
you
signed
and
compute
a
second
thing
that
was
also
signed
by
you,
but
looked
different,
and
this
affects
how
their
utxo
based
system
works.
That
sort
of
thing
it
was
not
nearly
as
important
for
ethereum
to
solve
this
problem,
but
it's
really
a
nice
to
have
going
forward.
B
It
just
made
a
lot
of
possible
things,
not
a
problem.
The
nice
thing
is
this
had
a
huge,
profound
impact
on
what
we
can
do
with
this.
With
this
eip
as
because
we
are
taking
the
canonical
signature,
it
locks
one
of
the
bits
to
always
being
zero,
so
I
think
that's
mentioned
in
the
next
slide.
Yes,
so
this
is
the
consequence
of
having
canonical
signatures.
B
So
you
basically
have
this
compact
version
of
the
s
and
if
the
v,
if
you're,
trying
to
indicate
the
v,
should
be
zero
or
27
as
a
quick
background
on
27
versus
28,
this
was
chosen
again
for
like
legacy
bitcoin
purposes.
Basically,
things
like
zero
and
one
were
already
in
use
like
there's,
there's
very
specific
bytes
that
you
use
to
indicate
this
is
a
private
key.
This
is
an
address.
This
is
a
compressed
address.
B
This
is
the
upper
part
of
a
compressed
address,
so
there's
all
these
like
existing
values
that
were
really
important
so,
rather
than
using
zero
and
one
they
use.
27
and
28,
but
the
fact
is,
we
can
just
change
that
27
or
28
into
a
zero
or
one,
and
so
now
we
have
this
possibility
where
that
one
bit
that
we
have
left
over
at
the
top,
that
would
otherwise
just
be
kind
of
like
zero.
All
the
time
we
can
kind
of
cram
that
extra
bit
of
v
into
that.
B
B
So
if
you
pass
in
a
signature
today,
like
normal
signatures
as
you're
used
to
so
they're
65
bytes
long,
but
if
you
call
this
solidity
as
a
bytes
object,
that's
160
bytes
of
call
data
that
you're
passing
along
for
for
the
signature.
If
you
use
separate
parameters
because
of
the
way
like
alignment
works
in
solidity,
which
is
everything
is
aligned
to
32
bytes
well,
that
v
is
actually
a
32
byte
value,
and
so
just
passing
in
the
signature
is
96
bytes
of
call
data.
B
So
if
you
use
a
compact
representation,
you
can
fit
it
in
the
r
and
the
compact
s
so
you're
at
your
minimal
64
bytes
of
data.
So
just
some
quick
numbers
because
numbers
seem
to
be
people
things.
People
like
over
the
bytes
saves
60
of
the
amount
of
call
data
being
passed
in
and
33
for
the
the
separated
parameters
and
keep
in
mind
that
each
byte
you
pass
as
call
data,
actually
has
a
cost
to
the
transaction.
Like
you
pay
extra
for
each
byte,
you
pass
into
for
your
call
data.
B
So
this
is
just
gas
saved.
The
one
byte
of
of
call
data
would
simply
the
gas
for
that
would
cover
the
entire
gas
required
for
the
extra
extra
small
amounts
of
math.
You
have
to
do
internally
to
convert
them,
and
so
that's
solidity
and
the
other
thing
to
keep
in
mind
is
now.
We
have
typed
transactions,
which
means
we
actually
have
envelopes
all
envelopes
currently
encode
in
r
s
and
v.
This
actually
means
that
every
transaction
type
has
an
extra
byte
being
stored,
that
every
node
must
remember
for
the
rest
of
eternity.
B
We're
not
talking
about
archive
notes.
We're
talking
about
regular
full
nodes,
have
to
remember
this
value
for
the
rest
of
eternity.
So
if
we,
for
example
in
if
we
have
a
type
3,
whatever
happens
after
eip
1559,
we
could
remove
that
and
now
every
transaction
is
just
one
byte
smaller,
which
is
not
a
huge
savings,
because
transactions
are
like
400
to
500
bytes
each,
but
just
as
a
quick
example,
I
was
just
doing
this
last
night.
B
I
popped
my
head,
and
I
was
thinking
about
it
right
now-
we're
sitting
at
14
transactions
per
second.
So,
let's
put
1.2
megs
per
day
that
we
simply
can
throw
to
the
wind
and
we
literally
lose
nothing
like
there's
no
cost
to
this.
This
is
data
that
we're
just
storing
eight
bits
around
in
a
database
somewhere
for
the
purposes
of
just
remembering
that
one
bit
of
data,
one
other
quick
note-
is
fully
backwards.
Compatible
existing
signatures
are
65
bytes
long.
B
These
are
64
bytes
long,
so
you
can
programmatically
detect,
which
one
is
being
used
and
kind
of
flip
over
to
one
or
the
other.
Somebody
was
pointing
out
on
twitter
that
open
zeppelin
already
supports
the
cip
2098
standard,
and
so
they
are
back
to
using
the
bytes
size,
which
would
be
not
the
160
bytes.
If
you
pass
this
in
it'd,
be
the
160
minus
32,
so
like
128.
That
makes
sense.
B
So,
even
if
you
use
this
with
legacy
bytes
systems,
it's
still
knocking
off
an
entire
word
or
32
bytes
from
from
call
the
data,
but
it
means
that
the
contract
can
detect.
Oh,
this
is
a
compact
representation.
Therefore,
blorp
do
this
other
thing
and
I
think
I've
spoken
very
fast
and
got
to
my
slides,
and
so
I
will
turn
it
over
to
questions
and
that
sort
of
thing.
B
You
could
imagine
this
silly
could
offer
a
actual
built-in
function
that
takes
in
a
signature
or
because
it's
a
different
type
of
parameters.
You
could
even
imagine
the
the
signature
for
the
function
is
different
and
therefore
there's
not
even
a
need
to
specify
compact
or
otherwise
the
the
the
function
itself.
Could
I've
got
two
parameters
versus
three
parameters:
that
sort
of
thing.
B
Right
and,
and
so
as
a
quick
aside,
the
original
eip,
I
did
have
like
a
block
of
code
that
kind
of
implemented.
It
show
how
the
solidity
would
look.
The
solidity
is
like
an
extra
three
lines
of
code
and
I
think
the
gas
requirements
was
were
like
an
extra
between
probably
16
to
20
gas
and
I
think
you're
saving
68
gas
per
byte
of
call
data
so
saving
you
know
an
entire
word
of
call
data
or
in
the
worst
case
like
and
not
96.
B
D
D
So
what
2612
does
is
it
allows
you
to
sign
a
message
and
pass
that
signed
message
to
someone
and
then
they're
able
to
basically
get
an
approval
over
your
c-20s
using
the
signed
message,
so
the
specification
inside
2612
specifically
breaks
down
into
vr
and
s.
I
believe
some
maker
dow
code
does
too,
but
I
wouldn't
know
exactly
where
off
the
top
of
my
head,
and
I
I
think
that
that's
at
least
it
could
be
I'm
getting
the
entire
history
wrong.
D
But
it's
looked
to
me
kind
of
like
the
history
of
splitting
signatures
into
vr
and
s
on
chain
to
get
the
bytes
32
bytes
32,
bytes,
eight,
so
that
you
know
exactly
what
types
are
coming
in
you're,
not
stuck
with
an
entire
unbounded,
dynamic,
bytes
array
and
all
of
that,
if
2098
would
start
getting
tractions.
That
would
mean
that
it
wouldn't
work
with
2612
out
of
the
box
and
a
lot
of
d5,
for
instance,
able
to
ask
with
the
2098s
absolutely
and
so
oh
sorry
go
ahead.
B
Okay
yeah,
so
basically,
I
do
see,
for
example,
like
there's
a
lot
of
existing
things
that
already
use
a
vrs.
You
could
imagine
there
could
be
an
event
where
there's
like
a
permit
that
takes
in
a
a
r,
a
sorry,
a
r
and
a
compact
s
or
or
some
equivalent
of
that
sort
of
thing.
It's
true,
there's
lots
of
things
that
exist
that
use
the
vrs
already
you
could.
B
B
So
the
cool
thing
about
how
solidity
also
works
is,
if
you
have,
you
could,
for
example,
have
a
struct
called
a
signature
which
could
have
two
byte
32s,
and
that
also
greatly
simplifies
what
the
signatures
would
look
like,
and
I
almost
kind
of
want
to
see
that
kind
of
be
the
the
path
forward.
Rather
than
seeing
this
bytes
32
our
bytes
32
s,
u8
int
v.
I'd
rather
see
a
tuple,
toefl,
bytes32,
bytes32
and
then
sig.
That
just
means
it
requires
no
additional
bytes.
B
The
solidity
compiler
will
generate
probably
the
exact
same
code
and,
for
example,
if
you
are
using
ethers
by
the
way
I
probably
should
have
mentioned
earlier,
I'm
the
author
of
ethers
js.
If
you
use
ethers,
there's
already
2098
support
in
when
you
generate
a
signature,
it
generates
an
underscore
vs.
That
was
the
like
the
underscore,
because
it's
experimental,
the
vs
was
the
original
name.
B
I
need
to
update
it
for
the
eip
and
version
six
it'll
just
be
like
a
native
thing
that
you
can
pass
into
any
any
eip,
2098
enabled
signature,
and
it
will
automatically
just
kind
of
compress
it
down
to
the
right
size
for
you
and
pass
that
in.
It
is
definitely
an
issue
that
there
exists
a
ton
of
things
out
there
that
are
already
expecting
a
vrs.
B
I
mean
I
have
a
ton
of
things
out
there
that
use
vrs,
and
this
is
kind
of
one
of
the
motivating
reasons,
because
there
are
so
many
things
and
I'm
not
saying
this
is
a
change
that
either
needs
to
be
made
overnight
or
so
you're,
not
even
changing
mate
exclusively.
You
could
imagine
having
a
second
permit,
which
takes
in
a
compact
representation
and
simply
just
calls
the
other
version
after
extra
extracting
the
various
components
that
needed
and
you
can
and
again
in
the
future.
B
B
I
tried,
I
guess
gone
into
more
details
with
canonical
signatures.
Canonical
signatures
just
means
that
the
s
value
is
between
the
values
of
zero
and
the
order
of
the
selectp256k1
curve
divided
by
two.
Yes,
so
I
mean
it's
just
kind
of
like
this
is
more.
This
is
more
encoding
than
it
is
about
changing
the
signature
type
or
the
signature
represent.
Like
the
the
signature,
format
is
still
the
same,
it's
just
the
the
encoding
is
different.
So
yes,
I'll
leave
without
that.
D
Actually,
maybe
if
I
could,
we
were
saying
about
the
ethers
tooling,
so
it's
if
I'm
understanding
right,
you
mean
that
when
you
use
ethers
to
generate
a
signature,
so
it'll
generate
in
2098
format
automatically,
and
then
let's
say
I
would
be
passing
that
into
something
like.
I
do
know
that
you
can
deconstruct
that
into
vrnss.
D
B
B
And
it
also
produces
a
underscore
vs,
which
is
the
compressed
the
compact
s
so
and
in
in
v.
Ether's
v6
it'll
do
the
same
thing,
but
it'll
do
it
on
the
fly
so
by
default,
or
the
way
that
v6
works
is
vr
and
s
are
internally
stored,
but
it's
just
an
object
with
getters.
So
if
you
ask
for
the
compact
s,
for
example,
it
at
that
time
will
compute
it
for
you
and
give
it
back
to
you.
C
B
So
if
you
had
a,
for
example,
a
function
call
that
had
that
took
a
struct
that
required
a
r
and
a
compact
s,
and
you
passed
in
one
of
these
objects.
It
would
just
know
to
use
those
two
portions
of
of
the
signature.
Thank
you.
Yes,
exactly
and,
for
example,
it
works
the
other
way
too.
If
you
had
a
if
you
had
a
structure
that
had
a
bytes
32r
of
bytes
32s
and
a
you
and
8v.
D
D
I
was
actually
about
to
say
something
very
similar
to
you.
I
think,
which
is
that
sometimes
in
a
situation
like
this,
where,
like
we
already
have
kind
of
one
paradigm,
that's
there
and
instituting
kind
of
like
standards,
for
there
is
a
way
to
accommodate
everybody
like
it.
It
definitely
seems
like
a
very,
very
reasonable
approach.
D
B
D
A
A
My
first
question
is
related
to
the
implementation.
The
proposal
suggests
that
ether's
js
library
supports
this
inversion
file.
So
in
simple
terms,
if
you
have
to
talk
about
like
what
this
actually
provide
to
a
wallet
or
a
d5
project
developer,
when
they
are
trying
to
use
either's
library,
especially
when
rlp
encoded
transaction,
would
there
be
an
elegant
script
or
would
it
be
building
an
economical
tab?
What
would
be
the
major
advantage
of
using
this
proposal?
A
B
Mean
the
biggest
advantage
right
now
I
mean
what
I
mean
when
I
came
up
this
idea.
It
was
not
nearly
as
important,
but
I
think
we
all
kind
of
understand
the
value
of
saving
a
little
bit
of
gas
now,
and
so,
if
you
can
save
like
an
extra
couple
hundred
gas
on
a
lot
of
things,
that's
kind
of,
I
think
the
biggest
advantage
in
terms
of
what
what
I
think
a
lot
of
d5
developers
would
really
care
about
or
defy
developer
managers.
B
B
It
just
becomes
very
complicated,
so
I
think,
from
a
developer
point
of
view,
it's
much
simpler
but
as
william
was
pointing
it
out,
there's
definitely
going
to
be
a
legacy
issue.
If
you
are
a
new
age,
d5
person
and
you're
using
some
like
you
know,
older
contract,
there
is
going
to
be
a
little
bit
of
a
hurdle
for
you
in
the
sense
that
not
really
a
hurdle,
but
a
you
can't
use
this,
because
you
have
to
speak
the
way
that
the
old,
the
old
stuff
used
to
work
so
kind
of
a
mixed
blessing.
B
I
also
feel
like
if
this
got
traction
and
took
off.
It
would
be
really
interesting
to
come
back
in
two
years
time
when
all
new
standards
are
using
compact
representation
and
for
a
new
d5
developer
to
come
in
and
take
a
look
at
trying
to
interact
with
an
older
contract.
I
mean
what
the
hell
am
I
doing
here.
Why
am
I
passing
in
all
these
like
crazy
things?
I
just
want
to
pass
in
a
signature.
I
don't
want
to
pass
in,
like
sig,
dot,
v,
dot,
r
sig
dot
s
to
see
what
happens.
A
Absolutely
yeah,
I
mean
I'm
also
excited
to
see
this
proposal
being
adopted
and
based
on
adoption.
My
next
question
is
about
the
implementation
d.
We
did
talk
about
open
zaplin
and
we
are
aware
that
it
is
js
have
implemented
this
proposal.
Are
you
by
any
chance
aware
of
any
other
project?
Those
are
either
in
active
implementation
or
proposing
to
be.
You
can
also
suggest
adapts
that
can
be
like
benefiting
from
them.
B
Right
so
I
mean
in
terms
of
implementation:
I've
in
the
original
eip
there
was
included
a
implementation
of
solidity.
Again,
it's
like,
I
think,
three
to
four
lines
of
code,
so
you
can
see
how
the
solidity
differs,
but
there
was
some.
I
guess
that
doesn't
belong
in
an
eip,
so
I
should
probably
create
excuse
me
an
example
somewhere
else
that
demonstrates
how
to
use
it.
I
think
I've
actually
used
it
in
some
of
my
hackathon
projects.
Just
because
again
it
was
simpler
to
like
knock
out.
B
I'd
have
to
look,
but
if
I
is
out
there
you
can
take
a
look
like
takoyaki
or
actually
now,
I
think
about
it.
I
think
even
firefly
might
have
internally
used
this
just
to
squish
things
down
to
a
qr
code
by
the
time
it
wasn't
really
an
idea
idea.
It
was
just
kind
of
me
cheating
hardware
to
make
things
work,
but
in
terms
of
real
world
things
that
they're
using
it,
I
don't
believe
there's
anything.
That's
at
least
nothing,
nothing
huge
that
I
know
about.
A
No
worries:
we
hope
that
when
this
proposal
gets
finalized,
people
give
the
proper
attention
this
proposal
requires,
and
it
will
be
helpful
for
other
new
job
developers
to
kind
of
integrate
this
in
their
upcoming
projects.
So
it's
good,
like
I
remember
when
firefly
was
around,
you
had
some
concerns
with
qr
codes.
So
if
that
was
implemented,
like
basic
idea,
also
they're
quite
interesting
to
follow.
B
I
was
gonna
say
like
basically
the
way
the
firefly
worked
for.
Those
who
don't
know
is.
It
was
a
completely
air-gapped
hardware
wallet,
and
so
it
had
a
radio
that
could
listen,
but
it
had
no
way
to
broadcast
data
back.
This
was
a
huge
cost
savings
device
back
then
it
didn't
actually
support
bluetooth,
but
it
could
kind
of
fake
understanding,
bluetooth,
packets,
but
the
way
it
got.
B
Information
back
into
your
computer
was
by
displaying
a
qr
code
on
the
on
it
on
its
display
that
you
could
then
scan,
and
then
your
scanning
software
would
recombine
that
qr
code
into
something
more
meaningful.
The
actual
signature
and
the
problem
was
this
screen
was
only
the
screen's
capacity
to
show
a
qr
code
could
only
show
two
side-by-side
qr
codes
capable
of
storing
32
bytes
each,
and
so
there
wasn't
room
to
store
the
extra
eight
bits
of
a
v.
B
I
can't
we
might
have
done
one
of
two
things
we
might
have
crammed
the
v
in
there
or
we
might
have
just
had
the
software
compute,
both
v0
and
v1,
and
see
which
one
matches
the
address.
Those
are
both.
Those
are
both
different
solutions
and
the
ladder
solution
is
actually
how
a
lot
of
software
the
bitcoin
space
recommended
you
do.
Some
of
these
sorts
of
things
which,
for
your
own
personal
use,
is
fine,
but
one
of
the
biggest
hits
especially
early
on
the
blockchain
was
signature.
B
Verification
was
the
the
thing
that
really
chugged
the
like
really
brought
the
speed
of
syncing
the
blockchain
down,
because-
and
nowadays
it's
probably
not
a
big
deal,
I
mean
we
can
set
p256k
one
ec
recover
like
out
of
the
wazoo.
We
don't
care
so
anyways,
that's
just
some
like
random
little
tidbits
of
background
information,
so
it
might
have
been
used.
I
can't
remember
whether
we
used
that
or
just
the
kind
of
like
just
try
everything
and
see
what
happens.
A
B
I
mean
not
really
there's
not
really
much
that
ens
can
do
with
it
any
more
than
anything
else.
I
mean
it's
just
kind
of
like
a
different
presentation,
like
anything
that
you
could
imagine.
Even
a
lot
of
like
l2
solutions
could
start
using
this
when
they're
providing
signatures
for
one
thing
or
the
other,
and
so,
if
there's
any
l2
stuff
upcoming
in
ens,
it
could
probably
use
this,
but
I
haven't
really
thought
much
about
anything
enos
specific
that
could
use
this.
B
Exactly
like,
like
I
feel
like
this
is
the
format
that
we
should
probably
be
using.
I
understand
there's
a
lot
of
legacy
things,
and
so
that's
kind
of
it's
up
to
the
kind
of
community
to
decide
is
like
following
legacy
more
important
or
is
kind
of
like
using
a
a
newer
but
un
like
a
newer
but
not
widely
adopted
standard.
A
My
next
question
is
about
the
type
or
yeah
the
type
I
mean
when
I
was
reading
the
proposal
it
it
felt
to
me
it
can
be
something
else,
because
we
do
not
have
a
lot
of
information
proposal.
This
is
as
an
information
proposal,
so
it
was
like
more
of
a
curiosity
thing,
but
my
question
to
you
would
be:
why
did
you
choose
it
to
be
an
informational
and
not
an
erc.
B
B
B
So
there
you
go,
oh
perfect,
perfect,
so
there
you
go.
You
have
an
idea
of
like
that's
how
long
ago
it
was
I
mean
I
probably
read
eip
one
over
and
stared
at
his
track
and
like
that
big
block,
because
in
my
mind,
at
the
time,
I'm
guessing.
I
can't
really
fully
appreciate
where
my
mindset
was
in
2019,
but
my
guess
is.
I
saw
erc
and
probably
thought.
Oh,
this
is
like
erc20
erc721.
These
are
probably
in
my
mind,
erc
was
for
tokens,
and
so
I
saw
the
word
informational
I'm
like
well.
A
I
think
that's
going
to
be
helpful
for
even
developers,
because
in
my
experience,
informational
eips
are
generally
neglected.
They
are
not
seen
because
they
are
kind
of
recommendation
people
may
or
may
not
use,
but
if
something
comes
up
as
an
erc
category
or
maybe
if
that
is
of
the
more
of
protocol
side,
none
in
the
core
category,
then
people
pay
much
attention
towards
those
proposals
so
yeah.
That
can
be
an
added
advantage
to
this
proposal.
I'm
happy
that
you
are
planning
to
move
it
to
erc
category
absolutely.
B
It's
just
something
I
wasn't
really
even
this
is
the
unknown.
I
didn't
even
know
that
that
was
a
thing
I
didn't
know,
and
I
guess
I
didn't
even
know
this
thing
you're
discussing
like
how
informational
are
obviously
overlooked.
In
my
mind,
it
was
just
like
this
is
just
an
idea.
It's
not
like
I,
I
guess
yeah
anyways,
that's
my
so
I
completely
agree
with
you.
You
are
100
correct.
It
should
absolutely
be
erc
and
I'll
be
making
that
change.
A
All
right,
that's
good
to
know,
I
mean
I
understand
we
were
discussing
this
in
our
conversation
today
with
one
of
the
eibb
editors
that
sometimes
it's
not
clear
to
author.
What
what
they
can
do
is
go
ahead
with
whatever
they
find
best
at
the
time.
But
when
we
reach
that
proposal
on
like
further
statuses,
we
might
want
to
look
into
deeper
and
help
author
decide
the
category
so
glad
to
know.
We
are
on
the
same
page
on
that.
C
A
B
B
I'm
not
gonna,
go
a
lot
into
detail
in
them
right
here,
but
the
basic
idea
is,
rather
than
signing
opaque
hashes.
I
kind
of
want
the
ability
to
sign
a
string.
I
want
to
be
able
to
see
a
string
that
says
you
are
about
to
send
eight
what
wrapped
eve
to
the
sum
address
and
then,
when
I
sign
it,
it
signs
the
data
associated
with
that
again.
This
is
like
another
eip
or
people
I'll
bug
you
about.
At
some
point
I
have
one
and
one
of
the
eips.
B
So
those
are
like
the
two
that
are
due
to
my
heart,
but
there's
obviously
like
I'm,
adding
25
44
to
ethers
right
now
for
those
unfamiliar
with
not
memorizing
every
number
in
the
ipv
space.
This
is
wild
card.
Support
for
ens
basically
means
that
you
can
now
have
like
the
the
example.
I
have
it's
running
on
roxton
right
now.
Is
you
basically
have
star
dot,
hatch,
dot,
eth
and
if
you
send
ether
to
rickmu
dot,
hatch
dot
eth
on
robsten,
it
will
go
into
this
account.
B
That
is
now
only
which
becomes
it's
a
counterfactually
instantiated
proxy.
So
there's
no
contract
code
sitting
there
now,
but
if
I,
the
owner
of
riku.etha,
ever
decided
that
I
wanted
to
get
that
ether
only
the
owner
of
ricky.you
can
just
can
deploy
that
contract
get
access
to
it.
Anyways
it's
super
exciting
and
it's
going
to
be
like
it's.
It's
something.
I've
wanted
for
a
long
time
we're
going
to
see
a
lot
of
just
crazy,
crazy,
cool
awesome
ideas.
B
B
Okay,
yes,
there
you
go,
I
I
knew
six
sounded
familiar
so
and
that's
basically
allows
you
to
like
get
off
get
off
chain
data
call
call
on
chain
to
get
off
chain
data
and
then
verify
the
data
is
valid
and
that
sort
of
thing
it's
way
too
complicated
to
even
really
get
into
right.
Now,
even
though
it's
very
simple,
it's
it's,
the
power
of
it
is
very
hard
to
encapsulate
into
a
concise
bubble
on
this
right
now,
but
basically
it
allows
a
lot
of
really
cool
things.
B
We
can
do
with
l2s
and
even
a
lot
of
things
like
the
the
what's
it
called
like
the
ens
airdrop
or
the
bitcoin
airdrop.
If
they
would
have
had
access
to
ccip
in
the
day,
then
you
could
have
done
a
lot
more
things
on
chain.
You
could
have
asked
for
your
balance
of
your
your
ens
tokens
without
having
ever
claimed
them
like
you,
wouldn't
even
need
a
portal
or
anything.
It
would
just
be
something
you
could
ask,
and
it
would
give
to
you.
A
I
asked
this
question
from
nick
johnson
when
we
had
him
to
talk
about
the
ccip
like
why
you
did
not
do
it
when,
when
there
was
enos
air
drop
going
on,
he
said
that
we
are
a
little
late,
but
I
hope
that
it's
going
to
be
useful
for
other
projects
who
may
plan
air
drops
in
future
and
also
about
the
other
proposal
that
you
mentioned
about
the
ens.
I
think
two,
five,
four
four.
Fortunately,
we
have
a
talk
with
nick
johnson
on
that
proposal
as
well.
A
So
I'm
gonna
link
here
so
people
who
are
interested
to
learn
more
about
these
proposals
may
follow
the
link
and
learn
about
it
and
hearing
after
your
interest.
It
looks
like
I
need
to
book
your
calendar
in
advance
to
have
you
back
to
talk
about
more
proposals,
because
I
believe
sooner
we
start
talking
about
proposal
is
good
for
people
to
know,
implement
and
then
help
those
proposals
move
towards
the
final
status.
A
B
It's
only
been
three
years,
but
yes
exactly
well.
It
was
such
a
shame
because
you
imagine,
if
I
would
have
really
I
mean
that's
one
of
the
things.
I
guess
it's
a
lot
of
effort
like
champion
and
eip
as
it
stands
right
now.
If
I,
if
I
would
have
really
put
the
time
in
earlier
on,
like
it
might
have
been
a
year
two
years
ago,
we
got
it
and
maybe
we
would
have
seen
the
the
eip
referenced
or
sorry
william
referenced
the
the
permit.
Maybe
it
would
have
used
compact
representation.
B
A
B
A
No
that's
right
and
talking
in
the
same
direction.
I
think
I
would
be
really
curious
to
hear
your
thoughts
on
the
present
process.
I
know
this
eip
took
long.
It
was
over
three
years
about
three
years
late
march,
until
nineteen
right
so
but
it
was
not
active
for
about
a
couple
of
years
from
last
11
months,
I
see
some
more
discussion
going
on
in
discussion
to
link.
So
what
is
your
general
thought
about
the
present
eip
process
or
if
you
have
got
any
suggestion
or
recommendation
to
improve
the
present
process.
B
Right-
and
so
I
mean
I
think,
as
mentioned
to
a
few
people
earlier
as
well,
is
like
so
I
think
eip
process.
The
eip
process
is
incredibly
important
and
I
do
find
right
now
it's
a
little
bit
slow.
It's
a
little
bit
like
it's
a
little
bit
frustrating
as
well,
because
you're
you,
basically
you
do
all
these
changes
and
you
get
like
it
back
and
it's
justifiably
so
I
feel,
like
you,
get
back
a
lot
of
nitpicks
and
and
that
sort
of
thing
just
to
move
a
little
bit
more
forward.
B
So
it's
definitely
you
have
to
dedicate
time
to
it.
If
you
have
an
eip,
you
want
to
put
forward
right
now.
It's
actually
quite
time
consuming,
and
I
do
worry
that
there
are
maybe
people
out
there
with
ideas
that
put
them
forward
that
we're
not
even
seeing
get
as
far
as
getting
pushed
to
the
point
where
there's
even
anything
to
talk
about,
I
mean
I
have
no
idea.
This
is
just
my
my
id.
My
thoughts
are,
there
might
be.
B
I
thought
I
know
I've
got
one
eip
that
I've
been
kind
of
pushing
for
for
quite
a
while.
I
mean
not
quite
a
while,
let's
say
like
maybe
six
months,
but
it
hasn't
even
made
it
so
far
as
to
like
really
getting
into
the
the
repo
yet
and
that
sort
of
thing,
and
so
it
it
definitely
there's
times
where
I
feel
frustrated,
I
don't
usually
feel
frustrated,
I'm
usually
a
pretty
chill
guy.
B
So
I
know
that
when
there's
something
that
makes
me
feel
frustrated
that
either
the
process
is
too
hard
or
maybe
justif
justifiably
hard,
and
I'm
just
like
you
know,
hitting
the
edge
of
my
patients
or
whatever
on
that
sort
of
thing.
So
I
think
it's
very
important,
and
one
thing
I
I
I've
heard
like
a
little
inklings
around
here
and
there
that
a
lot
of
the
eip
process
is
basically
volunteer
work,
and
I
think
it's
something
that
in
general
should
be
very
much
funded.
B
I
mean
these
are
these
are
this
is
the
future
of
ethereum?
This
is
where
the
ids
of
the
next
things
come
from.
So,
if
that's
the
only
problem,
if
it's
a
funding
issue,
then
I
would
love
to
see
something
I
mean
in
my
mind
the
ef
would
just
say
would
almost
just
hire
like
eip
editors
as
part-time
whatever's.
I
mean
I
don't
contract
employee,
whatever
the
whatever
the
system
indicates
and
again
I
am
not
a
manager.
B
I
am
not
a
I'm,
not
a
coordinator,
and
so
coordination
is
not
my
my
my
forte,
it's
not
like
my
my
powerhouse
and
so
there's,
probably
a
ton
of
things
again.
I
don't
even
know
that
I
don't
know
in
this
type
of
space.
That's
difficult
to
manage
and
logistics
are
crazy.
Give
all
these
like
groups
of
people
and
it's
so
I'm
not
blaming
you,
I'm
not
playing
the
eap
process,
I'm
not
blaming
the
cash.
B
That
said,
I
mean
now
when
I
see
something
when
it
says
stagnant,
I
jump
in
quickly
and
make
a
white
white
space
change
just
to
prevent
it
from
like
moving
into
that
state,
because
that
was
the
most
frustrating
state
to
be
in
so
so
sad
anyways.
Overall,
I
think
the
process
is
great.
I
think
it's
putting
a
lot
of
great
ideas
out
there.
I
love
the.
I
love
the
amount
of
automatedness
where
someone
approves
a
thing
and
then
eips.ethereum.org
is
just
like.
Well,
here's
your
new
information.
B
A
That's
important,
like
some
critics,
are
also
required
because
that's
needed
for
the
changes
that
is
needed
to
make
the
process
better
and
taking
some
of
your
points
that
you
just
brought
up.
I
would
like
to
let
audience
know
and
rest
of
the
people
know
that
there
are
quite
a
few
changes.
Those
are
being
done.
We,
the
cat
hurdles,
are
planning
a
bi-weekly
call
in
which
we
try
to
go
through
every
pull
request
that
has
been
made
in
the
past
two
weeks.
A
Try
to
read
them,
respond
to
them
in
sense
like
if
minor
changes
are
required.
This
is
what
you
need
to
do
and
just
fix
it
up.
We
try
to
like
these
days.
We
have
been
looking
a
lot
into
proposals
or
pull
requests.
They
should
not
be
long
painting.
Obviously,
as
you
mentioned,
the
bot,
they
have
helped
a
lot.
A
We
have
this
eip
ip
meeting,
which
is
organized
alternate
wednesday
at
1500
utc,
where
we
invite
all
the
eip
editors
to
look
into
what's
going
wrong
at
the
moment.
So
if
there
is
any
concern,
they
can
just
leave
a
comment.
It's
like
all
goddamn
meeting,
but
here
it's
not
all
core
dev.
Here,
it's
all
eip
editors
meeting,
so
we
try
to
talk
about.
A
That
way,
we
hope
that
it's
going
to
help
more
proposal
get
passed
through
the
process
fast.
As
you
rightly
mentioned,
it
is
slow
and
it
needs
some
support,
so
we
are
in
the
process
of
that.
Hopefully,
in
a
six
month
or
one
year
down,
the
line
process
would
be
way
more
smoother.
We
have
more
people
to
review
and
look
into
it
so
yeah.
Thank
you
so
very
much
for
all
your
feedback
that
you
have
shared
with
us.
We'll
try
to
go
back
to
the
recording
pick
up
one
by
one
and.
B
I
I
do
really
appreciate
the
process.
I
I
am
happy
that
it
exists
like
I
also
know,
there's
so
many
things
you
have
to
deal
with
like
one
thing
that
just
popped
in
my
mind
now
was
these
spam,
like
bots,
trying
to
pretend
they're
actual
real
people
by
making
weird
pull
requests
like,
I
understand,
there's
a
lot
of
things
you
have
to
deal
with
as
well,
and
I
guess
exactly
what
you
said.
I
think
when
the
big,
I
would
say,
probably
the
biggest
issue
with
eip
with
the
process
is
you're
understaffed.
B
A
Yeah
we
are
hoping
for
like
having
some
people
get
trained
as
an
eip
editor,
because
this
is,
as
you
mentioned
earlier,
it's
something
very
important
for
ethereum,
so
we
would
like
to
have
people
who
have
been
here
in
the
ethereum
space
for
a
while.
We
cannot
just
have
new
person
getting
in
because
it's
not
working
in
person
has
to
understand
everything
like
how
it
will
be
fitted
in
the
system.
So
it
may
take
time,
but
I
hope
that
we
are
moving
in
the
right
direction
and
thank
you
so
much.
A
B
Mean
I
don't
think,
there's
much
I've
got.
I
mean
it's
been
a
lot
of
fun.
Thank
you
so
much
for
having
me
and
I
apologize
if
I
vented
too
much,
but
I
mean
it's
been
a
great.
It
was
all
it
was
a
great
process
like
I.
I
really
enjoyed
like
having
a
chance
to
talk
about
it
and
I'm
looking
forward
to
kind
of
seeing
what
others
think
about
eip
2098.
So.
A
Awesome
we
appreciate
you
taking
out
time
to
talk
about
this
proposal
eit
2098
and
I
was
hoping
it
to
become
the
second
final
eip
of
informational
category,
but
now
now
it's
so
sorry.
That's
great.
I
mean
I'm,
I'm
not
sad
about
this
part,
because
I'm
hoping
this
proposal
will
be
widely
implemented,
so
it
actually
will
be
used
as
a
standard.
A
So
that's
a
plus
point
all
right
on
this
note,
thanks
to
all
our
youtube
viewers
for
watching
this
episode
check
out
the
description
section
for
related
links
and
guest
twitter
profiles
to
follow.
If
you
like,
the
talk
hit
like
and
share,
should
you
have
any
question?
Leave
a
comment
or
reach
us
on
ech
discord
subscribe
to
ech
youtube
youtube
channel.
If
you
haven't
done
it
already
see
you
in
the
next
week
with
another
interesting
purpose.
Until
then,
keep
watching
keep
sharing
your
love
with
the
km
cat
have
a
good
day.
Everyone.