Fuzzchain

Tweet

In an earlier post, some 2 years ago, I thought out loud about how one might record the voluminous output of a computer assisted proof on a blockchain. It's a thought I've kept returning to and which I'm still developing, hopefully with the help of others (but if someone runs with this or some variation on it, that's okay too). I'm calling it Fuzzchain--and not just because its outlines are still fuzzy.

So I started sketching this out as a blog post, but quickly realized it would need to be an evolving document. I had begun with an outline:

• Scale/distribute computational bandwidth (minimize duplication)
• Reliably record the result of a long running computation
• Random access the state of a [completed] long running computation
• Compress the voluminous output of a long running computation (equivalent to previous bullet)
• Embue fuzz, the chain's native coin, with intrinsic (yet market driven) computational value.

The design of the proposed blockchain is discussed in parts.

• Overview of protocol philosophy, design elements
• hint-of-work (HoW)
• chain state hash
• work proposals
• falsification incentives
• block value function
• block payload data
• ecosystem evolution
• Outline of protocol
• programs written in a Turing-complete, but stack-based language
• format for serializing execution checkpoints of programs
• block elements
• existing technologies
• block linking rules
• Discussion

But that kind of exposition sounds too normative. So I abandoned using that outline, but am including it here because it hints at what it's about. Here's my working document. Hope it sparks some ideas.

Blockchains, Transaction Immutability, and the Judiciary

Tweet

The rise of Bitcoin and other cryptocurrencies as a recognized financial asset class has somewhat distracted pundits and observers from the original intent of these blockchain technologies, namely as a decentralized medium of exchange of goods and services. When viewed as a pure store of value instead, much like gold, a cryptocurrency's functional performance becomes peripheral to the belief system that sustains it. (That observation, and how the drive for profit might mechanize the creation of pure belief systems, is an interesting aside--perhaps, for another time.) To be sure, much is being developed on the functional side with 2nd layer infrastructure (Lightning Network, for example, to address scaling issues). So the vision of a functioning decentralized crypto-economy is still very much alive.

The crux of this post is a call to attention that the rise of the blockchain poses unique challenges to the judicial system. I write this not in the belief my arguments and conclusions are necessarily correct, but with the worry that it's an issue we should cover sooner than later. If economic prosperity is premised on sound property rights and well functioning courts, then to drink the Cool-Aid we must also consider what is to replace a withering judiciary. Transaction immutability, we shall see, the very principle held most dear to the community, lies at the heart of the issue. But before delving there, let us back up and consider the basic components of any transaction.

Trust Multifaceted in Transactions

It's easy to forget, but whether bartering, or exchanging a good or service for currency, there are always at least 2 types of items being exchanged in any given transaction. Each type of item exchanged introduces its own type of risk. Is the gold real? Are the apples rotten? Is it counterfeit money? Is the title clear?

The issue of trust (the other side of risk) presents itself not just in the examining the quality or provenance of the goods/services being traded, but also in how ownership is conveyed (or transferred--IANAL but am taking liberties with the real estate law sense of convey).

Traditionally, the state has acted as a sort of guarantor in various capacities in a well functioning marketplace. Indeed, the minting of hard-to-forge currency can be seen as a means for facilitating trust on the monetary side of transactions.

Ownership Records

But that protection does not extend to the goods/services being purchased. For these, we largely depend on evolved structures and institutions. Ownership in certain asset classes (such as land) has historically been recorded, and in modern times the state has assumed the role of recorder of many a such asset--real estate, vehicles, come to mind. In other cases, this recording is delegated to existing evolved institutions in the marketplace. Here in the US ownership of shares in public companies, for example, is recorded with an independent entity, the transfer agent--or at the brokerage house (in so called "street name"), if held in a margin account. And for centuries across bazaars in the middle east, wholesale goods in storage have often changed hands only in book entry form.

Regardless how (and whether) property is recorded, the power of the state to intervene and transfer the ownership of property (usually not to or from itself) is implicit in the marketplace. Indeed, it is generally (if implicitly) understood that property rights are rights granted and protected by the state. In well functioning market economies (not necessarily democracies) this power is exercised both sparingly and judiciously. While most transactions clear without its direct involvement, the state (usually through its judicial arm) intervenes in a minority disputes. Ultimately, the exercise of this power rests in the state's ability to force property records (whether private or public) to convey ownership. And these records also include those of financial assets and currency.

Blockchains: Code as Law

