path: root/transcripts/gmaxwell-confidential-transactions.mdwn

Confidential transactions

gmaxwell

2017-04-28

<https://twitter.com/kanzure/status/859604355917414400>

<https://www.youtube.com/watch?v=LHPYNZ8i1cU>

# Introduction

Thank you.

So as mentioned, I am going to be talking about <a href="https://people.xiph.org/~greg/confidential_values.txt">confidential transactions</a> today. And I look at confidential transactions as a building block fundamental piece of technology, it's not like altcoin or something like that. It's not a turnkey system, it's some fundamental tech, and there are many different ways to use it and deploy it.

My interest in this technology is primarily driven by bitcoin, but the technology here could be applied to many other things, including things outside of the cryptocurrency space.

So I want to talk a little bit about in detail about what motivates me in on working on this and why I think it's interesting. What does CT do? What are the costs and benefits of a system like CT in bitcoin? I want to talk about extensions and related technology, and maybe also the prospect of using CT with bitcoin in the future. I also have some slides to go into more detail about how CT works in more technical detail, but I'm not sure how much interest there is in getting into the really deep details. I am seeing some thumbs up, so lots of details. We'll see how the time works out on it too, because I want to leave some good time for questions and such. And if I start blabbering off in space and someone is confused, then please ask me to clarify.

# Why confidential transactions?

CT is a tool for improving privacy and <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/fungibility-overview/">fungibility</a> in a system like bitcoin. Why is this important? If you look at traditional systems, like banking systems, they provide a level of privacy in their systems. And when you usually use your bank account, your neighbors don't know what you're doing with your bank account. Your bank might know, but your neighbors don't. Your counterparties know, other people generally don't know. This is important to people, both for personal reasons as well as for commercial reasons. In a business, you don't want your competition to know who is supplying your parts. You don't want to necessarily share who is getting paid what. You don't want your competition to have insight into your big sales or who your customers are and all that. There is a long list of commercial reasons as to why this kind of privacy is important.

Personally as well-- if you think about it, in order to speak as a person to speak up in the political sphere, to have an effect on the world, you need to spend some money to do it... so this is basically you have the case that you're spending of money is intricately tied to your ability to have free speech in the world. If someone is able to surveil and monitor and control your use of money all the time, they are also controlling your ability to speak. This is also the opinion of the U.S. Supreme Court in Citizens United and a lot of people on the more liberal end of the spectrum don't like this conflation of money and free speech but it cuts both ways. People should have a high degree of financial privacy, and they can't have that if they are using a system that doesn't provide that.

In bitcoin, we have this fundamental conflict where we have built this decentralized distributed network, and it's security is based on this concept of public verification: you know bitcoin is correct because your own computer running software that you or someone you trust has audited, has verified all of this history of it, and has verified that it all adds up. That all the signatures match, that all the values match and it's all good to go. It uses conspicuous transparency in order to obtain security. Many people look at this and say ah there's a conflict we can't both have strong privacy and have this public verification needed for a decentralized system. But this apparent conflict is not true. If you think about the idea of a <a href="https://en.wikipedia.org/wiki/Digital_signature">digital signature</a>, that is a scheme that lets you sign a message and show that a person who knows the private key knows the message, we use this every day in bitcoin, you can use this to verify a digital signature without ever knowing your private key but they can verify that you knew it. So a digital signature showing that, you can build a system that can be publicly verified but without giving up your secrets. This shows that it is possible.

This whole idea of a system of money needed some kind of privacy-- that's not a new one. It's discussed in the bitcoin whitepaper, where it says that you can basically use pseudonyms, one use addresses, in order to have privacy in the system. The challenge that we found is that this is very fragile. In practice, the pseudonymity in bitcoin doesn't actually provide a whole lot of privacy. People reuse addresses and then it's really easy to trace the transaction graph through the history. The way that the earliest bitcoin software was written, you didn't usually pay to an address directly, you would provide an IP address, then your node would go to the other node and get an address from it, and then every payment would use a new fresh address on the blockchain. That was a much more private way of using things, but it required that to receive payments you had to run a node exposed to the internet not running behind NAT. So not very usable. And that whole protocol in fact was completely unauthenticated, so it was very vulnerable to man-in-the-middle attacks as well. That wasn't a good way to transaction, and as a result people started using bitcoin addresses for everything, and the address model ends up causing lots of reuse and things that really degrades privacy.

