►
From YouTube: 🖧 IPLD weekly Sync 🙌🏽 2020-05-18
Description
A weekly meeting to sync up on all IPLD (https://ipld.io) related topics. It's open for everyone and recorded. https://github.com/ipld/team-mgmt
A
Welcome
everyone
to
this
week's
IPL
desync
meeting
a
maybe
18
2020
and
as
every
week
we
go
over
the
stuff
that
we've
done
in
the
past
week,
and
then
this
has
open
issues
we
might
have
or
yeah
answer
questions
and
so
on
and
I
need
to
open
the
egg
paid
and
yeah
I.
So
I
start
with
myself
what
I've
done
and
we'll
do
so
on
the
rest.
A
I
put
aside
just
a
link
to
there
is
another
implementation
of
rust,
IPL
D,
which
is
kind
of
interesting,
because
it's
using
survey
for
civilization
which,
but
from
talking
to
the
person
who
did
it,
it's
really
done
in
a
good
way.
So
I'm
still
need
to
check
it
out
more
closely.
But
it's
just
a
bit
of
a
different
approach
and
yeah
feel
free
to
check
it
out.
I
would
have
definitely
have
a
close
look
at
it
and
other
than
that.
A
I
haven't
done
much
iPad
work
the
past
week,
mostly
time,
FICO
and
stuff
and
other
things
and
bad
as
promised
for
Chris
I've
looked
into
the
graph
seeing
stuff
and
what
the
state
is
so
currently,
there's
really
as
far
as
I
could
tell
it
has
only
stuff
going
on
early
in
the
rust
world
and
also
there
seems
to
be
more
parties
interested.
But
now
it
really
boils
down
to
the
chain
safe.
A
The
people
that
wrote
on
the
rust
fight
when
a
permutation
called
forest
work
on
worked
on
selectors
and
now
move
on
to
working
on
grafting.
So
there
will
be
a
rustic
plantation
of
crafts
ink
and
then
on
the
transcripts
that
I
haven't
or
anything
so
yeah.
So
that's,
basically
it
so.
It
started
as
so
many
people
excited
and
wanted
to
do
something,
and
now
it's
basically
just
the
one
imitation,
and
it
seems
yes.
A
But
of
course,
if
I
hear
anything
else,
I
will
update
you
on
this
one,
but
it
might
be
still
interesting
to
check
out
check
out
with
the
with
those
folks
because
they
probably
would
also
find
issues
or
interesting
things
or
yeah
I
expected
also.
Perhaps
even
the
spec
might
change.
If
we
have
an
implementation
of
it,
we'll
see.
A
B
A
A
They
only
do
the
fight
when
stuff,
so
I
hope
that,
for
example,
eager
for
matrix
is
interested
in
ipfs
and
I
think
he
is,
but
I
haven't
heard
back
from
him
yet
so
I
hope
that
basically,
he
will
kind
of
look
outward
and
see
like
how
are
you
laser
ipfs
and
make
sure
that
it
also
works
there,
but
I
don't
know
I
can
tell
us.
So
do
you
only
really
think
that
is
happening?
Is
that
chance?
A
B
A
A
B
Maybe
there's
okay
I
mean
I.
That's
really
helpful
to
know
where
things
are
at.
It
almost
seems
like
I
need
to
kind
of
look
at
this
and
a
little
bit
but
I
guess
Volker.
If
people
come
back
around
and
you
know
are
trying
to
do
more
with
graphs,
Sinkin,
ipfs
or
whatever
you'll.
Let
me
know
I'm
interested
in
helping
out
I.
Just
don't
know,
I,
don't
know
how
much
progress,
I'm,
I,
think
I
myself
without
anyone
else
to
talk
to
so
I.
C
Don't
know
if
you
saw
some
of
these
discussions
and
IRC
general
lately,
but
we
did
have
a
bunch
where
I
think
it
was.
Someone
from
that
same
project
is
also
really
worried
about
making
sure
you
have
test
fixtures
come
out
of
the
selectors
part,
which
is
one
of
the
big
prerequisite
steps
towards
graphing
and
I.
C
C
Please
go
on
Eric
any
safe,
slash,
I
can
be
test,
something
it's
off
my
screen
area,
but
yeah,
that's
cool
and
good
that
that
exists.
So
I
don't
have
a
ton
more
to
report
for
my
self
this
week.
Other
than
discussions
like
that
continuing
and
being
really
awesome
technical
things
to
worry
about
lately,
so
that's
been
fun,
go
uphill,
be
prime,
is
starting
to
sprout
and
change
long
document
now
knowledge.
C
It's
probably
well
overdue,
before
there's
enough
tag
releases
now
that
I
don't
remember
what
they
mean
so
I'm
starting
to
take
notes
and
also
put
some
accumulated
plan
to
changes
in
they're
trying
to
be
a
little
more
intentional
about
racking
up
the
changes
that
are
going
to
require
any
sort
of
refactored
from
consumers
before
I,
just
throw
them
out.
So
this
document
is
gonna,
be
at
least
for
now,
but
the
place
for
those
trees,
I
and
yeah.
That's
about
it.
E
E
What's
a
native
see
poor
representation
and
then
really
a
more
specific,
dag,
see
more
representation,
which
is
IP
LD
and
the
only
issue
I
really
have
right
now
is
with
and
I
mentioned
this
before
months
ago.
Is
that
way
you
strip
away
all
the
other
tags
other
than
tag
42?
Then
it
disrupts
the
abilities
to
do
see
board
it's
cozy
tag,
98
signing
with
semantic
types
embedded
in
the
tags
and
I'm
I'm
still
kind
of
struggling
with
us.
E
There's
probably
ways
around
this
with
just
basically
signing
things
other
than
decks
Ybor
and
not
using
tags,
but
I.
If
you
get
a
chance
to
do,
please
read
my
pull
request
and
I'd
love
any
feedback.
This
builds
upon
what
I
was
working
on
with
that
paper
for
the
rebooting
of
a
trust
that
never
happened
in
Argentina.
F
E
E
B
E
Think
there
are
I
know
so
the
three
box
people
actually
are
also
picking
up
on
this
idea
of
dag
signing,
dag
Seaguar
with
cosy
and
so
I've
been
seeing
a
lot
of
that
so
and
that
comes
out
of
like
so
the
previous
reboot
name
of
the
trust.
I
actually
talked
about
IP
OD
as
being
the
native
format
and
how
we
actually
do
this
and
Christian
muds
Fitz
and
I
actually
wrote
a
paper
together
from
the
Toronto
meeting
and
that's
I
think
migrated
into
three
box.
A
A
A
E
And
then
the
write-up
I,
actually
just
basically
just
spelled
out,
see,
bore
and
the
semantic
types
for
tagging,
but
then
beneath
that
actually
added
a
section
as
far
as
dag
see
bar
being
a
more
constrained
flavor
of
Seaborg
and
I.
Think
I,
specifically
I
spelled
out
all
the
constraints.
For
instance,
keys
can't
be
integers,
they
could
only
be
strings
deterministic
ordering
in
the
representation
and
an
only
using
tagged
42
for
it
to
be
dag,
see
war,
but
I
would
love
to
make
sure
I'm
not
missing
anything.
E
F
E
F
C
C
E
Is
spikes
I
think
that
did
documents
don't
require
floats
it?
Actually,
it's
very
much
just
cryptographic
key
material
and
I.
Think
it
really.
It's
not
gonna.
Be
that
urgent
for
me
to
figure
that
out,
but
I
think
if
I
actually
have
something
that
basically
for
the
time
being
sticks
that
I
think
would
be
give
me
far
enough
along
that
I
should
get
sticker.
Actually
it.
F
F
F
F
Addressing
that
I
feel
like
I
need
and
I
need
to
have
some
mind
share
with
so
that
and
the
first.
The
first
first
main
thing
is
why
why
pull
it
apart
at
all
so
Bitcoin
blocks
our
content
addressed
in
the
sense
that
you
address
these
blocks
by
a
hash,
and
then
you
can
look
them
up
in
their
system
by
the
hash,
but
the
the
hash.
Only
I
don't
know
is
it's
only
a
pure
hash.
It's
a
double
char
to
256
of
the
first
80
bytes.
F
That's
all
of
these,
and
then
you
have
this
internal
dag
structure
within
the
block
itself.
Where
that
any
80
bytes
contains
a
hash
of
this
binary
Merkle
tree,
which
hashes
the
transactions
there
is.
There
is
an
approach
you
could
take
where
you
could
say
that
the
the
Bitcoin
block
construction
is
a
hash
and
that's
what
we're
going
to
call
the
hash
function
and
so
that
that
top-level
hash,
even
though
it
might
be
a
char
to
256,
we
could
say
well,
it's
actually
a
Bitcoin
hash
and
that
it
mat
hashes
the
entire
block.
F
F
It
comprises
the
double
Shire
to
256
hash
of
the
chunk,
which
you
can
do
because
Bitcoin
uses
that
to
address
these
chunks,
it
does
internally,
if
you,
it
uses
that
same
algorithm
to
dress
all
these
chunks.
So
this
is
a
standard
Bitcoin
block
the
old-fashioned,
simple
version
of
the
Bitcoin
block,
where
you
would
have
the
header
which
is
addressed,
so
you
can
pull
that
out
as
a
piece
and
then
you've
got
this.
This
IPL
D
like
structure
of
this
tree,
where
you
eat
one
links
to
another
one.
F
So
it's
it's
a
merkel
in
the
sense
that
this
thing
links
to
all
the
other
pieces
of
itself
in
a
contained
unit,
and
so
the
head
of
links
to
this
binary
miracle
tree
root
and
then
in
there
or
you
traverse
the
nodes.
Then
you
get
to
the
the
base
of
it,
which
it
contains
these
transaction
IDs
which
the
wg6
hash
of
the
individual
transactions
and-
and
so
you
can
traverse
that
the
the
block
itself
but
Bitcoin
blocks
in
their
binary
form,
don't
store
all
that
tree
intermediate
structure,
it's
implicit
because
all
the
bytes
are
there.
F
You
can
reverse-engineer
it
so
that
it's
there,
but
what
I'm
doing
is
treating
them
as
blocks
and
so
I'm
creating
blocks
for
them
and
then
storing
them,
and
they.
You
know
64
bytes
long,
because
the
two
hashes
put
together
and
so
I've
got
this
tree
of
64
byte
chunks,
and
then
you
can
actually
navigate
it
with
IP
LD
tooling.
You
can
treat
it
just
like
it.
I
could
do
with
every
other
IP
LD
thing
except
it's
not
it's,
not
our
normal
dag
form.
F
So
you
can't
like
sort
arbitrary
types
in
there,
but
you
can
decode
this
thing
into
the
same
sort
of
structure
that
you
would
for
our
building.
So
there's
this
there's
a
bunch
of
assumptions
packed
into
that
that
I'm
happy
for
energy
to
attack,
but
that's
that's
the
top
level.
Then
segwayed
came
along
and
mess
things
up
because
segue
was
addressing.
F
Is
this
where
we've
got
two
internal
binary,
Merkle
trees,
so
we've
still
got
the
first
one,
but
the
first
one
only
only
hashes
the
transactions
with
our
witness
data
so
to
make
that
first
merkel
structure
and
get
the
TX
mochel
root.
You
take
all
the
transactions,
remove
the
witness
data
from
them,
hash
them,
and
then
you
get
their
TX
ID
and
that's
the
TX
ID
that
you
see
if
you
were
to
go
to
a
blockchain,
Explorer
and
search
for
a
particular
transaction.
You
could
use
that
TX
ID,
it's
that
first
level
one.
F
But
then
the
witness
data
is
attached
and
it's
done
by
hashing
the
transactions
with
the
witness
data
and
then
that's
the
transaction
hash.
So
they
got
TX
ID
and
TX
hash.
Two
different
things
ones
with
witness
ones
without
witness,
not
every
transaction
in
a
block
will
have
will
have
witness
data,
so
those
two
things
will
be
the
same
for
a
number
of
transactions
and
over
time
more
and
more
transactions
have
witness
data.
So
we
see
divergence
more
and
more.
F
You
have
to
go
through
the
first
transaction,
the
coinbase
and
in
there
there's
this
little
field
that
contains
a
38
byte
string
that
is
prefixed
by
a
special
six
bytes
and
then
the
remaining
32
bytes
is
a
hash,
and
that
hash
is
of
the
heading
of
this
second
structure,
which
is
not
quite
the
head
of
the
merkel
root.
But
it
also
contains
a
piece.
This
nonce,
that
when
you
reconstruct
the
binary
form
of
the
block
that
non-sexually
gets
reattached
to
the
coin
base,
so
the
coin
base
itself.
F
If
you
were
to
hash
it
twice
with
and
without
witness
data,
it
would
have
different
hashes,
because
it
has
witnessed
utter
in
the
form
of
this
nonce
and
because,
because
that's
the
sort
of
self
referential
thing
the
coin
base
doesn't
appear
in
this
second
Merkle
tree.
So
you
can
see
the
first
entry
here
is
just
a
null
hat,
which
is
just
zeros.
F
So
the
coin
base
makes
an
appearance
once,
but
it
does
have
witness
data
which
you
have
to
retrieve
from
here
and
then
some
of
the
transactions
there
full-form
can
only
be
addressed
from
the
bottom
of
this
Merkel
tree,
but
others
will
make
an
appearance
of
both
so
once
transactions
that
don't
have
witnessed
on
it
will
make
an
appearance,
their
TX,
ID
and
their
hash
are
the
same.
So
they'll
make
an
appearance
in
both
of
these
merkel
structures
and
that
which
also
means
that
you'll
have
some
repetition
in
the
internal
blocks
of
that
binary
Merkle
tree.
F
F
So
that's
the
that's
the
that's
the
that's.
What
happens
when
you
try
and
decompose
Bitcoin
into
content
address
structures
where
you
are
unwilling
to
say
that
the
Bitcoin
block
encoding
algorithm
itself
is
a
hash
function
which
works
so
I.
Have
this
all
working
and
I
am
decomposing,
although
the
blockchain
into
these
things,
and
mostly
it
works
great,
but
it
turns
out
that
there's
a
bunch
of
unicorns
which
break
assumptions
so
interesting
ones,
I've
encountered
so
far
that
I'm
having
to
deal
with
that
do
undermine
some
of
this
approach.
F
One
of
them
is
the
this
little
38
byte
string
in
the
coin
base.
That
says
this
is
a
sigrid
block.
You're
gonna
have
to
navigate
to
this
other
other
binary
Merkle
tree
to
get
the
real
form
of
some
of
the
transactions
that
does
make
an
appearance
pritus
prior
to
secret,
because
it's
not
a
non-standard
string.
It
was
used,
some
would
say,
abused
in
some
transactions
and
they
appear
before
segue.
So
you
can
find
that
string
in
blocks
that
are
not
segments.
F
So
when
you're,
when
you
are
parsing
out
these
chunks,
so
a
new
pond,
you
you
you
navigate.
So
what
I
do
is
when
I'm,
if
I'm
recomposing,
an
entire
Bitcoin
block
I,
will
navigate
from
the
header
to
the
TX
poker
all
the
way
down
the
left
side
of
that
binary
miracle
tree
get
the
coin
base
and
say
do.
Is
this
a
secret
block?
F
The
only
way
to
know
is
to
try
and
load
it
from
wherever
you're.
Storing
these
things
say:
we're
storing
a
mean
ipfs.
You
would
do
this
traversal
you
get
to
the
coin
base.
It
would
present
this
witness
commitment
thing
to
you
and
you
and
then
you
would
have
to
say:
okay,
let's
try
and
load
it
from
the
ipfs
Network
and
if
it
doesn't
load
okay,
if
it
doesn't
load,
it's
probably
not
a
sacred
pot
block.
F
C
F
A
A
F
So
this
because,
because
this
the
thing
is,
it
doesn't
point
to
Merkel
route,
so
I
can
differentiate
it.
This
thing
here
like,
although
in
here
I've,
got
three
different
multi
codecs
we've
got
the
header,
which
is
we're
going,
Bitcoin
block
the
transactions
and
the
inner
parts
of
these
binary,
Merkle
trees,
we're
calling
Bitcoin
transaction
and
but
but
then
the
thing
that
the
coin
base
points
to
is
something
different.
F
It's
called
the
witness
commitment
and
so
I'm
storing
them
as
as
multi
codec,
witness
commitment,
yes
and
and-
and
that
means
that
when
I
do
the
load,
it's
only
of
the
CID
is
encoded
with
witness
commitment.
It's
not
a
Bitcoin
block,
Bitcoin
transaction,
so
it
has
to
be
of
type
witness
commitment
for
it
to
successfully
load,
so
that
limits
the
range
of
what
other
things
are
confined.
So
it's
it's
a
binary
exists
or
not.
Yes,.
A
Yes,
but
if
you
so
basically
you
try
to
retrieve
it
and
you
don't
get
anything
back.
The
problem,
is
you
don't
know
if
it's,
if
you
couldn't
retrieve
it
or
it's
not
there,
that's
the
that's
a
problem
yeah,
but
you
know
when
you
created
the
CID
for
the
witness
commitment.
You
could
also
create
a
CID
of
the
transaction
because
if
so
and
then
try
to
retrieve
the
transaction
and
if
this
transaction
exists,
then
it
wasn't
a
witness
commitment.
No.
F
F
You
can't
just
construct
a
CID
out
of
nowhere.
You've
got
a
constructor
with
the
information
you
have
and
all
we
have
is
this
little
bit
of
information.
What
you
do,
though,
if
it
fails,
if
you
get
to
the
coin
base,
you
try
and
load
the
witness
commit,
and
it
fails
you
just
back
up
and
say:
okay,
let's
assume
this
is
not
a
sacred
block,
we'll
go
back
to
the
top
of
that.
F
Other
binary
merkel
resolve
all
the
other
transactions
from
there
and
you'll
get
the
you
will
be
able
to
load
the
the
poor
form
of
all
the
transactions,
the
non
witness
form
of
all
the
transactions
which
might
piece
of
like
it's,
not
that
that's
insufficient,
that
they
contain
a
lot
of
information.
They
contain
all
the
coin:
values
and
and
public
keys
and
stuff.
It's
you're
just
missing
a
bit
of
information.
Okay,.
A
A
E
Commitment
so
almost
seems
like
you
need
branching
logic
for
actually
the
scheme
representation
at
the
pinch
is
representing
the
data
model,
and
this
is
where,
like
in
the
w3c,
they
love
an
algorithmic
approach.
They
describe
it
in
the
abstract.
He's
like
json-ld
parsing
with
rdf
normalization
algorithm
is
basically
just
a
four-step
parsing
algorithm,
and
so
you
need
like
an
adjacent
scheme.
You
actually
can
basically
do
like
you
know.
If
this
field
exists,
then
actually
it
means
to
be
in
this
format
or
like
these
are
the
optional
enumeration
types.
E
F
In
a
purely
schema,
because
that's
built
in
it's
the
the
the
challenge
here,
not
maybe,
if
there's
another
thing,
I
have
been
covered,
which
is
we're
trying
to
encode
these
things
in
in
the
their
byte
format,
so
that
the
for
start
the
block
ID
matches
what
the
Bitcoin
blockchain
uses.
So
we
don't
want
to
modify
these
bytes
and
then
the
transaction
ID
is
the
same.
F
So
you
can
take
a
block
ID
from
the
web
somewhere
0
0,
0,
0,
0
la
la,
and
you
can
turn
that
eat
that
into
a
CID
and
then
resolve
these
and
same
for
the
transaction.
Ladies,
you
can
take
them
from
the
web
anywhere
else
up
make.
You
know.
Maybe
you're
querying
the
blockchain,
oh
I'll
crew,
that
in
you
know,
PLD
and
I,
have
the
ability,
don't
I'll
query
it
there,
so
we're
not
making
up
new
ID.
F
F
F
E
F
G
G
This
height
down
use
this
other
schema
and,
from
this
height
up
use
this,
the
the
current
good
schema
and
in
a
better
future
height
will
have
yet
another
scheme
and
I'll
tell
plz
you
actually
don't
have
an
ability
to
say
that
kind
of
thing.
We
only
have.
Does
it
part
it's
good,
it
doesn't
parse.
Then
it's
a
difference
claim
yeah.
F
Yeah
yeah
you
right
and
and
the
height
information
is
not
backed
into
the
blocks,
so
we
can't
use
that
when
we
put
these
blocks
independent
of
each
other,
there
is
a
time
in
there
which
you
could
use
as
a
signal,
but
I,
don't
think
that's
a
reliable
mechanism.
There's
no
there's
not
really
there's
not
very
firm
rules
about
times.
Although
that's
something
I
haven't
investigated
very
deeply,
but
you
could
actually
use
if
time
was
more
rigorously
applied,
then
you
could
use
time
as
a
signaling
mechanism.
Yeah.
E
I
think
the
time
specificity
is
only
about
90
minutes
and
so
I
it
could
you
she
can
have
it's
not
bad,
ordered
yeah,
yeah
actually
actually
have
unordered
blocks,
is
actually
plenty
of
turn
up
of
blocks
that
actually
are
out
of
order.
Time
series:
why?
Because
actually,
you
allow
up
to
90
minutes
for
a
reconciliation,
so.
F
F
This
problem
of
the
witness
commitment,
looking
like
it
exists,
but
didn't,
and
so
I
thought
well
mainly
in
my
like
when
I
specify
this,
because
I'll
make
I'll
write
up
this
stuff
in
documentation
and
say
this
is
the
IP
LD
Bitcoin
format,
and
this
is
how
we
do
it
and
by
the
way
there
is
a
white
list
of
coinbase
identifiers
that,
if
you
encounter
these,
then
they
have
a
special
case
and
you
could
use
just
the
hashes
like
you
could
list.
You
know
four
or
five
hashes
and
say
these
are
special
unicorns.
F
E
And
so
in
json-ld
world
there's
actually
such
a
thing
as
jason
framing,
and
I
think
there
is
where
basically,
you
have
the
scaffolding
of
a
document
that
actually
things
that
must
be
there.
But
then
I
think
there
was
a
branching
logic
that
says:
if
these
things
are
here,
you
know,
then
you
follow
this
path
right.
F
Yeah
well
within
an
IP
all
these
gamers.
We
have
unions
which
help
us
do
that
and
then,
but
then
they
also,
the
concept
is
baked
in
that
you
should
be
able
to
apply
different
schema
IP
le
scheme,
as
the
intention
is
that
they
will
be
quickly
verifiable
because
their
block
local
and
they
you
don't-
require
too
much
processing,
and
so
you
should
be
able
to
quickly
try
different
schemas
to
find
out.
But
this
is
this
is
not
a
dag
seaboard,
deck
jason,
dag
anything.
C
So
as
I
correctly
understanding
that
part
of
the
problem
also
is
this
information.
It
must
have
been
used
inconsistently.
Some
part
of
this
block
of
information
in
the
history
of
Bitcoin
as
like,
as
humans,
actually
wielded
it
right.
So
you've
got
this.
That
was
reserved
in
the
blocks
earlier
in
time
and
it
was
used.
It
must
contain
nonsense
data
or
are
we
like
encountering
blocks
where
people
like
try
to
put
low
bit
rate
selfies
into
the
Bitcoin
or
something
I
remember
hearing
stories
about
this?
Yes,.
F
F
But
it's
possible
to
put
stuff
after
the
Opera
turn,
which
is
nonsense,
and
so
that's
where
people
would
embed
things
in,
they
could
say:
okay,
opera
turn,
but
I'm
gonna
put
some
bytes
after
that,
and
that
contains
my
fun
stuff
sake
when
they
said
for
segment.
They
said:
okay,
if
you
find
an
opera
turn
plus
32
bytes.
That
32
bytes
is
a
witness
commitment,
but
it
turns
out
that
people
were
inserting
32
bytes
after
I
returned.
C
You're
not
trying
to
specify
a
decoding
in
a
schema
for
something
that
was
well
designed,
it's
more
like.
If
this
was
like
website
certificates,
we
would
be
looking
at
a
situation
where
somebody
had
discovered
the
encoding
bugs
where
you
can
put
information
after
a
null
terminator,
and
some
implementations
are
finer
things
so
hard
and
peanuts
exactly
this,
and
then
somebody
else
wrote
back
that
uses
it
even
more
with
different
semantics
than
ever
before,
and
they
just
pushed
it.
C
F
What
we're
seeing
is
is
implications,
I
was
thinking
is
the
implications
of
a
desire
not
to
make
a
hard
fork.
This
is
what
happens
if
you
want
to
do
a
soft
fork
and
it's
all
backwards
compatible.
That's
what
Segway
is.
Even
though
every
minor
now
handled
sacred,
it
was
never
a
hard
fork,
and
it
was
this
is
this
is
this
is
what
happened.
C
F
C
G
G
Otherwise,
you
have
to
trust
the
actual
the
actual
software
downloaded
that
it
has
baked
in
a
number
of
check
points
from
the
blockchain
like
actual
IDs,
and
it
says
yeah
yeah
from
from
from
there
on
like
earlier
than
this
ID
we're
good.
But
if
you
actually
wants
to
verify
that
your
software,
isn't,
you
know
being
screwed
with
you
have
to
start
from
the
Genesis
block
all
the
way
up
and.
F
F
C
F
Right,
this
is
what
I'm
finding
is
this.
Is
this
address
this
this?
A
this
exercise
is
really
helpful
in
figuring
out
some
things
not
to
do
I'm
really
finding
this
valuable,
and
it's
also,
but
it's
also
really
challenging
some
of
the
core
assumptions
like
this
thing
of
okay.
Why
don't
we
just
called
the
block
algorithm,
a
hash
function.
C
So
I
don't
know
we
mentioned
time
briefly
earlier
and
the
granularity
might
be
kind
of
quiet
sure,
but
it
is.
Is
it
plausible
in
practice
and
knowing
that
the
thing
that
Bitcoin
officially
does
with
the
block
height
is
also
wildly
impure,
and
it's
a
bit
silly
right.
So
the
bar
for
sanity
here
is
really
is
low,
granularity
time,
good
enough
that
we
can
actually
use
it
as
a
heuristic
for
this
thing
and
document,
that's
what
we're
doing
and
go
with
it,
because.
C
F
That's
definitely
something
I
probably
should
check,
because
I
have
the
village
to
it.
It
does
assume
that
there
will
be
no,
that
future
blocks
will
have
no
ability
to
make
wild
times,
because
perhaps
some
future
incarnation
of
bit
of
the
algorithm
will
say.
Yeah
we've
decided
this
time
field
doesn't
really
matter,
so
you
can
use
it
for
variation
in
mining
like
they
like
they've
done
that
with
a
version,
the
version
string
now
so
miners.
F
F
G
Yeah
I
just
want
to
bring
it
back
just
a
little
bit
to
what
Eric
said
that
this
is
kinda
like
breaking
with
the
spirit
of
Merkle
trees.
It
doesn't
really
because
the
schema
is
defined
on
the
entire
dag,
which
starts
from
the
root,
and
that
is
completely
deterministic.
In
fact,
this
how
they
rolled
it
out.
It
was
like
their
greatest
software
and
in
the
end,
in
each
Bitcoin
node,
there
was
a
switch
in
the
future
at
some
date
that
wasn't
known
at
the
time.
F
G
G
C
No,
no
isn't
that
sort
of
taking
their
the
wrong
way,
though
so
like
if
you've
got
a
patch.
That
starts
you
off
with
a
dag.
That's
very,
very
large,
like
you've
got
it
at
the
tip
of
the
current,
and
it
covers
everything.
Then
that
reasoning
holds
just
fine,
but
isn't
the
sort
of
a
problem
where,
if
you
take
a
tip
that
was
quite
old,
but
you
don't
know
that
right.
You
have
no
magical
knowledge
of
this.
C
G
F
There
are
all
these
blocks
are
labeled
Bitcoin
TX,
because
you
don't
know-
and
you
can't
know
whether
this
thing
will
be
a
real
transaction
or
another
node
in
this
binary
merkel.
You
only
know
once
you
get
there
and
so
labeling
them
all
Bitcoin
TX,
Mata
codec
does
make
sense.
So
what
you
do
is
you
navigate
in
and
you
resolve
a
block.
You
get
the
block
out
and
you
use
the
size
to
tell
you
whether
it's
a
an
inner
node
in
this
tree
or
whether
it's
the
real
transaction.
F
If
it's
64
bytes
exactly
then
it's
two
hashes
jammed
together.
I
can
then,
and
then
that's
your
schema
and
then
you
will
say:
okay,
I
return,
then
an
array
of
to
see
IDs.
That's
that's
that
that's
how
you
do
deserialize
64
byte
things,
and
if
you
get
anything
other
than
64
bytes,
you
do
serialize
it
as
a
transaction
format,
and
so
you
can
do
that
really
nicely.
You
load
these
blocks
and
you
signal
on
the
length
of
them.
F
It
turns
out,
though,
as
I
discovered
yesterday,
that
there
are
transactions
which
decode,
which
which
in
encode
into
a
binary
form
of
64,
bytes,
very
small
transactions
but
they're
exactly
the
same
length
of
these
as
these
inner
merkel
nodes.
So
then,
then
we
have
this
scheme
a
problem
of
okay.
It's
do
it.
I
can't
just
switch
on
lengths.
F
I
have
to
actually
start
decoding
these
things
and
see
if
they
decode
properly
so
tell
whether
it's
a
transaction
or
not,
which
is
possible,
but
then
there's
another
problem,
which
is
that
there
are
a
number
of
these
blocks
which
start
with
enough
zeros
that
they
will
successfully
decode
and
one
of
these
merkel
inner
merkel
nodes
as
a
transaction
and
and
the
common
one.
Is
this
series
number
17
here
they
start
with
32
zeros
and
that
will
decode
you
a
successful
transaction
that
is
basically
empty.
F
Which
sucks
so
then
so
then
the
branching
logic
is:
okay.
Can
does
it
decode?
Yes,
okay?
Well,
let's
have
a
look
inside
and
sanity
check
it,
because
maybe
it
contains
version
zero
and
all
of
the
structures
are
zero
length.
If
so,
that
is,
that
is
almost
certainly
not
a
transaction
and
probably
an
inner
merkel
node.
F
It's
a
branch
on
that
now,
I
haven't
processed
all
that
blockchain
to
know
whether
that
is
successful,
because
maybe
there's
another
unicorn
out
there,
which
is
a
transaction
that
has
version
zero
and
no
arrays,
which
I
don't
think
is
possible
because
the
the
coin
base
has
to
exist.
Universes
we've
talked
about
transactions
but
I,
think
in
transactions.
You
have
to
have
a
flow
of
coins.
F
You
have
to
have
an
in
and
an
out,
and
these
things
are
arrays,
so
you
have
to
have
at
least
one
element
arrays,
except
in
the
Genesis
block
another
even
the
Genesis
Fox
has
in
it
in
and
out
so
I
think
that's
a
successful
enough
check,
but
but
the
unicorn
here
is
64-byte
exactly
likes
transactions
where
there's
enough
rent
enough
bites
in
the
front
for
it
to
decode
into
a
transaction.
I
haven't
encountered
a
bite.
F
F
And
then
what
else
is
there?
Oh
yeah?
No,
my
other,
my
other
unicorn
is
more
of
a
formatting
thing
where
I've
discovered
blocks
that
only
have
a
coin
base,
which
I
didn't
think
was
possible,
but
that's
exists
even
later
in
the
tree
later
in
the
chain
in
the
coin
bait.
The
coin
basis
is
the
is
the
thing
where
the
minor
awards
come
come
in
and
get
distributed,
so
the
minor
will
take
their
cut
inside
the
coin
base
and
they
receive
it
from
the
chain
in
the
coin
base.
F
So
there
are
some
blocks
that
only
have
minor
awards
and
no
other
real
transactions
that,
but
that's
not
a
that's,
not
really
an
IPO
concern,
that's
more
of
a
decoding
consumer.
So
anyway,
that's
this!
This
is
these.
Are
the
adventures
I'm
encountering
and
keep
on
encountering
I've
done
about
half
of
the
blocks
in
the
blockchain,
but
mostly
at
the
front?
Half
because
all
this
more
novelty
introduces
over
time
as
as
there's
more
randomness
as
the
million
monkeys
to
typing
and
keyboards
in
this
thing.
F
A
E
Supposed
to
mean,
do
you
need
to
traverse
the
entire
history?
Can
you
actually
go
back?
You
know
300
blocks
or
a
hundred
thousand
blocks
and
just
be
contented
actually
like.
We
have
everyone
agrees
that
that
their
earlier
schemas
are
hard
to
parse.
So
actually
you
have
it
like.
You
know
most
of
the
way
done.
F
So
I
don't
really
want
to
talk
about
explicitly
the
purpose
of
this,
but
let's
just
say
that
it's
for
archival
reasons,
so
the
ultimate
game.
The
ultimate
purpose
here
is
to
actually
decompose
these
things
into
IP
LD
blocks
that
we
can
archive
outside
of
the
Bitcoin
network
and
I
yeah.
The
reason
we
don't
announce
is
that
I,
it's
part
of
another
effort
that
will
have
its
own
announcement,
but
it's
it's
it's
it's
already
good,
partly
announced.
So
it's
not
it
shouldn't
be
so
much
but
yeah.
F
The
idea
is
well
and-
and
Bitcoin
is
one
of
these
things
that
is
probably
gonna
exist
for
a
very
long
time,
because
it's
like
it's
like
digital
gold
like
unless
there's
some
major
flaw
found
that
can't
be
undone
cubby,
workaround,
probably
gonna,
be
around
for
a
long
time.
But
it's
easier
to
imagine
one
of
these
smaller
block
chains
disappearing,
let's
say
Z
cache,
which
is
it's
got
some
really
good
properties
to
it.
F
Can
we
store
them
so
that
they
can
be
historical
records?
That's
that's
that's
what
part
of
the
thinking
here.
So
how
can
we
store
them
in
ways
that
are
useful
to
traverse?
And
maybe
it's
maybe
it's
overly
ambitious
to
say
we
can
store
them
in
in
our
conception
of
what
content
addressed
blocks
should
be
that's
what
we're
trying
and
it's
turning
out
to
be
an
interesting
exercise.
F
F
And-
and
you
can't
really
never
get
them
very
usefully
unless
you
have
the
file
name,
which
could
be
the
hash
and
then
that's
all
you
have
but
yeah
this
mostly.
This
is
I'm
finding.
This
is
useful
for
challenging
and
putting
questions
to
IP
LD.
Okay.
Is
this
sufficient?
How
how
do
how
are
we
solving
these
problems
and
what
are
we
doing?
That
is
a
significant
evolution
above
this
conception
of
content,
dressing
and
block
chains
and
all
the
other
things
that
Bitcoin
brought
and
tries
to
use,
and
it's
it's
a
good
exercise.