In Part 1 of this series, I demonstrated how we convert the interactive Schnorr protocol into a non-interactive variant, using something called a Fiat-Shamir transformation. This sets the foundation for the Schnorr signature scheme.

AOS signatures, the first type of ring signature we will be discussing, builds heavily off of Schnorr.

The idea of AOS rings work as follows: Bob gathers public keys belonging to Alice, Carol and Dave from some directory. Because their keys are assumed to be public knowledge, the scheme requires no interaction from anyone outside of Bob. Alice, Carol and Dave may not even know that their keys are being used.

Bob then creates a Schnorr signature using his private key. Note that Bob does not have access to Alice, Carol or Dave’s private keys. Normally, this means that he would be incapable of issuing signatures on behalf of these individuals.

The AOS protocol flips this idea on its head. Using a bit of cryptographic magic, they allow a method for Bob to forge signatures on behalf of the external parties without knowing their private keys. These forged signatures are then concatenated with Bob’s valid signature to create a cohesive “group signature”.

Incredibly, if Bob’s portion of the group signature is produced legitimately (i.e. by using his private key), the forged portions representing Alice, Carol and Dave will appear equally legitimate from the perspective of a validator. Cryptographically speaking, the verifier can only decipher whether or not someone in the group signed their index using the private key. But they are incapable of determining which member it was.

This plausible deniability allows Bob to preserve his identity as the group’s coordinator, while at the same time, provide assurance to a validator that some member had knowledge of the private key, and was thereby authorized to create the ring.

Read the full AOS report here

Before we get into ring signatures, we need to differentiate between interactive and noninteractive proofs of knowledge. Interactive proofs engage in a pre-processing round where the two parties (prover and verifier) exchange relevant information in order to construct a signature. The hand waving overview looks like this:

The prover has a keypair (x,P), where x is the private key and P is the public key. P is publicly broadcast, while x remains hidden to the prover alone.

When dealing with signatures, specifically of the Schnorr family, our commitment is constructed by picking a random nonce value r, then encrypting it to create R. Specifically, the encryption process works by performing R=r*G (mod n), where G is some specified elliptic curve generator point. The discreet logarithm assumption now makes it safe for us to give R out to the rest of the world, because trying to reverse engineer r given only R is computationally infeasible.

The challenge is some randomly selected scalar of the verifier’s choosing. We call this e. The verifier ships e back to the prover only after he is given R by the prover.

Finally, after receiving the challenge back from the verifier, the prover takes x, e and r and uses them as inputs to the signature function: s = r+e*x. This is the response.

At this point the verifier can check the validity of the response by feeding P, R, s, e (all of which are public parameters) as inputs into the verification algorithm. The algorithm works by first taking the signature value, then multiplying it by the generator point G. After calculating this sG value, the verifier then moves to the other side of the equation, and computes R + e*P. If both sides match, she knows that the prover does in fact know the discreet logarithm, aka they are in possession of the underlying private key x and authorized to sign the message.

Going forward, we will refer to the prover as Peggy (starts with a P), and the verifier as Victor. Even though Peggy uses r (plaintext nonce) and x (private key) in the computation of the signature, Victor will be incapable of recovering these variables independently. A good analogy is trying to recover the primary ingredients of a cake (eggs, milk, flour) once they been blended into batter. Victor only sees the encrypted values R and P (which Peggy includes publicly when broadcasting the transaction) and plugs them into the equation. However, he is mathematically convinced of authenticity of the signature, because the only person who could make this equation balance is someone that possessed the secret values x and r.

Now, if Peggy were to find out what e value Victor was going to pick in advance, then she could cheat the whole protocol and forge a [seemingly] valid signature WITHOUT knowing x. Here’s how:

1. Peggy picks a random s value, not really caring what the value is. This s value will simply be a facade in her ploy to trick the verifier.

2. Peggy knows that during the verification process, Victor will take the signature and multiply it by G to see if the equation balances (bottom left formula in above graphic). So, she takes her random s value in step #1 and multiplies it by G.

3. With sG locked in, Peggy now turns and computes R by using the bottom right formula. She is able to do this because a) e was leaked by Victor in advance b) P is the public key that everyone in the world can see c) sG was just computed in step 2.

4. Peggy ships off the values (R,s) to Victor for verification.

Poor sucker Victor will plug Peggy’s signature value into the verification algorithm, and it will return a TRUE response. Now, if Victor was seeing the r and x values going into the construction of s = r + x*e, he would be able to spot the forgery. Unfortunately, if we gave Victor these secret values, we’d lose the entire value proposition of the signature, i.e. Peggy not having to reveal to the rest of the world what her secret private key is.

Also notice in our above description that if Peggy doesn’t have access to e in advance, she can’t back out a malicious R and trick Victor. Why? Because in the Schnorr protocol, literally the first thing we require is that Peggy commit to a R value (by choosing a nonce r, then computing R=r*G) BEFORE she receives Victor’s e challenge. In the malicious equation R = sG - e*P, we are using e as an INPUT variable. It’s common sense that we cannot use something as an input which we do not yet know, outside of randomly guessing what Victor’s e value may be ahead of time and constructing R that way. But given the massive parameters being used, we can say that the chances of such an event occurring are so astronomically small that they are negligible.

So, we can say one of two things happened if the equation balances: either Peggy truly does know the secret key x, or Victor slipped Peggy knowledge of e ahead of time, allowing her to craft a signature. However, since Victor is the one who’s trying to figure out this question, he will know whether or not he colluded, meaning the only conclusion left is that Peggy indeed knows the private key, and created the signature honestly.

Non-interactive Variations

The frustrations with the scheme described above are twofold. First, it requires both parties to communicate back and forth before the proof can be constructed. This is especially problematic for blockchains where we need the prover to be able to append some information to the chain and immediately walk away. Not every party will be online at all times, some could lose connection midway through the exchange, some might be malicious etc. Reliance on external parties in a real-time scheme is impractical, thus we prefer an autonomous alternative.

Secondly, interactive schemes are not publicly verifiable; again, a huge impediment to a blockchain-based system. The interactive model only works when the two parties involved want to demonstrate proof among themselves. Remember, if Peggy is slipped knowledge of Victor’s e before the scheme, she can forge a valid signature without knowing the private key. But what if another validator comes along (call her Carol) and wants to audit Peggy’s signature herself? Carol wouldn’t be able to tell if there was collusion involved between Peggy and Victor in the last trial. The only way Carol can derive conviction is if she forces Peggy to perform the trial again, using a different e value of Carol’s choosing. Peggy would then have to replay this simulation over and over as new verifiers show up.

This is where non-interactive proofs come into play. Using a technique called the Fiat-Shamir heuristic, we can transform any interactive proof of knowledge into a non-interactive one, where we cut out the back-and-forth commitment/challenge phases and skip straight to signature construction, without requiring any interaction from the verifier’s end until validation. Additionally, we gain a second property of public verification, where Peggy can issue a single signature that will sufficiently satisfy any validator in question.

How is this accomplished? By “automating” away the verifier’s role in the challenge phase. In the interactive sequence described above, the only relevant operation performed by the verifier is providing a source of randomness for the e value. With the Fiat Shamir transformation, we can replace that role with a hash function and receive the same feature, but in a publicly auditable fashion.

This is viable because by definition, hash functions take in arbitrary length input values, and map them to fixed outputs that are indistinguishable from random. It’s impossible to reverse engineer the input, given the output alone. Another key component is that hash functions are deterministic, meaning the inputs to the hash function can be replayed over and over, and each time the output stays the same. For example, below is a SHA256 hash table on the following input variables. Verify the digests here.

The hash function provides us with a form of native time ordering. In order to compute the output of a hash H(X), we need to choose an X value before we can evaluate H(X); i.e. if I want to find e= H(5), I need to select “5” before I can solve for e. We can apply this concept to our protocol and gain some coveted properties.

In the non-interactive Schnorr protocol, instead of e being provided by verifier, we reassign e= H(R). Notice that in our new definition, we are guaranteeing that R is determined before the e value is chosen, as the hash of something cannot be evaluated prior to that something being known.

Security threats exist in the interactive Schnorr protocol which are not exploitable in the non-interactive model. We acknowledged earlier that Victor, being the one choosing the random e value, can interpret whether or not Peggy knows the discrete logarithm. But this is only true under perfect security assumptions. What if the piece of hardware Victor is using to generate the random nonce is being key logged by Peggy? Or what if the RNG Victor is using is not truly random, and Peggy is able to guess ahead of time what e value might get spit out in advance? If this was the case, Peggy would be capable of forging a signature without the private key. Victor would have no way of knowing that he’d been compromised and would interpret the invalid signature as valid.

We eliminate these social engineering attacks (assuming the hash function is secure) simply by removing the verifier altogether. Signature construction is isolated around Peggy alone, and Peggy cannot trick herself. Even if she decides on an R value and computes its hash well in advance of generating the signature, the very act of her committing to the R value in her head means that the time ordering has been set. There is literally no possible way Peggy can obtain e prior to R unless she picks some e value first, then goes back after the fact and randomly guesses its preimage, which violates our definition of a secure hash function.

The other benefit provided by this model is universal conviction to any validator, not just Victor. In our interactive example, the only person confident that Peggy possesses knowledge is Victor, because he is the one providing the randomness to e. An outside observer Carol cannot know that Peggy and Victor aren’t colluding. With this new scheme, any external validator can derive the same conviction as Victor, because cheating the protocol would require breaking the hash function, which is assumed to be impossible.

In Part 2 of this series, I will explore an interesting cryptographic technique called chameleon hashes, which sets the a foundation for ring signature construction. I’ll also perform a step-by-step walk through of AOS rings, the first (and most basic) iteration in the ring signature family.

In 2014, a group of notable Bitcoin developers published Enabling Blockchain Innovations with Pegged Sidechains. This whitepaper outlined a very high level framework on how sidechains might look, but lacked significant technical specifications with regard to implementation. Two years later, a group of Blockstream researchers released Strong Federations: An Interoperable Blockchain Solution to Centralized Third-Party Risks, describing how many of the aforementioned concepts could be implemented utilizing a semi-trusted Byzantine fault tolerant consensus mechanism referred to as strong federations. Strong federations fall somewhere between the extensive decentralization guarantees provided through Nakamoto style consensus, and the significant trust implications of centralized exchange services. In this article, we explore one of the first iterations of federated two-way pegs: Liquid, a settlement network primarily directed towards exchanges and other liquidity providers.

What do sidechains provide?

Sidechains allow us to take an asset that traditionally exists on a remote chain, and transfer it onto a different blockchain, without distorting the asset’s integrity. For example, imagine there were a way to move bitcoin onto the Ethereum network. Though it is impossible to actually move a BTC onto another chain, we could create a synthetic ETH token collateralized by real bitcoin on the mainchain. Anyone holding the ETH token could exchange it at any moment for real BTC, and thus the two assets would exhibit a 1:1 (or near 1:1) peg.

Having this capability opens the door to many different form of unique cross-chain interoperability features, such as executing smart contracts across different blockchains. Sidechains always involve a source and destination blockchain. A peg is established between the chains, meaning assets from the source are converted into entirely new ones on the destination, at a fixed ratio (usually 1:1). Since the destination sidechain is its own independent blockchain, destination tokens can be transferred freely among network users, just as they would inside of the source network. Users are free to reconvert their sidechain tokens back into mainchain ones at their full discretion. Usually these destination tokens provide beneficial features that the source chain cannot: privacy, Turing-completeness, fast settlement or low fees. In our scenario, Bitcoin serves as the source blockchain, with Liquid as the destination.

Functionaries

To begin, let’s first start off by defining two important figures within the Liquid ecosystem:

1) Watchmen- play an important role serving as gatekeepers, regulating the transition of assets between the source and destination blockchains.

2) Blocksigners- contribute to the creation of new blocks, similar to miners in proof-of-work systems and validators in proof-of-stake systems

Both of the above parties fall under the collective roof of functionaries. Functionaries are a privileged set of network actors who mechanically perform defined network operations. By privileged, we are referring to a fixed group of permissioned actors who have the capacity to fulfill these roles. Contrast this to open system like Bitcoin, where any network participant has the ability to contribute to the consensus process through open mining operations.

Entry into the sidechain is a process referred to as a “peg-in”, where Bitcoin users deposit BTC to a specially constructed address, called a pay-to-script-hash (P2SH). Traditional Bitcoin scripts usually just require the spender to produce a valid signature from a private key. This private key corresponds to the public key in which the funds are encumbered. P2SH requires the spender to produce a few more pieces of information outside of just a digital signature. The scripts required to spend the LBTC reads: <11 of 15 Multisig> OR <4-week timeout + 2-of-3 Multisig>. We will touch on this construct and its importance in later segments.

Once bitcoins are sent to the P2SH address, the depositing party loses sovereignty over them. A confirmation period ensues to guarantee settlement of the funds, preventing against the risk of a chain reorganization or double spend attack. Without sufficient confirmation that the pegged-in BTC has settled, an attacker might be granted LBTC prematurely on the Liquid sidechain, while their BTC manages to “escape” on the mainchain through a reorg or doublespend. Such an event would lead to a situation where LBTC and BTC no longer maintain a 1:1 pegged ratio, thereby granting the attacker free money.

Liquid requires 102 BTC confirmations for the transaction in order for the LBTC to become available. This seemingly ambiguous number exists for 2 reasons:

