EB65 – Adam Back & Greg Maxwell:

people:

• Sebastien Couture
• Brian Fabian Crain
• Adam Back (adam3us)
• Greg Maxwell (gmaxwell)

Brian: We are here today we have Adam Back and Greg Maxwell, to anyone who is following bitcoin and bitcoin's development, you will have probably heard of these two gentlemen. I was fortunate enough that the first time that I went to a bitcoin conference at the beginning of my involvement in this space, it was in Amsterdam 2013 and I somehow randomly ended up having dinner twice with Adam which really was super fascinating talking to him about bitcoin, and so I'm really exciting to have them on today, especially since we are going to have a chance to talk about a project we have talked about many times on this show before, with different people, which is sidechains, because sidechains I think that everyone is in agreement that it is one of the more interesting projects in the space, and a lot of people have many questions about it. So today we will get to ask those.

Sebastien: I would just like to say it's been so long since we've done a bitcoin episode, we've lately been talking about bitcoin 2.0 stuff and decentralized apps and all these other interesting things, but it's nice to come back to the roots, good ol' bitcoin. Right?

Adam: Maybe bitcoin 1.1?

Sebastien: Yeah, let's talk about bitcoin 1.1.

Brian: Can you guys for those who haven't heard aobut it, or for those who have but sort of, remember what sidechains are about? What is the main thing that sidechains are trying to accomplish?

gmaxwell: So what sidechains are trying to do is address a sort of fundamental limitation that we run into in the bitcoin space. So the whole bitcoin network and bitcoin system works based on consensus. It's this big distributed cryptographic infrastructure that produces a currency as a side-effect of all of the computers coming together to agree all on exactly the same thing. This is quite complicated to get right. Most importantly, it means that we all have to be doing the same thing. Having to do the same thing is really bad for innovation, because basically it ends up being that you got this enormous difficult to change distributed system that has to decide on the behavior for everything that is going on inside the system. So if you want to make an enhancement or add a feature or do something interesting with your bitcoin that the system doesn't support, you're kind of stuck and you have to convince the rest of the network to add functionality. This is a difficult way to develop software, and it's politically limiting because users shouldn't have to ask the network for permission, even if it's a decentralized network, for different ways of using their bitcoin. So the obvious alternative to sidechains is to well let's just start a new cryptocurrency for every kind of application, every new feature, every new functionality, maybe per every user, and it works from a technical sense, but it doesn't necessarily make economic sense, because money has value in its scarcity and starting up a new currency for every new feature that you want to deploy does not make sense. And there's also other natural stopping points, why won't someone fork foocoin to create barcoin, and at the end of the day a bystander looking at this from the sideline might say well I'm not going to get involved in this because it's constantly getting replaced. The whole idea of sidechains was to come up with a general cryptographi protocol, to come up with a separate system where you transfer the bitcoin values that you already have to and from that system. You can move your bitcoin into another chain, you can transact, gain features and capabilities, and then move your coins back if you want to transact with someone not on that chain. Hopefully this would unlock innovation and allow the network to not act like a gatekeeper.

Sebastien: This is kind of a dividing issue in the community. Some people are for it, others have come out against it, and you know there are different arguments on each side. Why do you think this is such a dividing issue?

gmaxwell: So maybe I live in a bubble, but I have seen some vocal negative voices some of which are concerns based on things like, any change is a potential risk, which is a concern that I share, and it's actually a motivation for sidechains, because I want to stop most changes to bitcoin. There are other people who are quite transparently and you know open about the fact that they are concerned because they have investments in competing systems, and sidechains might make bitcoin more competitive with them. And maybe I live in a bubble, but I haven't seen any actual genuine controversy in the technical circles about this. I think that the view of most of the hard-core technical people that have been involved in contributing to the bitcoin space, has been "yeah this sounds interesting if it works, that's great, let's see how it works out". I would say cautiously positive rather than controversy at least from that camp.

Brian: I think a lot of the concerns are around the security, and we will dive into that in depth today. One thing that I find really astonishing about the sidechains idea, we talk about bitcoin as a network, and the little b as the value. And then you can say, those two are kind of independent, .. have people who develop on top of the network. I think it is separated the other way, we keep using the bitcoin monetary value, but we separate that from the network, or at least to some extent, I think that's a really amazing way to look at this.

gmaxwell: I would say that for the purposes of a money, money wants to have a monopoly. Money works better when it grows with a strong network effect, and money wants to have few monies. We get better interop with fewer monies. But when it comes to actual mechanisms of transmitting money, we actually want the greatest diversity possible. I mean, the way that I transfer money between myself and you should be whatever we pick, and nobody else should have a say in that.

Brian: Yeah, absolutely.

adam3us: Well, I have heard some people recently say that they like the blockchain, but they don't like bitcoin. That's not actually a technologically grounded statement because bitcoin is a tokenized representation of seucrity in the blockchain. And a blockchain is a distributed data structure that provides security, and so if you take the currency out of it, you collapse the incentive structure of it and you have nothing left. I don't think that particular side comment, which I have seen in the media a few times, I don't think that's actually correct. That's really a side track and not directly related to what you said.

adam3us: Going back to what Greg said about being able to extend bitcoin, when I first started getting interested in bitcoin on a technical basis, I got some ideas and there's a lot of ideas floating around for what people would like to do with bitcoin. Some of them are quite direct, simple and elegant and useful things to do with bitcoin, to fix limitations or fix other aspects. Had we known these at the beginning, we would have implemented bitcoin in a slightly different way. One example is for the value of a transaction to be part of the same data, so because that's absent, for the kind of offline bitcoin wallets, they need to have some transaction history to see how much money they have. If you have the value in the transaction, it solves the problem. What happens to them if they don't do this extra work, they get tricked into spending all of their money into a fee transaction or something. If the value of the money being spent was in the signature, then the blockchain itself would enforce that. If we could do a hard-fork it would be easy to do that, but hard-forks are difficult to do in a consensus network, it's a live network, there's really no beta protocol. I had some other ideas, like being able to encrypt the values so that you could still get blockchain validation without leaking confidentiality, which I think is something businesses would like to have to do share trading or to do transactions at scale. So I got excited about if we could get this or explore adding it to bitcoin, but I came to understand that it is quite challenging or demanding to do that. So I became interested and started to focus on how to have a general extension mechanism for bitcoin, and that's where the one-way peg came from, and then there was the two-way peg mechanism that gives a soft-fork to bitcoin to enable so that you can have a blockchain without effecting this software risk factor. If you look at internet history, when the world wide web and http 1 point nought, there was lots of rapid innovation on the protocol, and some people draw analogies between bitcoin and the web and internet and so on, and if we look at bitcoin versus web technology at what people are assuming is a similar earlier phase of adoption, there was way faster experimental development going on, and bitcoin can't directly accomodate that rate of change even though the demand is there. That's not to say that bitcoin core is not changing, lots of things are changing, but they are changing in a focused conserving consensus-conserving way, bug fixing priority first, and less on the nice to have next generation ideas, because you have to control software risk you have to procede in small carefully validated steps or something like that.

