Thursday, April 13, 2023

SSN daydreams and time-locked proofs

In 2022, the FTC received 5.7 million total fraud and identity theft reports. A substantial portion of these cases result from the antiquated Social Security Number (SSN) system. This may come as a surprise, but your SSN is almost certainly online. If you don't believe me, you're rolling the dice, hoping you're not among the forty percent of Americans whose SSNs were leaked in the now-infamous 2017 Equifax hack. Just last year, Capital One, Experian, and Medibank, all of which collect SSNs as a consequence of the Patriot Act, suffered customer data breaches. When I say ‘online,’ I don’t mean that someone can simply Google your name and find your SSN. But it is indeed out there, stowed away in database files, circulating around dark web hacker forums, being sold to scammers, fraudsters, and other malicious actors on a per-record basis.

The price of an SSN may vary depending on the amount of accompanying personally identifiable information (PII), such as current and past residences, driver's license numbers, and email addresses, as this data is valuable for identifying associated accounts and performing password recovery flows. However, credit score has the largest influence on how dark markets will price your SSN. Not only are loan applications requested in your name likely to be approved quickly, but strong credit is a good indicator of general affluence.

Individuals with higher credit are likely to have larger-than-average checking account balances and stable employment. Banks often provide agent assisted recovery flows for customers that forgot their password, and a thief can try and beat you to the punch and file taxes as you, having your rightful return mailed to his address. Both avenues of exploitation require only the individual’s SSN and other publicly available information.

Now, don’t get me wrong, there are ways to mitigate all of these things. Create an account with all three credit bureaus and effectively ‘freeze’ all lines of credit, instate a mandatory verbal password with your bank, and generate an identity protection pin for federal tax filings. While these are well and good, they are, as stated, mitigations — band-aids to work around the fact that SSNs wield enormous power and yet are hardly private. Furthermore, we are forced to provide our SSN to a vast array of institutions from banks to credit companies, insurance providers to new places of employment; each one storing a copy of your SSN in their own database, each time unnecessarily magnifying its exposure.

The most frustrating aspect is that the SSN itself is often not needed. Instead, it is funneled to some third-party that cross-references a government database and verifies identity. This individual is qualified to receive insurance, eligible to add a line of credit, and so on. So whenever I, or someone I know, is forced to implement said mitigations due to a leaked SSN, I find myself daydreaming about a better alternative (don’t get me wrong, I am aware this is more of a bureaucratic problem than a technical one).

The SSUID

The most obvious first step is to replace SSN numbers with a stronger source of entropy. Currently, a single static identifier is allocated to each individual, with a limited range of possibilities and insufficient randomness. The first five digits of your SSN are based on geographic location where the application was processed and time of issuance. Both can be reduced to a relatively small set of possibilities if an attacker knows where and when you were born (in targeted identity theft, these are the first things an attacker will research). If you are born after 2010, you get a measly 7.4 bits of additional entropy, as the fourth and fifth digit are now randomly generated due to widespread fraud. So, in the best case, you get 20 bits of entropy, or about a million possibilities, which can be trivially enumerated in a few seconds on a low-end cell phone.

Secondly, we need to divorce location data from SSNs (which if desired, can be stored as metadata) and assign everyone a 128-bit globally unique identifier. We will call this a Social Security Unique Identifier, or SSUID for short. Even if the SSA generated one billion SSUIDs per second, it would take eighty-five years for there to be a reasonable probability of producing a duplicate. The SSUID offers a vast pool of identifiers that will never be exhausted, better privacy by removing geographic and temporal data, and an infinitesimally small chance of two citizens being assigned the same number.

TOTP

Your SSUID should be known exclusively to you and the government. In only exceptionally rare circumstances should the SSUID itself be disclosed to any other verifying party. For instance, if mistakenly pasted into a malicious website, the ID is burned. Unlike a regular password, it cannot be quickly and easily changed and would likely entail a long, bureaucratic process dealing with the SSA. A security professional might suggest authenticating SSUIDs using time-based one-time passwords (TOTP). TOTPs are unique, temporary passwords based on a shared secret (called the seed) and the current time. They are only valid for a short time period (usually 30 seconds), adding an extra layer of security if one’s primary password is compromised.

