Month: May 2017

Bitcoin and the ship of Theseus

Change and identity in a decentralized system

The Ship of Theseus is a philosophical conundrum about the continuity of identity in the face of change. Theseus and his ship sail the wide-open seas. Natural wear-and-tear takes its toll on the vessel, requiring its components to be replaced gradually over time. One day it is a few planks in the hull, the next season one of the masts are swapped out, followed by the sails. Eventually there comes a point where not a single nail or piece of fabric is left from the original build, and some parts have been replaced several times over. But unbeknownst to Theseus, a mysterious collector of maritime souvenirs has carefully preserved every component from the original ship taken out during repairs. (This is a variation on the original paradox, due to Hobbes.) In what may be the first case of retro-design, this person meticulously reassembles the original components into their original configuration. The riddle on which much ink has been spilled: which one is the true ship of Theseus? The one that has been sailing the seas all this time or the carefully restored one in the docks, which contains every last nut, bolt and rope from the original?

Bitcoin has been confronting a version of this riddle, most acutely during a few days in March when a hard-fork of the network appeared imminent. To recap: Bitcoin is a distributed ledger recording transactions and ownership of funds. This ledger is organized into “blocks,” with miners competing to tack on new blocks to the ledger, one block on average every 10 minutes. The catch is there is a limit on the size of blocks, which constrains how many transactions can be processed. Currently that stands at 1 megabyte—a gratuitous and arbitrary limit which may have seemed generous back in 2011 when it was first introduced, with plenty of spare room left in blocks to solve the problem. But kicking the can down the road predictably ends exactly as one would expect: increasing popularity of the network all but guaranteed that ceiling would be hit. Results of scarcity follow: transactions both became slower and more expensive. The time expected for a transaction to appear in a block increased and the fees paid to miners for that privilege sky-rocketed.

It is clear the situation calls for some form of scaling improvement. But there is no governance framework for Bitcoin. A system marvelously effective at bringing about distributed consensus at the technology level—everyone agrees on who owns what and which payments were sent—turns out to be terrible at producing consensus at the political level among its participants. Even the existence of a scaling crisis has been disputed. Some argue that Bitcoin excels as a settlement layer or store of value, and there is no reason to increase its on-chain capacity to handle everyday payment scenarios.

After much internecine fighting and several false-starts, the community coalesced around two opposing camps. One side mobilized under the Bitcoin Unlimited (BU) banner seeks to increase block size with a disruptive change, ratcheting up the arbitrary 1MB cap to some other, equally arbitrary but higher limit. On the other side is a group pushing for segregated-witness, a more complex proposal that solves multiple problems (including transaction malleability) but conveniently has the side-effect of providing an effective capacity increase. At the time of writing, this controversy remains in a deadlock. Segregated witness must reach roughly 75% miner support to activate. It has stalled at 30%, prompting supporters to give up on miners and seek an alternative approach called user-activated soft-fork or UASF. Meanwhile BU has been plagued by code-quality problems and DDoS attacks.

At some point in March, the miner support for BU was hovering dangerously close to the magic 50% mark. If that threshold is crossed, those miners could realistically start producing large blocks. While anyone can mine a large block any time, such blocks would be ignored by miners following the 1MB limit. It makes no sense to start producing them when they are only recognized by a minority. Such additions to the ledger would be quickly crowded-out and discarded in favor of alternative blocks obeying the 1MB restriction. But suppose BU exceeds 50%. (With some safety margin thrown in; otherwise there is the risk of block reorganization, where the original chain catches up and results in the entire history of big-blocks getting overwritten.) What happens if BU miners in the majority start producing those large blocks?
This was the question on everyone’s mind in March. It would result in a spit or “forking” of the Bitcoin ledger. Instead of one ledger there would be two parallel ledgers, maintained according to different rules. All blocks up to the point of the fork would be identical. If you owned 1 bitcoin, you still have 1 bitcoin according to both ledgers. But new transactions after the fork point can result in divergence, appearing on only one ledger. In effect two parallel universes emerge, where the same funds are owned by different people.