The rule of law has always been essential to the proper functioning of the marketplace. If the traditional interpreter and arbiter was the judiciary, the new interpreter of contracts and law in the crypto-economy is code. This new interpreter is guaranteed to be impartial. It follows the rule book to the letter, and its records are final. Moreover, neither it nor any sovereign can force a change to its records to convey ownership.

In the land of Code as Law, the only remedies are legislative: an amendment to the rule book. Legislative measures, however, usually target classes of stakeholders; they seldom address individual transactions and in any event cannot scale to remedy any significant number of transactions in dispute. An example of such a legislative fix was the Ethereum fork to undo the DAO heist--of which I griped about here.

Caveat Emptor: Mixed Legal Regimes

A transaction involving the purchase of a good or service with bitcoins, then, falls under two separate and independent legal regimes. On the buyer's side, the conveyance of the goods or the performance services purchased is governed and protected under the local laws of the state or relevant jurisdiction. On the seller's side, however, currency is conveyed under the Code as Law regime. Because neither regime can ultimately force the other to change its property records, the two legal regimes are largely disjoint.

From a theoretical standpoint, jurisdictional power enjoys a slight upper hand over Code as Law. While in the face of a court judgement an individual may be unwilling to give up their secret key in order to, say, return ill-gotten bitcoin gains, the state can still induce cooperation by depriving them of liberty.

What about smart contracts? Here, jurisdictional power seems to enjoy a bigger advantage. In the event a smart contract conveys ownership of, say, a hard asset, the state (again, usually through its judicial arm) may potentially overrule the new record of ownership (title) on the blockchain. Same if it involves an exchange of financial assets (such as shares in a public company). And this fact, in turn, clouds the authority of records on blockchains that reference assets that ultimately fall under the purview of the state.

Returning to the simple purchase of real goods using bitcoins use case, the risk asymmetry for buyer and seller is accentuated. Consider the following: would you feel more comfortable buying from a vendor who deposits your money at the local bank or one who immediately wires it to an account in the Cayman Islands? Buyer be wary.

Remarks

I am deeply skeptical that any system of commerce can prosper without the protections of a functioning judiciary. If commerce is to extend to the blockchain, then the blockchain must offer something in place of the courts. And if it does, then its records cannot be immutable in the strict sense we have espoused.

Let us then contemplate how a judiciary on a blockchain might work. If no transaction is ever [effectively] final, then perhaps there are a set of cryptographic keys that can override all others. One approach that comes to mind is to employ a proof-of-stake (PoS) strategy for constructing a blockchain. Some PoS protocols leave out how the initial stakeholders come to be: Algorand is an interesting recent example. What if a central bank were to issue crypto coins backed by fiat currency? That would take care of bootstrapping the initial stakeholders (anyone holding the pegged fiat currency would be provided a mechanism to be a stakeholder). Also, there might be special keys held in trust by the courts, that are collectively empowered to override all others. Just how the state manages [not to lose] its keys is obviously an open question.

Yes that is a perversion of the trustless, decentralized ideal. But what if the ideal is impractical? What if we are forced to build the analogous trust hierarchies on the blockchain as have already evolved in the real world?

And why would a sovereign consider issuing coins this way, besides? Perhaps because it couldn't risk being second.

Recording Computer Generated Proofs Using Blockchain Technologies

Tweet

It seems every day we break a new record for the longest computer generated mathematical proof. The other day I was imagining soon there will be ever larger proofs that might not fit comfortably on a single computer. Perhaps such proofs should be saved in compressed form, I wondered. This line of thinking led me to ponder what to publish and where to publish. I have some rough ideas.

What to Publish

An obvious (and very effective) compression technique here would be to just record the program that generated the proof. That is, the size of the program should come close to Kolmogorov-Chaitin entropy of its output (the symbolic proof). The downside to this approach is that it may work too well: it may take a lot of computing time to decompress. Indeed, it's easy to imagine a (large) proof being the product of a massively parallel, perhaps distributed, computing infrastructure. In that event, once the validity of such a proof was settled, the result, that is the theorem and the program that proves it, would be historically recorded (in peer review math journals), and the proof itself would not be revisited until computing resources became cheap and plentiful enough to repeat the exercise.

What makes a theorem worthwhile or interesting, by the way? I don't know what the criteria are, but one, generality certainly helps (a statement that cuts across a class of objects rather than a few instances, for example) and two, the statement of the theorem (the conjecture) ought to be compact--that is, it ought to be a low entropy statement. From the perspective of this second point, I note in passing, for a lengthy proof, the statement of the theorem itself can be viewed as a compression of its proof (so long as we consider all valid proofs of a same proposition to be equivalent).