When I have gone out and talked to institutions outside of bitcoin in the wider world and talked about using bitcoin itself as well as using blockchain sort-of technology adopted from bitcoin, one of the first concerns that many boring institutions like banks have brought up is this lack of privacy, from all these commercial angles, not necessarily protecting personal rights, but keeping your business deals secret is sort of the bread and butter of commerce. So the transparency that bitcoin provides is often touted as a very powerful feature, so that everyone can see the blockchain and it's transparent-- but transparency is a feature that cuts both ways. Having an open blockchain doesn't necessarily mean your activities are transparent. You have an open blockchain, and everyone can see the transactions, but it doesn't mean they have any wisdom. Right. It is not knowledge. Knowledge is not wisdom. And so this very open nature of bitcoin, unless people take action to turn this openness into transparency, isn't functionally transparency, and the lack of privacy in bitcoin exacerbates existing power imbalances.. If you're just some nobody and someone wants to block your transactions and mess around with you, you're made more visible by the fact that your transactions are visible. And, some people are concerned about more harmful users, like users that want to use cryptocurrencies for immoral activities -- it might be argued that their lack of privacy is a feature. But it turns out that people doing criminal activities have money to blow, and they can afford to purchase privacy via expensive means regardless. They don't look and say oh bitcoin isn't private I guess I'll just have to make all of my criminal activities visible, no that's not how it works. Certainly less privacy in bitcoin can make investigations in bitcoin easier at times, but it doesn't fundamentally block criminal activity. So in my view, when we don't have good privacy in a system like bitcoin, the criminal activity still occurs it's just that everyone else who can't afford to get privacy that suffers from the lack.

And a key point that I don't have in the slide here that I should mention is that privacy is integrally tied to <a href="http://diyhpl.us/wiki/transcripts/bitcoin-adam3us-fungibility-privacy/">fungibility</a>. The idea behind fungibility is that one coin is equivalent to every other coin, and this is an essential property for any money. The reason why it is essential is so that when you get paid, you know you've been paid. If instead you were being paid in a highly non-fungible asset like a piece of art or whatever, you might receive the art and think you were paid and then later find out the art was a forgery or you find out it's stolen and you have to give it back. And so, that art doesn't work as well as money, one piece of art isn't the same as another piece of art. The more we can make our money-like asset behave in a fungible way, the better it is. And this is a well-recognized legal and social concept elsewhere. The US dollar is not physically fungible... one dollar is very different from another dollar, in fact they are serialized and have serial numbers, but for the most part as a society we are willfully blind to the non-fungibility of the dollar bill, because if we say hey this dollar is counterfeit but it's unidentifiably counterfeit so it's no good, then the dollar breaks down as being a useful money. And so we ignore those things, and in cryptocurrency we need to do a degree of that as well, if you want cryptocurrency to function as money.

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=10m24s>

There have been many past proposals to improve privacy in the bitcoin space. Many people have recognized there's a problem here. People have done things like, proposals to combine <a href="https://bitcointalk.org/index.php?topic=279249.0">coinjoin</a> and <a href="https://bitcointalk.org/index.php?topic=321228.0">coinswap</a>, which are completely compatible with the existing bitcoin system and use some smart contracting protocol trickery to increase user privacy. People have also used things like centralized servers where you trust a third-party, you give them the money, they make the payments for you, and that can at times improve your privacy except at the central server which usually destroys your privacy along the way. There have been cryptographic proposals, there's a proposal called zerocoin which is distinct from the zerocash stuff that exists today, which had poor scalability but interesting privacy properties. There's an interesting not-well-known proposal called <a href="https://bitcointalk.org/index.php?topic=290971.0">one-way aggregatable signatures (OWAS)</a> which showed up on bitcointalk from an anonymous author who vanished (<a href="https://bitcointalk.org/index.php?topic=1377298.0">follow-up</a>). It's a pretty interesting approach. There's the traceable ring signatures that were used in bytecoin, monero and more recently in zerocash system which is now showing up as an altcoin. The compatible things-- like coinjoin-- have mostly suffered from not having as much privacy as you would expect, due to transaction amount tracing. The idea behind coinjoin is that multiple parties come together and they jointly author a single transaction that spends all of their money and pays out to a set of addresses, and by doing that, an observer can't determine which outputs match with which inputs so that the users gain privacy from doing this, but if all the users are putting in and taking out different amounts then you can easily unravel the coinjoin and the requirement to make the amounts match to prevent the unraveling would make coinjoin hard to be usable. And then, prior to confidential transactions as a proposal, the cryptographic solutions that people proposed have broken the pruning process in bitcoin. They really have harmed the scalability of the system causing the state to balloon up forever. Today you can run a bitcoin node with something like 2 GB of space on a system, and that's all it needs in order to validate new incoming blocks and that's with all the validation and all the rules no trusting third parties. And if not for pruning, then that number would be 120 gigabytes and rapidly growing. Many of these cryptographic privacy tools have basically broken this pruning and have hurt scaling... the exception being the more recent <a href="http://diyhpl.us/~bryan/papers2/bitcoin/TumbleBit:%20An%20untrusted%20bitcoin-compatible%20anonymous%20payment%20hub%20-%202016.pdf">tumblebit</a> proposal, and <a href="http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/tumblebit/">tumblebit</a> is a proposal like coinswap that allows two users to swap ownership of coins in a secure way without network observer being able to tell that they did this. Tumblebit improves the privacy of that by making the users themselves not able to tell who the other users were, and tumblebit doesn't break scalability, but because it only does these swaps and a few other things, it's not as flexible as many of the other options.

# Confidential transactions

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=13m37s>