1. 100 blocks as overkill to guarantee that a reorganization is probabilistically impractical. This is the same depth that the Bitcoin protocol requires miners to wait before being able to spend their coinbase rewards when they solve a new block. While 6 confirmations is usually considered sufficiently strong for a BTC transaction, there have been a few rare occasions of orphaned blocks extending much deeper (though this usually only happens during some obscure bug interval). For example, the March 12, 2013 fork extended 31 blocks, while the 2010 value overflow bug extended an orphan 53 blocks.
2. 2 blocks to ensure every node agrees on the 100th block. Given our first principle, conflicting views could exist amongst the network nodes as to which block that 100th block is, were a chain split to happen after the 99th mined block. By extending depth an additional 2 blocks, we allow the blockchain some leeway time to re-converge if necessary.

It is important to understand that the BTC on the Bitcoin chain is not destroyed. Rather they remain “frozen” in the multisignature account until the corresponding LBTC are revoked off the destination chain, and proof has been illustrated that such action has taken place.

Examining LBTC Creation

BIP 32 introduced a set of important features that allows for hierarchical wallet structures. Hierarchical frameworks are useful because they allow for deterministic construction of new public keys (and therefore unlimited new BTC addresses) without needing underlying exposure to the public key’s corresponding private key. This is a great feature for online merchants wanting to incorporate Bitcoin payments at point of sale. They can upload something called the master private key into their web server, and compute sub-domains of new bitcoin addresses directly from this master public key. Previously, they would have had to either expose their private key onto the server in order to derive new addresses (dangerous) or generate a bunch of new private/pub key pairs offline, then manually import the addresses over to the server (inefficient).

We can think about the construction of new LBTC in a somewhat similar fashion, though some technical differences remain. Essentially what the user is doing during a Liquid peg-in transaction is performing some cryptographic tricks to derive a new public key (call this A’) directly from each functionary’s existing public key (call this A), in a similar way that BIP 32 allows one to derive a child public key from a parent public key without needing involvement from the corresponding private keys. The user then sends their BTC to a special P2SH address that references all these new A’ addresses. This P2SH transaction reads very analogously to a multisignature clause. It says “if 11 functionaries (out of the 15 possible) prove ownership of the A’ public keys outlined in this template, by collectively signing off with their corresponding a’ private keys, they can unlock and spend the funds.”

After issuing the Bitcoin P2SH transaction, the user needs to actually let the functionaries know that the transaction occurred. Up to this point, the functionaries still have no idea that they’ve been paid; everything has been done on the user end. The user now needs to turns around and hand this new template of A’ to the functionaries, so that they can reverse engineer the corresponding a’ and gain access to the locked up BTC.

The way the user goes about doing this is by creating a LBTC transaction from scratch. The inputs to this transaction will look a bit funky, because they reference no previous LBTC output (think coinbase transactions when miners mine a new BTC block). Instead, the LBTC transaction embeds the original BTC transfer as its input, illustrating proof that the user previously surrendered their BTC rights into the hands of the watchmen. Seeing that they’ve been paid via the A’ public keys and the 102-block confirmation period has passed, these functionaries can reverse engineer back to its corresponding private keys a’ and assume control over those funds. With all the boxes now checked, the functionaries will validate the peg-in LBTC transaction by including it into a Liquid block.

Once the new LBTC are unlocked onto the Liquid sidechain, users are free to engage in transactional behavior at their full discretion. Very similar to the traditional Bitcoin blockchain, LBTC are governed by the underlying private keys of their owners, are immutable digital assets, and publicly auditable through a distributed ledger. LBTC also possess certain characteristic advantages over the tradition BTC network. Examples include resistance to reorganizations, 1-minute block times, deterministic block intervals (instead of dynamic block production), and ring confidential transactions.

When users are ready to convert their LBTC back into BTC, they engage in the “peg-out” process. This involves transferring their LBTC to a Liquid address where they wait for 2 block confirmations. Because there is no threat of reorganizations occuring on the Liquid network, we don’t have to wait the meticulous 100-block period as we did during the peg-in process. After 2 Liquid blocks have ensued, watchmen sign off the 11 of 15 transaction on the Bitcoin mainchain, transferring money to the entitled owner, and subsequently destroying the LBTC in the process.

Peg-Out Transactions

When funds are ready to be transferred out of the Liquid sidechain and back into the Bitcoin network, the LBTC needs to be destroyed and the corresponding BTC released from multisig via the Watchmen efforts. In an effort to preserve privacy and mitigate security risks, functionaries control a Peg-out Authorization Key list that ensures outgoing BTC transactions are sent to a bitcoin address controlled by an authorized party. However, this creates an unfortunate situation where any user needing to redeem their LBTC to BTC must do so through an exchange or partner with a block signer. Essentially what we have happening is the user sends LBTC to a burn-style address, then waits 2 confirmations for that LBTC transaction to settle. The exchange sees the transaction as confirmed, pays out the user from their own hot wallet, and is subsequently “reimbursed” by receiving the BTC from the functionary multisig.

The intention of this strategy is aimed to reduce the risk of theft on the sidechain, which would consequently lead to theft on the mainchain. Peg-out addresses which the Watchmen pay out to are air-gapped cold addresses maintained by the exchanges. These addresses are constructed in a way that make it incredibly difficult to compromise the underlying private key.

Emergency Recovery Process

Remember how we earlier touched on the <11 of 15 Multisig> OR <4-week timeout + 2-of-3 Multisig> P2SH that keeps our Bitcoin locked up? The <4-week + 2-of-3 Multisig> clause serves as an emergency recovery component in a situation where ⅓ of the network goes offline or begins engaging in nefarious behavior. If such an event were to take place, the network would stall out and fail to produce additional blocks, but the Bitcoin on the mainchain would be stuck in escrow if the 11 of 15 component is not capable of being overcome. So, we introduce a second clause that consists of a completely different set of 3 emergency keys which can be used if (and only if) the network sits idle for 4 weeks, and we only need 2 of those 3 signers to sign off and move funds out. These keys are controlled by a totally different set of functionaries (undisclosed who these participants are for security reasons, but presumed to be geographically distributed attorneys) and can only be utilized after the 4 week lapse. Because of this, functionaries need to “churn” the locked BTC on the 27th day by sending it to to a new peg-in address they control, as a way to reset the timelock. Otherwise, 2 of the 3 emergency component would go into effect, and functionaries could then collude and steal user deposits.

Consensus Algorithm

In Bitcoin, miners bundle transactions into aggregated units called candidate blocks, with each candidate displaying a unique header. These miners subsequently perform redundant SHA-256 hashing on such headers, tweaking the nonce field element after each iterative hash, until someone in the group arbitrarily produces a digest below a predefined target. The winning party broadcasts their solution to the rest of the network, who can validate its authenticity. If the rest of the network is satisfied by the proof, they simultaneously adopt the winning party’s candidate block as the “official” ledger state.

Liquid does not depend on a dynamic hashing contest to reach network consensus. Rather, it involves a Byzantine fault tolerant, round-robin multisignature scheme amongst a privileged group of blocksigners (the second group of functionaries we touched on earlier). These blocksigners inherit a role similar to miners in PoW, or validators in PoS; their job is to contribute to forward propagation of the network by creating new blocks, and thereby validate transactions. By limiting the number of candidates capable of contributing to consensus rather than remaining an open consortium, the network is able to achieve universal consensus with lower latency, faster block intervals, and lower computational burdens. In many respects, the consensus algorithm replicates features found in the Ripple RCPA protocol, described here. The system involves a round-robin style where blocksigners rotate turns proposing candidate blocks. After the blocksigner issues a candidate, their peers signal intent to validate the block through a precommitment scheme. At the conclusion of the precommitment round, if 2/3 or more of the group has signaled favorably, each member proceeds by actually signing the k of n block with their key. If the number of signees is greater than 2/3 then the block is accepted by the network and written to ledger. Note that the number of blocksigners who commit to sign and those who actually end up signing may be slightly different. For example, if someone loses connection midway through the process. The system rotates to a different block signer who proposes a new candidate block, and the process repeats.

A compelling feature of the Liquid BFT is that a reorganization after two block’s depth is impossible (assuming no malice or bugs). If a candidate block fails to reach its designated threshold, or the selected functionary for that 1-min time frame fails to perform their duty, no block for that interval is produced. Those transactions then carry over into the next candidate round. Users are not at risk of the network forking into two conflicting chains. The tradeoff to this scenario is that the network has the potential to stall out if blocksigners continually fail to reach the designated threshold required to append a new block.

Privacy

Liquid offers privacy features to users by embedding Ring Confidential Transactions directly into the protocol. Ring CT shields important metadata such as the transactional output values along with the destination/recipient addresses. Similar to Zcash, Liquid users have the ability to broadcast transactions on a transparent or confidential basis. However, the protocol automatically issues transactions on an opaque basis by default; users must manually configure transactions if they want the metadata to be publicly exposed. When dealing with CT’s, only the participants that have access to the what is known as the blinding key are capable of viewing such information. This key is limited to the sender and recipient of the transaction, but can be passed along to other parties as they like.

The benefit to such a system is that it allows network participants selective disclosure. Selective disclosure gives network participants the ability to preserve the integrity of information that may be sensitive to their business or trading operations, while simultaneously offering the ease and flexibility of sharing this data in a frictionless manner with authorized parties (business partners, auditors, government officials etc). A great example of where CT might prove beneficial is for traders who are looking to place large orders. Since the Bitcoin blockchain is available for public audit, external actors can witness the movement of large funds to an exchange and front run, driving up the order book and forcing the trader to incur slippage.

Challenges

While there are many positive implications of LBTC, it also comes with its share of tradeoffs, especially for node operators. Some of the biggest performance limitations include:

• 1MB block size (relatively low)
• 10x CPU requirements over BTC
• 10x bandwidth requirements over BTC
• 10x transaction sizes compared to BTC due to CT features. However, drastic improvements are on the horizon with the implementation of bulletproofs (see XMR)
• UTXO sets could grow exponentially larger
• Synchronization and new node bootstrapping could get significantly more difficult and computationally expensive
• Higher trust implications (discussed in later segments)

Issued Assets

Another interesting feature Liquid provisions are Issued Assets. Issued Assets are analog to the ERC-20 standard commonly found on the Ethereum network, and are uniquely native to the Liquid sidechain. Any sidechain participant has the ability to issue and transfer their own Issued Asset with other users inside the Liquid ecosystem. The provisioners can elect for supply to remain permanently fixed, or maintain discretionary autonomy over its future inflation schedule. This is accomplished through a feature called the reissuance token, which subsequently can be constructed using a multisignature scheme and dispersed among numerous parties. Different scenarios where these assets may come into play is if an issuer wants to distribute some form of tokenized security across a highly liquid and interconnected network: gold storage tokens, fiat backed tokens, shares in a company, collectables, ETF-related products etc.

Risk Mitigation

If not already obvious, some attack vectors lay present. Functionaries are not only required to communicate with one another, but sometimes depend on these communication broadcasts in order to determine how they themselves should act in specific situations. For example, during the precommitment of the consensus algorithm, if a blocksigner themselves signals “Yes” for a specific candidate block, but sees that not enough signers signaled accordingly to meet the X target, they will sit out during the actual signing phase. If an attacker is capable of infiltrating more than 1/3 of the blocksigners, they could force a network stall out simply by refusing to vote, and preventing the require 2/3 consensus to be achieved in order to create a block. If they are capable of corrupting 2/3 of the blocksigners, they could validate nefarious blocks.

To prevent against such threats, when new functionaries join the network, Blockstream provides these agents with proprietary hardware to conduct network operations. This hardware consists of two components: a server with precompiled software to perform network operations, and a “offline” hardware module to store functionary keys. These hardware boxes are designed in a way that purposely limits their vulnerabilities to network stack exploits which could compromise the consensus process. Each functionary server is presumably stored in a secure, anonymous location, and only communicates to other functionary servers via Tor. Tor connections provide security by obfuscating the server’s IP address, reducing the risk of physical theft or tampering while simultaneously hedging against potential DDOS attacks on the server. RCP calls are severely restricted and the hardware is specifically configured to only allow incoming SSH connections when a button on the box is pressed. Meaning to make any software or network alterations, you need to be in physical location of the hardware, severely limiting attack vectors.

The most obvious threat to the Federation is the group of functionaries themselves. At the end of the day, users transacting across the Liquid network are forced to trust the functionaries. If more than ⅔ of the functionaries collude, they have the ability to steal user funds. However, given the game-theoretic incentive models at play, the probability of this happening seems relatively low. First and most obvious, these functionaries are not anonymous parties but publicly recognized institutions that operate in jurisdictions where laws exist. The probability of a set of functionaries openly colluding to steal user funds without being subject to legal recourse are slim to none. Second, with regards to covert collusion (playing it off as a hack), exchanges would naturally be disincentivized to steal from their customers, thereby driving away core business revenues (exchange fees), unless the payoff from the attack outweighed the cost of collusion plus opportunity cost of capital relinquished from future business revenues. Consider also the fact that the cost of collusion grows logarithmically with respect to number of total parties colluding. Unless the Liquid network grows to a considerable value, it is highly improbable scenario this happens, given how much money these businesses are making on trading fees.

Workflows

Liquid’s audience will primarily cater towards exchanges, market makers and other large liquidity providers, along with their users. While Issued Assets might offer compelling opportunities for asset issuance, the scripting capabilities offered by other blockchain systems and higher levels of throughput make it a highly competitive and saturated market. Traders on the other hand are in fervent demand for quicker asset settlement, illustrated through the radical price discrepancies that exist across premier exchanges. Being able to move significant volume across platforms will reduce friction and costs for traders and liquidity providers alike, while simultaneously improving overall market efficiency by reducing spreads between exchange indexes.

