path: root/transcripts/gmaxwell-sidechains-elements.mdwn

Bringing New Elements to Bitcoin with Sidechains

SF Bitcoin Devs Meetup
2015-06-08

Gregory Maxwell
DE47 BC9E 6D2D A6B0 2DC6 10B1 AC85 9362 B041 3BFA

slides: <https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf>

video: <https://s3-us-west-1.amazonaws.com/blkstrm/video/elements-gmaxwell.mp4>

<https://github.com/ElementsProject/elements/>

Hello, I am Greg Maxwell, one of the developers of the Bitcoin system and its reference software. Since 2011, I have worked on the system facing many interesting challenges and developing many solutions to many problems, adapting and growing and maintaining Bitcoin along with a community of other technical contributors.

Today I am going to talk about some of the interesting challenges that we faced in adapting Bitcoin. And I am also going to be announcing some new projects and initiatives that we are making available to the public now to help address some of these challenges.

Blockstream was founded by a collection of technical experts in the Bitcoin space who were looking for a way to organize and fund the development of complicated technical solutions to important problems. And to also take the ethos and trustlessness values of the bitcoin system out to the wider world to apply them to new places.

So first I am going to talk about some of these challenges we've had in bringing bitcoin technology to more applications. Then I am going to talk about Elements, which is our project that introduces some tools for dealing with these challenges. And then I am going to talk about specific interesting features that we're using Elements to make available. Before talking about the challenges we're facing, I thought I should level set with a view on what bitcoin is actually accomplishing.

So traditionally, systems of money have this property where they require trust at all levels. You trust your bank, you trust the parties that move funds from place to place, you trust the central banks to have good economic policy. And this trust is very costly to maintain: it requires constant vigilance, and it's also easily violated and unpredictably violated. So this makes the existing monetary system that we have in use, less useful.

So Bitcoin is a potential solution to some of these problems. And it starts with the idea that what if we replace the systems of money that we are using today, or augment them, with a system that is based purely on mechanical and mathematical rules. Mathematically defined rules and enforced by computers, rather than just human processes. And by taking the human out of the loop, we have potentially reduced the influence of politics on the system and have something that is much more dependable.

And the idea of building a digital currency out of computers and mechanical rules has been around for a long time. And people have been seriously working on it since at least the 1980s. But it's not as easy as it might sound. It runs at odds with something like the fundamental nature of information. One aspect of digital information and information in general is that a copy of a piece of data is every bit as good as the original. And information does not inherently have an owner that can control it. We can only achieve those via overlays on top. And if we think about building a monetary system out of information, well for a money to be useful it has to have controlled supply or otherwise I would just say I have a trillion dollars, and it also has to have ownership so that someone can't come along and take my money. These criteria are fundamentally opposed to how information actually works. And if we are going to build this sort of system out of computers, well computers are controlled by people, and people are pretty good at ignoring rules when it suits them.

So the positive news is that after decades of effort and people believing the problem was impossible, it was discovered that there was one possible path to do this. And that's what Bitcoin is. So Bitcoin employs cryptography and economic incentives to build a system where the rules of the system have independent force that can exist independently of popular will.

Now, you can look at this basically as handing control of the system over to computers, where the computers are really in charge and not just following the orders of people. And that's pretty cool because you can make pretty strong promises about what that system will do. But the bad side is that computers are in charge, and nothing can be as inherently stupid as a computer. And there has been plenty of science fiction that has warned us of the potential dangers of putting computers in charge of things. Fortunately, Bitcoin's remit is pretty narrow, the thing it is in charge of is pretty narrow, and it doesn't necessarily have a lot of danger, but it does have a fixed set of rules. And so if we had perfect foresight, perfect ingenuity, if we could perceive all of the consequences of our decisions when we built the system, we might be able to build a system of money where all of the rules were completely defined at the outset of the project. And which never change, and everyone could count on never changing for all time. And that would be pretty interesting. But the problem is that we do not have perfect engineering and we do not have perfect foresight, and people do not always agree on what their values are. And so since we don't have these things, mistakes were made and Bitcoin originally didn't even correctly enforce ownership at first because of bugs that allowed anyone to spend anyone's coins. So needs change, problems are found, the world changes, and sometimes people have contradictory requirements. And so we faced this challenge where Bitcoin's very nature should be hard to change, and that's how it's trustworthy and survivable and you don't have to worry about who created it or who controls it, because nobody controls it- it just is. But those same qualities also make it hard to adapt Bitcoin to the changing needs of the world.