What confidential transactions, what does it do? So the prior work on improving privacy in cryptocurrency systems has been entirely focused on or almost entirely focused on making the transaction graph private. It's addressing the linkage between transactions. And this is kind of odd, because if you think about internet protocols, the transaction graph is like metadata: who's talking to who. And metadata is absolutely information that needs to be private. But normally when we communicate on the internet, we don't worry so much about making our metadata private, unless we use something like tor. We normally use SSL which makes the content of our messages private. Well the content of a transaction is the destination and the amounts involved. That's really the transaction. And the prior privacy schemes, most of them didn't make the content private, which is a little surprising. If you use one-use addresses, the destination is inherently pretty private, but the amounts are not private. In fact, in many commercial contexts at least, the amount is even more important to keep private. Knowing that Alice is paying Bob is somewhat interesting, but knowing that Alice is paying Bob $10,000 dollars is much more interesting. The amounts are pretty important. And one of the things on my slides a couple back I didn't mention is that one of the things we worry about in bitcoin in particular as we watch the market price rocket up, is the security implications of owning bitcoin. If you own a bunch of coins, you generally don't want the world to know about it. And if you go into a Starbucks and try to pay for something with bitcoin, you make a transaction and your transaction moves 1k bitcoin at a time, you have to worry that maybe the barrista is out back calling his buddies to mug you and take your phone or something. So making the amounts private is important.

That's what confidential transactions does. It makes the amounts private. There are many benefits to this. The way that this works is that there's normally in a transaction an 8-byte value that indicates the amount of the output, and that 8-byte value is replaced with this 33 byte commitment which is functionally like a cryptographic hash. Instead of putting the amount in the transaction, you put this hash of the amount in the transaction. And these commitments have a special property that, the hashing process preserves addition which means that if you take the hash of one amount and the hash of another amount and add them together, you get the hash of their sum. This addition preserving property is what allows the network to still verify that the inputs and the outputs still match up. This is why CT can be verified by a public network even though the information is private.

Using this kind of scheme for bitcoin was <a href="https://bitcointalk.org/index.php?topic=305791.0">proposed by Adam Back in 2013 on bitcointalk</a>. I assume these slides will be made available online, there's links on all of these things too. And Adam's post is really hard to understand and even for me.. Just knowing that he said you could do it, I went and reinvented the scheme and also came up with a much more efficient construction than he had proposed, and in fact the constructions I used for CT were by a large factor more efficient than any system in the literature previously, and that's required in order to possibly begin to think about using these things in a large scale public system such as bitcoin. I'll talk a little bit more about that.

# Costs

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=17m19s>

* No new cryptographic assumptions: CT is secure if secp256k1 ECC signatures are secure (or even better).

* ~66% increase in UTXO size (addition of 33 byte 'CT amounts')

* 15x-20x increase in bandwidth for transactions

* 30x-60x increase in validation costs. Not an issue for high end hardware especially due to validation caching, but a problem for low end hardware.

* Addresses which are ~twice the length.

* Moderate code complexity (+1.4kloc crypto code)

So on that subject of costs, doing this stuff with the hidden values isn't cheap in this system. The end result is that on the plus side we can do it with no new cryptographic assumptions by which I mean that CT is completely secure so as long as our ECC signatures are completely secure. And in fact we can do even better so that CT is completely secure against inflation even if ECC is completely broken and I'll talk a bit more about that. So that's the good part.

The downside... so it's roughly on order of a 66% increase in the UTXO set size. That's manageable, that's about 2 GB right now and maybe doubling it, that's reasonable. But it also results in something of the order of a 15-20x in the amount of bandwidth required for transactions. Now, CT is completely prunable so you don't have to keep that data around, but you do have to keep it temporarily.

It also results in according to signature validation a 30-60x increase in validation cost. So if you could assume that all your nodes are high-end hardware and they aren't going to validate old history, taking a 30x increase in validation cost is okay because there is extensive caching in bitcoin node software.

Also it results in addresses that are 2x the length because CT needs to include an additional pubkey in the address which is used to encrypt a message to receiver to tell them how much you're paying them or else they wouldn't know.

There's a complexity hit, my implementation adds about 1400 lines of code, this is pretty small compared to the rest of the crypto code in bitcoin, but it is a cost. It's as small as it is because I was able to leverage existing infrastructure in bitcoin code.

# Benefits

What benefits do we get out of this? Well, the amounts are private, and that has some direct effects. In many cases you need fewer transactions or outputs in order to preserve privacy. Today if you were to do something like decide to pay all your staff in coins and didn't want to disclose how much your staff was paid, you would probably get your staff to provide you with lots of addresses per staff member and then you would pay the same amount to different addresses, and the people who get multiple transactions would get different total payouts. That would be reasonably private, until people go and spend those outputs in groups and reveal some of it, but it would be very inefficient because it would require larger transactions to execute that scheme. So I think making outputs private really does solve many of the commercial problems. That's the big win directly.

On the privacy that CT provides, it's controllable by the user. The sender obviously knows what he sent, the receiver knows what he received, but additionally the sender or receiver can show to any third party all the details of the transaction to show and prove that a payment happened, or publish it to the world. My ability to prove a payment is not reduced by CT. Moreover, it's straightforward in the design of CT to share a per wallet master key with an auditor and the auditor could see all the information. You control that.