Conclusion:

While not the most bleeding edge implementation of sidechain technology, Liquid addresses a legitimate and current need in the cryptoasset ecosystem by allowing traders and exchanges to provision liquidity and settle transactions in short order. Benefits include embedded privacy through confidential transactions, higher throughput, faster settlements times, and ability to issue custom assets. Drawbacks include increased computational costs to node operators, higher degrees of trust than Nakamoto consensus, and counterparty risk of stolen or irrecoverable funds. If successful, Liquid validates the sidechain model, and opens the Bitcoin blockchain for increased functionality in further implementations. This no doubt comes with certain risks, but is a development challenge worth pursuing given the non-coercive nature of this technology.

Many thanks to Allen Piscitello from Blockstream, Pietro Moran and Hasu for their contributions to this piece!

Overview was originally published in Good Audience on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Lightning Network is a protocol layer that seeks to provide instantaneous, trustless Bitcoin payments. In this article, I walk through the construction process for Lightning Channels and illustrate how multi-hop transfers are initiated. This article is the third piece in a multi-part series where I attempt to deep dive into notable cryptoasset projects.

Background

The Lightning Network is Layer 2 infrastructure built on top of the Bitcoin protocol, and hopes to increase transactional throughput. Bitcoin has a hardcoded upper bound limit on the number of transactions it can process. In traditional payment rails, ledgers are updated every few seconds and can achieve high degrees of scalability. These systems reach finality quickly and efficiently due to their centralized structure: clients communicate directly with the master server, who make ledger alterations in real time as notice is provided.

Bitcoin faces inherent challenges since the system utilizes distributed architecture. When new information needs to be appended to the ledger, that information must be redundantly pushed across every participating server inside the network. These servers must parse through the data and reach consensual agreement on which transactions they intend to accept and write to database, and which to reject. The difficulty in this scenario arises when multiple servers have conflicting views on transactional sequencing. Each node in the ecosystem maintains equivalent weight, so without top-down authority to establish a canonical vision, the system would eventually stall out if participating validators are unable to reach consensus.

Bitcoin introduces the concept of mining to guarantee network progression and prevent ledger fragmentation. Miners contribute computational power from specialized hardware to earn the right to propose ledger alterations during iteration rounds which occur roughly every 10 minutes. A mathematical challenge is included in each round. If a miner is able to find a solution, they earn the right to establish canonical vision of the ledger, which the rest of the network accepts based off protocol rules. When a claimant proposes a solution, other nodes can verify integrity of the solution. Peers will only recognize the claimant’s ledger version if the solution is valid.

When we talk about “vision” of the ledger, we are referring to the construction of blocks. Blocks are aggregations of transactions compressed into a singular file unit. When a miner “solves” a block, they earn the right to inscribe their view of the ledger to the blockchain, an immutable database containing an archive of previous network transactions. Transactions are simply lines of code, so they have deterministic size. With the blocks having an upper bound limit at 1MB, the system can process ~7 transactions per second (tps). In contrast, networks like VISA can support ~50,000 tps.

Overview

The Lightning Network utilizes the concept of payment channels to provide bi-directional monetary transfers, and envisions a network with near-instantaneous speed, zero counterparty risk, and low fees. In doing so, the Lightning Network aims to alleviate scalability concerns surrounding the Bitcoin protocol. The system routes around the bottlenecks of universal consensus by settling transactions off chain, avoiding latency and computational redundancies that plague blockchains. Lightning claims transactional processing capabilities in the millions of tps.

Funding Payment Channel

The first step involves an initial funding transaction where each party deposits BTC into a 2-of-2 multisignature address. Once deposited, each participant has full guarantee of security, since any forward movement of funds will require signature authentication from both parties. But what if the channel is unable to progress forward after the funding transaction? If the opposing party becomes unresponsive or loses their private key, any balance locked up in that channel is permanently lost. Thus, both sides of the agreement need insurance against counterparty risk that may ensue.

To solve this dilemma, users draft refund transactions and have their counterparty sign. These transactions are constructed before either individual deposit to the multisignature address, and allows for revocation of the original funds back to channel depositors. Bob asks Alice to draft a settlement transaction that refunds his deposit back to himself. Alice complies with the request, drafts the message, and signs it with her key. She then returns it to Bob. In the process, she also includes a similar refund script for her bitcoins. Bob reviews the transaction, and if the outputs align with his specifications, attaches his signature to the message, relaying it back to Alice. Both members now possess a symmetric transaction which they tuck away as leverage for a future mishap. In the event either party becomes unresponsive, the counterparty can simply broadcast the transaction to the network, creating an escape route to withdrawal their balance from the multisig. Both individuals are now protected and can deposit to the channel with full reassurance.

Commitment Advances

With funds locked up in the multisig account, a “channel” is now created. Participants can issue fully valid transaction scripts to one another via private medium, and both parties can accept these instruments of payment as valid without having to broadcast the payment on-chain. In doing so, these commitments act as a form of promissory note with enforceable guarantees backed by the Bitcoin blockchain, all while avoiding the bottlenecks and costs of universal consensus. If circumstance requires, either party can push the latest commitment version to the blockchain and close out the channel without requiring approval from their counterparty.

Problems arise when it becomes economically advantageous for a participant to push a previous commitment to the blockchain. Returning to our example, after both depositing a 1 BTC balance, Bob sends 0.5 BTC to Alice inside the channel. His balance will now show 0.5 BTC, and Alice’s will read 1.5 BTC. But remember, Bob has his initial refund TX, signed by Alice, that allocates 1 BTC back to himself. Bob is now incentivized to push this outdated transaction to the network and make off with Alice’s money. Thus, we need some method to invalidate previous commitments.

Commitment Transactions

When Bob and Alice want to advance the state of the channel, they need a way to autonomously enforce their contracts. This is done through commitment transactions. Suppose Bob wishes to send Alice 0.5 BTC. Each party creates two near-identical transactions spending the same input values. These transactions operate similar to a RBF or a Doublespend- if both transactions are pushed to the blockchain, only one of them will ultimately confirm and be appended to the ledger since they reference the same input values. Bob and Alice carefully construct these transactions in a manner that makes it deterministically provable which will be included into a block first.

Bob creates a transaction by referencing a set of outputs, and signs with his key. We call this transaction C1Bob (Commitment1Bob), which he forwards to Alice. Alice mirrors this action, creating C1Alice and forwards to Bob. Because these transactions are originating from the 2-of-2 multisig, neither party’s script is valid until both signatures are transcribed. Once Bob and Alice put their stamp of approval on each other’s commitments, they are voluntarily accepting the potential of their counterparty broadcast the transaction at any point in the future (thereby closing the channel). Bob cannot push the transaction he constructed to the network, since he doesn’t possess Alice’s private key. Bob can only broadcast Alice’s version, and Alice can only broadcast Bob’s.

The above illustration describes the redemption paths if a commitment were broadcast on-chain. If Alice were to push her transaction to the network, she would initiate two events. The first would immediately unlock Bob’s balance, allowing him to transfer his funds. The second would trigger a countdown on her funds. Alice will have to wait 1,000 blocks in order for her outputs to unlock. Once this timespan has elapsed, her funds will become available for redemption. This process is mirrored on Bob’s commitment. If he pushes his version to the network, Alice’s funds are immediately unlocked, while he has to wait 1,000 blocks. These lockup intervals are set to mitigate counterparty risk.

We introduce the concept of Revocable Sequence Maturity Contracts (RSMC) as a means to invalidate previous commitments. This occurs via the scripting flag CHECKSEQUENCEVERIFY (CSV). CSV’s are a way to dynamically lock up bitcoins over a predefined time interval, and is enforced by the Bitcoin blockchain rather than users themselves. CSV checks for the current block height (aka the sequence) from the moment the transaction is included in a block, and verifies that the encumbrance scripts are met. In the example above, it is the CSV encumbrance in the transaction that forces Alice/Bob to wait 1,000 blocks for their funds to become redeemable. This creates a bonded deposit window where a plaintiff can present a breached remedy tool in the event the counterparty tries to broadcast an outdated commitment.

Creating Breached Remedy Commitments

When Bob and Alice want to advance the state of the channel, they need a way to invalidate previous commitments. Bob and Alice repeat the commitment process by constructing a new 2-of-2 multisig account (aka C2Bob, C2Alice) with a fresh set of keys. They reference their outputs, enact similar 1,000 block CSV scripts, sign the transaction with their own keys and pass along to their counterparty. Their counterparty tucks this transaction away. However, before finalizing the new C2Bob/C2Alice commitment schemes, both parties disclose their private keys used in C1Bob/C1Alice. Once this occurs, each party is protected from publication of outdated commitments.

As mentioned earlier, if Bob closes out the channel, Alice’s funds are immediately spendable. Bob’s money on the other hand is locked up for 1,000 blocks by the CSV encumbrance. If Bob tries to cheat the system by broadcasting an outdated commitment whenever financially incentivizing to do so, those funds are not immediately accessible. Alice will see that Bob is trying to cheat her, and use her breach remedy “tool”. This tool allows Alice to spend the 1,000 block encumbered funds immediately if she can provide Bob’s private key. Alice is capable of fulfilling this obligation now that the channel state has advanced, because Bob has voluntarily relinquished the key to her in the last round. Thus, Alice can not only ensure that she won’t be cheated out of the BTC she is owed, but will be able to walk away with the entirety of Bob’s balance, making additional money. Thus, Bob is highly incentivized not to try and cheat the system by publishing outdated commitments, since Alice will be able to walk with his entire deposit. Conversely, if Alice tries to pull a similar trick on Bob, he can walk with the entirety of her deposit. This creates incentive models where both parties are highly incentivized to act altruistically.

Cooperative Channel Closeout

When either party wants to close out the channel, they can do so cooperatively by disregarding all outstanding promissory notes and constructing a normal transaction from the original 2-of-2 escrow. This transaction would pay out the respective balance to each member, based off the most recent commitments. Because the outstanding promissory notes are backed with full guarantee by the blockchain, both parties have an incentive to collaborate. Neither individual has to go through the frictionary process of paying additional on-chain fees, nor lose out on opportunity costs of time having their BTC locked up by the CSV encumbrances for 1,000 blocks.

Hashed Timelock Contracts (HTLC’s) and Multi-hop Transfers

HTLC’s are forms of transactional encumbrances which use hashlocks (locking scripts that ensure certain data is known) and timelocks (restricts future spending of outputs until a predetermined date) as a way to enforce provisions on a transaction. Both types of encumbrances are enforced by the blockchain rather than channel counterparties. The concept is fairly simple, and serves as a way to extend payment channels beyond a bi-directional state. Lightning Network will have the ability to route channels deterministically through multiple parties through a process called multi-hop transfers. At first, Lightning might not be very appealing unless two participants plan to remunerate very frequently, since opening a new channel requires locking up assets via an on-chain broadcasted transaction. Bob having unique channels with many participants means less money in his wallet for discretionary spending, significantly reducing the versatility of his funds. Lightning alleviates these concerns by introducing an effective path finding algorithm between network participants, and linking their channels together via HTLC’s. Bob and Alice are two individuals who want to transact, but don’t have an existing channel open. If both parties have a mutual channel connection with Steve, they can still route the transaction with full guarantee of atomic settlement. This works by Bob paying Steve, who in turn pays Alice. Bob has now trustlessly paid Alice without needing to open a channel with her. If the relationships between participants are extremely isolated, we can keep introducing more intermediaries to form a lineage robust enough to facilitate payments.

Bob(the sender) initiates the multi-hop process by communicating directly with Alice(the beneficiary). Bobs asks Alice to create a randomly generated secret R, which remains private to Alice. Bob asks Alice for a hash of R, called the preimage, but not the plaintext version of R itself. Bob subsequently specifies only to disclose R to an intermediary party, Steve, in exchange for 1 BTC.

So, Alice hashes R, and sends a copy of the preimage to Bob. Bob takes this preimage to Steve, and offers a 1 BTC bounty if he can produce the hash’s plaintext version, R. Steve accepts the offer, and goes to Alice with an offering of 1 BTC in exchange for the secret value. Note that in this situation, Steve front runs his own capital to make this exchange with Alice. Alice, seeing this offer of 1 BTC in exchange for an arbitrary secret R, accepts the proposition and gives the value of R to Steve, just as she was instructed earlier by Bob. Steve then hands R to Bob in order to claim his bounty. In this example, Bob has found a trustless way to pay Alice, without having to go through the burden of opening a channel with her. If Bob and Alice lack a mutual contact to route the channel through, we can keep introducing more intermediary liquidity providers until a connection is made. For example, if Bob has an open channel with Steve, and Alice has an open channel with Sarah, and Sarah and Steve have a channel together, a payment can be initiated.

CHECKLOCKTIMEVERIFY (CLTV) vs. CHECKSEQUENCEVERIFY (CSV)

What is the difference between a CLTV and a CSV? Both are examples of timelock encumbrances, and are used to accomplish similar goals.

Suppose a CLTV encumbrance is placed on an output for 10 blocks. The current BTC block height is b=500,000. Once the blockchain hits b=500,010 the outputs unlock and become spendable. The time at which the original transaction gets a confirmation is irrelevant to the spender.

