Monday, June 4, 2018

Forking for ASIC Resistance: A Monero Case Study

This research has been sponsored by LBRY, a free, open, and community-run digital marketplace.

Designing ASIC resistant proof-of-work blockchains, and particularly hard-forking to achieve such ASIC-resistance is a contentious new issue in the cryptocurrency space. ASIC chips are custom manufactured computing devices designed specifically for a particular blockchain or hashing algorithm. As such, they are far more efficient at mining than commodity hardware such as CPUs or GPUs.

Forking to prevent such resistance, referred to as an AAHF (Anti-ASIC Hard Fork) for the rest of this article, changes the mining algorithm on a blockchain so that ASICs tailored to the old algorithm can no longer mine effectively. AAHF aren’t just theory. Recently Monero executed one and Zcash is pondering whether to do the same. At LBRY, we’ve received requests to hard fork due to the release of a Baikal miner appearing on the market (the miner is likely a FPGA machine, not an ASIC, however).

This article is a case study on the recent Monero AAHF. The Monero hard fork that occurred on April 6th was interesting in that it:

A) Set the Monero dev/community against the much maligned ASIC manufacturer Bitmain
B) Resulted in the chain splintering into various alternative projects that took over the old pre-fork chain (you can read about this here)

The goals of this article is to look at verifiable data instead of speculating about the nature of the fork, and to see what kind of lessons we can learn from it.

Effects on Hashrate

First let’s look at Monero’s hash rate before and after the hard fork. In the below graph, you can see the hashrate for Monero in green. The black line is the hashrate for the the various alt-coin splinter projects that took over Monero’s old chain after the hard fork (from henceforth called Monero Original)*.

*Note that according to GPU miners that I’ve talked to, the pre-fork and post-fork Monero POW algorithm is equivalent in computational difficulty thus the hash rate before and after the fork should be comparable.

Green: Monero hash rate, Black: Monero Original hash rate

One possible interpretation of this graph is that the total Bitmain ASIC hashrate is around 500 Megahash/sec. This matches up with the amount that seemed to drop off from Monero post-fork, and also matches up with the amount that remained on the Monero Original chain post-fork. However, we can’t say this with certainty that the above interpretation is correct since it is impossible to associate hashrate to a specific type of miner.

Regardless of what the total hashrate of Bitmain’s ASIC miners is, losing almost 50% of the hashrate post fork should be a concern for Monero. The recent 51% attack of Bitcoin Gold illustrates the very real connection that exists between hash rate and security.

ASIC Capabilities

The primary argument for an AAHF is that ASIC manufacturing results in more mining centralization by pushing out the commodity hardware miners. To verify this claim, we need to look at the capability of these ASIC miners and compare them to commodity hardware. Below are the respective specs for the Bitmain Monero miner and a top of the line AMD GPU miner:
  • Bitmain X3: 220 KH/s, 550 Watts, 0.4KH/s per Watt, Retail value: 1900$
  • AMD HD 7990: 1.1 KH/s, 110 Watts, 0.01 KH/s per Watt, Retail value: 900$
We see that the Bitmain miner is 220 times more powerful than a single top of the line AMD GPU unit. More importantly, it is 40 times more energy efficient at mining. It is clear that commodity GPUs are outclassed by these custom miners, but it’s also important to note that there are a whole lot of GPUs out there in the world. Consider that AMD shipped 19.6 million discrete GPUs in 2017 alone. AMD does not release sale numbers for specific models, but if we assume that all 19.6 million of the GPUs sold were of the cheap 400 series variety, this adds up to 7.84 GH/s (a 400 series runs about 0.4 KH/s on the Monero network). This is 15 times larger than the 0.5 GH/s that we estimated to be the Bitmain ASICs total hashrate and the current Monero hashrate.

The point of this calculation is to show that while AMD/NVIDIA may not produce profitable miners, the total hash rate they produce is immense. ASIC producers like Bitmain may be able to obtain monopolies on profitable mining, but they have not monopolized mining. If Bitmain tries to perform a 51% attack, the Monero community will likely be able to fight it off using commodity GPUs. If we assume that 0.5 GH/s is the correct estimate for the Bitmain ASICs total hash rate, this will require 1.25 million AMD 400 series GPUs. Assuming 150 watts of power consumption per unit and 12 cents per kilowatt-hour we get the energy costs to be 22,500$ per hour. The numbers will obviously be better if we use a higher end GPU.

Aftermath for Users

Software upgrades by nature are attack vectors. Some users will end up downloading a compromised version of the upgrade which may for example send all their coins to a hacker’s address. We can actually get download numbers for Monero 0 and Monero Original. They are two projects that took over the old chain after the Monero fork and released their binaries on GitHub (GitHub tracks download numbers through their API).

About 1000 users total have downloaded either Monero Original or Monero 0 binaries and have presumably used them. I’m not suggesting that these binaries are malware but they are unsigned binaries from anonymous developers. Needless to say, there are significant risks involved in running such software. It is worth considering whether it is worth exposing users to such attack vectors when hard forking.

Other users may not even be aware that the Monero network has hard forked and may be transacting on the old network unaware of what is happening. It is impossible to tell whether the transactions happening on the Monero Original chain are intentional or accidental but the below graph shows that there is still small amount of transactions occurring on the Monero Original chain (note that the Monero Original chain is traded on so the transactions below could all be intentional).

