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