TOTP pseudocode:

def GetTimestep(step_size_secs=30): 

  current_time = int(time.time()) 

  timestep = current_time//step_size_secs

  return timestep


The client computes $p=HASH(seed || GetTimestep())$ and sends it to the server. The server computes $p’$, and authentication only succeeds if $p’==p$.

TOTP is often wrongly conflated with 2FA due to the fact that almost no websites support TOTP for primary passwords, although this is a totally reasonable thing to do. Rather, TOTP is employed as a secondary password, retrieved from a different device (typically smartphone apps like Google Authenticator and Authy). The value of TOTP lies in its ability to prevent phishing attacks by transforming a static password into a rolling password. Even if you mistakenly type your login information into a malicious website, under ideal circumstances, the attacker has only 30 seconds in which he can authenticate as you. Once that window expires, he loses access to your account.

The secondary device doesn't provide many meaningful security benefits beyond that. I’ll even venture to say that 2FA is clunky and annoying — it adds an additional authentication step, which often disallows pasting from the clipboard, and users go from managing a single password (which has already proven problematic) to managing two more passwords per site: the seed and the backup recovery codes you are instructed to print out. (I’m convinced no one actually does the latter.) The only practical way to effectively manage TOTP tokens is to store them in a password manager alongside its associated password, in essence eliminating the second-factor aspect. I’m going to again echo the sentiment that the hassle of managing password-esque information across two or more devices outweighs any marginal security benefits of doing so. So, if you can accept that, then you are ready for my proposal.

ZKPs

Given the deep integration of SSNs within our society, I believe it is time to tap into more advanced cryptographic techniques to secure SSUIDs. First and foremost, I do not ever want to provide my SSUID to any website, like we have been trained to do with SSNs. I operate under the assumption that any website requesting an SSUID will store it. To prevent this, access to raw SSUIDs would be limited to select government agencies that provide APIs for identity verification. Such APIs ought to authenticate callers without requiring them to disclose any PII.

Before diving into the proposed solution, let us briefly discuss zero-knowledge proofs (ZKPs) and Schnorr's protocol. ZKPs allow one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any information about the statement other than its truthfulness. In the context of our discussion, an individual can prove his SSUID without ever transmitting it across a network.

Schnorr’s protocol is a specific class of ZKP that nicely applies to this problem statement. A prover can convince a verifier that they know the discrete logarithm $x$ of some value $h=g^x$ without revealing the logarithm itself. In its original form, Schorrs involves back-and-forth communication between client and server (formally referred to as an interactive proof of knowledge); so we apply the Fiat–Shamir transformation, distilling it down to a digital signature, or Schnorr signature, which can be verified in a single round-trip.

Single-use proofs

Still, we haven’t yet improved on TOTP, because a man-in-the-middle (MitM) could still intercept our proof, using it later to repeatedly authenticate as us. I have discovered attempts to address the issue in the wild that convert proofs into single-use items. The following preliminary step is added to the protocol.

Verifier:
$t ← Rand()$
Send $t$ to Prover

Prover and Verifier use $x=HASH(SSUID || t)$, and the protocol continues.

$x$ is made unique per request by mixing it with a randomly generated token $t$. It is a good improvement, as the attack is reduced to a single authentication from an infinitely replayable proof, although I am still not satisfied with this solution.

Time-locked proofs

Instead, I propose time-locked proofs, which integrate TOTP timestamps into Schnorr signatures. In fact, we don’t even need to change the protocol at all, just the inputs to it!

Both the client and server compute $h^x$ where $x=HASH(SSUID || GetTimestep())$ so that the proof will change whenever the timestep does. This creates a method for generating ‘rolling proofs’ which function much like rolling passwords. Here, you can find a toy implementation on GitHub that uses sleeps to simulate the passage of time between proof and verification.