That brings us full-circle to the philosophical riddle of Theseus: which one of these is “Bitcoin”? Major cryptocurrency exchanges opted for a pragmatic answer: the original chain is Bitcoin-proper. According to this interpretation, the alternate ledger with large blocks will be considered an alternative cryptocurrency traded under its own ticker symbol BTU. (Reuse of the acronym for “British Thermal Unit,” a measure of heat, provides unintended irony for those who consider BU to be a dumpster-fire.)

While that tactical response addressed the uncertainty in markets, it did not provide a coherent definition of what exactly counts as Bitcoin. In effects the signatories were declaring that the chain with the large blocks would be relegated to “alternate coin” status regardless of hash power. For a system where security is derived from miners’ hash power to issue a blanket declaration of the irrelevance of hash power is extraordinary. Arguably the harshest criticism came from left field: the Ethereum community. Ethereum itself had taken flak in the past for taking exactly the same stance of ignoring miner choices during the 2016 DAO bailout. Orchestrated by the Ethereum Foundation and widely panned as crony-capitalism, this intervention resulted in a permanent, with a minority chain “Ethereum Classic” continuing at ~10% of hash power. In a case Orwellian terminology, this alternative chain is in reality the true continuation of the original Ethereum blockchain. What is now referred to as “Ethereum” incorporates the deus ex machina of the DAO intervention. But from a governance perspective, the most troubling aspect of the DAO debacle concerns how the legitimacy of the fork was ordained. When faced with a faction of the community expressing doubts about the wisdom of intervention, the Foundation insisted that regardless of what miners do, the branch reversing the DAO theft would become the official Ethereum branch. Such a priori declarations of the “correct chain” go against the design principle of miners providing integrity of the blockchain through costly, energy-intensive proof-of-work. Why waste all that electricity if you can just ask the Ethereum Foundation what the correct ledger is? In anointing a winner of the hard-fork by fiat without regard for hash power, the Bitcoin community had exhibited precisely the same disregard for market preferences.

Once unmoored from the economics of hash power, arguments about which chain is “legitimate” quickly devolves into philosophical questions about identity. If you hold that 1MB block-size is the sine quo non of Bitcoin, then any hard-fork modifying that property is by definition not Bitcoin. Yet some of the same individuals arguing that changing to 2MB blocks would results in complete loss of identity have also proposed  changing the proof-of-work function, after evidence emerged suggesting that mining hardware from a particular vendor may be exploiting a quirk of the existing PoW function to optimize their hardware. Changing the PoW is arguably a far more disruptive change than tweaking block size.

So it remains an open question what exactly defines Bitcoin and to what extent the system can evolve over time while unambiguously retaining its identity as Bitcoin. Is it still Bitcoin if block sizes are allowed to increase based on demand? If the proof-of-work function is replaced by a different one? Or if the environmentally wasteful proof-of-work model is abandoned entirely in favor of proof-of-stake approach? What if the distribution of coinbase rewards is altered to decrease continuously instead of having abrupt “halving” moments? Or to take a more extreme example, if the deflationary model with money supply capped at 21 million bitcoin is lifted, allowing the money supply to continue expanding indefinitely? Is it still “Bitcoin” or does that system deserve to be relegated to alt-coin status with an adjective attached to its name? A related question is who gets to make the branding determination? When Ethereum went through its hard-fork to bail to the DAO, it was the altered chain bestowed with the privilege of carrying the Ethereum name; the original, unmodified chain got relegated to second-class citizen as “Ethereum Classic.” Would the situation have been reversed if the Ethereum Foundation was instead opposed to intervention and the hard-fork was instead driven by a grassroots community effort to rescue the DAO at all costs?

