►
From YouTube: TokenScript Weekly Meeting 20200220
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
B
B
D
B
Good
good
so
so
previously-
and
this
is
a
topic
that
we
should
have
started
quite
a
few
months
ago-
but
because
we're
busy
trying
to
implement
event,
support
most
of
the
weekly
discussions
around
event.
Support
so
I
have
postponed
this
DVP
security
discussion
and
now
the
the
event
support
schema
is
ism.
Is
there
and
it's
under
its
it's
an
it's
going
to
be
merged
soon,
it's
already
there.
So
so
we
stop
talking
about
events
and
we
go
on
with
them
with
the
DVP
security.
B
B
Yes,
okay,
good,
so
I'll
start
with
the
three
cases
one
by
one
and
then
this
is
based
on
the
understanding
data
objects
which
we
discussed
before
and
test
stations
which
are
signed
that
objects.
So
I
guess
who
goes
you
guys
already
know
these?
So
I
will
go
through
case
by
case
one
two:
three
talk
about
generic
technology
of
using
test
ation
in
transactions
and
code
DVD
security
from
time
to
time,
but
it's
just
the
way,
I
call
it.
So,
let's
look
at
the
first
case.
B
B
They
cannot,
they
cannot
combine
transactions,
they
cannot
make
transaction
since
transactional,
meaning
that
they
cannot
simply
decide
that
the
transaction,
a
and
transaction
B
must
be
successful.
At
the
same
time,
all
the
whole
thing,
roll
back
and
in
the
first
case,
we're
not
using
the
wallet
contract
because
we
want
to
simplify
it
a
little
bit
and
later
we
go
to
the
more
complicated
stuff.
B
B
So
then,
we
talked
about
a
start
start
up
called
car
hood.
The
start
up
work
in
this,
such
a
way
that
if
you
rent
her
car
to
the
company
called
car
hood,
they
will
pay
you
by
day.
Every
day
the
car
is
with
car
hood.
They
would
pay
you
and
in
the
meanwhile
cow
who
will
rent
the
car
to
other
people,
tourists,
and
then
they
were
charged
twice
with
money
and
for
tourists
to
rent
their
car.
B
B
B
Address
beneficiary
says
that
which
address
received
the
daily
rental
revenue
and
you
get
bytes
insurance
attestation,
which
is
attestation
being
used
on
the
blockchain
tour
and
what
and
me
working
on
the
paper
about
how
to
use
block
sensational
blockchain.
So
this
is.
This
is
one
of
the
test
station.
So
the
logic
if
a
user
wants
to
rent
his
car
to
car
hood,
who
in
turn
rented
to
other
people-
and
they
will
call
rent
your
car
with
all
the
parameters
you
want,
you
want
renting
a
car
for
a
year.
B
B
Yes,
okay,
thank
you
very
much.
Thank
you.
So
the
problem
of
this
design
is,
of
course,
that
the
user
who
owns
a
car
would
would
have
to
approve
if
it's
in
ER
C
20
style,
it
has.
It
need
to
approve
car
hood
contract
to
call
the
car
token
contract.
So
you
need
to
do
approve
fist.
It
was
basically
whitelist
the
car
hood
contract
and
once
you
done
have
done
the
proof,
there's
two
a
problem
that
the
car
token
holder.
B
The
car
owners
will
trust
the
car
token,
let's
say
100
percent,
and
they
will
trust
the
car
hood
token.
Only
50
percent,
because
car
hood
company
can
bankrupt
there
might
be
a
bug
in
the
car
in
the
contract.
And
then,
if
the.
If
the
contract
has
caused
an
image,
they
may
simply
clear
Bank
bankruptcy
and
all
that
they
think
that
the
the
service
to
new
didn't
do
time
of
tides
of
time.
B
Then,
and
if
you,
if
the
user
approves
car,
would
contract,
the
anniversary
can
can
hack
this
contract
and
potentially
make
this
contract
transferred
car
ownership
instead
of
allocating
usage
to
the
emissary.
Therefore,
the
user
simply
want
to
rent
his
car
and
then
ended
up
having
lost
the
car
or
maybe
not
anniversary,
but
the
car
would
themselves
if
they
intend
to
do
so.
For
example,
the
company
is
too
small
and
too
new
and
some
of
the
some
of
the
developers
inside
are
malicious.
B
So
that's
one
issue
and
you
can
argue
this
can
be
amended
but
having
to
approved
functions
when
is
transfer
and
the
other
is
allocate
you
search,
and
that
is
a
not
a
very
good
end,
I
think's
plane.
If
you
approve
it,
then
you
have
the
problem
of
them.
Let's
say
how
fun
do
you
want
to
prove
it?
For
example,
do
you
approve
allocate
you
search
car
hold
food
to
to
to
called
allocate
usage
function
with
their
own
parameter?
B
All
do
you
set
a
range
of
time
and
the
the
approval
only
means
that,
during
the
range
of
time
that
that
if
the
car
hood
contract
cause
allocate
usage,
the
allocated
users
must
must
be
within
the
boundary
of
the
approved
time.
So
things
gets
very
complicated
easily,
as
you
can
imagine,
and
and
and
also
more
attack
service.
If
you
went
the
other
way
to
solve
this
problem
is
okay.
The
problem
is
the
user
trusts
the
car
hood
car
token
not
Kahu
token,
that
much
so.
Why
don't?
B
So
wide
will
let
user
call
car
hood
contract,
which
interns
call
car
token
contract?
Why
don't
we
do
the
other
way
run
like
let's
call
car
token
contract
which
which
in
turn
course
car
hood
contract?
Now
that
is
not
good
design,
because,
as
you
can
see,
the
transaction
involves
something
that
car
token
doesn't
care.
B
So
when
is
address
beneficiary,
which
is
which
address
received
the
monthly
rental
income
and
gather
is
the
car
insurance
attestation,
when
the
with
the
car
token
provide
interface,
allocate
usage,
it
doesn't
care
that
this
allocate
usage
will
be
relevant
to
a
car
hood
company
with
its
own
business
information
relevant,
which
is
address
beneficiary
and
the
insurance
has
station,
maybe
even
with
the
geo
boundary
so
or
maybe
there
are
other
stuff
like
them.
Whether
or
not
you
allow
your
car
to
be
rented
to
people
with
a
learning
license.
B
This
will
be
business
logic
that
the
car
token
company
is
not
aware
of
so
it's
difficult
to
make
modified
car
token
contracts
to
allow
such
usage.
So,
as
you
can
see,
if
we
call
car
hood
contract,
we
have
a
security
issue.
If
we
call
car
token
contract,
we
have
an
interoperability
issue
so
so
far,
so
good.
C
B
That's
that's
that
is
solved.
Yes,
that
can
be
solved.
So
basically,
what
you
do
is
you
provide
a
complicated
payload
say
that
allocate
usage
and
then
further
you
can
call
other
stuff
and
the
thinnest
and
the
car
token
contract
is
not
trusting
the
other
contracts
much
too
so
by
it's,
not
just
the
parameter.
It's
also
like
inside.
It
has
to
be
able
to
call
a
third
contract
simply
by
users
dictate
dictated
by
the
user,
which
means
malicious,
malicious
user
can
be
the
can
be
the
attacker
for
the
car
token
contract
right,
okay,
yeah!
B
B
B
B
Yeah
and
then
let's
look
at
authorization
because
that's
the
interesting
part,
the
other
two
are
just
no
copied
from
the
previous
example
where
authorization
is.
This
is
an
authorization
object.
He
said
yes,
what
you
are
seeing
is
that
that
object,
I
left
out
the
signature.
So
first
he
says
object
class.
This
is
a
car
user
of
car
usage,
authorization
and
and
then
receipt.
B
So
the
requirement
is
the
recipient,
so
that
object
by
saying
that
recipient
is
this
address.
It
means
either.
This
authorization
has
to
be
sent
from
this
contract
or
if
the
recipient
is
not
a
contract,
the
the
the
authorization
has
to
be
signed
co-signed
by
this
address.
This
is
to
prevent
the
car's
usage
to
be
transferred
to
a
non
existing
address
and
the
owner
loses
the
usage
right
and
and
not
able
to
recover
it.
Actually
they
can
from
the
transfer
car
cart
they
can.
B
B
The
the
next
line
is
that
you
know
you
know
the
which
card
it
is
reference
to
this
car
token
is
identified
by
a
car
ID,
and
then
you
have
a
start
time.
You
have
n
time,
you
have
the
transfer
level,
which
means
the
recipient
can
transfer
to
you
so
drive
further
one
time
and
they
have
the
and
the
police
engine
timeout,
which
is
just
details
like,
and
if
the
lessee
has
ended,
then
the
engine
would
will
stop
working
in
one
hour,
so
the
user
come
safely
parks
a
car
somewhere.
B
B
As
for
transaction
and
be
extendable,
because
you
cannot
change
the
parameter
of
a
function
very
well,
you
can
extend
the
authorization
if
something
and
if
the
function
you
reaches
is
functionality.
Okay.
So
so
that's
that's
how
we
can
use
attestation
solve
the
first
case.
Does
it
make
sense?
How
do
you
think
that
yeah.
A
Yeah,
it
makes
sense,
but
I
I'm
not
quite
sure
how
how
it
solves
all
the
all
the
issues
I
mean
there.
You
had
the
in
the
first
issue.
You've
got
the
problem
of
you're
authorizing
somebody
to
use
the
car
yeah,
but
you
are
worried
that,
because
you're
authorizing
you're
not
authorizing
a
specific
person
to
use
it,
you're
authorizing
car
hood
to
use
your
to
rent
your
car
on
your
behalf,
yeah.
B
B
A
B
A
D
A
A
B
A
Yeah,
but
they
could
always,
they
could
always
call
the
allocation
function
again:
2d
arcade,
but
I
suppose
they
would
relies
on
them.
Knowing
that
car
would
is
untrustworthy
if.
B
B
A
A
That's
that's
what
I
thought,
but
it
appears
that
so
the
judicial
token,
then,
is.
D
B
Also
allows
the
proof
to
be
added,
so
you
cannot
modify
the
the
the
function
interface
very
frequently.
For
example,
if
your
car
has
a
geofencing
feature,
then
you
have
to
add
a
geofence
parameter
into
the
new
approved
function.
This
wouldn't
work
so
user
authorization
that
authorization
has
a
few
advantages.
It
can
be
extended
and
also
it
can
be
signed
by
two
parties.
So
so
you
know
that
you're
not
transferring
something
to
someone
that
doesn't
this.
B
B
Then
you
get
the
exchange
without
even
using
water
contract
yeah
because
they
are,
they
are
not
a
global
blockchain,
meaning
that
they,
the
transactions,
are
only
viewable
for
the
relevant
parties.
So
you
don't
really
get
a
global
wallet
contract
that
can
work
everywhere.
Now
this
is
the
transaction
wallet
contract.
B
So
the
user
calls
the
wallet
contract
to
buy
this
transaction,
which
contains
to
what
the
user
really
wants
to
do,
and-
and
in
this
case
the
user
is
I
mean
they
signed.
This.
The
object
is
quite
complicated,
so
it's
because
it
has
a
few
levels.
So,
first,
the
user
has
a
transfer
and
which
the
object
class
says
that
it
should
activate
the
Die
contract
to
do
the
transfer
and
the
amount
is
here.
An
account
is
the
party
that
receives
the
transfer.
B
So,
let's
assume
this
addresses
a
contract
address
in
this
story,
so
the
user
transfer
$100
this
contract
and
then
expect
the
contractor
gendered
certain
events
to
be
generated
on
a
different
contract,
which
is
cryptokey
contract.
Where
a
token
of
desire,
a
desire
to
token
kentucky
d
token,
is
transferred
to
myself
actually.
B
B
So
what
it
does
is
this
that
the
word
contract
will
activate
the
transfer
which
is
100
dollars
to
the
dye
contract
and
then
expect
a
certain
event
to
happen
as
a
result
of
that
transaction
and
if
that
event
actually
happened
emitted
by
the
crypto
kt
contract,
then
the
transaction
finishes.
If
the
crypto
kt
contract
doesn't
he
need
such
a
event?
That
means
the
user
didn't
get
the
kitty.
Then
the
whole
transaction
rose
back.
A
Is
it
not
just
providing
receipt,
but
it's
doing
what
it's
supposed
to
do,
rather
than
actually
guarantee,
and
it's
doing
what
it's
supposed
to
do
is
you're
just
watching
you're
watching
events
you're
not
yes,.
B
A
A
B
Let's
say:
okay,
here's
the
here's,
Rose
better
I,
see
where
the
community
can
broke
down
and
he
didn't
find
a
rose
better.
C
B
B
Okay,
so
here's
the
story.
So,
let's,
let's
get
all
the
rows
out
and
let
me
tell
the
story
from
the
beginning:
okay:
I
was
a
little
bit
hand
wavy
in
the
first
pass,
so
Katie
contract,
we
assume,
is
well
trusted
if
the
Katie
contract.
Today's
the
kitty
is
transferred
to
a
new
person.
Then
it's
actually
belong
to
new
person.
B
Katie
shop
contract
is
the
contract
provided
by
Kelly,
Shoppach
and
suppose
the
users
visiting
that
website
and
decide
to
buy
a
kitty
and
the
kitty
shop
contract
would
receive
payment
and
give
you
the
kitty
ordered,
and
you
specify
the
kitty.
You
ordered
by
the
Kitty
ID.
Okay,.
B
B
This
information
will
be
passed
from
the
users
wallet
contract
to
the
kitty.
Shop
contract,
which
is
a
order,
and
from
here
to
here,
is
the
payment
instruction
which
the
Kate
account
a
shop
contract
will
pass
to
the
dye
contract
to
actually
do
payment
and
the
event
portion
is
what
what
it
contract
is
going
to
observe
and
if
it
does
observe
in
fact
of
the
transaction
described
by
the
by
this
data
object,
then
it
will
let
the
transaction
happen
otherwise,
and
it
will
simply
bail
out.
A
A
B
A
A
Yeah,
okay,
if
that
assumption
is
true,
then
I
can
completely
see
how
this
would
work
and
then
and
that
works
fine,
but
okay,
that.
A
B
A
A
B
Basically,
this
is
I
didn't
know.
You
could
do
that.
I
miss
it
to
you
that
only
if
you
observe
the
event,
then
the
money
will
leave
your
bag
and
the
third
thing-
and
so
this
is
the
second
case.
The
third
case
is
more
complicated,
but
I
didn't
write
it.
But
it's
built
on
the
previous
cases,
where
you'll
pay
50
died
to
plus
50
coin,
to
get
the
kitty
instead
of
paying
100
died.
So
this
is
a
needed
because
it
actually
just
happened
today.
B
B
I
cannot
get
the
Australian
dollar
back
USD
dollar,
because
it's
not
a
transactional
saying
here.
Let's
say
the
user
have
50,
died
and
50
coin
and
he
is
transferring
50
coin
into
50
died
and
that
was
the
they
wanted
to
die
together
so
precious
kitty
when
he
still
is
able
to
express
that
in
one
transaction.
That's
like
the
case,
but
I
didn't
write
it.
So
you
get
the
idea
so.
B
A
B
E
B
A
B
Okay,
so
there's
another
case:
I
didn't
mention
where
it's
not.
The
user
is
not
dealing
with
a
contract
but
dealing
with
a
person.
So
you
cannot
observe
a
event
from
you
can't
kind
of
from
dealing
with
a
person.
You
can
still
observe
event,
but
the
interesting
thing
is
the
person
need
to
provide
his
payment
inside
of
authorization.
Together.
You
can
see
here
the
buyer
is
providing
a
payment
authorization.
A
B
And
then
it's
signed
from
the
other
side.
So
that's
where
a
Merkel
acts
structure
for
attestation
is
probably
useful.
Instead
of
an
you
know,
padding
looks
like
and
like
an
ASN
sequence,
isn't
that
one
sequence
is
that
one
sequence?
We
might
use
a
Merkel
act
structure
which
we
can
talk
later
so
Boone
so
tall.
B
E
B
D
E
B
B
Yeah,
so
the
root
of
the
tree
can
be
signed
or
the
if
the,
if
the
guy
really
the
buyer,
really
is
pretty
antsy
I,
don't
want
to
sign
the
seller
part
because
I'm
afraid
that
it
can
be
misused,
although
I
don't
own
that
token,
but
I
still
don't
want
to
sign
it,
then
the
the
buyer
can
choose
only
sign
this
and
seller
can
choose
only
sign
this
and
it
has
two
constructor
order,
which
is
signed
by
the
buyer.
I.
E
Always
just
include
some
like
meta
information
in
what's
get
signed.
That
basically
says
this
is
a
this
is
a
transaction
from
this
to
this
I
mean
that's
how
you
usually,
when
you
do
like
mix
encryption
and
signatures,
or
encryption
and
and
max
that,
that's
what
you
usually
do
in
order
to
avoid
these
issues
where,
if
where
you
can
like
mix
and
match
different
components
by
ensuring
that
it's
clear
from
whatever
is
this
sign
twist,
where
it's
coming
from
and
we're
supposed
to
should
go
too,
but
yeah
I
see
what
you
see.
E
B
So
so
actual
data
structure
probably
need
another
meeting
we've
been
going
through
and
I
also
learned
how
how
this
is
typically
done
in
existing
cryptography
with
from
you.
So
this
is
today
only
talk
about
the
high
level
actual
that
has
structure
who
can
go
through
later.
Just
to
give
you
a
reminder,
the
reason,
the
reason
Mirko
lack
structure
was
used
in
in
coda
was
because
the
the
payment
authorization
is
collapsed
like
an
it's,
not
reviewed
when
it
is
being
delivered
to
the
delivery
contract.
Well,
the
delivery
section
of
this
information.
B
Three
dots
are
not
expended
when
the
transaction
centers
the
payment
one,
because
that
network
was
designed
to
take
the
users,
maths
and
transaction
and
only
deliver
a
portion
of
it
to
a
and
another
portion
of
it
to
be
so
that
they
so
that
they
don't
have
to
know
what
they
don't
need
to
know.
But
this
is
not
the
case
with
the
theorem,
so
yeah
we
don't
have
to
care
about
it.
I
just
explained
why
there
was
an
American
saying
when
there's
no
apparently
user
from
our
course
now.