Brian: I would suggest that we dive right in before we go into some of the, maybe more of the big picture issues, let's dive into one of the main criticism that have been made of sidechains. You guys explained before an approach that turned upside the idea of sidechains, so I think this is going to be interesting from that perspective. One of the main criticisms has been that if you have a thousand different sidechains and a lot of them have only a small amount of hashing power mining that chain, it would be very easy and basically free because it's merge-mined, for any mining pool to attack any smaller sidechain, so it's not really clear how the security of the sidechains could work. So essentially the risk scenario would be that somebody holds coins on the sidechain, they use those coins to get back the coins that have been suspended, to move money in the sidechain, and then they would go back and do a 51% attack and essentially they would be able to steal money from other people in the sidechain.

adam3us: There are two phasess of the sidechain idea. There is a loosely coupled phase, where the bitcoin network is a SPV client of the sidechain. If you look at the existing security limitations of a SPV client on the bitcoin network, a majority hashrate of miners could convince you that you have received money that you haven't.

gmaxwell: Sidechains provide a different security model than bitcoin by itself. The differences are subtle. in the long term, the bitcoin miners can attack the bitcoin system, and they lose out on the transaction fees that they could have received otherwise. The same is true of sidechains. The difference is sort of the magnitude of what can happen when you attack. So in bitcoin, miners who attack the network will lose out on the transaction fees but all they can do is double spend, unless they do a really long attack where they rewrite a big chunk of the chain, in which case they can also steal coins. So there are some subtle differences here. In the case of a sidechain, it's a SPV client like electrum or multibit or the common wallets that people use today, what sidechains do is they trust the miners mining on the sidechain, just like the spv clients trust the miners implicitly. A lrarge hashpower attack that steals coins on the sidechain could steal those coins and not just double spend them.

adam3us: You may be familiar with soft-forks. There is a way that has evolved since bitcoin started to introduce software changes, it's backwards-compatible. I will outline this briefly. The idea is that if you look at the network, there are multiple versions of software. Let's say the current version of software there is an operation code called OP_TRUE, and basically if there is a bitcoin transaction with a bitcoin script with OP_TRUE it means that anyone can take your coins. Whoever can get to the miner first can get the transaction verified and validated by the miner, and they will receive the coin. In practice that would mean the miners take the coins. People don't tend to send OP_TRUE transactions to miners because they know that the miners will take their coins. But the fact that the OP_TRUE transaction can exist and can have parameters after it that would be ignored, is the kind of seed of backwards-compatible upgrade mechanism that can be pushed out to the network. How that would work is that, say we want to introduce a new type of transaction with a particular feature. So we will put OP_TRUE and some parameters that describe the transaction, or maybe we are introducing a new signature algorithm like Schnorr signatures. This is kind of crude, some technical people may be cringing, but I just want to illustrate the point. So this signature is in the extension field, and the miners that have or are interested in supporting this feature, look at the extended information and they have a narrow interpretation of what OP_TRUE means, it doesn't mean anybody can take it, it means to them that anybody can take if they have this Schnorr signature that is listed in the extended opcode, right? So basically once the mining of this, once the number of miners that understand this extended interpretation has reached a decent number, say 95%, then it can be turned on and the miners can reject attempts to take that coin by others who don't understand those extra rules, because they have ignored the extended meaning after it. The miners would censor that transaction.

gmaxwell: So this soft-fork mechanism has been used several times, such as by BIP16, BIP34, BIP30. We have used it to fix bugs and upgrade the bitcoin system in the past. It's nothing new. It's a mechanism that allows us to extend the system in a way that is backwards-compatible.

adam3us: So the idea of sidechains is to allow innovation and upgrades etc. If you look at the current way that the bitcoin system upgrades itself, it's a soft-fork mechanism. And if you look at what's going on in the network when a soft-fork is in effect, there are maybe 2 or 3 kinds of users. There's the miners who have upgraded to the version of the protocol that understands the extended meanings, there's a small number of miners that haven't upgraded yet, and the hashrate majority rejects the small miners tha tdon't understand the upgrade, and hten some number of users that haven't upgraded. As a user with a coin that hasn't upgraded, you can receive a transaction from what looks like what was formerly an OP_TRUE address, and you could say well that's lucky and anyone could spend that to me, that's lucky. But what's really going on is that some new feature allowed that. So if you look at it from the point of view of the numbe rof users that ewre still on the old rules, then they are susceptible to a 51% attack. Anyone could grab an OP_TRUE transaction and pay it to themselves. And the people who don't understand the protocol upgrade would suffer that security downgrade. So a sidechain is basically the same thing. It's more modular, on a separate sidechain, but for people who don't understand the sidechain, it still just looks like someone grabbed something that they understood, and the lucky beneficaries can't. So it's just to say that this is actually much more similar to the way that bitcoin works, than what people might be imagining when they say that sidechains are less secure than bitcoin. The security properties of bitcoin during a soft-fork are basically the same with sidechains; if you are not validating these things then you can be fooled by the hashrate majority. Any period of time after a soft-fork in bitcoin, there are presumably many clients running on the bitcoin network that haven't upgraded from previous soft-forks, they could be fooled just as much. So it's not really different from the security properties of bitcoin.

Brian: So let me try to rephrase that, because I'm trying to understand it. OP_TRUE looks to someone who hasn't upgraded that they are coins they can just take. Is the idea that, but if the majority of the miners are aware of sidechains or aware of this upgrade, then they will know that if someone takes that coisn that appears to be spendable, they know that it is invalid and they will reject it. So as long as more than half are using the new software, those rules of the upgrade will be respected and that might try to take the money but it wont work.

gmaxwell: Yes, that's how soft-forks work. There has to be more than a majority because otherwise there is network instability.

adam3us: When the feature is implemented, there's like a block number version increase, so all nodes can look at this block version and from it they can estimate the proportion of the miners that are with the new program that understand the new feature. So if 90% of the new blocks are mining blocks with that block version, then the clients know that it's safe to use that new feature. So they know it's in the network, but nobody will create one of those blocks until the hashrate or there's an acceptable miner understanding ratio and then those transactions are safe to make. There's the possibility that someone might take the coins before that point, it's not safe until the proportion of miners that understand it is sufficient.