Having been pronounced for dead multiple times, Bitcoin continues to defy the odds. It is already up more than 50% against the USD for 2017 at the time of writing, having survived a crack-down on capital controls in China. Yet the contentious scaling debate shows no signs of slowing down. BU proponents continue to lobby for a disruptive hard-fork, while segregated-witness adherents play a a game-of-chicken with user-activated soft forks.  Will the resulting system—or one of the resulting systems, in case the contentious fork results in a proliferation of incompatible blockchains— still qualify as “Bitcoin”? Beyond the crisis du jour, it remains unclear if Bitcoin is capable of improving by incorporating new ideas, especially when these ideas call for a disruptive change  breaking backwards compatibility. If the community interprets every hard-fork as an identity crisis that calls into question the meaning of “Bitcoin,” the resulting stasis will  place Bitcoin at a disadvantage compared to alternative cryptocurrencies which are more responsive to market demand. (To wit, the so-called “Bitcoin dominance index” which measures the market capitalization of BTC as a fraction of all cryptocurrencies is now at an all-time low, having dipped below 50% mark.) There is something to be said about stability and consistency. Whimsical changes and excessive interventionism of the type demonstrated during the Ethereum DAO hard-fork do not inspire confidence in the long-term reliability of a currency either. Bitcoin so far has stubbornly occupied the opposite end of the spectrum, clinging to a literal, originalist interpretation of its identity defined by Satoshi.

That is one way of dodging the paradox of Theseus: this ship may be taking on water, but at least every single one of its planks is original.

CP

 

Trading cryptocurrency without trusted third-parties (part III)

[continued from part II]

Reliable execution matters

The preceding discussions suggest it is possible in principle to exchange cryptocurrency across different blockchains, without calling on a trusted third-party to hold funds in escrow. (Or viewed another way, the blockchain itself is the trusted third-party equivalent, its immutable rules guaranteeing all-or-nothing fair exchange where neither side can cheat the other.) That however is not enough to achieve feature parity with existing marketplaces. It provides only one piece of the puzzle: arranging for settlement of funds after a trade is agreed upon. The problem statement made a leap of faith in assuming that Alice and Bob already found each other, and somehow came to an agreement on price/quantity. But that arguably is the raison d’être of markets: helping buyers and sellers locate each other while facilitating price discovery. In realistic equity markets,  such arrangements of crossing buy/sell orders can take far more complex forms than  pairwise arrangements. For example it is very common for an order to be executed piece-meal: when Alice places an order to sell 10BTC, some fraction of that order is paired with Bob while the remainder goes to Carol. These can even take place at different times; Alice has a partially-executed order in the interim before Carol shows up, and she could even cancel the remainder.

Meanwhile accurate price discovery depends on reliable trade execution. Suppose the exchange stopped at matching Alice and Bob, delegating the actual trading for the individual parties to work out. Imagine Alice and Bob each receiving an email: “Congratulations, we found a counter-party for your trade. Here is their contact information.” At this point there is no guarantee that settlement will take place. If Alice or Bob back-out—which does not violate the fair-exchange property as long as neither side delivered anything—this trade did not occur as far as the market is concerned. That means the bid/ask quotes come with a prominent disclaimer: you can buy/sell at this price as long as your counter-party is in the mood for executing the settlement. This is very different from the expectation of trading in equity markets: if there is an order on the book to sell 10 shares of Google stock at a specified price, and a buyer shows up offering that exact price/quantity, there is very high confidence that this trade will execute. (In fact one of the main objections to high-frequency trading popularized by accounts like Flash Boys involve edge-cases where those guarantees are weakened due to order- spoofing and phantom liquidity: seemingly available trades disappearing when somebody attempts to take advantage of it by posting the corresponding buy/sell order.)

In principle, trade execution can be incentivized in a P2P exchange by creating an economic structure of rewards and fines. Customers who bail out on the settlement can be forced to pay additional restitution to the exchange or their counter-party. In some cases the guilty party is easy to determine. Fair-exchange protocols that leverage the blockchain can be audited publicly. Anyone can observe its progress and determine who backed out at which stage. But turning this into a fee/reward structure already requires creating a financial dependency between the exchange and its customers. For example, customers may have to post bond as insurance against abandoned trades.