What if a researcher doesn't want the entire proof, but just parts of it? In other words, can we devise a way to random access the text of such a large proof? e.g. jump from the billionth line to the trillionth line? In many cases, yes. To be precise, if the program outputting the proof is memory efficient, then a snapshot of its state can be efficiently recorded at any point along its execution path. If that is the case, we can annotate the program with separate, relatively small checkpoint data that would allow us to restore the call stack to the checkpoint (breakpoint, in debugger terminology) and from there see the program execute to completion. In general, the less each part of a proof depends on the intermediate results before it, the more memory efficient the program that generates it can be. Most of the computer assisted proofs I read about today appear to fall into this category. (For a counter example, if the nth part of a proof depends on results (data) from the n-1 parts before it, then it can't be memory efficient, and this strategy won't work.)

Diagram: Annotated proof generating program. With this scheme, you publish both the program (blue) and annotations (green), not the much larger output (yellow). Each annotation contains data allowing the program to output the remainder of the proof starting at the execution point that annotation represents. So n annotations partition the proof into n+1 chunks.


Why might reading a proof piecemeal be worthwhile? For one, math proofs are often developed by introducing and proving sub-theorems which when combined yield the desired final result. It may be the proof of these lemmas and sub-theorems that a researcher (human or machine) may want to revisit. And many of these "sub-theorems" may have, relatively, much smaller proofs. So there is possible value in being able to random access a very large proof. But I have another motivation..

I'm imagining you have lots of these very large computer generated theorems (I mean their proofs, of course), and they're piling up at an ever faster rate. Maybe some of these build on other ones, whatever. Regardless, if there are many of these, it would be nice, if once a theorem were proven, we would have an unimpeachable record of it that would obviate the need to verify the long proof again at a future date. So here's a stab at a trustworthy, if not unimpeachable, record keeping system.

Consider dividing the program's output (proof) into contiguous chunks as outlined above. We consider the coordinates of each chunk to be the (self-delimited) annotation data that allows us to rebuild the call stack to the checkpoint. And we define a given chunk to be the program's output from the start of its checkpoint (coordinates) to the next recorded checkpoint. Now, in addition to publishing the program, the coordinates of the chunks, and possibly the chunks themselves, we also publish a cryptographic hash of each chunk. We then construct a Merkle tree with these hashes as its leaf nodes and publish that tree too. Or perhaps we just publish the root hash the Merkle tree (?). The idea here is you can sample the proof and reliably demonstrate that it's part of the published whole.

 Diagram: Proof generating program, chunk checkpoints, chunk Merkle tree

Where to Publish

Now if in our imaginary future ecosystem we're piling on a lot of these proofs at an ever faster pace, we should also consider where they'll be published. These computer generated proofs are not being peer reviewed directly by humans; rather, this peer review has been mechanized to a point where the entire publishing process proceeds unimpeded without human intervention. Where to publish?

How about borrowing some design elements from Bitcoin's blockchain? Here's a simplified [re]view of its basic design.

The chain depicted above started on the right and ended with the most recent block on the left. Each block consists of 2 parts (white and blue, above): one, a linking mechanism connecting the block with its predecessor, and two, a payload that is app-specific. Structurally, the block chain is a singly linked list (left to right), or if you prefer, a stack that is only ever appended; "physically", the head of the linked list (the latest block), or again, top of the stack, is located at the end of the file. The role of this linking, however, is not for navigating the blocks during read access. Rather, it's role is syntactic: it enforces the form a block must take in order for it to be eligible for inclusion at the end of the chain (i.e. what can be appended to the head of the linked list).

The linking mechanism itself is interesting. It involves writing a nonce which when combined with the  block's cargo data yields a [cryptographic] hash that is very close to a hash of the entirety of previous block. Finding such a nonce for a cryptographically secure hash is computationally hard: an algorithm can do no better than trial and error. So hard, that you need a network of incentivized computing nodes competing to find the first eligible block that may be appended to the end of the chain. This nonce is the so-called proof of work. The protocol adjusts the difficulty level (the maximum allowed difference in the above hashes) so that on average blocks are appended to the chain at a steady rate.

How do we know who's first to find an eligible new block? We don't. However, the protocol values the longest known chain the greatest. Thus once a new eligible block is discovered and it's existence is broadcasted across the network, there's little incentive for a computing node to work on the older, shorter chain.