Some people have thought to address this particular problem by creating new alternative digital currencies, called altcoins. So they are just copies of the Bitcoin system that work by taking the Bitcoin source code and changing the name on it, maybe adding some new functionality or maybe not. Maybe adding a picture of a dog. Some have been interesting, but most are pretty boring and they're just a reboot. Why would people reboot it? Well, when Bitcoin came into existence it was worthless. Over time as people saw the potential value, they started trading bitcoins for larger and larger amount sof money. So this creates the potential for a speculative race where people want to get in and hope that it becomes valuable in the future. And this has incentivized the creation of many altcoins, even ones that have no other reason for existing creating problematic pump and dumps. A problem with this is that there's no natural stopping point. So first there's bitcoin, then there's foocoin, then there's barcoin, then there's barfcoin, and someone from the outside looking in might look in and say "Well why am I going to use this Bitcoin stuff when tomorrow it will be worthless because tomorrow someone wants barcoin instead?". And that comes to this point that the fundamental value of a money-like good is the fact that other people will accept it. You know that you can take it today and give it to someone else tomorrow and they will value it. The value of currency comes from the network effect, and if you're starting up new cryptocurrencies all the time, all you're doing is fragmenting the network effect.

We're also left with the problem that fundamentally this is no different: if you build a new system, a widely distributed system becomes hard to change. So the reboot is left with the same problem that Bitcoin has, that it's difficult to adapt and change. So I wish altcoin developers luck, but I don't think it's a sustainable way to build technology. What else could we do?

Bitcoin was designed from its very start to be able to be extended in a way that is compatible with the existing system in a way that does not override existing rules, but adds new ones. One of the systems that Bitcoin has built into it is a system for smart contracts. Smart contracts are this idea that when you pay someone in bitcoin, you don't just say who you're paying, but you specify a computer program that decides when the payment is to be permitted. This is a smart contract, where the contract is a program. Now this doesn't eliminate or make easier establishing contracts that do what you want, in fact it makes it harder when you have to write a program that enforces your rules, you really have to get the program right. What it does is make the enforcement effortless, because a smart contract is enforced by the Bitcoin network. The Bitcoin network acts as a perfectly trustworthy artificial intelligence that executes the contract and completes whatever it does, good or bad. What this means is that in many environments today where you cannot get enforcement for a contract, you make that contract over a cup of coffee, you can try to enforce it, but your counterparty will laugh at you and the courts will laugh at you and you will get nothing. It allows you to have a system where the contract is inherently enforced by the system itself. Unfortunately the smart contracting capabilities of Bitcoin were somewhat cobbled by bugs. The original system had limitations and problems, but it's possible to fix them and improve them in a compatible way. We use a mechanism called soft-forks, which are backwards compatible revision schemes in Bitcoin. We have used soft-forks several times to deploy new features into the Bitcoin system. So the 3-type addresses that are widely used today are an example of a soft-fork we did in 2012. There is another soft-fork right now, a change in the signature encoding which is quite technical minutia, but it shows that this process works and it shows that we can use it to deploy updates to the system.

But even given the process of soft-forks, it's very difficult to do updates to a live, production network. And Bitcoin is a system that is used by many people, it has a sort of "market cap" if that is how you want to measure things that are over a billion dollars, and the sort of design of the Bitcoin system was to be beyond influence. And so it is just hard to update. Many of the updates that you would like to do are easier to do in a whole new system where you don't want to disrupt all of the other things going on. Bitcoin has built into it a mechanism for very efficiently proving to someone that they were paid in the system. This is called simplified payment verification (SPV). And it allows you to have something like a vending machine that listens to the Bitcoin network and with very little data sent can learn that it was paid. It has to make some security tradeoffs in doing this, it has to trust the network to be honest to it, and the network as a whole honest, but it's very efficient.

