2016-01-25

Cryptocurrencies as protection from the government

Recently, International Monetary Fund released a report on Virtual Currencies. Overall, it's not a bad report - it discusses whether virtual currencies such as Bitcoin should be considered money, what the regulatory approach should be and what are some of the challenges related to dealing with cryptocurrencies. It has its share of misconceptions (for example: "VC schemes are difficult to monitor. Their opaque nature makes it difficult to gather information, including statistical data, or to monitor their operation." - yeah, no, that's the current banking system you are describing there), and overall it paints a cautionary picture of virtual currencies. However, I think the report is missing one important feature of cryptocurrencies that a lot of people might find interesting - they are a protection from the government. Let me explain what I mean...

Government power over money


When you stop and think about it, a lot of governments have nearly orwellian power over money. The monetary policy is not something that is often discussed by a lot of people, and often we are not equipped with the vocabulary to talk about it (like trying to form complex thoughts in newspeak). They get to decide whether savers or borrowers have it easier by controlling the rate of inflation. They get to determine how much your labour is worth by engaging in currency wars and a "beggar thy neighbour" race to devalue its currency the most. Then we have the incompetent governments that let their currency devalue in hyperinflation like Venezuela (reaching about 100+% in 2015). The fiscal and monetary policies are thrust upon us.

In short, the governments can effect our savings, future income, as well as many other factors just by controlling how money is created and spent.

Lack of trust in the government


For those and other reasons, some people resort to moving away from the government-issued currencies and adopt new forms of payments. Whether they take the form of local currencies, gold or something else, they can be an expression of lack of trust in the government.

However, there are limitations to a lot of those currencies in the modern world. Local currencies are often low-tech and they are not usable globally. Physical currencies can be seized by force (like in 1933 in USA, by the Executive Order 6102).

At the moment it would appear that only native cryptocurrencies such as Bitcoin can be a viable protection from the government in the modern world.

Protection from the government


While some people would jump to thinking that "protection from the government" necessarily means breaking the rule of law and engaging in illegal activities, that's not what I'm talking about here. What I'm discussing is withdrawing at least partially from the fiat-fuelled economy and moving into the cryptocurrency economy. One can and should still pay taxes, obey the law and so on, but that doesn't mean one has to keep one's wealth in the potential house of cards that various banks and government currencies are (look no further than the 2013 Cyprus crisis and the related bank bail-ins).

I am a saver, not a borrower. I wish for my money to at least keep its value, or be worth more. I want my wage to be stable no matter which government I work under. I don't want the currency I use to be created as debt by the banks, or even let the banks take any part in the money creation process. As such, I know of no fiat currency in the world today that satisfies my preferences, hence why I choose Bitcoin over fiat.

Conclusions


Native cryptocurrencies like Bitcoin offer a way for people to de-leverage the power governments hold over the currency and shape a new economy for themselves.

The IMF and similar organizations need to understand that asking "should the government regulate cryptocurrencies?" might be less important than "if cryptos will succeed, why would anyone continue to use fiat?". Probably for the first time ever, fiat currencies have a worthy competitor in the global Internet economy. They can either focus on becoming the best currencies they can be to compete (akin to Steam trumping free torrents), or go the way of the Kodak.

Related topics:

2016-01-17

Stanford University and its native advertising of 21.co

About two weeks ago there was a post on /r/Bitcoin advertising a new course on Bitcoin Engineering from Stanford University. It sounded good enough - there is a lot one can develop with Bitcoin and teaching it at a university would be a perfect way for new people to get exposed into Bitcoin. However, reading some of the topics to be covered, such as "Bitcoin Dropbox" or "Bitcoin WordPress", made me think of some company I covered before on this blog. Reading further down, yup, one of the instructors for the course was Balaji Srinivasan, the CEO of 21.co. "Oh boy!" I thought, "I wonder how much of this course will focus on using the 21 Computer rather than pure Bitcoin...". Today I came back to the website and I got my answer...

It's not often that I get to write multiple pieces on this blog that fit together into a neat narrative, but it seems that 21.co will have the privilege (previous entries - 1, 2).

Course content so far


At the moment, it looks like the course is two weeks in and we have 3 out of 12 rows of documents available publicly:


While it is possible the course becomes more generalized in the future, I have my doubts.