Advantages over and single-use proofs

  • Non-interactivity: Time-locked proofs stay faithful to the non-interactive transformation of Schnorrs, whereas single-use proofs require an extra round-trip, as the server must send the token to the client before proving can commence.
  • Horizontal Scalability: Single-use ZKPs require a map of connections to tokens to be stored in memory, and the mapping is unique for each instance of the service. Therefore, the client's proof must be routed to the same instance that generated the token or it will incorrectly fail to verify. In contrast, time-locked proofs allow both parties to independently calculate the timestep, avoiding the added complexity and overhead.
  • Better resistance to replay attacks: Time-locked proofs provide the same resistance to replay attacks as TOTP, while single-use proofs lack expiration properties entirely. In theory, an active MitM attacker could request $t$ from the server, proxy it to the victim, intercept the single-use proof, and replay it once on some later occasion.

Advantages over TOTP

A security minded reader may wonder what this scheme offers over TOTP. In other words, why choose time-locked proofs in favor of TOTP, using the SSUID as the seed? This reasoning is quite subtle. Let’s imagine we are sending our TOTP token to MitM. The attacker will calibrate his clock just as the client and server do. Thus, in this scenario, TOTP degenerates into sending hashed passwords (salted with the current time) across the network, and there exist many tools dedicated to cracking hashes. If your SSUID has been leaked, the MitM could crack the hash, thereby de-anonymizing you as the requester. Using time-locked proofs instead would prevent any information from being leaked to the attacker.

Application: Universal Background Checks

Universal background checks are a real-world application of time-locked proofs. For instance, if two private individuals want to engage in a firearm sale, the seller is not able to conduct a background check on the prospective buyer. That privilege is reserved only for FFLs (shops that operate full-time in the business of buying and selling weapons), and access to them is brokered by the NICS, a branch of the FBI. The current system's lack of technical sophistication means that private individuals cannot be granted access because no mechanism is in place which would prevent unauthorized and illegitimate background checks from occurring.

However, with time-locked proofs, we can imagine programmatic background checks without the privacy drawbacks. The NICS would provide a public API, which can be used to perform a background check on anyone. The catch is that accessing an individual’s background check requires a time-locked proof of identity. The buyer can provide the seller a proof of their SSUID that expires after two days, authorizing the check; the time-lock ensures that the seller can only access the buyer's background check information for a limited period, precluding unauthorized access to an updated version of the background check on some later date after the transaction has concluded.

In summary, achieving the same outcome through technological means is strictly superior. It enables private parties to securely conduct background checks, increases efficiency, and eliminates the need for FFLs as middlemen. Regulatory law serves as a barrier that prevents FFLs from abusing the current system; however, legal safeguards can be finicky, and should only be introduced when no suitable technological solutions exist.

Conclusion

Tying it all together, the existing Social Security Number system is plagued with security and privacy warts that leave millions of individuals at risk of identity theft and fraud. To address these challenges, we must move towards a more secure and privacy-conscious system. By replacing SSNs with SSUIDs and adopting time-locked proofs for identity verification, we can significantly reduce the risk of identity theft and unauthorized access to personal information. This essay is mostly an exercise in exploratory ideation, so it is unlikely that the solution ultimately adopted by government institutions will be the one proposed here. But one thing is certain: to create a more secure future for everyone, it is crucial that policymakers, tech companies, and American citizens recognize the urgency of modernizing the SSN system. We absolutely must embrace modern cryptography and leave the vulnerable, outdated SSN system in the past.

Wednesday, April 5, 2023

From Bullae to Bitcoin: A New Implementation of Ancient Ideas

On March 12, 2023, Bitcoin rallied 10% as trust in US banks declined following the collapse of Silicon Valley Bank. Bitcoin has captured the attention of financial analysts, tech enthusiasts, and skeptics alike. But while the buzz surrounding the cryptocurrency may suggest a modern, cutting-edge technology, the bulla (plural bullae), a clay jar used in Uruk 5000 years ago, pioneered signatures and verification in fiduciary transactions, today implemented in Bitcoin cryptographically.

There is much debate about the impetus behind the development of the bullae system. Some scholars contend that bullae were merely employed for accounting purposes, while others argue they served as a tool for facilitating long-distance trade. This essay argues bullae primary use case were a security measure to safeguard Uruk’s temple economy. The temple acted as a communal storage facility, and bullae played a key role by allowing individuals to retain ownership of goods without opening the temple up to fraud. We will then examine similarities between bulla and Bitcoin in their approaches to fraud prevention, tamper-proofing, and double-spending within their respective economic frameworks. Finally, we can explore enduring issues of the user experience (UX) and trust faced by both systems.