What if we combined this notion of simplified payment verification with smart contracts? What if you write a smart contract in Bitcoin that allows coins to be moved only if another transaction occurs? And this is a little abstract, but the mechanism here is something we call the two-way peg and it's described in the whitepaper we released last November. What we can do is use this two-way peg mechanism to build something called a sidechain, a parallel bitcoin network that is similar to the bitcoin network but separate maybe with new features. You can take some coins on the bitcoin network, and freeze them, and then the sidechain can observe these frozen coins and allow you to transact on the sidechain network. When you are done transacting there, you make a transaction that effectively moves the coins back to Bitcoin, and releases them out of the smart contract that is holding them on the Bitcoin network. So in doing so, we can gain the freedom and agility of having multiple networks, without rebooting the Bitcoin network effect and without changing to a new currency. So multiple networks, one currency. This allows us to do new experimental, risky, research or niche applications and put them in their own networks.

So I am happy to introduce Elements, which is our project to advance the state of the art in Bitcoin using this sidechains two-way peg mechanism. And the idea here is to have a no-holds-barred use of exploratory technology where we will be able to try out new things, and deploy them on a network that can be used with an existing Bitcoin network. Now using them straight on a Bitcoin network might be a little bit of a leap, so we are first using with Elements, we are using the testnet sidechain. Testnet is an existing parallel Bitcoin network that is used for testing the Bitcoin system. It has existed since 2010 or so. It's used by the developers of the Bitcoin software, and by social convention the coins on testnet have no value. So you can trade them back and forth, and it's widely used.

With Elements, we are producing a new sidechain that will use the two-way peg mechanism to transfer coins from the testnet network to the sidechain network which we are calling Alpha, and back again. This is new software that is open to everyone to open new avenues to exploration. And we have included into it a bunch of interesting features, which we are calling elements. And this is all neat and all, but please keep in mind that it does not have a lot of quality assurance. This is actually a good thing, because one of the barriers to deploying technology in bitcoin is all the work you have to do to make sure that the software is trustworthy, so it's very refreshing to be able to work on new software and experiment without it potentially impacting a billion dollar economy, but still have a way to put it into production use.

I would like to talk a bit about each of the top-level new features we have put into Elements. Each of these new features is effectively a single person's experiment, although we have taken some for review and enhancing the software. And I hope that people will pick this up, find this software useful or inspiring and contribute their own experiments. I would strongly oppose using the current software with any cryptocurrency network that has value.

The first element I would like to discuss is the deterministc peg. This is the two-way peg mechanism that allows you to bring testnet coins into the Alpha network and then back again. This is implementing the stuff we described in the sidechains whitepaper. And the basic mechanism is that you can make a transaction in testnet, wait for 10 blocks on testnet, and then signal to move it into the sidechain. On the sidechain there is a 144 block confirmation period, which allows someone to prove to it that the proof that you gave to it wasn't actually valid. And if that passes, then the coins are allowed. This is all fundamentally limited by the insecurity of the testnet network itself, because testnet only has a few users itself and it's not really a decentralized system, and the security is not really good. So really all of these steps don't make it secure on testnet because testnet itself is insecure.

So one thing that comes up here is wait a minute I thought you said in the sidechains whitepaper that Bitcoin smart contracts system had to be improved and fixed before it could handle this two-way peg mechanism? And that's true. So in the appendix A of the whitepaper, we described a federated peg mechanism which is a sort of "step in alternative" to the true two-way peg mechanism which works without any changes at all in the hosting network. So the way that the federated peg works is that there is a federation group of computers, called oracles, that execute the same rules that we would like the testnet network to run, but which it doesn't currently run because the rules haven't been changed. So you can think of this as a centralized protocol adapter that allows the two things to talk absent native support.

The federation uses multisignatures, so it's an N-of-M threshold and the participants in it have no disgression. The rules are defined by the rules of the system. The users of the sidechain can mechanically detect rule violations on the sidechain. But if a super-threshold set of the functionaries or these parties with no disgression in the federation, if they are compromised or misbehave, then they can steal the coins on the sidechain network, and this is one of the limitations of this federated peg workaround.

In the case of the Elements alpha network, we are using a hybrid where the direction from the elements network back to the testnet uses functionaries, but the direction from testnet into the elements network is autonomously verified by the participants in the elements network. This work with the deterministic two-way peg and its implementation was done in principal by Matt Corallo.

