replace all href a tags

site/general/2017/12/17/voting.html

@@ -588,7 +588,7 @@ <h3 id="toward-a-balance">Toward A Balance</h3>
 any protocol changes, and their freedom, and credible threat, to "fork
 off" if someone attempts to force changes on them that they consider
 hostile (see also: <a
-href="http://vitalik.ca/general/2017/05/08/coordination_problems.html">http://vitalik.ca/general/2017/05/08/coordination_problems.html</a>).</p>
+href="http://vitalik.eth.limo/general/2017/05/08/coordination_problems.html">http://vitalik.eth.limo/general/2017/05/08/coordination_problems.html</a>).</p>
 <p>Tightly coupled voting is also okay to have in some limited contexts
 - for example, despite its flaws, miners' ability to vote on the gas
 limit is a feature that has proven very beneficial on multiple

site/general/2017/12/31/pos_faq.html

@@ -723,7 +723,7 @@ <h3 id="can-one-economically-penalize-censorship-in-proof-of-stake">Can
 carries an opportunity cost equal to the block reward, but sometimes the
 new random seed would give the validator an above-average number of
 blocks over the next few dozen blocks. See <a
-href="http://vitalik.ca/files/randomness.html">here</a> and <a
+href="http://vitalik.eth.limo/files/randomness.html">here</a> and <a
 href="https://hackernoon.com/nxt-pos-block-skipping-attack-myth-de88cf4b3363">here</a>
 for a more detailed analysis.</li>
 </ol>

site/general/2020/02/28/complexity.html

@@ -63,7 +63,7 @@ <h1 style="margin-bottom:7px"> Encapsulated vs systemic complexity in protocol d
 <br> <br> <br>
 <title> Encapsulated vs systemic complexity in protocol design </title>
 
-<p>One of the main <a href="https://notes.ethereum.org/@vbuterin/serenity_design_rationale#Principles">goals of Ethereum protocol design</a> is to minimize complexity: make the protocol as simple as possible, while still making a blockchain that can <a href="https://vitalik.ca/general/2019/12/26/mvb.html">do what an effective blockchain needs to do</a>. The Ethereum protocol is far from perfect at this, especially since much of it was designed in 2014-16 when we understood much less, but we nevertheless make an active effort to reduce complexity whenever possible.</p>
+<p>One of the main <a href="https://notes.ethereum.org/@vbuterin/serenity_design_rationale#Principles">goals of Ethereum protocol design</a> is to minimize complexity: make the protocol as simple as possible, while still making a blockchain that can <a href="https://vitalik.eth.limo/general/2019/12/26/mvb.html">do what an effective blockchain needs to do</a>. The Ethereum protocol is far from perfect at this, especially since much of it was designed in 2014-16 when we understood much less, but we nevertheless make an active effort to reduce complexity whenever possible.</p>
 <p>One of the challenges of this goal, however, is that complexity is difficult to define, and sometimes, you have to trade off between two choices that introduce different kinds of complexity and have different costs. How do we compare?</p>
 <p>One powerful intellectual tool that allows for more nuanced thinking about complexity is to draw a distinction between what we will call <strong>encapsulated complexity</strong> and <strong>systemic complexity</strong>.</p>
 <center>
@@ -77,7 +77,7 @@ <h3 id="bls-signatures-vs-schnorr-signatures">BLS signatures vs Schnorr signatur
 <p><a href="https://en.wikipedia.org/wiki/BLS_digital_signature">BLS signatures</a> and <a href="https://en.wikipedia.org/wiki/Schnorr_signature">Schnorr signatures</a> are two popular types of cryptographic signature schemes that can be made with elliptic curves.</p>
 <p>BLS signatures appear mathematically very simple:</p>
 <p>Signing: <span class="math inline">\(\sigma = H(m) * k\)</span> Verifying: <span class="math inline">\(e([1], \sigma) \stackrel{?}{=} e(H(m), K)\)</span></p>
-<p><span class="math inline">\(H\)</span> is a hash function, <span class="math inline">\(m\)</span> is the message, and <span class="math inline">\(k\)</span> and <span class="math inline">\(K\)</span> are the private and public keys. So far, so simple. However, the true complexity is hidden inside the definition of the <span class="math inline">\(e\)</span> function: <a href="https://vitalik.ca/general/2017/01/14/exploring_ecp.html">elliptic curve pairings</a>, one of the most devilishly hard-to-understand pieces of math in all of cryptography.</p>
+<p><span class="math inline">\(H\)</span> is a hash function, <span class="math inline">\(m\)</span> is the message, and <span class="math inline">\(k\)</span> and <span class="math inline">\(K\)</span> are the private and public keys. So far, so simple. However, the true complexity is hidden inside the definition of the <span class="math inline">\(e\)</span> function: <a href="https://vitalik.eth.limo/general/2017/01/14/exploring_ecp.html">elliptic curve pairings</a>, one of the most devilishly hard-to-understand pieces of math in all of cryptography.</p>
 <p>Now, consider Schnorr signatures. Schnorr signatures rely only on basic <a href="https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/">elliptic curves</a>. But the signing and verification logic is somewhat more complex:</p>
 <center>
 <p><br><a href="https://en.wikipedia.org/wiki/Schnorr_signature"></p>
@@ -90,10 +90,10 @@ <h3 id="bls-signatures-vs-schnorr-signatures">BLS signatures vs Schnorr signatur
 <li>Doing a BLS multi-signature (a combined signature from two keys <span class="math inline">\(k_1\)</span> and <span class="math inline">\(k_2\)</span>) is easy: just take <span class="math inline">\(\sigma_1 + \sigma_2\)</span>. But a Schnorr multi-signature requires two rounds of interaction, and there are tricky <a href="https://tlu.tarilabs.com/cryptography/introduction-schnorr-signatures#key-cancellation-attack">key cancellation attacks</a> that need to be dealt with.</li>
 <li>Schnorr signatures require random number generation, BLS signatures do not.</li>
 </ul>
-<p>Elliptic curve pairings in general are a powerful "complexity sponge" in that they contain large amounts of encapsulated complexity, but enable solutions with much less systemic complexity. This is also true in the area of polynomial commitments: compare the <a href="https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html">simplicity of KZG commitments</a> (which require pairings) and the much more complicated internal logic of <a href="https://vitalik.ca/general/2021/11/05/halo.html#background-how-do-inner-product-arguments-work">inner product arguments</a> (which do not).</p>
+<p>Elliptic curve pairings in general are a powerful "complexity sponge" in that they contain large amounts of encapsulated complexity, but enable solutions with much less systemic complexity. This is also true in the area of polynomial commitments: compare the <a href="https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html">simplicity of KZG commitments</a> (which require pairings) and the much more complicated internal logic of <a href="https://vitalik.eth.limo/general/2021/11/05/halo.html#background-how-do-inner-product-arguments-work">inner product arguments</a> (which do not).</p>
 <h3 id="cryptography-vs-cryptoeconomics">Cryptography vs cryptoeconomics</h3>
-<p>One important design choice that appears in many blockchain designs is that of cryptography versus cryptoeconomics. Often (eg. in <a href="https://vitalik.ca/general/2021/01/05/rollup.html">rollups</a>) this comes in the form of a choice between <strong>fraud proofs</strong> and <strong>validity proofs</strong> (aka. ZK-SNARKs).</p>
-<p>ZK-SNARKs are complex technology. While <a href="https://vitalik.ca/general/2021/01/26/snarks.html">the basic ideas</a> behind how they work can be explained in a single post, actually implementing a ZK-SNARK to verify some computation involves many times more complexity than the computation itself (hence why ZK-SNARKs for the EVM are <a href="https://ethresear.ch/t/a-zk-evm-specification/11549">still under development</a> while fraud proofs for the EVM are <a href="https://github.com/ethereum-optimism/cannon/">already in the testing stage</a>). Implementing a ZK-SNARK effectively involves circuit design with special-purpose optimization, working with unfamiliar programming languages, and many other challenges. Fraud proofs, on the other hand, are inherently simple: if someone makes a challenge, you just directly run the computation on-chain. For efficiency, a binary-search scheme is sometimes added, but even that doesn't add too much complexity.</p>
+<p>One important design choice that appears in many blockchain designs is that of cryptography versus cryptoeconomics. Often (eg. in <a href="https://vitalik.eth.limo/general/2021/01/05/rollup.html">rollups</a>) this comes in the form of a choice between <strong>fraud proofs</strong> and <strong>validity proofs</strong> (aka. ZK-SNARKs).</p>
+<p>ZK-SNARKs are complex technology. While <a href="https://vitalik.eth.limo/general/2021/01/26/snarks.html">the basic ideas</a> behind how they work can be explained in a single post, actually implementing a ZK-SNARK to verify some computation involves many times more complexity than the computation itself (hence why ZK-SNARKs for the EVM are <a href="https://ethresear.ch/t/a-zk-evm-specification/11549">still under development</a> while fraud proofs for the EVM are <a href="https://github.com/ethereum-optimism/cannon/">already in the testing stage</a>). Implementing a ZK-SNARK effectively involves circuit design with special-purpose optimization, working with unfamiliar programming languages, and many other challenges. Fraud proofs, on the other hand, are inherently simple: if someone makes a challenge, you just directly run the computation on-chain. For efficiency, a binary-search scheme is sometimes added, but even that doesn't add too much complexity.</p>
 <p>But while ZK-SNARKs are complex, their complexity is <em>encapsulated complexity</em>. The relatively light complexity of fraud proofs, on the other hand, is <em>systemic</em>. Here are some examples of systemic complexity that fraud proofs introduce:</p>
 <ul>
 <li>They require careful incentive engineering to avoid the <a href="https://eprint.iacr.org/2015/702.pdf">verifier's dilemma</a>.</li>
@@ -109,7 +109,7 @@ <h3 id="miscellaneous-examples">Miscellaneous examples</h3>
 <li><strong>Hash functions</strong> - high encapsulated complexity, but very easy-to-understand properties so low systemic complexity.</li>
 <li><strong>Random shuffling algorithms</strong> - shuffling algorithms can either be internally complicated (as in <a href="https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763">Whisk</a>) but lead to easy-to-understand guarantees of strong randomness, or internally simpler but lead to randomness properties that are weaker and more difficult to analyze (systemic complexity).</li>
 <li><strong>Miner extractable value (<a href="https://medium.com/umbrella-network/miner-extractable-value-mev-101-why-what-and-how-4bec3bc3bb2a">MEV</a>)</strong> - a protocol that is powerful enough to support complex transactions can be fairly simple internally, but those complex transactions can have complex systemic effects on the protocol's incentives by contributing to the incentive to propose blocks in very irregular ways.</li>
-<li><strong>Verkle trees</strong> - <a href="https://vitalik.ca/general/2021/06/18/verkle.html">Verkle trees</a> do have some encapsulated complexity, in fact quite a bit more than plain Merkle hash trees. Systemically, however, Verkle trees present the exact same relatively clean-and-simple interface of a key-value map. The main systemic complexity "leak" is the possibility of an attacker manipulating the tree to make a particular value have a very long branch; but this risk is the same for both Verkle trees and Merkle trees.</li>
+<li><strong>Verkle trees</strong> - <a href="https://vitalik.eth.limo/general/2021/06/18/verkle.html">Verkle trees</a> do have some encapsulated complexity, in fact quite a bit more than plain Merkle hash trees. Systemically, however, Verkle trees present the exact same relatively clean-and-simple interface of a key-value map. The main systemic complexity "leak" is the possibility of an attacker manipulating the tree to make a particular value have a very long branch; but this risk is the same for both Verkle trees and Merkle trees.</li>
 </ul>
 <h3 id="how-do-we-make-the-tradeoff">How do we make the tradeoff?</h3>
 <p>Often, the choice with less encapsulated complexity is also the choice with less systemic complexity, and so there is one choice that is obviously simpler. But at other times, you have to make a hard choice between one type of complexity and the ther. What should be clear at this point is that <strong>complexity is less dangerous if it is encapsulated</strong>. The risks from complexity of a system are not a simple function of how long the specification is; a small 10-line piece of the specification that interacts with every other piece adds more complexity than a 100-line function that is otherwise treated as a black box.</p>

site/general/2021/11/16/retro1.html

@@ -140,7 +140,7 @@ <h1 style="margin-bottom:7px"> Review of Optimism retro funding round 1 </h1>
 viewable: the <span
 style="color:#880044">#retroactive-public-goods</span> channel on the <a
 href="discord.optimism.io">Optimism discord</a>, and a <a
-href="https://vitalik.ca/files/misc_files/retro_recording.mp4">published
+href="https://vitalik.eth.limo/files/misc_files/retro_recording.mp4">published
 Zoom call</a></li>
 <li>The full results, and the individual badge holder votes that went
 into the results, can be viewed <a

site/general/2021/12/19/bullveto.html

@@ -132,7 +132,7 @@ <h1 style="margin-bottom:7px"> The bulldozer vs vetocracy political axis </h1>
 href="https://www.reddit.com/r/politicalcompassmemes">subreddit
 dedicated to memes</a> based on these charts. I even made a spin on the
 concept myself, with <a
-href="https://vitalik.ca/files/misc_files/meta_political_compass_expanded.png">this
+href="https://vitalik.eth.limo/files/misc_files/meta_political_compass_expanded.png">this
 "meta-political compass"</a> where at each point on the compass there is
 a smaller compass depicting what the people at that point on the compass
 see the axes of the compass as being.</p>

site/general/2022/12/30/institutions.html

@@ -303,7 +303,7 @@ <h2 id="what-are-some-common-factors">What are some common factors?</h2>
 gains from being part of the Elon-verse specifically)</li>
 </ul>
 <p>The full data is <a