Nakamoto
The pseudonymous Satoshi Nakamoto was born into a rapidly evolving digital world. His actual age is unknown, but many speculate he is in his late fifties. He witnessed the computer revolution as the mainframe begat the PC, which begat the laptop. Nakamoto was an early adopter of the home computer and an avid student of computer security. Long before the Internet processed most financial transactions, he spent his free time on the Cypherpunks mailing list discussing the cryptography that would later secure it. 

A digital payment system backed by a deflationary currency represented the holy grail for the libertarian-oriented Cypherpunks, who shared a mutual disdain for fiat currency. The Cypherpunks chipped away at the problem by targeting individual components: Adam Back built a scheme individuals to prove they expended a certain amount of computation power (proof of work), Wei-dai explored methods to keep consistent records across thousands of computers (distributed ledger), and Nick Szabo’s writings laid the ideological groundwork. But for years the doubling-spending problem continued to thwart the group. Thus, would-be fraudsters would be able to make perfect counterfeits of their digital currency.


2007 marked the most severe financial crisis in America since the Great Depression. An entirely avoidable crisis fueled by greed and predatory loan practices left the world economy in tatters. To add insult to injury, governments deployed massive bail-outs to the tune of \$700 billion, ensuring the continued existence of the banks that created the crisis. That \$700 billion is nominally supposed to be paid by taxpayers sometime in the future. However, the government never really intends to recoup this debt. Annual taxes are well behind the ever-increasing debt bubble. Instead, the bail-outs serve to further depreciate fiat money and the spending power of those holding it.


The incompetence and greed of governments and central banks were the inspiration Nakamoto needed to finally solve the devious doubling-spending problem. His solution, paired with the ideas of his contemporaries, is Bitcoin. Nakamoto pulled no punches in expressing his motivations. The ledger’s initial (Genesis) block encodes the eerie message, “Chancellor on brink of second bailout for banks.”


Early Sumeria
Mesopotamia is the cradle of civilization. Beginning as early as 10000 BCE, small communities began to form in the river valley surrounding the Tigris and Euphrates. Nomadic hunter-gatherer tribes sought stability promised by agrarian life — especially in the fertile crescent, with an annual snowmelt that makes it uniquely well-suited for crop production. As these communities prospered, they grew both in size and sophistication. Successful irrigation practices allowed the Mesopotamians to scale up their agricultural operations, and the population proliferated to enjoy the yields. 

Although such dominance over an environment was hitherto unprecedented, the Sumerians felt perplexed by natural phenomena out of their control. The unrest that followed from droughts, dust storms, extreme temperature fluctuations, and consequently bad harvests could only be explained as a manifestation of the will of the gods. So they built shrines and temples to form deeper relationships with the deities and make sense of their whims. The temple became the central institution within settlements and commanded the skyline to display its prominence. Each community had its patron deity to which the temple was dedicated.


The Temple
Uruk, dedicated to Inanna, grew from a small community of scattered settlements into the largest Mesopotamian city-state. Perhaps this growth can be attributed to Inanna, goddess of fertility, who blessed the fields of her devotees, while others lie fallow and barren. Nevertheless, this drastic demographic expansion permitted a small segment of society to begin specializing in non-agricultural professions as opposed to working strictly for survival. Choice individuals began to apply their talents to higher purposes. The need to immortalize the particulars of Sumer life gave way to the scribe. Men and women perfected the art of fine pottery by sculpting clay on the newly invented wheel. Construction workers built houses of sun-dried brick, and scientists explored early metallurgy. The economy became so advanced that the temple assumed a new role: the centralized collector and redistributor of goods.


Reconstruction of the Eanna Ziggurat in the Central District. Eanna Ziggurat is dedicated to Inanna. [Source]