One of the side effects of the design is that there's this, I mentioned this 15-20x increase in transaction bandwidth because of larger transactions, but 80% of that increase could be used to communicate a private memo from the sender to the receiver. This private memo can contain structured or unstructured arbitrary data from one side to the other. In the typical transaction there would be several kilobytes of memo field. Unfortunately we can't eliminate this data overhead, but we can get dual use out of this-- it's part of the cryptographic overhead for CT, but it's also let you send data.

One of the other benefits of using CT in a system is that it's quite straightforward to do private solvency proofs over CT (Provisions 2015 paper). If you were to imagine that if bitcoin was using CT today, you would be able to construct a proof that says I own 1000 coins, at least 1000 coins, out of the set of all coins that exist, if everyone was using CT, the privacy set of that would be all the coins, and you could prove this to someone without revealing which coins are yours, and even without the amount, you could reveal just a threshold. You could build a system that in a bank-like situation, or an exchange, you could show that the users account balances all add up to the sum of the assets without showing what that sum is. So you could say something like Coinbase for example that the users account balances add up to the sum of the coins that Coinbase holds, without revealing the total number of users or total amounts. It's possible to do this with bitcoin without CT by layering CT on top of it, but you don't get a full privacy set because if you're the only person using that privacy proof system then you would be easily discovered so it doesn't add much privacy on the full set.

# Benefits: Metadata privacy

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=23m10s>

So, I said that CT provides value privacy, but in fact it also indirectly provides metadata graph privacy. The reason for this is that the existing compatible non-cryptographic proposals like coinjoin for graph privacy are primarily broken by their lack of amount privacy also their usability is broken by their lack of amount privacy. Coinjoin and CT can be combined so that you can have multiple people that collaborate together to make a transaction, nobody learns any amounts, and the observer doesn't learn the matchup between inputs and outputs. You lose the coinjoin problem where inputs and output values have to match. So if you do this scheme, you can get metadata privacy and get amount privacy, it preserves the properties of CT alone. This is true for coinswap and tumblebit and many other techniques.

# Benefits: Scalability

Although CT has significant costs, I would actually say that one of CT's advantages is scalability. The costs involved in CT are constant factors. Pretty big constant factors, but they are constant, they don't change the asymptotic scaling of the system. All of the overhead that CT creates, or almost all of the overhead, is prunable. So it will blowup the history of the chain but the state required to run a node and continue verifying things doesn't increase that much. Other schemes for privacy result in perpetual growing states where you need to keep perpetual history on every node. CT + coinjoin and technologies based on it, like <a href="http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble.txt">mimblewimble</a> (see also <a href="http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2016-11-21-mimblewimble/">andytoshi's talk</a>), are the only strong privacy approaches that don't break scalability.

# Benefits: Decentralization offset

Another benefit you can see from looking at something like CT is something I would call decentralization offset which is we talked before about how fungibility is important but in systems like bitcoin there is risk that miners or other ecosystem players might discriminate against coins or be forced by third-parties to participate in discrimination. If they did that, and did it enough, it would degrade the value of the system, although it might be profitable for the participating parties-- perhaps they get paid by regulators or something to discriminate against coins. There was some prepub work in this MIT chainanchor paper where they have since removed this from their paper but they suggested paying miners to mine only approved transactions. My response is to not be angry about this, it's a vulnerability in the system, let's fix it. If the system is more fungible, then issues related to decentralization limits in other parts of the system are less of an issue, because all the coins look the same and therefore you can't discriminate against coins. So that's an advantage I think.

# CT soundness

I mentioned before that CT is at least as strong as ECC security but actually it's potentially stronger. The scheme in our original CT publication provides what's called unconditional privacy but only computational soundness. This means that if ECC is broken the privacy is not compromised, but someone could inflate the currency. What unconditional privacy means is that even if you were to get an infinitely powerful computer that could solve any problem in one operation, you still could not remove the amount privacy in CT. The privacy part of it cannot be broken. But it only provides computational soundness, which means that if ECC is broken or if someone has an infinitely powerful computer, they can basically make CT proofs that are false and create inflation. And it's fundamentally impossible for any scheme to achieve both unconditional privacy and unconditional soundness. It could miss both, it could have one but not the other, but it cannot have both.

For use in bitcoin, it probably makes sense to have a system that has computational privacy where if the crypto is broken you lose your privacy, but unconditional soundness where you know for absolute certainty that the coins cannot be inflated by the system. I am not too concerned about ECC in bitcoin, and even if it were to become broken, we have bigger problems to deal with. But, you know, for a system you want people to adopt, you have to answer FUD. Even if you could possibly have unending inflation in the system, hidden away, that would be a pretty good FUD point and I think it would be important for bitcoin to fix it.

When we first worked on CT, we knew that we could solve the soundness and make it unconditionally sound, but we thought it would make it significantly less efficient. It turns out that we found a way to make it equally efficient while preserving the unconditional soundness. And this is something that we have been working on for a while as well as Oleg Andreev for unconditional soundness for CT. We have some implementations that haven't been published yet that do this.

# CT vs Zcash