In contrast, a CSV script is based entirely on the time the original transaction is included into a block. Suppose a CSV script is placed on an output for 10 blocks. The current BTC block is b= 500,000. Once this transaction is broadcast, it sits unconfirmed for 5 blocks. After 5 blocks ensue, it finally gets picked up and included at b=500,005. In this scenario, the timer begins once that transaction gets its first confirmation. The CSV encumbered output doesn’t become spendable until 10 subsequent blocks at b=500,015. Conversely, if the original transaction receives its first confirmation at b=500,003 then the outputs becomes spendable at b=500,013.

In summary, a CSV sets a dynamic encumbrance that makes an output spendable after a specified number of confirmations once the original transaction is included in a block. In contrast, with CLTV you are specifying when the output will become spendable based off block height. This means that the output’s encumbrance status is completely independent of the mining process.

Constructing Hashed Timelock Contracts

In our previous example, we presented a basic overview of how a multihop transfer can occur, but failed to articulate how to create an enforceable contract on the blockchain to facilitate those functions. For example, what if Alice fails to produce the secret value after Bob transfers her the bitcoin? Or what if Bob revokes his bounty commitment to Steve after acquiring the secret from Alice? In both scenarios, Steve has lost money.

In order to create a trustless layer of commitments, we build off similar RSMC properties outlined in earlier sections, but add a few twists. After Bob communicates directly with Alice and receives a copy of her preimage, he constructs a hashed-timelock contract (HTLC) transaction with Steve. This contract has two paths for output redemption. The first is a “delivery” path which sends Steve 1 BTC immediately if he can produce the secret R. The second is a “timeout” path which allows Bob to refund himself in the event Steve cannot produce the secret. This is accomplished using a CLTV flag instead of the CSV as in previous examples.

In the transactional script, Bob sets the timeout length of the CTLV to 1,000 blocks. This means Steve essentially has 1,000 blocks to obtain R from Alice and claim the 1 BTC bounty via the “delivery” path. If he waits longer than this time, he loses guaranteed insurance that he can claim the bounty safely. Steve mirrors this same transactional script with Alice, front running his own personal capital in the process. If Alice wants to claim the 1 BTC sitting in escrow, all she needs to do is reveal the secret R. Once Steve has R, he can turn around and use it to pull the 1 BTC out of escrow sitting between him and Bob. Everyone gets paid.

Importantly though, these “timeout” intervals must decrease in length as the chain progresses right to left. The timeout between Alice and Steve must expire earlier than the timeout between Steve and Bob. If they expire simultaneously, Bob runs the risk of transferring his funds to Alice near the end of expiration, and then having Bob’s “timeout” unlocking before he has time to grab his funds out of escrow. In this scenario, Steve would be left doing the bagholding, since he front ran capital to Alice but was not able to collect from Bob. To make matters even more challenging, blocks are solved in random 10-minute intervals. There is no inherent guarantee that a subsequent block will be solved 10 minutes after a previous. It could happen 1 second afterward. This is why CLTVs are used instead of CSVs. Thus, it is imperative that participants provide ample blocks between channel “timeouts” to prevent loss of funds.

If Steve cannot obtain R from Alice (she is a fraudulent actor, becomes unresponsive etc.), nothing is hurt. He simply lets the channel expire and revokes his money out of the escrow by using the “timeout” path. This will set off a chain reaction, where Bob will revoke his funds out of escrow once they timeout. Though the parties may experience opportunity costs of locked-up capital, they have full reassurance that they can ultimately reclaim those escrowed funds.

Interestingly, disruption of the channel somewhere along the line does not destroy payment guarantee, but actually strengthens it. Suppose Sarah fulfills her end of the obligation and provides Steve with R, but Steve remains unresponsive and does not update their channel balance. In such a situation, Sarah is still capable of obtaining the 1 BTC she is owed through the HTLC contract. If Sarah uses the “Delivery” Path, R becomes publicly available on the blockchain; she has to disclose it in the metadata of the transaction to unlock the encumbrance and receive her BTC. Intermediary liquidity providers can extract this information off the blockchain and use it to unlock their escrow channels immediately, without ever having to wait for their correspondent to reveal R to them. This structure provides cryptographic certainty that each claimant will be able to receive their capital, so long as they push the TX before the CLTV encumbrance expires.

Recap

Final Closeout

The beautiful thing about Lightning Network is that all these described provisions will rarely take place on-chain. Participants can avoid broadcast of all these intermediary steps and simply pay one another out at the conclusion of the channel using traditional payment terms. These intermediary technicalities exist for the sole purpose of protection. Participants essentially load a gun, then handing it over to the opposing channel member with instructions to shoot if they act dishonestly. Incentives are aligned to follow the rules by constructing channel operations in such a manner. Thus, altruistic behavior is a rational assumption. If participants act dishonestly or become disconnected for extended periods, the Bitcoin blockchain acts as an enforcement mechanism to ensure integrity of commitment balances.

Follow me on twitter for more Crypto insight!

More where this came from

This story is published in Noteworthy, where thousands come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more stories featured by the Journal team.

Ripple is a financial services company that looks to facilitate global payments through blockchain-based technologies. Unlike most crypto-related projects, Ripple has carved out a niche by looking to integrate their products with legacy institutions, improving on their infrastructure rather than trying to displace them. The company is built around a novel trust-based consensus mechanism that allows the transmission of any arbitrary asset across its network. However, the system cannot guarantee delivery of the asset, it can only transfer cryptographically provable contracts, subjecting the transacting parties to counterparty risk. To address these dilemmas, the protocol created a native token, XRP, which provides full guarantees of on-chain settlement in a matter of seconds.

Problem/Solution

Systemic friction exists inside the global payments and remittance industries. Institutions can move money within their network seamlessly, but inter-ledger transactions pose a problem due to their complexity. Banks move money across ledgers via multiple correspondent accounts, which usually take days to settle, cannot guarantee finality, and requires substantial capital lockups. Due to endogenous fixed costs, transaction fees are traditionally high while transparency and competition are low.

Trust lines exist between banks which allow for such inter-ledger transactions. If a transfer needs to be made between Bank of America and Chase, and the two have an existing channel where they are willing to accept IOUs from one another, their outstanding balances only need to be settled periodically. If no line of credit exists between the two parties, the transaction must hop through various middlemen until it ultimately reaches the final beneficiary. This process is expensive and takes a significant amount of time.

Ripple looks to improve on this process by creating a unitary network that bridges siloed ledgers. The system routes a direct path between transacting parties, building off this practice of IOU relationships. Imagine Bob and Alice are two individuals who want to transact, but don’t trust one another to extend a line of credit. If both parties have a mutual connection with Steve, they can route the transaction through a lineage of trust. This works by Bob paying Steve, who in turn pays Alice. Bob has now indirectly paid Alice without ever needing to inherently trust her. If the relationships between parties are extremely isolated, we can keep introducing more intermediaries to form a lineage robust enough to facilitate payments.

By having these IOUs compartmentalized onto a single electronic network, Ripple can assist in settling inter-ledger payments with greater transparency, reduced fees, and shortened settlement intervals.

Product Suite

xCurrent:

xCurrent is Ripple’s blockbuster product, consisting of a settlement solution for banks and other financial institutions. xCurrent can support a variety of different assets and instruments. For example, if Bank A wants to pay Bank B with USD, but Bank B wants to be paid in EUR, the network will automatically source a liquidity route for each party to be paid in their respective currencies. xCurrent is conducted through Interledger (ILP), a completely independent protocol layer that uses hash time-lock contracts to facilitate trustless payments over ledger systems.

ILP is trustless by design and works with an escrow-like mechanism analogous to Bitcoin’s lightening network. Once a liquidity route is established, parties deposit the asset of interest to their correspondent by placing it in an escrow account. This sets off a chain reaction, where the correspondent deposits to an escrow account with their subsequent correspondent. This continues down the line until the ultimate beneficiary is reached.

Once the beneficiary sees the money waiting in escrow, they sign a cryptographic receipt acknowledging reception of the funds. Signature of this receipt catalyzes two reactions. First it allows the beneficiary to claim those funds out of the escrow and get paid. Second, that receipt allows the correspondent to claim the money sitting in escrow with their correspondent.

This form of atomic settlement ensures security across each leg of the channel. Correspondents carry just as many incentives as the transacting parties since they post their own collateral to facilitate movement of the funds. If the chain is broken by an intermediary, stakers have full guarantee of being refunded due to the escrow mechanisms.

Overall, xCurrent offers significant benefits compared to legacy financial systems. Payments take mere seconds to complete, while guaranteeing settlement by providing end-to-end visibility. This results in lower operating overhead, fewer risks, and decreased transaction costs.

xRapid:

xRapid is an emerging technology layer imbedded into the xCurrent network that allows sending and recipient parties to use the native XRP token to issue payments. Rather than sourcing liquidity routes through numerous correspondent payment providers, thereby incurring numerous transaction costs, participants can cut out the middle men and transmit funds to one another directly. xRapid transactions are conducted over the novel Ripple Protocol Consensus Algorithm, which we explore in later sections of this article.

Banks either hold XRP reserves on their balance sheets, or have dedicated liquidity lines facilitated through the xRapid layer. Originating banks convert fiat to XRP, transmit it over the Ripple medium to the Beneficiary bank, who then converts the XRP holdings back to fiat through their local liquidity provider. This process can achieve finality in a matter of seconds and eliminate a great deal of overhead/conversion fees associated with xCurrent.

xVia:

xVia is a standard interface solution for payments conducted across the X-series platforms. The system provides a compliance backed, friendly interface for initiating real time transactions over xCurrent or xRapid networks. The project itself is still under construction, with limited details on the explicit underpinnings of the technical architecture.

In the following sections, we explore the open-sourced Ripple protocol.

Characteristics

Accounts:

Like Ethereum, Ripple uses a configuration model where the ledger marks systematic changes to a specific state of the network. These changes are referred to as transactions, and these transactions alter consensus to the underlying account. Transactions can be a payment from one account to another, offers to trade, or alterations to existing trust lines and account settings. If the network has reached universal consensus of the ledger at time t, any new reflections of consensus at time t+1 can be accounted for via the transactions that occurred during the intermission period.

The bitcoin protocol tracks ownership of UTXO encumbrances to specific addresses. By focusing on a single address, users can determine the history of different UTXOs that have previously been encumbranced to that address, along with bitcoins that are currently being locked. Similarly, individuals can derive information by auditing an XRP account. Accounts on the Ripple network include an identifying base58 encoded address to receive payments, outstanding balance, activation information, and a unique element called the sequence number. The sequence begins at 1 when the account is activated, and tracks each subsequent transaction to the account moving forward.

Signature Algorithms:

Ripple uses elliptic curve based algorithms to generate underlying key pairs. By default, the protocol uses the same secp256k1 scheme found in Bitcoin. However, Ripple also offers a more efficient, Schnorr-based ed25519 algorithm for users to take advantage of. Account owners start by generating a master keypair from which transactions can be signed. The protocol offers also includes subset keypairs called regular keys which can be permissioned with signature properties. Keeping credentialed regular keys on a hot connection proposes an ideal mechanism to maintain security of the underlying master pair. If the integrity of the regular keys is compromised, permissions can be revoked and assigned to a fresh set.

Block Construction:

Blocks do not exist in the Ripple protocol. Rather, they are replaced by ledger versions. Nodes receive incoming transactions and relay them to connected peers. After a specified time interval (currently 2 seconds), nodes gather non-validated transactions sitting in memory, compiling them into an aggregated unit designated as a candidate set. Nodes pass along their individually compiled candidate sets and those from peers, creating an individual perception of the state of the network. This is referred to as the open ledger. Through the Ripple consensus process, differences between nodes’ open ledgers begin to converge, until they reach a canonical agreement on what transactions will ultimately be appended to the ledger. This instance becomes the last closed ledger, and represents the most current state of the network ratified by the consensus process.

Like accounts, the ledger archives information about the state of its contents. Some of this content includes:

• Account configuration settings
• Trust lines that exist between accounts
• Account balances
• Transactions specific to that ledger version
• Timestamp

Most importantly, each ledger is assigned a unique sequence number, that is always n+1 its parent. By ordering Ledger versions in this manner, a secure hash chain can be formed. Transaction sets advance the ledger and provide a full snapshot of the network at any interval. As a result, prior states of the ledger are not a necessary component and can theoretically be pruned from disk space (though most choose to maintain the entire history). This provides a significant advantage with respect to block synchronization, where bootstrapping nodes can engage in the validation process simply by obtaining a timestamp from the last closed ledger. Once the current sequence number can be extracted, the user only has to follow the block headers to the genesis point. Contrast this to UTXO-based protocols like Bitcoin, where each full node must synch a copy of every transaction in blockchain to compile an authenticated vision of UTXO ownership.

UNLs:

When a new server configures to the Ripple network, they must bootstrap to peers in order to determine the sequence number of the current ledger. Once this is accomplished, they can begin verifying integrity of the chain by trailing through the hash tree, iterating through the block headers and verifying alterations to accounts produced through transactions. Doing all this requires the node to compile a unique node list (UNL) of peers they can trust. Not only will this node reach out to its trusted validators to bootstrap their client, they will engage with these peers going forward during the Consensus algorithm to vote on new alterations to the ledger. Because both of these interactions rely on mutual trust between the participants, the node with the largest amount of UNL connections has the greatest influence inside the network.

