►
From YouTube: PEEPanEIP #24: EIP-2876: Deposit contract and address standard with Jonathan Underwood
Description
EIP: https://eips.ethereum.org/EIPS/eip-2876
Presentation: https://docs.google.com/presentation/d/10LiMhEqxyjY_uQx5gch-nFxljukscrvZICPgnNaH2gw/edit#slide=id.gbd727f6910_0_0
Discussion: https://ethereum-magicians.org/t/eip-2876-deposit-contract-and-address-standard/4504
Add Memo proposal - https://ethereum-magicians.org/t/eip-add-memo-to-transaction-requires-hard-fork/4982
Topics:
1:13 - Introduction
4:50 - Overview
5:04 - Motivation (Wastage of gas in the deposit on exchange)
13:03 - Analogy of how deposit works in exchange
18:00 - Abstract
20:50 - Specification
25:30 - Is this similar to tacking on the optional parameter which are the user id on the end of the address?
27:58 - How does that work, are you setting up a custom address?
30:50 - Security considerations - Don't use SELFDESTRUCT
35:08 - Implementation in Solidity (POC)
37:15 - If SELFDESTRUCT does get removed, will this affect the functionality of the EIP?
38:30 - Another idea (Append the 8byte id to Call Data)
47:19 - Major difference between a non-HF change and an HF change?
51:14 - With this non-HF proposal, are you making the contract that people can actually use or making the change to the EVM?
52:20 - Main argument for making this as a standard whereas we already have EIP-681 in the "Last Call"?
56:08 - What could be the possible reason for the delay in the adoption of this proposal in web3js and EthereumJS?
1:03:37 - Is the reduced Gas cost of this functionality very important for exchanges to succeed in the market?
1:09:45 - Summary
1:11:01 - Changing the link to the Fellowship of Ethereum Magicians?
1:15:00 - Change of status to "Review".
Follow at Twitter:
Jonathan Underwood @junderwood4649 | Pooja Ranjan @poojaranjan19 | Alita Moore @AlitaMoore85
Follow at GitHub
Jonathan Underwood - junderw | Pooja Ranjan - poojaranjan
Follow earlier episodes at 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.gg/tzYmDmF
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
A
This
is
a
standard
track
erc
created
in
august
2020
and
at
present
it
is
in
the
draft
status.
We
are
joined
by
the
author
of
the
proposal.
Janatan
underwood,
welcome
to
the
show.
Let
us
know
a
little
bit
about
you
and
how
you
got
involved
in
the
blockchain
space.
Then
we'll
go
over
with
the
overview
of
the
proposal,
and
we
will
have
a
few
questions
for
you
so
without
further
delay.
Let
me
pass
it
on
to
the
author.
B
Thank
you
so
much
pooja,
I'm
I'm
I'm
very
honored
to
be
on
this.
Show
I've
seen
some
of
your
other
episodes
and
definitely
like
what
you
guys
are
doing
here,
how
I
got
into
the
space.
So
I've
been
in
the
cryptocurrency
space
since,
to
give
you
an
idea,
the
the
first
altcoin
the
first
coin
after
bitcoin
was
name
coin
and
I
got
into
the
space
a
little
bit
after
namecoin
came
in
and
so
probably
about
2012..
B
So
this
was
back
when
vitalik
was
still.
You
know
a
big
bitcoiner,
you
know,
and
he
was
writing
articles
about
bitcoin
and
whatnot.
So
I've
definitely
been
here
a
while
and
and
yeah.
So
just
to
give
you
a
background
of
of
what
I've
been
doing
in
a
professional
sense,
I
started
working
professionally
like
as
a
daytime
job
on
bitcoin
and
related
cryptocurrencies,
since
I
would
say
about
2014
or
15
a
little
bit
after
mount.
B
B
The
network
would
win,
we
would
win,
our
users
would
win.
So
I
basically
made
this
proposal.
The
main
part
is
the
kind
of
the
address
standard.
So
it's
basically
just
saying
you
know
we
want
to
have
some
sort
of
identifier
so
that
we
can
use
one
account
for
multiple
users
and
then
the
deposit
contract
is
just
a
standardized
way
of
of
dealing
with
that.
B
B
B
They
all
have
some
sort
of
feature
where
you
can
put
kind
of
any.
You
know
string
or
any
sort
of
data
extra
data
that
you
want
onto
a
transaction
and
the
way
that
most
exchanges
use
this
is
they
will
give
each
user
a
specific
nonce
or
a
specific
random
data
that
is
linked
to
that
user
of
the
exchange,
and
so
when
they
send
us
ripple
or
they
send
us,
they
send
us
a
stellar
coins
in
that
transaction.
B
If
they
have
the
memo
and
the
destination
tag
that
is
attributed
to
their
user,
then
we
know
when
we
see
that
transaction.
We
can
look
at
the
memo
area
or
the
destination
tag
area,
and
we
can
say:
okay,
this
deposit
was
for
this
user,
whereas
all
of
our
users
are
sending
the
coin
to
a
specific
account.
B
So
the
the
the
way
that
that
kind
of
increases
efficiency
is
that
if
we
had
to
have
a
separate
account
for
each
user,
it
wouldn't
be
that
difficult
from
a
key
generation
standpoint
because
of
all
the
hd
key
libraries
and
whatnot.
It
makes
it
very
simple,
but
the
problem
is:
is
that
we
need
to
for
accounting
purposes.
B
You
know,
move
all
of
those
funds
into
one
kind
of
area
so
that
we
have
them
protected
under
like
a
cold
wallet.
So
in
ethereum,
because
there's
a
lack
of
that
feature,
you
know
we
need
to
have
an
account
per
user
system
and
since
the
accounts
can
be
eoa
accounts
so
accounts
that
are
just
basically
the
hash
of
a
public
key
of
a
private
key
that
someone
has
like,
maybe
from
their
ledger
device
or
whatever
and
contract
accounts.
So
if
you
deploy
a
contract
on
the
network,
it
has
an
account.
B
It
has
an
address
so
with
these
two
different
types
of
of
accounts
that
we
have
that
we
can
give
to
each
user
there's
basically
three
methods
of
doing
a
deposit
system,
the
first
one,
the
first
two
are
using
eoa
accounts.
One
of
them
is
a
hot
wallet
forwarder.
That
is
automated.
So
when
someone
deposits
to
their
address,
we
have
an
automated
hot
wallet
system
that
will
automatically
send
all
those
funds
to
our
cold
wallet.
B
The
second
one
is
an
eoa
account
where
it's
a
manual
cold
wallet
where
basically
every
time,
someone
deposits
you
know.
Obviously,
we
can't
do
it
real
time
because
our
cold
wallet
signers
are,
you
know
higher
ups
in
our
company
and
they
don't
have
all
the
time
to
be
sitting
there
signing
transactions
all
day.
So
we
basically
just
say:
okay,
you've
deposited
to
a
a
cold
address,
so
we
don't
need
to
move
it
immediately.
B
So
whenever
we
need
to
kind
of
refill
our
hot
wallet
for
sending
out
withdrawals,
you
know
maybe
we'll
have
some
some
of
our
cold
wallet
signers
come
in
and
sign
a
couple
thousand
accounts
and
empty
them
out.
You
know
so
because
in
ethereum
there's
only
one
you
can
only
have
one
from
address
per
transaction,
we'll
just
basically
generate
a
couple
hundred
or
a
couple
thousand
unsigned
transactions
and
feed
them
into
our
offline
signing
application,
which
will
then
run
through
all
of
those
and
sign
all
those.
B
And
then
basically
we
have
these
kind
of
spikes
of
tons
of
transactions
that
we
just
flood
onto
the
network,
which
is
you
know,
hundreds
and
sometimes
thousands,
which
kind
of
plug
plugs
up
the
blockchain
quite
a
bit.
Since
one
block,
you
know
only
has
a
couple:
tens
or
maybe
100
or
200
transactions,
and
then
the
last
one
is
each
deposit.
Account
is
a
contract.
B
This
is
a
huge
onboarding
cost
because
we
want
to
create
an
account,
a
deposit
account
for
the
user,
regardless
of
whether
they
have
any
plan
to
deposit.
So
we
need
to
have
a
deposit
address
to
show
to
them,
so
so
that's
kind
of
a
high
cost.
I
mean
there's
a
lot
of
different
proposals
for
how
you
can
deterministically
create
the
address
using
a
create
to
deployment
method.
B
B
So
it's
it's
a
very
difficult
problem,
so
this
is
actually
quite
a
huge
waste
of
gas.
If
you
actually
work
it
out,
I
think
it's
on
the
last
last
slide
yeah.
So
the
automated
hot
wallet
forwarder,
assuming
that
it's
just
a
pure
value
transaction,
the
user,
sends
a
transaction
to
our
hot
wallet.
You
know
deposits
and
then
we
send
another
transaction
to
our
cold
wallet.
So
basically
we're
essentially
doubling
the
amount
of
gas
needed
in
order
for
one
user
to
deposit
onto
a
an
exchange.
B
B
B
And
basically,
what
you'd
be
saying
is
this
transaction
was
initiated
by
the
by
on
behalf
of
or
by
the
user.
That
has
the
tag
you
know
xyz
and
then
that
way,
when
we
see
a
transaction
for
a
deposit
to
our
single
cold
wallet
account,
then
we
could
then
look
at
the
inside
of
that
transaction
which
is
signed,
and
we
know
that
whoever
signed
this
trend,
this
valid
transaction,
wants
whatever
value
that
was
deposited
from
this
transaction
to
go
to
this
account
on
our
on
our
exchange.
B
B
So
if
we
can
reduce
the
amount
of
gas
that
those
guys
are
are
spending
you
know,
even
just
a
reduction
of
a
couple
of
percent
of
the
overall
gas
usage
on
the
network
will
definitely
help
with
the
fee
problems
that
have
been
occurring
recently.
So
waste
of
gas
is
bad
for
the
network,
bad
for
us
bad
for
our
users.
So,
in
order
to
kind
of
help
that
I
created
this.
A
C
B
So
you
say
you
know
whatever
whatever
co,
and
then
you
say,
like
co,
dot,
the
name
of
the
employee
and
then
that
way
when
they
get
the
package
to
the
company
they
go.
Oh
we'll
give
it
to
bob,
whereas
in
ethereum
you're
not
allowed
to
write
care
by,
like
you,
you're
only
allowed
to
send
to
a
building
you're
not
allowed
to
send
to
a
person,
you
can
only
send
to
a
building,
and
so,
if
everyone
sent
their
money
to
our
building,
we
don't
know
which
employee
is
supposed
to
get
this
package.
B
Then
it
costs
a
lot
of
money
because
we
have
to
create
a
lot
of
buildings
even
for
users
who
will
never
send
us
a
package,
and
so
once
we
get
a
package
to
that
building,
we
have
the
the
the
person
in
that
building,
basically
re-label
it
to
our
company
and
then
after
they
send
it
to
us.
They
say,
oh
by
the
way,
this
package
is
for
xyz
like
using
the
phone
or
something
because
we
can't,
we
can't
paste
it
on
the
on
the
whatever.
B
Whereas
if
we
could
just
write
on
the
label
like
this
is
for
bob,
then
everyone
could
just
send
it
to
our
our
main
office
and
we
could
just
look
at
the
label
and
say:
oh,
this
is
for
bob
and
we
could
just
give
it
to
bob
and
we
won't
have
to
like
send
to
you
know
postal.
You
know,
packages
and
whatnot.
So.
B
So
it's
it's
it's
twofold,
so
building
the
building.
Obviously
you
know
it
creates
a
lot
of
co2.
It
costs
us
a
lot
of
money.
It's
it's
really
expensive,
but
also
it's
a
lot
less
efficient,
for
you
know
the
planes
and
trucks
or
whatever
that
take
the
package
to
that.
Building
that
we
created
just
for
accepting
packages
and
then
they
have
to
do
it
all
over
again
and
set
it
on
a
plane
and
put
it
on
the
truck
and
whatever
to
our
our
office.
B
So
there's
also
the
inefficiencies
of
the
actual
sending
of
the
package.
So
when
you
send
a
transaction
in
ethereum,
the
base
is
21k
gas
and
the
more
gas
that
is
used
on
the
network,
the
more
congested
it
gets
and
the
higher
the
fees
are.
So
if
we
can
get
rid
of
all
that
excess
travel
by
going
through
all
these
different,
you
know
buildings
or
whatnot,
and
it
just
went
directly
to
our
office
and
we
could
read
just
a
little
label
on
it.
B
B
You
know
proposals
for
hard
fork
stuff
on
the
table
of
many
everyone
and
to
be
quite
honest
from
what
I've
gathered
by
kind
of
trying
to
get
into
the
ethereum
community
is
no
one
really
cares
about
the
efficiency
of
you
know,
deposit
systems
on
on
centralized
exchanges,
even
though
it's
a
huge
waste
of
gas
and
it
caught
it,
it
uses
up
a
lot
of
gas
on
the
system,
basically,
everyone's
more
concerned
with
other
different.
You
know
problems,
so
you
know
I
kind
of
felt
like
well.
B
In
that
case
you
know
someone
from
a
centralized
exchange
kind
of
needs
to
be
the
champion
for
this
issue,
and
one
of
the
best
ways
to
become
a
champion
for
an
issue
in
in
any
space
is
to
kind
of
start
moving
towards
a
standard.
So
I
started
off
with
this
eep.
This
isn't
it.
This
is
an
abstract.
I
pulled
directly
from
the
eep
and
the
reason
why
I
set
it
up
this
way
was
because
this
this
is
not.
B
This
does
not
require
any
forks
of
the
network
and
it
can
be
done
by
any
exchange
as
long
as
they
follow
this
system
and
if
we
can
get
all
the
wallets
so
like
all
of
the
different
exchanges
that
are
sending
out
transactions
and
all
the
user
wallets
like
ledger
and
metamask
and
whatnot.
If
we
can
get
them
to
support
the
the
addresses
and
to
support
sending
to
this
type
of
interface,
then
we
can
lower
the
gas
cost
quite
significantly
by
using
a
single
contract
per
exchange
where
basically
you're
sending
the
the
package.
B
So,
basically,
a
compatible
deposit
system
can
accept
ethereum
payments
from
multiple
depositors
without
the
need
of
managing
multiple
keys
or
requiring
use
of
a
hot
wallet.
The
wallet
application
can
send
ethereum
to
a
compatible
compatible
deposit
system
in
a
way
that
the
deposit
system
can
differentiate
the
payments
using
an
eight
byte
id
specified
in
the
standard,
and
then
basically
you
know.
B
B
So
basically
you
take
the
base
address.
So
if
I
wanted
to
send
to
this
this
centralized,
you
know
contract
that
each
exchange
has
one
of
the
base
address
will
be
the
address
of
that
contract
and
then
the
nonce
is
just
a
five
byte
random
value
that
is
given
to
each
user,
so
each
user
has
an
in
a
unique
nonce.
So
in
that
case,
you
would
generate
the
the
new
address
format
by
following
this
javascript
function.
Right
here.
B
B
So
this
is
the
main
part
is:
is
here's
how
we
define
the
id
here's,
how
we
define
the
checksum
in
the
id-
and
this
is
how
we
define
the
address
system
that
includes
the
id
so
that
we
don't
accidentally
send
money
to
the
contract
without
the
id
and
then
basically
the
contract
itself
is
just
a
very
simple
interface,
which
is
just
a
deposit
bytes8
id.
It
returns
a
bool
in
the
eip
itself.
C
So,
okay,
if
you
don't
want
me
hopping
in
here
sure
there's
a
http
which
is
like
internet
method
by
the
way,
I'm
just
saying
that
like
because
I'm
trying
to
be
but
anyway
so
like
and
at
the
end
of
the
the
get
method
right.
You
have
optional
parameters
right,
and
so
is
this
similar
to
that,
in
the
sense
that
you're,
basically
just
like
tacking
on
a
couple
optional
parameters,
which
are
the
user
id
on
the
end
of
the
address.
B
Exactly
yeah,
so
in
ethereum,
when
you
send
a
transaction
there's,
a
value
transaction
which
doesn't
have
any
extra
data
and
that's
the
kind
of
the
the
package,
that's
not
allowed
to
write
anything
except
the
address,
and
then
there
are.
There
are
transactions
that
actually
call
methods
of
trend
of
contracts
which
is
basically
you
know.
B
I
don't
know
exactly
how
to
make
the
analogy
to
the
to
the
address
thing,
but
basically
you're
calling
a
a
contract
similar
to
the
way
you
would
call
a
defy
contract
and
say
I
want
to
swap
this
coin
for
that
coin.
Please
do
it
as
I,
as
I
instructed
you're,
basically
doing
the
same
thing,
except
instead,
what
you're
doing
is
you're
calling
to
our
centralized
contract.
B
So
so,
basically
it's
it's
like
what
you
said
where,
if
you
add
some
sort
of
like
parameters
at
the
end,
you're
telling
google.
Oh
when
you
open
up
this
page.
I
also
want
you
to
sort
it
by
xyz,
and
so
you
might
have
something
like
question:
mark
sort,
equals
item
name
and
then,
when
you
open
up
the
page,
you
don't
need
to
click
any
buttons.
B
It's
just
sorted
by
item
name
as
soon
as
you
open
the
page,
because
when
you
made
that
get
request
to
the
google
server
they'll
be
like
oh
okay,
he
wants
us
to
return
the
data
with
it
sorted
in
this
way,
so
it's
similar
to
that,
except
instead
of
using
a
server
to
to
query
to
you're
you're
querying
to
a
contract
that
is
on
the
on
the
on
the
network.
So
yeah
your
your
analogy
is
very,
very
good
and.
C
So,
in
this
case,
would
would
that
be
obfuscating?
Sorry,
would
that
be
avoiding
like
the
necessity
of
like
a
building,
or
would
that
be
or
would
you
still
require
that
because,
like
the
the
transaction
address
right?
Okay,
so
if
I'm
understanding
it
properly,
the
transaction
address
would
include
the
user
id
right,
and
so,
in
that
case,
how
does
that
work
though,
because,
like
are
you
setting
up
a
a
custom
address.
B
Yes,
so
so
in
the
analogy
we
did
before
each
user
gets
a
contract,
so
each
user
has
a
building.
So
in
this
in
this
eip,
which
the
reason
why
we're
doing
this
is
because
it
doesn't
require
a
hard
fork,
we're
creating
a
separate
building,
but
it's
only
one
building
per
company,
so
each
company
will
have
their
main
building
and
then
they'll
have
a
e2876
building
and
then
that's
it.
So
they
don't
need
to
make
one
building
per
user.
B
They
just
need
to
make
one
extra
building,
so
every
company
will
have
two
buildings
and
then
that
one
building
will
basically
say.
Okay,
when
you
send
a
package
to
us,
you
are
allowed
to
add
this
extra
data
in
a
specific
format
and-
and
we
will
accept
it,
whereas
other
you
know,
buildings
on
in
in
the
world
won't
accept
that
this
special
building,
because
it's
a
smart
contract
and
it's
allowed
to
make
any
rules
and
stipulations
on
extra
extra
data
that
is
included
in
the
package.
It
can
make
any
stipulations.
B
B
This
is
bad
and
then
so,
when
they
send
a
package
to
us,
it
will
have
that
extra
data
which
will,
let
us
know
which
user
this
deposit
is
on
behalf
of
and
then
also
we'll
be
able
to
tell
the
guy
who
set
who
actually
delivered
the
package
to
us
would
be
like.
Okay,
this
looks
good
or
no.
This
is
bad,
you
know.
So
that's,
basically
all
this.
B
This
interface
interface
is
saying
so,
instead
of
making
one
building
for
each
user
we're
making
one
extra
building
so
instead
of
having
one
building
we'll
have
two
buildings,
but
you
know
it's
better
than
having
one
plus
the
number
of
user
buildings.
So
we're
kind
of
increasing
the
efficiency
in
that
way.
B
It's
all
good,
okay,
so
security
considerations,
there's
one
big
one,
that
is,
that
needs
to
be
considered
it's
in
the
eep.
It's
don't
use
self-destruct,
so
a
lot
of
people
they
like
to.
They
would
like
to
have
some
sort
of
kill
method
where
you
will
self-destruct
the
contract
when
you're
done
using
it,
but
with
exchanges
you
never
know
when
some
huge
whale
will
send.
B
You
know
500
million
ether
or
whatever
to
one
of
your
deposit
addresses,
which
is
why
we
want
to
keep
deposit
addresses
cold
if
we
can.
So
the
problem
is:
is
that
if
you
self-destruct
the
deposit
contract
after
you're,
like
let's
say
you
shut
down
the
exchange
users
who
used
to
use
the
exchange
might
still
have
their
deposit
address?
B
You
know
set
into
some
sort
of
like
you
know,
saved
database
or
maybe
they'll
have
like
some
sort
of
contacts
list,
or
something
or
they'll
have
it
written
on
a
post-it
note,
or
I
don't
know
so.
What
happens?
A
lot
of
times
is
we'll
we'll
switch
the
the
wallet
of
our
exchange.
Like
let's
say
we
have
to
update
the
wallet,
and
so
we
have
to
change
all
the
deposit
addresses,
and
so
we
tell
the
users
we
say:
okay,
your
deposit
address
is
going
to
change
on
this
date.
B
Please
update
any
wallets
or
any
like
contact
information
or
whatever,
where
you
have
your
deposit
address
saved
in
and
a
lot
of
users.
Don't
do
that.
So
as
soon
as
we
switch
over
to
the
new
wallet,
we'll
still
have
users
depositing
into
the
old
wallet
for
like
months
and
months
after
we've
switched,
and
even
if
we
stop,
you
know
detecting
those
deposits
and
we
tell
the
user.
B
You
know
if
you
deposit
to
the
old
wallet,
we
will
not
credit
you,
then
what
will
happen
is
they'll,
send
a
bunch
of
money
and
then
they'll
be
like
well.
Why
am
I
not
getting
credited
and
then
they'll
send
us
a
ticket
to
our
support
team
and
they'll
threaten
us
with
the
lawsuit,
if
we
don't
give
it
to
them
and
blah
blah
blah
blah,
and
it's
just
a
lot
easier
on
us
to
go
in
there
manually
check
and
go
okay.
They
deposited
the
old
address
will
credit
their
account
manually,
but
they
still
keep
doing
it.
B
So
if
you
self-destruct
the
contract
and
then
if
you
didn't,
do
it
in
a
deterministic
way
like
using
create
two,
you
cannot
create
the
same
contract
at
the
same
address,
so
it
would
be
impossible
because
the
the
contract
address,
if
you
don't
use,
create
two-
is
based
upon
the
the
nonce
of
the
account
that
created
the
the
contract
and
the
the
address
of
that
contract.
So
you
would
never
be
able
to
create
the
same
contract
with
the
same
address
ever
again.
B
So
there
are
ways
to
get
around
that
you
could
use
like
a
proxy
factory
that
would
basically
deploy
the
the
deposit
contract
for
you,
and
that
way
you
would
be
able
to
kind
of
redeploy
the
same
contract
again,
but
it
would
be
a
lot
less
efficient
and
it
would
be
very
difficult
to
manage
and
one
slip
up
you
would.
You
would
have
no
way
to
to
re,
deploy
the
same
address
or
the
same
contract
on
that
same
address,
so
in
general.
B
So
you
would
need
to
do
something
like
that,
so
that
it
would
basically
reject
any
deposits
from
people
who
tried
to
send
after
the
the
exchange
closes
down
or
whatever
that
that's
the
only
real
security
consideration
that
needs
to
be
kind
of
taken
from
an
exchange
deposit
perspective,
so
other
than
that.
It's
really
just
a
simple
protocol.
It's
just
an
interface
of
the
contract
and
a
new
address
method
with
a
checksum,
and
so
basically
the
implementation
in
a
solidity
contract
is
very
simple.
B
I
have
a
proof
of
concept
which
is
linked
in
the
eep
itself,
but
it's
so
small.
It
just
fits
on
the
slide.
So
literally,
it's
just
the
the
contract
is
literally
just
a
deposit
method.
An
internal
checksum
match
method
which
we
use
in
the
require
here
to
make
sure
that
the
checksum
matches,
and
then
we
emit
an
event
which
is
deposit
bytes
and
you
went
the
amount
so
that,
basically,
we
can
look
at
these
events
on
the
event
log
and
then
we
can
use
that
as
our
deposit
system.
B
Now.
Obviously,
this
is
not
totally
secure.
You
might
want
to
check
the
constructor
address
to
make
sure
it's
not.
You
know
the
zero
address
or
anything
like
that.
You
might
want
to
add
a
couple
more
functions
and
whatnot,
but
you
know,
obviously
you
want
to
follow
the
eip
standard
because
there's
a
lot
of
stipulations
like
you
can't
have
a
unprotected.
You
know
fallback
function
that
would
allow
value
transactions,
so
we
want
to
reject
all
value
transactions
and
and
require
everyone
to
use
this
kind
of
deposit
method
here.
B
So
this
is
just
a
very
simple
implementation.
If
you
have
any
questions,
you
can
ask
them
on
the
github
itself
as
an
issue,
or
you
know,
contact
me
on
twitter
or
you
know,
my
email
is
in
my
github
account.
You
can
send
me
an
email,
whatever
you
feel
like,
although
email
is
probably
less
I'm
sure
punja
can
attribute
to
my
lack
of
checking
email.
So
so
email
might
not
be
the
best
way
to
contact
me.
You
know
so,
but
yeah.
B
No,
so
it
won't
affect
this
eip
at
all.
There's
another
method
of
doing
deposits,
which
you
basically
create
a
contract
that
self-destructs
itself
in
the
constructor
so
like
it
literally
deploys
itself
and
then
kills
itself
all
in
the
same
transaction
and
by
doing
that,
because
when
you
do
self-destruct,
you
are
refunded
the
gas
of
the
deployment
of
that
contract.
B
So
so,
basically
it
you
know
you're
kind
of
you're,
you're
spending
the
gas
to
deploy
the
contract
and
then
you're
doing
some
logic
like
transferring
money
from
the
the
address
to
wherever
and
then
you're
you're,
basically
committing
sep
and
killing
yourself.
I
don't
know
of
any
exchanges
that
actually
use
that
method,
so
I
don't
think
many
people
are
affected,
but
this
eep
itself
is
not
affected
at
all.
B
B
But
it's
quite
a
big
change
and
it's
kind
of
iffy,
so
I'll
go
ahead
and
talk
about
the
idea.
So
basically
it's
you
would
just
keep
the
address
format,
so
the
address
format
and
the
eight
byte
id
format
and
how
the
checksum
works
and
whatnot
that
would
stay
the
same.
But
basically
you
would
say:
okay,
we
don't
even
need
a
deposit
contract.
B
What
we
would
say
is
if
you
get
an
address
with
this
extra
8.8
byte
id
data.
What
you
should
do
is
you
should
append
those
eight
bytes
to
the
end
of
the
call
data.
So
what
is
the
call
data?
The
call
data
is
basically,
whenever
you
call
a
contract,
you
create
some
data
that
you
add
to
a
place
called
the
call
data.
So
if
I'm,
if
I'm
sending
you
an
erc20
token,
I'm
calling
the
transfer
method
on
that
erc20
contract.
B
So,
in
order
to
call
that
method
I
have
to
create
what's
called
a
call
data
which
has
the
four
byte
method
id
and
then
the
the
the
parameter
data
which
is
similar
to
that
kind
of
you
know,
get
parameters
that
you
were
talking
about
with
http
requests
so
like
question,
mark
blah
blah
blah
equals
blah
blah
blah
and
blah
blah
blah
blah.
So
in
solidity,
which
basically
translates
solidity
language
into
actual
evm
byte
code
that
lives
on
the
network.
B
B
B
But
in
more
recent
versions
it
was
apparent
and
it
actually
broke
some
contracts,
because
what
happened
was
a
lot
of
contracts
were
relying
on
the
fact
that
that
the
that
any
contract
compiled
by
solidity
would
not
actually
check
to
make
sure
that
the
call
data
is
a
specific
length
right
now.
If
we
were
to
adopt
this
this
new
idea,
we
are
relying
on
the
fact
that
that
the
solidity
compiler
does
not
revert
when
the
call
data
is
too
long,
which
is
dangerous,
because
there's
no
guarantee
that
that
will
always
be
true.
B
So
that's
the
big
huge
bad
bad
one.
If
we
were
to
kind
of
like
add
this
to
the
eep,
we
would
almost
kind
of
need
a
verbal
confirmation,
at
least
from
the
main
solidity
dance
to
be
like
you're,
never
going
to
make
it
so
that
a
compiled
track
contract
will
check
the
the
to
make
sure
that
the
call
data
is
too
long
or
not
right.
You're
never
going
to
do
that
right,
because
if
they
do
do
that
and
then
there
are
some
contracts
that
are,
you
know
compiled
with
this
new
version.
B
Then,
if
there
was
a
erc20
or
something
that
was
that
was
kind
of
created
with
that
new
solidity
version,
we
as
an
exchange
would
not
be
able
to
deposit
to
that
using
this
system
because
it
would
it
would,
it
would
basically
revert
so
what
you
would
do
is
you
take
the
eight
bytes
and
you
just
append
it
to
the
call
data.
So
if
you
are
sending
just
a
normal
value
transaction
of
ether,
then
the
call
data
for
a
normal,
just
a
normal
ether
send
is
empty.
B
So
there's
just
no
call
data
because
you're
not
calling
a
contract
you're
just
sending
ether,
but
if
you're
sending
ether
you
can
actually
have
any
call
data.
You
want
it'll
increase
the
gas
usage
by
a
little
little
bit
depending
on
the
length
of
the
call
data,
but
you
can
add
call
data
and
it'll
just
get
ignored
by
the
network.
So
it's
kind
of
like
a
memo.
B
No
one
is
relying
on
that.
So
it's
not
a
backwards,
incompatible
change
and
then
it
turns
out
that
a
bunch
of
exchanges
were
relying
on
it
and
then
it
just
gets
all
messy.
So
the
good
parts
is
it's
totally
backwards
compatible
with
all
erc
tokens.
So
if
you
sent
us,
you
know
bat
or
any
you
know
token
or
whatever.
All
you
have
to
do
is
tag
on
the
extra
eight
bytes
to
the
end
of
the
transfer
method,
call
data
and
then
solidity
won't
even
see
it
it'll
just
ignore
it.
B
But
when
we
look
at
that
transaction
we
can
actually
pick
up
the
transaction.
When
we
see
the
deposit
and
then
we
can
look
at
the
call,
data
make
sure
that
it's
longer
than
it
needs
to
be
and
make
sure
that
it
it's
exactly
eight
bytes
longer
than
it
needs
to
be,
and
then
we
can
take
that
last
eight
bytes
and
treat
it
as
the
id
and
then
like
check
the
checksum,
and
you
know,
take
the
five
byte
notes
and
look
it
up
up
on
our
table.
Make
sure
we
know
who
the
user
it
is.
B
B
You
could
technically
create
another
eep
that
would
make
erc
20
tokens
in
the
future
compatible
with
this
8
byte
id
standard,
but
you
would
not
be
able
to
do
it
for
any
erc20
token
that
has
already
been
deployed,
but
using
this
method
method
we
would
be
able
to
support
any
erc20
tokens
using
this
method
as
long
as
they
were
not
compiled
in
such
a
way
where
they
send
an
error.
If
the
call
data
is
too
long,
so
it
also
doesn't
require
any
deployed
contracts
on
the
exchange
side.
B
So
in
the
building
analogy
we
don't
need
to
create
any
extra
buildings.
We
just
have
one
building
and
it
doesn't
increase
gas
by
much.
So
if
you're,
sending
a
value
transaction
in
ether
and
you're,
just
adding
eight
bytes
of
just
random
data
into
the
call
data,
it
doesn't
increase
the
gas
usage
by
that
much
21k
is
the
base
and
I
think
it
only
adds
a
few
gas.
B
We
can
support
any
erc20
blah
blah
blah,
and
this
will
basically
act
as
like
a
memo
without
a
hard
fork.
Now,
if
we're
gonna,
do
that,
then
obviously
it's
like
okay.
Well,
we
need
complete
consensus
from
the
community
to
get
this
kind
of
undefined
method
through
well.
In
that
case,
why
not
just
do
a
hard
work
if
we
need
consensus
from
everyone,
so
it's
kind
of
a
chicken
and
egg
problem.
If
we
were
to
add
this
to
the
eep
it
it,
it
increases
the
hurdle
it
increases.
B
The
barrier
of
entry
for
this
to
be
adopted
similar
to
the
the
hurdle,
would
would
be
if
we
proposed
a
hard
fork
idea.
So
that's
one
of
the
reasons
why
this
idea
wasn't
really
adopted
or
still
hasn't
been
adopted,
I'm
still
kind
of
trying
to
figure
out
if
there's
a
better
way
to
kind
of
do
this,
so
that
is
the
end
of
the
the
kind
of
presentation
so
bitbank
bringing
value
to
the
world
with
bitcoin
technology.
B
B
Now
the
reason
why
adding
a
memo
space
would
change
the
rules
of
the
blocks
is
because
currently
any
miner
that
has
mining
software,
that
verifies
ethereum
blocks
and
then
mines
a
new
block.
They
have
rules
on
which
how
how
they
can
parse
the
block
and
parse
the
transactions
and
understand
the
transactions.
B
Now,
if
we
add
a
memo
or
a
destination
tag
to
the
transaction.
Currently
there
is
no
space
for
that.
So,
if
we
add
that
space
any
program
that
tries
to
parse
that
transaction
and
subsequently
parse
any
block
containing
that
transaction
will
basically
choke
on
it,
so
they
will
try
to
parse
the
transaction
using
the
old
rules
that
they
know
and
because
there's
this
extra
data
that
they
don't
understand,
they
won't
just
ignore
it
and
they
will
just
say:
okay.
B
This
is
an
invalid
transaction,
so
this
block
is
invalid,
whereas
any
software
that
updates
with
that
support
the
sport
of
that
memo
destination
whatever
they
will
see
it
as
a
valid
block.
So
anytime,
you
have
miners
on
the
network
or
validators
on
the
network,
seeing
the
same
block
as
valid
and
invalid
based
upon
what
type
of
what
version
of
software
they're
running.
That
is
called
a
hard
fork.
B
So
if
the
to
address
is
not
a
contract
and
it's
just
an
an
eoa
account
just
a
normal
public
key
account,
then
no
contract
gets
run,
so
the
call
data
is
basically
ignored,
but
because
it's
the
rule
of
ethereum
that
any
transaction
can
have
call
data,
it
is
not
invalid
to
add
call
data
to
a
non-contract
call,
and
it's
not
invalid.
For
most
contracts
to
add
call
data
at
the
end
of
the
call
data-
that's
supposed
to
be
there
but,
like
I
said
you
know
that
could
change
for
the
contracts.
B
It
could
also
change
for
the
network.
If
someday.
Let's
say
we
do
a
hard
fork
for
proof
of
stake
and
during
that
hard
fork
they
decide.
Oh
yeah,
if
you're
not
calling
a
contract-
and
you
have
call
data,
we
should
throw
an
error.
You
know
if
they
decide
to
do
that.
Then
anyone
using
this
this
new
idea
that
I
proposed
would
be
out
of
luck
because
it's
undefined
effect
behavior,
so
yeah.
C
B
Yeah,
so
you
are
basically
just
making
a
a
contract
that
people
can
use
so
we're
defining
the
the
method
in
which
you
would
use
that
contract
by
this
interface
and
then
we're
defining
the
method
in
which
you
will
tell
the
wallet,
because
the
wallet
is
essentially
the
thing
that
is
actually
creating
the
data
that
calls
into
the
contract.
So
the
wallet
needs
to
know
what
that
eight
byte
id
is
in
order
to
call
this
method
and
the
way
that
we
tell
the
wallet
software.
B
A
Okay,
yeah.
I
have
a
few
questions
for
you,
but
before
that
I
want
to
mention
that
I
find
this
proposal
interesting
and
the
topmost
reason
is,
of
course,
the
gas
saving
part
as
you
mentioned,
but
it
is
also
interesting
because
it
is
proposed
by
the
chief
bitcoin
officer
of
an
exchange
dominant
on
bitcoin
technology.
B
Yeah
so
681
url
format
for
transaction
requests
yeah.
So
the
reason
why
this
is
not
kind
of
used
is
primarily
because
when
I
looked
at
this
proposal,
this
was
actually
in
the
pull
request
where
I
created
the
eep
itself.
Someone
mentioned
this
this
proposal
and
one
of
the
reasons
why
I
made
my
separate
proposal
was
because
number
one.
B
This
is
a
kind
of
very
complicated
scheme
that
is
generalized
for
all
types
of
contracts,
so
this
kind
of
scheme
would
basically
you
know
it's
it's
very
complicated
and
it's
it's
very
difficult
to
implement,
for
you
know
different
wallets
and
from
my
knowledge
I
don't
know
of
any
major
wallets
that
support
the
standard
I
mean
there
might
be
some,
but
I've
never
really
seen
I've.
I've
never
really
seen
any
wallets.
That
kind
of
you
know
parse
this
type
of
address
format,
kind
of
like
url
format
that
that
is
in
681.
B
So
basically,
I
just
took
the
most
simple
address
format
that
I
could
think
of
and
basically
added
in
a
checksum
which
you
know
looking
at
this.
I
if
I
remember
correctly,
there's
no
checksum
here.
So
it's
basically
just
or
maybe
maybe
there
is
a
checksum.
I
remember
looking
at
this
when
I
was
when
I
was
told
about
it
when
I
made
the
pull
request
and
there
was
no
checksum,
so
that
also
kind
of
increases.
B
What
I
was
talking
about
before,
where
users
tend
to
butterfingers
their
stuff,
a
lot
where,
like
they'll
copy,
some
of
it
and
not
all
of
it
or
they'll,
mistype
it
or
they'll.
You
know
only
copy
the
first
20
letters
out
of
24
letters
or
something
like
that.
So
having
kind
of
this
method
where,
if
I
accidentally
don't
copy
one
of
these
key
values,
then
it
might
cause
an
error
or
it
might
do
something
whatever.
Whereas
if
we
have
a
very
simple
address
that
has
a
check
sum
in
it,
then
we
can
say
to
the
user.
B
This
checksum
doesn't
match
so
you're,
probably
miscopying
it.
So,
as
far
as
the
address
format
is
concerned,
I
mean
this
is
very
versatile
and
it's
very
generalized
so
that
it
can,
you
can
use
it
to
call
any
contract
on
any
chain
which
is
very
great
for
for
many
many
use
cases,
whereas
the
eep
that
I
created
is
only
for
one
specific
use
case,
which
hopefully
will
make
it
easier
to
adopt.
A
A
That
brings
to
my
next
question
on
implementation.
I
found
two
separate
issues
created
for
implementation
in
web3.js
and
ethereum
js
for
proposal,
and,
if
I
understand
correctly
for
ethereum
js,
there
is
some
visibility
issue
and
it
was
closed.
However,
the
vert3gs
issue
was
marked
staying
so
curious
to
know
your
thoughts
on
the
possible
reason
for
delaying
the
implementation.
Could
it
be
the
bandwidth
or
priority
or
complexity
of
the
code,
or
maybe
you
know
in
lack
of
some
tools,
because
I
believe
there
were
some
tools
available
for
other
similar
proposals,
eip681
and
eip381.
B
Possible
reason:
yeah
so
after
discussing
with
web
3
and
and
the
other
guys
at
ethereum,
js
and
whatnot.
Basically,
their
stance
was
that
they,
they
do
not
want
to
add
any
code
from
a
specific
eip
and
specific
eips
should
have
their
own
library
and
then
wallets
like
wallets,
who
create
wallet
applications
can
then
you
know,
call
that
that
extra
eip
library
into
their
application
and
then
use
that
separately.
So
it's
not
actually
in
the
the
web3
ecosystem
whatnot
now
this
is
not
a
difficult.
B
This
is
not
a
difficult
thing
to
implement
and
I
mean
I
have
been
planning
on.
You
know
officially
creating
a
np
npm
package
for
a
while
now,
but
to
be
quite
honest
after
going
through
ethereum
magicians
and
going
through
the
different,
the
different
libraries
and
trying
to
kind
of
get
it,
you
know
adopted
I've
kind
of
gotten
the
feeling
and
the
sense
that
most
people
don't
really
understand
the
problem
statement
of
this
eep,
because
99
of
ethereum
developers
are
not
exchanges.
B
They
don't
work
at
exchanges,
they
work
on
whatever
d5
protocol
or
whatever,
and
they
get
paid
in
whatever
token
or
ico
or
whatever.
So
they
they
don't
really
care
about
the
the
pro
or
maybe
I
it
would
be
easier
to
say
they
don't
have
an
understanding
of
the
problem.
Maybe
I
didn't
explain
it
better
well
enough
and
I'm
not
championing
it
well
enough.
B
So,
basically,
because
I
created
this
eip
to
kind
of
move
this
issue
forward,
and
then
I
got
a
lot
of
resistance
and
a
lot
of
indifference
where
people
didn't
really
care
that
much
so
I
thought
that
the
adoption
of
the
standard
is
going
to
be
a
very
long
process,
and
so
we
needed
some
solutions
for
our
to
kind
of
decrease
gas
costs
and
also
to
be
able
to
support
different.
You
know
erc20
and
things
like
that.
We
needed
that
sooner
rather
than
later.
B
So,
in
addition
to
this
eip
that
that
I've
created
also,
I
also
created
a
exchange
deposit
contract
which
actually
doesn't
use
this
this
this
standard,
but
it
actually
is
based
on
you
know
if
this.
If
this
eip
does
not
get
adopted,
then
what
is
the
cheapest
gas
cost?
You
know
deposit
system
that
you
could
possibly
create
on
ethereum.
B
Can
you
see
the
window
that
I
have
open?
Yes
yeah
so
on
our
big
bank
github,
we
have
a
repository
called
exchange,
deposit
contract
and,
basically,
what
it
does
is
it
deploys
a
contract
per
user,
but
we
got
it
as
cheap
as
possible,
so
each
deploy
of
the
contract
is
around
60k
60k
gas,
which,
for
a
contract
deploy,
is
really
really
cheap.
B
The
way
that
we're
actually
making
that
very
cheap
is
that
we
actually
have
the
the
proxy
for
the
users
is
written
in
evm
bytecode
directly,
and
we
have
that
the
bytecode
is
explained
in
a
huge
comment
at
the
bottom.
We
actually
explained
how
the
byte
codes
actually
work
and
by
by
coding
it
in
ethereum
byte
code,
we
saved
a
ton
of
gas,
so
each
each
user
contract
is
is
basically
you
know,
60k
gas
or
so,
and
this
whole
contract
like
system.
This
system
was
actually
audited
by
consensus.
B
So
on
the
consensus
website,
you
can
actually
see
the
public
audit
of
this
contract,
which
you
know
this
is
basically
kind
of
like
worst
we're
making
the
best
of
the
worst
case
scenario.
So
if
the
eip
never
gets
adopted,
then
we'll
just
use
this
contract,
which
we
we
created
and
it's
the
least
amount
of
gas
that
we
could
possibly
create
if
it
starts
getting
adoption,
this
contract
can
actually
be
modified
to
support
the
eep
that
I
created
after
the
fact
by
using
the
implementation
address,
which
was
also
audited
by
the
by
consensus.
B
So
we
have
all
of
these
things
and
we're
making
them
open
source
so
that
our
competitors
can
use
them
and
that
we
can.
Basically,
we
want
more
exchanges
to
use
this,
because
more
exchanges
using
this
will
lower
the
amount
of
gas
used
by
exchanges
which
will
lower
the
fees,
which
will
be
good
for
us
and
good
for
the
network
and
good
for
our
users.
B
C
B
B
The
only
time
they
ever
charge
you
money
is
when
you
send
money
out
of
the
exchange,
whereas
the
exchanges
actually
spend
network
fees
to
forward
like,
like,
I
said
in
the
in
the
worst
case
scenario,
if
they're
forwarding
packages
from
that
building,
you
know
they
have
to
pay
the
money
to
create
the
building.
They
have
to
pay
the
money
to
forward
the
package
from
that
building
to
the
their
main
building,
so
they're
paying
a
lot
of
stuff
that
is
unrelated
to
withdrawals,
so
the
sendouts.
B
So
I'm
not
going
to
say
exactly
how
much
we
spend,
but
you
know
on
a
monthly
basis,
I
would
say
easily
like
even
when
there's
not
a
ton
of
like
high
fees
like
right
now.
It's
it's
really
high
fees
because
of
the
d5
boom
and
whatnot.
But
even
when
the
the
fees
weren't
that
high
I
mean
you
could
easily
spend
you
know
ten
thousand
dollars
or
fifty
thousand
dollars
a
hundred
thousand
dollars
if
the
the
fees
get
get
high
enough.
B
We
do
make
some
money
back
on
that,
although
recently
we
actually
are
we're
not
taking
enough
so
we're
losing
money
on
every
ethereum
withdrawal
and
then
we're
also
losing
even
more
money
on
each
deposit
because
we
have
to
you
know
forward
that
and
spend
the
fees
to
for
that
and
the
way
that
we
kind
of
you
know
make
the
difference
is
we're
making
money
on
btc
or
you
know,
other
smaller
altcoins
we're
making
money
on
the
on
the
withdrawals
for
those
so
we're
kind
of
balancing
it
out.
So
a
lot
of
our
users.
B
We
can't
like
change
it
every
day.
It's
just
a
set
fee
that
maybe
once
every
couple
months
we
announced
that
we're
going
to
change
it
a
little
bit,
but
we
can't
change
it.
Every
five
minutes
to
you
know
match
with
the
network
so
right
now
we're
losing
money
on
every
withdrawal
with
with
with
ethereum,
and
we
have
to
make
that
up
by
getting
money
gaining
money
on
the
withdrawal
fees
for
other
coins.
You
know
so
it
it's
a
difficult
problem.
B
So
I
think,
if,
if
we
had
this
this
this
or
even
better
memo
or
destination
tag
added
as
a
as
a
as
a
hard
fork,
it
would
definitely
increase
or
decrease
the
barrier
of
entry
for
people
trying
to
get
into
the
space
of
accepting
deposits
from
multiple
users,
whatever
that
business
may
be,
it
might
not
even
be
an
exchange.
In
fact,
one
of
my
good
friends
nicola
dorier
he's
the
main
guy
behind
btc
pay
server,
which
is
a
merchant
platform.
A
lot
of
ethereums
have
been
like.
B
Well,
we
want
you
to
support
ethereum
so
that
we
can
use
btc
server
because
it
supports
a
bunch
of
old
coins.
It
supports
dogecoin
and
all
those
things.
So
we
want
you
to
support
ethereum,
but
when
you
know-
because
I
I
know
a
lot
about
ethereum,
he
asked
me
about
it
and
I
said
well
the
only
way
to
really
do
that
is.
If
you
have
a
a
bunch
of
it's
either
on
your
merchant
server
and
every
time
someone
creates
an
invoice
to
like
buy
a
product.
B
You
don't
even
know
if
they're
going
to
pay
it,
but
you
already
have
to
deploy
a
contract
to
mess
around
with
it.
So
he
was
like
yeah
no
one's
going
to
use
this,
even
if
we
make
it.
So.
If
there
was
a
memo
destination
tag
feature,
then
you
could
have
these
types
of
merchant
applications
that
are
easy
to
use
in
a
non-custodial
manner.
So
it's
not
just
centralized
exchanges,
it's
it's
in
general,
accepting
deposits
from
multiple
people
or
multiple
invoices
or
multiple
shopping
carts
or
whatever,
in
a
way
that
doesn't
waste
gas.
B
C
I
mean,
if
they're
on
one
slide
right,
this
really
small
change
and
then
what
you?
What
what
I'm
hearing
is
that
it's
gonna
make
the
you
know
defy
or
the
application
of
ethereum
much
more
economical
because
you
don't
have
to
at
least
for
well.
It
just
makes
certain
applications
possible
versus
they
are
not
before,
and
that
sort
of
is
important
because
it
means
an
increased
value
in
ethereum.
I
would
say
because
the
the
infrastructure,
the
ecosystem
grows
and
that's
ultimately,
what
gives
our
or
gives
ethereum
value.
D
A
The
first
thing
that
I
would
like
to
mention
is
about
the
discussion
tooling,
like
the
present
that
suggests
the
discussion
link
is
at
github
repository,
I
believe,
of
the
author
of
you,
but
recently
the
process
improvement
group.
The
eipip
have
been
encouraging
to
move
the
discussion
link
to
the
fellowship
of
ethereum
magician.
A
B
B
I
mean
I
I
I
changing.
The
link
is
not
that
big
of
a
deal,
but
you
know
to
be
honest:
I've
only
ever
gotten
really
one
issue
on
the
on
the
github
issue
itself
and
the
the
thread
on
the
ethereum
magicians
is
pretty
much
dead.
So
I
mean
you
know.
If,
if
it's
visibility,
that's
the
concern,
I
think
it
would.
You
know
it
would
already
be.
There
would
be
comments
on
one
or
the
other
if
they
were
seen
on
either
one
of
them
so
definitely
down
the
road.
B
If
that's
kind
of
the
standard
I
I
would
definitely
look
into
changing
the
link
to
ethereum
magicians.
But,
to
be
quite
honest,
I
mean
right
now
I've
just
kind
of
prioritized
the
exchange
deposit
contract
that
I
just
showed
you
primarily
because
after
kind
of
poking
around
a
bit
and
creating
that
that
thread
that
you
you
mentioned
on
ethereum
magicians
and
then
I
also
created
another
thread
about
adding
a
tag
or
memo
thing
to
the
the
blockchain
and
not
really
any
responses.
B
B
I
think
that
definitely
moving
this
eep
forward
will
definitely
help
in
the
community
at
large,
and
I
I
I
do
think
that
I
should
champion
it
eventually
and
kind
of
start
pushing
a
little
bit
more
specifically
towards
different
parts
of
the
of
the
community.
But
right
now
I
just
don't
really
have
the
time.
I've
been
really
busy
with
work
so
but
yeah.
B
Definitely
if,
if
you
or
anyone
watching
this,
has
any
any
ideas
on
how
we
can
kind
of
push
adoption
of
this
eep
or
maybe
push
a
conversation
forward
for
the
next
hard
fork.
Because
I
mean
it's
not
an
end
or
I
mean
we
could
have
this
eep
be
supported
on
all
wallets
and
then
also
after
the
fact
create
a
memo
or
a
destination
tag,
and
then
just
everyone
could
switch
that
after
the
fact
that
that
would
be
a
better.
So
I
mean
I'm
just
pushing
all
three
of
these.
B
At
the
same
time
and
seeing
what
sticks
we've
got
the
exchange
deposit
contract,
which
is
mit,
licensed
it's
audited
by
consensus.
Anyone
can
use
it
adopt
it
if
they
want
the
eip,
which
anyone
can
adopt
it
if
they
want
hopefully
I'll
champion
it
somehow,
and
maybe
we
can
get
more
people
to
kind
of
support
it
more
wallets
to
support
it,
and
then
you
know
down
the
road
if
we
can
convince
people
that
this
is
something
that's
good
for
the
network.
B
Maybe
we
could
get
a
hard
fork
in
there
so
yeah,
that's,
I
I'm
definitely
cool
with
moving
the
link,
I'm
cool
with
anything.
If
anyone
wants
to
create
a
pull
request
on
any
of
these
repositories
or
the
the
repository,
and
they
want
to
help
me
with
the
seat.
You
know
I
could
definitely
add
them
as
a
champion
and
they
can
help
me
kind
of
move
move
this
this
issue
forward.
If
they
feel
like
it's
an
issue
that
they
care
about.
A
Yeah,
well,
I
mean
like
when
you
are
creating
a
core
proposal.
As
you
mentioned
about
the
hard
fork,
I
am
very
sure
that
it
is
going
to
get
a
required
attention,
but
in
the
meantime,
the
proposal
itself.
It
is
well
structured
and
is
already
merged
as
drop.
So
I
think
it
is
good
to
move
forward
to
the
next
status
of
the
state
at
the
standardization
process.
A
A
It
was
a
wonderful
presentation
and
I
hope
it
gets
the
attention
of
a
wallet
api
providers
and
be
implemented
in
the
major
projects
soon
on
that
note
for
our
youtube
viewers,
if
you
have
any
further
question
on
this
proposal
or
any
other
that
we
recorded
earlier,
you
may
leave
a
comment
to
us
from
the
author.
We
are
gonna,
provide
the
twitter
and
github
handle
of
the
author
in
the
description
section,
along
with
the
link
to
the
presentation
and
other
resources
available
for
this
proposal.
A
Do
let
us
know
how
you
like
this
episode
and
which
erb
would
you
like
to
see
in
future?
Your
feedback
is
important
to
us
and
we'll
be
able
to
bring
more
episodes
for
you
do
hit
like
and
share.
If
you
are
the
first
time,
viewer
don't
forget
to
subscribe,
keep
sharing
your
love
with
ethereum
cat
artist.
This
is
all
of
us
signing.