Now let me talk some comparisons of CT with some other technologies. And I'm talking about more the technology than the altcoin in cases where this stuff is implemented. Zcash uses some very modern cryptography to do some really cool stuff, and zcash directly hides the amount and the transaction metadata and hides it completely. Among all the private transactions in zcash, you can't tell what the linkages are between any of them. That's even stronger than coinjoin can provide. It's basically perfect from that perspective, but you always have to be careful when only thinking about a little perspective at a time. Zcash isn't unconditionally sound and cannot be made unconditionally sound with current technology, not even close. In fact, zcash requires trusted setup which means that a number of trusted parties have to get together, and if they <a href="https://petertodd.org/2016/cypherpunk-desert-bus-zcash-trusted-setup-ceremony">cheat</a> then they can break the crypto and make unbounded undetectable inflation. If there's a crypto break, or a trusted setup flaw, then it's really bad news. They had a ritual to increase trust in the trusted setup, but they have to redo this procedure to upgrade the crypto over time. So it's a vulnerability.

Zcash involves a growing accumulator so there's basically a spent coins list that all nodes must have. That spent coins list will grow forever. Zcash is not just using one new piece of crypto, it's kind of a stack of new crypto on top of new crypto. I spoke with Dan Boneh, the author of the pairing cryptography that zcash is based on, and I said well what do you think about the security of pairing and he said oh yeah it's great, then I asked well what do you think about the security of SNARKS which is the next layer in the zcash stack and he sort of shrugged and went "ehh I dunno, it's new". So, not to say it isn't secure, but it's really new, and that's a big hurdle.

There have also been recent advancements in breaking the kind of crypto that is used in zcash that will eventually require that they upgrade to a larger curve at a minimum. Right now they have something on the order of 80 or 90 bits of security which isn't really considered all that strong. Particularly with those upgrades, their verification speed is on par with CT, it would be maybe 25% in the future. Verification is similar but a bit slower.

The real killer for zcash in practice is that the signing speed is horribly slow, we're talking about minutes to sign a private transaction. Zcash ouldn't plausibly make private transactions mandatory because of that slowness and UX, and as a result it's option and as a result very few of the transactions in the zcash blockchain are using the private transaction feature. If you look at the raw numbers, it's 24%, but that number is misleading because miners are required to pay to a private address, but most miners are pools and the pools immediately unblind those coins and if you unseparate out the mining load then maybe it's in the order of 4% of zcash transactions are private. As a result, this anonymity set that this "perfect" anonymity system is achieving system, isn't that good. I think the idea is cool but it's not the kind proposal I would want to take to bitcoin today.

# CT vs Monero

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=32m22s>

Monero is another kind of altcoin that uses privacy technique that was first in bytecoin which is an altcoin with probably the scammiest launch of anything I have ever seen. But monero is the reboot of bytecoin that removed the ridiculous premine and 5 years of faked history and obfuscated mining code and who knows what else. But what was really cool about bytecoin was that it had cool crypto in it that hadn't been discussed. The idea behind bytecoin was that it used a ring signature and a ring signature lets you say I am spending one of these 4 coins and I won't tell you which one but I will prove to you that it hadn't been spent before whichever one it was. This hides the graph. The privacy of bytecoin and monero originally was really fragile and a vast majority of transactions were deanonymizable because of amount non-privacy which made things visible in the system.

More modern monero as of a few months ago is using CT, they have adapted ring signatures with CT for something called <a href="http://diyhpl.us/~bryan/papers2/bitcoin/Ring%20CT%20for%20Monero.pdf">ringCT</a> and it's sort of like how CT can be combined with coinjoin.

So this system has the benefits of CT but it also has the disadvantages of the ring signature and there's a forever-growing spent coins list. Monero today isn't unconditionally sound, but it could be, just like CT it could be upgraded to unconditional soundness. The crypto assumptions are the same as CT but they use the <a href="https://ed25519.cr.yp.to/">ed25519 curve</a> but otherwise it's the same crypto assumptions.

The other cryptographically-private altcoin that people talk about is Dash... but it's not cryptographically private at all. I had a slide about this that was just "Dash LOL". It's snakeoil. I'm beside myself about it, personally. What they have is a system like coinjoin, they nominate nodes based on proof of stake to be coinjoin masters, and then they have done this insecurely many times in the past I have no idea if the current version is secure. It's not on the same level as zcash or monero maybe it's better than doing nothing I don't know. LOL, right?

# Other risks

There are other risks with this technology. I guess I was talking about one of them right now. It's difficult to distinguish snakeoil from real stuff and vet claims. Maybe some of the stuff I said today was crap, like maybe someone will claim that I said CT is unconditionally private (which is something I said) but maybe because of the way it gets used it's not actually unconditionally private.... right, like it's hard to work out this stuff and figure out which complaints are legitimate, not too many experts, new area, many people that try to sound like experts, etc.