Brian: When you move a bitcoin to a sidechain, you sort of suspend it and it's just staying there. And this deals with that. Can we come back to the question of the merge mining?

(hilarious awkward mumbling between adam3us and gmaxwell))

gmaxwell: The assumption that sidechains have to be merge-mined isn't really true. The sidechains whitepaper is quite explicit about this. Merge mining is an option for sidechains, but it's a design option that each sidechain can choose to use or not use. I think it is a prudent option, so we talk about it a lot, but it's not fundamentally necessary. The issue with merge mining that is often cited is that in the case of merge mining you don't have a hardware capital cost because you have that hardware to mine bitcoin. So the incentive versus attacking is do you make more money attacking versus mining honestly, and you don't have to worry about this upfront cost of the hardware. When we analyze bitcoin security, we ignore upfront costs of the hardware just because of latent hardware and things like purchased cloud mining and you can buy mining on demand. I just wanted to mention that merge mining is not essential to the sidechain proposal.

adam3us: So comparing soft-forks in the bitcoin blockchain and a sidechain, which is another kind of protocol upgrade, right. Now, you could rearticulate the situation of a soft-fork upgrade to say that the people who have upgraded, so the subset of the bitcoin network that has upgraded, you could view that as an in-chain sidechain. There is a subset of people that understand an extended feature. That's what a sidechain does. And the people who have not upgraded or are not susceptible to those rules, are susceptible to losing their coins to a dishonest hashrate majority that does understand those features. So a sidechain is a sort of, if you want to express it that way, a generalization or modularization of that existing upgrade behavior.

gmaxwell: One of the advantages of sidechains is that by making the bitcoin network effectively an SPV client of the sidechain network, is that we get very loose coupling so that problems on the sidechain network don't leak into the bitcoin network. But we get that at the cost of a different security model, that the hashrate on the sidechain network can steal all these coins when normally the hashrate that you would have to compete with is the hashrate on the bitcoin network. Now, if there's merge mining and there are transaction fees, hopefully these hashrates are relatively equal but maybe they aren't. Should bitcoin be as secured like Satoshi said if 51% of the hashrate is honest, or should we require something stronger, like the evidence that the economic incentives are such that 51% of the hashrate will be honest? We should take away the assumption and use economics. There's the risk that you could mine bitcoin honestly and attack the sidechain, then it might be in your economic interest to do so. That's a byproduct of that loose coupling. One of the things pointed out in the sidechain whitepaper is that this loose coupling is not inherent. You could pick your degree of "looseness". One possible outcome from sidechains, and there's several different ways to boost sidechain security with complex cryptography that we could talk about for hours... But one of the pathways is to say, well the bitcoi nnetwork could like a regular soft-forking rule, could enforce the validity of sidechain blocks. The bitcoin miners wont allow you to make a sidechain recovery transaction unless the sidechain says you could do that. There's a downside, listed as a risk in the sidechain whitepaper, this introduces the complexity of the sidechain into the consensus model of the bitcoin network, and it tightens up that coupling. On the flip side, it makes the security story basically the same as the bitcoin security system. If the bitcoin miners aren't blowing up the system, bitcoins can't be stolen.

adam3us: Concretely, you go through a loosely-coupled phase where 85% of the miners are merge mining, and they both have bitcoind and sidecoind running, and there are separate consensus rules running there. They actually have the information. If there was an attack going on, where somebody was collecting bitcoin reward but attacking the sidechain, the miner has the information there, the sidechain daemon would say that's an incorrect block, someone is taking something. So you can at some point do a soft-fork, and what it looks like is just tying the consensus together so that the bitcoind says okay this is a valid bitcoin block, but it also wants a response from the sidechain daemon that the associated merge mined block is also valid according to the sidechain rules, and if it requires both of those to be valid then it is equivalent to a soft-fork, you would get the same outcome if the sidechain logic was copied into the bitcoin source code.

Brian: But doesn't this get rid of one of the main arguments for sidechains? Which is that you can have all this extra without introducing risk to bitcoin. This seems to introduce a lot of risk.

adam3us: Right, there are two kinds of risk. One kind of risk is consensus risk that the code in the sidechain is more complex, there's also the sheer complexity risk I guess, but if that's packaged up in the daemon with process separation, kind of complexity and security risk could be managed, the other kind of risk is a consensus risk. As long as the sidechain is deterministic, maybe you don't care so much, but because it's a generic binary it's hard to be sure of determinism. Maybe it has some random bug that on, some operating systme, it says one thing and on another operating system it says something conflicting, and it could fork the network. That becomes dangerous. So you need to impose determinism on the experimental exteded, you need a robust way to enforce determinism, and that's where abstract virtual machines like moxie and moxiebox come into the picture.

gmaxwell: It's the notion that you could have the code that runs for the sidechain run in a very simple CPU simulator, a simple virtual machine kind of like the bitcoin Script system, that is exactly the same on all the bitcoin hosts, which allows you to be very sure that the sidechain validating code runs identically on all the systems. So this gets you around the risk to consensus for non-determinism. There's another point here that tightening the coupling does weaken the argument for sidechains somewhat, but what's nice is that you have this on-ramp where you can develop a new sidechain, the security story is weaker than the security story for bitcoin, but you don't have to cooperate with anyone you can just run it and go, and if that becomes widely used and the security becomes important because everyone is using and depending on it, then it would be reasonable to say okay everyone is using it then maybe we should regard it as an upgrade to bitcoin, we could use tools like deterministic virtual machine to make it a safe upgrade to bitcoin, even safer than the changes we have been making to bitcoin in the past.

Sebastien: I would like to come back to use-cases, bitcoin core development, economics, and Blockstream. Have you guys read this article?

Brian: No, I haven't.

Sebastien: I would like to come back to use cases for sidechains. We often talk about it.

Brian: I feel like we talked about before, we will have to come back to use cases, I feel like this is a key issue. I feel like we haven't wrapped our heads around this. Just before this show, you mentioned that the increase in block size, that's the way that merge mining would be accomplished. Could you explain how this would work?

