Update internal links

app/pages/literature/bit-gold.html

@@ -5,7 +5,7 @@
 
 <p>Thus, it would be very nice if there were a protocol whereby unforgeably costly bits could be created online with minimal dependence on trusted third parties, and then securely stored, transferred, and assayed with similar minimal trust. Bit gold.</p>
 
-<p>My proposal for bit gold is based on computing a string of bits from a string of challenge bits, using functions called variously "client puzzle function," "proof of work function," or <a href="http://szabo.best.vwh.net/intrapoly.html">"secure benchmark function."</a> The resulting string of bits is the proof of work. Where a <a href="http://en.wikipedia.org/wiki/One_way_function">one-way function</a> is prohibitively difficult to compute backwards, a secure benchmark function ideally comes with a specific cost, measured in compute cycles, to compute backwards.</p>
+<p>My proposal for bit gold is based on computing a string of bits from a string of challenge bits, using functions called variously "client puzzle function," "proof of work function," or <a href="/intrapolynomial-cryptography/">"secure benchmark function."</a> The resulting string of bits is the proof of work. Where a <a href="http://en.wikipedia.org/wiki/One_way_function">one-way function</a> is prohibitively difficult to compute backwards, a secure benchmark function ideally comes with a specific cost, measured in compute cycles, to compute backwards.</p>
 
 <p>Here are the main steps of the bit gold system that I envision:</p>
 
@@ -31,7 +31,7 @@
 
 <p>Hal Finney has implemented a variant of bit gold called <a href="http://rpow.net/">RPOW</a> (Reusable Proofs of Work). This relies on publishing the computer code for the "mint," which runs on a remote tamper-evident computer. The purchaser of of bit gold can then use remote attestation, which Finney calls the <a href="http://rpow.net/security.html">transparent server</a> technique, to verify that a particular number of cycles were actually performed.</p>
 
-<p>The main problem with all these schemes is that proof of work schemes depend on computer architecture, not just an abstract mathematics based on an abstract "compute cycle." (<a href="http://szabo.best.vwh.net/intrapoly.html">I wrote about this obscurely several years ago.</a>) Thus, it might be possible to be a very low cost producer (by several orders of magnitude) and swamp the market with bit gold. However, since bit gold is timestamped, the time created as well as the mathematical difficulty of the work can be automatically proven. From this, it can usually be inferred what the cost of producing during that time period was.</p>
+<p>The main problem with all these schemes is that proof of work schemes depend on computer architecture, not just an abstract mathematics based on an abstract "compute cycle." (<a href="/intrapolynomial-cryptography/">I wrote about this obscurely several years ago.</a>) Thus, it might be possible to be a very low cost producer (by several orders of magnitude) and swamp the market with bit gold. However, since bit gold is timestamped, the time created as well as the mathematical difficulty of the work can be automatically proven. From this, it can usually be inferred what the cost of producing during that time period was.</p>
 
 <p>Unlike fungible atoms of gold, but as with collector's items, a large supply during a given time period will drive down the value of those particular items. In this respect "bit gold" acts more like collector's items than like gold. However, the match between this ex post market and the auction determining the initial value might create a very substantial profit for the "bit gold miner" who invents and deploys an optimized computer architecture.</p>
 

app/pages/literature/confidential-auditing.html

@@ -31,7 +31,7 @@ <h2>Footnotes</h2>
   </li>
 
   <li id="fn4">
-    <p>Overview, http://szabo.best.vwh.net/msc.html; Quorum systems model, http://szabo.best.vwh.net/quorum.html&nbsp;<a href="#ref4">↩</a></p>
+    <p><a href="/the-god-protocols/">Overview</a>; Quorum systems model, http://szabo.best.vwh.net/quorum.html&nbsp;<a href="#ref4">↩</a></p>
   </li>
 </ol>
 

app/pages/literature/contract-language.html

@@ -15,7 +15,7 @@
 
   <li>Analyze formally specified contracts for flaws in logic, scheduling, opportunities for parties to breach the contract, and conflicts with other contracts one is already committed to.<sup><a href="#fn1" id="ref1">[1]</a></sup></li>
 
-  <li>Translate the formal contracts into an existing programming language such as E<sup><a href="#fn2" id="ref2">[2]</a></sup>, and/or cryptographic protocols<sup><a href="#fn3" id="ref3">[3]</a></sup>, for partially self-enforcing and protected execution as <a href="http://szabo.best.vwh.net/idea.html">smart contracts</a>.</li>
+  <li>Translate the formal contracts into an existing programming language such as E<sup><a href="#fn2" id="ref2">[2]</a></sup>, and/or cryptographic protocols<sup><a href="#fn3" id="ref3">[3]</a></sup>, for partially self-enforcing and protected execution as <a href="/the-idea-of-smart-contracts/">smart contracts</a>.</li>
 
   <li>Some kinds of contracts, especially financial and commodity contracts and their derivatives, can be converted into a decision or game tree that can be analyzed to determine risk, net present value, etc.</li>
 </ul>