Green: number of transactions on Monero, Black: number of transactions on Monero Original


There are several causes for concern regarding Monero’s AAHF.

The first concern is that the AAHF may have been unnecessary in the first place because the Monero community underestimated the total amount of hash rate that can be produced through commodity hardware. If the community had concerns about Bitmain abusing their powers, they certainly could have fought back without resorting to a hard fork.

The second concern is that the AAHF created attack vectors that could be exploited against its users. The lowered hash rate can be used to 51% attack the chain, and the software update necessary for the hard fork may have left users on the wrong chain or exposed them to malware.

It remains to be seen how these concerns will work out for Monero in the future. So far, things has gone smoothly as the Monero price has been stable and there has been no noticeable network disruption for the user. The market for the most part has deemed this AAHF to be a success. However, this AAHF is likely just the opening battle in a war to determine who gets to control the Monero network. Bitmain, and other ASIC manufacturer, will not be undeterred if there is money to be made. The next time this battle is fought, these concerns are going to be revisited again.

Friday, March 2, 2018

Left/Right Political Ideologies of Hodlers: Part 1

I’ve been thinking a lot about left and right-wing politics, due to the extremely polarized nature of the current American/Western political landscape. Naturally, I started thinking about left and right-wing ideologies in the cryptocurrency space, and how increasingly relevant these ideologies have become in this space. In the early days of Bitcoin, arguments revolved purely around the technology and efficient solutions to tractable engineering problems. If there was any ideological arguments, they were mostly between Hodlers (people that believe in, or can at least see some value in cryptocurrencies) and Nocoiners (people who think that Bitcoin is stupid).

But these days, major conflicts in the crypto space can be described as intractable ideological conflicts. The block size debate is an example of this. The numerous skirmishes between altcoins vs Bitcoin, or altcoins vs altcoins is another example. In this article, I will describe how we can look at these ideological conflicts the same way we look at mainstream political conflicts. More specifically, I will describe how the concept of left-right political spectrum applies to people in the cryptocurrency space, which I will call “hodlers” for a lack of a better term.

Psychologists have done many studies to discover differences in the way conservatives and liberals think. One important finding from these studies is that the amount of fear, or the lack of it, is a critical component of whether a person is left or right-leaning. The presence of fear shifts people to the right side, while the lack of it shifts people to the left side. Studies have shown that conservatives (right-leaning people) are more responsive to physical threats and other negative stimuli, focus more on threatening imagery rather than pleasant imagery , and have a larger amygdala (a region of your brain that processes fear stimuli) than liberals. Academics have coined the phrase “negativity bias” as a way to describe the tendency of right-leaning people to be more fearful and more responsive to negative stimuli. Conversely, you could use the phrase “positivity bias” to describe the tendency of left-leaning people to be less fearful. The opposite of fear is hope so you could say that liberals are more hopeful, and conservatives are more fearful. Here are some further summary readings on the issue: 1 , 2.

The hypothesis that fear and hope are the driving emotions that separates people into the right and left seems to be very fitting if we look at ideological battles in the cryptocurrency space. Below, I present my definition of right-wing hodlers and left-wing hodlers.

The right-wing hodlers are driven by a fear of the worst case scenarios. Worst case scenarios in the crypto space will generally involve adversarial attacks against the blockchain by a nation state. It could also be related to personal loss/theft or unforeseen errors in the code that results in catastrophic consensus failure. Because their main instinct is fear of the worst case, the right-wing hodler’s focus is on security above everything else. For a right-winger, means to achieve security is derived from their strict adherence to cryptographic rules and stable Nash equilibrium solutions. In some sense, you could characterize them as Technocrats, an overly logical bureaucrat that is beholden to technology, instead of the government. A good fictional archetype might be the Vulcan race in Star Trek. Someone like Gregory Maxwell and Peter Todd would be a good example of a right-wing hodler.

The left-wing hodlers are driven by their hope for the best case scenario. The best case scenarios generally involve the destruction of fiat or a large scale adoption of cryptocurrencies in the global market. The scenario also includes personal increase in wealth, narratives regarding egalitarianism (i.e, “banking the unbanked”), and the take down of tyrannical governments. Because their main instinct is hope of the best case scenarios, their focus is on innovation. Innovation for a left-winger involves creating new ways to utilize the blockchain, or inventing some alternative decentralized consensus methods (such as proof of stake). This is not to say that a left-winger does not care about security at all, it just means that they are more willing to make a security trade-off in order to achieve their goals. The left-winger could be characterized as techno-evangelists and culturally they have a lot in common with Silicon Valley start-up entrepreneurs in the mold of Steve Jobs and Mark Zuckerberg. Vitalik Buterin and Roger Ver are good examples of left-wing hodlers.

Here is a rough graph I made that places different cryptocurrencies and ideas in the crypto space on a left-right continuum. For fun, I’ve named the left-wing after the latest Ethereum collectible craze CryptoKitties, and the right-wing after the POW stalwart meme-coin Dogecoin. The center is anchored by everyone’s favorite shining beacon of blockchain information, Andreas Antonopolous. Note that the words in red are ideas that have nebulous associations with their placement, thus their location are inexact (for example “freedom of speech” is historically a left-leaning concept in mainstream politics, but can also be adopted by the right).