adam3us: Another way to look at a sidechain is this other experiment, where could you increase the block size without doing a hard-fork? Could you do a soft-fork to increase the max block size? Actually you could. The way it would work is you'd have a one megabyte bitcoin block, you would introduce an extension block like a one gigabyte extension block, something huge with an obvious centralization side effect involved in its practicality. So the bitcoin blockchain, the one megabyte block has a merkle tree representing all of the transactions in it, and there are ways to add links into that which are ignored by people who don't understand the links. You can add a hook into the bottom of the one megabyte block tree, so maybe a tree for a 10 meg block or 1 gig block, could be hooked in there, you could then consider adding a new transaction version and people who look at and understand the transactions in this extension block and then, if the majority of the miners are understanding and receiving these transactions, they could facilitate people who want to do transactions that wouldn't fit in one meg because they are low value or maybe they are an exchange with high volume, they can have a hope of fitting into the larger extension block with some other trade-offs. It is easy for an existing bitcoin user to pay to an existing extension block address, it would just look like a p2sh (pay-to-script-hash) address, they don't need to understand too much about the criteria of the recipient, because how the recipient spends their money using some extended rules is their problem, the sender can send money to other people on their own. The harder part is to think about how somebody using the extension block could send a bitcoin to somebody ... and how that works goes back to how soft-forks work, which is that you have transactions and coins in resting in one OP_TRUE address, and from one megabyte block's point of view there might be one suspiciously large OP_TRUE address that holds all of the coins in the extension block's address, which could be a lot of coins, and so if they were to receive a payment, it would look like someone decided to send a fraction of a bitcoin from what looks like this huge bitcoin address with lots of coins that anybody could take that for some reason the system decided to assign to them, and they might have a go at taking all of those coins but of course the miners who have an understanding of the additional extension rule would reject that sort of transaction attempt. So using those two componetns you could see that you could soft-fork in a larger block and there's something analogous between that setup and ...... ((lost connection)).

Brian: Guys? Hello?

Sebastien: I think we lost them.

adam3us: Sorry about that. Can you hear us now?

Sebastien: Yep.

Brian: So you were explaining how it was analogous, how this extension block is analogous to..?

adam3us: So we were explaining how you could consider an extension block analogous to a sidechain. We have described this situation where you can soft-fork a sidechain where the bitcoin daemon wouldn't accept blocks that were associated wit ha merge-mined block that didn't pass the sidechain's opinions about what a valid transaction set looks like. You have the same thing in-chain with an extension block. In addition to allowing different block frequency and sizes, the more interesting thing is that you could put additional features in an extension block. It could be extended to do the same kind of things that people are interested to do in sidechains, such as introducing additional types of assets, like representing shares or other things that people are interested in like smart proxy and so forth, it could have extended smart contracts, zerocash or whatever else people are interested in experimenting with. And again for software risk and determinism, you notice there's a difference there. Really to get the best assurance on a soft-forked sidechain, you would want to put the sidechain code into a moxiebox environment, but you would notice that this hasn't been described for an extension block. The code that is validating an extension block is in the same code area that has access to shared memory or something as bitcoind, so that introduces an element of software complexity risk. You can observe that you could run the validation rules for the extension block could also run in a moxiebox container and I think you would have similar reasons for arguing that would should be done, to control software risk.

gmaxwell: The point here is that you can think of this sort of extension block line of thinking and realize that in the extreme end case where the rules have been soft-forked in the sidechain, the extension block and the sidechain are effectively the same thing. It's another line of thinking to get to the same approach to handling these things.

Brian: If I may jump in here, you were talking about a bitcoin client like bitcoind, and then there would be sidechaind. Would there have to be an agreement about sidechaind's implementation? There's only one sidechain client, that may have zerocash and micropayments and different block sizes etc, but there has to be an agreement about what's in there?

gmaxwell: The behavior of it would be defined by the sidechain daemon itself. In the case of where bitcoin is enforcing the sidechain's rules for transactions, there would just be a simple RPC between the two daemons where the sidechain daemon would say ytep this sidechain block is valid, so if it says you can spend coins then that's valid. The software would still be separate, even if it was soft-forked into the system.

adam3us: A soft-fork just means that a block has to be valid for both versions or both points of view to be accepted. Thta means that if someone tries to put an invalid sidechain block or take some coins that the sidechain allows it, they wouldn't be able to pass that second test, and if bitcoind is soft-forked to work with sidechaind, then that would say that's an invalid block, and bitcoin reward would be lost and they wouldn't get that block reward on the bitcoin side of the network.

