CHAPTER 7
Contracts and Tokens

This is a short chapter that covers the ability of some cryptocurrencies to encode contracts within a transaction. This feature, especially of contract-based cryptocurrencies such as Ethereum, has led to companies releasing tokens based on the blockchain, which hold the promise of some reward when the business performs well.

An investigator may be faced with blockchain-based contracts that have been involved in some fraud or theft. Initial Coin Offerings (ICOs) may be fraudulent and need investigating.

Contracts

A transaction of money, even on a blockchain, is essentially a contract. For example, if I decide to purchase a lemon drizzle cake (in the café I'm currently sitting in), both sides agree on a swap of a certain value for the drizzle cake. This would be the case with any transaction of goods, services, or generic agreements. Interestingly, a contract can also have a “promise” on one or both sides of the agreement. An example of this would be a marriage contract. Although goods and services are not traded, marriage is essentially a contract with an embedded promise in the vows and marriage certificate.

Bitcoin

Bitcoin and its derivative cryptocurrencies carry the ability to embed small amounts of data, whether code or text, to act as a contract. Bitcoin's ability to have multi-signature transactions means that both parties can sign the transaction, and it's then on the blockchain forever. Of course, this process is not without cost, because a small amount of bitcoin would need to be included in the transaction to cover the miner's fee.

In 2010, Satoshi Nakamoto said that he designed into Bitcoin the ability to carry out multiple contract types including escrow transactions, bonded contracts, third-party arbitration, and multi-signature contracts.

Bitcoin uses the simple stack-based language that was discussed in Chapter 4, “Transactions,” but only a very limited number of operations can be done. The standard script for a pay-to-hash transaction is

<sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

This takes the public key and duplicates it, hashes it using SHA256 and RIPEMD-160, checks that the inputs are equal, and then checks that the input signature is valid. The OP_CHECKMULTISIG at the end of this script checks that the supplied signatures on the transaction are valid signatures from the specified number of public keys. This enables multiple public keys to be used to “lock” the transaction.

A number of ways exist to create a contract on Bitcoin. One way uses two transactions: the contract and the payment. If each of these transactions requires signing by both parties involved in the contract, then trust can be achieved.

Another type of contract uses a feature of the script operation nLockTime, which can be used to delay a contract from being included in the blockchain until a specific time or block height is reached. If the nLockTime value is less than 500 million, it is interpreted as a block height number, and if it's over 500 million, it is then understood to be a UNIX timestamp. This operation means that the transaction will not lock until the specified height or time is reached. This could be useful for something as simple as a son wanting to send money to his parents on their wedding anniversary. He would just set the UNIX timestamp locktime to the anniversary date, and the transaction will not happen until then.

nLockTime can also be used in contract transactions to ensure that the contract or payment is not encoded on the blockchain until a specific point in time.

Bitcoin has not been used significantly for complex contracts to date, but that could change in the future.

Ethereum

Ethereum is different from a Bitcoin-type blockchain in that each transaction is essentially framed as a contract. Although Ethereum will only allow a transaction from one address to another, a contract can call multiple transactions. Ethereum also has a considerably more complex scripting language called a Turing-Complete, which can be used to design a program that can perform any computation.

With Ethereum, the process of enabling transactions to complete only when certain conditions are met is straightforward. For example, imagine a gambling site based on Ethereum where bets are placed on the blockchain and payment is made in either direction when the conditions for a win or lose are met. Another example might be encoding a transfer of sale for a car or a house. Deeds of ownership could never be lost or destroyed, because the proof of ownership would exist on the blockchain in thousands of places simultaneously. That is assuming, of course, that you do not lose your private key, which would remove your ability to prove ownership of the contract.

Essentially, a blockchain like Ethereum could be used for just about any type of contract. An interesting example of this is the first wedding contract that was made available for Ethereum. The code is available on GitHub (http://bit.ly/2zgx1BF) and can be edited it to change key elements such as the names of the betrothed and add any other stipulations. Using an Ethereum transaction, the betrothed couple simply calls the contract and they both sign it with their Ethereum public keys. You can see this in use at the Ethereum contract address 0x5657b8d985be88af0f3d2dc064e2db784071ae1c. Just enter it into etherscan.io and click the Read Smart Contract tab (see Figure 7-1).

Snapshot illustration showing a marriage contract on Ethereum.

Figure 7-1: Marriage contract on Ethereum.

A blockchain such as Ethereum could also work to improve resilience where trust is vital. Consider, for example, a modern car that regularly receives software updates over the Internet. Imagine if a car could be hacked by a nefarious person, perhaps intercepting the over-the-air update and adjusting the code so that the brakes are somehow turned off. How could this attack be intercepted? The software could be hashed each time the car is started, and the value could be checked with the main server. But what if the server was hacked? A blockchain would make this more resilient. If the developers roll out a new software update to the car-based blockchain via random peers, there would not need to be a single update server, because the software would be sent to a random number of cars on the network. If all these cars were nodes on a peer-to-peer system, they could send the software update to each other and then, when a car is started, the car could check the consensus of all other cars on the network to ensure that the majority agreed with the hash of the software version being run. The contract would just need to state something like this:

On car start:

  • Does my checksum agree with the consensus on the blockchain (which in this example would be every other of this model car in the world)?
  • If yes, allow the car to be driven.
  • If no, notify the manufacturer that something is wrong.

This type of contract could work with almost anything that requires updates to help ensure that updates from the factory are not intercepted or hacked in any way.

Tokens and Initial Coin Offerings

Ethereum is being extensively used to launch funding campaigns for new products and services. This involves creating a type of contract called a token. These tokens are offered for sale on the Ethereum network in exchange for ether and represent the hope that the company or service will become successful and then the token can be traded at a higher value than the original investment. This is very similar to a share offering, except the token does not represent any ownership of the company and is not yet regulated by any legislation or body, although many countries are looking to regulate in the same manner as share offerings.

The standard token is called an ERC-20 token. The owners of the company wanting to raise funds will assign themselves a number of tokens, for example 100,000. They will then launch an ICO or an Initial Coin Offering where people can purchase tokens at a set rate. Often a purchaser will have some free service or reduced price product offered as a benefit of purchase.

The problem is that although some solid business plans are available for some of the companies offering ICOs, many—I would suggest a vast majority—are at best tenuous and at worst, fraudulent.

To illustrate, looking at some of the ICOs coming up at the time of writing includes a system based around a blockchain for finding return loads in the shipping industry or to enable non-technical people to create Ethereum contracts. Those are interesting applications of blockchain technology and one can see the potential. However, others include “Funding the ultimate board game with free access for users” or “A platform on the blockchain that reinvents cyber security.” What does that even mean? Reading the blurb is equally confusing and doesn't tell me at all how they will redefine anything except how to write a business plan that doesn't actually say anything.

At the extreme end of this are ICOs that are designed to be fraudulent, taking investments for a business idea and then liquidating the money without providing the service. I believe that this will happen often in the coming years without stronger legislation.

To see an example of an ICO, browse to http://authorship.com/contribute/. I am not suggesting anything wrong with the validity of this offering, apart from explaining that it's a blockchain-based book publishing system (see Figure 7-2).

Snapshot illustration of an Ethereum blockchain presenting the Authorship Token sale.

Figure 7-2: The Authorship Token sale.

We can use the Ethereum blockchain explorer etherscan.io to search for those who invested in Authorship tokens. Browse to etherscan.io/tokens and search for the word “authorship.” Here you can see the address of the token contract and records of the transaction of tokens being transacted with buyers (see Figure 7-3).

Snapshot illustration of a list of purchasers of Authorship tokens.

Figure 7-3: List of purchasers of Authorship tokens.

If you click any of the transaction hashes you can see the details of the token transaction. The first thing you will notice is the tag that identifies this as an Authorship token. You will also see that no Ether was transferred, just the contract code that makes up the token (see Figure 7-4).

Snapshot illustration showing the hash of the contract for the Authorship Token.

Figure 7-4: The hash of the contract for the Authorship token.

By clicking the contract address, you are able to see the Contract Source and Read Smart Contract, which enables you to see the token name, the total supply available, and the address of the owner (see Figure 7-5).

Snapshot illustration showing the details of the Authorship token.

Figure 7-5: Details of the Authorship token.

As with any blockchain with a reasonable anonymity, it would be very difficult to trace the owner if no other information were provided. This can make it quite straightforward for a fraudster to set up and market a token for the sole purpose of eventually stealing the money. I am not in any way suggesting this is the case for Authorship, but investors need to make sure to do their homework.

I cannot put it any better than Kevin Roose did in the “Is There a Cryptocurrency Bubble?” article that he wrote for The New York Times (http://nyti.ms/2www4jr). Here's a brief extract from that article:

Even though tremendous risk exists, ICOs are continuing to be wildly popular when a company manages to catch investors' eyes. Let's hope the majority of them are not just snake oil.

In September 2017, the U.S. Securities and Exchange Commission charged what is thought to be the first companies perpetrating an ICO fraud (see http://bit.ly/2x3p2mt to read more about this event). Interestingly, the fraud itself was fundamentally that the business owners were misrepresenting the investments they were making and the fact that the coins being offered were not backed by real estate as was advertised. The lesson here for an investigator is that the investigation actually had little to do with cryptocurrencies or blockchains and more to do with traditional lying and misrepresentation—it's just that the technology in the back office was a little different. I mention this because sometimes we get hung up on the technology when, in fact, we are just investigating a crime that's really been around since the dawn of time. Or at least since 300 BC, when a Greek sea merchant named Hegestratos took out a type of insurance policy to transport corn but decided to scuttle his empty boat and run off with the money and the corn. He drowned trying to escape his sinking ship. But even 2000 years ago, the crime was just simple fraud—in many ways, no different from any fraud today. In recent years, I have seen many Internet-based crimes that are not investigated due to a lack of technical knowledge on the part of the investigator. However, sometimes you just need to look at the basics of the actual crime being committed and worry less about the mechanics.

Summary

The long-term future of the blockchain is possibly not just in its role as a currency mechanism, but also as a way to create and store contracts between parties for virtually any reason. Bitcoin can do this already to a limited degree, but by using Ethereum, a person is able to construct and store complex contracts. This ability has led to the rise in ICOs (Initial Coin Offerings) as a way to raise money. As I discussed in this chapter, some of these are legitimate attempts to raise capital and others are, perhaps, fraudulent. An investigator should make an effort to understand the technologies involved but not forget that the crimes are essentially simple and no different from other thefts or frauds.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.129.217.5