Note we glossed over the application-specific payload data in each block. In Bitcoin, this part of the block records [cryptographically secured] transactions of bitcoins across individuals. Naturally, in order for a Bitcoin block to be well formed, it must also satisfy certain constraints that define (and validate) such transactions. The reason why it was glossed over, as you've probably already guessed, is that I want to explore swapping out bitcoin transactions for math proofs, instead.

Now while the Bitcoin blockchain is computationally hard to construct, it is computationally easy to verify. In its entirety. That is, verifying a file of the entire blockchain is as simple as playing the file from the beginning, the first block in the chain, and then verifying that each subsequent block properly matches the one before it. This involves checking both each block's nonce and the app-specific payload (the transaction signatures must match the public keys of the coins involved). The motivation behind the approach I'm exploring, however, is to store computational work (math proofs, here) in the app-specific section of each block. And, generally, the only way to verify a computational result is to redo it. So it would appear that Bitcoin's principle of quick verifiability would be in opposition to the strategy I have in mind.

A Layered Goldilocks Approach

How about a layered approach? What if some [computationally hard] properties of a blockchain (the linking/chaining mechanism) are easy to verify but verifying some of its other properties are more time consuming (such as verifying the recorded hash of a chunk of a proof as discussed above)? Suppose the latest 10 blocks can be verified in a reasonable amount of time, but verifying the entire blockchain takes an unreasonable amount of computing resources. If someone gave you a blockchain of math proofs so recorded, how confident would you be that it was valid and not just some made up chain? Let us outline the verification steps that we can reasonably perform:

1. Verify that the current, existing distributed blockchain is a longer, appended version of the one you were given.
2. Verify the proof-of-work chaining mechanism is intact.
3. Sample the blocks to ensure they record valid hashes of the computations they represent.

Suppose further this blockchain network contains a built-in falsification protocol (that is seldom, if ever, meant to be exercised): if the hash of the result of a single computational chunk recorded in a block does not match the actual output of the computation, then this falsification can be broadcast to alert the nodes that that block and every block after it are invalid and that the chain must be pruned. If the game the computational nodes are playing still rewards the longest blockchain, then the expected behavior of the nodes will be to try to poke holes in and falsify newer blocks than the old, since the older blocks have likely been checked many times before by other participants in the network.

So, to recap, our proposed computation-recording blockchain has the following attributes:

1. It allows for programs to be recorded in it and later referenced (identified) by their hash.
2. It allows for the chunks of a so-recorded program's output to be parameterized as chunk coordinates.
3. It supports a format to record the hash of a chunk so described.
4. It supports an explicit block falsification protocol (that is only likely ever exercised on blocks at the tail end of the chain).

Taken together, I'm inclined to think such an approach might just work. The underlying hidden force holding this together is history. This suggestion, I think, is not as preposterous as it sounds. Indeed, observe what happens to the Bitcoin blockchain as computational resources become ever more powerful and plentiful: the nonces of the blocks in the early parts of the chain are ever easier to reproduce. Here too proof-of-work, then, is a time-sensitive concept. A more extreme example would be if a vulnerability were later found that necessitated a change in hash function. It is doubtful we'd throw away the historical blockchain: we'd likely find a way to recognize it as a historical artifact and secure the chain with a better function going forward.

A Concluding Thought

A longstanding principle of science has been repeatability. Experimental results are supposed to be repeatable. The modern laboratories of science are big and expensive. Be they planetary science or particle physics, because these experiments are expensive to duplicate, we compensate by bearing witness to them in large numbers. Years from now, we won't be worried about the veracity of pictures New Horizons snapped of Pluto even if we haven't been there since. Same for data collected from the LHC: if it's later shutdown, we'll still trust the recorded data was not doctored, since there were so many witnesses when the experiments took place. From this perspective, the present discussion is about bearing witness in numbers (the number of computing nodes on the network, that is) to math proofs we might not have the resources to revisit again and again. In this sense, mathematics may have already entered the realm of big science.

Second Thoughts on Smart Contracts and Crypto Gold

Tweet

Note: I began writing this post a little after Ethereum's DAO project ran into trouble. I put thoughts down slowly, and over the course of penning it, to my surprise, the community pulled off the hard fork to save the DAO's funds.

