Next we're going to talk about some of the ways that Bitcoin and the altcoins in this ecosystem interact with each other. Al the altcoins and Bitcoins, in a sense compete with each other. They have rivalries and we've looked at some of the ways that they change in relative value and participation over time. It's also possible for them to interact in a more hostile or harmful way. So, for example, given the way that the proof of work mining system works, it's possible if you have a lot of mining power to conduct various forms of attacks on BitCoin or on an altcoin using this mining power. Now, in particular, this means that if there's a very large entity on a large network such as Bitcoin, for example, a powerful single miner or a large mining pool. This mining entity would have a very large power relative to the participation of a very small coin that uses the same proof of work puzzle. This means that a large miner on a Bitcoin network could fairly easily attack any small altcoin if it wanted to. Now attacks like this have actually happened before in practice. There's a well-known story of an old coin called CoiledCoin, which was quite small, during the time of 2012, and one of the large mining pools, Eligius in Bitcoin decided that CoiledCoin was a scam, and an affront to the crypto currency ecosystem, and a very bad idea. And so the director of this Eligius pool pointed his mighty resources at CoiledCoin and launched an attack. This attack involved mining a lot of blocks that reversed days worth of transaction history in CoiledCoin, reversing the users transactions. And as well as mining a long chain that had empty blocks containing no transactions at all effectively making a denial of service attack. CoiledCoin users weren’t able to make any transactions during that time. After a fairly short time of the siege, all of the users of CoiledCoin had left and moved on, and the altcoin doesn’t exist anymore as such. Similar attacks have also been conducted on other altcoins, such as TerraCoin and WorldCoin most recently. Although, in these instances the attacks were short and the altcoins did survive at least to some degree after the attack. I wanna talk now about a technique called merge mining, which I mentioned is a very clever technique and this involves a way that mining on two altcoins can be combined. Now ordinarily mining on an altcoin is exclusive to a particular altcoin. Each hash you compute, each puzzle solution attempt you make, has a chance of either being a solution for one altcoin or for a Bitcoin, but there's no chance of it being both. You can divert some of your mining resources to mining on one altcoin network or on another. You can change it over time, or you could split your resources, but at any one time your hash power has to be divided from its total in this sense. Now this is an obstacle to bootstrapping. If you wanted to launch an altcoin, and convince Bitcoin miners to participate in your network, the Bitcoin miners would have to stop mining Bitcoin while they switch to your altcoin. So what if were possible to mine both blocks on an altcoin and blocks on Bitcoin at the same time without having to sacrifice either. Just to illustrate this, the reason why each puzzle solution attempt has a chance of being either a Bitcoin block or an altcoin block is because each hash you compute is over a string. And the string contains, in the case of Bitcoin, the hash of a previous block, the merkl_root of a tree containing a bunch of valid Bitcoin transactions and you have to compare it to Bitcoin's target difficulty in order to see if it wins. Now for a basic altcoin, that would be just a fork of Bitcoin's code with a different genesis block but no other changes, so the same mining puzzle. Each puzzle attempt for this altcoin would be a hash over a string including the hash of a previous altcoin block. A merkl_root of altcoin transactions, which would be different than Bitcoin transactions, and you'd compare it to the altcoin's difficulty target, which would be different than Bitcoins as well. Each hash you compute either has the string of the top type or the string of the bottom type and there's no way for a single hash to give you information about both. So Merge mining is a way of designing the mining puzzle for an altcoin, such that every puzzle attempt in the altcoin is also a valid puzzle attempt in Bitcoin. Now the secret to this is that, there are places where a miner can put data in a Bitcoin block that they're mining on, and they can put arbitrary data that isn't validated by the Bitcoin network and its up to them. So the approach will be to make the important data like transactions and previous block cash for the alt coin embedded in the Bitcoin block in this location. More specifically, one of the places in Bitcoin where you can place arbitrary data is in the scriptSig of the first transaction in the block, the coin-based transaction. All right, the scriptSig field isn't checked at all by Bitcoin so it can be arbitrary data and it would still be a valid Bitcoin block. So the approach for Merge mining is to, put all of the data that you need for your altcoin encoded in the scriptSig. This includes the previous block hash for you alt and the merkl_root of some transactions relative to your altcoin. Now then the Merge mining puzzle is to compute the hash over the string including an entirely valid set of Bitcoin block data and just happens to contain the altcoin data. And once you compute this one hash, you can compare it even to a different difficulty target for the altcoin that's typically less than the difficulty in Bitcoin. Now notice that you can only compute one hash, and yet it still has a chance of being either an altcoin solution or a Bitcoin solution, or even both. Now what we've just illustrated is a way of Merge mining an altcoin onto Bitcoin, but it's possible to generalize this so that you can Merge mine any number of altcoins at the same time as well. Mining participants in Bitcoin don't have to stop mining Bitcoin in order to also merge mine on a altcoin. On the other hand, it also makes this cheaper for attackers. So for example, the CoiledCoin attack that I mentioned, CoiledCoin was a merge mined altcoin. This meant that for a Bitcoin mining pool to attack CoiledCoin, it doesn't even have to take the opportunity cost of stopping mining Bitcoin while it launches this attack. Another problem is that, miners don't have an incentive directly to validate transactions thoroughly if they believe that the chance of there being an invalid transaction published is fairly low, or if they delegate validating transactions to someone else, such as the leader of a mining pool. So while it might not be too expensive to fully validate transactions for a single network if you wanted to merge mine on a very large number of different altcoins it would be expensive to thoroughly validate transaction on all of them. Therefore merge mining makes it more likely that only a smaller number of miners would actually perform transaction validation. Many large mining pools in Bitcoin actually provide the service of helping you merge mine many compatible coins at once. So for example, the largest Bitcoin mining pool, GHash.IO or Gigahash.IO allows you to simultaneously mine on Bitcoin, Namecoin, IXCoin, and Devcoin. So these become the most popular Bitcoin compatible merge mined altcoins. Next, we’re going to talk about a way that transactions in two unrelated altcoin block chains can actually be related and interdependent to each other. In general, a transaction on one altcoin is entirely independent of and as no way of referring to a transaction that happens on some other altcoin's transaction history. However, there is a way to do something to this effect using a technique that we've discussed previously. Now the motivation here is, suppose that Alice has one Bitcoin, and Bob has one Litecoin, and they would like to trade with each other. This means that Alice could make a transaction on the Bitcoin network that transfers her BitCoin to Bob. Bob could make a transaction on the Litecoin network that transfers his Litecoin to Alice, but they have a problem if they don't trust each other, which one of them's going to go first? If Alice sends her Bitcoin to Bob, Bob might not make a Litecoin transaction and Alice would never get the Litecoin. Bob would end up with both of them. What you would like is for an atomic transaction property where either both transactions, the Litecoin transaction and the Bitcoin transaction, both complete, or neither of them do. Now the way that this technique is going to work, it's going to involve a couple of different steps. In the first step Alice is going to generate a secret key x. She's also going to compute the hash of x and we'll call that hash value h. Alice is going to start by creating a pair of transactions. The first one is a deposit. It's a Bitcoin transaction that, deposits for Bitcoin such that the Bitcoin can be spent in one of two ways. One of the ways is for Bob to take it, this way is colored in green on this side. It only requires Bob's signature, but it also has to involve publishing the secret value x, such that the transaction can check that indeed the hash of x is actually h. All right, and this is the way of claiming the Bitcoin that'll happen if the protocol completes. Now the other way of claiming Alice's Bitcoin requires a signature from both Alice and Bob. Now Alice generates this deposit transaction, but she doesn't publish it yet. First she generates another transaction refund, which refers to deposit, and it contains both Alice and Bob's signature, and it is time locked to a time in the future which we'll call T+2. Now once she gets Bob's signature on this refund transaction, she can publish the deposit transaction. Now the important conditions here are that, if Bob is able to learn the secret value x before time T+2 and he's able to take Alice's Bitcoin, this is what happens when the protocol completes normally. On the other hand, if Alice never reveals her secret x, then she knows that she will be able to reclaim her refund at time T+2. Now, the second step involves Bob also creating a similar pair of transactions. Bob's going to create a DepositB transaction which contains his Litecoin and his Litecoin can be spent in one of two ways. Again, one way is, in the ordinary course of the protocol, requires only Alice's signature, so it will transfer the coin to Alice, but it requires Alice to publish and reveal her secret string x, which again is checked to the hash value h. Now, Bob creates the deposit transaction, but doesn't publish it immediately. First, he creates his refund transaction. He has to collect Bob's, his own signature, and Alice's signature as well, and this transaction is time-locked to a time T+1. And this means that this transaction Signed by Alice by it isn't valid until some time after T+1. Once Bob has Alice's signature on this timelocked transaction, he's free to publish the DepositB transaction. Now the important qualities here are that, if Bob is able to learn the secret value x because Alice reveals it before time T+1, then Alice is going to be able to take the Litecoin from this transaction. This is how the protocol completes normally. On the other hand if Alice never revealed x, then Bob can claim his refund at time T+1. So putting this together, after all of the deposit transactions are published Alice reveals x and she creates a transaction that takes the light coin from Bob, but to do so she has to reveal x. So, when Bob learns x he can create the transaction that takes Alice's Bitcoin and now the transaction is completed. Now, the important logic about why this is secure is that, if Alice doesn't reveal x then Bob gets to take his refund at time T+1. If Alice takes Bob's Litecoin, then the only way she can do that is if she does reveal x before time T+1. All right, and in any case that Alice reveals x before time T+1, Bob will learn it and have time to take Alice's Bitcoin before time T+2, the final deadline. This guarantees that either both transactions complete or neither of them do, which is the property we wanted out of this. So this is a clever transaction protocol. It has the potential to provide liquidity between all the coins in a secure and decentralized way. On the other hand, this technique hasn't been seen in the wild, there are a few reasons for this. The disadvantages of this protocol are that, it requires many transactions, each of which typically has to carry a transaction fee, or at the minimum, take some amount of time to complete. Even though you're guaranteed that either both transactions complete or neither of them do, there's still a risk of denial of service. If you try to do this protocol with a random stranger they might waste a lot of your time by starting protocols that end with everyone having to collect their refund at the deadline. But because of these disadvantages almost all exchanges between altcoins are done using large centralized third party exchanges or ad hoc transactions like local Bitcoin exchanges. So to summarize so far, we talked about Bitcoin and its role in the context of a large ecosystem of hundreds of altcoins. These altcoins compete and interact with each other in a variety of ways. Some co-operative and some hostile. We've also looked at two specific ways that altcoins can interact at a technical level. We looked at Merge mining, which is interesting because an altcoin can support merge mining without even explicitly having support from Bitcoin. Not only does Bitcoin not have to change for an altcoin to merge mine on it, but it isn't even clear what Bitcoin could do to prevent merge mining like this from occurring. Similarly you can use the hash commit technique in order to have interdependent transactions even though they occur on entirely separate altcoins that have nothing to do with each other directly. This is possible with the existing script language that essentially every altcoin supports.
