Skip to content

Commit 2eda789

Browse files
committed
update README.md
Signed-off-by: Dave Grantham <[email protected]>
1 parent 910d915 commit 2eda789

File tree

1 file changed

+86
-77
lines changed

1 file changed

+86
-77
lines changed

README.md

Lines changed: 86 additions & 77 deletions
Original file line numberDiff line numberDiff line change
@@ -6,6 +6,8 @@
66

77
# BetterSign
88

9+
[![Solving Global PKI, Decentralized Identity, and Provable Provenance all at Once](https://img.youtube.com/vi/LxU4wG4ryFo/default.jpg)(https://www.youtube.com/watch?v=LxU4wG4ryFo)]
10+
911
## Introduction
1012

1113
BetterSign (`bs`) is a new signing tool designed to use provenance based
@@ -32,29 +34,34 @@ therefore lack the ability to prove the history of control and modification of
3234
any digital data, let alone cryptographic keys. With the creation of
3335
blockchains and distributed consensus popularizing the idea of immutable
3436
records of transactions over time, we've learned the value of maintaining logs
35-
to document the provenance of data over large spans of time despite the
36-
unbounded memory requirement that results. In a world where there is old data
37-
signed with old keys, there must be some cryptographically verifiable record
38-
preserving and linking old keys to the new keys; provenance logs are design to
39-
be the simplest and most decentralized solution for that.
37+
to document the provenance of data despite the associated unbounded memory
38+
requirement. In a world where there is old data signed with old keys, there
39+
must be some cryptographically verifiable record preserving and linking old
40+
keys to the new keys; provenance logs are design to be the simplest and most
41+
decentralized solution for that.
4042

4143
To finally improve the global PKI system, it seems logical to start from
4244
scratch and construct an identity solution based entirely off of a provenance
4345
logging structure. It also is apparent that identity transactions are either
44-
1-party or 3-party transactions and therefore do not require the distributed
45-
consensus necessary for trustful 2-party transactions. This opens the door for
46-
provenance logs that grow in trust in several ways. They can accumulate 1st
47-
party self-attestations along with proofs of work (i.e. content creation of all
48-
kinds or verifiable acts of service). They may also record references to 3rd
49-
party corroborating attestation sources for realtime, late-binding verification
50-
from multiple trustworthy societal institutions or organizations. In the end,
51-
this solution is very good at overcoming the analog-to-digital problem of
52-
encoding verifiability. The security rests in the statistical improbability of
53-
corrupting and/or falsifying proof from an increasing number of trustworthy
54-
insitutions while also making verification time-sensitive and responsive to
55-
shifting facts on the ground. This corroboration based security model gives
56-
statistical assurances of what is true and is the native model for provenance
57-
logs.
46+
1-party ("trust me, bro") or 3-party ("they vouch for me") transactions and
47+
therefore do not require the distributed consensus necessary for trustful
48+
2-party transactions. This opens the door for provenance logs that grow in
49+
trust in several ways:
50+
51+
1. They can accumulate 1st party self-attestations along with proofs of work
52+
(i.e. content creation of all kinds or verifiable acts of service).
53+
54+
2. They may also record references to 3rd party corroborating attestation
55+
sources for realtime, late-binding verification from multiple trustworthy
56+
societal institutions or organizations.
57+
58+
In the end, this solution is very good at overcoming the analog-to-digital
59+
problem of encoding verifiability. The security rests in the statistical
60+
improbability of corrupting and/or falsifying proof from an increasing number
61+
of trustworthy insitutions while also making verification time-sensitive and
62+
responsive to shifting facts on the ground. This corroboration based security
63+
model gives statistical assurances of what is true and is the native model for
64+
provenance logs.
5865

5966
Provenance logs are a form of time-based log with the added feature of
6067
cryptographically enforced write priviledges which may be delegated and
@@ -72,32 +79,34 @@ README][PROVREADME].
7279
7380
When discussing distributed systems we speak of networks of peers connected
7481
together with links. A network consists of peers with links that reference
75-
other peers. The links are an identifier that may reference the peer, a service
76-
provided by a peer, or data stored by a peer. A link does not necessarily imply
77-
an active network connection but does imply that one will be created when the
78-
link is used to execute the distributed functions of the network.
82+
other peers. The links are an identifier that either reference a peer, a
83+
service provided by a peer, or data stored by a peer. A link does not
84+
necessarily imply an active network connection but does imply that one will be
85+
created when the link is used to execute the distributed functions of the
86+
network.
7987

8088
All distributed systems are chaotic in nature meaning that the range and trends
8189
in network behavior observed over time are impossible to predict from the
8290
current conditions. However, distributed systems may be categorized into two
8391
buckets based on their long-term stability and resilience in the face of the
8492
corrosive effects of time. One category—*unstable* systems—are those that exist
85-
at a point in time but due to the design characteristics dictating peer and
86-
link behavior they are *not* biased towards stability and never trend towards
87-
*metastability*. These unstable systems often have many small localized
88-
networks of peers but they never seem to conglomerate into a single long-term
89-
network. You never get *THE* network—as in *THE* World Wide Web—arrising
90-
spontaneously from *unstable* preconditions. The primary example of an
91-
*unstable* network is the global identity "Web of Trust". Despite decades old
93+
at a given point in time—say t0—but due to the design characteristics of the
94+
peer and links they are *not* biased towards stability and never trend towards
95+
*metastability*. Unstable systems often have many small localized networks of
96+
peers but they never seem to conglomerate into a single long-term network. You
97+
never get *THE* network—as in *THE* World Wide Web—arrising spontaneously from
98+
*unstable* preconditions. The primary example of an *unstable* network is the
99+
various attempts at building a global "Web of Trust". Despite decades old
92100
standards and long-established market conditions, we still do not have *THE*
93-
Web of Trust. This is likely due to the characteristics of pubkey links.
101+
Web of Trust. This is likely due to using pubkeys as the identifiers and links
102+
in the network.
94103

95-
The other category—*metastable* systems—are those with peer and node
96-
characteristics that bias the chaos towards the accretion of a single, stable
97-
network. These *metastable* networks start with a set of preconditions that
98-
make *THE* network innevitable from the common usage patterns. The primary
99-
example in this category is *THE* World Wide Web. This is also likely due to
100-
the characteristics of URL links in the system.
104+
The other category—*metastable* systems—are those with peer and link
105+
characteristics that bias it towards the accretion of a single, stable network.
106+
These *metastable* networks start with a set of preconditions that make *THE*
107+
network innevitable from the common usage patterns. The primary example in this
108+
category is *THE* World Wide Web. This is also likely due to the
109+
characteristics of URL links in the system.
101110

102111
One key insight that comes from comparing pubkey links with URL links is that
103112
pubkeys links can only be in one of two states—*valid* or *invalid*—while URLs
@@ -380,62 +389,62 @@ provenance log stored in content addressable storage.
380389

381390
To reduce the tight binding and fragility of VLADs, they are encoded using the
382391
self-describiing [multiformats standard][MULTIFORMATS]. A VLAD therefore begins
383-
with the multicodec sigil identifying itself as a VLAD (e.g. `0x07`) followed
384-
by two multiformat encoded values, a nonce (e.g. `0x3b`) followed by a content
385-
addres CID (e.g. `0x01` v1, `0x02` v2, or `0x03` v3). Below are examples of
386-
different VLADs.
392+
with the multicodec sigil identifying itself as a VLAD (e.g. `0x1207`) followed
393+
by two multiformat encoded values, a nonce (e.g. `0x123b`) followed by a
394+
content addres CID (e.g. `0x01` v1, `0x02` v2, or `0x03` v3). Below are
395+
examples of different VLADs.
387396

388-
A [nonce][NONCE] is encoded using the multicodec sigil `0x3b` followed by a
397+
A [nonce][NONCE] is encoded using the multicodec sigil `0x123b` followed by a
389398
varuint specifying the number of octets in the nonce followed by the nonce
390399
octets; like so:
391400

392401
```
393-
number of nonce
394-
octets
395-
396-
0x3b <varuint> N(octet)
397-
│ │
398-
nonce variable number
399-
sigil of nonce octets
402+
number of nonce
403+
octets
404+
405+
0x123b <varuint> N(octet)
406+
407+
nonce variable number
408+
sigil of nonce octets
400409
```
401410

402411
A "plain" VLAD consisting of a nonce and CID looks like:
403412

404413
```
405-
nonce data
406-
407-
0x07 <nonce> <cid>
408-
│ │
409-
VLAD WASM content
410-
sigil address
414+
nonce data
415+
416+
0x1207 <nonce> <cid>
417+
418+
VLAD WASM content
419+
sigil address
411420
```
412421

413422
A "signed" VLAD consisting of a [multisig][MULTISIG] encoded signature nonce
414423
and CID looks like following:
415424

416425
```
417-
nonce data
418-
419-
0x07 <multisig nonce> <cid>
420-
│ │
421-
VLAD WASM content
422-
sigil address
423-
424-
425-
number of
426-
multisig octets
427-
428-
<multisig nonce> ::= 0x3b <varuint> <multisig>
429-
╱ │
430-
nonce sigil multisig octets
431-
432-
433-
multisig optional combined
434-
sigil signature message
435-
│ │
436-
<multisig> ::= 0x39 <varuint> <message> <attributes>
437-
╱ │
438-
signing codec signature attributes
426+
nonce data
427+
428+
0x1207 <multisig nonce> <cid>
429+
430+
VLAD WASM content
431+
sigil address
432+
433+
434+
number of
435+
multisig octets
436+
437+
<multisig nonce> ::= 0x123b <varuint> <multisig>
438+
╱ │
439+
nonce sigil multisig octets
440+
441+
442+
multisig optional combined
443+
sigil signature message
444+
│ │
445+
<multisig> ::= 0x1239 <varuint> <message> <attributes>
446+
╱ │
447+
signing codec signature attributes
439448
440449
441450
<message> ::= <varbytes>

0 commit comments

Comments
 (0)