The Token and Bullae System
Agriculture remained the powerhouse that drove Uruk’s economy forward, and the temple expanded its influence through land ownership. Hectares of farmland, called nigenna, were reserved for the temple. Sections of nigenna could be leased in allotments (urulal) to individuals in exchange for a percentage of the yields. But this presented an interesting conundrum in highly productive seasons: when, for instance, a grain farmer had a great surplus after his tax to the temple had already been paid, how could he profit from the excess? Temple temple would issue a token representing a credit owed in grain.  This token could be redeemed by the farmer anytime in the future — perhaps after a poor harvest to continue providing for his family. 

Tokens were crucial for early economic development, predating large city-states, and among the first objects to be fired in a kiln. Although the temple economy greatly magnified the utility of tokens as various sectors of society began to pay dues in animal meat, grains, and metals. But keeping records of the variegated goods coming into and going out of the central organization gave rise to entire offices staffed with the newfound job of ‘administrator.’


Cache of tokens uncovered in Uruk. [Source: Schmandt-Besserat]

The token, while a powerful tool for exchange, presented a previously unseen risk of fraud. In a barter economy, a farmer would be hard-pressed to inflate his true holdings in grain. Manufacturing a token must cost proportionally less than the good it represents, otherwise it would be an entirely impractical media. Therefore, it is quite easy to devise a scheme in which a farmer conspires with an adroit ceramicist to counterfeit tokens representing his mainstay crop. Additionally, this problem of trust becomes more significant as the size of the population increases.

In a close-knit community, it may be obvious when a farmer you encounter daily exaggerates his yields; Uruk at its peak had a population of 25000. The issuance of tokens by multiple administrative departments created a situation where no individual could effectively oversee all transactions, creating an ideal climate for fraudulent activity. We argue bullae were introduced to address by the temple administrators to address this class of fraud.


Tamper-proofing
Bitcoin, on the other hand, prevents fraudulent transactions from being appended tothe blockchain through its use of public key cryptography. The blockchain is a decentralized and publicly accessible ledger that records all bitcoin transactions. Each transaction is made auditable through its pairing with a digital signature. For the uninitiated, two properties that follow from public key cryptosystems are signatures and verification.


A message can be ‘signed’ using a privately held decryption key. Anyone can verify this signature using the corresponding publicly revealed encryption key. Signatures cannot be forged, and a signer cannot later deny the validity of his signature.
–Rivest, Shamir, and Adleman, 1978


In actuality, a Bitcoin 'wallet' is a randomly generated and unique public and private key pair. Using your private key, you can attach proof that an outgoing transaction is indeed coming from your wallet; any node in the network can access your public key to verify transactions claiming to originate from it. If the transaction is forged, or tampered with in any way, signature verification fails, and it will not be appended to the ledger.1


The Mesopotamians, quite cunning in their own right, developed their own tamper-proofing protocol. The temple stopped issuing raw tokens in favor of tokens encased in bulla — a spherical mass of baked clay. Its security properties follow from the process of clay vitrification, which irreversibly alters the chemical makeup of clay. In its initial, unbaked form, clay is soft, moldable, and dissolves in water. By exposing the clay to intense heat through the baking process, it becomes rigid, brittle, and retains its shape even when submerged in water. Thus, for an individual to surreptitiously add to his token count, he is forced to break open the bulla, and its compromised structure bears evidence of manipulation.


Broken open bulla. [Source: Schmandt-Besserat]

Bulla bearing impressed markings corresponding to the tokens held inside. [Source: Schmandt-Besserat]

The cylindrical seal made it possible for the temple to knowingly accept only bullae they issued.  Each administrative office had its own seal made easily identifiable through a distinct design. Administrators ‘signed’ bullae by rolling their department’s seal along the softened clay before it was balled into a sphere. With respect to modern cryptography, these signatures were emblazoned in clay rather than encoded in bits. Archaeological evidence suggests that the intricately embossed motifs on the seal were time-consuming to produce and necessitated a profound mastery of the art, protecting the temple against illicit reproductions. A group of specialized administrators, known as inspectors, developed an expertise in the practice of fraud identification, possessing well-trained eyes that could spot even the slight imperfections in a signature.


Cylindrical seal of horned animals with stars overhead from the Uruk period. [Source]