Second there is still the problem of friction and delays introduced by forcing every trade to hit the blockchain. In a traditional exchange, when Alice and Bob swap BTC for ETH that trade is not reflected on any external blockchain. Only an internal ledger reflecting their balances is updated. Requiring all such transactions to execute on-chain both introduces delays and aggravates the scaling challenge, particularly in the case of Bitcoin which is already facing acute congestion while proposed solutions are mired in political gridlock. (Ethereum is relatively fast with block times measured in seconds and plenty of room in blocks to accommodate expanded usage.) At its current capacity, the network has an estimated total capacity around ~7 transactions per second. By comparison roughly 1 trade per second occurred for USD/BTC alone on major exchanges over the last thirty days. If all of that activity were reflected on the blockchain, it would account a significant fraction of overall capacity and further strain the overloaded network. And that is just one trading pair among many currencies for which BTC markets exist. Not to mention variable fees that must be paid to miners for moving bitcoin on chain, compared to the efficiency of updating an internal ledger.

Unless settlement is immediate and guaranteed, at best Alice and Bob have something akin to a futures contract in place. Each is promising to deliver some asset (BTC or ETH) at a future time for a price agreed upon today. That price is not an accurate reflection of present BTC/ETH price: neither party is guaranteed to receive their BTC or ETH immediately at that price. Especially for volatile assets such as cryptocurrency where price can fluctuate widely in a short span of time, this is an important consideration. Paradoxically such high volatility can encourage parties to back out of settlement if they have the chance. Suppose Alice agreed to sell 1 BTC for 20ETH but while she is working through the peer-to-peer settlement process with Bob, a spike in BTC price makes her assets now worth 21ETH. She has every incentive at this point to walk away from the trade and seek an alternative buyer at the improved price. Meanwhile Bob who assumed that he had a deal to exchange his ETH for BTC discovers that the offer was a mirage. Without a forcing mechanism to guarantee timely (ideally, real-time) settlement of trades, prices quoted on the order-book become an unreliable indicator of supply/demand.

Granted none of the preceding implies that a fully decentralized, trust-free exchange with real-time settlement can not exist. It simply points to the chasm that exists between current attempts to replace the traditional exchange model, and places the problem of settlement—which may well turn out to be the easy piece—in context with the full spectrum of functionality that full-fledged market places are expected to provide. There are many challenges and open problems involved in designing a solution that can reasonably compete with the existing paradigm.

CP

Trading cryptocurrency without trusted third-parties (part II)

[continued from part I]

To recap the scenario: Alice and Bob are interested in trading bitcoin (BTC) for ether (ETH.) Alice owns BTC, Bob has ETH, and they have agreed on pricing and quantity. (Note we are fast-forwarding past the scene where Alice and Bob miraculously located each other and organized this trade. That is one of the most valuable functions of a market, a point that we will return to.) Now they want to set up a fair-exchange where Alice only receives her ETH if Bob receives the corresponding amount of BTC.

Fragility of ECDSA as a feature

One way to do this involves turning what could be considered a “bug” in the ECDSA signature algorithm—used by both Bitcoin and Ethereum— into a feature. ECDSA is a randomized signature algorithm. Signing a message involves picking a random nonce each time. The random choice of nonce for each operations means even signing the same message multiple times can yield a different result each time. This is in contrast to RSA for example, where the most common padding mode is deterministic. Processing the same message again will yield the exact same signature.** It is critical for this nonce to be unpredictable and unique, otherwise the security of ECDSA completely breaks down:

  • If you know the nonce, you can recover the private key.
  • If the same unknown nonce is reused across different messages you can recover the private key. (Just ask Sony about their PlayStation code-signing debacle.)
  • It gets worse: if multiple messages are signed with different nonces with known relationship (such as, linear combination of some nonces equals another one) you can still recover the private key.

That makes ECDSA highly fragile, dependent critically on a robust source of randomness. It also means implementations susceptible to backdoors: a malicious version can leak private-keys by cooking the nonce while appearing to operate correctly by producing valid signatures. Variants have been introduced to improve this state of affairs. For example deterministic ECDSA schemes compute the nonce as a  one-way function of secret-key and message, without relying on any source of randomness from the environment.