Validators synching to the network for the first time are often isolated. Peer nodes are pseudonymous by nature, making it hard to establish these trust lines that are so critical to the integrity of the Consensus process. Furthermore, the network exerts no incentive structures for validators to act altruistically, making Sybil attacks a relatively cheap endeavor. The Ripple protocol overcomes this dilemma by establishing a default UNL of trusted validator sets run by Ripple Labs themselves. It is important to note that the protocol does not require the user to interact with the default UNL, and actually encourages those with the resources to configure a custom UNL. However, it is probable that the majority of nodes choose to default to the pre-compiled list, not only due to their exclusivity from the rest of the network, but the fact that these Ripple validator sets are well provisioned. This means the user can request large “fetch packs”, submitting far fewer queries when synching up, thereby expediting the process. While Ripple has worked to increase the number of validator sets and simultaneously pledged to democratize the network by removing themselves as validators in the future, the company currently operates the largest number nodes. Not only do they have the largest number of nodes, but these nodes are the most interconnected, meaning they have the highest degree of influence over the network.

Byzantine Generals Problem

Every distrusted payment system must include some form of Byzantine fault tolerance to prevent against the doublespend problem. Throughout most of history, doublespends have been a trivial matter, since physical assets cannot be permissioned twice. As money evolved into digital form, this problem became much greater, as the code comprising the asset is easily duplicable. The Bitcoin protocol achieved notable recognition by proposing the first known solution to this barrier where no centralized fail point exists. The consensus mechanism is backboned by the Proof of Work algorithm where miners contribute computational hashpower to earn the rights to propose a block. However, the protocol includes a mathematical challenge for each prospective candidate to solve, in order to earn the right to establish a canonical vision. When a claimant proposes a solution, peers can mathematically verify its integrity ensuring the required work was fulfilled by the issuer. Different forms of consensus mechanisms emerged over time, some evolving away from the concept of a computational race altogether to minimize latency, energy resources, and other plaguing challenges associated with this industry standard. These novel consensus systems still face the underlying Byzantine Generals Problem, requiring conception of a unique solution. Ripple has proposed the Ripple Protocol Consensus Algorithm (RPCA) as a circumvention tool to route around these described challenges. The architecture relies on small, independent networks where trust between altruistic actors serves as the consensus mechanism. These independent networks are then cross-referenced with one another, ultimately converging on a universal status of the ledger in a mathematically provable manner, even amidst segments of independent networks behaving nefariously.

Consensus Process

The RCPA process works to ultimately advance the ledger sequence. The process consists of three phases: deliberation, consensus and validation:

Deliberation:

Clients begin by the process by broadcasting a Ripple transaction to the network, where it is received by two types of nodes: validating and tracking. These nodes subsequently flood the network by transmitting it to their peers, who pass it along to their connections. Soon, every connected party in the network has received notice of the broadcast. If the node is a validating node, it initiates the consensus process. The validator checks the authenticity of the message by verifying that the signature data matches the corresponding public key. If it does, the validator adds that transaction to a list L that is stored locally. Simultaneously, the node appends this transaction to its current candidate set. After doing so, the node will check the transaction for correctness. It does this by comparing the logs from sequence t-1 and ensuring alterations to the account have been accounted for. If the transaction utilizes the XRP medium, this means ensuring the spender has necessary funds available in their account. If done with a non-native asset, the validator ensures that a trust line exists between the two parties, and that transaction meet the specified requirements of that relationship.

Consensus:

The validator keeps performing this function of analyzing incoming transactions and appending them to the candidate set. At the conclusion of each phase (every 2 seconds), the validator packages the candidate set into a singular unit, hashing the transactions into a tree and signing the corresponding merkel root. This merkel root, called the proposal, is then broadcast to the peers on the validator’s UNL. When receiving a new proposal, peers ensure its integrity first by checking the identity of the sender against their UNL. If they are not a member, the proposal is immediately discarded. If they are a member, the validator compares the transactions in the bundle against those stored locally in their set L. For each transaction the node iterates through in their peers’ proposal, if the transaction appears inside their local L, they add a vote to a secondary local list V. Nodes continue swapping proposal bundles until they have cross referenced every member on the UNL. After parsing the data, they take all transactions from V that appeared in at least 50% of their peer’s proposals, discarding those that didn’t.

Validation:

Nodes repackage these 50%+ “winners” into a new proposal and submit a hashed version to the UNL for a second iteration round, repeating the cross referencing process. This cycle of new proposals continues in 10% increments until the UNL network hits quorum, the parameter which specifies the minimum number of agreeing nodes in the UNL in order to validate the ledger, currently configured at 80%. Once this interval is achieved, nodes recognize the version hash as the last closed ledger, and begin working on appending a new ledger version n+1.

Consensus is only implemented to solve the double spend problem. Transaction sequencing is a deterministic function, since validators’ only role is to aggregate transactions on a time basis. This is not the case for proof-of-work based protocols, where miners play a hands on role in determining which transactions will be admitted into each block.

Emission:

Ripple does not have a distribution method natively inscribed into the protocol. Rather, all XRP were pre-mined upon creation of the token in 2013 and allocated to entities or persons within the organization. Below is a summary of the provisioning terms:

• 100B XRP tokens were created upon launch
• 80B XRP were allocated to Ripple Labs
• 9.5B XRP to Founder Jeb McCaleb
• 9.5B XRP to Co-Founder Chris Larsen
• 1B XRP to Co-Founder Arthur Britto

Concern over Ripple’s ability to manipulate XRP markets increased as market liquidity began to emerge. Investors worried that an arbitrary decision by the company to dump a considerable amount of holdings would devastate XRP price. As we touch on in later sections, this argument holds little rational sense considering that XRP holdings account for more than 98% of the company’s assets. For transparency stake, Ripple decided to lock up 55 billion XRP into escrow smart contracts with provisioned terms. At the beginning of each month, the escrow releases 1B XRP into treasury accounts to finance operations. There are no stipulations that these XRP must be used by the firm. Any excess XRP is refunded into a new escrow contract that is appended at n+55 months. For example, if 500MM XRP remain unused at month 1, these 500MM tokens are locked up into a subsequent escrow contract which become available for use at month 56.

Network Upgrades

Rippled is the official reference client for the Ripple Protocol, written in C++ and actively maintained by Ripple Corporation full time developers. While the code is open sourced, contributors are limited to employees of the firm, meaning the company has effective control over protocol implementations. This has tradeoffs in both directions. It allows system continuity and effective governance to the platform, reducing friction associated with conflicting ideology that tends to plague progress. However, it brings challenges in the face of forced network upgrades, reducing sovereignty at the individual level.

Bitcoin strives to implement network updates that are backward compatible, meaning user software updates are fully functional with underlying consensus rules. These updates are referred to as soft forks, which are non-contentious implementations. Backwards compatibility allows the user to opt-in to new features on a consensual basis; individuals are fully capable of rejecting the upgrades and maintaining legacy software without interruption, even if the overwhelming majority of the network has chosen to implement the new features. Not only does this respect individual sovereignty, these procedures are also considered less risky. Some nodes may not receive message of the new consensus rules. If the network requires all servers to upgrade simultaneously, there is a high probability some will get pushed out.

Backwards-incompatible implementations, often referred to as hard forks, requires changes to the consensus protocol rules rather than the user software that interfaces them. Users that continue to operate under the old parameters are rejected by those running the new (and vice versa). This creates a difficult situation where a minority of participants could be pushed out of the network if a majority upgrades, or a worse, a fork emerges where the network fragments into two separate lineages. This detracts from both user sovereignty and network security.

Improvements to Ripple frequently require changing the consensus-critical codebase rather than user software. If individuals fail to upgrade, they run the risk of operating outside of Consensus parameters and being removed by their UNL peers. Network hard forks tend to be less of a risk for protocols with fewer node operators and a smaller user base like XRP has. This is because the majority of the participants tend to exhibit similar visions for the network. That being said, as the system begins to expand, operating under these parameters does come at a tradeoff to sovereignty. Ripple Corporation can implement new features with or without community consensus. Node operators that disagree with the implementations could refuse to upgrade, but because Ripple’s servers are connected to so many UNL’s due to default configuration, they would most likely be pruned from the network very quickly.

Challenges

UNL Trust Model:

XRP critics tend to vocalize their discontent with the Ripple Consensus process, stating that it inherently contradicts the decentralized ethos. Criticism of the process algorithm can usually be summarized in two regards: a network that relies on altruism between participants revokes guarantees of a decentralized system, and Ripple’s default configuration to point bootstrapping nodes towards company-run servers ultimately grants them permissioned advantages over other nodes in the network, thereby revoking decentralization.

Critics outline some fair points, and the Ripple company does face inherent dilemmas due to the manner in which the Consensus model is constructed. As official documentation on the website states, nodes inherently rely on peers inside its UNL to engage in the consensus process. Reliance on these validators involves allocating a level of trust in each party to perform their validation tasks honestly:

“Chosen validators represent a subset of the network which, when taken collectively, is “trusted” not to collude in an attempt to defraud the node evaluating the proposals. This definition of “trust” does not require that each individual chosen validator is trusted. Rather, validators are chosen based on the expectation they will not collude in a coordinated effort to falsify data relayed to the network.”

As interaction between UNLs starts to converge at higher levels of the consensus process, the structure starts providing provable security guarantees. However, this doesn’t necessarily solve any of the described challenges, as potential “pollution” occurs at the ground level, compromising the integrity of anything that follows.

Consensus models with some form of security validation provide an inherently greater level of safety than a trust-based model, because they configure financial incentives that induce the actor to purse altruism out of rationale self-interests. This occurs because these protocols punish individuals that attempt to operate outside of the defined parameters. In Proof of Stake, this means revoking the validator’s deposit. In Proof of Work, this involves burning a tremendous amount of energy, hardware and bandwidth the miner can never reclaim. The incentive structures create game theory scenarios where the marginal cost of a network attack are much higher than the economic benefit that they could potentially gain.

Placing blind faith in an entity to perform their role in an honest fashion seems to illustrate a reversion to trust-based models decentralized systems seek to pivot away from. Critics argue that nodes inside a UNL can never validate the ledger independently, because the consensus process ultimately converges on an upper bound quorum threshold. Once that quorum is reached, opponent’s vision is deemed meaningless. Unlike in bitcoin, there is simply no guarantee of security on an independent basis. This is because the UNL proposals are ratified on the basis of majority-rule. If an overwhelming number of servers in the UNL are nefarious, an honest participant has no hedging mechanism against bad behavior and ultimately will be overruled. Even worse, the honest participant is subjected to the negative externalities of the group’s conduct. They are essentially forced to sign off on the nefarious proposal as a member of that UNL, even if they personally refuse to validate incoming proposals from their peers. In bitcoin, nodes work on a completely independent basis aggregating UTXO ownership and relaying transactions according to consensus rules. This means they have full have full jurisdiction over what they choose (or don’t choose) to relay across the network, and are not subjected to the actions of others.

UNL Centralization:

Contrary to popular belief, every distributed system relies on some degree of a majority behaving honestly. In bitcoin for example, we operate under the notion that 51% of the hashpower acts in accordance with the protocol rules. However, it is important to note how incentive structures in these networks are constructed. In the long run, participants will always act according to rational self-interest. We cannot assume inherent altruism. It is possible to predict a majority of honest actors when incentives reward participants for doing good, but if the payoffs for operating against the consensus protocols are high, expect a system of nefarious conduct.

The Consensus process can work efficiently, as long as the participants act altruistically. As mentioned in previous sections, default UNL configuration points bootstrap nodes to servers operated by Ripple themselves. Nodes can safely allocate trust in these peers since the Ripple Company has a high incentive to see the network operate functionally. Undoubtedly though, this configuration comes at a tradeoff to decentralization. Even Ripple themselves has articulated the need to improve in this regard:

“Decentralization of XRP Ledger is a process that started right at its inception and has been ongoing since. We intentionally haven’t rushed the process and have been making continuous progress all along. To meet the growing demands of our customers, we need to diversify the validator ecosystem to further increase resiliency and robustness.”

XRP critics are quick to point fingers at the degrees of centralization exhibited in the Ripple network, but fail to recognize that decentralization is an extensive and ongoing process. In fact, the majority of distributed systems we see today are centralized to some degree. No system is immediately endowed with decentralization, but accrues it after years of expanding its network. Every new protocol is configured with training wheel support as its infrastructure builds out. Ultimately, subsidiaries hope to remove intervention and allow the system to operate on its own.

Given current outlooks, questions still remain whether this will prove functional for the Ripple protocol, based off the alignment of incentives and the way the protocol is inherently constructed. While the Consensus process relies on trusted behavior between UNL participants, critics argue that the system lacks inherent incentive structures for a rationally motivated participant to behave accordingly. If the Ripple Corporation relinquishes UNL support prematurely, it opens up the door for a wave of Sybil attacks. It is relatively inexpensive to operate a node, validators contribute directly to progressing the ledger, and nodes have huge financial incentives if they can disrupt the ledger through double-spends. Furthermore, the protocol exhibits a “nothing at stake” problem where nodes are not reprimanded for attempting to push faulty transactions through the system.

UNLs have the ability to prune lagging nodes or nodes that exhibit nefarious behavior. This feature is effective under stable conditions when a minority group is acting to disrupt the consensus process. However, it also has the ability to further problems under chaotic situations. If Ripple validators were removed from the system (ie a governmental shutdown, internal corruption etc) and a large scale Sybil attack was simultaneously launched, the nefarious nodes could theoretically gain significant influence over fragmented UNLs. This collusion could be used to push out honest nodes, creating a furthered downward spiral.

Node Incentives:

