 Derek says, do you see the danger of the side-chain market being dominated by a very few big companies? Since I just talked about side-chains, no, I don't. There are very few barriers to entry for this type of market, and there are very few advantages to being a big company in this particular space. Anonymous asks, could you please go more into the topic of side-chains? How would one go about creating a separate blockchain and connecting it to the Bitcoin blockchain in simple steps? Side-chains can be implemented in a number of different ways. The most common way is what is called a two-way peg, which is creating a special type of transaction in one blockchain, which locks up coins, which can then be referenced to unlock an equivalent amount, based on an exchange rate of a specific amount of coins, in the other blockchain. You can think of that as one form of an atomic swap, because that is really what it is. A bi-directional one would allow you to do a two-way peg, where you can move back and forth between the two. You take coins in one blockchain, you lock them up, and when you lock them up, you can then release coins in the other blockchain at a specific exchange rate. You can do that with a two-way peg that is implemented as an SBB-proof and some kind of multi-sig-smart contract, or you can also implement it with Lightning Network, where you send a payment into the Lightning Network on a payment channel, where you own Bitcoin, for example, and receive it on a payment channel where you have Ethereum. Now you can use Ether on Ethereum for whatever exchange rates you secured, and you can move money between them. Now you can implement functionalities where you seamlessly move coins to another blockchain without any intermediaries in a decentralized fashion. That is what a signed chain is. It is just another blockchain secured by a different mechanism, where you shift your coins and transmogrify them into this other coin. Anitta asks, what is liquid and which use cases do you see? Liquid is, particularly what Anitta means here, a solution offered by BlockStream. Liquid is a sidechain that uses a federated signing model, or proof-of-authority, as it is called. It is basically a sidechain that is not mined, but instead has a group of signers who federate their signing. They approve of transactions. Liquid has a couple of features developed by BlockStream, including confidential transactions, which allow the transaction amounts to be encrypted and verifiable, so that participants can transmit value without revealing what value they are transmitting. The primary reason Liquid was created, and the way it is promoted, is to be used as a back-end network that connects large exchanges and payment providers to each other. They can exchange transfers of liquidity without using on-chain space on the Bitcoin blockchain. Liquid is intended to tie together lots of large exchanges and payment providers, so they can use it as a back-end transport network. It is effectively the other end of the scale of the lightning network. If the lightning network is for decentralized micro-payments through millions of participants, Liquid is more centralized federated payments that are very large payments through a few very large providers. It is a commercial product, so BlockStream sells Liquid and manages the network and allows exchanges to use it for a fee. Liquid is a commercial product. It is open-source, but it is still a commercial product. Ironically, one of the big arguments about or against the Lightning Network is that it is somehow a trojan product by BlockStream, and they are sabotaging the scaling debate in order to get Lightning promoted, because they are going to profit from it. The irony here is that Lightning isn't a BlockStream product, it is an open protocol, which has multiple implementations. Secondly, Lightning undermines Liquid, which is the commercial product from BlockStream. The more successful Lightning is, the less need you have for Liquid. The bigger the Lightning network gets, the more exchanges can use it to run payment channels... between each other directly, without having to use Liquid, which is the paid commercial product from BlockStream. That makes that argument fall apart. In any case, this is a side-chains project. It is probably the first commercially available side-chains project created by BlockStream. Matt asks, what do you think of delegated Byzantine fault-tolerance as a consensus algorithm? Do you think this federated governance model can become effectively decentralized? I think the delegated Byzantine fault-tolerance consensus algorithm, as far as I understand it, is a form of signing, where you assign votes to different parties. In a federated model, you can delegate those votes to other parties. It is a signing versus mining algorithm. To me, the fundamental problem with consensus algorithms is that the ability of the parties to collude and reverse the history of the chain is there. With Bitcoin, one of the things to understand, with proof-of-work consensus algorithms, one of the important characteristics of a proof-of-work algorithm is, even if 100% of the miners decided they wanted to rewrite the chain from last year, they would still have to re-mine a year's worth of blocks. They would still have to produce proof-of-work to re-mine those blocks. They would still have to do that by consuming the same amount of energy, approximately, that they consumed over the past year. Mining chips have not gotten that much more efficient in the last year. Which means that they would expel all of that energy twice, assuming it is the same miners, but only get rewarded once by rewriting the chain. That means that even if 100% of the miners decide to rewrite the chain, they can't actually do that without expending a very large amount of energy. It would take a very long time. At current rates of difficulty, if they go back a year, it will take them less than a year to do it, because the hash rate has increased significantly over the past year. But not much less. Maybe it takes them six months to rewrite the chain. During those six months, they have to allocate 100% of the hashing power to rewriting the past without moving forward at all. All of this just to rewrite one transaction that is a year old. That puts a very effective backstop against attempts to alter history. That form of immutability to me is much stronger than simply assuming that the miners won't collude. In proof-of-work systems, even if the miners collude 100%, they have to expend the energy and produce the proof-of-work. Otherwise, none of the other nodes in the system will accept these blocks as valid. They cannot rewrite the chain simply by decree, by fiat, you might say. In federated governance systems where signing has replaced mining, delegated Byzantine fault tolerance, and various forms of proof-of-stake perhaps, there is nothing backstopping them. If 100% of the signers collude, and in some cases not even 100%, maybe only 50%, 51% of the federated signers agree between themselves, they can go back and rewrite everything since the Genesis block at zero cost. It doesn't cost them a thing, it doesn't take them more than a few seconds to recalculate the entire blockchain, and arrive at a new present with a rewritten history that no one can independently and objectively see that it has changed. If a new node joins the system, they can't tell the difference between a history that is the original history, or the new changed history, they both look the same. You can't do that in proof-of-work. A new node can join the system and immediately knows which history is true. It's the one with the most proof-of-work behind it, fault tolerance, or some other federated consensus algorithm. All of the well-known, named federated signers of that model receive a subpoena that says, we would like you to please rewrite and erase this transaction that funded the WikiLeaks organization, that funded whatever organization in the past, and remove that transaction. That transaction never happened, remove funding from that organization. Under a court order, they would have to comply, and more importantly, it's not just a matter of having to comply, they would be able to comply. The same scenario in a proof-of-work system. You hand all of the miners, if you can find them, a subpoena and say, change this transaction. They simply cannot, without expending six months of energy. Most courts would not even approve under a variety of legal concepts. That doesn't mean federated signing, governance models, delegated Byzantine fault tolerance, things like that, are not useful. They are just different. They are not immutable in the same way the proof-of-work is. If you don't need immutability, what you are trying to do is have a consortium of banks that don't trust each other, be able to do wire transfers to each other. You don't mind that perhaps the government can compel them all to change the transaction in the past and rewrite the history, then that's a perfectly good system. In that case, you don't need a blockchain. In fact, if you look at it, most of the systems that are moving in that direction, where they have delegated signing, they don't use a blockchain. They don't need a blockchain. They can use something else, a hashgraph, a tangler, a series of linked transactions without blocks. You don't need to aggregate things in blocks if you don't have proof-of-work. You don't need to have a system like that. You can basically sign every transaction independently. It's a more efficient system. At that point, you are not in the blockchain space. You are in the distributed database space. That's fine. It's just not what I'm interested in.