@@ -1,208 +1,217 @@
1−# Why Urbit (probably) doesn't need a blockchain
4+title: Why Urbit (probably) doesn't need a blockchain
2−
5+author: Curtis Yarvin
3−TLDR: Urbit (probably) doesn't need a blockchain, because the
16+TLDR: Urbit (probably) doesn't need a blockchain, because the Urbit
4−Urbit address-space PKI is a special case of a consensus ledger
17+address-space PKI is a special case of a consensus ledger (itself a
5−(itself a special case of Byzantine agreement).
18+special case of Byzantine agreement).
7−Special cases are often easier to solve than general problems.
20+Special cases are often easier to solve than general problems. The
8−The "New Jersey" or "worse-is-better" school of systems design
21+"New Jersey" or "worse-is-better" school of systems design emphasizes
9−emphasizes solving any problem with the weakest possible tools.
22+solving any problem with the weakest possible tools.
11## The worse-is-better school
24## The worse-is-better school
13−Culturally, Urbit is best described as a functional stack built in
26+Culturally, Urbit is best described as a functional stack built in the
14−the "New Jersey" school of system software design, as described
27+"New Jersey" school of system software design, as described in Richard
15−in Richard Gabriel's famous ["worse is
28+Gabriel's famous ["worse is
16better"](https://en.wikipedia.org/wiki/Worse_is_better) essay.
29better"](https://en.wikipedia.org/wiki/Worse_is_better) essay.
18There are two kinds of mindsets when approaching hard technical
31There are two kinds of mindsets when approaching hard technical
19−problems. The "MIT" mindset, more typical among mathematicians
32+problems. The "MIT" mindset, more typical among mathematicians and
20−and scientists, wants to attack the problem as its simplest and
33+scientists, wants to attack the problem as its simplest and broadest
21−broadest case, producing the most general and powerful solution
34+case, producing the most general and powerful solution available. In
22−available. In short: better-is-better.
35+short: better-is-better.
24The "New Jersey" worse-is-better mentality, more typical among
37The "New Jersey" worse-is-better mentality, more typical among
25−programmers and engineers, wants to do everything possible to
38+programmers and engineers, wants to do everything possible to *not*
26−*not* attack the problem. Can I produce a serviceable
39+attack the problem. Can I produce a serviceable approximation to a
27−approximation to a true solution? Do I actually have to solve
40+true solution? Do I actually have to solve the general problem, or
28−the general problem, or can I reduce it to an easier special
41+can I reduce it to an easier special case? Can I change the product
29−case? Can I change the product so it doesn't have this problem?
42+so it doesn't have this problem?
31−Ideally, anyone building anything has both these mindsets in
44+Ideally, anyone building anything has both these mindsets in their
32−their toolbox. But it's worth noting that (a) Jersey designs
45+toolbox. But it's worth noting that (a) Jersey designs (meaning the
33−(meaning the Bell Labs school that produced Unix, C, and Go) tend
46+Bell Labs school that produced Unix, C, and Go) tend to beat MIT
34−to beat MIT designs in the marketplace, and (b) there are very
47+designs in the marketplace, and (b) there are very few pure-functional
35−few pure-functional systems built with the true Jersey spirit.
48+systems built with the true Jersey spirit.
37## Why Urbit (probably) doesn't need a blockchain
50## Why Urbit (probably) doesn't need a blockchain
39−Nakamoto consensus is an example of better-is-better. The
52+Nakamoto consensus is an example of better-is-better. The blockchain
40−blockchain design is actually more powerful than it needs to be.
53+design is actually more powerful than it needs to be. It's not just a
41−It's not just a trustless decentralized ledger; it's a trustless
54+trustless decentralized ledger; it's a trustless decentralized
42−decentralized database and (as Ethereum has realized; but this
55+database and (as Ethereum has realized; but this idea is clearly
43−idea is clearly present in Bitcoin's scripting language) a
56+present in Bitcoin's scripting language) a general-purpose, zero-trust
44−general-purpose, zero-trust decentralized computer.
57+decentralized computer.
46Again, Urbit is not a general-purpose decentralized database or
59Again, Urbit is not a general-purpose decentralized database or
47−consensus computer. It's a special case of the former, which is
60+consensus computer. It's a special case of the former, which is a
48−a special case of the latter. Urbit is nothing but a digital
61+special case of the latter. Urbit is nothing but a digital title
49−title chain for network addresses. Our belief is that the
62+chain for network addresses. Our belief is that the special case is
50−special case is much easier than the general case, which is why
63+much easier than the general case, which is why Urbit (probably)
51−Urbit (probably) doesn't need a blockchain.
64+doesn't need a blockchain.
53−The rest of this essay describes what makes this special case
66+The rest of this essay describes what makes this special case special,
54−special, and how we can use that to not need full Nakamoto
67+and how we can use that to not need full Nakamoto consensus, or any
55−consensus, or any kind of general-purpose Byzantine agreement.
68+kind of general-purpose Byzantine agreement.
57## The double-sell problem
70## The double-sell problem
59−Urbit has the same basic "double-spend" issue as Bitcoin. As
72+Urbit has the same basic "double-spend" issue as Bitcoin. As Satoshi
60−Satoshi puts it: "The problem of course is the payee can't verify
73+puts it: "The problem of course is the payee can't verify that one of
61−that one of the owners did not double-spend the coin." (Satoshi's
74+the owners did not double-spend the coin." But Urbit is not a
62−grammar is usually better than this.) But Urbit is not a
63currency, so we say "double-selling."
75currency, so we say "double-selling."
65−"Double-selling" means signing over an Urbit address (*ship*) to
77+"Double-selling" means signing over an Urbit address (*ship*) to two
66−two different parties at the same time, presumably with the
78+different parties at the same time, presumably with the intent to sell
67−intent to sell it to both and skip town with the loot.
79+it to both and skip town with the loot.
69−Again, the logical problem is the same. Bitcoin attacks it as a
81+Again, the logical problem is the same. Bitcoin attacks it as a broad
70−broad theoretical breakthrough: better-is-better. Urbit attacks
82+theoretical breakthrough: better-is-better. Urbit attacks it as a
71−it as a narrow special case: worse-is-better.
83+narrow special case: worse-is-better.
73Intuitively, Urbit's answer is that a real-estate transaction is
85Intuitively, Urbit's answer is that a real-estate transaction is
74−substantively a very different thing from a credit-card payment.
86+substantively a very different thing from a credit-card payment. No
75−No real-estate agent ever has ever leaned over the desk, quickly
87+real-estate agent ever has ever leaned over the desk, quickly grabbed
76−grabbed *both* the check and the keys, and run laughing out
88+*both* the check and the keys, and run laughing out the door.
79−To understand more rigorously how Urbit is a special case, let's
90+To understand more rigorously how Urbit is a special case, let's take
80−take a quick look at the Urbit address space and PKI.
91+a quick look at the Urbit address space and PKI.
82## The Urbit address space and PKI
93## The Urbit address space and PKI
84−(NB: this description differs in minor ways from the running
95+(NB: this description differs in minor ways from the running code.
85−code. Where they differ, the description is right. Urbit is not
96+Where they differ, the description is right. Urbit is not at present
86−at present secure: use for entertainment purpose only.)
97+secure: use for entertainment purpose only.)
88An Urbit ship is an unsigned integer that serves four purposes: a
99An Urbit ship is an unsigned integer that serves four purposes: a
89−cryptographic identity, a packet routing address, a stateful
100+cryptographic identity, a packet routing address, a stateful virtual
90−virtual computer, and a unique, human-memorable name.
101+computer, and a unique, human-memorable name.
92Each ship is owned by a private key. To transfer a ship to a new
103Each ship is owned by a private key. To transfer a ship to a new
93keypair, sign the new public key with the old private key. This
104keypair, sign the new public key with the old private key. This
94revokes the old key and activates the new key. Propagating this
105revokes the old key and activates the new key. Propagating this
95−update globally makes the revocation global. This is essentially
106+update globally makes the revocation global. This is essentially the
96−the digital title system a smart 12-year-old would design.
107+digital title system a smart 12-year-old would design.
98### Ships and wills
109### Ships and wills
100−Ships are 128-bit numbers classified into tiers by bitwidth. An
111+Ships are 128-bit numbers classified into tiers by bitwidth. An 8-bit
101−8-bit ship (a number less than 256) is a *galaxy*. A 16-bit ship
112+ship (a number less than 256) is a *galaxy*. A 16-bit ship is a
102−is a *star*. A 32-bit ship is a *planet*. A 64-bit ship is a
113+*star*. A 32-bit ship is a *planet*. A 64-bit ship is a *moon*. A
103−*moon*. A 128-bit ship is a *comet*.
114+128-bit ship is a *comet*.
105−The chain of signatures for each ship is called a *will*. Unlike
116+The chain of signatures for each ship is called a *will*. Unlike most
106−most certificate systems, there is no metadata in an Urbit will.
117+certificate systems, there is no metadata in an Urbit will. Nothing is
107−Nothing is signed but the public-key fingerprint. The length of
118+signed but the public-key fingerprint. The length of the will is the
108−the will is the keypair version that owns the ship. This version
119+keypair version that owns the ship. This version is called its
109−is called its *life*. Each new signed fingerprint in the will is
120+*life*. Each new signed fingerprint in the will is a *deed*.
112−Who gets to create a ship? Comets are fingerprints of a random
122+Who gets to create a ship? Comets are fingerprints of a random
113−keypair. Moons, planets and stars are created by their *prefix*,
123+keypair. Moons, planets and stars are created by their *prefix*, the
114−the ship whose bits are the bottom half of their formal width.
124+ship whose bits are the bottom half of their formal width. For
115−For instance, the star `0xbeef` is the prefix of the planet
125+instance, the star `0xbeef` is the prefix of the planet `0xdeadbeef`.
116−`0xdeadbeef`. Galaxies have their fingerprints hardcoded in the
126+Galaxies have their fingerprints hardcoded in the official kernel.
119−Ship numbers are not generally written in hex. They're written
128+Ship numbers are not generally written in hex. They're written in
120−in Hoon's `@p` syntax, a phonemic base-256. `@p` also permutes
129+Hoon's `@p` syntax, a phonemic base-256. `@p` also permutes within
121−within tiers, to superficially conceal prefix structure; for
130+tiers, to superficially conceal prefix structure; for instance,
122−instance, `0xdead.beef` is `~firbyr-napbes`, while `0xcafe.beef`
131+`0xdead.beef` is `~firbyr-napbes`, while `0xcafe.beef` is
123−is `~nissep-sopnub`.
132+`~nissep-sopnub`.
125### Parent hierarchy
134### Parent hierarchy
127−The prefix of a moon, planet, or star also becomes its *parent*.
136+The prefix of a moon, planet, or star also becomes its *parent*. The
128−The parent of a ship is its natural locus of federated services.
137+parent of a ship is its natural locus of federated services. The most
129−The most basic such service is to mediate P2P routing, as a
138+basic such service is to mediate P2P routing, as a so-called
130−so-called "supernode." But the set of potential federated
139+"supernode." But the set of potential federated services is
131−services is unbounded.
140+unbounded.
133−For moons, each new key update is signed by the parent. Planets
142+For moons, each new key update is signed by the parent. Planets and
134−and stars sign their own updates, making them independent. To
143+stars sign their own updates, making them independent. To prevent
135−prevent denial-of-service attacks by parents against children,
144+denial-of-service attacks by parents against children, stars and
136−stars and planets can *exit*, choosing a new parent. An exit
145+planets can *exit*, choosing a new parent. An exit deed is a key
137−deed is a key update also signed by the new parent.
146+update also signed by the new parent.
139−The full public cryptographic record of a ship is its *dossier*.
148+The full public cryptographic record of a ship is its *dossier*. The
140−The dossier is the set of ship-will pairs, including all parents
149+dossier is the set of ship-will pairs, including all parents and
141−and prefixes recursively, needed to validate the ship's current
150+prefixes recursively, needed to validate the ship's current key. A
142−key. A ship can process a dossier from an untrusted source.
151+ship can process a dossier from an untrusted source.
144−The full set of ship-will pairs a ship knows is its *cabinet*.
153+The full set of ship-will pairs a ship knows is its *cabinet*. So the
145−So the crucial question for PKI propagation is whether a
154+crucial question for PKI propagation is whether a submitted dossier is
146−submitted dossier is accepted into a ship's cabinet.
155+accepted into a ship's cabinet.
148### Propagation race
157### Propagation race
150The rule is simple: any deeds in the dossier which are new (not
159The rule is simple: any deeds in the dossier which are new (not
151−already in the cabinet) must not use keys superseded in the
160+already in the cabinet) must not use keys superseded in the cabinet.
152−cabinet. Otherwise revocation doesn't work. But revocation
161+Otherwise revocation doesn't work. But revocation affects only
153−affects only dossiers received in the future; nothing already in
162+dossiers received in the future; nothing already in the cabinet can be
154−the cabinet can be revoked.
163+revoked.
156−Intuitively, this algorithm creates a propagation race. Life `2`
165+Intuitively, this algorithm creates a propagation race. Life `2` of
157−of `~firbyr-napbes` revokes life `1` of `~firbyr-napbes`, so
166+`~firbyr-napbes` revokes life `1` of `~firbyr-napbes`, so propagating
158−propagating life `2` to the whole network ensures that anyone who
167+life `2` to the whole network ensures that anyone who steals the
159−steals the private key for life `1` can't use it in any way --
168+private key for life `1` can't use it in any way -- whether to launch
160−whether to launch children, or to sign a new, bogus life `2`.
169+children, or to sign a new, bogus life `2`.
162## Solving the special case
171## Solving the special case
164−So how can we solve the double-sell problem, for the special case
173+So how can we solve the double-sell problem, for the special case of
165−of the system designed above?
174+the system designed above?
167### Double-spend relaying in Bitcoin
176### Double-spend relaying in Bitcoin
169−The first thing we need to notice about our special case is that
178+The first thing we need to notice about our special case is that *even
170−*even Bitcoin*, not considered as a general consensus problem but
179+Bitcoin*, not considered as a general consensus problem but just as a
171−just as a decentralized payment rail, isn't that far from *not*
180+decentralized payment rail, isn't that far from *not* needing a
172−needing a blockchain.
181+blockchain.
174−As the Karame ["Two Bitcoins at the Price of One"](http://eprint.iacr.org/2012/248.pdf)
183+As the Karame ["Two Bitcoins at the Price of
175−paper points out:
184+One"](http://eprint.iacr.org/2012/248.pdf) paper points out:
177> An efficient countermeasure to combat double-spending on fast
186> An efficient countermeasure to combat double-spending on fast
178Bitcoin payments would be for Bitcoin peers to propagate alerts
187Bitcoin payments would be for Bitcoin peers to propagate alerts
179whenever they receive two or more transactions that share common
188whenever they receive two or more transactions that share common
180inputs and different outputs.
189inputs and different outputs.
182−"Fast Bitcoin payments" means zero-confirmation, ie, Bitcoin
191+"Fast Bitcoin payments" means zero-confirmation, ie, Bitcoin without
183−without the blockchain. These double-spend alerts have never
192+the blockchain. These double-spend alerts have never been integrated
184−been integrated into Bitcoin Core, despite frequent proposals.
193+into Bitcoin Core, despite frequent proposals. Given that Bitcoin
185−Given that Bitcoin *does* have a blockchain, it seems quite
194+*does* have a blockchain, it seems quite sensible for purists to shun
186−sensible for purists to shun hacks that make zero-conf
187−transactions somewhat more secure. Also, double-spend alerts in
195+hacks that make zero-conf transactions somewhat more secure. Also,
188−Bitcoin are a DoS vulnerability; Bitcoin has fees to control the
196+double-spend alerts in Bitcoin are a DoS vulnerability; Bitcoin has
189−cost of propagating transactions, but who pays for an alert?
197+fees to control the cost of propagating transactions, but who pays for
191−In principle, however, we could imagine a version of Bitcoin
200+In principle, however, we could imagine a version of Bitcoin without a
192−without a blockchain, in which the mempool was the ledger, and
201+blockchain, in which the mempool was the ledger, and there was an
193−there was an alerting and/or conflict model to detect and resolve
202+alerting and/or conflict model to detect and resolve double spends.
194−double spends. An accepted transaction is simply one that
203+An accepted transaction is simply one that propagates to one or more
195−propagates to one or more randomly chosen observer nodes.
204+randomly chosen observer nodes.
197This design, for the problem that Bitcoin is solving, intuitively
206This design, for the problem that Bitcoin is solving, intuitively
198feels weak and a little hacky. The Karame paper is not actually
207feels weak and a little hacky. The Karame paper is not actually
199advocating for removing the blockchain from Bitcoin. At the same
208advocating for removing the blockchain from Bitcoin. At the same
200time, low-value zero-confirmation payments are commonly used.
209time, low-value zero-confirmation payments are commonly used.
202−One way to think about security is to flip the tables and think
211+One way to think about security is to flip the tables and think of the
203−of the defender as the attacker, and vice versa. Just imagine
212+defender as the attacker, and vice versa. Just imagine you have some
204−you have some moral right to double spend. The rest of the world
213+moral right to double spend. The rest of the world is unfairly trying
205−is unfairly trying to stop you. Can you defend yourself?
214+to stop you. Can you defend yourself?
207In the context of a gossip network that shares all the things, a
216In the context of a gossip network that shares all the things, a
208procedure that involves telling one person one thing, and another
217procedure that involves telling one person one thing, and another
@@ -211,52 +220,51 @@ unfair world which believes there should be only one truth, is
211inherently quite fragile. And where the attack is fragile, the
220inherently quite fragile. And where the attack is fragile, the
212defense is robust.
221defense is robust.
214−Most of the security in any digital title system comes from the
223+Most of the security in any digital title system comes from the PKI
215−PKI itself. The double-spend problem, the general issue of
224+itself. The double-spend problem, the general issue of Byzantine
216−Byzantine failures in information propagation, is already a
225+failures in information propagation, is already a corner case. So
217−corner case. So perhaps we can solve it as a corner case.
226+perhaps we can solve it as a corner case.
219−Again: *even Bitcoin* isn't that far from being able to build
228+Again: *even Bitcoin* isn't that far from being able to build a
220−a practical decentralized ledger without a blockchain. The same
229+practical decentralized ledger without a blockchain. The same gossip
221−gossip model that broadcasts nonconflicting transactions is
230+model that broadcasts nonconflicting transactions is not at all
222−not at all incapable of reacting to conflicting transactions.
231+incapable of reacting to conflicting transactions. We're not really
223−We're not really recommending that Bitcoin ditch the blockchain,
232+recommending that Bitcoin ditch the blockchain, but this gives us hope
224−but this gives us hope with our fundamentally easier problem.
233+with our fundamentally easier problem.
226## Various specific specialnesses
235## Various specific specialnesses
228−What are the differences between the Urbit double-sell problem
237+What are the differences between the Urbit double-sell problem and the
229−and the Bitcoin double-spend problem? Is our special case
238+Bitcoin double-spend problem? Is our special case really, truly,
230−really, truly, special?
239+special?
232−In worse-is-better mode, we want every special-case advantage we
241+In worse-is-better mode, we want every special-case advantage we can
233−can get. Every difference we find is one we can use as a
242+get. Every difference we find is one we can use as a leverage point.
236### Minimal transaction interdependency
244### Minimal transaction interdependency
238−The first major technical difference between the Urbit title
246+The first major technical difference between the Urbit title history
239−history and the Bitcoin blockchain is that Bitcoin and its
247+and the Bitcoin blockchain is that Bitcoin and its relatives are
240−relatives are designed to secure a complete, interdependent,
248+designed to secure a complete, interdependent, collective transaction
241−collective transaction history. Except for the parent-child
249+history. Except for the parent-child relationship, Urbit wills are
242−relationship, Urbit wills are independent of each other.
250+independent of each other.
244−Bitcoin's use of UTXOs rather than balances reduces
252+Bitcoin's use of UTXOs rather than balances reduces interdependency
245−interdependency somewhat. But the validity of each transaction
253+somewhat. But the validity of each transaction is still dependent on
246−is still dependent on all the transactions that created its
254+all the transactions that created its inputs. (Ethereum drops the
247−inputs. (Ethereum drops the UTXO model, whose value in reducing
255+UTXO model, whose value in reducing dependencies may not match its
248−dependencies may not match its cost in complexity.)
256+cost in complexity.)
250Urbit is not a payment system or a shared ledger. Bitcoins are
258Urbit is not a payment system or a shared ledger. Bitcoins are
251−divisible, but Urbit ships aren't. An Urbit will containing
259+divisible, but Urbit ships aren't. An Urbit will containing its
252−its parent chain is self-validating and has no dependencies.
260+parent chain is self-validating and has no dependencies. There is no
253−There is no collective history. There is no Merkle tree. There
261+collective history. There is no Merkle tree. There is no chain, with
254−is no chain, with or without blocks.
262+or without blocks.
256This simplification doesn't eliminate the double-sell problem in
264This simplification doesn't eliminate the double-sell problem in
257−theory, but makes it much more tractable in practice. The set of
265+theory, but makes it much more tractable in practice. The set of past
258−past transactions (key transfers) that a new transaction could
266+transactions (key transfers) that a new transaction could conflict
259−conflict with is much smaller.
267+with is much smaller.
261### Trust hierarchy and governance structure
269### Trust hierarchy and governance structure
@@ -264,353 +272,349 @@ The second major technical difference is that Bitcoin is a flat,
264trustless, fully decentralized system. Urbit has a hierarchical,
272trustless, fully decentralized system. Urbit has a hierarchical,
265polycentric governance system which is a trust hierarchy.
273polycentric governance system which is a trust hierarchy.
267−Now and for quite some time, urbits default to automatically
275+Now and for quite some time, urbits default to automatically accepting
268−accepting OS updates from their parent, making this trust
276+OS updates from their parent, making this trust effectively absolute.
269−effectively absolute. This is not a novelty -- all "evergreen"
277+This is not a novelty -- all "evergreen" browsers now work this way.
270−browsers now work this way. You trust your browser quite a bit,
271−which means you trust your browser vendor.
278+You trust your browser quite a bit, which means you trust your browser
273−And since few Bitcoin node operators code their own daemons, the
281+And since few Bitcoin node operators code their own daemons, the same
274−same dependency on a source distribution exists in Bitcoin. It's
282+dependency on a source distribution exists in Bitcoin. It's informal
275−informal and off-chain, though, which is not really a good thing.
283+and off-chain, though, which is not really a good thing. (Urbit is
276−(Urbit is like if Bitcoin Core hotpatched itself automatically by
284+like if Bitcoin Core hotpatched itself automatically by publishing
277−publishing source-code diffs on the blockchain.)
285+source-code diffs on the blockchain.)
279To be on the safe side, we should think of Urbit as a centralized
287To be on the safe side, we should think of Urbit as a centralized
280system until the OS update that turns off automatic updates is
288system until the OS update that turns off automatic updates is
281−shipped. This of course requires a certain measure of
289+shipped. This of course requires a certain measure of perfection,
282−perfection, which cannot in any way be predicted.
290+which cannot in any way be predicted.
284−After Arvo proper becomes "deciduous" (apps will of course always
292+After Arvo proper becomes "deciduous" (apps will of course always be
285−be remotely hotpatched), child-to-parent trust should diminish to
293+remotely hotpatched), child-to-parent trust should diminish to the
286−the power of the parent to deny service to the child. This will
294+power of the parent to deny service to the child. This will always be
287−always be present without some major redesign.
295+present without some major redesign.
289But it's opposed by the equal and opposite power of the child to
297But it's opposed by the equal and opposite power of the child to
290switch to a different parent, creating a competitive market in
298switch to a different parent, creating a competitive market in
291−governance. This should deliver service at the highest quality
299+governance. This should deliver service at the highest quality and
292−and lowest price, fortifying trust with incentives. The power
300+lowest price, fortifying trust with incentives. The power of a
293−of a restaurant owner to deny you service does not give the food
301+restaurant owner to deny you service does not give the food industry
294−industry the power to starve you to death.
302+the power to starve you to death.
296−And if no parent wants your business, with 2^16 stars who could
304+And if no parent wants your business, with 2^16 stars who could accept
297−accept it, you probably shouldn't be on the network at all.
305+it, you probably shouldn't be on the network at all. Urbit, like a
298−Urbit, like a real society, is designed to be a network of
306+real society, is designed to be a network of incentives that holds
299−incentives that holds everyone in productive tension. We want
307+everyone in productive tension. We want everyone to be free, and no
300−everyone to be free, and no one to be unaccountable.
308+one to be unaccountable.
302For example: a parent which extends its will also needs to send
310For example: a parent which extends its will also needs to send
303−updated signatures to its children and former children. Either
311+updated signatures to its children and former children. Either will
304−will otherwise be unable to propagate their dossiers to ships
312+otherwise be unable to propagate their dossiers to ships whose
305−whose cabinets have the updated parent will, *even if some other
313+cabinets have the updated parent will, *even if some other parent
306−parent adopts them*.
314+adopts them*.
308−But Urbit is a collectively governed and updatable system. A
316+But Urbit is a collectively governed and updatable system. A star or
309−star or galaxy which denies service to its own children will (a)
317+galaxy which denies service to its own children will (a) get a bad
310−get a bad reputation, (b) drive its children to other parents,
318+reputation, (b) drive its children to other parents, and (c) force the
311−and (c) force the network to hardcode a ship-specific exception
319+network to hardcode a ship-specific exception into the propagation
312−into the propagation algorithm, overriding stale-key revocation.
320+algorithm, overriding stale-key revocation.
314−In theory, a parent can extort its children by denying service.
322+In theory, a parent can extort its children by denying service. In
315−In practice, since Urbit is self-governing, not ungoverned, and
323+practice, since Urbit is self-governing, not ungoverned, and its
316−its government can right this wrong with a source-code patch,
324+government can right this wrong with a source-code patch, the
317−the extortion won't work. So it won't happen. So the act of
325+extortion won't work. So it won't happen. So the act of government
318−government won't be necessary, and won't happen either.
326+won't be necessary, and won't happen either.
320−Of course a perfectly decentralized system would be freer. But
328+Of course a perfectly decentralized system would be freer. But worse,
321−worse, as usual, is better. And since we are paying for this
329+as usual, is better. And since we are paying for this worseness,
322−worseness, imperfect decentralization, we'd like to get all the
330+imperfect decentralization, we'd like to get all the mileage out of it
323−mileage out of it that we can.
331+that we can.
325−Again, Urbit, not being a trustless system, does not have to
333+Again, Urbit, not being a trustless system, does not have to solve the
326−solve the trustless consensus problem -- although we still very
334+trustless consensus problem -- although we still very much want to
327−much want to minimize and bound the delegation of trust. This is
335+minimize and bound the delegation of trust. This is an obvious
328−an obvious relaxation of Bitcoin's hard theoretical problem.
336+relaxation of Bitcoin's hard theoretical problem.
330### Routing: security through topology
338### Routing: security through topology
332−Please don't laugh. Security through routing topology isn't a
340+Please don't laugh. Security through routing topology isn't a joke --
333−joke -- unless firewalls are a joke. Cisco sells too many
341+unless firewalls are a joke. Cisco sells too many firewalls for them
334−firewalls for them to be a joke.
342+to be a joke.
336−In Bitcoin we may have all sorts of reasons to ask what ship
344+In Bitcoin we may have all sorts of reasons to ask what ship holds
337−holds what coins. In Urbit, when we ask what key controls an
345+what coins. In Urbit, when we ask what key controls an ship, we are
338−ship, we are either sending or receiving a message. Is our
346+either sending or receiving a message. Is our outgoing message safely
339−outgoing message safely sealed to the current owner? Is our
340−incoming message properly signed by the current owner?
347+sealed to the current owner? Is our incoming message properly signed
348+by the current owner?
342When the parent also forwards all packets until a P2P link is
350When the parent also forwards all packets until a P2P link is
343−established (Urbit forwarding resolves to STUN if either party
351+established (Urbit forwarding resolves to STUN if either party has
344−has full cone NAT, TURN if not), we can design in all kinds of
352+full cone NAT, TURN if not), we can design in all kinds of
345interactions between routing and certificate management.
353interactions between routing and certificate management.
347In particular, a parent which is a single source of truth in some
355In particular, a parent which is a single source of truth in some
348−sense is a very attractive design element. Again, we're paying
356+sense is a very attractive design element. Again, we're paying for
349−for our imperfect decentralization. We might as well use it.
357+our imperfect decentralization. We might as well use it.
351−For example: I want to send a packet to ship X. Two parties,
359+For example: I want to send a packet to ship X. Two parties, A and B,
352−A and B, are competing for ownership of X. A is the rightful
360+are competing for ownership of X. A is the rightful owner. I am
353−owner. I am secure against B if either of these conditions are
361+secure against B if either of these conditions are true: my packet can
354−true: my packet can only be decoded by A, or my packet is not
362+only be decoded by A, or my packet is not sent to B. Both would be
355−sent to B. Both would be ideal, of course. Either will do.
363+ideal, of course. Either will do.
357### Latency and friction tolerance
365### Latency and friction tolerance
359−Confirmed Bitcoin payments aren't especially low-latency by
367+Confirmed Bitcoin payments aren't especially low-latency by payment
360−payment standards. They're reasonably low-friction by payment
368+standards. They're reasonably low-friction by payment standards. But
361−standards. But fees are certainly a thing.
369+fees are certainly a thing.
363−Urbit is digital real estate, not digital money. When we look at
371+Urbit is digital real estate, not digital money. When we look at the
364−the standards of latency and friction in actual real estate --
372+standards of latency and friction in actual real estate -- where a
365−where a transaction that takes a week is super-fast, a 5% payment
373+transaction that takes a week is super-fast, a 5% payment overhead is
366−overhead is normal, and a third-party intermediary is standard --
374+normal, and a third-party intermediary is standard -- we see a much,
367−we see a much, much weaker set of requirements.
375+much weaker set of requirements.
369Obviously a week and a 5% overhead are incredibly sucky levels of
377Obviously a week and a 5% overhead are incredibly sucky levels of
370latency and friction. The point is that even if this is the only
378latency and friction. The point is that even if this is the only
371−level of performance Urbit can achieve, that's not necessarily
379+level of performance Urbit can achieve, that's not necessarily the end
372−the end of the world for Urbit.
380+of the world for Urbit.
374−For instance: if we wait a week for a double-sell alert, and we
382+For instance: if we wait a week for a double-sell alert, and we don't
375−don't see one, either the gossip network is totally hosed (to a
383+see one, either the gossip network is totally hosed (to a point we'd
376−point we'd surely find out about), or there wasn't a double-sell.
384+surely find out about), or there wasn't a double-sell. This stuff is
377−This stuff is just not that hard.
385+just not that hard.
379(One little-made point about Bitcoin, by the way, is that Bitcoin
387(One little-made point about Bitcoin, by the way, is that Bitcoin
380−enables trust-free *payments*, but not trust-free *exchanges*.
388+enables trust-free *payments*, but not trust-free *exchanges*. The
381−The seller still needs to deliver the goods either before or
389+seller still needs to deliver the goods either before or after the
382−after the payment; in either case, there is trust. Only Ethereum
390+payment; in either case, there is trust. Only Ethereum can solve this
383−can solve this problem -- and only for digital exchanges.)
391+problem -- and only for digital exchanges.)
385## We can afford to be patient
393## We can afford to be patient
387−With a better-is-better, general-purpose solution, one size fits
395+With a better-is-better, general-purpose solution, one size fits all
388−all until the end of time. With a worse-is-better, special-case
396+until the end of time. With a worse-is-better, special-case solution,
389−solution, the details of that case are critical.
397+the details of that case are critical.
391But we actually don't know these details. One rule of the
399But we actually don't know these details. One rule of the
392−worse-is-better school: never solve a problem before you have to.
400+worse-is-better school: never solve a problem before you have to. You
393−You don't know all the details, and you need those details. (Of
401+don't know all the details, and you need those details. (Of course,
394−course, with the better-is-better approach, the details don't
402+with the better-is-better approach, the details don't matter at all.)
397Is there such a thing as a transitive adjective? Grammarians are
404Is there such a thing as a transitive adjective? Grammarians are
398−unclear. But technically, the adjective "secure" is always an
405+unclear. But technically, the adjective "secure" is always an error.
399−error. Nothing is "secure." "Secure against X" is the correct
406+Nothing is "secure." "Secure against X" is the correct usage, where X
400−usage, where X is some threat model.
407+is some threat model.
402−Urbit is an insecure test network with no sensitive data on it.
409+Urbit is an insecure test network with no sensitive data on it. This
403−This will remain true for a while. No Urbit ship has ever
410+will remain true for a while. No Urbit ship has ever been transferred
404−been transferred cryptographically. This will also remain the
411+cryptographically. This will also remain the status quo for quite a
405−status quo for quite a while.
412+while.
407−We *don't know the threat model*. We *can't solve the problem*.
414+We *don't know the threat model*. We *can't solve the problem*. It's
408−It's as simple as that. The best Urbit can do, at the present
415+as simple as that. The best Urbit can do, at the present time, is map
409−time, is map out the ballpark of solutions.
416+out the ballpark of solutions.
411−And we have time to proceed patiently. One way to think about
418+And we have time to proceed patiently. One way to think about the
412−the timing of cryptographic decentralization is to look at the
419+timing of cryptographic decentralization is to look at the DNS. It's
413−DNS. It's clear that now, a decentralized DNS with cryptographic
420+clear that now, a decentralized DNS with cryptographic domain-name
414−domain-name titles would be extremely desirable. It was never
421+titles would be extremely desirable. It was never designed to happen.
415−designed to happen. It will probably never happen.
422+It will probably never happen.
417−But if we look at when cryptographic DNS with allodial title
424+But if we look at when cryptographic DNS with allodial title *should*
418−*should* have happened, it's probably sometime in the mid-90s.
425+have happened, it's probably sometime in the mid-90s. Ie, after over a
419−Ie, after over a decade of production use of the Domain Name
426+decade of production use of the Domain Name System. In short: there's
420−System. In short: there's no need to hurry here.
427+no need to hurry here.
422## A map of the solution space
429## A map of the solution space
424−But we still need a map of the worse-is-better ballpark. Let's
431+But we still need a map of the worse-is-better ballpark. Let's look
425−look at some options, from least secure to most.
432+at some options, from least secure to most.
427−The essential question we can't answer, without a better sense of
434+The essential question we can't answer, without a better sense of the
428−the threat model, is how aggressively we need to propagate wills.
435+threat model, is how aggressively we need to propagate wills. We
429−We especially are not sure about the threat model of malicious
436+especially are not sure about the threat model of malicious stars
430−stars (16-bit ships) and/or galaxies (8-bit ships).
437+(16-bit ships) and/or galaxies (8-bit ships).
432−We need to know what kinds of double-sell attacks are plausible.
439+We need to know what kinds of double-sell attacks are plausible. Since
433−Since we don't know this yet, we need not one propagation design,
440+we don't know this yet, we need not one propagation design, but a
434−but a range of designs -- stretching all the way up to a full
441+range of designs -- stretching all the way up to a full blockchain.
437### Acceptance model
443### Acceptance model
439What doesn't change is the will *acceptance* model. A ship will
445What doesn't change is the will *acceptance* model. A ship will
440−always accept a new will if (a) the new will extends the old
446+always accept a new will if (a) the new will extends the old will, (b)
441−will, (b) the parent signature on the initial public key is at
447+the parent signature on the initial public key is at least as recent
442−least as recent as the ship's current version of that parent.
448+as the ship's current version of that parent.
444The parent clause implies that when a parent extends its will, it
450The parent clause implies that when a parent extends its will, it
445needs to send updated initial signatures to all the children it's
451needs to send updated initial signatures to all the children it's
446−launched. Otherwise, their own future updates will not be
452+launched. Otherwise, their own future updates will not be accepted by
447−accepted by ships that have seen the parent's update.
453+ships that have seen the parent's update.
449−This is not a big deal in the world of parent responsibilities.
455+This is not a big deal in the world of parent responsibilities. But
450−But like many such responsibilities, it lets a badly operated
456+like many such responsibilities, it lets a badly operated parent deny
451−parent deny service to its children.
457+service to its children.
453−A ship accepts all wills, new or updated, and stores them
459+A ship accepts all wills, new or updated, and stores them permanently.
454−permanently. If this is abused trivially as a DoS vector, Urbit
460+If this is abused trivially as a DoS vector, Urbit will mitigate it by
455−will mitigate it by the usual technique of degrading service to
461+the usual technique of degrading service to non-scarce ship tiers.
456−non-scarce ship tiers. Scarcity rules.
462+Scarcity rules.
458### Level 0: passive propagation only
464### Level 0: passive propagation only
460−The Ames protocol can piggyback a will on any packet. Each ship
466+The Ames protocol can piggyback a will on any packet. Each ship also
461−also permanently records which other ships hold which version of
467+permanently records which other ships hold which version of its own
462−its own will. An update is automatically sent when needed.
468+will. An update is automatically sent when needed.
464−With level 0 propagation, all key exchanges in Ames are passive
470+With level 0 propagation, all key exchanges in Ames are passive and
465−and invisible to the programmer. When the sender has no will or
471+invisible to the programmer. When the sender has no will or symmetric
466−symmetric key for the receiver, the packet is signed, bundled
472+key for the receiver, the packet is signed, bundled with the will, and
467−with the will, and sent as cleartext.
473+sent as cleartext.
469−Signed cleartext? If you have no will for a peer, you've never
475+Signed cleartext? If you have no will for a peer, you've never talked
470−talked to this ship before. Your first words to a stranger
476+to this ship before. Your first words to a stranger probably won't be
471−probably won't be super secret. If this isn't true, the
477+super secret. If this isn't true, the programmer has to send an
472−programmer has to send an innocuous message first and wait for it
478+innocuous message first and wait for it to be acknowledged. Kicking a
473−to be acknowledged. Kicking a rare corner case up to the
474−programmer is a classic worse-is-better move.
479+rare corner case up to the programmer is a classic worse-is-better
476−With level 0 propagation only (the current implementation,
482+With level 0 propagation only (the current implementation, because we
477−because we don't even care about key updates yet), an updated
483+don't even care about key updates yet), an updated does not
478−does not effectively revoke the old key. If Alice updates to a
484+effectively revoke the old key. If Alice updates to a new key,
479−new key, Mallory steals the old key, then Mallory talks to Bob
485+Mallory steals the old key, then Mallory talks to Bob before Alice
480−before Alice does, Mallory can impersonate Alice.
486+does, Mallory can impersonate Alice.
482So not only does level 0 not solve double-sell, it's also quite
488So not only does level 0 not solve double-sell, it's also quite
483−insecure. But it's still fine for now (because Urbit isn't
489+insecure. But it's still fine for now (because Urbit isn't really
484−really decentralized yet).
490+decentralized yet).
486### Level 1: neighbor-only propagation with parent filtering
492### Level 1: neighbor-only propagation with parent filtering
488−The list of other ships which hold your will, essentially the
494+The list of other ships which hold your will, essentially the list of
489−list of all ships you've talked to, is your list of *neighbors*.
495+all ships you've talked to, is your list of *neighbors*. You
490−You essentially have permanent, if perhaps very sporadic,
496+essentially have permanent, if perhaps very sporadic, conversations
491−conversations with all your cryptographic neighbors. Symmetric
497+with all your cryptographic neighbors. Symmetric keys time out fast,
492−keys time out fast, but wills are held forever.
498+but wills are held forever.
494−By proactively pinging all your neighbors when you extend your
500+By proactively pinging all your neighbors when you extend your will,
495−will, you prevent anyone who finds the old private key (ideally
501+you prevent anyone who finds the old private key (ideally you update
496−you update when your old key is stale, not when it's actually
502+when your old key is stale, not when it's actually been *stolen*) from
497−been *stolen*) from jumping into these conversations.
503+jumping into these conversations.
499−What about non-neighbors? We add a second feature: a parent will
505+What about non-neighbors? We add a second feature: a parent will only
500−only forward a packet if its sender matches the current will. So
506+forward a packet if its sender matches the current will. So updating
501−updating your parent (who is always your neighbor) transforms it
507+your parent (who is always your neighbor) transforms it
503−There are two cases: where Alice's parent Trent is also Bob's
509+There are two cases: where Alice's parent Trent is also Bob's parent,
504−parent, and where Bob has a separate parent Walter. In the first
510+and where Bob has a separate parent Walter. In the first case, the
505−case, the expected packet flow is that Alice will send the packet
511+expected packet flow is that Alice will send the packet to Trent, who
506−to Trent, who sends it to Bob. In the second case, Trent sends
512+sends it to Bob. In the second case, Trent sends it to Walter, who
507−it to Walter, who sends it to Bob.
513+sends it to Bob.
509−In either flow, Bob or Walter is sure that the packet came
515+In either flow, Bob or Walter is sure that the packet came through
510−through Trent. Since Trent is Alice's parent and hence Alice's
516+Trent. Since Trent is Alice's parent and hence Alice's neighbor, and
511−neighbor, and hence is updated, Trent will forward no packets
517+hence is updated, Trent will forward no packets from Mallory. So
512−from Mallory. So Mallory has no way to reach Bob.
518+Mallory has no way to reach Bob.
514Non-neighborly packets not matching this flow can't be accepted.
520Non-neighborly packets not matching this flow can't be accepted.
515−Suppose Mallory gets Bob's public IP address directly? If Bob
521+Suppose Mallory gets Bob's public IP address directly? If Bob gets a
516−gets a non-forwarded packet marked "Alice," but Alice is not his
522+non-forwarded packet marked "Alice," but Alice is not his neighbor,
517−neighbor, that's super weird. He must reject the packet.
523+that's super weird. He must reject the packet.
519−Level 1 is nice because it provides a reasonable level of
525+Level 1 is nice because it provides a reasonable level of security,
520−security, but it's still extremely simple. Not only does it not
526+but it's still extremely simple. Not only does it not use a
521−use a blockchain, it doesn't even need a gossip flood!
527+blockchain, it doesn't even need a gossip flood!
523−And level 1 propagation also does a competent worse-is-better job
529+And level 1 propagation also does a competent worse-is-better job on
524−on the double-sell problem. Trent simply becomes the single
530+the double-sell problem. Trent simply becomes the single source of
525−source of truth. The buyer of Alice needs to check that Trent,
531+truth. The buyer of Alice needs to check that Trent, her parent, has
526−her parent, has Alice's latest will from the buyer's perspective.
532+Alice's latest will from the buyer's perspective. If Alice's seller
527−If Alice's seller propagates a different fork to other ships,
533+propagates a different fork to other ships, this damages Alice's
528−this damages Alice's ability to communicate, but produces no
534+ability to communicate, but produces no obvious gain for the seller.
529−obvious gain for the seller.
531Level 1 puts a lot of security weight on the parent. If Trent
536Level 1 puts a lot of security weight on the parent. If Trent
532−misbehaves, for example by not filtering Mallory's packets, Alice
537+misbehaves, for example by not filtering Mallory's packets, Alice can
533−can be impersonated. And its solution to the double-sell problem
538+be impersonated. And its solution to the double-sell problem is
534−is adequate, but not ideal. Level 1 is the worse-is-better sweet
539+adequate, but not ideal. Level 1 is the worse-is-better sweet spot
535−spot for a young Urbit, but will probably give way to level 2.
540+for a young Urbit, but will probably give way to level 2.
537### Level 2: broadcast all wills
542### Level 2: broadcast all wills
539We can't say definitively that level 1 will be inadequate. But
544We can't say definitively that level 1 will be inadequate. But
540−intuitively, it feels slightly weak. We will probably need a
545+intuitively, it feels slightly weak. We will probably need a gossip
541−gossip protocol.
546+protocol.
543The only ships that can be transferred are galaxies, stars and
548The only ships that can be transferred are galaxies, stars and
544planets; if all updates of all wills of all these major ships are
549planets; if all updates of all wills of all these major ships are
545−broadcast, we hardly have a scaling problem like Bitcoin's. Even
550+broadcast, we hardly have a scaling problem like Bitcoin's. Even if
546−if changing the lock on your front door counted as a real-estate
551+changing the lock on your front door counted as a real-estate
547transaction, there are a lot fewer real-estate transactions than
552transaction, there are a lot fewer real-estate transactions than
548credit-card payments.
553credit-card payments.
550−Moreover, conflict detection (double-sell alerts) is a natural
555+Moreover, conflict detection (double-sell alerts) is a natural part of
551−part of any gossip protocol. Gossip should be between stars, not
556+any gossip protocol. Gossip should be between stars, not directly
552−directly between planets; horizontal gossip, vertical
557+between planets; horizontal gossip, vertical distribution.
553−distribution. Star-to-planet distribution may still be limited.
558+Star-to-planet distribution may still be limited.
555−Especially since stars are somewhat trusted, ganking a gossip
560+Especially since stars are somewhat trusted, ganking a gossip protocol
556−protocol with random update edges is incredibly hard and requires
561+with random update edges is incredibly hard and requires a pretty
557−a pretty preposterous conspiracy. And flooding all planet wills
562+preposterous conspiracy. And flooding all planet wills does a lot to
558−does a lot to keep stars honest. It would be incredibly stupid
563+keep stars honest. It would be incredibly stupid for a star to try a
559−for a star to try a double-sell attack against its own planets,
564+double-sell attack against its own planets, but code is always more
560−but code is always more powerful than mere incentives.
565+powerful than mere incentives.
562−Finally, the exit model isn't fully baked yet, but it will
567+Finally, the exit model isn't fully baked yet, but it will probably
563−probably have more aggressive propagation needs. What's clear is
568+have more aggressive propagation needs. What's clear is that an exit
564−that an exit statement is another type of will entry, involving a
569+statement is another type of will entry, involving a signature both
565−signature both from the previous key and the new parent. You can
570+from the previous key and the new parent. You can only escape to
566−only escape to another ship of your parent's class that agrees to
571+another ship of your parent's class that agrees to adopt you.
569−In general, because escaping need to work for routing (without
573+In general, because escaping need to work for routing (without the
570−the cooperation of the former parent), wills containing an exit
574+cooperation of the former parent), wills containing an exit statement
571−statement (a planet moving to a new star, or a star moving to a
575+(a planet moving to a new star, or a star moving to a new galaxy)
572−new galaxy) exit) probably need to be flooded globally among all
576+exit) probably need to be flooded globally among all 8-bit galaxies
573−8-bit galaxies and 16-bit stars. Exits should be rare, so they
577+and 16-bit stars. Exits should be rare, so they shouldn't present
574−shouldn't present much of a scaling problem.
578+much of a scaling problem.
576### Level 3: full blockchain
580### Level 3: full blockchain
578−Obviously a blockchain can solve Urbit's problem. Probably the
582+Obviously a blockchain can solve Urbit's problem. Probably the right
579−right thing to do would be to use the Bitcoin blockchain, and
583+thing to do would be to use the Bitcoin blockchain, and confirm the
580−confirm the current Urbit key version with a "colored coin" of
584+current Urbit key version with a "colored coin" of some kind. (This
581−some kind. (This should not be confused with the orthogonal
585+should not be confused with the orthogonal idea of representing Urbit
582−idea of representing Urbit *invitations* as colored coins.)
586+*invitations* as colored coins.)
584−This involves making all Urbit ships into Bitcoin SPV nodes at
588+This involves making all Urbit ships into Bitcoin SPV nodes at the
585−the least. Not the worst fate in the world, but also a cost.
589+least. Not the worst fate in the world, but also a cost.
586−Alternatively, Urbit could have its own "altcoin" blockchain,
590+Alternatively, Urbit could have its own "altcoin" blockchain, with
587−with actual Urbit-specific mining.
591+actual Urbit-specific mining.
589−Again, given that level 2 seems like it should work quite well,
593+Again, given that level 2 seems like it should work quite well, it's
590−it's hard to see why level 3 propagation would be needed. But we
594+hard to see why level 3 propagation would be needed. But we can't
591−can't really know at this point. There's a reason Urbit can
595+really know at this point. There's a reason Urbit can update itself
592−update itself over the air. That's why we say: Urbit (probably)
596+over the air. That's why we say: Urbit (probably) doesn't need a
593−doesn't need a blockchain. If it does, we can retrofit it.
597+blockchain. If it does, we can retrofit it.
595## Retrospective note
599## Retrospective note
597−This essay has presented the Urbit cryptographic title as a
601+This essay has presented the Urbit cryptographic title as a low-power,
598−low-power, stripped-down, worse-is-better variation of Nakamoto
602+stripped-down, worse-is-better variation of Nakamoto consensus.
599−consensus. That's clearly the right way to introduce it in 2016.
603+That's clearly the right way to introduce it in 2016.
601−Actually, though, this part of Urbit was designed before the
605+Actually, though, this part of Urbit was designed before the Bitcoin
602−Bitcoin paper was published. There were other academic
606+paper was published. There were other academic approaches to
603−approaches to Byzantine consensus, but certainly none validated
607+Byzantine consensus, but certainly none validated on a large scale as
604−on a large scale as Nakamoto consensus has been. It never seemed
608+Nakamoto consensus has been. It never seemed appropriate to treat
605−appropriate to treat cryptographic titles to network addresses as
609+cryptographic titles to network addresses as a case of generalized
606−a case of generalized Byzantine consensus, and without the
610+Byzantine consensus, and without the existence of Bitcoin there was no
607−existence of Bitcoin there was no temptation in this direction.
611+temptation in this direction.
609−In a sense the secret of PKIs is that PKIs are easy. What's hard
613+In a sense the secret of PKIs is that PKIs are easy. What's hard is
610−is adapting an existing identity and authorization structure into
614+adapting an existing identity and authorization structure into a PKI.
611−a PKI. If you build the simplest possible PKI, then force the
615+If you build the simplest possible PKI, then force the human processes
612−human processes to fit themselves to the protocol instead of vice
616+to fit themselves to the protocol instead of vice versa, you have a
613−versa, you have a much easier job. Similarly, if you are not
617+much easier job. Similarly, if you are not adding PKI to an existing
614−adding PKI to an existing network, but building the network and
618+network, but building the network and the PKI as one system, many
615−the PKI as one system, many simplifications are possible. This
619+simplifications are possible. This is once again the classic
616−is once again the classic worse-is-better method.
620+worse-is-better method.