A big risk is that if you look at any of these other cryptosystems that the consensus part of it is itself a cryptosystem just like RSA or AES or whatever. The whole thing has to work exactly right, and if one part is wrong then it doesn't give the properties you think, and if you get it wrong, everything breaks. Complexity is the enemy of integrity, it's hard to verify it. It makes the system more complex. I'm currently aware of three and a half devastating failures in privacy improvement attempts... There's an altcoin based on the original zcoin proposal, where they had an <a href="http://www.businessinsider.com/typo-bitcoin-rival-zcoin-attacker-steals-400000-2017-2">inflation incident</a> where it had more or less like a typo made it possible for people to mint coins out of nothing. They let their system keep running, the coins inflated, then they said well OK now there's more coins. The loss was effectively socialized. Because this was caught fortunately due to some of the privacy limitations in the approach of exploiting it, the loss was found to be sort of small and it was possible to socialize it, but if they (the attacker) had printed billions and billions of coins, then that might not have been salvageable.

There's a system called Shadowcash which is a clone of the bytecoin-like monero-like ring signatures with no CT based on the bitcoin code base. And, it had no privacy at all. I don't know if the person building it was a complete fool or utter genius, but they managed to make a really subtle mistake that made it have no privacy.

These upgrades to monero called ringCT which is now deployed, the original version was unsound and could cause unbounded inflation due to basically a protocol design error. When they created ringCT, they didn't copy the design of CT, they reinvented it again but I guess I'm guilty of that too, but anyway they made the error while doing so, and it made it through Ledger journal peer review without being detected. Fortunately it was detected by the Monero team as well as someone at my company, Blockstream. Before it was implemented in the system and they fixed it, and as far as anyone knows, the system is currently sound, and that's my "half" one.

There's another system that is non-public but it will be public in a couple months that was a total break in one of these kinds of things. It isn't a concern now. But we have to learn from these mistakes as time goes on. (maybe <a href="https://www.reddit.com/r/Monero/comments/6buu5j/disclosure_of_a_major_bug_in_cryptonotebased/dhr9jj7/">this one</a>)

I don't really think that these privacy systems are really much harder than normal consensus work in cryptocurrencies, but the failures are severe and really hard or impossible to recover from, and it's a place where people are doing something interesting, it's not just the hot air stuff in altcoins, this cryptographic privacy stuff is real.

# Further enhancements: Mimblewimble

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=38m25s>

<http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2016-11-21-mimblewimble/>

I would like to talk about where we could go from CT today. Maybe I should have added a slide here to say where we currently are. I have published a high-performance implementation of CT and it's part of this demo called Elements alpha sidechain. It's used in our Liquid product, too. It's out there, it's available, it's described, it's been included in academic publications. It's real, it's still being improved. Well where can we go moving forward?

CT is pretty powerful when combined with coinjoin. But coinjoin is interactive and the parties have to be online and communicate with each other. Coinjoin can be made non-interactive, to allow miners to aggregate transactions to improve scalability and privacy. Some of the properties of this aggregation make it possible to sync a node without looking at history only looking at UTXO set but have same security as if you had inspected the entire history, without having to transfer the entire history. The downside is that the state size for the verifying node is massively increased. The end result is that if-- if bitcoin was mimblewimble from day one, the equivalent of the UTXO set size would be the size of the blockchain, but you wouldn't need the blockchain to sync a node. The asymptotics are good, the constant factors stink, and people are experimenting with this and enhancing this.

# Further enhancements: Multi-asset

<https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=40m20s>

paper: <https://blockstream.com/bitcoin17-final41.pdf>

CT is single asset like bitcoin. But it's possible to extend CT for many assets that could be kept-- and in doing so, you provide privacy for the assets being traded. For a low volume asset, just knowing that it's being traded at all is the really important thing that you need to keep private. Several groups have been working on this, Chain recently had an announcement about this, and Blockstream has been working on this and put out a paper at FC17 and put out a working implementation also a part of that Elements demo system.

I think this is a cool area and we'll see where it goes. I think it's very neat that you can just combine these approaches. Perhaps other things can be combined with it.

# Further enhancements: ValueShuffle

So I have mentioned many times that CT + coinjoin is pretty interesting. The normal way to do coinjoin in practice today is that you have the participants either pick a server and the server mediates it and learns things about the correspondence between users, and that's not good. It's possible to have a protocol where all the participants in the join work with each other and nobody learns the input-output mapping. I knew it was possible when CT was created, but I didn't work out the details. Fortunately, others have been working on this, and in particular the <a href="http://diyhpl.us/~bryan/papers2/bitcoin/Mixing%20confidential%20transactions:%20Comprehensive%20transaction%20privacy%20for%20bitcoin%20-%202017.pdf">valueshuffle</a> paper that works out how you can have a multi-party coinjoin with all the parties private from each other using CT.

# Further enhancements: Efficiency

The area where I have been focusing the most on CT is efficiency. The costs are constant factors but they are big and it would be good to get them down. We have schemes right now that can make them 20% smaller or the same size but unconditionally sound. There's more optimizations out there to be worked on. This is an area that Oleg Andreev at Chain has also been working on.

# Patent status