@@ -618,7 +618,7 @@ <h2>Hooking Up Machines</h2>
 
 <p>How is it that we have specified the behavior of a vending machine in a language designed for drafting contracts? Can nickels, dimes, quarters, and operations like dropping coins from one till to another be thought of as rights and obligations? I think so. They are not <em>legal</em> rights and obligations, to be sure. There is no explicit contract between the vendor and candy machine customers, and if their were it would probably waive liability for violating most of the clauses in our code. What this code describes is the logical and typical behavior of a vending machine. It also reifies the implicit understanding most customers have when using a vending machine. Thus it models a contract-like "meeting of the minds" between the customer and the vendor that is mediated by the machine.</p>
 
-<p>Here is a stab at formally describing the hypothetical <a href="http://szabo.best.vwh.net/idea.html">"auto repo auto"</a>. The car is controlled by a <a href="http://szabo.best.vwh.net/proplets.html">proplet</a> and the proplet looks to <a href="/secure-property-titles.html">property titles</a> to determine ownership authority. The proplet lets only the titled owner enter and drive the car. "Holder" is the bank that made the loan and "Counterparty" is the new owner. As above we ignore the car dealer; the bank originally owning the car. This example highlights the ability of the language to very succinctly describe contracts but also its inability to describe the actual security that will enforce the contract. There is of course a lot missing here, including the items missing from the above car loan contract. From a smart contracts viewpoint, the biggest thing missing is that there is nothing to motivate the "Holder getTitle(car)" in the last <strong>when</strong>, nor any way specified here to enforce it. And of course all connection between ownership and authority to enter, start, and drive the car is here implicit &ndash; the actual proplet behavior in this regard would have to account for safety, emergency use, etc.</p>
+<p>Here is a stab at formally describing the hypothetical <a href="/the-idea-of-smart-contracts/">"auto repo auto"</a>. The car is controlled by a <a href="/proplets-devices-for-controlling-property/">proplet</a> and the proplet looks to <a href="/secure-property-titles/">property titles</a> to determine ownership authority. The proplet lets only the titled owner enter and drive the car. "Holder" is the bank that made the loan and "Counterparty" is the new owner. As above we ignore the car dealer; the bank originally owning the car. This example highlights the ability of the language to very succinctly describe contracts but also its inability to describe the actual security that will enforce the contract. There is of course a lot missing here, including the items missing from the above car loan contract. From a smart contracts viewpoint, the biggest thing missing is that there is nothing to motivate the "Holder getTitle(car)" in the last <strong>when</strong>, nor any way specified here to enforce it. And of course all connection between ownership and authority to enter, start, and drive the car is here implicit &ndash; the actual proplet behavior in this regard would have to account for safety, emergency use, etc.</p>
 
 <p>For all that work-up, we've only actually added one clause to our car purchase contract above. The clause forfeits the title and is structured much like the damage clauses we have seen. A <strong>breachedPerformance()</strong> event is generated if it is detected (by the Holder, a third party auditor, or the proplet itself) that the Countparty failed to make a payment according to the schedule specified by <strong>loan</strong>.</p>
 

app/pages/literature/negative-reputations.html

@@ -27,7 +27,7 @@
 
 <p>Robin Hanson has noted that in a world of global nyms, the use of a local nym may signal the hiding of negative credentials, so that the use of global nyms is in equilibrium. A further problem with local nyms is that our relationships are often not neatly compartmentalizable into standard service types, and even where they are we might like to expand them into new areas. I suggest that, at minimum, we will want to reveal progressively more local nyms to our counterparties as our relationships with them become closer and more co-exposed.</p>
 
-<p>While the global nym equilibrium may hold for many of our relationships, there may be plenty of areas where the <a href="http://szabo.best.vwh.net/smart_contracts_glossary.html#privity">privity</a> benefits of localizing nyms outweigh the costs of being less or unable to differentiate newcomers from hostiles. (By "privity" I refer the entire general task of protecting relationships from hostile third parties; confidentiality and protection of property from theft are two examples of privity). For example, the preference-tracking service at www.firefly.com increases participation via the use of pseudonyms, and suffers little exposure from hostiles. On the other hand, credit transactions typically demand identifying information, because the contractual exposure typically outweighs benefits of privity.</p>
+<p>While the global nym equilibrium may hold for many of our relationships, there may be plenty of areas where the <a href="/smart-contracts-glossary/#privity">privity</a> benefits of localizing nyms outweigh the costs of being less or unable to differentiate newcomers from hostiles. (By "privity" I refer the entire general task of protecting relationships from hostile third parties; confidentiality and protection of property from theft are two examples of privity). For example, the preference-tracking service at www.firefly.com increases participation via the use of pseudonyms, and suffers little exposure from hostiles. On the other hand, credit transactions typically demand identifying information, because the contractual exposure typically outweighs benefits of privity.</p>
 
 <p>Global nym public keys, which have many drawbacks in terms of privity, may be the best way to track negative reputation, but they are no panacea. There is an important conundrum in an ID-based key system: the conflict between the ability to get a new key when the old one is or could be abused by another (key revocation), and the ability of another to be sure they are dealing with the same person again. This may also provide an opportunity for parties to selectively reveal positive credentials and hide negative ones. For example, a person with a bad credit rating could revoke the key under which that rating is distributed and create a new one, while selectively updating their positive credentials to the new key (eg, have their alma mater create a new diploma). Key revocation <a href="http://szabo.best.vwh.net/authorities.html">authorities</a> might combine forces with credit rating agencies to avoid such erasure of negative history, but this gives them even more centralized control — not merely over IDs but over important elements of reputation associated with those IDs. This further violates the principles of separation of powers and segregation of duties, providing added opportunity for fraudulent issue or revocation of IDs along with fraudulent communication of reputation information.</p>
 