Reading the entire course page, we can see the course is about "Bitcoin and Bitcoin-enabled computing", where the students will be "build[ing] Bitcoin-powered versions of several popular Internet services". No mention of "Bitcoin Computer" or "21 Bitcoin Computer", so one would think you would be building something with perhaps Bitcoin Core, or some other open APIs...



"Pick up your 21 Bitcoin Computer up front". Makes me REALLY excited for the possible upcoming MOOC version of the course (signup form available). Thanks Balaji.

Lab 1, instructions on setting up 21 Bitcoin Computer, followed by some okay explanation of what Bitcoin is, basics of how it works, etc. This is then followed by some hands-on exploration of data in Bitcoin on the 21 Computer, explanation of what mining is and "How to rapidly mine bitcoin with a Bitcoin Computer" (after all, "The 21 Bitcoin Computer includes a fast and convenient way to get bitcoin for programming purposes" - who needs TestNet, right?). After that we learn about the all important "21.co balance and your blockchain balance"...

Guys, there is a reason mining is downplayed in most introductions to Bitcoin (including the version 2 of the famous "What is Bitcoin?" video) - it is a specialized industry doing some of the most boring things around Bitcoin. A vast majority of Bitcoin businesses never touch it, nor care about it. Sure, by all means, explain how it works and what it is, but devoting 11+ out of 54 pages to it in the first lab is an overkill. TestNet exists for a reason - you can get some coins to play around for free and its way less complicated.

After that, we get a document on "Remotely login to your Bitcoin Computer" (I think what you meant  to say was "Remotely logging into"). As expected, more 21 Computer. Finally, we get some document to schedule 'Genius Bar' appointments (Apple much?).

Upwards and onwards to week 1. We get out Lab 0, which is the course overview, how to set up 21 Computer (with a special slide on how to "Mount the 21 hard-drive as a volume on your Mac"...). Not much else to see here.

It looks like the first proper presentation for this course is "Bitcoin: An Overview", which does a decent job explaining what is Bitcoin about, a number of things surrounding Bitcoin. It looks like a decent presentation without plugging 21 Computer too much. I guess that might be because a good chunk of it was presented by Belaji back in May last year at Sunnyvale's Bitcoin Job Fair when 21.co was still in semi-secrecy mode...

After that, we get linked to Lab 1 again, and we also see the first Self Test, including such important questions as:
  • "When you ran `21 status` to create your wallet and 21 account, what username did you select? (If you don't remember, you can run the following command at any time: 21 status)"
  • "How many satoshis do you get each time you run 21 mine? (If you don't remember, run the command again.)"
  • "Fill in your Stanford email and run the following command (if you get an error about your balance, run `21 mine` and try again): 21 buy sms +14084383755 'YOUR_EMAIL@stanford.edu'"
    • For which the only thing to check is " I sent the SMS message using the 21 CLI"

We're now at week two. Lab 2 - after a brief introduction to "Bitcoin Computing", we get a few step process of how to mine some bitcoins, buy and sell digital goods for bitcoin, and learn how to work with the bitcoin library (of course, all with the use of the 21 Computer). [Side note - we get have both the uppercase and lowercase "bitcoin" used to refer to the currency ("buy digital goods with bitcoin", "sell digital goods for Bitcoin") - keep it consistent, please.] Afterwards, we get some example of how to use the 21.co's library on how to develop some software-as-a-service.

After Lab 2, we get our Self Test 2, with the important questions of:
  • "Which of these is the main advantage of using off-chain transactions?"
    • After all, this wouldn't be a course on Bitcoin if we didn't focus on transactions happening outside of the Bitcoin network...
  • "What API calls can be outsourced using micropayments?"
    • With the answers being "Any remote API call", "Only calls that have a high per-use cost", "Only calls that depend on complicated technology, like Google Maps", "Only calls that use cloud services" and "Only calls that require registering for an API key before using"
    • None of the answers are particularly correct, and the question itself doesn't make sense - outsourcing API calls in the context of software development would be more focused on putting the API calling logic in some separate library, rather than as an external product...
  • "After you joined the market with "21 join", what was your IP address for the zt0 interface? (Instructions to get this are in the lab 2 document.)"
  • "Were you able to get someone on the Slack channel to buy your endpoint?"

And that would be it when it comes to what is available for public viewing so far.

Course critique