The next element I would like to talk about is issued assets. Bitcoin brought us these ideas of smart contracts enforced trustlessly by the bitcoin network. Ultimately the bitcoin network can only control the disposition of the bitcoin currency but not other assets. You can imagine using smart contracts to build things like trustless exchanges for one asset to another, building derivatives... Since the bitcoin network can only control things in it, and it can't reach out to the rest of the world and control things, it means that in order for the smart contracts to be used they must nbe used with assets in the system. So the network has to understand the component assets. A synthetic asset is like a token that can be redeemed for one car or some amount of bitcoin that changes over time. So the way that you would make an asset in a cryptocurrency network like a car, to be an actual interesting thing, is this idea of smart property. The idea here is that you could build the car, vending machine or other device to watch the bitcoin network, and uses information in the bitcoin network who its owner is, which key would start the car.

There are other ways to do issued assets on the bitcoin network. There is a proposal called colored coins which has been deployed for a number of years with some amount of use. But colored coins have a number of problems, for one they are incompatible with this communication-efficient payment verification mechanisms like SPV in Bitcoin which is pretty important when you want to have a vending machine or car to decide whether its ownership is changed. You don't want the vehicle to have to download the entire bitcoin blockchain to trace its ownership. Colored coins also result in the creation of many tiny amounts of bitcoin in the network that are used for tracking value. Now, bitcoin remains valuable so as long as people want bitcoin and as long as the bitcoin network exists and people are using it, but a proxy asset for bitcoin using colored coins may lose its value, maybe the car its representing in the system becomes destoryed, and wit hcolored coins there is no mechanism in bitcoin to have a different retention policy for different assets. Fundamentally, colored coins are invisible to the colored coins network. And smart contracts in bitcoin cannot be made aware of the colored coins, you can't write a contract that says I will trade 1 BTC for 1 FOO because it has no idea that a FOO is involved in the transaction. If a colored coin system was constructed correctly, it could have a very strong censorship resistance because other participants in the systme wouldn't be able to block colored coin transactions if the system was built that way, but the existing colored coin systems are not built that way anyway.

So the idea behind the issued assets functionality in Elements is to explicitly tag all of the tokens on the network with an asset type, and this immediately lets you use an efficient payment verification mechanism like bitcoin has today. And then all of the accounting rules can be grouped by asset type. Normally in bitcoin your transaction has to ensure that the sum of the coins that comes in is equal to the sum that come out to prevent inflation. With issued assets, the same is true for the separate assets, such that the sum of the cars that come in is the same as the sum of the cars that come out of the transaction or whatever the asset is. So to issue an asset on the system, you use a new special transaction type, the asset issuance transaction, and the transaction ID from that issuance transaction becomes the tag that traces them around. So this is early work, just the basic infrastructure for it, but there's a lot of neat things to do on top of this. This is mostly the work of Jorge Timon.

The next element that I am going to talk about is relative check-locktime. Today in bitcoin, transactions have a good-after date, a sort of time criteria after which the transaction is good and before that it could not be confirmed in the network. Many fancy contracts that people would like to create need a refund to avoid holdup, so if I am going to place some code in escrow and transfer it out in some conditions, I want to make sure that if those conditions are never met that those coins come back to me in some amount of time. CHECKLOCKTIME allow you to provide a constraint on that good-after date. There is a current proposal, BIP65, to deploy CHECKLOCKTIME in the bitcoin network and it may be available sometime this year, although we don't know when it will be deployed exactly because it has to wait for some other features in the system. This absolute CHECKLOCKTIME is immediately available in the Elements network time. Going beyond absolute CHECKLOCKTIME, it would be very useful to support relative times. The idea behind the relative time is that the coin starts ticking not at a fixed time but when some other event has occured in the network, like another contract or transaction. Each input coin has a 32 bit sequence number, the original idea was that you could increment the sequence number when you issued a new version of the transaction and someone would take the final version to the network, but there was no enforcement of that monotone update to the bitcoin network and there was no obvious way to enforce that. You could make an updated transaction, but the person that you were transacting with may have preferred an older version and could have take ntaht other transaction to the network instead, so you couldn't count on it to do anything useful. Relative checklocktime redefines this sequence number, when it's at the maximum you can then spend it whenever. When it's one less than the maximum, then it must be spent one block after, if it's two after then it must be two blocks later, and the point is that as you increase your sequence number you increase the earliest time that the coins can go into the network. The latest version of the transaction is the one that can go into the blockchain network. This is a technique used in a proposal called the lightning network to achieve very high scalability off of the main bitcoin network.