-href="https://vitalik.ca/files/misc_files/institution_analysis.ods">here</a>.
+href="https://vitalik.eth.limo/files/misc_files/institution_analysis.ods">here</a>.
 I know that many people will have many disagreements over various
 individual rankings I make, and readers could probably convince me that
 a few of my scores are wrong; I am mainly hoping that I've included a

site/general/2023/04/14/traveltime.html

@@ -233,7 +233,7 @@ <h1 style="margin-bottom:7px"> Travel time ~= 750 * distance ^ 0.6 </h1>
 service that would make it easier to hire other people to do this for me
 and get much more data. In any case, 16 is enough; I put my resulting
 data <a
-href="https://vitalik.ca/files/misc_files/travel_time_data_with_flights.csv">here</a>.</p>
+href="https://vitalik.eth.limo/files/misc_files/travel_time_data_with_flights.csv">here</a>.</p>
 <p>Finally, just for fun, I added some data for how long it would take
 to travel to various locations in space: <a
 href="https://science.howstuffworks.com/how-long-to-moon.htm">the
@@ -246,7 +246,7 @@ <h1 style="margin-bottom:7px"> Travel time ~= 750 * distance ^ 0.6 </h1>
 <a
 href="https://www.technologyreview.com/2018/06/22/142160/this-is-how-many-people-wed-have-to-send-to-proxima-centauri-to-make-sure-someone-actually/">Centauri</a>.
 You can find my complete code <a
-href="https://vitalik.ca/files/misc_files/geoanalyze.py">here</a>.</p>
+href="https://vitalik.eth.limo/files/misc_files/geoanalyze.py">here</a>.</p>
 <p>Here's the resulting chart:</p>
 <center>
 <p><img src="../../../../images/traveltime/chart2.png" /></p>