As someone who has written a Master Thesis on Bitcoin almost 4 years ago, I have mixed feelings about the course. My major gripe is that the course looks like some HEAVY native advertising in disguise. The course website makes you believe you would be working with Bitcoin, but in reality, you are working with 21 Computer and their proprietary libraries. This would be like wanting to take a course on the C programming language, but ending up with a course being on developing Windows Phone apps in ASP.NET as presented by Steve Ballmer. Sure, you would learn some similar fundamentals, but one would be a good basis for learning other C-based languages, a staple in the current industry, while the other would make you a Windows Phone app developer - not something many people aspire to really.

Similarly, since the course requires heavy use of the proprietary $400 device, I doubt many students not physically present at the university would be able to participate. If 21 decided to release some "student version" of their software that can be used on any device - it wouldn't be a problem, but I somehow doubt that would be the case...

That being said, as I stated before, the software itself seems to be quite feature-rich and the examples presented with the lecture wouldn't probably be possible to implement in a short time frame without them. Speaking from experience, one week is about enough to implement a web wallet from scratch if you're using Bitcoin Core for the first time - hardly as impressive as digital content delivery.

The strong emphasis put on mining and the use of off-chain transactions is a bit misleading if you want to learn about programming on Bitcoin. It is yet again 21 pushing its narrative of having mining available on every device and all of them being connected to their proprietary mining pool / shared wallet. It isn't representative of how Bitcoin works in its core, although it may be used as a good example perhaps later down the line of some alternative ways of handling bitcoins.

Lastly, when we're considering that two weeks of this 11 week course are focused on small hackathons, where the "Best projects get written up in Bitcoin Magazine" (from Lab 0), one might start to think that this whole lab exists not for the students to learn about Bitcoin, but for 21.co to get exposure, teach a number of students how to be completely reliant on its software for anything Bitcoin-ralated and possibly get some ideas / examples of what can be built with their hardware and software.

Conclusions


The Stanford Bitcoin Engineering course is a series of labs and lectures on how to use the 21 Computer, as presented by the CEO of 21.co. The majority of learning materials so far are reliant on proprietary software and hardware making it useless for anyone without the device. 

All in all, if the instructors of the course were more up-front about what they are trying to teach in this course I probably wouldn't be bothered by this so much, but as it stands, I can see it as nothing more than Stanford doing some native advertising of 21.co. I'm sure any student that essentially paid $1k+ to take the course will be grateful...

2016-01-11

Full Proof of Solvency - pondering Tether

Tether (currently in beta) is a fiat gateway allowing its users to transact in USD IOUs on Omni and internally in Tether's shared wallet. One of the core features the platform advertises is its 100% backing of the issued assets, coupled with frequent solvency reports. This used to be a big issue in the Bitcoin world a few years back, when MtGox, once biggest Bitcoin exchange in the world, became insolvent and shut down. After that incident, a few exchanges (1, 2, 3) started looking into creating proof of solvency to bolster consumer confidence in their platforms. Today I would like to talk about what constitutes a full proof of solvency, how Tether approaches it in a multi-platform system, as well as some potential pitfalls one might face while designing proof of solvency.

Proof of Solvency


A quick recap of what is a Proof of Solvency. In simple terms, its a way for exchanges and other companies holding their customer funds to prove their liabilities to their customers never exceed their cash and crypto reserves. It stands in stark contrast to fractional reserve banking, where by definition, there isn't enough cash or precious metals to cover all of the outstanding deposits. Historically, this is an important concept for Bitcoin - the Genesis Block created by Satoshi quotes a newspaper headline talking about a bank bailout.

Since we're dealing with cryptocurrencies, the modus operandi is always "trust but verify" - claiming that you have a certain amount of money but not having a strong, verifiable and falsifiable proof usually raises red flags.

Proof of Solvency can be broken down into two parts - Proof of Liabilities, wherein the company proves how much they owe their customers, and Proof of Reserves, where they prove how much liquid fiat and crypto they have to cover those deposits.

Proof of Reserves


Proof of Reserves is usually quite tricky for the Bitcoin exchanges as it often involves interacting with "the old financial world" - banks and their banking system. To prove they are solvent, an exchange would publish statements from their banks indicating how much money they have in a segregated account. As banks usually don't focus on creating cryptographically authenticated documents or balances, this is usually the hardest part of the proof to verify outside of a full audit.

However, when we get into the cryptographic world, things get a lot easier. An exchange needs only to state which addresses they own, what is their current balance, and sign the message with those stated addresses. This proves they have access to those addresses, and anyone can go onto the blockchain and verify how much money is really in them at all times.