But this same fragility can prove useful as a primitive for exchanging funds across different blockchains, by deliberately forcing disclosure of a private key. Specifically, it’s possible to craft an Ethereum smart-contract that releases funds conditionally on observing two valid signatures for different messages with the same nonce.

Setup

  • Alice has her public-key A, which can be used to create corresponding addresses on both Bitcoin & Ethereum blockchains.
  • Bob likewise has public-key B.
  • Alice generates a temporary ECDSA key, the “transfer-key” T.

Before starting execution, Alice rearranges her funds and moves the agreed-upon quantity of bitcoin into a UTXO with a specific redeem script. The script is designed to allow spending if either one of these two conditions are satisfied:

  • One signature using Alice’s own public key A but only after some time Δ has elapsed. This is a time-lock enabled by the  check-locktime-verify instruction.
  • 2-of-2 multi-signature using Bob’s public key B and the transfer key T.

Once this UTXO is confirmed, Alice sends Bob a pointer to the UTXO on the blockchain. In practice she would also have to send the redeem script for Bob to verify that it has been constructed. (Since the P2SH address is based on a one-way hash of the script, it is not possible in general to infer the original script from an address alone.)

Once Bob is satisfied that Alice has put forward the expected Bitcoin amount subject to the right spending conditions, he sets up an Ethereum contract. This contract has two methods:

  • Refund(): Can only be called by Bob using B and only after some future date. Sends all funds back to Bob’s address. This is used by Bob to reclaim funds tied up in the contract in case Alice abandons the protocol.
  • Exchange(signature1, signature2): This method is called by Alice and implements the fair-exchange logic. It expects two signatures using the transfer-key T over predefined messages, which can be fixed ahead of time such as “foo” and “bar”. The method verifies that both signatures are valid and more importantly they are reusing the ECDSA nonce. (In other words, the private key for T has been disclosed.) If these conditions are met, the contract sends all of its available balance to Alice’s address.

Alice in turn needs to verify that this contract has been setup correctly. As a practical matter, all instances of the contract can share the same source-code, differentiated only by parameters they receive during the contract creation. These constructor parameters are the Ethereum addresses for Alice and Bob, along with the public-key for T to check signatures against. That way there is no need to reverse-engineer the contract logic from EVM byte-code. A single reference implementation can be used for all invocations of the protocol. Only the constructor arguments need to be compared against expected values, along with the current contract balance.

Assuming this smart-contract is setup correctly, Alice can proceed with taking delivery of the ETH from Bob. She signs two messages with her private-key, reusing the same nonce for both. Then she invokes the Exchange method on the contract with these signatures. Immutability of smart-contract logic dictates that upon receiving two signatures with the right properties, the contract has no choice but to send all its funds to Alice.

At this point Alice has her ETH but Bob has not claimed his BTC. This is where the fair-exchange logic comes into play: Alice staked her claim to the ETH by deliberately disclosing the private-key T. Looking back at the redeem script for Alice’s UTXO on the blockchain, possession of T and Bob’s key B allows taking control of those funds. Bob can now sign a transaction using both private-keys to move that BTC to a new address he controls exclusively. Meanwhile Alice herself is prevented from taking those funds back herself because of the timelock.

The fine-print: caveats and improvements

A few subtleties about this protocol. Invoking Exchange() on the contract means the entire world learns the private key for T, not just Bob; blockchain messages are broadcast so all nodes can verify correct execution. Why not have Alice send one of the signatures to Bob out-of-band, in private? A related question is why not allow the Bitcoin funds to be moved using the transfer-key T only, instead of requiring a multi-signature? The answer to both of these is that Bob can not count on his knowledge of T being exclusive. Even if the Ethereum smart-contract only expected a single signature (having the expected nonce hard-coded) Alice can still publish the private-key for T to the entire world after she receives her ETH. If her funds only depended on a single key T for control, it would become a race-condition between Bob and everyone else in the world to claim them. Alice does not care; once she discloses T someone will take her BTC. But Bob cares very much that he is the only recipient and not have to race against others to get their TX mined first. Including an additional key B only known to Bob guarantees this, while also making it moot whether other people come in possession of the private-key for T.