So I should mention about patents. I have <a href="http://diyhpl.us/~bryan/papers2/bitcoin/patent%20-%20WO2016200885%20-%20Cryptographically%20concealing%20amounts%20transacted%20on%20a%20ledger%20while%20preserving%20a%20network's%20ability%20to%20verify%20the%20transaction%20-%202016.pdf">patented</a> many of the techniques and optimizations in confidential transactions with the explicit intention and very loudly stated goal of using these patents to prevent other people from patent this stuff, and to commit to a patent nonaggression licensing scheme where anyone can use my patents as long as they commit not to sue each other into oblivion.

Blockstream has a very open patent policy that is purely defensive. It has been applauded by many groups, including the <a href="https://www.eff.org/deeplinks/2016/07/blockstream-commits-patent-nonaggression">EFF</a>. If it's not good enough for somebody, let me know and we can figure out how to make it better. We can't make the patent system go away, and it's a risk to any deployment of any complex technology. I previously worked on royalty-free multimedia codecs. I am one of the authors of Vorbis, the Opus audio codec, WebRTC and like anyone using Signal is using Opus. We used patents strategically in Opus to get other patents opened. Trying to do the same thing with CT. I don't think anyone needs to worry about patents in CT. However, if someone is worried, then I would be happy to work with them to make the situation better for everyone.

<https://blockstream.com/about/patent_pledge/>

<https://blockstream.com/about/patent_faq/>

<https://defensivepatentlicense.org/license/>

# CT for bitcoin?

What about using this CT thing for bitcoin?

Well, you can use CT for bitcoin already with sidechains. And that's what we're doing with Liquid for example. You can build a system that trades bitcoin value, use CT to make it private inside that system, it's just not private going in and out of that system. If you want to talk about using T with bitcoin itself, the efficiencies are a big problem. There are some really cool tricks we can use to move around the costs in the system... in particular there is a notion that every spend creates a coin, it could be possible for miners to basically perform all the validations and if you make an invalid CT proof with your coin then the miner could publish a proof that your CT proof was invalid and then confiscate your coins for doing that, there could be some tradeoffs made so that not everyone has to make the CT tradeoffs and therefore make it cheaper.

Politics are a big hurdle-- some people don't want bitcoin to improve on the privacy aspects, and some people don't want bitcoin to improve at all. But I think that privacy and the existence of CT and sidechains and so on will remove these arguments. If bitcoin should use CT, and competing systems use it, I don't think it will take forever.

There are designs for <a href="https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html">soft-fork CT</a> and deploying it in a backwards-compatible manner, but right now they have some severe limitations, in particular if the chain has a reorgs once coins have been moved from CT back to non-CT transactions, the transactions around that reorg wont survive. Once you break the coins out of CT, you have to have a protocol rule to not spend the coins for like 100 blocks. This is the same issue that extension block proposals have, and is a reason why I have not been too supportive of extension block proposals in the past. If it's the only way to do it then maybe it's the only viable way, but I'd really like to find something better-- haven't yet, but there are many things that in bitcoin I have looked at and didn't immediately know how to do better until later.

So the tech is still maturing for CT. If the reason for it not be deploying right now is 15x, well is 10x enough? With improvements we can get this down to lower amounts. As the technology improves, we could make this story better. I am happy to help with other people experimenting with this. I think it's premature to do CT on litecoin today, Charlie, but I would like to see this get more use of course.

# Q&A

Why don't I go to questions? I have slides on more details and I am happy to answer questions even in email.

Q: Can you talk about range proofs about why they are needed and what they do?

A: Right, so let me go to my details slides. I'm going to do the fast description of what CT is doing. First my slides talk about you need a commitment scheme. This is a commitment where you say you have some secret text and a nonce and I want to prove to you that I have committed to the secret text without showing you the secret text. We can do this with a hash function. Take a hash of the secret text, give you the hash, and later I can show you the secret text of my nonce and you can verify it. That's a commitment scheme. For CT, we need a commitment scheme with the following property: the commitment of A, with its nonce, and the commitment of B with its nonce, is equal to the commitment of A + B with a nonce of nonce A + nonce B. We need that property. We can't get that with a normal hash function. So we introduce a thing called pedersen commitments. We reuse some properties of cyclic groups, ECC is one of these things. Whenever someone talks about ECC, if they start talking about actual numbers and doing arithmetic with the details behind the points, they're really sort of wasting your time because one of the key points of ECDSA and discrete log problem is that it's all based on abstract algebra, which is abstract, so the properties of algebra just generally work and you don't need to worry about the properties under the hood. A pedersen commitment is a commitment that has this additively homomorphic property, where you can basically take these commitments and add them up. Great, hooray, they can be added. The problem that arises is that the addition is cyclic like adding an unsigned integer on a computer it overflows, so if I make a transaction that overflows I could potentially create coins from nothing, like a negative overflowing value in the output and a 13 value out, and it all adds up to 0 and nets out, so I would have created 10 coins out of nothing or something. We have to prove that all of our committed values are in a range, so you know that if you have a bunch of small values they will still fit with 256 bits or something. So the range proofs are a way to prevent this over/underflow problem. And so, almost all of the performance cost and size of CT is in that proving that the value is small. So we have a scheme to prove that a value is either zero or another number, we do this with a ring signature and say that this pubkey is a pubkey that corresponds to a zero commitment or a 1 commitment and we just do this over and over again, we prove this value is 0 or 1, this value is 0 or 4, and we add them all up together, and we show that they are equal to the value we're talking about, and that it must be in range if it's built out of this OR. So a typical size for a range proof covering 32 bits is about 2. kilobytes. But we can recover 80% of that for a memo field. There's an optimization where most-- there's an exponent field, most bitcoin values are round numbers in base 10, so you can shift up your values by multiples of 10 in order to have a smaller proof that covers a larger range. If you add some more zeroes, it covers 42,000 coins instead, for example. So that's where the range proof stuff comes from.