Though a fan of cryptocurrencies, and blockchain technologies in general, I've harbored doubts about the wisdom of adopting smart contracts as instruments of finance since well before the recent demise of Ethereum's DAO project. It was a fine idea: a sort of VC fund (expressed as a smart contract on the Ethereum blockchain) that would seed other projects and enterprises. Trouble was there was a bug in this contract (not in Ethereum itself) that enabled a slow motion $50 million dollar heist in broad daylight. The bug (the exploit) was discovered well before the DAO's funds (ethers) had been depleted, but little could be done to stop it. For smart contracts are programs written in stone (the blockchain, itself), executable code whose state (when conditions are met) inexorably advances as new blocks are added to the chain.

Real world contracts, by contrast, are interpreted by humans, which unlike machines, are far more forgiving. We allow for syntactic errors--errors in punctuation, grammar, spelling, etc. (Recall the 2nd amendment to the US constitution.) We can even tolerate a moderate degree of illogic. When the meaning of a contract is in dispute, we (the courts, or other empowered arbitrators) analyze and interpret both the letter of the contract and intent of the parties to that contract. This ability to re-interpret contracts, to clarify, amend, or even annul them in the future is an indispensable tool of human progress. If society were governed by immutable contracts (think slavery), we'd all be screwed.

The Trouble with Financial Instruments as Smart Contracts

The collapse of the DAO was viewed by many in its community as a blow to the ecosystem itself. Considerable resources (people, time, energy, dollars and ethers) had been expended, and the project's success was to underscore, validate--indeed some would argue kick off a demonstration of the true purpose of--the foundational Ethereum it was built on.

How to save the DAO? There was considerable wrangling about just how this could be done, but none involved fixing the contract itself, since by the rules of the game (Ethereum blockchain), contracts are immutable. No, the only way the DAO could possibly be saved was by somehow actually changing the rules. And the only way that could be done was (and always will be) by consensus.

Of course in blockchains like Bitcoin's and Ethereum's (proof-of-work based) "consensus" means a plurality in mining (hashing) power: the more computing power that you can plug to the network, the more say you have (at this time, the proof-of-stake version of Ethereum is still in development). The details, tradeoffs, and risks of the proposed solutions (soft fork vs. hard fork, etc.) are not important here. As it turned out, the community successfully pulled off a hard fork. Rather, the issue here is how a bug in a contract put the larger system (Ethereum itself) in play.

Systemic Risk: At the Intersection of Randomness and Determinism

Forget the challenges of crafting bug-free contracts. Let us assume we've achieved a bug-free ecosystem of best practices, and the contracts themselves work as intended. The larger and more important question is whether the system itself (the totality of the contracts) will work as intended.