The right-wing is anchored by Bitcoin, the original blockchain created by Satoshi Nakamoto. The central tenet since the inception of Bitcoin has been proof of work (POW), and to me it seems like it is still a centrist position despite the fact that I’ve drawn up Bitcoin to be on the far right. Rogue ideas like proof of stake may have pushed POW to the right-hand side by a bit, but since most cryptocurrencies are POW based, I think it’s in an appropriate position.

It’s important to note that when Bitcoin was first created, the concept of left and right-wing was limited in scope to conversation between sophisticated Bitcoin devs who understood that many problems in the blockchain could not be solved without making concessions on security or decentralization. This concept did not exist in the consciousness of the general public. In those days, the general Bitcoin public behaved very much like a classic left-wing archetype. Optimistic slogans like “global digital currency”, “fast peer-to-peer transactions”, “banking the unbanked”, and “low processing fees” are the creation of the left and can be credited with driving Bitcoin’s meteoric rise in the early days (the left-wing is much better at shilling than the right-wing).

The rise of altcoins began the split of the Bitcoin community into separate factions. Litecoin was the first significant altcoin to emerge, and when it first came out it was seen as a radical idea. These days many people mostly dismiss it as a Bitcoin clone (which it literally is in the parlance of git). Ripple then came onto the scene and staked out a very far left position in the continuum, completely abandoning proof of work and laying a dubious claim that a cryptographic distributed consensus system was sufficient for a cryptocurrency.

Currently, the left is anchored by Ethereum whose main difference from Bitcoin is its comparatively functionally rich and Turing-complete scripting language. Although Ethereum has many fundamental similarities with Bitcoin, the biggest one being proof of work, its leftist tendency is made clear by the grandiose plans of its developers and the actions it has taken to resolve difficult situations such as the DAO hack. Their proposed move to proof of stake will certainly move Ethereum even further to the left. If this happens, I suspect that some other cryptocurrency will fill the large gap in the left/right spectrum that it will leave behind.

In summary, the political spectrum in the cryptocurrency space is occupied by the left, who is driven by hope, and the right, who is driven by fear. The left-wing wants to focus on innovation and the right-wing wants to focus on security. Important homework questions you might want to think about are: A) Where would you place yourself in the crypto-political spectrum? B) What political spectrum does a certain cryptocurrency belong to? C) What is the future crypto left/right landscape going to look like?

In a future part 2 of this article, I will expand further on what it exactly means to be a left/right-winger in the cryptocurrency space and go over some examples from the past where this has played out with huge consequences. Further, we can establish some basic theories about how left/right-wing politics will play out in the future that will help us navigate all you hodlers out there to the moon.

Friday, February 9, 2018

IOTA Doesn't Scale

IOTA is cryptocurrency that uses a Tangle instead of a “blockchain”. From, “The Tangle as implemented in IOTA is the first public distributed ledger to achieve scalability, no fee transactions, as well as quantum-computing protection”. In this article, I will try to investigate how they achieve this claim and see how correct their claim is.

I’m going to skip the “quantum-computing protection” part here because I’m not well versed in the topic, but let’s cover the two important topics. IOTA is proposing that the Tangle is a ledger that has “no fee transactions” and “achieves scalability”. These are two very contradictory statements because if there is no fee, there is nothing that prevents someone from spamming the network, and thus you have a ledger that grows out of control. Some shills have used “infinite scaling” ( ) as a tagline, which is also a funny oxymoron.

So how does the IOTA Tangle work? When creating a transaction in IOTA, you must assemble any two transactions that came before it, and attach a small proof of work to it. Therefore, the creation of a transaction necessitates a creation of a very small block with two other transactions on it. This proof of work is a small constant (presumably so that it works on small devices to enable the Internet-of-things) and does not adjust to the network hash rate.
This raises an obvious question: so if the proof of work is a small constant, how does IOTA deal with the fact that someone with a lot of hashing power can spam the network with a bunch of transactions? The Tangle will quickly grow out of control preventing anybody from validating the full ledger. Oddly enough, the whitepaper makes only a single sentence mention of this attack and how it plans to deal with this. Here is the sentence: “To avoid spamming and other attack styles, it is assumed that no entity can generate an abundance of transactions with “acceptable” weights in a short period of time.”

Ehh… what? What kind of crazy assumption is that? So basically what the whitepaper is saying is that the proof of work has to be difficult enough to prevent spamming, even though the difficulty does not adjust automatically. This means that the Tangle has to hard fork every time there is some drastic change in the network hash rate. Anybody who’s ever mined a cryptocurency knows that the network hash rate can abruptly change at any time, so this assumption is just plain wrong. Another problem with this assumption is that if the proof of work is difficult enough to prevent spamming, it will also be too difficult for your typical Internet of things(the single application that IOTA is supposed to be for) device to solve.