The next element I would like to introduce is segregated witness. This is somewhat of a technical name. First I am going to explain what we are trying to accomplish. When you approve a transaction, you are providing a set of inputs that satisfy the rules on the contract you are spending, so you are providing a signature and then the netowrk checks the rules and sees whether the inputs match the rules. Well what happens when you take a valid transaction in the network and you change those inputs, you modify them and encode them differently, where they have been changed but are still valid? This can be done, what happens is tha tit changes the ID number of transaction but nothing else. It doesn't change what the transaction does or anything else, it just changes the ID number. Changing the ID number breaks many applications in bitcoin, it confuses accounting, and it also means that if you are making a multi-step dependent sequence of trnsactions that sine eache etransaction references each other by ID, that feature can be used to attack the network. Because of the way tha the flexible contract system works is that it is almos timpossible to fix malleability, and there's BIP62 that tries to define exactly how th etransaction needs to vbe encoded, and it's kind of complicated and that's why the proposal has not been deployed on the network... So witness, is a mathematical term that refers to a specific value that is a concrete proof of an existential plan, there exists an X such that F(x) returns true, that value x is a witness. The signature data, the inputs in the bitcoin transaction, can be thought of as a witness of the validity of the transaction. We use the term witness to distinguish the scriptsig data from the basic digital signature system. Bitcoin doesn't care what the witness is, it just cares that the trangsaction is valid. If you are not verifying the network history, you can skip downloading this data and the witnesses, and the witnesses are about two thirds of the data in the blockchain. You can't skip downloading these right now because you need these to compute and check the transaction IDs. What segregated witness does is change hte transaction ID formula, into just the witness and all the scriptsig fields, and the transaction which is everything else. The transaction ID should only cover the transaction itself, and not the witness itself. The blocks still commit to the witnesses that were used, which is useful for forensic reasons, like checking who signed off on a transaction and you want to see which 2 of 3 signed a transaction, you need to check the witness. It can be committed in a block that lets you skip it if you are not interested in. You can synchronize without transferring that data, saving you 2/3rd of the bandwidth, and it eliminates 3rd party changes to the transaction system. This has been the work of Pieter Wuille.

The next element that I would like to talk about is Script enhancements. I have talked about smart contracts in Bitcoin that is built in cvalled Script. Bitcoin script was originally much more powerufl, a bit too powerful in fact, it allowed people to crash nodes and steal coins, which most people considered undesirable. These bits of excessive power were removed with emergency repairs to the system, where many operations were removed completely from the system. These operations were not technically hard to fix, but it was kind of an emergency so they were removed, but they could be restored without much effort, especially if you didn't care about compatibility with the existing system. Nobody is using functionality that isn't there, and it's hard to justify the risk of putting in functionality that people aren't yet using. And people have tlaked about replacing it with a much more powerful script system, and that has a lot of interesting ideas, and that's a longer-term system. Well when we look at the element system the whole idea was that it is cheap, so why not experiment with turning on other scripting features? So we re-enable all of the disabled op-codes, like concatenation, substring, bitwise operations like AND OR XOR, and there's a lot that you can do with this... you can make an efficient 1-of-1000 multisig, trustless lotteries and well I'm not sure, it will be interesting to see what people do with it.

We also replaced the ECDSA signature system with Schnorr, we are using the same cryptographic curve but the security proofs are more strong and more convincing. It also supports an efficient multisig, where you can use only the same amount of data as 1-of-1 but have a 20-of-20 threshold. Schnorr also does efficient batch-level verification of data. So the network can verify many transactions at once much faster than it could verify one at a time, and this is about a 2x speedup. We also add the ability to check signatures on data on the stack other than the transactoin data itself, and this allows you to build bonds on good behavior, so you could say here's some bitcoin on the network that you could be paid if you prove the same contract was signed twice by some party. This has been the work of Patrick Strateman.