The last part can also be very important - being able to verify the reserve balance at all times, or at least very frequently, is a lot more reassuring than one-off statements. After all, one could borrow the money for a day to create the proof, therefore misleading everyone.

In the Bitcoin world, one might try to similarly falsify the reserves by asking someone else with deep pockets to sign the proof of reserves statements, creating a false belief that those coins form the reserves. However, this problem can be mitigated with Voting Pools.

All in all, Proof of Reserves is fairly straightforward, at least when it comes to cryptocurrencies. Banks still need to catch up.

Proof of Liabilities


Proof of Liabilities can be tricky for the Bitcoin companies as it often touches on their customer records and databases.

If we're dealing with cryptographic IOUs, things are fairly simple - one only needs to point to the issuing address, count the total number of outstanding liabilities, and sign the statement. Anyone can verify it in real time, just like in the Proof of Reserves for cryptocurrencies.

When it comes to shared wallets and private databases, as is usually the case for many exchanges, the things get a bit more complicated. The companies usually don't want to reveal the balances of every individual account, and the dumps could get quite sizeable (back in 2011, MtGox's database leak was said to contain 61'016 user accounts).

There are a few ways of compressing the data, but the most popular one appears to be creating a merkle tree consisting of account IDs and balances. A single account-balance pair would be a tree leaf. One would then combine the two balances together and pair that with a hash combination of the IDs to form a node higher up the tree. This would continue until we would get one hash and one balance at the very end.

This merkle tree would be hard to fully verify without access to the full account list, but it would also be combined with another interesting trick - every user would be able to request an SPV-like balance branch connecting their account to the merkle root of the tree. If the exchange would fail to provide the branch, the balances would not add up, there would be some negative balances or the branch would not match the latest published root - one would have a cryptographic evidence of foul-play. Now if we only had something like this for the banks...

All in all, Proof of Liabilities is a bit harder than Proof of Reserves, unless we're dealing with pure cryptos once more. Combined with Proof of Reserves, we create a Full Proof of Solvency - the company in question is completely liquid, at least for the time being. Now, lets take a look at how Tether does this...

Tether


A good chunk of this discussion is based on a few conversations I had with the company last year. Since the product is in beta and some time has passed since I spoke with them last, this description might not be indicative of the final product if and when it launches. I bring this example up mainly because it raises some insights into a few important design choices for gateway design.

Tether at the moment is a gateway focused on issuing USD-backed IOUs. Those IOUs can be transferred both on the Omni network, as well as from inside of the Tether shared wallet. In the future, it would be possible to see Tether issuing similar assets on other Crypto 2.0 networks, such as Ripple or Ethereum.

We can see their outstanding balances on their transparency page. Here we come to the first design question - what does this number represent? Is it the balance on Omni, in the shared wallet, a sum of both or something else?

In case of Tether, the number corresponds to the assets issued on Omni. Their shared wallet balance is then a subset of that amount, and as I understand, balances on any other network like Ethereum would also have their own separate balances on the Omni network.

Since we're dealing with multiple networks, the Full Proof of Solvency would be dependent on all of them. In case of Tether, we would start with Proof of Reserves to figure out how much the company has in deposits. The number would be compared with Proof of Liabilities from the Omni network. If that passes, our job is still not done. Now we would use the Omni balance of the shared wallet as a PoR to compare against the PoL of that wallet, and use similar methods for any other connected networks.

The Proofs are valid top-down. If any part is invalid, anything relying on those Proofs are also invalid (which might be more relevant for bigger constructs, like exchanges relying on Tether).

Another interesting issue to consider would be the transaction lag when moving between the different networks. As Tether's top-level settlement network is Omni, which in turn is sitting on Bitcoin, the transactions that move assets between network would have to go over one of the slowest cryptocurrency network (at least in comparison to things like Ethereum or Ripple), which might not be ideal. Since Tether as a company already needs to provide Proofs for all of the network as well as its own wallet, it would make the most sense to make the fastest element be the top level, which in this case would be the wallet.

Conclusions


Full Proof of Solvency is an interesting concept that came out of the Bitcoin world in reaction to shoddy business practices of using fractional reserves at an exchange. It can be tricky to implement when dealing with non-cryptocurrency systems, but becomes trivial on publicly auditable blockchains. It would be interesting to see something similar implemented in a traditional bank...

2016-01-04

Positive and negative proofs in blockchain audits