Double-Spending
A crucial aspect of both systems is the prevention of double-spending, and Bitcoin’s success can be attributed to its innovative approach to this problem. Let's imagine we run a merchandise shop. Our gift card payment processor is flawed, since voiding a gift card code takes thirty additional seconds after the transaction completes. An attacker could issue a transaction that exhausts his balance, then quickly rush to another checkout counter, reusing the same code within this thirty second window.


The same problem arises in Bitcoin if a single non-cooperating member of the network — who Satoshi terms the greedy attacker — controls the ledger. He may attempt to spend the same Bitcoins twice before the network has had a chance to reach consensus on his wallet's true holdings. Digital signatures on their own fall short because nothing prevents the attacker from signing multiple fake transactions. The solution is that all members compete to solve a computationally difficult puzzle. The winner appends the next block of transactions to the ledger and is awarded coins for his contribution. A greedy attacker who has sufficient computational power to win consistently2 is incentivized “to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth.” –Nakamoto, 2008


The bulla is designed as a single-use device to address the double-spending problem. Token redemption involved a ritual in which the bulla was smashed in the presence of a temple administrator. This theory is supported by archaeological findings, which show that the overwhelming majority of bulla recovered in temple ruins were broken in antiquity. 

The compromised state of the bulla prevents doubling-spending, as tokens without an associated bulla are insufficient for redemption. However, this does not cover the case of a greedy administrator who is analogous to Nakamoto's greedy attacker — he may fraudulently seal bullae for his own gain. The temple has a strong incentive to eliminate corruption, as it can undermine the legitimacy of the token economy that they control. As a result, the seal also serves the secondary purpose of identifying any greedy administrator who may be defrauding the system.

User Experience
While researching the similarities between the two systems, one cannot help but be amused by the shared UX issues. Specifically, honest mistakes may misregister as fraudulent tampering. A careful Bitcoin holder knows to keep his private key a secret and treat it like a bank password. Storing the key on a public cloud presents a severe security risk in case of a breach, and managing your own ‘cold storage’ is a perilous endeavor fraught with expensive mistakes. We have all heard the familiar tale of the hard drive, now lying in a city dump, which holds the keys to unfathomable wealth. A similar fate was entirely possible in Uruk. The brittle clay bulla is easy to drop and damage by accident, now bearing evidence of manipulation when no such treachery has occurred. For the Sumerian farmer, this means an entire season of work can never be recovered.


Trust
The last topic this essay will discuss is the complicated issue of trust. For the Sumerians, the trust relationship was straightforward. Citizens must trust that the temple will uphold its side of the transaction when a bulla is smashed. In contrast, Bitcoin is trustless — or trust-minimized — by design, however, if analyzed less idealistically, Bitcoin has its own techno-elite, not too dissimilar from the temple authorities.

First, miners don’t work individually but pool their resources in order to profit from the endeavor. This has created enormous mining pools like Foundry USA, which appends about 22% of all new blocks to the ledger. Second, and more subtly, significant trust is also placed in Nakamoto himself, who is estimated to own 5% of all Bitcoins that will ever exist. The fact that he has never touched these coins separates Bitcoin from countless other cryptocurrencies created merely as a vehicle to enrich its founders. Nevertheless, Bitcoin believers must face the fact that, either explicitly or implicitly, they are entrusting the economics to Nakamoto's goodwill. For if he were to liquidate a significant portion of his coins the Bitcoin economy would be irreparably damaged.


Lastly, the majority of Bitcoin users don’t manage their wallet keys due to the aforementioned UX issues. Most offload this responsibility to cryptocurrency exchanges. Because of that, exchanges hold 27% of the supply of Bitcoins in circulation. Exchanges are wholly centralized and often unregulated entities which, while not banks in name, operate no more scrupulously than the same banks Satoshi sought to destabilize with Bitcoin. Last year, the world witnessed this in the unraveling of FTX, which was the third-largest exchange at the time. Clients thought they held Bitcoin, but their funds were actually being used to finance risky bets made by Alameda, FTX's sister company.


