Thursday, November 29, 2018

The Nigerian Nakamoto Scam

Craig “Faketoshi” Wright and Bitcoin SV is running a variant of the Nigerian scam. Nigerian scams work because “by sending an email that repels all but the most gullible, the scammer gets the most promising marks to self-select, and tilts the true to false positive ratio in his favor.” [Cormac Herley, “Why do Nigerian Scammers Say They are From Nigeria”]. In other words, Nigerian scams work because it is a hyper efficient idiot finder. Only an idiot would engage with such a preposterous claim regarding a Nigerian prince. Most people will just ignore it, and this is good for the scammer because the scammer does not have to waste time engaging people with brains. Imagine if you were a scammer and you sent out a million emails. You don’t want to waste time corresponding with hundreds of people with normal intelligence, you want to find the stupidest of the bunch.
Craig Wright is basically a Nigerian prince (or as per the title of this article, a Nigerian Nakamoto). Only an idiot will actually believe that someone like Craig is Satoshi. He is in fact the exact opposite of Satoshi. A patent trolling, plagiarizer who uses 4chan insults and technobabble.

So called creator of Bitcoin rallying against soy boy committees

It would be a mistake however to believe that Faketoshi himself is an idiot, he is not. He is merely playing a character that attracts gullible idiots. Craig was smart to position himself into the Bitcoin Cash crowd because he correctly deduced that they had the right combination of gullibility and liquidity. He saw that they were eating up ridiculous conspiracy theories that revolved around Blockstream. It would not be that hard to convince them that he was Satoshi, especially if he was on their side of the fight against Bitcoin. I suspect that people in leadership position within Bitcoin Cash like Roger Ver were smart enough to know that Craig was a fraud. However, they were morally bankrupt enough and too short sighted to reject him because they thought that he was on their side. I’m surprised that Ver has so far received almost no backlash from the ABC camp from this ordeal. He 100% enabled the SV camp from gaining credibility within Bitcoin Cash. If you are a Bitcoin Cash conspiracy theorist who believe everyone is a Blockstream plant, you have to wonder whether Roger Ver himself isn’t a Blockstream plant.

Roger Ver sharing a drink with SV

Once Craig gained credibility within Bitcoin Cash, the next step was to splinter off the chain into Bitcoin SV. This step is equivalent to the phase where the Nigerian prince gives you a bank account number to wire the money to. With the financial backing of billionaire and online casino mogul Calvin Ayre, Bitcoin SV was created. Before and during the chain split, SV made a lot of noise regarding a hashwar where they threatened to 51% attack the ABC chain. Many people took the bait and believed that there would only be one chain that would remain after the split. However, this was all just a marketing ploy to give legitimacy to SV.

SV would gain nothing and probably lose by engaging in a hashwar against ABC which has the backing of mining giant Bitmain. What SV wanted was for the stupidest people within Bitcoin Cash to self select themselves onto a chain where they have 100% control. The next step is obvious. Once they have total control on the chain containing a bunch of stupid people that are members of the cult of Faketoshi, they are free to do whatever they want. Faketoshi has already hinted that they were going to be stealing burned coins, by changing the code to interpret them as miner rewards. There are also other creative ways to make money, especially if you control both the software development and mining on the chain. Bitmain showed that such a scheme was possible with their implementation of ASICBoost. I would also not be surprised if they decided to implement some inflationary scheme that enriches their own wallets at some point in the future.

I think the mastermind behind this idea can be traced to Calvin Ayre, who made his money running online casinos. He sees the blockchain as a poker table. And there’s two sure fire ways of making money in poker and that is a) to make sure you are the house and b) that you are always playing against terrible poker players. POW mining is like a game of chance after all. Being able to fully control the software development enables you to be the “house” and set the rules of the game. Kicking out Bitmain into their own chain also allows them to be the biggest player on the table. Now the only task remaining is to steadily dump the newly minted SV coins. I suspect that SV will be very good at doing this because the crypto market is mostly just a large unregulated online market for people to gamble their excess money away. Calvin Ayre is an expert in that market, and Faketoshi gave him the best customers.

Saturday, August 25, 2018

Crypto Ideology: The Bitcoin Cash Ideology and the Incoming Schism

Bitcoin cash is facing a schism. Developers on Bitcoin ABC seems to be completely oblivious to this threat, hence they are proposing to hardfork over non critical matters on Nov 15th. It is not clear what the other BCH implementations like Bitcoin Unlimited and the new Craig Wright project Bitcoin SV intends to do on Nov 15th. What is clear is that there is a good deal of hostility (devs being banned from communication channels, Faketoshi posturing), and a high likelihood of Bitcoin Cash splitting into multiple chains. Various vulture chains have started to come out like Bitcoin Cobra and Bitcoin Stash trying to take advantage of the situation.