After some looking and asking around, there seems to be another solution that IOTA is using to prevent spam attacks. The solution is the usual suspect when IOTA is being criticized and that is the central coordinator. IOTA’s central coordinator “decides” what is a spam transaction and removes it from being propagated through the network…. hmm doesn’t sound decentralized to me. I was going to bring this up with an IOTA developer, but it seems like I’m not the only one with this concern. Reddit user polayo expressed the same concerns about IOTA’s scaling when IOTA held its AMA, and an IOTA developer actually answered this question himself.

His answer basically states “We don’t have an answer right now. We are going to research this, but for now snapshots is our answer”. So there you have it. One of the main developers of IOTA is admitting that the Tangle does not achieve scalability in its current state. Their two excuses are that a) they are relying on “snapshots” and b) its part of some ongoing research which nobody knows about and they are not going to disclose (if you believe this, I have some Bitconnects to sell you).

“Snapshots” describe the state of a ledger at a certain time without you having to download the entire ledger. They are centralized solutions that relies on trust. Every time you download a snapshot you are putting yourself at diverging from consensus because you have to trust that you are getting the correct snapshot. Scaling is extremely easy when it doesn’t have to be trustless. Every cryptocurrency, including Bitcoin, scales just as well as IOTA’s Tangle if it relied on snapshots and hand-waved away the fact that snapshots are not trust-less (services like are essentially snapshotting services and no one's seriously proposing it as a scaling solution for Bitcoin).
Skimming through the IOTA roadmap, , they refer to snapshots several times but there is nothing in place to tell us how they will remove their dependencies from snapshots. There is also no plan whatsoever to deprecate their central coordinator which they rely on heavily to keep the network going.

In summary, when you strip away the fancy tech jargon like Directed Acylic Graphs, Internet of Things, and Tangle, what the IOTA whitepaper proposes is simple and fundamentally impossible. They are basically proposing that a blockchain with no difficulty adjustment can scale. When they actually implemented their system, they realized that this was impossible for an actual decentralized system so they implemented a centralized solution to fix it.

Does IOTA achieve better scalability compared to other cryptocurrencies? No.
Does it heavily rely on a centralized coordinator? Yes.
Is there any plan in place to remove dependencies from the coordinator? No.

Wednesday, December 2, 2015

A Case for Replace by Fee : How Bitcoin Businesses can Benefit from RBF

"Replace by Fee" or RBF has recently received a lot of talk with the merge of “Opt in RBF” by the Bitcoin Core devs. Although there has been a lot of FUD and drama being spread on social media channels regarding the change, several noted figures in the Bitcoin community , such as Erik Voorhees from Shapeshift, and Chris Pacia from OpenBazaaar, have made valid and well written statements against RBF . Their main argument is that RBF makes it easier to double spend and will reduce the capabilities of Bitcoin businesses to compete since they can no longer rely on zero confirm transactions. I think this is a valid and pragmatic point, but here I would like to make the counter argument that Bitcoin businesses stand to gain a lot from the adoption of RBF, and give coherent examples of how Bitcoin businesses can utilize RBF to provide a better customer experience, and be more cost efficient.

Point 1: Bitcoin businesses will save money on transaction fees:

The businesses that stand to gain a lot from RBF are operations that must handle large volumes of outbound Bitcoin transactions, and must pay a large amount of aggregate transaction fees. This means exchanges, brokers (like Shapeshift), and payment processors stand to gain a lot from RBF. Operations like these want to pay the lowest transaction fee possible, but at the same time it must meet customer expectation of timeliness. They don't want to underpay the transaction fee because the transaction will take a long time to confirm, and they don't want to overpay the transaction fee because it impacts their bottom line negatively. This is a difficult problem to solve, due to the fact that transaction fees are not static, and will be increasingly more volatile as the Bitcoin mining subsidy is decreased and miners must rely more on transaction fees for revenue. We have already seen instances of high transaction fee volatility, due to the spam attacks on the network. According to BlockCypher, during the spam attack on 2015, July 8th , the average transaction fee went up 3 times, while the minimum transaction fee went up 25 times.

Transaction fees are dependent on many factors such as available network bandwidth, available size of the mempool, the miners that are active at that particular moment, and the cost of operation for those miners. So spam attacks are not the only source of volatility for transaction fees. You could see unpredictable transaction fee increases when there is a large network outage that knocks out a bunch of full nodes, or when there is an increase in the spot price of coal in China that affects operation costs for Chinese Bitcoin miners. It is important to note that the volatility of transaction fee can not solved by increasing the block size. It may have an impact of lowering the transaction fee, but it will not make transaction fees static, due to the large number of variables that affects transaction fees as mentioned above.

With RBF, Bitcoin businesses now have the capability to adjust their transaction fee on their outbound transactions in real time. This makes it far less likely for a business to overpay or underpay the transaction fee. This is easy to see if you look at RBF as a bartering process between the transaction creator and the miner. The transaction creator can start with a low offer, and progressively increase his offer until the miner accepts. This is much better alternative to the current “First Seen Safe” process where the transaction creator is stuck with the first offer he makes with no ability to make a better offer. The first offer could be flat out wrong due to the transaction creator's inability to estimate the required transaction fee, or some unpredictable event could occur immediately after the time that the transaction was created that impacts the required transaction fee.

Point 2: Double spends are not necessarily malicious

When we think of double spends, we think of people defrauding other users, but this does not always have to be the case. For example, people mistakenly send Bitcoins to the wrong address all the time with fortunes being lost in this way. I'm sure that many Bitcoin businesses past and present have also mistakenly created transactions that they'd like to take back. RBF gives you a time window where you can reverse this mistake (with some probability of success).

Many honest mistakes are made all the time in mainstream financial markets, such as the six billion dollar “fat finger” screw up at Deutsche Bank, so institutions have rules in place to deal with the fact that human beings are prone to type in an extra zero or two. Bitcoin having a feature where transactions are reversible up to a certain time period is not necessarily a bad thing. It can protect Bitcoin businesses and their customers from their own mistakes.

Additional Readings on RBF:

Sunday, October 18, 2015

Atomic Cross Chain Transfer, an Overview

Atomic cross chain transfers (or atomic cross chain trading, from here on referred to as ACCT for short) , makes it possible to trustlessly trade between two cryptocurrencies existing on different blockchains. This means that neither of the two parties involved in the trade is at risk of their funds being stolen. The trade either completes with both parties getting the coins that they agreed upon, or the trade fails and both parties get their coins back. The trustless nature of ACCT will eventually have a huge impact on the way cryptocurrencies are traded, as it allows complete strangers with no prior reputation to trade with each other without a third party intermediary.

The first working theoretical implementation of ACCT was first described by Noel Tiernan in this thread, and the basic details of the algorithm is described here. In this document, we are specifically interested in discussing ACCT for Bitcoin and Bitcoin derived cryptocurrencies. Bitcoin derived cryptocurrencies are forked off of the Bitcoin Core source code, and examples include Dogecoin, DASH, and Litecoin. Below are the covered topics in this document:

1. ACCT using refund transactions
2. Alternative implementation of ACCT using refund transactions
3. Vulnerabilities of ACCT using refund transactions
4. ACCT using Check Lock Time Verify

1. ACCT using refund transactions

ACCT can be currently implemented by constructing refund transactions. We discuss in detail here one implementation of this method. This implementation is based on Ross Nicoll’s CATE project.

Variables and Terms

AlphaCoin - a bitcoin derived cryptocurrency
BetaCoin - another bitcoin derived cryptocurrency
Initiator – one party of the trade, looking to sell Alpha Coin for Beta Coin.
Responder – the second party involved in the trade, looking to sell Beta Coin for Alpha Coin
X – secret number created by initiator
H(X) – hash of secret X
Privkey i / Pubkey i - private public key pairs belonging to initiator
Privkey r / Pubkey r - private public key pairs belonging to responder
TxAb - initiator's bail in transaction, for the Alpha Coin network
TxAr - initiator's refund transaction, for the Alpha Coin network
TxAp – responder's pay out transaction, for the Alpha Coin network
TxBb - responder's bail in transaction, for the Beta Coin network
TxBr – responder's refund transaction, for the Beta Coin network
TxBp – initiators pay out transaction, for the Beta Coin network
T2 - time till initiator can obtain refund
T1 - time till responder can obtain refund , where T1 < T2


Step 1.
Initiator creates secret X, and hashes it to create H(X). Initiator also creates two public private key pairs (pubkey i1,i2 / privkey i1,i2). Responder creates two public private key pairs (pubkey r1,r2 / privkey r1,r2).

Step 2.
Initiator shares H(X) and pubkey i’s with responder. Responder shares pubkey r’s with initiator.

Step 3
Initiator creates and keeps secret TxAb, the bail in transaction. The bail in transaction moves initiator's funds into an unspent that can be redeemed with knowledge of secret X and a signature from privkey r1, or it can be redeemed with signature from both privkey i1 and privkey r1.

Step 4.
Responder creates and keeps secret TxBb, his bail in transaction. The bail in transaction moves responder's funds into an unspent that can be redeemed with knowledge of secret X and a signature from privkey i2 or it can be redeemed with signature from privkey i2 and privkey r2.

Step 5.
Initiator creates TxAr, his refund transaction that spends TxAb with signature from privkey i1 and privkey r1 to an address controlled by initiator. TxAr has nLocktime set to some time in the future T2 so is not valid until that time passes. TxAr is sent to responder and the responder sends back TxAr signed with privkey r1. Initiator signs the transaction with privkey i1.

Step 6.
Responder creates refund TxBr, his refund transaction that spends TxBb with signature from privkey i2 and privkey r2. The refund TxBr has nlocktime set to some time in the future T1 (where T2 > T1 ) so is not valid until that time passes. TxBr is sent to initiator and the initiator sends back TxBr signed with privkey i2. Responder signs the transaction with privkey r2.

Step 7.
TxAb is broadcast by initiator.

Step 8.
After confirming TxAb, responder broadcasts TxBb.

Step 9.
Initiator creates payout transaction TxBp that spends TxBb by revealing secret and using privkey i2. Since the secret is now revealed to the responder, the responder creates payout transaciton TxAp that spends TxAb by using the revealed secret X and privkey r1.


If initiator fails to broadcast TxAb in step 7, the exchange has failed and no further steps need to be taken by the responder.

If responder fails to broadcast TxBb in step 8, initiator can redeem TxAb in time T2 using refund transaction TxAr.

At step 9, if initiator fails to get pay out from TxBb before time T1, responder can get refund with TxBr. If responder fails to get pay out from TxAb after time T2 has passed. Initiator can get refund with TxAr


TxAb’s output should be a p2sh transaction to the hash of the serialized script outlined below. The reason we use a p2sh transaction is that since Bitcoin Core 10.0, any p2sh transactions are considered standard and will be relayed by 10.0 nodes.

OP_DUP OP_HASH160 [Hash160(pubkey r1)] OP_EQUALVERIFY
OP_DUP OP_HASH160 [Hash160(pubkey i1)] OP_EQUALVERIFY

Refund transaction TxAr’s script sig will look like below:

[signature from privkey i1] [pubkey i1] 1 [signature from privkey r1] [pubkey r1]
{serialized script}

Pay out transaction TxAp’s script sig will look like below:

[X] 0 [signature from privkey r1] [pubkey r1] {serialized script}

TxBb, TxBr, and TxBp is symmetrical and replaces key pair r1 with i2 and key pair i1 with r2.

2. Alternative Implementation of ACCT using refund transactions

Noel Tiernan describes an alternative implementation, which is also implemented by Matthew Bell in project Mercury. The main advantage of this implementation was that before Bitcoin Core release 10.0.0, not all p2sh scripts were considered standard and were not relayed by nodes. This implementation required the use of only one non standard transaction in the entire ACCT protocol, as opposed to two. Thus this implementation was more likely to be propagated across the entire network.

However with the introduction of Bitcoin Core 10.0.0 on February 2015, rules for standard transactions were relaxed so that all P2SH redemption scripts are considered “standard” and are relayed by the nodes. Thus this alternative implementation no longer has this advantage. Litecoin Core has adapted the 10.0.0 changes since June 2015 with version 10.2.2, and Dogecoin Core as of September 2015 is in the process of adapting the 10.0.0 changes with its beta release of 1.10.

3. Vulnerabilities of ACCT using refund transactions

Extortion using Transaction Malleability

TxAb and TxBb could be mutated , thus making their respectable refund transactions TxAr and TxBr invalid. If refund transaction is invalid, the funds could be forever locked unless you obtain cooperation from your counterparty to resign the refund transaction. A possible attack that can be performed either by the initiator or the responder is to mutate the counterparty's funding transaction, making their refund transaction invalid. Now the attacker is in position to extort money from the counterparty.

There has been progress on several fronts to alleviate the transaction malleability problem in Bitcoin such as strict DER encoding, lowS signature enforcement, and stricter definitions for standard transactions limits mutated transaction from being relayed. However, relay rules do not prevent miners from mining mutated transactions, and do not change the behavior of old clients or clients that do not adhere to the same relay rules as the core protocol.

It is unlikely that the malleability problem will be solved in the near future. BIP 62 outlines all known malleability sources, but it is by no means an exhaustive list, since it is based on heuristics. New malleability sources could be discovered, and could also be created by changes in the protocol. Normalized Transaction ID's have been proposed as a solution, but this proposal is far from obtaining consensus from Core devs and being implemented into Bitcoin. This vulnerability makes it dangerous for ACCT using refund transactions to be deployed in production systems.

Fund Lock Attack

A trivial attack to perform is for the responder to never follow through the bail in transaction broadcast on step 8. This will lock up the initiator’s fund for time T2 without any losses by the responder. The initiator can perform a similar attack although not without locking up his own funds. He can refuse to perform his pay out transaction in step 9, but in this case it will keep responder’s fund locked up for time T1 and keep his own funds locked up for time T2.

Payout Failure

Responder could fail to obtain payout from TxAb before time T2 as in step 8. This could happen for many reasons such as the responder losing private key r, the responder losing access to the internet (DDOS, network failure), or his transaction does not make it into the blockchain (blacklisted by miner, congestion in the blockchain, failure to pay sufficient tx fee). In this case, the initiator would be able to have access to both his own fund and the responder's fund, effectively allowing him to steal responder's funds.

Note that initiator does not face the same risk if he fails to redeem TxBb before time T1, as long as he does not reveal secret X. If initiator fails to redeem TxBb before time T1. Responder can use refund transaction TxBr to redeem TxBb , but responder has no access to TxAb. However, if initiator reveals secret X (for example, TxBp is broadcast onto the network but does not make it into any blocks before time T1), the responder would be able to have access to both his own fund and the initiator's fund.

Double Spend Attack

As with any cryptocurrency transactions involving two parties, there is an opportunity for a double spend attack. This can happen if the victim does not wait for sufficient confirmations , or an attacker has access to sufficient mining power.

If the initiator can convince the responder that TxAb occurred when in didn’t, and the responder publishes TxBb, the imitator can steal from the responder by spending TxBb using TxBp and than double spending the inputs of TxAb. Likewise, if the responder can convince the initiator that TxBb occurred when it didn’t, and the responder publishes TxBp, the responder can steal from the initiator by spending TxAb using TxAp and than double spending the inputs of TxBb.

4. ACCT using Check Lock Time Verify (CLTV)

OP_CHECKLOCKTIMEVERIFY is a new op code in the works that Bitcoin Core devs will be looking to deploy with a soft fork in the near future. It is described here in BIP 65. The op code allows us to create transactions that can be spent in different ways depending on the nLockTime of the spending transaction.

ACCT using CLTV is superior in that it does not have the transaction malleability issues of ACCT using refund transactions (it does however have the same other vulnerabilities discussed in the previous section). Additionally, all transaction signing occurs on the blockchain, and the trading parties only need to exchange the hashed secret and their public keys in order for the trade to take place.


Initiator creates secret X, and hashes it to create H(X). Initiator also creates public private key pair (pubkey i1,i2 / privkey i2,i2). Responder creates public private key pair (pubkey r1,r2 / privkey r1,r2).

Step 2.
Initiator shares H(X) and pubkey i2 with responder. Responder shares pubkey r1 with intiator.

Step 3.
Initiator creates TxAb. TxAb can be redeemed after time T2 with privkey i1. At any time TxAb can redeemed with signature from privkey r1 and reveal of secret X. Initiator broadcasts TxAb onto the network.

Step 4.
Responder confirms TxAb. Responder creates TxBb. TxBb can be redeemed after T1 time with privkey r2. At any time TxBb can be redeemed with signature fom privkey i2 and reveal of secret X. Responder broadcasts TxBb onto the network.

Step 5.
Initiator creates TxBp which spends TxBb using privkey i2 and secret X. With the revealed secret, responder can create TxAp which spends TxAb with privkey r1 and secret X.


If initiator fails to broadcast TxAb in step 3, the exchange has failed and no steps need to be taken by the responder.

If responder fails to broadcast TxBb in step 4, initiator can create refund transaction TxAr which redeems TxAb after time T2 using privkey i1.

If initiator fails to spend TxBb on step 5 before time T1, responder can create refund transaction TxBr after time T1 using privkey r2. If responder fails to spend TxAb before time T2, initiator can use TxAr to get refund from TxAb.


TxAb’s output should be a pay to script hash transaction to the hash of the serialized script outlined below.



The refund transaction TxAr has nLockTime > T2 and the input script is

[signature from privkey i1] [pubkey i1] 1 {serialized script}

The payout transaction TxAp has nLockTime < T2 and the input script is

[x] [signature from privkey r1] [pubkey r1] 0 {serialized script}

TxBb, TxBr, and TxBp is symmetrical and replaces key pairs i1 with r2 and key pairs r1 with i2

Friday, July 3, 2015

Noffee Coin : A coin that can't be used to buy your coffee in the morning.

This is a proposal to create Noffee coin. The world's first cryptocurrency created specifically so that you won't be able to buy your coffee with it in the morning (portmanteau of No Coffee). It is also ironically called Noffee because it is predicted that the transaction fee will be very large due to the restrictive amount of space available on each block. 

The goal of this cryptocurrency is to create a blockchain that is small enough that you could easily run a full node on your smart phone even with 10 years of past blockchain data. Now you could be asking, "why would I want to run this on my mobile phone if I can't buy my coffee with it?" Well there are many transactions in the real world that are done with very large briefcases full of US dollars. Noffee coin would be a perfect replacement for such situations. Since the exchanged amount is so huge and the stakes are large, it is imperative that you run a full node and it is no problem waiting three hours to get your six confirms. I have no idea what kind of transactions they could be, but a more imaginative person could figure that out.

The current proposals are:

- 30 minute block time
- 1 kilobyte block size limit 
- Equivalent block reward and halving schedule as Bitcoin. We will halve the block reward every 70000 blocks, which will be about 4 years (same time duration as Bitcoin)

There will be roughly a max of 8 transactions per hour. This means that even with completely full blocks for 10 years, the total blockchain size will be about 170 megabytes. I think a lot of cool stuff can be done with this project, but you definitely will not be able to buy your coffee with it. I am now looking for initial comments and questions regarding the project.

Further things to consider are whether we should further reduce Noffee coin's hardware requirements by putting in things to restrict bandwidth usage in the p2p communication protocol, limit the growth of UTXO's (high dust and minimum tx fee), and reduce computing requirements in the script processing (or remove the entire thing altogether). I like the idea of a "Minimum Viable Block Chain" that would scrap the entire scripting language of Bitcoin as it introduces a significant amount of complexity into the consensus protocol.

 If there is enough interest, especially from other developers that can help out, I will proceed in refining the proposal further and will create the cryptocurrency that everyone deserves. If there is no interest, well maybe this is at least a funny way to think about the block size debate.

Coffee icon made by Freepik from is licensed under CC BY 3.0

Friday, June 12, 2015

Front running Decentralized Exchanges: The problem with Augur, Bitshares, Nxt, and Counterparty

Decentralized exchanges have been raved about for a while now in the Bitcoin space and has been crowned as the future saviour of our financial exchange infrastructure (even Mark Karpeles of Mt. Gox fame is talking about it ) . But unfortunately, this is a very hard problem and the current batch of decentralized exchanges have one system breaking issue that makes them entirely unusable. I’m specifically talking about decentralized exchanges where the actual process of matching orders happens on the blockchain. This includes the likes of Nxt, BitShares, Counterparty, and Augur which has a built in limit order book, or some approximation of the limit order book, on the protocol consensus level (Augur is not branded as a decentralized exchange, but you can think of them as an exchange for a specific asset class which is prediction of future events).  All of these platforms allow you to issue assets and trade them on the blockchain. The basic premise  is that you can submit an order to trade like you would submit a transaction to the blockchain, and then the underlying protocol would act as an order book and match up the orders automatically and execute them for you.

This sounds awesome, and if it works it would be a cure for the cancer of incompetent centralized exchanges in the cryptocurrency ecosystem. Unfortunately, the currently available solutions cures the cancer, but also kills the patient.  The basic problem is that the miners can ruthlessly front run you without any repercussion. This is made possible simply by the fact that in a bitcoin derived distributed system, a miner can see all the transaction before they are put into a block, and they are free to put in their own transaction into the block before your transaction happens. For example, let’s say I submit a large order to buy some asset on the Counterparty exchange. This order finds its way to a Bitcoin miner (Counterparty is built on top of the Bitcoin blockchain) who says, “hey, that’s a fat and juicy order that will drive up the price, let’s create our own order to buy the asset and put it in the blockchain before he does”. Then, if the miner is able to mine this particular block, he would have gained an easy risk free profit by utilizing the information in my order.

Bitshare’s Daniel Larimer has a very informative article called “How Bitshares prevents frontrunning ” , which describes the problem better than I can, but unfortunately makes a terrible conclusion. The conclusion of the article is that they can’t prevent frontrunning, so you should just assume that you are being front run. This conclusions seems to be missing the whole entire point of having a limit order book. If you cannot provide a fair and orderly execution, you should just provide an auction system where orders are not automatically executed and users can choose the orders they execute against. Using a limit order book gives a dangerous illusion that the system is fair, when it is inherently rigged in favor of the miners.

Another great feature of the limit order book that is lost upon these decentralized exchanges is that it rewards traders that reveal price information by giving them priority of trade execution. This feature has a lot of social benefits because it encourages people with new price information to disclose it to the rest of the world and improve the price accuracy of the underlying asset. However,  in these decentralized exchanges, the miners are always favoured to have the priority of execution, thus traders have no incentive to reveal price information. This is going to be particularly system breaking for Augur whose main premise is to provide a decentralized prediction system. If traders with information are not given priority of execution, they cannot extract value out of their information because the miners will take all or most of the value by front running them. If traders cannot extract value out of their information, they will simply not use Augur.  Unless they can provide some solution for this problem, my opinion is that this project will be a complete failure.

One argument I’ve heard against this problem is that the situation is not any worse than a centralized exchange. They are kind of right because a centralized exchange can also front run you. But they are wrong because a centralized exchange faces serious damage in its reputation and business if it is revealed that they are front running. Bitcoin hard liners will scoff at this idea but believe it or not, some systems work fine based on reputation and trust. Miners face no such disincentives for front running. These decentralized exchanges have basically anointed the miners to collectively act as a fair exchange, but the miners never agreed to it. The miners are in the business of following consensus rules and getting block rewards, not running an exchange. If they can skim some tasty frontrunning profits on the side in addition to collecting their block rewards, why not?

No practical technical solutions exists to solve this problem currently. The only thing that mitigates front running is enforcing random ordering of transactions within a block, cutting down the possibility of front running to 50% within the same block. But this only mitigates, and does not remove it entirely. A two phase commit and reveal system is another potential solution. This is when orders enter the block encrypted so that the miner cannot see your orders, and then once they are confirmed in the block, the order is decrypted so everyone can resolve the state of the order book. Unfortunately, this suffers from the problem that people can selectively choose not to decrypt their order, thus destroying the integrity of the order book. You could use a trusted arbiter whose job is to encrypt and decrypt orders, instead of having each participant encrypt their own orders. The problem of course is that the arbiter now has the ability to front run instead of the miner, but this is a better proposition because the arbiter’s sole job depends on him being trustworthy.

It may also be possible to use time locked encryption , to turn the two phase commit and reveal system into a one phase commit and reveal system. This would prevent people from selectively decrypting their order, since decryption does not rely on revealing a secret and relies on computation time. But in practice, time locked encryption is very hard to implement since you need access to large computational power, and have to estimate accurately the computational power of your adversaries.

There may be a simple solution, which is economic in nature as opposed to technical. The solution is to pay miners to be fair. If miners are getting a large share of profit from validating exchange related activities, they may be incentivized to play fair and encourage trading to continue at a healthy volume. This can be done by attaching high transaction fees on exchange related transactions or paying miners out of band. Some miners could also choose to establish themselves as a trustworthy entity that specializes in processing exchange related orders (and charge people for it). Now this solution raises many important and difficult questions. How much should the miners be paid for this service? If miners are essentially acting as an exchange, does it subject them to securities and exchange regulations? Should they be subject to third party audits to make sure their system is fair? Is there really any benefit to a decentralized exchange if the system is ultimately reliant on trust? Developers on Augur, Bitshares, Counterparty, and Nxt needs to seriously consider these questions if they want their exchanges to be taken seriously.  

In summary, the current batch of decentralized exchanges have serious problems with no good solutions in sight. The inherent architecture of the blockchain makes the task of frontrunning a decentralized order book trivial as a miner. Anyone using these exchanges for trading purposes should consider the consequences of miners having perfect information against you.