As the old logical fallacy goes - you can't prove a negative, and absence of evidence is not evidence of absence. While for a long time this might've been true in various financial audits - you could only prove that some invoice existed, not that there were no invoices you missed - thanks to the blockchain technology things might change in the near future.

Positive vs negative proof


In general, we use positive proofs a lot in our everyday lives and in business. To create a positive proof, we only need to show that something exist - show an invoice of a transaction, a recording of a conversation, etc. Even in the Bitcoin Genesis Block Satoshi used a positive proof - a quote from The Times to prove that the Block could not have been created before 2009-01-03.

Negative proofs, while applicable in mathematics and some other cases, are often used in logical fallacies. If your goal is to prove for example, that there are no mice in the attic. You can easily disprove that theory with a positive proof if you find a single mouse there. However, searching the attic and not finding anything only proved that you have no evidence there are mice there, not that you had a proof there were no mice there. A subtle, but important difference.

Proofs on the blockchain


As in most cases, it is easy to create a positive proof on a blockchain. Point to a transaction paying for a particular invoice, if it is included in a block with 6+ confirmations, it's all you need.

Now, what if instead we are being audited and we have to produce an exhaustive list of all transactions we sent and received? It is possible, but we would have to do some preparations beforehand.

Cryptographic audit on the blockchain


First of all, we need to establish some way of uniquely declaring some data, saying "I am X and this is a message coming from me: ...". If we had something like government-issued unique digital signatures, that would be good enough. Alternatively, we could rely on some less infallible methods - notarized letters, tweets from some official handles, posting information on our website for everyone to see, perhaps sending the information to our competitors (if we try to lie about something, they would benefit from calling us out). Once we can prove that we as the person or a corporation were the authors of any given message, we can use cryptographic digests to prove any piece of data is coming from us, and coupled with embedding messages into the Bitcoin blockchain for timestamping (directly, or through Factom for example), we can create tight time bounds on when the data was created.

Why do we need all of this? Well, depending on how we use the blockchain, we will need to be able to create timestamped commits / anchors that we have to prove came from us.

If we only use one address on a public blockchain for all of our transactions, we have to commit to that address early on through the above scheme - "I am X, and I will be using the address 1PiachuEVn6sh52Ez7o6Fymvw54qvQ4RBm".

If we use multiple addresses on a public blockchain, it would be best if all of those addresses were derived from a single address in some predictable fashion. For example, we could use split-key address generation, multiplying the base private key by a sequential list of integers. This way, we can easily disclose the public key of the seed and allow any auditor to derive all of the other public keys, while still keeping our private keys safe. This way we only need to declare one address early on to create a full proof for the audit.

If the blockchain we are using is private, whether it is used only by us internally or by multiple parties, it would need to be anchored into the Bitcoin blockchain periodically to prove it wasn't altered in any way (Factom does this for example). Once we have that, we would also need a complete copy of the blockchain (or at least the relevant slice between two anchors) as part of the audit. If it is our internal blockchain, it would be analysed in whole, if it is shared - we would need to indicate which parts we used just like in the public blockchain scenarios.

Having gone through all of that effort, we can finally create our final data compilation for our audit, consisting of:

  • The entire block history in the slice of time we are analysing (say, all of 2010)
  • Whatever else is needed to prove the block history was unaltered. This can come in block header chain up to the newest Bitcoin block, simplified-payment-verification-esque branches of anchor transactions included in blocks, etc
  • Our original commits to the addresses we would use (if applicable), along with the necessary proofs that we committed to them at the appropriate time
  • Any relevant metadata we wish to submit (descriptions of which transaction was for what, etc.)


Finally, we would have not only a cryptographically verifiable proof that all of the transactions took place, but also have irrefutable proof of the time frame they took place in (we couldn't forge a few extra transactions from last year after the fact) and be able to prove that we didn't omit any piece of data - creating a negative proof.

The last one is possible because the records we are dealing with are cryptographically sealed (we can't alter the blockchain without invalidating its future, which would be evident), but also public and finite (we CAN iterate over every block and every transaction and check whether it is relevant to the audit or not). This way we not only provide every relevant transaction, but prove there are no relevant transactions we didn't provide.

Conclusions


Thanks to the advent of cryptography and blockchain technology with atomic, countable transactions, it is now possible to create an undeniable cryptographic provable complete audits. Hopefully this will help us avoid more audit fraud cases in the future...