Bitcoin cash is founded on the ideological tenet that a hard forked minority chain can be a legitimate successor to the original chain. “Bitcoin Cash is Bitcoin” is a Roger Ver invented meme based on this tenet. It should not surprise anyone that disagreements within the Bitcoin Cash community will be settled by the chain splitting into multiple forks, using the tenet as the justification. Allow me to “unroll” this statement:

The core foundation of any large group of people rests on ideology. Nations, religions, and political movements cannot exist without ideology and neither can cryptocurrencies. Stable ideologies allow communities to thrive. A simple example in religion is the Christian tenet that “there is one true god”. This belief strengthens the religion because it weakens membership in competing religions. Communities with unstable ideologies will eventually collapse. Think of the Shakers, a 18th century Christian sect that endorsed celibacy as a core tenet. It should be no surprise that Shakers are now extinct because its members did not have children that could continue the practice of the religion.

The very ideology that justifies the existence of Bitcoin Cash, also justifies the use of chain splits to settle any disagreements within the community. Its easy to see that this ideology, that a hard forked minority chain can be a legitimate successor to the original chain, is completely unstable. Witness below this profoundly confused statement by professional BCash shill David Jerry. He proposes that to solve a chain split, the minority chain capitulates and switches to the winning chain, while not realizing that Bitcoin Cash itself is a minority chain to Bitcoin.
While David Jerry’s solution is sensible in Bitcoin, it is completely incompatible with the Bitcoin Cash ideology. It is thus reasonable to conclude that Bitcoin Cash will face a never ending threat where its community members threatens to split off permanently from the main chain. I predict that within 1 year, there will be multiple competing hard forks that come out Bitcoin Cash. Eventually, the chain will have been split so many times that it will be a forgotten footnote in the history of cryptocurrencies.

Now let us go back to the original debate which created Bitcoin Cash in the first place, the block size debate. Bitcoin Maximalists often say that the block size debate is not about the block size at all. This is true, the block size debate is about retaining a stable ideology. The most important belief that the maximalists wanted to stand by in the block size debate is that backwards compatibility is never broken (or that we never hard fork). This ideology is stable because it guarantees that members who failed to upgrade their software are never dropped from network. This may sound like a rigid requirement for a software project, but Bitcoin is not just a software project. It is a method of coordination for a large group of people who face extremely hostile and powerful adversaries. Understanding this fact, it becomes clear that software upgrades can be a large attack vector and may not be feasible when the adversaries are fully engaged.

Critics are correct in saying that currently, the state level adversaries are not fully engaged and that hard forks are completely possible in practice. What they don’t understand is the nature of ideology. Ideology can only be strengthened through strict adherence to it. A cryptocurrency project will not be able to easily switch to a policy of having no hardforks when the adversaries become suddenly engaged. For a project like Bitcoin Cash, which have already hard forked twice within a year to solve its problems, the users have been conditioned to believe that hardforks are safe. Thus when a malicious state sponsored hard fork comes along, they will be sitting ducks. Bitcoin users, who have been conditioned to believe that all hardforks are unsafe, will be immune when such an attack comes.

A Stable and sustainable ideology must be the foundation of all cryptocurrencies. No amount of cryptography, consensus protocol development, and technical optimizations will help a cryptocurrency with an unstable and bankrupt ideology.

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
Source: Blkdat.com

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 hitbtc.com so the transactions below could all be intentional).


Green: number of transactions on Monero, Black: number of transactions on Monero Original
Source: Blkdat.com

Conclusions


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 https://learn.iota.org/faqs, “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” ( https://www.iotasupport.org ) 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 https://iota.org/IOTA_Whitepaper.pdf 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 blockchain.info are essentially snapshotting services and no one's seriously proposing it as a scaling solution for Bitcoin).
Skimming through the IOTA roadmap, https://blog.iota.org/iota-development-roadmap-74741f37ed01 , 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.

TLDR:
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 bitcointalk.org 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

Steps

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.

Notes

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

Scripts

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_CHECKSIGVERIFY
OP_IF
OP_DUP OP_HASH160 [Hash160(pubkey i1)] OP_EQUALVERIFY
OP_CHECKSIG
OP_ELSE
OP_HASH256 [H(x)] OP_EQUAL
OP_ENDIF

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.

Steps

Step1.
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.

Notes

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.


Script


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

OP_IF
[T2] CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 [Hash160(pubkey i1)]
OP_EQUALVERIFY OP_CHECKSIG

OP_ELSE
OP_DUP OP_HASH160 [Hash160(pubkey r1)] OP_EQUALVERIFY OP_CHECKSIGVERIFY OP_DUP
OP_HASH160 H(X) OP_EQUAL
OP_ENDIF

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