app/pages/literature/scarce-objects.html

@@ -35,7 +35,7 @@ <h2>Introduction</h2>
 
 <p>Scarce objects may also represent unique or finite relationships between people and bits – names that correspond to addresses, ownership of trademarks, authorship of content, ownership of certain rights to content (which probably does not, for security reasons, include the right to exclude others from copying the bits), etc.</p>
 
-<p>Scarce objects are not a complete model of computation across trust boundaries. Indeed, there are many <a href="http://szabo.best.vwh.net/idea.html">smart contracts</a> that can be implemented with cryptographic protocols and/or secure hardware but not with scarce objects. What scarce objects provide is a straightforward basis for implementing, in an intuitively secure way, the anonymous commodity exchange economies formalized in microeconomics in a P2P fashion on the Internet.</p>
+<p>Scarce objects are not a complete model of computation across trust boundaries. Indeed, there are many <a href="/the-idea-of-smart-contracts/">smart contracts</a> that can be implemented with cryptographic protocols and/or secure hardware but not with scarce objects. What scarce objects provide is a straightforward basis for implementing, in an intuitively secure way, the anonymous commodity exchange economies formalized in microeconomics in a P2P fashion on the Internet.</p>
 
 <p>Another area important to scarce objects is in reasoning about supply chains. In distributed objects, the call graph is the supply chain. To stretch call graphs across trust boundaries, we must replace rigid client-server relationships with dynamically adaptable customer-supplier relationships. The ideal here is to create a rich toolset of exception handling across trust boundaries. Note that credit risks are a proper subset of supply chain risks. Ka-Ping Yee recently put the supply chain problem succinctly: "be wary of return values from objects you don't trust."</p>
 

app/pages/literature/shelling-out.html

@@ -98,7 +98,7 @@ <h2 id="evolution-cooperation-and-collectibles">Evolution, Cooperation, and Coll
 
 <p>The need to remember faces and favors is a major cognitive hurdle, but one that most humans find relatively easy to overcome. Recognizing faces is easy, but remembering that a favor took place when such memory needs to be recalled can be harder. Remembering the specifics about a favor that gave it a certain value to the favored is harder still. Avoiding disputes and misunderstandings can be improbable or prohibitively difficult.</p>
 
-<p>The appraisal or <a href="http://szabo.best.vwh.net/measuringvalue.html">value measurement</a> problem is very broad. For humans it comes into play in any system of exchange &ndash; reciprocation of favors, barter, money, credit, employment, or purchase in a market. It is important in extortion, taxation, tribute, and the setting of judicial penalties. It is even important in reciprocal altruism in animals. Consider monkeys exchanging favors &ndash; say pieces of fruit for back scratches. Mutual grooming can remove ticks and fleas that an individual can't see or reach. But just how much grooming versus how many pieces of fruit constitutes a reciprocation that both sides will consider to be "fair", or in other words not a defection? Is twenty minutes of backscratching worth one piece of fruit or two? And how big a piece?</p>
+<p>The appraisal or <a href="/measuring-value/">value measurement</a> problem is very broad. For humans it comes into play in any system of exchange &ndash; reciprocation of favors, barter, money, credit, employment, or purchase in a market. It is important in extortion, taxation, tribute, and the setting of judicial penalties. It is even important in reciprocal altruism in animals. Consider monkeys exchanging favors &ndash; say pieces of fruit for back scratches. Mutual grooming can remove ticks and fleas that an individual can't see or reach. But just how much grooming versus how many pieces of fruit constitutes a reciprocation that both sides will consider to be "fair", or in other words not a defection? Is twenty minutes of backscratching worth one piece of fruit or two? And how big a piece?</p>
 
 <p>Even the simple case of trading blood for blood is more complicated than it seems. Just how do the bats estimate the value of blood they have received? Do they estimate the value of a favor by weight, by bulk, by taste, by its ability to satiate hunger, or other variables? Just the same, measurement complications arise even in the simple monkey exchange of "you scratch my back and I'll scratch yours".</p>