Conclusion
The bulla and its various layers of attestment must be commended. The clay outer shell safeguards the tokens inside, and the seal ensures their integrity through the authority of the sealer. If the reader will indulge us to cite the Bible as evidence, the bulla has the endorsement of God Himself. When the prophet Jeremiah bought the field of Anathoth, God instructed him to “Take these documents, this deed of purchase, the sealed text and the open one, and put them into an earthen jar, so that they may last a long time.” (JPS, Jeremiah 32:14) The security properties satisfied by the bulla millenias prior were sought after for years by the Cypherpunks, who finally saw their dream of a distributed ledger realized in Bitcoin. A security researcher today may laugh at the notion of securing the financial system with clay balls. But we leave him to ponder the following fact: while digital signatures in Bitcoin are provably vulnerable to attacks by quantum computers, it is impossible to de-vitrify clay.


Bibliography

Barrett-Wilt, Karen. Horned Animals with Stars Overhead; Cylinder Seal Impression.

Basalt, Serpentine; Khafajah, Sin Temple II (Iraq), Late Uruk-Jamdat Nasr Period (3350-2900 BCE). Oriental Institute, University of Chicago. June 10, 2013. World History Encyclopedia. https://www.worldhistory.org/image/1302/cylinder-seal-horned-animals/.


BTC.com. "Pool Stats." BTC.com. Accessed March 16, 2023. https://btc.com/stats/pool.

Garbutt, Douglas. “THE SIGNIFICANCE OF ANCIENT MESOPOTAMIA IN ACCOUNTING HISTORY.” The Accounting Historians Journal 11, no. 1 (1984): 83–101. http://www.jstor.org/stable/40697796.


JPS Tanakh: The Holy Scriptures. Jewish Publication Society, 1985.

Kramer, Samuel Noah. The Sumerians: Their History, Culture and Character. London, UK: The University of Chicago Press, 1963.

Mark, Joshua J. “Cylinder Seals in Ancient Mesopotamia - Their History and Significance.” World History Encyclopedia, December 2, 2015. https://www.worldhistory.org/article/846/.

Mieroop, Marc Van de. A History of the Ancient Near East Ca 3000-323 BC. Thirded. The Atrium, Southern Gate, Chichester, West Sussex, UK: John Wiley & Sons, Inc., 2016.

Nakamoto, Satoshi. “Bitcoin: A Peer-to-Peer Electronic Cash System,” 2008. https://bitcoin.org/bitcoin.pdf.

Podany, Amanda H. The Ancient Near East: A Very Short Introduction. Oxford, NY: Oxford University Press, 2014.

Reconstruction of the Eanna Ziggurat in the Central District. 2012. Artefacts: Scientific Illustration & Archeological Reconstruction. https://www.artefacts-berlin.de/.

Rivest, R.L., A. Shamir, and L. Adleman. “A Method for Obtaining Digital Signatures and Public-Key Cryptosystems.” Story. In Association for Computing Machinery 21, 21:120–26. 2. New York, NY: Association for Computing Machinery, 1978.

Schmandt-Besserat, Denise. How Writing Came About. Austin, TX: University of Texas Press, 1996.

Vigna, Paul. “Bitcoin’s ‘One Percent’ Controls Lion’s Share of the Cryptocurrency’s Wealth.” The Wall Street Journal. Dow Jones & Company, December 20, 2021. https://www.wsj.com/articles/bitcoins-one-percent-controls-lions-share-of-the-cryptocurrencys-wealth-11639996204.

Acknowledgements
Many thanks to Paul Duguid, Daniel Kuehler, Mathew Cha, Abizer Lokhandwala, and Rachel Trujillo for their insightful comments.

[1] For those struggling to grasp public key signatures, we provide the following hypothetical. Let’s say I want to send you messages that you can verify. I place my letters in a magic lockbox with two keys: the private key can only lock the box, and the public key can only unlock it. I duplicate my public key and give you the copy. We also agree that if you receive an unlocked box, damaged box, or one that does not open easily, then the contents therein cannot be trusted.

[2] 51% of the network's total compute is required to perform this attack. An attacker would need access to more energy than some countries use annually.

A unified file streaming API for local and remote storage

Oftentimes, we want a simple API for streaming IO that works seamlessly across multiple sources. I am looking for an interface that not only...