The signatures in Bitcoin only directly cover the amount tha the transaction is moving, indirectly, by signing the transaction ID of the originating coin. So if you have some hardware wallet device that has some rules or conditions on what the amount of coins it could move or pay, the only way to enforce the rules is to prove to it that the value of the transaction is to stream all of the input transactions into the device; you could construct osme contrived cases where the amount of data you have to stream in is a gigabyte data. If you are not worried about compatibility, you could change the signing algorithm so that the signature covers the amount you are spending, and so if you are lying to the device, the signatures wont be valid and the transaction can't go through, and the rules can be enforced that way. This work has been performed by Glenn Willen.

The next element I would like to talk about is federated consensus. Bitcoin uses decentralized consensus, which is absolutely essential for holding Bitcoin's values and ethos in the wider world. It's what makes the system resistant to outside influence, political meddling and it's what makes it trustworthy. We're not even sure if it works in bitcoin, though. So it's hard to apply it to another network that is parallel to Bitcoin, but maybe the consnesus system of bitcoin doesn't work. What does decentralized consensus mean for a private network? It's not clear whether it's even possible to use decentralized consensus in a small low-value private network. Even if you were trying to use decentralized consensus in a small network, then how do you bootstrap it? .. because decentralized consensus is only secure if you have economic incentives in place. There are many other mechanisms for consensus that others have proposed. In the sidechains whitepaper, we formalized bitcoin consensus by calling it a dynamic membership multi-party signature (DMMS). The idea here is to say that the blocks are on the network are valid only if a threshold number of parties have signed it, and which group well it's dynamic. So what if you take that idea of DMMS and replace it with a static plain signature, and the result is a centralized system which is better than just trusting a single server. It's a system where you can have real-time auditing by most participants, and where dishonesty is machine detectable. Censorship is not machine-detectable in this system. You can build this with an arbitrary multisig policy, you could have a rule that says if an auditor or 5-of-8 sign on it, or 8-of-8 sign off on it. This approach does not require any human discretion, we could potentially implement it on tamper-resistant hardware to make it more secure, and some applications need trust. Trust is inherently a bit of centralization, but if you are trading around a digital proxy of gold, which requires someone to eventually redeem those tokens for gold, and if you have trust then why not make use of it. This has been mostly the work of Jorge Timon.

So the next part of the elements network is this functionality called confidential transactions. So traditional transaction systems for money provide at least privacy. So when you transact with money in the bank, the only parties that know about the transaction are you, the bank and the counterparty you are transacting with, and whoever the bank tells. The rest of the world does not learn about your transaction and they do not learn about your bank balance. And this is actually essential for both commercial and personal use. For some basic level of privacy, thieves can target money, and fraudsters could use information to fraud people. Commercial deals could be undermined if your counterparty knows how much you can spend. If your landlord knows you just got a raise, then maybe they could hit you up for a bigger bid. And a loss of privacy loses fungibility, and that's an inherent property of money. If each bitcoin has a history and people know how it's used, then maybe some people wont want some bitcoin. It's often presented as if there's a conflict here; where the network operates like a bank, and the bank can see all your transactions, so people say well isn't it that the bitcoin network has to see the transaction. Surprisingly, no. Privacy is completely compatible with public verification. An easy example of this is digital signatures, where you can sign a document, and your signature proves that you know your secret key, and that you approved the document, but it doesn't disclose anything about the secret key to the rest of the world. Verification does not have to be in conflict with privacy. We just need the right technology.

Bitcoin uses pseudonymity to handle the issue of privacy. The idea is that the bitcoin users rather than having persistent identities, would use single-use addresses that they would throw-away after use, and then you wouldn't know which address belonged to which user, and you would have some level of privacy. This approach is fragile. Once you pay someone, they know who you are because you transacted with them. They can look at your transaction history to make a good guess what your financial history is. You can leak this information to everyone, and they just have to attach your name to one address and they get all of the other details. When we ask institutions about using bitcoin, even the most boring institutions look at this and say we don't want to use all of our transactions in public. Often we like to talk about the advantages of transparency and how great a public ledger is. Transparency goes both ways; it is not in control of its users, transparency can exacerbate power imbalances. A government might be able to afford to go micromanage and check all of your spending, but you can't afford the time to go check all of its transactions. So transparency does not always work to your advantage. Also, data is not wisdom and so when you receive this raw information from the network, it doesn't necessarily mean or tell you anything. Real transparency requires a conscious effort.