There is little rational incentive for the average individual to run an XRP validating node. Some argue that this is the same case for bitcoin, but that is not necessarily true. Operating a full node is the only way to guarantee full security and privacy in the bitcoin network. Having a full sequence of transactional history is the only way to ensure authentic compilation of UTXO ownership, using an SPV client simply outsources this task to someone else. Running a ripple node does not inherently guarantee that same layer of sovereignty, as a minority group inside a UNL could be overruled by a majority of bad actors. Furthermore, unless an individual node has an extensive layer of trust with other servers, it is highly doubtful any peer servers would configure their UNL with that individual. Thus, adding more nodes doesn’t necessarily help contribute to the robustness of the ripple network. The system needs corporate/institutional partners to operate servers for people to feel confident trusting that node. However, one could argue that large financial institutions will be incentivized not to run an XRP validating node under a fully distributed RCPA model, due to potential legal recourse that could ensue. Imagine the PR backlash a bank would receive if it came out that one of its UNL peers was a darknet market, and the bank themselves played a direct role relaying drug and money laundering related transactions. Operating an XRP validating server means operating under a system that is permissionless and filled with unknown participants. Given the stringent KYC/AML banks and financial institutions face, it is highly unlikely many would want to participate in the process given the risk of not knowing the identities of other participants in the ecosystem.

This creates a chicken and the egg problem for the XRP network. In summary, the consensus model inherently relies on trust between UNL participants. It is hard to accumulate trust when dealing with anonymous servers. Most individuals will default to a Ripple Corp UNL due to these described risks. This creates centralization around Ripple validating nodes and an easy shutdown point for a state sponsored authority. Ripple can try to hedge this risk by enticing its X-suite clients to run servers, but many of the companies will not want to engage due to potential legal challenges that could ensue. Even if they find participants, these companies would still be quite limited and easily censorable. Ripple cannot afford to leave the validation process without stable infrastructure in place, lest the network becomes heavily disrupted by low-cost Sybil attacks.

XRP Token Analysis

Debate whether or not XRP meets the definition of a security has long plagued the project, especially as the price of the token has ballooned over the past 18 months. Some argue that it fits the criteria outlined in the Howey Test, while others disagree. I do not intend to digress into that argument, and will assume current legal status of XRP holds and token is not classified as a security.

Ripple Corporation and the XRP token are two entirely distinct entities. Ripple Corporation generates revenue on fees they charge their enterprise clients for using X-suite products, along with sales of company owned XRP in treasury. Ripple (the company) is a San Francisco based C corporation that has raised over $93.6MM of venture capital funding. As such, the firm’s fiduciary responsibility is limited to that of its shareholders. Although there is a strong correlation between XRP and Ripple due to their large allocation of tokens, autonomy over the consensus protocols/user software, and executive board that consists of 2/3 original founders, Ripple believes that XRP network is a completely independent system outside the jurisdiction of the company. Similarly, Ripple maintains that the company was gifted 80B XRP by the founders, rather than the company creating the protocol and allocating tokens internally. This viewpoint illustrates that Ripple has no fiduciary duties to XRP holders. While the company would love to see all stakeholders in the ecosystem accumulate wealth, their legal obligations of returning value are confined only to Ripple Corp investors.

While this may not come across as striking, it is an extremely important concept to consider when assessing XRP token value. When investors buy stock in a company, they are obtaining a percentage of equity in exchange for front running capital. This capital helps the firm finance operations and expand their business model, ultimately to produce higher earnings. Investors hope that the management teams can use this fresh capital to deliver on promises. If the business does become more profitable as a result of this investment, this capital will be returned in the form of appreciated equity, dividends, or both. An investor could then turn around and trade their equity on a public market for cash value. Ideally, the price this equity fetches is [significantly] higher than their original investment.

What’s important to understand in this scenario is this capital is not free money for the corporation. Equity shares are a way to determine allocation of cash flows associated with that company’s business operations. Each time a company takes in money from an investor, they are swapping present capital for future cash flows. These claims on future cash flows are represented by stock ownership, and scale linearly with the growth of that company’s business. If the company’s profits grow 10x over the course of a few years, obligations to shareholders (in commitments of USD) have subsequently expanded 10x as well.

By treating the 80B XRP as a gift, Ripple accrues additional assets on its balance sheet without having to subsequently dilute equity. Ripple has accrued the monetary benefits of the XRP token while simultaneously pushing fiduciary obligations onto another party. This party is a decentralized piece of software that can’t be regulated by a governing body. Considering that Ripple owns 60.85B XRP, this amounts to a staggering $51.71B of assets to finance current business projects. This means that at current market prices, capital accumulated from shareholders whom Ripple has fiduciary obligations amounts to a mere 18 basis points. The remaining 99.82% of the company’s assets were essentially granted for free.

Critics argue that the company plays both sides of the line, crossing over whenever it is advantageous to do so. Ripple maintains that XRP is not a security and the network operates outside the jurisdiction of the company. But opponents feel like Ripple seriously blurs the lines when marketing X-series products and their correlation to the XRP token. They feel the company not only fails to educate XRP investors that token ownership does not mean a slice of the pie from X-series business operations, but that the company actually goes out of their way to imply a false narrative. Company press releases consistently highlight XRP liquidity volumes, proceeds from sale of treasury XRP, and overall price appreciation of the XRP token. Few details are given whether these volumes are a result of retail adoption through exchanges compared to enterprise use cases, revenues streams accumulated through core X-series products, and deal transparency surrounding new enterprise clients/liquidity providers.

The Ripple business model has taken a unique approach by bootstrapping XRP speculators to their business operations. The company is front running capital, most of which is accumulated through retail markets, in order to build out a network that can match the daunting liquidity and network effects necessary to facilitate global payments at an enterprise level. XRP investors are happy to put down money, believing the company has well positioned itself to build out this infrastructure, first through onboarding customers to xCurrent products then transitioning them over to xRapid layers once they recognize the improved cost savings, security and settlement times. In doing so, institutions will be incentivized to hoard XRP reserves on their balance sheets, since they will be conducting business on them so frequently. If this occurs, a huge rebalancing of capital will transition away from fiat currencies into XRP, causing the price to greatly appreciate in value given the scarcity model of the token.

Other proponents have an alternative narrative for a bullish unfolding. They see XRP as the chosen one engineered to match the current state of regulatory affairs. The cypherpunk dream of a fully decentralized monetary system is simply too radical for politicians and positioned incumbents to ever allow through the gate, regardless of how efficient their new technology proves to be. A more centralized blockchain that assists, not challenges, current status-quo while simultaneously increasing transparency and control for statist intervention seems much more realistic. If Ripple does meet this standard, any bank that voluntarily revokes a huge chunk of its revenue models however are going to demand an arm and a leg in reverse compensation. Fortunately, due to the XRP pre-mine model and Ripple’s gift allocation, they can construct incentives packages and re-distribute these tokens to potential partners on a subjective basis. If the company can attract even a small network of big players, the smaller ones will quickly follow.

Critics point back to some major flaws and/or assumptions that exist under these hypotheses. For xRapid to gain even minor support, a mountain of liquidity must exist for these banks to pull from. Ripple has chosen to facilitate this by marketing XRP through exchanges at the retail sector. However, this allocates tokens into the hands of many uneducated speculators who often trade off emotional impulse or trend analysis. Without XRP being tied to Ripple Company’s cash producing assets, an intrinsic value is impossible to derive, leading to further volatility. This creates a liquidity trap where the sheer price fluctuations make it impossible for any rational institution to hold XRP on their balance sheets. Imagine a bank executive trying to explain to a board of shareholders how company assets dropped 75% in the past quarter due to a pullback in the crypto markets. Far more likely is a system of designated liquidity providers acting as ramps where institutions source XRP and transmit payments in real time. Recipient parties then immediately sell back that XRP for fiat to correspondent liquidity providers. The problem with this scenario is XRPs near-instantaneous settlement speed leads to a system of exponentially increasing velocity. One would expect the price of a token to increase linearly with usage of the network. However, assets with unbounded velocity will struggle to maintain long-term price appreciation unless a hoarding incentive/ burn mechanism exists.Opponents believe the system lacks such features, making current XRP prices are hard to justify, considering 60% of the inflation supply has yet to be injected into the ecosystem.

Furthermore, this does nothing to address the volatility dilemma, it merely transfers the risk onto the liquidity providers. If banks aren’t willing to subject themselves to volatility, why would we consider anything different for liquidity providers?

This is where Ripple’s war chest comes into play. The company can offer compelling incentive packages and loans to providers willing to facilitate liquidity channels the business depends so heavily upon. Like most banks, the liquidity providers won’t purchase unless they can derive a high conviction of profitability in doing so. This means Ripple will have to heavily subsidize the XRP sold to these partners to ensure safety on their investment. If Ripple sets a precedent of mouthwatering deals for small players, these incentives will need to scale linearly as they approach bigger targets. The problem with these subsidies is that they require a continual influx of retail money to offset the costs of accruing new enterprise clients, until the flood of capital runs out. Paradoxically, this could lead to a situation where retail investors, many of whom are looking to disrupt the incumbent financial institutions, voluntarily contribute money to a project that hands over free money to the same financial institutions originally thought to be displaced.

Conclusion

Ripple Corporation exhibits many promising products that will undoubtedly penetrate the global payments ecosystem for future years to come. The company has positioned itself as a leader in blockchain sphere by taking a unique approach, working with and improving legacy institutions rather than trying to displace them. Some proponents believe that the system’s native token XRP will appreciate in value by becoming a dominant global reserve currency, due to superior advantages in efficiencies and cost savings it will provide to customers. Critics argue such hypotheses involve many radical assumptions which are unlikely to align, given economic factors and institutional game theory.

Disclaimer: The author does not hold a position, long or short, in XRP.

Follow me on twitter for more Crypto insight!

Special thanks to Derek Hsue and Pietro Moran for feedback on this piece.

Abstract

Monero (XMR) is a distributed ledger project touted as one of the world’s leading privacy-centric coins. The Monero project has carved out a deep niche in its respective community by placing heavy emphasis around being private, electronic cash. While the system itself utilizes the same UTXO structure as Bitcoin, it’s design shifts in the way these UTXO’s are packaged and broadcast to the network, utilizing one-time ring signature architecture, effectively creating an unlinkable transaction where an on looking third party cannot identify the output. The Monero protocol also utilizes a concept called stealth addressing, in which senders initiate transactions by producing a one-time public key visible only to the recipient. The recipient alone possesses the ability to recover the corresponding private part of the key to redeem the funds. By protecting both the sender’s and recipient’s transactional information, Monero possess many inherent strengths compared to the Bitcoin protocol and other leading digital currency systems due to its strong fungibility properties.

Problem/Solution

Public perception of Bitcoin as an anonymous payment scheme could not be further from the truth. By its very structure, Bitcoin is arguably the most translucent financial system civilization has ever seen. These features come with a set of tradeoffs, as Bitcoin’s extreme transparency is a double-edged sword. Many in the community are worried that it could eventually come at the demise of fungibility. As blockchain analytic programs become more adept, the lineage of transactions will become increasingly visible. If certain bitcoins in the ecosystem become labeled as “tainted” due to association with nefarious transactions somewhere in their lineage, merchants, vendors and exchanges will refuse to accept them due to legal recourse that could potentially ensue. This could lead to a market scenario where mispricing exists between equal denominations of the currency. If equal denominations of bitcoin do not possess equal intrinsic value, the system is no longer fungible.

The transparency of the Bitcoin blockchain makes it possible for an outside third party to conduct a full audit on any account and view the transactional history linked to that address. For corporations and organizations that rely heavily on financial privacy in their business dealings, this is not feasible. If the system loses fungibility, heavy indirect costs are placed upon both users and merchants. Unsuspecting individuals who receive a “tainted” coin are left bag holding a worthless currency that processors will refuse to accept. Merchants and exchanges incur high infrastructure costs to pre-audit incoming transactions. This not only incurs monetary fees but slows down the point-of-sale, reducing customer experience. Monero seeks to alleviate these concerns by making transparency an optional off-chain feature for transacting parties.

History

Monero traces its lineage back to the publication of the CryptoNote whitepaper. The CryptoNote v1 document claimed to be uploaded to a Tor Hidden Server in late December of 2012, published by a pseudonymous author under the name Nicolas van Saberhagen. The document was followed by a v2 release months later. However, it wasn’t until 2014 that these papers were “discovered” and emerged into the public spotlight, initiating controversy as to whether the authors lied about the publication timeline. Increased scrutiny developed after an investigation showed conflicting publication dates embedded in the PDF metadata. Around this same time, Bytecoin, the first implementation utilizing the CryptoNote protocols, was publicized. Like the CryptoNote authors, the Bytecoin developers remained pseudonymous, and little background regarding the historical origins of the currency existed. The Bytecoin team claimed the protocol had been live for nearly 2 years and had been adopted by numerous individuals across the deep web, yet no evidence of these claims could be supported. Many believed that the pseudonymous developers of the currency had some correlation to the CryptoNote developers, igniting controversy. Bitcoin talk user Thankful_For_Today forked the network roughly one month later, dubbing the new system Bitmonero, after discovering a secret pre-mine in the Bytecoin protocol where nearly 80% of the funds had already been distributed. Continued political and governance turmoil within the BitMonero ecosystem materialized with a tertiary fork only one week after, out of which the Monero protocol was born.

Characteristics

Block Construction:

