►
From YouTube: AllWalletDev11
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
Cool
so,
first
of
all,
thanks
Sam
for
inviting
us
to
discuss
this
issue
that
we
found
like
two
or
three
months
ago.
It's
been
quite
a
challenge
to
you,
know,
coordinate
the
disclosure
and
and
also
to
let
every
involved
party
know
about
about
the
issue.
Okay,
so
I'm
gonna
talk
about
myself
like
very
quick
I
I
come
I'm
coming
from
the
web
to
security
area,
I
was
previously
a
consultant
at
an
another
consultancy
company
I'm
from
coinspec.
B
There
we've
been
working
in
the
blockchain
security
since
2014
and
yeah.
We
do
every
kind
of
security
audits
from
Smart
contract
to
off
chain
code.
B
B
We've
been
doing
that
in
our
free
time,
mostly
on
we
or
when
we
are
of
audits
or
or
another,
you
know
consultancy
projects,
so
we
realized
that
the
wallet
security
field
is
was
very
little
explored,
not
as
much
as
smart
contracts,
for
instance,
and
the
approach
we
took
was
first
starting
as
a
black
spot.
Black
box
testing,
like
you,
know,
testing
all
of
the
user
experience
of
the
of
the
wallet
to
assess
whether
that
user
experience
was
Secure,
and
now
we
are
focusing
more
towards
the
source
code.
B
Of
course,
whenever,
whenever
we
have
source
code,
there
aren't
many
source
code
wallets
out
there,
but
still
most
of
them
share
code
base
and
share
the
same
architectural
patterns
so
yeah,
that's
it
and
okay,
so
about
the
goal
of
This
research
project
is
to
overall
to
contribute
to
a
better
and
more
secure
user
experience.
B
Our
goal
is
to
assets
multiple
wallets
at
once
and
try
to
discover
issues,
multiple
issues
affecting
more
than
one
wallets,
which
is
the
case
of
these
EAP
712
issue
and
then,
like
aside
from
doing
the
research,
we
I
will
also
later
comment
about
the
our
upcoming
work
or
our
upcoming
ideas.
For
these
you
know
high
level
wallets
research
projects.
B
So
what's
the
eaps
712
issue
about
I
know
if
you
guys
were
able
to
to
read
about
the
issue,
the
thing
is
that
the
problem
itself
was
was
not
as
impactful
as
you
know
we
are
used
to.
Actually,
this
is
a
lower
medium
security
issue.
I
mean
the
risk
I
mean,
but
the
the
what's
interesting
here
is
is
that
it
affected
more
than
40
wallet.
Vendors
I
think
that
there
were
just
three
or
four
that
were
were
actually
validating
his
problem.
B
One
of
them
was
metamask,
which
we
most
of
the
time
consider
as
a
security
standard,
because
they
do
a
pretty
good
job
at
it.
So
the
problem
here
is
that
many
wallets
didn't
validate
the
the
chain,
ID,
the
that
that
that's
in
the
EIP
712
domain,
that
so
the
wallet
didn't
validate
that
the
chain
ID
of
of
this
domain
was
the
same
chain
ID
of
the
chain,
the
user
selected
in
the
wallet
so
I'm,
giving
I'm
giving
a
practical
example.
B
Let's
say
I'm
using
my
wallet
with
in
the
Ethereal
Network
and
a
malicious
app
could
have
signed
a
a
an
EAP
712
object
for,
let's
say
the
arbitrine
chain
and
unless
I'm
an
expert
at
chain
ideas,
I
I,
couldn't
have
noticed.
You
know
this
problem
and
could
have
signed
these
EIP
712
object,
which
would
have
allowed,
which
could
have
allowed
the
attacker
to
you
know
to
obtain,
let's
say
a
permit
for
the
for
another
chain
than
the
one
I
selected,
so
yeah.
B
The
relevance
of
this
issue
is
more
about
the
the
number
of
vendors
that
were
affected
more
than
they
should
solve.
But
that's
our
goal
to
you
know,
keep
finding
issues
like
this
that
are
shared
across
several
wallets.
We
also
found
a
couple
of
other
issues
that
were
also
reported
along
this
journey.
Also
related
to
EAP
712,
for
instance,
some
wallets
were
now
displaying
we're
not
displaying
the
EAP.
712
object
be
to
be
signed
at
all
or
we're
not
displaying
the
the
eip-712
domain.
B
Part,
which
is
I,
mean
the
the
EAP
712
domain
has
like
five
different
fields.
One
of
them
is
a
chain
ID.
Then
we
have
the
verifying
contract.
There
is
a
a
salt
and
a
version,
for
instance,
so
some
wallets
fail
to
to
actually
display
that
when
asking
users
for
for
their
signature
Okay.
So
regarding
our
experience,
because
this
was
an
experience,
I
think
that
it
took
us
like
almost
three
months
since
we,
since
we
started
to
discover
a
pattern
across
different
wallets
and
inspiring
for
pattern.
B
So
since
we
started
to
discover
that
pattern,
until
we
were
finally
able
to
publish
the
blog
post,
it
was
a
an
entire
experience.
So
we
realized
that
many
vendors
actually
host
or
I
think
it
was
almost
a
50
of
wallet,
vendors
hosts
by
grantee
programs
and
but
yeah
most
of
the
vendors
that
host
background
programs
are
them.
Well
established
wallet
wallets,
but
the
program
we
found
here
is
that
not
or
I'd
say
most
of
the
vendors
they
don't
allow.
B
The
disclosure
of
bugs
I
mean
once
you
report
it,
they
say:
hey
I,
don't
want
this
bag
to
be
disclosed,
but
the
thing
is
that
here
we
found
that
bugging
like
39,
more
other
wallets,
which
is
kind
of
you
know
difficult
for
us.
Then
we
also
found
I
I,
know
I,
think
that
it
was
for
vendors
that
didn't
even
have
a
contact
channel
that
we
couldn't
reach
out
to
Summer
vendors.
B
B
The
thing
is
that
many
vendors
kept
on
asking
for
an
extension
of
the
day
so
that
they
could,
you
know,
publish
their
or
I
mean
deploy
their
their
patch
and
I
think
there
are
still
some
vendors
that
haven't
deployed
the
patch
and
also
we
found
a
couple
of
vendors
that
said
hey
so,
since
this
is
a
malicious
app,
then
your
bag
is
not
in
scope
and
that's
funny,
because
I
think
that
in
the
in
the
thread
model
of
any
wallet,
you
have
to
consider
malicious
apps.
B
Otherwise,
why
are
we
asking?
You
know
permission
to
connect
to
adapt
if
it's
small,
if,
if
we
consider
it
not
to
be
malicious
right,
so
that
was
funny.
We
have
a.
We
have
a
couple
of
bugs
rejected.
B
Also,
if
you
guys
want
to
head
to
the
coinsback
Twitter
profile,
you'll
see
a
a
an
exploit
that
we
we
published
a
few
weeks
ago,
foreign
they
were
not
willing
to.
You
know
recognize
they
had
a
serious
bug
so
yeah
they
were
one
of
the
one
of
the
people
that
didn't
didn't
want
to
acknowledge
the
opponents.
B
So
I
I
talked
about
this
high
level.
Software
wallets
research,
research
project,
so
what's
next
the
things
that
we've
we
we
kept
on,
you
know
investigating
the
multiple
wallets
actually
in
the
upcoming
weeks.
I
think
that
we
are
going
to
publish
another
problem
that
we
found
related
to
the
the
transaction
simulation
in
a
well-known
wallet,
so
stay
tuned,
give
a
follow
to
the
coins
coins
back
profile
Okay.
B
So
then,
we
are
also
thinking
in
publishing
a
wallet
checklist
that
could
be
used
as
a
guideline
for
for
both
wallet,
Builders
security,
Auditors
and
even
users.
So-
and
this
checklist
was
the
result
of
the
research
that
we
started,
because
we
try
to
systematically
do
an
assessment
to
each
and
every
wallet.
So
this
checklist
was
a
sort
of
an
internal
tool
that
we
are
willing
to
publish
and
and
with,
and
that
we
think
that
will
be
will
come
handy
for
people
out
there.
B
And
we
can
figure
something
out
otherwise,
also
stay
tuned
for
updates.
I
think
that
we
will
shoot
soon
be
publishing
the
the
checklist
in
in
the
next
month
and,
finally,
if
there's
something
that
you
guys
don't
have
time
to
investigate
or
or
that
you'd
like
to
ask
to
investigate
about
just
please
ping
us
we
are
happy
to
do
so
in
our
in
our
free
time
and
I.
Think
that
that's
it
I
hope
to
have
been
pretty
quick
and
so
boring.
So
thanks
guy
for
for
listening
to
this
talk,
I
know.
A
B
Yeah
I
I
think
that
we
found
I
think
it
were
like
six
wallets
that
didn't
show
the
the
object
at
all
and
six
six
other
wallets
that
were
not
showing
the
domain.
Part
Which
is
less
of
a
problem,
but
it
is
still
a
problem
right
because
an
attacker
can
just
you
know,
sign
whatever
they
want
and
they
use
the
one
down.
That's
funny.
B
Of
it
it's
not,
it's
not
meant
to
be
automatable,
because
there
are
a
bunch
of
you
know,
code
source
code,
checks
and
but
I
think
that's
something
that
it
could
be
done
with.
You
know
a
certain
work,
but
at
the
very
beginning
it
was
meant
to
be
more
of
a
let's
say,
an
almost
checklist
for
for
software
wallets,
but
we
are
open
to
any
ideas
and
suggestions.
Of
course,.
A
So
the
reason
I
ask
is
kind
of
a
transition
into
the
next
topic,
we're
building
a
testing
framework
and
if
you
have,
if
any
parts
of
that
checklist
are
automatable
like
you
know,
the
wallet
should
display
the
712
domain.
That
would
be
a
good,
a
good
test
to
add
to
our
framework,
so
I'd
love
to
collaborate
with
you
on
that.
B
C
A
Right
so
next
up,
I
guess
is-
is
me
and
Nick
here
if
they're
here
we've
been
working
on
the
wallet
test
framework
that
you've
hopefully
heard
a
little
bit
about
and
if
you
haven't
go,
look
it
up
it's
a
collection
of
tests
that
we're
building
to
share
as
like
a
common
good
between
wallets
to
ensure
like
a
basic
level
of
consistency
and
quality.
D
A
So
far,
we've
been
using
frame
and
metamask
as
our
test
wallets.
If
you,
you
know
like
to
try
out
your
own
wallets,
there
are
instructions
on
the
GitHub,
repo
and
I'll
post,
a
link
to
that
after.
C
C
A
Yeah,
so
this
is
what
it
looks
like
today.
It's
a
small,
NPO
or
node.js
server
that
proxies
connections
and
I
have
to
turn
you
through
it.
A
So
the
first
step
is
that
it
adds
a
a
fake
ethereum
chain
that
connects
to
ganache
running
inside
the
browser,
we're
using
mocha
as
our
testing
framework,
and
it
makes
these
nice
little
HTML
summaries.
So
everything
that's
going
on
right
now
is
actually
testing
against
the
simulated,
blockchain
and
proxying
through
the
node.js
backend
server.
A
So
far
we
don't
have
any
UI
automation
tests,
that's
going
to
be
coming
a
little
bit
later.
So
far
we
have
just
some
tests
for
basic
RPC
endpoints
like
getting
the
chain
ID
getting
you
know,
transactions
and
that
your
balance
updates
after
you
receive
money.
A
C
Are
any
of
these
going
to
fail?
I
want
to
show
a
failed
test,
no
all
right
cool,
so
yeah,
that's
about.
A
It
for,
for
that,
does
anybody
else,
have
anything
they'd
like
to
demo
any
questions.
Any
conversation
topics.
D
A
Does
it?
Yes,
exactly
so,
metamask
adds
a
new
tech
like
we
call
wallet
at
ethereum
chain
with
like
a
unique
URL
that
gets
proxied
over
websockets
back
to
the
same
browser,
and
it's
connected
to
ganache
running
in
that
browser
instance.
A
D
A
Well,
yeah,
so
once
we
get
some
UI
automation
working,
so
the
design
is
kind
of
going
to
have
a
piece
of
glue,
that's
unique
to
each
wallet.
That
knows
how
to
click
buttons
and
and
things
in
the
UI,
and
that
is
how
we're
going
to
add
the
wallets
in
the
future.
As
I'm
sure
most
of
you
are
aware,
I
have
Eep
5139,
which
is
all
about
getting
rid
of
wallet
at
ethereum
chain.
But
for
now
this
works
really
well,
but
it
is
something
we're
planning
on
getting
rid
of.
A
Exactly
yeah,
but
that's
probably
gonna,
be
the
first
piece
of
automation.
We
do
yeah,
okay,
yeah,
there's
totally
an
empty
slot
today,
love
to
have
you
demo,
whatever
you've
been
working
on
any
other
questions
on
wallet
test
framework,
if,
if
not
we'll
move
on
to
Victor.
E
F
Everyone,
my
name,
is
Victor
and
I,
also
go
by
X.
I
am
the
NLB.
If
you
encounter
me
on
GitHub
or
ethereum
Edition
I'd
like
to
demonstrate
to
you
a
new
update
on
the
ERC
ref
I
came
to
this
a
group
a
few
weeks
ago,
demonstrating
the
general
concept
of
yati
ref.
F
Basically,
we
want
to
build
a
repository
for
people
to
share
the
reference
implementation
to
the
to
erc's,
so
authors
contributors
developers
feel
free
to
come
over
and
today,
I
just
want
to
share
one
of
the
new
thing
that
we
called
yes
yes20
token
with
fees,
so
I
I
think
it's
an
interest
in
my
interest,
the
wallet
group,
because
a
lot
of
you
operate
in
helping
people
sign,
contract,
signed
transactions
to
transact,
and
so
there's
a
general
concept.
F
That's
usually
an
erc20
transfer
doesn't
incur
a
commission
on
some
of
the
community.
Members
in
the
industry
has
started
to
discuss
whether
it's
possible
to
or
should
it
be,
a
new
Norm
to
incur
fees.
So
in
that
case,
for
example,
usdp
as
one
of
the
biggest
one
of
the
top
three
staple
coins
has
a
in
place
fee
default
to
zero.
Right
now
set
up
so
that
they
can
in
the
future,
change
that
parameters
to
charge
fees
whenever
a
transaction
happens.
F
So
a
reference
implementation
has
been
provided
in
this
particular
smart
contract
where
you
can
deploy
it
in
test
with
your
wallet
Whenever,
there
is
a
transaction
there's,
a
fees
that
is
incurred
and
then
to
see
if
it
works.
There
is
a
test.
We
also
wrote
to
just
demonstrate
how
it
works
and
what
is
to
be
expected
and
so
yeah.
F
This
is
what
I
want
to
show
and
in
general,
the
ERC
ref
contracts
is
we
want
to
build
a
library
so
that
you
cannot
not
only
share
your
smart
contract
but
also
learn
from
others,
and
then,
ultimately,
we
want
to
build
something
similar
to
open
Zeppelin,
but
a
more
bleeding
edge
right
for
this
ERC,
that's
even
in
draft
or
for
ercs,
that's
mature,
but
you
have
new
ideas
like
this.
F
This
is
hopefully
a
place
for
you
to
kind
of
check
out
and
and
come
to
contribute,
so
contributions
are
welcomed,
check
out
ERC
ref
of
the
git
in
a
GitHub
or
our
website,
and
that's
it.
Thank
you.
Our
wallet
call
meeting
back
to
you,
Sam.
A
E
Yep
Adam
yeah
I
just
wanted
to
quickly
show
the
human
readable
transactions
working
group
put
together
by
Kong
from
sourceify.
We
just
had
our
kickoff
meeting
this
morning.
It
seems
relevant
to
probably
most
of
y'all.
If
you
work
on
a
wallet
you
got
to
display
transactions
to
users,
somehow
so
just
linked
the
the
Twitter
posts
in
the
chat
and
also
in
the
general
Channel.
G
I
do
have
one
thing:
we're
trying
to
get
a
standard
into
the
various
clients
for
each
multi-call.
This
is
basically
the
same
as
this
call,
except
for
you
can
do
multiple
transactions
and
they'll
all
build
off
of
each
other.
The
same
way
transactions
in
the
block
build
off
each
other,
and
you
can
also
do
things
like
telling
the
underlying
execution
engine.
What
the
block
timestamp
is.
What
block
number
it
is
things
like
that?
G
The
idea
here
is
that
this
solves
a
number
of
different
problems
for
both
staff
developers
and
Tool
developers
and
integration
people
doing
Integrations
people
doing.
It
also
allows
for
people
to
do
Mev
without
needing
to
be
experts
in
scripting,
because
you
can
just
you
know.
G
Node
anyways
drop.
The
link
in
the
chat
I
strongly
encourage
any
wallet
developers
to
give
it
a
look,
because
it
may
impact
a
what's
how
your
wallet
works
and,
but
more
importantly,
it
may
allow
you
open
new
doors
for
your
wallet
and
so
we'd
love
to
get
more
feedback
and
support
from
the
wall
community
on
it.
C
A
F
Oh,
thank
you
Macau
good,
to
meet
you
here.
A
question
for
this
is
that
does
it
mean
that
the
people
will
no
longer
were
less
likely
to
need
to
use
any
on-chain
smart
contract
bundler,
because
the
evm
will
support
that?
The
execution
will
support
that
out.
Above
so
you
can
make
a.
G
Call
directly,
this
is
only
for
off-chain
calls,
meaning
like
each
call
type
stuff.
This
is
not
for
forcing
transaction
ordering,
which
is
a
separate
thing
so
like
if
you
want
to
make
sure
that
three
transactions
land
in
a
row
on
chain.
This
will
not
help
you
with
that
directly.
At
least
this
is
more.
If
you
want
to
say
okay,
what
happens
if
I
do
X,
then
y,
then
Z
and
I
want
to
see
the
feedback
so
the
way,
for
example,
the
way
we're
using
it
in
our
tool
is
we're
making
it.
G
So
people
can
utilize
ethereum
based
applications
like
uniswap
and
curve
and
whatever,
and
they
can
kind
of
go
through
the
process
of
using
that
app,
but
without
actually
committing
anything
to
the
chain,
but
they'll
see
the
chain
as
though
they
had
done
all
those
things.
That's
how
we're
using
it
and
they
can
again
it
could
be
used
in
a
bunch
of
different
ways,
but
this
is
all
just
just
for
the
eth
call
side
of
things
not
for
the
send
transaction
side
of
things.
F
Oh
I
see
got
it
yeah
thanks,
that's
very
helpful.
That's
it
if
I
just
to
make
sure
that
I
understand
correctly
it.
It
also
means
that
it's
just
for
local
check
and
then
wait
a
minute.
So
does
it
does
it
require
it
at
any
case
it's
being
used
to
to
send
in
transaction?
It
also
does
not
insert
automated
CT
of
those
transactions
together.
G
G
It
does
not
have
any
it
doesn't
give
you
any
guarantees
on
that
front
once
you
go
to
the
chain,
this
is
purely
for
simulation.
So
a
perfect
example
of
this
is:
if
you
go
to
uniswap,
you
need
to
do
an
approval
before
you
can
send
right,
and
so,
if
you
wanted
to
see
what
happens?
Okay,
if
I
do
an
approval,
then
I
do
Ascend
in
uniswap.
You
can
do
that
by
doing
a
multi-call
of
approved,
then
sends
you
stack
them
together.
G
You
send
them
both
as
one
thing
and
the
result
you
get
is
the
send
works.
So
normally
you
can't
simulate
the
send
or
the
transfer
the
token
transfer
until
after
you
do
the
approval.
The
approval
need
to
show
up
on
train
before
the
blockchain,
like
the
client
they're
using
will
actually
let
you
do
the
the
transfer
with
something
like
multi-call.
We
can
now
do
the
approval
and
transfer
in
simulation
mode,
and
so
we
can
now.
G
You
know
prep
multiple
transactions
in
a
row
and
so
uniswap
could,
for
example,
if
this
got
standardized
instead
of
having
to
prove
and
then
send
me
two
separate
steps,
they
could
potentially
you
know
cue
them
both
up
and
then
and
make
sure
and
then
get
them
both
ready
and
then
submit
them.
G
At
the
same
time,
they
still
have
no
guarantee
of
ordering
other
than
nonsense,
so
you
could
have
something
show
up
between
them
in
terms
of
the
transaction
order,
but
due
to
not
saying
the
approval
show
at
first,
then
the
transfer
will
show
up
second,
but
you
can
send
them
both
to
the
chain
at
the
same
time.
Theoretically,
and
so
the
the
hope
is,
is
that
this
will
allow
you
know
better
again.
G
The
thing
we're
using
for
and
the
things
on
my
mind
is
simulations,
and
so
just
letting
people
see
what's
going
to
happen
before
it
happens.
Right
now,
you
basically
here's
a
simple
example:
I
was
using
a
tool
other
day
that
lets
me.
Let
someone
invoice
me
and
then
I
can
pay
that
invoice,
and
so
the
contract
I
was
calling
wanted
to
want
me
to
do
an
approval
before
I
did
a
transfer
and
the
approval
was
for
more
than
what
I
expected
like
it
was.
G
G
But
in
this
case
it
was
enough
for
me
to
be
satisfied
that
everything
was
was
up
enough
and
our
hope
is
that
we
can
provide
that
sort
of
flow
to
to
more
users
where
they
can
kind
of
cue
things
up
see
what
the
final
outcome
is
and
then
submit
it
all
at
once,
and
then
maybe
at
some
point
in
the
future.
We'll
work
on
standardizing
something
in
the
consensus
layer
where
it
actually
guarantees
autonomicity
between
a
stack
of
transactions.
But
that's
probably
pretty
far
off.
F
Yeah
that
thank
you
for
explanation
that
that's
very,
very
helpful
and
I
think
it's
a
lot
of
value
to
allow
people
to
see
the
outcome
of
a
set
of
transactions
going
in
together
and
what
the
final
outcome
is.
What
I
have
like
if
there
is
I
like
if
I
were
playing
the
The
Devil's
Advocate
a
little
bit,
the
only
thing
is
that
usually
people
will
think
like
not
end.
F
Users
will
think
that
is
either
go
through
or
not
in
this
particular
case,
because
it's
multi-core
there
is
a
conflict,
complex
possibility
that
some
of
them
will
fail
in
in
the
middle
and
then
therefore,
unless
the
consensus
team
provides,
a
consensus
site
provides
us
autonomous,
ethnicity,
otherwise,
we'll
need
the
user
to
be
really
technical
Savvy.
F
To
really
understand
that
simulations
only
tell
what
a
good
day
look
like
and
in
a
bad
day
it
can
be
a
lot
of
variants
on
how
bad
it
could
how
different
kinds
of
weird
awkward
situation
it
could
occurred
in
so
yeah.
That's.
B
G
At
the
moment
we
don't
have
a
way
of
actually
submitting
the
the
batch,
and
so
that's
what
all
you
can
do
is
simulate
and
you
can
simulate
them
all
and
then
you
can
go
back
through
and
do
them
all
again
we're
working
on,
hopefully
making
it
so
you
can
actually
submit
a
batch,
but
again
that's
a
little
further
off
for
us,
but
yeah.
You
are
correct
that
anyone
who
does
use
this
multi-call
definitely
needs
to
be
aware
that
this
is
just
simulation
off
chain
very
useful,
certain
things,
but
not
everything.
G
A
Anybody
else
have
demos,
cool
wallet,
stuff,
they've
been
working
on.