►
From YouTube: The Cathedral & the EOS Bazaar
Description
EOSIO permissions make it possible to strengthen account security to the point where lost or stolen keys become nothing more than minor inconveniences. In this episode, we explain what EOSIO permissions are at the conceptual level, and the trend towards a strong, mesh network of interconnected accounts.
CONTACT:
Telegram: @eosweekly
Twitter: @EOSWeekly
SOURCES:
Chintai website:
https://www.chintai.io/
chintailease account:
https://bloks.io/account/chintailease
eosDAC website:
https://eosdac.io/
eosDAC accounts:
https://bloks.io/account/eosdactokens
https://bloks.io/account/daccustodian
https://bloks.io/account/eosdacthedac
https://bloks.io/account/dacauthority
Preventing the DAO by Michael Yeates:
https://steemit.com/eos/@m-i-k-e/preventing-the-dao
Chestnut:
http://www.chestnutaccounts.com/
A
Welcome
to
Yost
weekly,
how
is
the
physical
world
connected
to
the
blockchain
world?
What
is
the
bridge,
and
where
is
the
boundary
through?
What
mechanism
can
we
humans
located
here
in
the
physical
world,
influence
the
state
and
the
behavior
of
our
blockchain?
There's
one
simple
answer
to
this
question,
and
it
is
this
asymmetric
cryptography,
in
other
words,
the
connection
between
private
keys
and
public
keys.
That's
it.
A
The
one
and
only
one
magical
portal
through
which
we
humans
can
reach
inside
and
interact
with
our
blockchain,
is
through
this
private
public
key
pairing
from
the
smallest
transfer
of
tokens
to
smart
contract
updates
and
even
to
changes
in
the
system
contracts
themselves.
The
contracts
which
determine
the
core
behavior
of
our
blockchain.
The
mechanism
through
which
we
humans
are
able
to
reach
inside
and
interact
with
our
blockchain,
is
always
that
same
private
public,
key
pairing,
private
keys,
reside
outside
the
chain.
A
Public
keys
are
placed
like
anchors
at
strategic
positions
inside
the
chain,
and
these
two
keys
together
become
our
one
and
only
way
of
bridging
the
physical
world
with
the
blockchain
world.
But
a
single
private
public
key
pair
alone
is
not
the
strongest
of
bridges.
It's
more
like
a
thin
thread.
It's
vulnerable,
especially
on
the
private
key
side,
where
keys
can
be
lost
or
stolen.
Many
of
our
fellow
eros
community
members
have
fallen
victim
to
spoofing
scams
or
have
lost
their
keys
accidentally.
A
This
is
an
awful
thing
when
people
lose
access
to
their
funds
and
we
can't
emphasize
enough
how
sad
it
is
when
this
type
of
thing
happens,
but
the
asymmetric
cryptography
itself
isn't
the
problem.
This
cryptography
is
incredibly
powerful.
The
weak
point
lies
in
the
management
and
usage
of
these
keys,
and
there
are
two
approaches
we
can
take
to
minimize
the
risk
involved
in
this
err.
A
But
the
other
thing
we
can
do
starts
with
the
on
chain
side
of
the
divide
up
here
and
can
be
thought
of
as
multiplying
these
thin
threads
out
into
a
stronger,
more
robust
bridge
across
a
bridge
strong
enough
that
a
single
lost
or
stolen
key
won't
result
in
lost
funds
where
it'll
be
no
big
deal
when
this
type
of
thing
happens.
This
is
where
yo
Co
permissions
come
into
play,
and
this
is
the
focus
of
today's
episode.
A
Yeoseo
permissions
enable
us
to
spread
out
the
authority
on
a
given
account
so
that
the
on
change
side
of
the
divide
has
a
wide
set
of
public
key
endpoints.
All
of
these
endpoints.
All
these
public
keys
along
the
edge
here
enable
us
to
achieve
that
stronger
connection
that
we're
talking
about
what
we
can
do
here
with
ESL
permissions
is.
We
can
structure
our
accounts
in
a
way
so
as
to
require
more
or
fewer
people
to
approve
account
activity,
depending
on
the
risk
profile
of
a
given
account,
typically
we'll
setup.
A
The
higher
value
accounts
so
as
to
require
a
wider
combination
of
human
approvals,
whereas
the
smaller
and
smaller
value
accounts
will
require
fewer
and
fewer
people
to
make
approvals.
When
we
structure
our
accounts
in
this
way,
storing
value
on
the
chain
can
be
likened
to
burying
treasures
with
our
most
valued
treasures,
buried
deep
within
the
network
requiring
coordinated
efforts
to
unearth
them,
while
smaller
accounts
will
be
buried
closer
and
closer
to
the
surface.
A
The
single
thread
accounts
right
along
the
dividing
line
here
will
be
more
like
spending
cash
in
our
pockets.
These
smaller
accounts
will
have
greater
liquidity
with
an
acceptable
amount
of
risk
for
the
amount
of
funds
stored
in
them.
Today,
the
account
authority
structure
in
the
EOS
Network
looks
more
like
this.
It's
very
flat,
simple.
A
In
the
remainder
of
this
episode,
we're
going
to
show
you
how
they're
doing
this
so
that,
hopefully,
by
the
end
of
this
video
you'll,
understand
ESL
permissions
at
a
conceptual
level
and
you'll
have
a
better
understanding
as
to
the
direction
that
the
EOS
network
is
headed
to
real-world
examples
of
layered
hierarchies
that
are
already
following
this
future
pattern
are
chin
tie
and
EOS
deck
chin
tie
is
simpler,
so
we'll
start
with
this
one
vo
stack
is
a
bit
more
complex.
So
we'll
look
at
this
one
second.
A
So
if
you
aren't
familiar
with
chin
tie,
it
is
a
token
leasing
platform
where
Yost
token
holders
can
lend
their
unused
Yost's
to
those
applications
that
need
the
network
resources.
Chin,
tie
a
grits
the
tokens
from
the
lenders
and
creates
the
marketplace
between
lender
and
app
builder,
paying
out
a
dividend
to
the
lenders
in
the
process.
It's
a
great
system
benefiting
both
parties
involved,
but,
as
you
can
imagine,
this
type
of
system
ends
up
with
an
account
with
a
whole
lot
of
tokens
in
it.
A
The
chin
tie
lease
account
currently
holds
over
2
million
euros
in
it,
and
this
number
is
growing
daily.
This
is
worth
about
8
million
u.s.
dollars
at
the
current
token
price.
If
this
account
was
somehow
compromised
and
the
tokens
in
it
lost,
it
would
be
devastating
to
all
involved,
including
to
the
overall
reputation
of
use
similar
to
how
the
Dao
hack
hurt
aetherium.
So
how
do
we
structure
something
like
this,
so
that
it
has
the
highest
possible
level
of
security?
A
Well,
let's
look
at
how
tos
42
and
the
other
bps
behind
chin
tie
have
set
this
up.
What
you
see
here
is
the
current
hierarchical
structure
that
controls
the
chin
tie
lease
account
this
first
layer,
underneath
the
main
account
is
made
up
of
the
11
block
producers.
You
just
saw
here
on
the
chin,
Thai
web
site.
All
of
them
are
jin-tae
project
sponsors
and
these
bps
all
together,
sharing
the
account
security.
A
The
threshold
is
so
as
to
require
six
signatures.
Out
of
the
eleven
block
producers
to
approve
any
changes
to
this
account.
This
way,
if
one
or
two
bps
were
to
lose
their
keys
or
get
their
keys
stolen,
nothing
bad
would
happen
here.
A
hacker
would
have
to
somehow
gain
access
to
six
of
the
BP
accounts
in
order
to
gain
access
to
the
chin
tie
lease
account
by
setting
it
up
this
way,
the
token
lenders
don't
need
to
put
their
trust
in
a
single
person
or
a
single
organization,
same
thing
with
the
eleven
block
producer
sponsors.
A
None
of
these
VP's
need
to
put
their
trust
in
state,
EOS,
42
or
any
other
single
organization.
For
that
matter.
To
do
something
shady
with
the
chin
tie,
lease
account
would
require
collusion
among
six
of
the
11
bp's,
which
seems
highly
unlikely
to
pull
off
without
one
of
those
bp's
sounding
the
alarm.
Now
you'll
notice
that
there
is
another
layer
of
accounts
here
in
between
the
bps
in
the
public
keys.
A
This
is
Yoast
Nation
Yoast
nation,
within
their
own
BP
account
has
repeated
the
pattern
of
requiring
multiple
signatures
in
order
to
perform
actions
on
their
account
whenever
the
account
authority
is
distributed
out.
In
this
pattern,
whether
at
the
chin
tie
level
up
here
or
at
the
eos
nation
level
down
here-
this
is
what
they
call
a
multi-sig
account
which
is
short
for
a
multiple
signature.
A
We
didn't
mention
the
word
permission
once
and
it's
actually
Josiah
permissions
that
are
at
the
heart
of
this
whole
structure.
Permissions
are
what
make
this
layered
hierarchy
possible.
So,
let's
talk
about
owner
and
active
owner
and
active
our
standard
default
permissions
built
into
every
account.
We,
the
EOS
community,
often
refer
to
owner
inactive
as
keys,
and
this
might
have
caused
some
confusion.
Making
it
sound
like
owner
and
active
are
keys
when
they
are
in
actuality,
not
keys,
but
permissions.
A
The
reason
why
we
say
owner
keys
and
active
keys
is
because
keys
happen
to
be
the
most
common
things
that
these
permissions
are
mapped
to.
Going
back
to
our
jin-tae
lease
account.
This
authority
structure
that
we've
been
showing
so
far
is
the
owner
permission
of
the
Qin
ty
lease
account
and
when
you
link
accounts
together,
like
the
lines
in
our
diagram
imply
you're,
not
actually
linking
one
entire
account
to
another
entire
account.
What
you're
doing
is
linking
one
specific
account
permission
to
another
specific
account
permission.
A
So
the
owner
permission
of
Qin
ty
lease
is
mapped
to
the
active
permission
of
the
11
bps.
The
only
exception
to
this
is
us
New
York,
which
has
set
up
a
custom
permission
specifically
for
the
chin,
ty
lease
use
case,
and
if
we
look
at
the
O's
nation
again,
we
see
that
the
main
u.s.
nation
accounts
active
permission
here
is
map
to
their
multi-sig
accounts,
active
permission,
which
then
distributes
trust
out
to
the
active
permissions
of
a
TOS
nation
stakeholders,
each
of
which
are
finally
mapped
to
public
keys.
A
You
can
look
up
the
permissions
on
any
account
using
block
explorers
such
as
blocks
that
I.
Oh
here,
is
the
chin,
ty
lease
owner
permission
and
you
can
see
the
mapping
to
the
active
permissions
of
the
11
bps,
except
for
the
custom
permission
that
AOS
New
York
uses
here
blocks
that
io
uses
this
annotation
to
denote
permissions
mapping,
account
name
@
permission
name
and
in
terms
of
thresholds
and
weights.
You
can
see
the
threshold
of
6,
which
we
discussed
earlier,
and
each
BP
has
an
equal
weight
of
1
in
this
particular
example.
A
So
the
math
in
this
is
one
is
very
straightforward.
But
if
we
drill
down
and
look
at
the
multi-sig
under
US
nation,
we
see
more
variance
in
the
thresholds
and
the
weights
under
euros
nation.
The
owner
permission,
has
a
threshold
of
5
and
active,
has
a
threshold
of
3
and
the
weights
are
anywhere
from
1
to
3
under
active.
This
means
some
individuals
alone
enough
authority
to
reach
that
three
threshold,
but
the
route
permission
in
the
owner
permission
requires
two
to
five
people,
depending
on
their
weight,
in
order
to
reach
that
five
threshold.
A
Jin-Tae
lease
is
one
of
those
accounts
that
holds
code
the
logic
behind
the
chin
tight
token
leasing
platform
when
it
comes
to
code
just
like
how
we
human
beings
cannot
perform
actions
on
an
account
without
reaching
the
threshold
on
one
of
those
account
permissions.
Smart
contract
code
also
has
to
abide
by
those
same
exact
rules.
Code
cannot
perform
actions
on
an
account
such
as
transferring
tokens
without
reaching
certain
permissions
thresholds.
A
A
A
Essentially,
this
means
that
jin-tae
lease
tokens
are
under
the
control
of
the
smart
contract
of
this
account.
Only
through
the
active
permission,
though
humans
alone,
the
11
bps
control,
the
owner
permission
of
gentiles
Yeo's
DAC
is
taking
some
innovative
approaches
when
it
comes
to
their
permissions
management
and
specifically
how
a
austech
grants
access
to
the
code.
So,
let's
continue
this
discussion
of
code
permission
but
move
over
to
our
second
exam.
So
first,
what
is
yo
stick.
A
Yo
stack
is
a
block
producer,
but
there's
something
special
about
yo
stack
that
sets
them
apart
from
the
other
bps,
in
that
yo
stack
is
structured
as
a
deck.
A
decentralized
autonomous
community,
so
yo
stack,
is
not
owned
and
operated
by
a
private
organization,
but
instead
holds
elections
for
what
they
call
custodians
and
it
is
the
12
elected
custodians
who
run
the
e
o
static
block
producer
here.
Is
the
EO
stack
the
count,
Authority
structure?
A
Now,
as
we
were
just
discussing,
we
want
to
get
into
how
yo
stack
has
set
up
there.
Yo
Co
debt
code
permissions,
but
before
we
get
into
the
code
permissions.
The
first
thing
to
note
here
is
the
cool
way
that
yo
stack
has
decoupled
the
permissions
logic
into
a
separate
account.
These
three
accounts
up
here
are
the
ones
that
hold
the
code
and
the
tokens.
Then
there's
this
deck
authority
account
down
here.
A
This
account
has
no
tokens
and
no
code,
but
it
does
have
some
extensive
permissions
logic
with
multi-sig
set
up
for
the
1200
static
custodians
and
with
custom
permissions
created
for
high
medium
and
low
risk
actions.
What
Michael,
Yates
and
the
yo
stack
team
have
done
here?
Is
they
followed
an
important
design
pattern?
A
So
if
we
were
to
go
into
a
block
Explorer
and
look
in
any
of
these
three
main
yo
stack
accounts
will
see
owner
and
active,
mapped
to
deck
authority
active
in
each
of
them.
Heõs
deck
tokens
mapped
to
deck
authority
at
active,
dad
custodian
again
owner
an
active
are
mapped
to
deck
authority
at
active
and
yo
stack.
The
deck
again
I
want
her
an
active
our
map.
A
The
same
way
all
right
now,
back
to
the
topic
of
code,
permissions
yo
stack
is
defining
some
best
practices
in
terms
of
safely
and
securely,
connecting
smart
contract
code
with
account
permissions
code
that
has
a
bug
in
it
or
a
security.
Vulnerability
has
the
potential
to
cause
major
problems
when
that
code
is
empowered
to
transfer
tokens
out
of
a
given
account,
so
yo
stack
has
started
configuring
time
delays
alongside
any
code
that
is
charged
with
moving
tokens
around
now.
We
haven't
mentioned
time
delays.
A
Yet
in
this
video
but
time
delays
are
the
third
and
final
thing
that
permissions
can
be
mapped
to
permissions,
can
map
to
public
keys,
other
permissions
or
to
time
delays
these
time.
Delays
are
not
the
same
thing
as
the
three
day
staking
period.
The
three
day
sneaking
period
is
specific
to
the
Eos
token
for
voting
and
resource
procurement.
The
time
delays
we're
talking
about
here
in
the
context
of
permissions
work
within
the
same
weights
and
thresholds
logic
as
our
other
two
items.
A
Let's
look
at
how
a
OC
deck
is
using
time
delays
to
understand
them
better.
These
two
accounts
here
are
the
two
EOS
deck
accounts
that
hold
tokens
and
the
X
fer
the
transfer
permission
on
these
accounts
and
power
code
to
manage
those
tokens.
This
transfer
permission
is
configured
the
exact
same
way
on
both
of
these
accounts
and,
as
you
can
see
here,
transfer
has
a
threshold
of
two
and
this
threshold
can
be
met
in
a
few
ways.
First,
the
deck
authority
medium
permission
has
a
weight
of
two.
A
So
if
the
custodians
reach
the
medium
threshold
under
the
DAC
authority
account,
which
requires
nine
custodian
approvals,
the
transfer
permission
has
reached
its
threshold
and
the
trip
and
the
transaction
executes
without
delay.
Otherwise
these
two
here
would
together
have
to
reach
the
two
threshold.
This
means
that
the
code
can
initiate
a
transfer,
but
in
order
to
reach
the
two
threshold,
the
code
has
to
wait
for
60
minutes
before
the
transaction
is
allowed
to
execute.
A
The
idea
behind
this
delay
is
that
it
gives
yo
stack
a
bit
of
a
safeguard
in
case
the
code
starts
acting
wacky
due
to
a
bug
or,
if
there's
a
security
vulnerability.
The
code
that's
being
exploited.
Now,
you
might
be
saying,
is
60
minutes
really
enough
time
for
us
slow
humans
to
notice
something
bad
is
happening
and
react
to
it.
A
What
if
it
happens
while
we're
all
sleeping
this
is
where
automated
external
validators
come
into
play
as
Michael
Yates
described
in
his
preventing
the
Dow
Post,
automated
scripts
can
be
created
which
run
off
chain,
and
these
off
transcripts
can
monitor
yose
accounts
for
misbehaving
code
and
assuming
the
time
delay
was
implemented,
the
robots
can
catch
the
misbehavior
and
cancel
the
transaction
before
it
is
allowed
to
execute.
So
the
time
delay
doesn't
need
to
be
long
enough
thrust
slow
humans
to
react.
It
just
needs
to
be
long
enough
for
the
external,
automated
validators
to
react.
A
A
This
is
the
direction
Yoshi's
headed
with
intelligence
structures
like
chin,
tie
and
like
EOS
deck
being
implemented
across
the
ecosystem
of
accounts
intertwining
with
each
other
into
complex
clusters
of
accounts.
This
more
mature
version
of
a
OS
will
strengthen
our
bridges
across
the
dividing
line
here
and
turn
lost
and
stolen
keys
into
minor
inconveniences.
A
Now
the
two
structures
that
we
covered
in
this
episode,
we're
designed
by
highly
technical
block
producers
and
we're
not
expecting
a
typical
end
user
to
go
in
and
configure
this
stuff
themselves.
If
you
don't
know
what
you're
doing,
please
be
careful
and
seek
help
before
messing
with
your
permissions,
a
mistake,
your
permissions
could
get
you
locked
out
of
your
account,
which
obviously
defeats
the
purpose,
but
throughout
this
year,
you're
going
to
see
more
and
more
utilities
being
released.
That
will
guide
the
end
user
through
this
process
in
a
simple,
user-friendly
way.
A
Chestnut
is
an
early
example
of
this,
but
more
are
coming.
That's
it
for
this
week's
episode,
thanks
for
watching.
If
you
learned
something
from
this
video,
please
share
it
with
other
community
members
who
might
not
be
fully
aware
of
the
powerful
capabilities
of
geocell
permissions,
because
the
better
our
community
understands
how
this
stuff
works.
The
stronger
our
blockchain
will
ultimately
become
thanks
and
we'll
see
you
next
week
right
here
on
ilos
weekly.