In particular, what happens when financial contracts (on a blockchain) fail to price in risk correctly? Regrettably, the history of finance is filled with examples of ruin such mis-allocations of capital have caused (the 2007-2008 crisis being the most recent in memory). It is easy to imagine a blockchain embedding a web of contracts (recall, they can invoke each other's public interfaces) going down an execution branch that would have previously been considered a 6-sigma event. As we pile more contracts atop existing ones, the ability to analyze the future paths the blockchain might take becomes computationally hard. This calculation is compounded by the fact that, generally, the order of execution of the contracts cannot be guaranteed on the blockchain--there are therefore even more paths to consider given the combinatorics of ordering.

That last observation, by the way, holds irrespective of the richness of the programming language expressing those contracts--be it Turing-complete (as Ethereum claims with some caveats--gas), or one in which the execution path is constrained to a directed acyclic graph. Each contract is properly seen as a thread of execution and the blockchain, the current state of a highly concurrent system. The very nature of concurrency is disorder.

The '07-08 crisis, while still fresh in memory, is instructive. Financial institutions had sold insurance against outlier events that they had priced as astronomically unlikely. They insured against various forms of default: mortgages, corporate debt, the solvency of the insurers themselves. There was so much insurance being traded around that the impenetrable pile looked safe, and soon the insured were themselves insuring the insurers through circuitous paths few could see. Quite the contrary, the pile of paper instruments was viewed as a marvel of modern financial engineering.

And then, of course, a brick fell out of that fragile wall: mortgages. When the market realized that the default rate on these had surpassed all historical norms, the entire model on which everything was priced was called into question. The pile was now a tangled web of obligations no one could properly unravel. Counter-party risk became paramount: no financial player could trust that the other was actually solvent. The credit markets were frozen.

While the manner in which the Federal Reserve (and Congress) responded in the aftermath of the crisis can be legitimately scrutinized, putting aside questions of fairness and accountability, there's little doubt that some form of intervention was necessary. Some have argued that we should have left the chips fall where they may. But there was real risk that ATMs would soon stop working. Something had to be done. Someone had to suspend the rules of the game.

Which brings us back to smart contracts. Who will intervene when a pile of smart contracts form a dumb collective? In the case of the DAO, the Ethereum community's intervention manifested itself as a hard fork (a change in the rules that is not backward-compatible with the old rules). It was an impressive, if messy, feat. And it also brought controversy, as it called into question the very immutability of transactions on blockchains. But these are early days for Ethereum. It's doubtful a fork like this could have been pulled off if the project were in a more mature state like, say, Bitcoin.

Much has been made of the "lessons learned" about the DAO's failure and how a more rigorous, better tested, bottom-up approach promises a better second-go at it. I want to believe. Still, the real lesson, I'm afraid, might be that contracts written in stone are a bad idea, period.

And a Bit Glum About Bitcoin..

If having struck such a downer note, I might as well list some personal peeves about Bitcoin (a sort of cleansing of my mind). I will try not to bore you with technical peeves others have already made--that the system is an inefficient energy hog, for example.

So you might argue, What's the harm in a contract that records the transfer of ownership, of say, a car? Not much really. Except that the world is filled with unsavory actors. What if someone is holding a gun to your head? Would you buy into a system of ownership in which the courts cannot undo a transaction even after you've proven that it was executed under duress? (That no central authority can govern its transactions is in fact the key feature of the distributed ledger that is the blockchain.)

Now this argument must apply equally to Bitcoin, too. Owning bitcoins is much like owning gold in an impenetrable, pass-phrase-protected vault in your basement. If you store much gold there, you might want to take additional security measures--a security camera, for instance (so a would-be thief is less inclined to hold that gun to your head). Except, again, that with bitcoins, the camera is of little use, since the courts will have a hard time returning the stolen goods. Indeed, the courts generally have difficulty returning anything stolen from your safe--which is why we tend to prefer the banking system.

This doesn't necessarily mean that bitcoins are an unsafe store of wealth. Indeed, bitcoin is arguably safer than gold. For one, gold is more fungible than bitcoins: gold atoms are indistinguishable from one another, whereas the transaction history of any [fractional] bitcoin can be traced back to its beginning (when it was first mined). Bitcoins are thus less anonymous than once supposed, and this can make spending the loot harder for a thief. Two, the total supply of bitcoins is easier to predict than that of gold. The supply of gold is sensitive to one-off events, like the discovery of new sources (say a newly discovered mine, or more fantastically, imagine a bus-size gold asteroid landing in Siberia), whereas the maximum future supply of bitcoins is bounded (the sum of a decaying geometric series), and the network's mining power growth rate is relatively steady. And third, bitcoins are easier and safer to transport ('cause you don't).

But for me, investing in Bitcoins burdens me the same way as owning gold: great care must be taken to protect any significant amount of it from theft. I am far too sloppy to invest in either (and own too little to consider changing my ways worthwhile). No I think bitcoin's most important feature is that it functions unimpeded across geographical, governmental, jurisdictional boundaries--though, I've yet to actually need any of this.

A Better Name: Bitgold

I'm not suggesting, of course, that Bitcoin should be renamed. But bitcoins are more like precious metals than currency. Currencies, after all, aim for price stability. Ideally, a basket of everyday goods costs the same over time in a given currency. But Bitcoin, like gold, owing to its limited supply, tends to appreciate in value relative to most common goods and services that over time become ever more abundant through innovation and technological efficiency. So if it's a currency, Bitcoin is deflationary one.

Deflationary currencies, however, are ill-suited for tallying debt. A lender has little incentive to lend bitcoins long term. And a borrower's obligations tend to balloon in real terms over time thereby increasing credit risk even more. So bitcoins can be lent more like Treasury bonds: they can be used as collateral for other debt, but are themselves seldom borrowed for any meaningful length of time. (Typically, you borrow long term T-bonds short term, in order to sell them short in anticipation of a quick drop in price.)

Now some argue that debt and usury are evil twins that we'd best do away with anyway, that a system of finance that discourages credit is just what the doctor ordered. It's a questionable argument, supported by only a minority of economists. (To wit, the total value of bitcoin debt is minuscule when compared to aggregate supply, even though a good number startups provide intermediation services for such lending in the marketplace.) Whether right or wrong, whatever its merits, it seems to me buying into the Bitcoin system is somewhat synonymous with abandoning long term debt: the system inherently favors equity over credit.