gmaxwell: But as we said before, the whole point of the sidechain system is to have loose coupling, and this compromises the loose coupling somewhat. This is just one of the extra tools in the toolbox of about 20 different tools that can be used to narrow the gap between ..... ((lost connection).

adam3us: Are we going without video?

gmaxwell: No, you have video.

Brian: Ah, I think you're back.

adam3us: So actually the overlay seems to have disappeared. Do you see the overlay or is it different every time?

Sebastien: Oh that's not a problem. It's okay.

adam3us: Okay. So, where did we get to? We seem to be disconnecting periodically here.

Brian: We will cut it later.

adam3us: Okay. I was on track to saying that if you consider the extension block case, and you could have multiple extension blocks, and each extension block could be implemented in moxiebox script. The definition of an extension block would be the sha256 hash of the bytecode that represents the compiled version of its validation, then you could have quite good assurance in a sidechain-like way. The other aspect is that a sidechain provides a security so that only those with coins at risk of the validation rules being defective are only those who put the coins on that sidechain, so you would have that assurance with extension blocks. You could argue that this may provide a path forward for bitcoin to improve its security. Earlier we talked about the fact that whenever bitcoin goes through a soft-fork with some feature has been added, as Greg mentioned this has happened before, there is a transition period where some subset of users have not yet upgraded, and some of them have never upgraded and have degraded security such that the ability to do a soft-fork admits change to the network, and if you have a moxiebox-like container and you can put the validation code in it, then perhaps you could put the main blockchain's validation into a moxiebox container and then basically what's left is much simpler, it's moxiebox interpreter and something basic about choosing the longest block alright, and so if we can do that, and we have much simpler Bitcoin Core code, then we could reach a much higher level of software assurance and disallow further soft-forks, which is actually a security enhancement for the blockchain because if there's a user that is not keeping up to date and understnading these new extensions, or viewing soft-forks as giving miners additional power to propose rules, it's not a black and white thing, but it does slightly elevate the ability of miners to bring soft-forking rules into the network... It would be possible technically to block further soft-forks. And if you have moxiebox extension blocks which can be added into the network, it becomes an upgrade mechanism that does not have soft-fork risk because it's still within the network and it doesn't require a Bitcoin Core change, you could introduce a new extension block and all you need is the interpreter of the moxiebox bytestring and the longest chain rules and then you could move coins between them via the Core or directly.

gmaxwell: So these are just general ideas that, they aren't concrete yet, and they are not in the immediate future. Some of this thinking has been circulating for a while. From the perspective of Bitcoin Core, we have been working on reorganizing the code base so that it is easier to isolate the code that implements the consensus algorithm. The reason why we are doing this is because it makes it possible to try things out, such as moving the whole of the consensus code into a bytecode virtual machine to get better assurances about the consistency of the consensus in the network. You can take that idea and extend it more broadly so that you can extend the network more broadly so that you could add more code that runs in this very rigid virtual machine and not have such ad-hoc process for extending the bitcoin system.

Brian: We want to talk a little more about the economics and big picture questions like that. But perhaps to bring this down to a level that is more like graspable for people in concrete detail, can we get into some of that? How would a sidechain be created in this scenario where they would be run as these extension blocks?

adam3us: Well, someone would write some code and carefully validate it. Get other people to audit it. They would sign the code and make signatures like in existing systems. They would start to publish that in the blockchain and start to transfer coins into it. Other people who were interested in those features would do likewise and benefit from that. It's kind of opt-in, and people with coins in the main blockchain or other extension blocks are not effected by some kind of subtle bug in the validation of the brand new extension block or something like that.

gmaxwell: The point that Adam is making is that in this sort of grand extreme version of this idea, you would have the ability to publish your new cryptosystem rules as a special kind of transaction that says you are defining a new extension block and here's its rules. You would just advertise this into the network, it would get mined into the network like any other transaction, and then people could continue to send funds and interact with these new rules that were introduced into this sandbox in the network.

Brian: Does that mean that the rules would have to fit into a transaction?

gmaxwell: Yes, they would have to fit into a specially-formed transaction for this, whic his why it is important that the bytecode for this be succinct. You'd have to implement the rules in the context of it. But a transaction can technically be a megabyte in the bitcoin system today, so that's quite a bit of code, and it's more code than is in the current bitcoin consensus system right now.

adam3us: In an ideal world, bitcoin would have been bug-free and perfect and complete and extensible, and Bitcoin Core would have been frozen and soft-forks disallowed by some technical mechanism. This is basically a sort of long-term track to arrive at that position or get closer to that position. When bitcoin has a set of features and rules which are fundamental to its meaning, and nobody wants those to change obviously.

gmaxwell: We have this sort of twin pulling where in one direction if bitcoin can change then it can change out from under people and potentially compromise the promises that it made to them about their autonomy and their control of their money. But on the other hand if bitcoin can't change, then it's bound to not adapting to new needs for money. So what Adam is trying to talk about is pushing the systme into a case where there is a rigid core part and everyone can depend on it, but still have extensibility so that when people want to do that it's not precluded.

adam3us: Right.

Brian: I would like to talk about an idea that seems to me, at least listening and talking with you and hearing you speak about this in other contexts, it seems to be very central to what you guys are doing at Blockstream and what sidechains are about, is this idea of digital scarcity. Why is that important?

adam3us: I think much earlier Greg had mentioned, the idea that money is a kind of social network. It benefits from network effects. At the extreme, if everybody has their own money supply then it ceases to make meaning because it is just an IOU and there's no limit. I can print IOUs up to the limit that people are willing to trust me with, and then it is no longer scarce at all. And in between we have a istuation where; I think it is useful for there to be digital scarcity because if we have too many forks, so you start with bitcoin, there were some early altcoins, and they grew up a bit and then someone forked them. If bitcoin were to disappear and we were left with lots of competitive forking, it would not be attractive because it would lose its properties of money. The cryptocurrency that is left would have no store of value because the bubbles pop every 3 months or something, and that would be bad because it would lose its security because it's not a long-term stable thing, it would lose its value property and it may fail to reach unit of account, which needs wider use and sort of less volatility which would come with more unified use.

gmaxwell: There's another point to this where there are applications for cryptocurrency that doesn't involve scarcity, but the networks themselves have scarcity. A global broadcast network like a blockchain has limited capacity. Computers can only handle so much, and if you make it too big then decentralization goes away. One of the things you could do with a scarce asset but that you can't do with a non-scarce asset is that you can align the incentives, you can say well okay to use my resources you have to pay me some money of some kind, and since money is scarce then I know that you cannot unfairly exhaust my resources because you don't have an infinite supply of money.

adam3us: Yeah, so that's interesting, and the other thing that some people wonder about is could you start a new cryptocurrency or add support for other types of assets into a cryptocurrency, and then use the other assets issued by people or businesses as fees. And I think there's a fundamental limitation here: a blockchain cannot validate the scarcity of something that is issued by humans. If I issued a coin in my garage or something, and I use it as fees, I could completely flood the network because tomorrow I could just decide to print a trillion of them or something. And the problem is that the network has no way of knowing whether I am just someone playing around or trying to create mischief or if I am a reputable business or a bank with gold on deposit or something, it's not something that the bitcoin network can validate. So fees are basically to make the network work smoothly, prevent denial of service, and prevent the misallocation of resources in the network. For that to be the case, they need to be something directly machine-readable and understandable, like the fact that it is scarce has to be validatable. If we have lots of people creating things, just definitionally, then that wouldn't be the case, and it also wouldn't be the case in new independent networks that spring up, because they tend to come with larger and larger numbres of coins, like trillions or what have you. So scarcity is involved definitionally at some point.

Brian: So scarcity is necessary for true decentralization, no? Because if you don't have that, you have an issue.

adam3us: Right. Good observation. Carry on.

Brian: I gave a ... about sidechains. I was thinking about it. And one of the things, and I don't know if you share that view, but one of the things that I find interesting is that let's say bitcoin has achieved some success as a store of value, the question is how far can that go? Will we ever for example be able to say that I keep my savings in bitcoin as a prudent person, not someone who is a risk taker. And it seems to me that maybe bitcoin is the only chance, right? Because let's say that bitcoin doesn't work out, let's say that we hope bitcoin is going to be it, but somehow bitcoin fails and there's the next thing and then that's it, but the thing is, if bitcoin isn't it, if it's not the first one that is going to represent a digitally scarce unit of value, then wouldn't it always be the fear or the possibility of there being something else later that is better? So I think maybe from that perspective the idea of having a purely digital store of value sort of tied to bitcoin, do you see that the same way?

gmaxwell: From the very first beginning that I got involved with bitcoin, I somewhat felt that as a cypherpunk this was our one chance to get a world-wide used practical cryptocurrency because if it fails people wont sign up for the successor because they wont trust it, they wont sign up because... the point you were making. But at the same time, bitcoin as released in the first version couldn't be the something that replaces all fiat money, it was just another digital kind. It couldn't replace the other fiat because it didn't have the other properties like scale and other properties you can get with large scale issued fiat money... But yes, how do we preserve the unique starting position as this surprise technical marvel, and expand it out so that it could cover the whole world and be used in many more applications.

adam3us: As we can see already the viability of sidechains and extension blocks and other potential extension mechanisms, if somebody was to find useful extensions and useful scaling improvements, or the ability to support other asset types, there's no fundamental reason it couldn't be added to bitcoin. If it is useful, it should be added. When we talk about network effects and the internet and so on, that arose because everyone worked around an interoperable neutral standard and I think bitcoin also has the property of being neutral. There is no proprietary ownership or control that is centralized and associated.

Brian: So one thing that we have been talking about recently is, ... we talked about this with Vitalik as well, is this idea of a stable cryptocurrency. There's the question to what extent is volatility a problem, and to what extent is volatility going to go down as bitcoin is more adopted. Personally I think volatility is going to remain high even if bitcoin becomes very widely adopted. So the kind of idea of maybe, relatively fine as store of value, but unit of account, I have some doubts that this will ever be stable enough. What do you think of that? And what do you think about stable cryptocurrencies?

adam3us: I don't know so much about the you know funky things where they have some algorithm and reserve pool that implements a conventional currency supply curve, it's not just some people with an economics background and they were saying that if you look at the existing financial system, they say that tetchnically when those things arise they are unstable and collapse. They are often constructed as synthetic assets built from derivatives and the underlying asset is, and you have the problem where the market for the synthetic is a different market, and there's an element of relief and trust, and you saw this where George Soros bet against the british pounds or recently with the swiss franc where there was a loss of confidence or they thought they were going as far as they wanted to, or whatever reason they abandoned the currency peg, and even automated systems will have this property where someone will bet against it, and the algorithm is fully made out, so people can get good estimations of whether they are capable of breaking the peg.

gmaxwell: I may have not seen the specific proposal that you are talking about, but the ones that I have seen in the past often had problems where the algorithmic behavior could be rigged by miner censorship of data in the blockchain. So there were some really interesting ways to game it, but you know if people want to experiment with technology like that, then more power to them. But if it's valuable to people then they should be able to create it. I think that one of the neat things you could get with bitcoin is regardless of how that stabilized daily currency works regardless of what its security properties are it could be backed with very strong bitcoin behind it and then maybe you are willing to take some tradeoff where you lose some security over how that system works, maybe to get around problems like miner censorship you build a system that has ... and that may be attractive to some people that I may think are foolish but they should still have the ability to try out that idea regardless of my objections, just in a safe way that doesn't destroy the bitcoin network.

adam3us: Yeah, so I mean we don't know where bitcoin is going in terms of its wider use for the use of its to grow for international settlement or to reach unit of account status, so that's quite hazey and speculative. We could see that it grew very fast over the last few years, so in the next few years perhaps surprising things would come to pass, and there is some political interest to see a neutral currency exist that isn't controlled by a country or group of countries to do quantiative easing or have political influence over it. So they might be interested in that, and you could draw a loose analogy to the gold standard which survived for 6000 years or something, plus or minus depending on how you look at it. And it was used internationally, currencies and coins issued by reputable central banks got physical coins accepted internationally for a long period of time. I don't know if that works in this day and age, but maybe. And also you can look at gold and see that even gold is relatively volatile at this point in time.

Brian: Yeah, it is.

adam3us: The other thing is that you could look at blockchain, it's a good sort of financial networking technology for storing all kinds of things, whether shares by companies or intrinsic ownership of that company and to sell those units and what have you, but also fiat currencies could be issued in the blockchain format and there's something interesting to that as well. Some central bank could make an assertions about their intent. Monetary policy committees usually have some written mandate and self-composed constraints, objectives around inflation rates, or state assurances about the level of quantitative easing they would engage in given different market conditions, and some of those things could be expressed as a monetary policy statement and enforced by a blockchain. So if you take a weak currency, and there are a few hundred currencies in the world, and we are perhaps more used to dealing with the top 25 to top 50; but some of the lower ones are quite volatile and have currency exchange controls, hyperinflation and volatility; but if one of those weaker currencies were to issue its currency on to a blockchain and together with an insurance that more than 2% quantitative easing, the blockchain could enforce that and it could add to the attractiveness of that currency because they would be voluntarily ceding some political control to a completely neutral mechanism to provide a stronger currency assurance than they can presently offer.

Brian: Could we talk some about the issue of mining centralization? This has been one of the main criticisms of bitcoin. I totally agree with you that the idea of a stable currency, it's very attractive ubt there's no implementations but some people told me about this new bits thing but I haven't looked into it. Supposedly that's happening. But it's not implemented, but it's more complex and there's additional risks. Maybe it doesn't work. But the other thing is the security of mining and whether bitcoin mining is fit and will be fit to back the security of a network potentially worth hundreds of billions of dollars or even trillions of dollars. What are your views on that?

adam3us: The bitcoin network has gone through different periods of relative centralization, and some of the centralization that we see is artificial in the sense that it could be removed with simple protocol changes. So for example, when you use a mining pool, often people are ceding their choice for which transaction is valid, ceding this to the mining pool. And that's not technically necessary, you could run your own full node to decide on which transactions should go into the block, and separately use the pool to reduce variance in mining. And if we could see this separated, the mining centralization could look better. But there is also some centralization from people who own their own ASICs. But, Greg do you want to talk about the smart property miner?

gmaxwell: Right. There's another angle on this where mining centralization occurs because people colocate their mining hardware in places where energy is inexpensive, and there are some diseconomies of scale that show up when you put a lot of hardware in one place: it's expensive to cool, it's expensive to power and the location. There are still plenty of reasons to have large mining facilities. So they become risk points for the network. Someone could seize control of the facility and then have a bunch of hashrate to attack the network. So one of the ideas that I have been working on with some other people is to build a sort of next-generation mining ASIC that have intelligence in them so that they have an idea for who their actual owner is, and when their owner is different from the person with physical proximity. There would be some keys that are known inside the mining chip, and when you compute your consensus vote and tell your mining chip what to mine, you have to sign that so that the mining hardware only follows what its mining owner says. So the owner might be in Idaho but the equipment maybe in Iceland. This physical facility is less of a point of centralization risk because someone who gets physical control of the facility cna only just turn it off, or they could begin a very expensive process of decapping each of the mining ASICs and trying to extract the private keys which isn't practical.

adam3us: So you can think of that as kind of smart lease, so if you buy a mining contract or you buy the ASIC but it's housed by someone else, you could opt to use this new feature of the ASIC to program it and say you have purchased a 12 month contract, and this chip will defend from anyone asking it to mine that you haven't signed, for that period of time, after which it might change its control or it might remain in my control and take physical delivery of it. So it gives you the flexibility to further separate ownership from the physical location of the chip.

gmaxwell: There's a number of technical measures like these that could be used to improve the decentralization of mining. And this has been important to us because obviously keeping mining decentralized is essential to the security of bitcoin and anything that depends on it. It's essential to the network, currency and any sidechain. There's a bunch of tools to improve this. We don't know what level of impact thos etools would have.

adam3us: You could also say, on the term, there is an incentive to... if a cryptocurrency like bitcoin is going to have wider use and more value is going to depend on its integrity, then central banks and countries and these large bitcoin ecosystem players like countries and exchanges, there is a strong interest to have decentralization. The easy way to do this is to each buy a small percentage of the hashrate, you could imagine in the far future where some segment of the large companies on the stock exchange are involved in finance using blockchain technology and maybe there's a thousand of them worldwide, maybe between them they own like 50% of the hashrate independently and the public at large and other people own some. Then there is some decentralization and it's very difficult for somebody to take that away from them, right? It becomes a kind of balance-of-power structure. I mean right now, ... some companies, some people doing it as a profit-making enterprise, but if you were in this position you wouldn't have to make a profit, just not too large of a loss to retain the decentralization. And if you are taking a small loss because you depend on the decentralization of the network, it's very hard to compete against the loss. You can make a bigger loss, but that's not attractive.

gmaxwell: We've seen some weird effects... Go ahead.

Brian: Well one problem is that this is sort of a.. I don't know if I would buy tihs, if this would actually work. My bigger question relates to proof-of-stake. Isn't that just in case, one gets some kind of good working solution superior because you know the security is the value of the whole network, not just the subset the actual hardware?

gmaxwell: Well, the key point here is "if someone gets a good solution". It seems that, well, so time travel is also fantastic if someone gets a good solution. Perpetual motion is also a good thing if someone could get it. So I was very excited when the first proposals for proof-of-stake come out in 2011, and we thought that this would radically change our risk factors in the future. On deeper analysis, we ran into some really fundamental problems that we could only work around by making different security tradeoffs where you abandon sybil resistance or you rely on centralized signers, and we've seen this in systems that have been deployed out in the wild. We have seen proof-of-stake systems that were deployed and then attacked and then mitigated by things like a developer signing blocks to prevent reorganization. If it were, it would be very interesting, but it seems like it's probably not without some different security model. And different security models can be okay, but they are hard to analyze. It's clear that you don't get the same thing that you get from bitcoin. It's not clear if the thing you get is actually useful.

adam3us: So a couple of things. One is this sort of economic principle to mining. There's a kind of mining commodity price to the market where you can find miners expending up to the current price of the market to mine it. So if you radically change the cost of getting coins, presuming there is still mining going on, there is a potential for that economic self-interest to flow somewhere else. To result in buying political favors or influencing political committees, or influencing the committee handing out coins. That built-up economic demand has to go somewhere. Maybe it's not necessarily a bad thing that a commodity has a production cost.

gmaxwell: To add some more color to the proof-of-stake system, right, there's basically a generalized counterargument that you can basically take any proof-of-stake system and say well okay what happens when you own all the coins at the beginning of the network, the network goes on, you exit the network, you sell your coins, but later you show back up and you create a simulated network, a second fork of it, and you show it to someone who is new to the system and they can't distinguish it from the honest network and the dishonest network. It's a very fundamental difference. What you basically have to do to fix that is to say "well okay we're not going to use proof-of-stake for our consensus system, we're going to use something like ask-a-friend as a consensus mechanism". You can do that, but it has a very different security model, it's explicitly what bitcoin doesn't do, because ask-a-friend is incredibly difficult to automate in a secure way because of sybil attacks, people who pretend to be many entities to rig the state of the system. It's a process that gives you a; I think the proof-of-stake thing is a distraction. The security of that system reduces to whatever you do to repair the nothing-at-stake attack. Sometimes those tradeoffs are good in some environments and maybe they are bad in other environments.

adam3us: Yes, often it seems to degrade into a different proof-of-work which is to grind alternative transaction histories to find one in which it results in you receiving the coins. If that's how it degrades, you're better off sticking with proof-of-work because you can build ASICs for it, which avoids .... If you were to get a finer proof-of-work that can't be optimized by ASICs, which seems generally impossible, hypothetically then it's vulnerable to renting equipment on a temporary basis, like renting Amazon's cloud computing infrastructure. You don't want short-term renting of mining equipment, because if it's generic and you're capable of grinding alternative transaction histories which is problematic. So if somebody finds a solution, as Greg said, he was interested in it until he discovered those limitations, but if somebody does find some magic that solves it, great, bitcoin would be very happy to see that happen and adopt it.

gmaxwell: If this is interesting to you then you should look at a whitepaper written by Andrew Poelstra which summarizes the common deep technical..

Brian: Yeah, I think I read that.

gmaxwell: It's got some good information. What it doesn't try to do is a point-by-point rebuttal of the infinite series of ad-hoc patches that people have tried to do to get around the fundamental issues. But that's pretty interesting and I encourage people to get familiar with that and it's good food for thought. But yeah, if it's made to work in a model that gives good security then it would be useful to use. I haven't seen it yet. A lot of the things proposed for proof-of-stake have been things from bitcoin-wizards and bitcointalk that were previously discarded; people were trying to get proof-of-stake to offer decentralization like bitcoin and couldn't use those ideas to achieve it. Maybe you could use those things if you are willing to make different tradeoffs in the security model.

Brian: Maybe at some point we'll have to come back to this topic, because it's one that has also been coming up. It would be interesting to spend some time digging into that because, but yeah. So what is the timeline for sidechains? By what time or date do you think you're going to have this implemented? What time?

gmaxwell: What we've been trying to do-- we have published the initial whitepaper and got a widespread response to that. I consider it a big success it, not just for the excitement created but because lots of people have reviewed it and commented on it, and haven't brought up any deep fundamental flaws that weren't brought up in the paper and were unknown. So that's a big point of success. On sidechains, we've been trying to avoid exhausting review capacity. There's this problem in the cryptocurrency system in general where someone will propose a system and I walk up and go "nope, it's insecure, I break it this way, it's toast" and then they will go okay, I will fix that, then they apply a fix, then it takes me 10 minutes to break it, then they apply another bandaid, then it takes me an hour to break it, and then they apply some more bandaids and some other people come and break it after weeks of work. And at the end you have some patched up system that might be secure, and maybe it is secure because nobody knows how to break it right now, or maybe it's insecure because everyone got exhausted while reviewing it. And so we've been trying to do with the sidechain work, we want to have a very interactive development process for this infrastructure, but at the same time we don't want to exhaust review capacity by putting stuff out that people will analyze and then it has you know easy shortcomings and then it sort of exhausts that review capacity out there. One of the things we came up with in the development of sidechains is this soft launch of it, where you can use all of the sidechain technology with a weaker security model called a federated peg. So the idea of a federated peg is that instead of soft-forking the changes into bitcoin for a sidechain, you do a sidechain like normal and then there's some federation of functionaries, these are parties that hold private keys, and they will sign transactions that would have permitted the transaction to occur. They are standing in as a protocol gateway adaptor. The tradeoff is that if they wanted to they would just steal the coins. There is some protection against this, in that there would be a threshold of them. So this is laid out in one of the appendixes of the sidechains whitepaper. What it lets us do is release sidechains software that people can begin to use with real value but reduced security because of the risk of the federation stealing the coins, and then we can get experience with the technology and show that it is useful and has value and that it's realistic and that the software can be secured. And so we're planning on... and it doesn't do anyone any good to release something trivially insecure, so it's done when it's done. Beyond that we have to see where it goes from there. It will take some time for the initial system to mature and for people to gain confidence in this, and to figure out where to soft-fork things to make it possible to do this without the functionaries.

Brian: When do you think we will have these sidechains running?

gmaxwell: A couple months, two months, one months.

Brian: Oh.

gmaxwell: The people working on it have privately versions of it that run today. And we have for some time now. It's just, it's immature and buggy and not really ready to burn people's review cycles on it. I don't want to publish it and then get people to crash it immediately; it must have some level of integrity before it's worth people's time to review. The actual technology was easy to develop in the context of the federated peg.

Brian: Well, I don't know if you want to briefly, what's the idea. Blockstream you guys raised quite a lot of funding. What is the business model? Are the investors putting in money, do they think of this as a public good and maybe they are also bitcoin holders because they think it increases the value of their bitcoins perhaps indirectly?

gmaxwell: There's definitely an element of public good here. A special form of public good is building infrastructure that bitcoin needs going forward. There are other business angles on this as well. There's a line of thinking that says, "The best kind of charity is self-supporting". You can build a business that does good and makes money, which you can then use to go do more good. This is a more sustainable model then just putting money down a hole and hoping some good comes out on the other end. It turns out that once you have the sort of future of bitcoin more flexible, there are many businesses that you can get out of that. But you have to get to that point first. One of the reasons why we raised such a large amount is that we wanted to have the runway to go and give a decent shot at building tihs complex secure cryptographic infrastructure required to make the other folds of the business possible. To give you a taste is far beyond sidechains; we're taking some of the cryptographic concepts of bitcoin, these decentralized provable systems and extending them to the rest of the business world, allowing institutions to make proofs about their books and finances, and tying that into the bitcoin blockchain, like smart contracts depend on that. To make that real and worthwhile, we have to make bitcoin more flexible. We have a way to build bank-like services, private servers that can achieve really high transaction volumes, like 10k transactions/second, like the kind of thing to run an exchange in a cryptographically-provable way, but also they can't seize people's funds. They have much better security properties. But again to make that kind of system possible, you need a more flexible bitcoin ecosystem and can speak to more powerful external systems.

adam3us: I think bitcoin, smart properties and smart contracting hvae a lot of potential beyond bitcoin as a currency, which is to say that bitcoin is providing a kind of real-time audit capability which is lacking in the other financial system. You often don't find out something went wrong until a post-mortem audit. You discovered a problem and it's too late and you got some economic collapse. With the blockchain and a real-time audit, it means that each unit of value comes with a compact proof of fully balanced books and balance of the entity it comes from. So if you build out into the future where, say a company and all of the internetworked companies eventually, have hteir income and dividends and shares and expenditures all tracked on the blockchain, you can avoid some systemic risk where you don't really know the credit rating of a company or the credit rating is misleading or it turns out that it has some large unexposed debts or it has some insurance policy against some liabilities but the policy is overextended; all of those liabilities and assets and money flows can be represented in a machine-readable blockchain format, you could squeeze out a lot of systemic risk out of the system. Because of some of these cryptographic features, you can provide the companies with confidentiality about who they have contracts with, what the profit margin is, how large the values are of recurring payment values, all of these things can be hidden from public view while simultaneously validated. You can make the books add up without exposing the values, thanks to some encrypted value stuff that could be made to work. I think this is an interesting high-value thing for humanity to get that kind of assurance, and ultimately regulators and policymakers and central bankers and society at large will value this and see it as the way forward.

gmaxwell: They are going to need help to migrate into this. To make it valuable to them, it will need to tie into bitcoin. There is a lot of cryptographic development to span from what the world is today to what the future is going to be.

adam3us: There are some limitations in the bitcoin ecosystem, where over time people are oimproving the security mechanisms. Most of the bitcoin ecosystem is not doing smart contracts; like mtgox, most people were trusting them in a credit worthiness sense, and then we're migrating people and starting to deploy multisig and ultimately the business logic can be potentially implemented in and enforced by the blockchain. To give an example, let's say if you ((dropped connection)). You might get compromised, there's a central server that gives a second signature and it wont sign if you go over the transaction volume for the day. But if someone compromises the central server, those rules no longer apply. You can have the blockchain enforce the business logic, which scales ultimately to, you want to be programming to get the most assurance by having the blockchain as a narrow AI that is perfectly honest with enforcing these rules. That's where the future lies in the long term.

Brian: Yes, I think there will be a need for these capabilities. I think the ability to implement these things will be extremely rare. I think you guys will eb in a good place to make these things come true. This may have been our longest episode ever. Thank you so much for joining us today. It's such a complex project and my understanding of it has been kind of turned upside down. Thanks so much for joining us. Where should people go for more information?

gmaxwell: The sidechains whitepaper is a good place to start if people haven't read it yet. Ultimately I think more engagement with the wider bitcoin development community is also necessary. It's about more than just what we're saying about it.

Brian: We are looking forward to the first sidechains and trying them out and seeing how it works. Thanks.