more links: <https://www.youtube.com/watch?v=LHPYNZ8i1cU&t=51m9s>

Q: This might be a bit complicated, but can you talk some more about how you make the range proofs include arbitrary user-selected data, because that seems magical.

A: Yeah. I feel really clever for coming up with that. It's probably one of the things I am most proud of. It's actually really simple. I wish I had a whiteboard, but I don't have time anyway, in a ring signature most of the values used in it are dummy values, they are random, the signer picks random values, puts them in, uses their private key to solve one value and then sends it on. My message is signed by key A, key B, key C or key D. And the signature for 3 of the 4 dummies, and the 4th is computed based on the others. The other 3rd party observer must not distinguish them from random, so we can replace all the randomness in the range proof with an encrypted message that the receiver can decode. The receiver doesn't need this to be private because they know the value anyway. So we also use this so that we don't have to communicate extra data explicitly to the receiver to, for that unraveling in this scheme.

A: Also, one of the cool things about this message size thing is that, one thing I found in bitcoin is that for proposals to be accpeted by lots of people they kind of have to have different advantages to different factions. So some people might say "I don't care if we can gain X" and then they get surprised about Y and excited... so the memo field might actually help this get adopted. For people that want a big memo field, that might offer preferential pricing to people's fees and limits might be another reason that people would want to use it too.

Q: What are your latest thoughts on mining centralization and how are you thinking about this?

A: Mining centralization has been a long-term challenge for bitcoin in general. There's all kinds of market effects that result in mining centralization, including the fact that many of the mining projects have been scams, which scares away principal investors. We have known this would be a problem since 2012. Better privacy tech could reduce the effects of mining centralization. In the long run, mining is going to be boring, and it's not even as good as electricity production. In the long run, this will drive mining to decentralization just to gain access to cheap power in the world. Everyone in the bitcoin industry should be looking at opportunities to make mining more decentralized, like making small investments to make mining more decentralized. The system really does depend on this. It has to be widely spread, not even competently operated. It isn't even all that competently operated today anyway.

Q: Some people make the argument that for real fungibility that privacy has to be mandatory. What do you tihnk about that argument? If CT was introduced in bitcoin, would it be optional or mandatory?

A: I think that argument has a lot of merit. Just look at the zcash case. But I don't think it's really viable to make it anything in bitcoin mandatory... maybe it is maybe it isn't. It depends also on the cost. The way that bitcoin transactions are costed out is a byproduct of the system. One way that CT could be deployed is that every transaction in terms of its weight impact its impact on block limits could be charged based on its impact whether it has CT or not. I don't know, I think the argument has a lot of merit, but I don't see a way to hoist it on people that don't want it. This is an advantage that a system like Monero has right from the start that is hard to match.

Q: How excited are you about segwit activating on litecoin?

A: It'll be interesting. You know, I think it's cool that it gets used more, but I already knew it would get used somewhere-- maybe I'm deluded. In litecoin there's some interesting challenges with miners and there's some large vested interest in making segwit have problems. The size and scale in litecoin, it will get over the problems, it might be bumpy, I'll be happy to help out. I <a href="https://www.reddit.com/r/litecoin/comments/67rqqf/buckle_your_seatbelts_there_may_be_some_minor/">pointed out on litecoin's subreddit the other day</a> about potential turbulence and there's some good things to know about and to mitigate. It would be cool to get segwit activated on litecoin. I am happy about it. You are going to have bitcoin developers working on litecoin eventually, because nobody really doing protocol development in bitcoin wants to do script enhancement without segwit because it makes it so much easier. The idea of trying to do script enhancement without it is just not interesting...

Q: What do you think is preventing or how would you accelerate mainstream adoption of digital currency like bitcoin?

A: I think we have a long way to go for all the on ramps and off ramps. Having the right message and narrative for what bitcoin does for people. If you look at a public that is living entirely off of credit, what does bitcoin do for them? None of the cryptocurrencies provide credit, so how is he is he going to do it? In the long run, we will have credit, but we don't have it today. If you look at the pace of other really transformative technology like the phone network or automobiles.. they had long incubation periods. The internet went from kinda visible to super visible in 10 years, but it took decades for the internet to get to that point in the first place. Bitcoin is asking people to rethink how they handle money and to reboot many concepts. Sort of like how linux has impacted people as well-- linux has just permeated the infrastructure of the internet, but Joe Schmoe is not aware of it even though linux is on his phone. It's going to take time.

Thank you.