Monero utilizes the standard UTXO model pioneered by Bitcoin, not a state-account configuration exhibited by alternative currencies such as Ethereum. Like Bitcoin, UTXOs exist in the blockchain and are encumbranced to a designated address when a user spends them. Transactions are bundled into blocks, but generation of Monero blocks is radically different than the traditional model implemented by Bitcoin. In contrast to Bitcoin’s 1MB hardcoded limit, Monero has an extremely dynamic structure with regards to its block ceiling, as well as the coinbase emissions allocated to the winning miner. Maximum block sizes can exist up to 2x the median block of the last n blocks (currently 100). The protocol also maintains a minimum block size configuration of 300 kB. This means miners can construct blocks up to 300 kB without infraction. If they choose to build a block above these parameters, a penalty is levied.

Penalty = BaseReward * ((BlockSize / MN) — 1)²

Where:

● MN is the median of the block size over the last N blocks (currently 100)

● BlockSize is the size of the current candidate block

● BaseReward is the current reward as per the emission curve, derived as follows:

BaseReward = 2 * ((S — A) * 2–20 * 10–12)

Where:

● S is the initial number of atomic units ( 264–1)

● A is the current circulation, converted to atomic units, which can be found here.

From an economic perspective, if the marginal benefit of adding an additional transaction to a fully diluted 300kb block does not outweigh the marginal cost, miners would simply refuse to add subsequent transactions. This could lead to significant congestion inside the mempool and a backlog in confirmation times during periods of high on-chain volume. Taking such variables into consideration, a default fee of 0.013XMR was configured to incentivize miners to include additional transactions in the event blocks were to become full. Envision the following theoretical situation:

Where:

● Average Transaction Size = 13.2kB

● Current BaseReward of 5.7 XMR

● Default Fee of 0.013XMR

● Penalty = 5.7 * ((313.2/300)-1)² = ~0.011 XMR.

Since marginal benefit (0.013XMR miner’s fee) > marginal cost (0.011XMR block penalty) the miner would choose to include the transaction in the block.

In summary, the minimum limit, TX penalty and default fee work in tandem to ensure honest block size increases. The system disincentivizes a nefarious miner from DDOS’ing the network by initiating a flood of spam transactions while simultaneously mining them into an excessively large block.

Emission:

Like Bitcoin, Monero follows a diminishing supply curve in which block rewards decay over time.

A key component that lies in stark contrast to many other cryptocurrency projects is Monero’s unbounded inflation. Once 18.132 Million XMR have been mined, a continuous “tail emission” will output 0.6XMR every two minutes (the average interval of a block solution). Monero believes an indefinite inflation schedule is necessary to provide an incentive for miners to contribute hash power, thereby securing the network.

Proof of Work Algorithm:

Monero utilizes the egalitarian CryptoNight hash function, a proof-of-work based, memory-hard consensus system in which the marginal benefit derived from specialized circuits (GPUs, FPGAs or ASICs) does not outweigh the marginal costs of integrating such hardware. Thus, Monero mining tends to be performed via traditional CPUs. The hash function works by filling a segment of cache with random data corresponding to memory addresses, then subsequently hashing the resulting block after reading and writing to those addresses. This differs from traditional SHA-256 mining in Bitcoin where the accessible data can be stored in L1 cache, and thus be accessed far quicker not having to fetch addresses from RAM or video RAM. Spreading the data across multiple secondary layer caches prevents specialized systems from obtaining a definitive advantage over traditional processors and is more analogous to the one-CPU-one-vote vision described by Satoshi Nakamoto in the Bitcoin whitepaper. Allowing anyone with a simple computer an equiprobable chance at discovering a block means hash rate consolidation is far less likely to become a detrimental threat. This keeps the protocol hedged from centralization and other attack vectors.

Additionally, high levels of centralization induce opportunity for government manipulation at the macro level. Legal patents and economies of scale could potentially lead to situations where only a handful of hardware manufacturers exist. This opens the door to censorship, where governments could shut down the companies’ production facilities, demand hidden backdoors, require licensing to operate or purchase hardware, censor transactions, or initiate temporary sales bans/quotas to distort hash rate equilibrium and damage the network. The Monero Core Team maintains a fierce standpoint that the protocol remains ASIC resistant, vocalizing their intention to curb any potential threats to egalitarian mining. This includes alterations to the Proof-of-Work schematic during scheduled network upgrades as a response mechanism to emergent ASIC hardware.

Stealth Addresses:

Monero utilizes stealth addresses to protect recipient privacy, a feature outlined in the CryptoNote whitepaper. Much like a hierarchical deterministic wallet, stealth addresses allow unique one-time destination addresses for outputs, preventing address reuse and thereby diminishing privacy. Unlike HD wallets though, stealth addresses push the burden of address creation on the sender. This allows the recipient to publish a single address and receive unconditional, anonymous payments to it.

Stealth addresses work slightly different than traditional Bitcoin addresses but are merged from the same underlying elliptical curve principles. Rather than generating a single EC keypair, the recipient will generate dual-EC keypairs in order to create a one-time key to receive payments. Let’s envision a theoretical scenario where Alice pays Bob. Bob begins by generating a dual public-private keypair {(a,A) where A=aG and (b,B) where B=bG)}. Bob concatenates (A,B) into a human friendly, error encoded format to create a standard address, which he publishes to the network. Alice unpacks Bob’s standard address to obtain his public keys (A,B). She then generates a random secret, r, and constructs a one-time public key by multiplying r and A. Alice then takes that value, multiplies it by a generator point G, and finally adds the value to B. She then hashes the result, which we call P.

P= [Hs (rA)]G + B

Alice then takes P and uses it as the destination for her UTXO. She computes the hash’s value R, where R=rG. She packs that R value into her message and broadcasts the transaction.

Subsequently, Bob’s wallet software is checking every transaction passing through the network with his private keys, and can recognize transactions destined to his address via mathematical computation done using (a,b). Once Bob recognizes an output encumbrance to him, he can recover the corresponding one-time private key and spend the funds at any point in the future by signing with x (the private key for above P).

Because knowledge of r is a necessary component in recovery of the one-time private key, Alice can provide verifiable proof she sent the payment either by publishing r, or using a zero-knowledge proof that she knows r.

Ring Signatures:

Sending Monero requires the user to spend some value of XMR associated with a one-time public key, P, as we discussed in the previous section. The sender must provide verifiable proof of ownership by signing a message spending that P with its corresponding private key, x. Up until this point, no one knows that Bob has received a payment from Alice (other than Alice of course). However, holding the funds indefinitely does not provide much utility to Bob. He also needs a way to spend these funds, without leaving a trail back to himself.

To maintain greater anonymity, Monero adopted one-time ring signature technology, proposed in the CryptoNote whitepaper. Ring signatures allot privacy by allowing the sender to join a group, then sign a transaction as a unit, rather than from a single private key. This technique allows the sender an avenue to “blend in” with the crowd. Verifying parties can prove that the output exists and that one of the parties in the group is an authentic signer. However, they cannot determine which of the group members that signer is, as each member holds an equiprobable weight. As the group size increases, the probability of each member being the authentic signer decreases.

A ring signature involves aggregating the user’s authentic P, along with a plethora of “dummy” P’s scattered across the blockchain. The signature is verified by all the Ps, and mathematically any of the corresponding private keys could have signed the transaction, thus obfuscating identity of the authentic sender.

To prevent double-spend attacks, a key image I is created during the construction of a ring. The image is created by taking a hash of P, and multiplying it by the private key x. The mathematical relationship makes it impossible for the signer to try and make two signatures with different I’s and the same x. This mechanism ensures that each P can only be spent once, new XMR cannot be created out of thin air. The Monero network maintains a database of all outstanding key images, so if a user tries to reuse a key, the network will see the output as expended, and reject the transaction.

Ring CT:

With the combination of stealth addresses and ring signatures, both sender and recipient privacy are protected. However, the CryptoNote whitepaper has no implementation that effectively shields the value transfer amounts. If Alice pays Bob 5XMR, and Bob subsequently pays Bruce, Alice could piecemeal segments of the transaction chain by following the commitment values.

Ring Confidential Transactions (Ring CT) is a measure implemented by the Monero protocol which makes transaction values opaque to anyone outside the sending and recipient parties. The protocol accomplishes this by having the sender encrypt the values using a shared secret between the transacting parties. The recipient is then able to decrypt the value using a combination of their private view key, along with the transaction public key.

Third parties are still able to verify the integrity of the values and ensure that new XMR weren’t created out of thin air, without even needing to see the value amounts. This is achieved through cryptographical schemes called Pedersen commitments.

Commitment Inputs — (Transaction Fees + Commitment Outputs) = 0

A simple illustration can provide a basic overview of the mathematical properties involved:

1+2+3+4 = 5+5

If we want the values to remain confidential, we encrypt them, multiplying each by some generator point x, getting:

1x + 2x +3x +4x = 5x + 5x

=

x(1+2+3+4) = x(5+5)

Without knowing x, verifiers get obfuscated values, but can ensure the input commitments match the outputs (plus transaction fees). The only ones who can see the actual values are the recipient and sender, who know x.

Additionally, Ring CT requires the implementation of range proofs. Almost like a zero-knowledge proof, range proofs ensure that the commitment values fall within a parameter range (greater than 0), without ever exposing the integers themselves. This is necessary to prevent someone starting with 1XMR from creating two separate outputs of -5XMR and 6XMR, thereby creating XMR out of thin air.

Forward Implementations

Kovri:

Kovri is a C++ implementation project that would make Monero compatible with the Invisible Internet Project (I2P). Much like The Tor Project, I2P is a network layer that provides users privacy and anonymity when browsing the web. The architecture consists of nodes that pass end-to-end encrypted data throughout the network, all performed on a volunteer basis. I2P has a fundamentally different composition than Tor, providing different objectives. Tor’s uses circuit-based routing to enable private access to the public internet. It does this by breaking the link from where the request originated, and where it was ultimately delivered. Tor also features hidden services, servers that hold content which can only be accessed within the Tor network itself, and not via the public internet. However, this is more of an auxiliary service.

Simplistically, I2P looks to build a network completely independent from the traditional web where the majority of traffic stays within its borders (think of a network composed purely of Tor hidden services). Unlike Tor, which uses a circuit-based routing standard, I2P uses packet-based routing, analogous to the TCP/IP protocol. This provides higher degrees of reliability due to the protocol’s ability to route around congestion and network disruption.

Currently, one of the few pieces of software that facilitate interaction with these I2P network layers (referred to as a router) is written in Java. This current I2P daemon is quite incompatible with Monero, due to its bloat and difficult integration. Kovri is an alternative implementation written in C++, making it more complementary with Monero’s code. Kovri is a full I2P router, meaning it can be used for other applications than just Monero. This will help increase the strength and utility of the I2P network overall.

Embedding native access to the I2P network within Monero is a positive development with regards to privacy, since it will hide the user’s IP address. The Monero blockchain itself does not store IP addresses in blocks, but because synching a full node consumes a lot of storage, bandwidth and time, many choose to bootstrap their client to a remote node (a node controlled by someone other than yourself) to synch the blockchain. The owner of that remote node may be logging IP addresses of users and could see which TXIDs originated from specific users. Luckily, the operator cannot see what inputs in the ring signature are real and which are decoys, the amount sent, or what address these outputs are encumbranced to. However, if the node operator is nefarious, permanently sniffing your connection, or runs a massive number of nodes, they could potentially accumulate a great deal of information about user transactions and piecemeal information together. By obfuscating user IP addresses over I2P, Kovri highly mitigates the possibility of such attacks.

Bulletproofs:

As we mentioned previously, Monero uses range proofs to ensure that commitment outputs are positive integers, without revealing the underlying value of the outputs themselves. This method prevents users from creating new XMR out of thin air. However, these range proofs come at a cost to efficiency. Range proofs scale linearly with respect to the number of outputs in a transaction, meaning multiple-output transactions must contain a corresponding amount of proofs. Range proofs make up a significant majority of the transaction size and are the precise reason why XMR transactions are so much larger, and thereby costlier, than their crypto-counterparts.

Fortunately, a recent breakthrough called bulletproofs has found a way to significantly decrease the size of these range proofs. With bulletproofs, outputs scale logarithmically rather than linearly:

Current Range Proofs: 1 output = 7kB, 2 outputs = 13kB…

Bulletproofs: 1 output = 2kB, 2 outputs = 2.5kB…

A standard XMR transaction involves 2 outputs, one destined to the recipient, the other back to the sender in the form of change. Using current range proofs, this amounts to roughly a 13.2kB transaction. Using single-output bulletproofs, the size of the transaction is reduced to 2.5kB, a cost reduction of nearly 80%. The implementation of multiple-output bulletproofs will induce even higher savings.

The development team anticipates bulletproof deployment in a single stage during the upcoming September hard fork. Reduction to transaction size will lead to congruent savings in transaction fees, and on verification times as well. Overall, bulletproofs will have a robust impact on the efficiency and functionality of the Monero network.

Scheduled Hard Forks:

Hard forks in a distributed ledger system tend to be contentious. Conflict usually emerges between two or more factions within a community, growing to the point where one splits off and creates a completely independent protocol. However, not all forks have to be bad. Sometimes hard forks occur when a network implementation needs to be pushed, but no backwards-compatible coordination is possible.

Monero schedules predetermined hard forks every six months as pitstops to implement new technology or advance existing architecture. These forks are historically uncontentious and are more analogous to scheduled upgrades. Examples of notable technology implemented during these forks included Ring CT, multisig, and soon-to-be-released bulletproofs.