Speaking of race conditions, there is still one case of Bob racing against the clock: he must claim the bitcoin before the time-lock on the alternative spending path expires. Recall that Alice can claw-back her bitcoin after some time/block-height  is reached. That path is reserved for the case when the protocol does not run to completion, for example Bob never publishes the ethereum smart-contract. But even after Bob has published the contract and Alice invoked it to claim her ETH, the alternative redemption path remains. So there is an obligation for Bob to act in a timely manner. The deadline is driven by how the time-locks are chosen. Recall that the Ethereum smart-contract also has a deadline after which Bob can claw the funds back if Alice fails to deliver T. If this is set to say midnight on a given day while the Bitcoin UTXO is time-locked to midnight the next day (these are approximate, especially when specified as block-height since mining times are randomly distributed) then Bob has 24 hours to broadcast the transaction. That time window can be adjusted based on the preferences of two sides, but only at the risk of increasing recovery time after protocol is abandoned. In that situation Alice is stuck waiting out the expiration of this lock before she can regain control of her funds.

Another limitation in the basic protocol as described is lack of privacy. The transaction is linkable across blockchains: the keys A, B and T are reused on both sides, allowing observes to trace funds from Bitcoin into Ethereum. This situation can be improved. There is no reason for Alice to reuse the same key A for reclaiming her Bitcoin as the key she uses to receive Ethereum from Bob. (In fact Bob only cares about the second one since that is given as a parameter to the contract.) Similarly Bob can split B into two different keys. Dealing with T is a little more tricky. At first it looks like this must be identical on both chains to allow private-key disclosure to work. But there is another trick Alice and Bob can use. After Alice gives the public-key for T to Bob, Bob can craft his Ethereum contract to expect the related key T* = m·T for a random scalar m used to mask the original key. He in turn shares this masking factor with Alice. Since Alice has the private key for T, she can also compute the private key for T* by simply multiplying with m. When she discloses that private-key, Bob can now recover the original key for T by using the inverse of m. Meanwhile to outside observers the keys T and T* appear unrelated. This provides a form of plausible deniability. If many people were engaging in transactions of this exact format with identical parameters, it would not be possible to link the Bitcoin side of the exchange to the Ethereum side. But “identical parameters” is the operative qualification. If Alice and Bob are trading 1BTC while Carol and David are trading 1000BTC, the transactions are easily separated. Similarly if the time-locks on ETH and BTC side are not overlapping, it becomes possible to rule out an ETH contract as being the counterpart of another BTC transaction posted around the same time.

Finally an implementation detail: why use the repeated-nonce trick for disclosing private key instead of simply sending private-key bits to the contract? Because the Solidity language used for writing smart-contract has a convenient primitive for verifying ECDSA signatures given a public-key. It does not have a similar primitive to check if a given private-key corresponds to a public-key. In fact it makes sense for Solidity to have no facilities for working with private-keys. Since all smart-contract execution is public, the assumption is only publicly available information would ever be processed by the contract and never secret material. For this reason we resort to the nonce reuse trick. Ethereum virtual machine also has the additional primitives required to compare two signatures for nonce equality. Interestingly Bitcoin script-language is exactly one instruction shy of being able to accomplish that. The instruction OP_CAT is already defined in the scripting language but currently disabled and for good reason: without other limits, it can be used as a denial-of-service vector. But if OP_CAT were enabled, it could be used to construct a redeem script that receives ECDSA signatures in suitably encoded form (nonce and second component as individual stack-operands) and checks them for nonce reuse. Other “splicing” opcodes such as OP_SUBSTR can also achieve the same effect by parsing the full ASN1 encoded ECDSA signature to extract the nonce piece into an individual stack operand where it can be compared for equality against another nonce. Either way, it would allow inverting the protocol sequence: Bob posts a smart-contract on the Ethereum blockchain first, Alice sets up the corresponding Bitcoin UTXO, which Bob proceeds to claim by disclosing the transfer key.

[continued]

CP

** RSA does have a randomized padding mode as well called PSS.