Some people owrry about harmful uses of privacy. People who are stealing money can already buy their way into privacy in other networks and don't need to use Bitcoin. When I work in the IETF with other long-time developers of the protocosl of the internet, there is almost a ubiqituous regret that we built an internet where encryption wasn't a default and always on. And there was always a reason for this: it's complex, it's slow, it's incompatible with stuff already deployed. This is all true. But when we look at this history, these reasons were insignificatn and we should hvae taken the cost 10 years ago to make encryption the default. As time goes on, it becomes harder and harder to deploy pervasive encryption. And it is universally recognized as a regretful scenario. I don't want to make the same mistake wit hmoney. I think that if bitovcin were going to displace other forms of money, we need to improve privacy.

There have been many privacy proposals, I classify them into two groups. The compatible group and cryptographic group. The compatible group are features that work without change in the existing bitcoin network, like CoinJoin and CoinSwap, and centralized servers. And then there are these cryptographic solutions like ZeroCoin, OWAS, Traceable ring signatures, zerocash, and these usually ... the compatible solutions usually suffer from low privacy, and the amounts are unmasked or break the privacy. Cryptographic solutions where the greatest functionality is-- pruning. This is where a bitcoin node has the ability to forget the past. It can vlaidate new transactions without remembering all of the transactions that came before it. Pruning is essential to scalability. You need nodes to forget. The cryptographic system can hide which coins have been spent. We need strong new cryptographic assumptions, which may turn out to be broken later. So the work on cryptographic privacy in bitcoin is focused on protecting the flow of coins from one party to another, this is like metadata for phone records or internet traffic. For cryptograpihc privacy on the internte, we almost never make metadata private. Instead of protecting the metadata, what if we protect the content? It's the destination and amounts, how much is being transferred? If you use pseduononymous addresses and don't reuse them, the amounts are not private. If you think about it, the amounts are more important to keep private, when you transact iwth someone they know who you are but you would like to keep your balance private. It's possible to do this. We replace the amounts with 33-byte commitments, which are like a cryptographic hash, which are blinded by a blinding fee, and the commitment scheme is the one that preserves addition, that says that two committed values when added together is equal to the two values. So this approach was proposed by Adam Back in 2013 and a bitcoin talk. There is some challenge with making this work. In order to make this work, you have to deal with the case where the output of the transaction could potentially be negative. We are trying to verify that the sum of the inputs is the sum of the outputs. A -10 BTC output and a 13 BTC output, both sides of these equations do add up, but what that does is just create a whole bunch of BTC out of thin-air, to prevent someone from creating bitcoin out of thin-air, we need something called a zero-knowledge range proof and that's something that allows you to prove to someone that a value is within some range, without actually specifying what the value is. There are many techniques in the literature for range proofs, but they have challenges for efficiency. So I invented a generalization for a cryptographic ring signatures and a number of other optimizations in order to make range proofs which are more efficient. And I built a system where you can decide how private you want your outputs to be by choosing the range proof, and where the range proof has an exponent, and you can choose the range you want to specify. You can build a 32-bit range proof, which is large enough for a 42 BTC or a 429 BTC or 4,249 BTC amount, depending on what you have chosen for your precision, you can build one of that size in 2.5 kilobytes, which we can realistically use in the public network. Then I came up with a scheme to take those same 2.5 kilobytes to take it and deploy it for another application. You can use those 2.5 KB to communicate a private message to the payee to the transaction. Only the payee will receive this message. They can slip in this message. This is 80% efficient, most of the size can be used for this. People often want to add new messages to the bitcoin transaction, and it's hard to stomach that because all of the participants have to store that data, but if it's a side-effect of range proofs then great. So this approach is compatible with watching wallets, which is the ability for to give a key to a third-party so they can audit your payments without your ability to spend your coins, and it's also compatible with transparency because you can share your blinded values with whoever you want to prove that you sent those amounts, and this is completely up to you. And this has primarily been my work.

So where do we go from here? I am personally planning on refining and improving these elements to create many more of them, and I am looking forward to seeing what happens on the test network. I think it will be used in many interesting new ways. I am curious if other peoples will see and use this new technology to not seek permission or reboot the network effect, or restarting adoption. This potential might bring more development to the space and I look forward to finding out.

Thanks.