Scheduled upgrades to the Monero protocol have been highly successful, partly due to the infancy of the system. The community is a small grassroots organization that is very close knit. Consensus seems to be reached with very little disagreement, partly due to the alignment of incentives and complementary vision among group members. As the community continues to grow and adoption becomes more wide-spread, consensus may become problematic as fragmentation occurs.

Challenges

Scaling:

There is one definitive factor that has emerged in the crypto-ecosystem since the release of the Bitcoin whitepaper in 2008: Blockchains do not scale well. Monero is no exception to this principle.

Like every other protocol system, tradeoffs of certain characteristics must be relinquished to obtain alternatives. As a privacy centric coin, Monero puts transactional anonymity at the top of the list. Doing so comes at a great cost to transactional efficiency. Monero transactions sizes are some of the largest in all the crypto-ecosystem. At current levels, a two-output transaction (one output to recipient, one output as change back to sender) is roughly 30x the size of an average Bitcoin transaction. While new algorithms such as bulletproofs are anticipated to significantly increase savings, these efficiencies may be offset with privacy improvements (ie: increasing standard ring sizes to 100+ members). XMR has some of the most expensive network fees, despite transactional volume only amounting to 3,000–5,000 TX per day. If adoption continues to increase, this could pose serious challenges.

Many of the XMR Core Team members have illustrated the need for off chain scaling to become a viable P2P cash system. However due to the infancy stages of the protocol, most of the work is being done to improve efficiencies on-chain. Very few efforts have been allocated to sidechain/lightening payment channels, showing that the currency still has a way to go before reaching a dynamic threshold.

Governance:

Decentralized systems have garnered attraction over the past decade due to the individual sovereignty natively imbedded into their protocols. Voluntarism and immutability are core principles that make these systems so powerful. However, they often come at a tradeoff to consensus and innovation.

Monero lacks any hard governance structure or hierarchical leadership. The “highest” degree of power lies in the hands of the Core Development Team. Responsibilities that fall under their jurisdiction include the following:

● Act as primary trusted arbiters of the Forum Funding System on behalf of the community, so as to ensure the completion of all projects to the satisfaction of the community.

● Manage the codebase of the Monero Project, which includes merging code on Github, keeping backups, and ensuring the safety, security, and free access of the code from any party.

● Steward the general donation fund and spending the Monero there on anything they see fit to further the Monero Project.

● Act as trusted signers and distributors of reference clients for the Monero coin, and other related technologies.

● Set a direction and vision for the Monero Project

The development team simultaneously outlines principles that they are not obligated towards:

● Members of the Core Team are NOT anyone’s boss, and no permission is needed from them to do anything.

● The Core Team does NOT act as a centralized point of failure, but encourages organic, self-started initiatives that further the ecosystem of Monero.

● The Core Team does NOT equal Monero. In the event that one, or all of the Core Team goes rogue, we are to remember that Monero is a movement. A global initiative to further privacy globally, and provide real, fungible, digital money for everyone. This can happen even without the presence of the Core Team.

Merging coordinated action and individual sovereignty is no easy process. Attracting strong talent and producing innovative technology has not been the challenge for distributed systems over the years. Finding a way to reach simultaneous consensus on how to implement features has been. Different outlooks and visions for the protocol may result in factions within the community, like we’ve seen happen in Bitcoin. With no intrinsic hierarchy in the governance system to make difficult decisions, progress and innovation could potentially slow due to internal conflict.

Early signs of fragmentation have begun to emerge, catalyzed by the recent (and somewhat controversial) network hard-fork that went into effect April 6th. The fork has two primary components: increase the minimum ring size to 7 signatures, and alter the underlying CryptoNight hash function. The latter was a decision initiated by the Core Team in direct response to the release of the Antminer X3 ASIC rigs. Some community members feel that the move lacks definitive consensus, and paradoxically illustrates centralization concerns, as a small group of developers have the ability to radically transform the structure of the network at whim. However, the decision should come as no surprise and comes in conjunction with the majority of community agreement. The Core Team has consistently iterated egalitarian mining as a fundamental pillar to the protocol, and has outlined a fervent vision to preserve such features. Some members disagree that the team has the ability to outline such a direction, due to the complex economic/political implications of the decisions. Proponents are already launching a forked coin, Monero Classic, which removes the consensus algorithm alteration. The biggest takeaway we can generate from this event is that Monero’s fervent claims to remain ASIC resistant are extremely sincere. They are not afraid to wage war against hardware manufacturers, so expect a cat-and-mouse game of protocol alterations as each side counters.

Capital Financing:

Monero utilizes a unique crowdfunding approach called the Forum Funding System to finance projects. The entire system operates on a donation and is purely meritocratic based. Ideas are introduced across an idea thread, with developers proposing outlined solutions to achieve these objectives. If deemed relevant and obtains community approval, that person/campaign will receive capital pledges from community members to pursue their project. These funds are locked in escrow, and milestone requirements must be hit to receive payout. This safeguard mechanism aligns incentives for both the donors and recipients and ensures protection of the funds from theft or mismanagement.

Funding open-sourced applications has been historically challenging. Many in the Monero community have expressed discontent toward the outrageous sums of capital crowdsourced by alternative protocols in the form of ICO’s and token sales. Similar distrust for distributed currency systems that allocate a percentage of block rewards to the foundational team have been noted. By utilizing the FFS structure, the Monero community wants to foster an ecosystem of character and stewardship that properly aligned incentives across the community.

Relying on a system of donations fundamentally relies on the generosity of the community. Right now, the FFS has been very effective not just raising capital but allocating that capital to projects that have produced highly beneficial content. The grassroots environment fostered in the Monero network is very strong, and donations have been quite prevalent. However, as the community grows, factions could be introduced that split and divide the community, creating problems for consensus. This could detract from the community ethos and impact the generosity of its members in a negative way. Furthermore, at a certain scale, the FFS could suffer from the tragedy of the commons, where common users freeride off the minority development efforts of a few individuals. Average users have little incentive to donate since no tangible efforts of their donations come to fruition in a climatic manner. This free-rider problem could ultimately manifest with the concentrated developers becoming overburdened and upset, walking away from the project altogether.

Privacy:

While Monero provides a degree of anonymity much higher than most cryptocurrencies, no system is perfect. Some attack vectors still exist. Below are examples of notable concerns:

EAE Attack- This involves a transmission of funds from an exchange to Alice, then back to the exchange at a later interval. The exchange, which stores various KYC/AML information, would possess knowledge of Alice’s one-time ring signature. If any ring signatures appear referencing the UTXO Alice received from the exchange, then the exchange will know Alice is one of the possible spenders.

Key Image Reuse- This form of attack is likely to materialize from a fork in the network where private keys from the legacy chain are reused on the new chain (let’s call this network MoneroB). The same key image for rings now exists simultaneously on both forks.

Alice sends XMR to a new legacy wallet, using decoy inputs 1,2,3,4,5 and her authentic input 6. Similarly, she sends money to a new address on MoneroB, constructing a ring with authentic input 6 and decoy inputs 7,8,9,10,11. A third party can analyze the two chains and come to a conclusion that input 6 is the authentic commitment since it exists in both rings. A major problem in this scenario is that Alice’s input 6 is being used as a decoy for a ring constructed by someone else (call him Bob). Bob’s ring consists of decoys 6,12,13,14,15 with authentic input 16. The third party onlooker can now conclude that 6 is a decoy (since they already figured out that it belongs to Alice), reducing the ambiguity factor of the ring by one. By aggregating enough information, the onlooker can fill in many pieces of the puzzle, greatly reducing the security of the ring by removing plausibility of the authentic signer.

This scenario is near impossible to defend against, as any individual possesses the ability to fork the network at any time. If the fork is designed as an attack vector to undermine the legacy chain’s security, the attacker has economic incentives at their advantage. Uneducated users or users who value privacy in little regard are likely to claim their “free money” airdrops on the new chain. Even worse, if the attacker is a deep pocketed organization like a government or large corporation, they could purchase large buy orders on exchanges, artificially increasing price of the asset short term. This would entice users even further to claim their airdrops, compromising integrity of the main chain in the process.

The problem with this situation is tradeoffs are not restricted to the individual user, but rather amortized across the network as a whole. Users who refuse to claim their airdropped coins in an effort to maintain chain integrity are still subject to the negative externalities of those that do. This could potentially lead to an entirely new Byzantine fault problem the network would need to account for.

Ring Sizes- Tying in closely to the above scenarios, low ring sizes increase the probability of an onlooker determining the authentic input inside a ring. Fees scale in response to larger rings, so an underlying incentive exists for users to deploy smaller rings, especially those with “nothing to hide”. In scenarios where an attacker can probabilistically eliminate some decoys, smaller rings only make their job easier.

Competitors

A compelling argument can be made that over the long run, cryptocurrency systems will exhibit network effects that lie in tandem with Metcalfe’s law, leading to a winner-take-most end scenario. This is thought to be especially true for privacy-centric coins, due to the necessary properties of high liquidity and large user bases to prove functional. Even if the protocol possess strong cryptographic shielding properties, if the network maintain few participants and offers low liquidity, salient points of attack will manifest at the off-chain level (e.g. an exchange endpoint), thereby eroding user privacy. Thus for a privacy-centric network to become truly secure, it must become a de-facto protocol inside its niche. This is most likely to be accomplished through a combination of two elements: early mover advantage and strong utility.

At such a transition point, the network accrues monopolistic advantages over competition. Given that the asset is scarce, an increase in demand combined with [near] fixed supply will lead to a rise in the asset price. This will incentivize miners to migrate to the network due to heightened block rewards, increasing hash rate and contributing to the underlying network security. As the community expands, competent developers will crossover, leading to a more resilient and secure code base. These positive reinforcement mechanisms lead to an economic moat over competition, where small players have an increasingly complex time dethroning the incumbents. Also, currency networks tend to exhibit “sticky” properties due to high transition costs. Networks have the ability to fork, so incumbents can simply steal their competitor’s technology once it has proven to be resilient, leaving little incentive for users to migrate. Implementing new technology to the protocol is easy, generating an initial framework of users is difficult.

At current standards, Monero really only faces significant competition from a single alternative coin: Zcash. Like Monero, Zcash has built a value proposition based off strong degrees of privacy and fungibility. While both protocols seek to achieve the same objectives, each uses novel forms of cryptography to accomplish their aims. Monero deploys encryption schemes which protect sensitive data that exists inside the metadata of a transaction. If this data were to be decrypted, it would leak critical information that would compromise the user’s privacy. Conversely, Zcash routes around the dilemma by removing it from transaction data altogether. Zcash accomplishes this via a novel form of zero-knowledge proofs known as zkSNARKs. ZkSNARKs allow the sender to mathematically prove ownership of the asset without conveying any information in the transaction apart from the fact that they possess knowledge of the sensitive data.

Distinctions between Monero and Zcash appear in many different aspects. The most glaring has to do with cryptography schemes. Theoretically, zkSNARKs can offer higher degrees of security than Monero’s encryption based transactions. However, this does not necessarily mean their protocol is more secure, as attack vectors exist in multiple departments. Zcash offers the ability to initiate a shielded or transparent transaction. Less than 1/3 of transactions are shielded, partially due to the disincentives as they incur higher fees and longer propagation times. Low adoption rates open potential doors for analytical snooping on transactions as they pass in and out of different addresses. This revokes user sovereignty, as security becomes reliant on other users actions to a certain degree. In Monero, privacy is a mandated feature, preventing such drawbacks.

Governance is another stark contrast. Monero exhibits a highly distributed, grassroots-style organizational structure. No hierarchical leadership exists, and alterations to the protocols occur on a fairly consensual basis. Protocol development and research is aggregated across a wide set of contributors. Zcash displays a much more centralized governance structure where power is severely concentrated (at least for the time being). The Zcash Company consists of a highly accredited team of scientists, researchers and developers who drive technological advancements and innovations to the underlying Zcash protocol. Community members then have the ability to opt into these network alterations on their own accord.

Tradeoffs that exist between the two coins can be vaguely summarized by differences involving technological innovation and community governance. Monero offers higher on-chain privacy features in the short run due to its default anonymity settings, larger user base and tried encryption. In the long run, Zcash signals compelling evidence to offer better privacy due to zkSNARKS, increasing shielded transaction adoption rates, and qualified engineering talent. However, Zcash allocates less autonomy to its user base, stemming from its effective monopoly over protocol alterations, combined with its Founders Reward tax on 10% of mined coins. Each protocol provides a unique value proposition that attracts users with different objectives.

Conclusion

With relay, sender, recipient and transactional information all privatized, the level of anonymity provided by the Monero protocol is exceptionally high, positioning it as one of the world’s leading privacy coins. Innovation by Monero Research Labs into Ring CT, KOVRI, and Bulletproofs has illustrated the organization’s competent developers and strong dedication to community necessary for any project to succeed. While researchers argue that novel cryptography in competing systems such as Zcash may overshadow key Monero protocols in the long run, tradeoffs always exist. Raw cryptography is not the standalone decisive factor. Governance, adoption rates, incentives, and capital must all align to create a sustainable ecosystem. Taking into consideration all the different dynamics in the ecosystem at the present, I believe the Monero project has positioned itself as the frontrunner coin in the battle for privacy.

Disclaimer: The author holds a long position in XMR

Special thanks to Justin Ehrenhofer, Pietro Moran, Myles Snider and Derek Hsue for feedback on this piece!