►
From YouTube: PEEPanEIP #45: EIP-1271: Standard Signature Validation Method for Contracts with Philippe Castonguay
Description
Topics covered
-----------------------------
1:27 - Author’s introduction
2:30 - EIP-1271 (Introduction)
3:15 - Why do contracts need to be signed - Authentication
5:14 - Order books
6:00 - How to support EIP-1271?
09:31 - ERC-1271 support - example
11:05 - Q&A
11:24 - That magic value, where did that come from?
12:02 - Use cases - what other apps do you think can be built on 1271? Where do you see the future of EIP-1271?
17:06 - Why did you decide EIP-1271 to be independent of EIP-165, EIP-712?
22:33 - What do you think of the comment - “shouldn’t that be an interface EIP that makes use of EIP-165?”
23:53 - Do you see the proposal is ready to be moved to the “Final” status?
28:15 - Timeline - What do you think is the reason for a delay in moving to the last call?
31:00 - Anything that you would like to suggest to the process improvement team?
32:34 - What is the current way that this is done?
35:25 - Is there any security vulnerability?
Resources
-------------------
Slides - https://docs.google.com/presentation/d/1ydi6Kp11L5LtjsTcTpOXyqNG-k-CSD-EX1XLHrZmgvg/edit#slide=id.p
EIP-1271: https://eips.ethereum.org/EIPS/eip-1271
Discussion to: https://github.com/ethereum/EIPs/issues/1271
Follow at Twitter
-----------------------------------------------
Philippe Castonguay @PhABCD | William Schwab @William94029369 | Pooja Ranjan @poojaranjan19
Check out upcoming EIPs in Peep an EIP series at https://github.com/ethereum-cat-herders/PM/projects/2
Follow PEEPanEIP earlier episodes at https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F
Contact Ethereum Cat Herders
---------------------------------------------------
Discord: https://discord.gg/tzYmDmF
Twitter: https://twitter.com/EthCatHerders
Medium: https://medium.com/ethereum-cat-herders
GitHub: https://github.com/ethereum-cat-herde...
Email: support@ethereumcatherders.com
Website: https://www.ethereumcatherders.com/
A
Welcome
to
the
45th
episode
of
penny,
an
educational
series
where
we
learn
about
ethereum
improvement
proposal,
upcoming
feature
and
important
concepts.
Basically,
every
key
term.
You
want
to
learn
about
ethereum
blockchain,
I'm
your
host,
pooja,
ranjan
and
with
me,
are
william
schwab
and
brent
alsop
from
ethereum
cathodes
team.
In
this
episode
we
will
be
talking
about
eip
1271
standard
signature,
validation
method
for
contracts.
A
A
B
Thank
you
sounds
great
happy
to
be
here,
so
I've
been
in
the
ethereum
space
since
late
2016,
full
time,
mid,
2017
and
I've
worked
on
various
projects
and
contributed
to
a
couple
of
erc.
Standards
such
as
1155
and
1271
are
the
main
ones,
and
I've
been
working
for
last
few
years
at
a
company
called
horizon
games
and
we
are
building
a
few
products,
one
of
which
is
called
skyweaver,
which
is
a
tcg
based
on
on
blockchain
technology.
B
B
Okay,
so
this
is
1271
and,
as
puja
said
this,
this
was
introduced
in
july
2018
a
bit
earlier.
It
was
actually
a
an
inspiration
from
from
a
piece
of
snippet
of
code
that
the
xerox
protocol
implemented
way
back
in
2017,
but
it
hasn't
been
really
adopted
elsewhere.
So
we
took
that
snippet
of
code
tried
to
formalize
it
better
so
that
other
projects
can
use
it
and
yeah.
B
So
there
are.
There
are
a
few
places
that
we
need
signatures
in
in
ethereum,
and
but
why
specifically
contracts
would
need
to
sign
right
and
one
of
the
main
one
is
for
authentication.
So
this
is
was
the
ethereum
foundation
with
ens
made
this
request
for
proposal
around
kind
of
a
project
of
signing
with
ethereum,
try
to
standardize
and
have
a
flow,
and
it's
not
yet
finalized.
B
I
believe
there's
a
few
applications
still
that
are
being
processed,
but
the
idea
is
to
have
a
button,
a
bit
like
sign
in
with
facebook
sign
in
with
google,
and
now
we
would
have
signed
in
with
ethereum
and
this
so
signature,
and
this
is
usually
using
signatures.
Most
of
these
proposals
request
a
signature
from
a
wallet
and
then
the
application
will
authenticate
that
signature
as
the
mean
to
authenticate
the
user
to
prove
that
you
are
control
of
a
wallet.
B
This
is
for
regular
ethereum
wallets
such
as
metamask
and
well,
while
connect
or
derivatives,
and
these
use
a
simple
private
key,
whereas
login
with
contract
wallet
is
a
as
a
path
where,
if
you
use
a
smart
contract
wallet
such
as,
for
example,
or
multi-signature
wallet,
you
can
sign
with
the
contract
wallet
and
this
proposal
uses
1271.
As
you
mean
for
contracts
to
validate
the
signature.
So
authentication
is
a
big
one.
B
So,
okay.
So
how
do
we
support
erc
721?
So
I'm
briefly
going
to
go
over
the
standard.
It's
a
very,
very
simple
standard.
There's
very
little
to
implement,
so
it's
it's
very
easy
to
to
adapt,
but
this
is
really
the
core
of
it
and
that's
pretty
much
all
there
is
so
a
a
contract
that
wants
to
basically
sign
or
validate
signatures
needs
to
implement
this
function
called
is
valid
signature,
which
only
takes
to
argument
the
hash
that
is
signed,
which
is
the
pillar
that
I
signed
and
the
signature.
B
The
reason
for
that
I
can
explain
if
you're
interested,
but
instead
of
just
returning
a
true
or
false,
which
sometime
can
be
a
bit
misleading
if
it
was
an
error
or
something
else.
This
very
specific
value
makes
it
easy
for
the
contract
that
calls
it
to
know
that
this
is
indeed
a
valid
signature,
and
it's
really
up
to
the
contract
to
implement
the
logic
of
what
determines
a
valid
signature.
B
If
it's
a
multi-sig,
then
the
signature
may
be
very
long,
a
concatenation
of
multiple
signatures
from
users,
but
there
could
also
be
a
time
stamp
related
issues
where,
if
part
of
the
signature
signature
is
only
valid
for
a
couple
of
hours,
maybe
a
contract
within
the
as
valid
signature
could
decide
that
there's
a
time
limit
for
that
that
signature
to
be
valid.
So
it's
really
up
to
the
contract
to
determine
what
what
defines
a
valid
signature,
but
the
interface
is
the
same
for
all
of
them.
B
There's
a
hash,
there's
a
signature,
and
if
you
want
to
check
that
this
contract
authorizes
a
signature
or
that
a
signature
is
valid
for
that
contract,
you
just
pass
these
two
arguments.
So,
for
example,
let's
go
now
with
a
summer
contract
example,
just
as
an
example
implementation
that
this
one
checks
that
the
center
is
the
owner
of
the
signing
contract,
so
that
contract
could
be
again
like
argent
or
smart
contract
wallet
or
multi-signature,
and
you
just
check
if
the
you
recover
designer
that
signed
the
hash
and
if
that's
the
owner,
you
return
true.
B
B
So
that's
a
very
simple,
and
that
was
an
example
of
a
summer
contract.
Now
what
what
about
contracts
that
want
to
validate
signatures
for
using
1271,
so
you
could
have
a
method
called
your
c1271
is
valid
signature
that
takes
an
address,
a
hash
and
a
signature,
and
then
you
just
call
on
that
address.
That
method
is
valid.
Signature
pass
the
hash
pass,
the
signature.
B
Okay,
so
that
was
really
the
core
of
it
and
again,
maybe
just
to
return.
This
is
really
important,
because
a
contract
needs
to
be
able
to
signal
what
it
defines
a
valid
signature
and
the
contract
itself
is
should
be
the
only
entity
that
knows
this
is
a
valid
signature.
This
is
not
a
valid
signature
and
the
limits
there
are
really
like
endless.
You
can
have
very
abstract
signature
validation
per
contract
if
desired,
using
different
types
of
cryptography
curve.
B
Okay,
so
now
as
an
example
of
erc
1271
support,
so
this
is
actually
a
standard
that
has
been
around,
for
you
know
almost
three
years
more
than
three
years
now,
so
a
lot
of
projects
have
already
adopted
it,
even
though
it's
not
finalized
the
the
main
adoption
comes
from
all
the
smart
contract
wallet
pretty
much.
Every
single
smart
contract
wallet
that
exists
out
there
supports
a
1271..
Here
are
the
example
I
could
think
of
top
of
my
head
dharma
argent
sequence.
B
Now,
there's
a
few
also
dapps
that
support
it,
matcha,
which
is
the
aggregator
from
xerx.
You
can
sign
limit
order
using
1271,
so
that
means
you
can
sign
limit
orders
with
your
smart
contract
wallet
or
multi-signature
wallet,
arrogant
as
well
use.
It
is
for
governance,
votes,
rareball
uses
the
nfd
marketplace,
they
use
it
for
if
you
want
to
place
bid
on
nfts,
you
can
use
your
smart
contract
wallet
by
signing
messages
via
1271
as
well,
and
these
are
just
a
few
one.
B
I
know
there's
others
that
they
use,
but
that's
the
less
I
I
could
think
of
and
yeah
that's
that's
actually
pretty
much
all
there
is
to
that
standard.
The
more
people
use
it,
the
better.
It
is
and
yeah.
If
I
know,
there's
a
there's
a
few
questions,
maybe
we
could
jump
to
that
and
and
have
a
more
open
discussion.
A
B
It's
yeah,
it's
a
good
question,
so
the
magic
value
comes
from.
Actually
this
little
line
right
above
it's
something
that
other
standard
have
been
using,
because
it's
fairly
easy
to
remember.
You
just
take
the
first
four
byte
of
the
hash
of
the
basically
function,
signature
that
this
standard
is
referring
to.
So,
if,
if
you
just
take
the
hash
of
the
signat
valid
signature
function
by
32
bytes
and
you
take
the
first
four
byte,
it's
going
to
give
you
this.
D
B
So
to
for
to
answer
the
first
question:
yeah
like
definitely
everything
order
book
related
or
a
signature,
intent
for
a
specific
actions
or
there's
a
lot
of
applications
there,
the
main
one
today
and
since
the
last
few
years
have
been
signing
orders
for
trading.
It
could
be
like
on
dydx
your
x,
whatever
marketplace
that
uses
limit
orders
or
order
book.
B
This
probably
the
main
use
case,
but
you
can
also
have
things
like
you
could
implement
it
such
that
e2
validators
could
use
multi-signatures
or
or
a
wallet
contract,
as
you
mean
to
sign.
Currently,
the
ethereum
2.0
only
supports
eoas
for
validating
for
validators
to
sign,
but
you
could
add
1271
support
for
for
smart
contract
wallet,
so
that
would
be
another
application.
That
is
a
bit
out
of
different
than
the
order
book.
B
Well,
okay,
yes,
that
signer!
I
want
that
sun.
This
is
a
valid
center.
You
could
imagine
like
a
dow
or
something
that
has
hundreds
of
people
that
can
sign,
but
the
signature
does
not
have
the
same
abilities
or
different
signatures
cannot
perform
the
same
action,
so
you
could
say:
okay!
Well,
if
you
pass
more
data
into
this
is
valid
signature.
Instead
of
just
a
hash,
you
could
say:
okay,
well,
that
signer
is
trying
to
purchase.
B
B
D
D
D
B
Now.
It
is
true
that
contract
may
not
be
able
to
construct
the
hash
and
then
send
a
request
for
signature
validation,
because
they
may
not
know
how
to
construct
that
hash
in
the
first
place.
So
it's
expected
that
the
hash
would
be
passed
from,
perhaps
a
client,
so
it
does
cause
some
limitations
here,
but
in
general,
so
long
as
you
have
usually
each
application
are
going
to
have
their
own.
You
know
signature,
not
signature,
but
data
encoding
and
data
hashing
and
they're
only
going
to
care
about
that
specific
hash
structure.
B
So
in
general,
I
think
just
having
a
hash
is
sufficient,
so
712
would
lie
more
on
the
the
dapp
side,
so,
for
example,
0x
or
openc
could
require
the
data
that
is
signed
to
be
using
712,
encoded
and
then
hashed
and
then
signed.
But
1271
does
not
care
about
this.
It's
it
just
you
know
so
long
as
you
send
it
a
hash
and
a
signature.
B
It
doesn't
really
care
what
the
data
is.
So
I
think
that's
why
it's
it's
sufficient
on
its
own,
to
just
have
the
hash
not
specify
how
the
hash
is
created
and
for
your
second
question
of
erc
165
I
actually.
This
is
something
I
I
saw
the
comments
a
week
ago.
I
forgot
about
it,
but
this
is
actually
really
interesting
idea
and
I
think
it's
fairly
standard
now
to
incorporate
erc
165
in
other
standards,
so
I
could
definitely
see
adding
it.
B
The
only
reason
why
I
could
see
people,
maybe
being
reluctant
or
feel
like
it's
not
necessary
is
the
fact
that
there's
no
other
standard
for
contract
signatures.
So
if
that
call
fails,
if
I
try,
if
I
detect
that
you
know
a
user
is
a
user
address,
is
a
smart
contract,
then
erc
1271
is
pretty
much
the
only
option.
B
There
is
for
signature
validation
at
the
moment,
that
is
standardized
and
if
you
call
is
valid
signature
and
it
throws
an
error
or
returns
a
value
that
is
unexpected,
then
it's
very
unlikely
that
that
signer
contract
supports
any
contract
signature.
So
that's
my
argument
as
to
why
maybe
erc
165
is
not
needed.
B
I'm
super
happy
and
open,
of
course,
to
include
it
because
it's
a
small
component,
but
I
don't
know
if,
because
1271
has
been
in
in
the
wild
for
a
long
time,
which
means
a
lot
of
people
already
incorporated
it,
and
it's
unclear
to
me
if
all
of
them
already
support
erc
165
already,
and
I
wouldn't
want
to
you-
know,
put
them
as
like,
not
standard
compliant.
For
that
reason,
but
yeah
happy
to
have
opinion
from
other
people
as
well.
In
this.
D
Very
interesting,
that's
it
for
me
on
the
technical
side,
but
you
did
start
mentioning
kind
of
the
process
of
12.71
and
there's
already
a
lot
of
people
who
are
incorporating
it-
and
I
know
puja
has
some
questions
about
kind
of
the
process
and
the
the
history
of
1271
so
far,
and
also
the
the
current
ecosystem
support.
So
I'm
going
to
hand
over
to
her.
A
B
B
A
So
the
question
here
is
at
at
present
that
the
proposal
is
in
form
of
an
erc
not
as
an
interface
proposal
so
like
it
is
on
different
types
and
categories
of
eips.
So
there
are
three
different
types
of
proposals,
so
meta
standard
and
informational
and
in
standard
we
have
different
four
categories:
one
is
erc,
one
is
core
interface
and
networking.
A
So
when
we
are
talking
about
interface
proposal,
basically
that
is
there
for
interaction
of
like
contracts
on
different
levels
and
because
this
is
actually
helping
like
validating
the
signature
of
non-eoa
contracts.
So
the
person
I
believe,
is
asking
trying
to
ask
here
like
why
not
an
interface
proposal,
why
you
are
going
with
erc.
A
Right,
yeah
interface
category
is
really
not
so
very
popular.
We
have
very
few
proposals
which
are
in
final
status
and
like
now.
Also
there
are
some
distinctions
going
on.
We
are
removing
some
of
the
already
standard
moving
out
of
the
interface
category
and
having
them
like
living
somewhere
else.
It's
at
eat
one
dot
or
spec
repository,
but
that's
a
part
of
process.
A
A
B
B
It's
it's
a
bit
unfortunate
because
erc
1271
has
been.
You
know.
It
took
a
very
long
time
to
come
out
of
the
draft
stage,
mainly
because
people
use
it
already
from
the
draft,
and
that's
that's
how
everybody
knows
it.
So
I
think
people
kind
of
assume
that
it's
already
final
and
so
that's
why
there's
very
little
discussion
around
it
and
people
just
use
it
as
as
it's
defined
so
yeah
I'd,
be
I'd,
be
happy
to
finalize
it
like
this
without
erc
165.
B
A
Right,
so
just
for
your
information
generally,
this
is
completely
on
the
other,
whether
they
want
to
implement
any
suggestion
provided
by
community
or
not
if
they
feel
like
that
is
good
proposal,
and
they
want
to
go
ahead
with
that.
That
can
be
considered
as
a
standard.
Now
that
you
are
already
into
last
call-
and
you
have
received
a
few
comments-
and
it's
completely
up
to
the
author-
that
they
want
to
do
it.
A
If
you
decide
to
go
ahead
without
integrating
165
into
it,
that's
fine
and
people
who
are
planning
to
search
who
are
suggesting
or
planning
to
have
some
something
more
added
to
it.
They
can
always
propose
a
new
proposal
with
having
this
as
like
a
required
proposal
like
this
would
be
the
base
proposal
for
them,
and
on
top
of
that,
whatever
feature
they
want
to
add,
they
can
go
ahead
and
do
that
and
just
one
more
comment
I
want
to
add
here,
because
I
know
just
the
new
process
is
not
very
like
popular.
A
A
So
I'm
not
very
sure
that
this
is
the
reason,
but
this
can
be
one
of
the
reasons
like
of
getting
less
comments.
So
there
is
this
one
more
thing
I
wanted
to
bring
it
here
about
the
eip
status.
I
am
aware
that
there
was
an
attempt
to
move
the
proposal
to
the
last
call
like
before
we
did
it
recently,
but
it
was
suggested
to
move
into
the
review
phase
instead
and
it
was
done
and
now.
Finally,
it
is
at
the
stage
where
it
has
already
passed
last
call.
A
A
My
next
question
is
related
to
the
timeline,
like
we
discussed
that
this
proposal
is
out
over
three
years
like
and
I'm
very
surprised
to
see
that
it
has
got
over
100
comments
right,
so
I'll
be
a
little
curious.
What
do
you
think
could
be
the
reason
of
delay
for
moving
towards
standardization?
I
saw
that
comment
started
in
2018
till
2020.
It
was
there
and
then
there
was
some
gap
and
then
coming
back
in
2021..
B
B
Paying
me
put
a
message
like
hey:
why
is
this
not
final?
It's
been
years
and
then
you
know
at
that
point
which
is
a
valid
point.
Then
we
just
tidied
it
up
submitted
for
review
and
then
last
call.
So
I
would
say,
number
one
was
leanness,
but
before
that
there
was
a
lot
of
projects
that
wanted
to
implement
this.
A
lot
of
different
smart
contract
quality,
a
lot
of
applications
and
some
of
them
had
slightly
different
needs,
and
there
was
a
big
debate
around.
B
So
I
think
at
that
point
the
tide
shifted
to
okay,
we'll
just
use
byte
32
pass
a
hash
instead
of
a
bite
array
to
for
simplicity
and
in
practice
it
seems
to
be
what's
mostly
used,
so
that
also,
I
think
delayed.
So
that
would
be
the
second
to
be
yeah.
For
sure
number
one
is
is,
is
laziness
on
my
part,
so
apologies
for
that.
A
A
A
B
A
A
E
B
Now
that
smart
contract
has
its
own
ownership
rules
saying
okay!
Well,
all
of
these
address
are
able
to
transfer
funds
from
the
contract,
so
you
can
have
multiple
owner
of
a
wallet
for
example,
or
you
can
have
a
multi-signature.
You
need
two
out
of
three
owners
to
sign
before
you
can
take
out
your
phones
from
arjun,
for
example,
prognosis,
if
not
safe,
is
mainly
used
for
multi-signatures
in
many
cases.
B
So
this
is
where
a
signature
is
a
bit
convoluted,
because
imaging
gnosis
safe
that
is
used
sometimes
by
corporations
with
you
know:
seven
signers.
What
is
a
valid
signature
for
gnosis
safe?
Well,
I
mean
there's
a
lot
of
signers.
We
can't
really
there's
no
way
for
us
outside
of
that
contract
to
know
for
that
contract.
What
is
a
valid
signature,
so
gnosis
safe
would
implement
that
function
within
its
code
contract
code,
and
you
could
call
it
passing
a
hash
and
a
signature,
byte
array
and
then
knows
the
same,
would
say.
B
Yes,
this
is
a
valid
signature.
According
to
my
own
definition
of
what
a
valid
signature
is
so
that
allows
basically
all
these
contracts
to
define
their
own
rules
of
what
defines
a
signature,
a
valid
signature
and,
for
example,
as
an
example
of
like
application
that
uses
I
showed
here
but
like
on
openc.
B
B
But
if
you
had
a
smart
contract
wallet
such
as
agnosis
safe,
for
example,
a
multi-signature
wallet
it
would
instead
of
you,
would
sign
a
message,
but
the
the
open
c
or
the
dap
would
need
to
call
that
function
here.
Saying.
Is
that
a
valid
signature
first?
In
order
to
make
sure
that
this
is
a
valid
signature,
that's
being
signed
for
that
wallet
yeah.
Does
that
answer
your
question.
E
Yeah
it
does,
I
think,
also,
I
think
you
might
have
answered
this,
but
maybe
I
I
didn't
quite
catch
it.
How
is
it
handled
right
now
in
the
sense
of
like
so
when
a
contract
responds
to
you
or
when
you
kind
of
do
dealings
with
a
contract?
There's
no
way
to
know
whether
or
not
that
that's
actually
coming
from
the
contract?
So
isn't
that,
like
a
security,
vulnerability
that
exists
currently.
B
B
B
Can
you
sign
with
metamasker
this
random
message
in
order
for
you
to
prove
that
you
are
in
control
of
that
wallet
now
that
dap
would
basically
request
a
signature
from
gnosis
a
for
argent
or
whatever,
and
then
in
order
to
validate,
if
it's
a
valid
signature
for
that
specific
wallet,
it
would
do
this
here.
It
would
call
the
is
valid
signature
method
on
your
wallet
address,
passing
the
wallet
address
and
it
would
ask
your
wallet
by
doing
a
contract
call
via
the
blockchain
say.
B
A
A
Twitter
handle
the
presentation
and
some
of
the
resources
related
to
this
proposal
in
the
description
section,
give
it
a
look,
do
let
us
know
which
proposal
you
would
like
to
hear
next
in
this
series,
as
usual
I'll
be
looking
forward
to
your
feedback,
reach
me
or
any
of
the
cathodes
on
twitter
or
ech
discord
with
any
suggestions,
we
will
keep
getting
you
interesting
talks.
Stay
tuned,
keep
watching,
keep
sharing
your
love
with
the
team
catered
see
you
all
in
the
next
episode
cheers.