paper: https://adiabat.github.io/dlc.pdf

slides: http://bit.ly/2uSqkV6 or https://docs.google.com/presentation/d/1QXZBtELcVMoCq6wx-rJr31KvtsqxxcWIewMvuSTpsa4

https://twitter.com/kanzure/status/902201044297555970

We are going to have next month on September 13 when Ethan Heilman will be talking about something controversial but he hasn't told me what it is yet. But it's controversial. I am Amy. I organize the meetup with some help from other people in the MIT Bitcoin Club. I write about blockchain technologies and stuff. I have written for coindesk and bitcoin magazine and now I'm writing for Forbes. It's a great space to have fun in. I used to come to meetups and not know what anyone is saying, if you're not sure what you're hearing, keep coming to the meetups and it will eventually all come together. Tadge will be talking about discreet log contracts, which are smart contracts on bitcoin that you can't even see. We're going to meet at mead hall afterwards to socialize. Beer. Segwit.

Hi everyone. I'm Tadge Dryja. You can see this. I'll try to be loud. If you don't hear somtehing, or have questions, stop me. If I go too fast, I sort of made it so that the stuff at the end is not so important. We can run out of time and that's okay. I will start.

I work at Media Lab which is sort of over there I think. Right? That way. At the Digital Currency Initiative which is a small lab in MIT Media Lab that works on cryptocurrency stuff, cryptography, blockchain tech, we have the director over there. I guess the primary thing that I work on is lightning network, which is something I coauthored baout two years ago. This talk is a branch out of that. It's similar. I'll explain. I also work on other fun bitcoin stuff.

About today's topic, it's a new thing. I wrote the paper about two months gao. This whole thing might not work. I think it will. It's new stuff, and maybe someone will read it and give me a mathematical reason why it doesn't work at all. But so far, I feel like the people that know this stuff better than I do have given their OK so far. It's basically smart contracts (whatever that means) using bitcoin, similar in structure to the lightning network. Nobody can see the contracts.

I'm not as familiar with.... I know how ethereum works, but I haven't programmed a lot of ethereum stuff, even though I did write a part of their proof-of-work algorithm. That's the reason why all the graphics cards are expensive today. I know. So it's also a pun because of discreet (quiet and unintrusive) where you can't tell if it's a smart contract, and discrete where it's non-continuous where you have integers instead of reals. And discrete log math is what a lot of bitcoin math is based on. If you don't know about the elliptic curve discrete logarithm problem by now, then by the end of this hour you will definitely know about it.

https://www.youtube.com/watch?v=FU-rA5dkTHI&t=4m15s

I'll talk about the structure of the lighting network, for people.... how many people here have heard about lightning network or sort of know how it works? Okay, most people. And probably fewer know about homomorphic additive that goes into it? I'll talk about elliptic curves, combining keys, smart contracts and the problem with oracles, schnorr signatures, and this semi-new thing that I came up with called anticipated signatures (using schnorr signatures), discreet log contracts, scalability and privacy and then uses. I'll try to stay within an hour or 45 minutes.

The idea of the lightning network was about scalability. If you want to make a bunch of transactions in bitcoin, you have to broadcast a bunch of transactions to everyone which clogs up the network and costs fees. To interactively make a transaction with a single counterparty, the idea is that you spend to a 2-of-2 multisig where both parties need to sign to spend the money. That's the person you're locked in with. You keep sending messages back and forth to re-allocate money in that channel. It's enforced in the bitcoin blockchain in that only the most recent transaction is valid. This is tricky because the global network doesn't see the transactions, only the channel participants know about those transactions.

So the idea is that you, someone, let's say Bob in this case, Bob creates a fund transaction and here's an output for the transaction and there's 10 coins there. From the network's perspective, it sees that someone sent 10 coins there. And then Alice and Bob together can create spends from that. So they both need to sign to spend the 10 coins. They exchange signatures saying well okay Alice gets 1 and Bob gets 9. They both exchange signatures. Whenever they feel like it, they can broadcast this state 1 transaction. But they choose not to because they want to keep the channel open. So then they say let's switch. Bob pays Alice. The difference between state 1 and state 2 is that Alice gets extra coins. So Bob sends signatures and they create that. They can also go in reverse where Alice gives Bob some coins. So from the perspective of the network, all that the network sees is "here's 10 coins". But for Alice and Bob, they agree to the state of the channel under penalty of a lock-up period and commitment of the last agreed (mutually signed) state. They sort of only need to keep track of the most recent state. Old states are valid to the blockchain but Alice and Bob know that the old states are invalid because they are old (and they have more recent transactions that invalidate the older transactions). So to make the network aware of this, they must broadcast the most recent transactions of course.

This is enforced with an output script where basically you're sending to 2 keys. Although I say this is Alice's and this is Bob's, that's like who owns it. But that's not who the network specifies, exactly. The output script is quite simple. It's just key X or key Y and time. So there's two keys that can spend this money. One of the keys can spend it immediately. The other key has to wait, let's say waiting one day before they can spend the money. In lightning network, when you close it, let's say Alice closes this transaction, it's actually Bob's key plus some other stuff can spend it immediately. But Alice's key has to wait a day before she can take the money. She can close the channel but she has to wait a while. The wait is to give Bob a chance to grab it in the event that Alice broadcasted the wrong thing. If she broadcasted an older state, she has to wait some time to get that transaction committed, but Bob can broadcast another transaction immediately because Alice's transaction was an old state. The immediate key is the combination of both Alice's and Bob's key. So when they switch to the next state, Alice sort of rescinds her claim on the previous state by giving Bob the ability to immediately grab the latest version or state of the channel.

And how do they immediately grab it? How do you have this combination pubkey X? I'll go into how this combination process works. So elliptic curves. This is the basis of all the signatures and fun stuff in bitcoin. Not the proof-of-work, which is just a hash function. So you have these points on a curve that look sort of like this. The bitcoin curve doesn't chop into two pieces actually, because it's actually x^3 + 7 instead of -4x + 2. So none of them actually look like this because it's modulo some giant number, so it all looks like random dots. But it's much easier to explain and look at, like this.

The idea is that you've got these points on the curve. You have defined addition. You can add p plus .... well, you can double a point by taking its tangent. And you can add two points by drawing a line between them. So you draw a line between two points, find where it intersects, it will intersect at some point, and that's the sum, the inverse of the sum. You have these points, you can add them, you can't multiply because that's not defined. But you can multiply them by regular numbers. You can say this is 2p and this is 3p, I can add 2p to p, I can have a regular number coefficient for these points but I can't multiply or divide the points. The rules of this system-- and htroughout this I will use lower case letters to represent regular numbers, scalars, numbers, and uppercase letters to represent points on the curve. With regular numbers you can add, subtract, divide, multiply. With points, you ca add and subtract but you cannot mulyiply points. Addition is defined, but not multiplication. And when you mix the two, you can multiply a point by a regular integer, but you cannot add a point to a regular integer, that's not defined.

And also, in this curve, you have some curve that everyone agrees on that we use in bitcoin, and you have a generator point G, and this is the point that everyone starts with. And public keys are some secret number multiplied by that generator point. So it's kind of fun because while you can multiply, you can now... point A is some coefficient times G, but we don't know what the coefficient is. You can't divide, to get the scalar back out. There's no real way to do that. And it's homomorphic, so what you can do is you can say this coefficient times the generator, so this is a point-- a coefficient times a point is a point, and do it again to another point and coefficient; it's the same as adding the integers themselves and then multiplying a point. So this homomorphic property is very useful and it's the basis of what we're going to be doing here.

The sum of the private keys... if you're from the software engineering point of view, if you add the two private keys-- a private key is just a 32 byte sequence; if you add those two private keys, it will be the same as if you add the two points in the pubkeys. So that's fine.

So what you can do to make the revocable public keys in lightning network, say Alice has public key A, and Bob has public key B, and they say okay the combined key is just the sum of these two points. We add A and B, we draw a line between them. Alice knows secret key A, Bob knows secret key B, and neither party can sign with secret key C. Neither party knows the sum of these two. But if Bob reveals little b to alice, then Alice knows how to sign with C. She can just add a and b together and then they know how to sign with C. The inverse could also happen, but in this case, one party reveals a key to another party and the key is now known.

Alice gives her part of the key to Bob to revoke her claim on the transaction. So this public key x is a combined key. Public key Y is Alice's only. So this is Bob and Alice. Alice reveals to Bob. So now Alice has rescinded her claim on this. The fact that she has to wait means that if Bob sees this on the blockchain then Bob just grabs it immediately. So it's going to be gone by the time that the timeperiod has been exhausted. So it's this kind of weird thing where you do need to monitor the network. If you're asleep at the wheel, Alice might be able to broadcast something old that shouldn't be broadcasted, and if Bob doesn't see it in time, then Alice might be able to get away with it and spend it because Bob didn't broadcast the alternative quickly enough.

https://www.youtube.com/watch?v=FU-rA5dkTHI&t=14m

This is a smart contract. It's fairly straightforward. It's a payment conditional on something. In lightning network, the smart contracts are only based on internal data. It's Alice and Bob exchanging data which determines who gets what money. But in smart contracts, we're interested in external state.

If we need an external state, then we might want an oracle. In this example, Alice and Bob want to bet on tomorrow's weather. So if it rains, Alice gets a bitcoin. If it's sunny, then Bob gets a bitcoin. The problem is that the bitcoin blockchain doesn't know what the weather is. There's no OP_WEATHER. Do people have questions on the structure of lightning and how you enforce only the most recent transaction is valid?

More fancy is what if we want a smart contract based on something external to the blockchain? Okay, we need an oracle. You kind of need an oracle. If you don't have an oracle, then you could say that well Alice and Bob could just agree that if it rains, Alice gets a coin, and if it's sunny then Bob gets a coin. If they are totally chill with each other, then it works great. But the point is that bitcoin is the enemy of currencies, you don't trust anyone and everyone is trying to kill you or something. So just having 2-of-2 multisig, it doesn't really work for this problem. What you can do is let's say it rains, and Alice says okay Bob you have to sign. And Bob can say that well I don't agree with that-- it didn't really rain, it was barely a drizzle, so I'll give you 0.7 and I'll get 0.3. But Alice will contest that. You need some sort of third-party to step in.

A third-party could decide in the case of conflict. So you get a 2-of-3 multisig oracle. Instead of sending the deposit to a 2-of-2 multisig with the two contract participants, you send to a 2-of-3 multisig. You have 3 keys, Alice, Bob and Olivia and Olivia is the oracle. If they are both chill, then they both sign without contacting Olivia at all. If they are both chill then they do 2-of-2 and they ever contact Olivia. If they are fighting over it, and they have used 2-of-3, then they ca turn to Olivia and she will decide in favor of whatever correct party. You only need two signatures, so the conflicting party is left out. Well, the problem with this is that say that Alice calls up Olivia and gives her a bribe. Alice has lost everything and she might be able to bribe the oracle. The oracle had to be part of the setup process. So Alice might collude with the oracle.

It's interactive. The oracle sees everything. They also decide the outcome of every contract. They can equivocate. They could say it's sunny to one contract and it's raining to another party. So the oracle knows, but it's really hard to prove. You could have some kind of proof that this signature represents rain and it didn't rain, but it's on an individual basis. The interactivity is ugly because you can bribe them and try to influence the oracles.

Having a system where the oracles can't equivocate and can't see what's going on... it's not a cryptographic assurance; maybe they can still collude anyway, but it's a lot better of a system. How do we do this? How can we have the oracle sign off on outcome sand effect the state of these contracts, without them even realizing that they are doing so? There's a nice way to do this.

https://www.youtube.com/watch?v=FU-rA5dkTHI&t=18m40s

I am going to talk about Schnorr signatures, which is also relevant to bitcoin. I think people have talked about Schnorr signatures and how they are cool and how we want to put this into bitcoin in the future. Sort of random aside, ... schnorr signatures, one random thing; Schnorr is kind of a jerk. Hopefully this guy doesn't sue me. This guy patented this signature scheme. It's really a straightforward signature scheme. In writing my paper about discreet log contracts, I accidentally derived the concept of Schnorr signatures but I didn't realize it. I was told by other people that this is a Schnorr signature scheme. So it's an obvious thing to do, and he patented it, and nobody used it for 20 years, and this is why we have ECDSA instead. If you know the math behind ECDSA signature scheme, it's ssort of ugly, and it was developed that way so that it wouldn't infringe on the Schnorr signature patent. How much, how little could we change so that we're not infringing on the patent? It got pretty ugly. So we're probably not going to call them Schnorr signatures in bitcoin, we will probably be calling them Bn signatures. There's another team that wrote something similar. So, yeah.

In signatures, you don't just have your public key. You have other things going on, like a message. In this explanation, you have a scalar and a point, that's your public key. You come up with a random key, there's your public key, H is a hash function probably sha256 in this case, and hten there's some message which is just some bytes. Schnorr signature is real simple. You have a public key. You have a random scalar k, you multiply it by the generator point to get a point r, and this is similar to a public key but you're using it for only one signature. And to sign, you just, for the signer it's really simple, you just say your signature s is k minus the H(message) and r times my private key. That's it. It's a little weird in that you concatenate your message, and r is a point, and you can have an x coordinate and a y coordinate and hash that together. Little k is a secret. The signature is r and s. The signer reveals r and s, but the signer keeps k and little a secret. It's important to keep both of those secret. To verify, you have r and s, everyone knows G, you know big A because that's the public key, and you know the message and the signature. To verify, you need to make sure that s is really equal to K minus H(m) * r * a. You don't know little k... but you know k times G and little a times G. Because that's just r, and big A times... because that's their pubkey. You algebraically multiply both sides by G, so you have s times G equals this whole hash times a * G, and ... H(m) ... you know these values, so it's verifiable. That's a Schnorr signature. You can't forge signatures because you can't inverse the hash function and r is in both sides. You can't just compute a scalar that looks like that. r is in both places. If you can break the hash function or figure out the discrete log then you can forge the signature.

In my discreet log contracts scheme, I am introducing a fixed r value signature scheme. Generally what you do is you say I've got a pubkey A, and my signature is r and s, and you verify it with this formula. With discreet log contracts, we say that the pubkey includes an r point. And the signature is only s. It's the same formula. Everything is the same, except that I pre-commit to this r value. Instead of coming up with a random k at signing time, I come up with random k at the time of revealing my public key. It's the same thing except now you've got a couple of differences. The big difference is that you can only sign once. When you're signing, with the same public key, you need to use a different k each time. If you don't, and this is a little ugly, I'll go over it real quick: say you have two signatures on two different messages with the same k and the same pubkey A. You can subtract those two signatures, so s1 = k - H(m1)*A, s2 = k - H(m2)*A, so the difference between these two, the k's disappear, so you're left with these two hashes, you can factor out little a, and you can solve for a. So you know s1 and s2, you know H1 and H2 are, and you just revealed the private key. So don't do that, always use different k's. There's a standard, rfc6979, where you can make k deterministic on the message you're signing, but you can't do that in discreet log contracts.

This is a fun fact. This is what brought down the playstation3 code signing. They used the same k for all their code signing. And so people were able to figure out their private keys and sign code and private video games. That's probably the first time that I learned about elliptic curve private signatures. That was like 2001 before I really got into this stuff. But I was like hey that's how they hacked the playstation.

So with this, if you already know their point r, and their public key, that's not normally the case, but in this case we're going to pre-commit to an r value. If you know a, r, and a message m, you can't compute s, but you can compute s times a generator point. That's just going to be r minus this hash times their public key. You know all these things: G, r, the message, their public key. You can compute, you can pick a message and compute what their signature will look like times the generator. You don't know the scalar, but you know the point it will multiply to. So you can compute sG for any message without knowing s. This is not how I cam eto this, I came to it backwards. It makes more sense if you're doing it this way, though.

https://www.youtube.com/watch?v=FU-rA5dkTHI&t=27m

You have this signature which is sort of a key... you have this unknown scalar, but you know what it is times the generator point. It seems like a key pair. It's the same as a public key where like okay I know what it is times the generator point, but I don't know the actual scalar to get there. So you can use the oracle's signature as a private key in this case. Similar to lightning network, you have a bunch of states spending from a single transaction output. But instead of making them sequentially... like in lightning, where state 2 is made after state 3; in discreet log contracts, you can number them but it's arbitrary because you make them all at the same time when you're creating the contract. Instead of saying the most recent transaction is valid, the validity is determined after the fact by the oracle. So the oracle will contribute part of a private key to one of these outputs. So say you're making a transaction about weather betting, where some output goes to a different party. How do we enforce that only this one should get broadcasted and this other one shouldn't get broadcasted? What we do is that the oracle's signature is thrown into these private keys. Olivia's signature s, treated as a private key, we don't know what it is yet. Olivia hasn't signed anything yet. We're building the contract. She might sign the eclipse message, the sunny message, or the rainy message. We can calculate s * G for any given message we expect her to might sin. So we take the contract public key for Alice which will be Alice's public key plus s * G, and her private key will be Alice's private key plus s, which is the signature that Olivia will provide. We don't know what the private key is going to be, unless Olivia signs. So say there's three messages that could be signed, like sun, rain, eclipse. So there's three signature keys. The detail is going to be H(word sun). So we can make rain public keys for Alice and Bob and sun public keys for Alice and Bob, and so on.

Q: ... how can... class of outcomes..

A: Yes, in this case, in all the cases actually, we're assuming there's only one possible outcome. It could be sunny and have an eclipse. It could be rainy and there's an eclipse. Alice says that she is going to sign one message-- she can't sign more than one, so if she signs two, she reveals the private key. Only one of these is going to be valid.

Q: Okay so go back to... I'm sorry, can you go through the transaction history of setting up the contract?

A: Yes, sure. The sequence would be that you build these first. First, Olivia commits to an r point and says this is the keypair I'm going to use to sign tomorrow's weather. She should probably be specific about what possible messages she could sign. You want everyone to know that there's only three messages or whatever. It could be signing the temperature in celsius and there's only 100 possible things I could sign. Alice and Bob need ot anticipate every possibility. So for each possibility, they create a transaction and hand each other the signatures. They say I'll send 9 here and 1 here in this case, and this key is Bob's key plus Olivia's sunny signature, and this one is Bob's key plus Olivia's eclipse signature, etc.

Q: How did...

A: That hasn't happened. Olivia has not yet signed. Olivia just said here's a pubkey. I'm going to sign a message tomorrow. You know a, you know r, and you can anticipate the messages she's going to sign. So you can calculate the signature times the generator point, but you don't yet know the signature. So Olivia commits to these things. They can build the transactions. They can fund the transaction output and send money to the contract. And then they wait. They have to wait because if they broadcast these, they wont be able to spend from it. They need Olivia's signature to spend it. It says Alice but they can't grab it on its own. So they need Olivia's rain signature to broadcast this or to get this.

Q: Am I right in understand that the main reason to do this instead of many hashlocks is to enforce that Olivia only sends one signature?

A: Okay. So yeah. You could have a table of all possible hashes and preimages. There's a couple improvements in this case. One is that Olivia can't equivocate... she can only release one, without revealing her private key.

Q: Is the assumption that Olivia is using a long-term keypair that she wants to maintain?

A: If Olivia is a known entity, A can stay the same each time. Or without that property, you can have a parent key above that which endorses subkeys, and so on. One is that it's harder for Olivia to equivocate. It saves space. What happens if there's a million different outcomes? Well Olivia only needs to commit to one 32-byte r. It also helps in that if they end up on the blockchain, you can't tell. If everyone sees that Olivia is committing to different hashes and they're going to reveal a preimage, that would show up on the blockchain. They will say I don't know who these two people are, but they were betting. Whereas in this case, they can't see it.

There's three possibilities-- three different signature keys-- you can add those. It's the same script as in lightning. You have these values.. but it's swapped. In lightning, the correct use is the timeout. If you broadcast the right thing, you have to wait. But if you broadcast the fraudulent thing, your counterparty will immediately grab it. However, in discreet log contracts, the fraudulent one is the timeout one. Whereas if you broadcast something and you don't know the immediate combined key, then it means you broadcasted the wrong thing and the other person can grab it later.

So they build this. They build these. They fund it. They wait for Olivia to sign. So it rains. Olivia signs the message 'rain'. Alice or Bob, but Alice is winning so she probably does this. So he knows the value, she has the private key to sign for this one now. Alice can broadcast state 2. Once she does, she knows the private key of course, she can sweep it and send to her own address, which she wants to do immediately because otherwise Bob will eventually be able to spend from that output. So she broadcasts state 2, and then also broadcasts a spend from that. It's a little ugly because you have two transactions that are redundant and they both have to go on the blockchain, it's not so bad. The software can do it at the same time. If she doesn't broadcast the sweep, then after the timeout then Bob would be able to grab them.

The timing is a little different from lighting. It's sort of better. In lightning, you don't know when things are going to happen. You have to be vigilant and watch for fraud constantly. In discrete log contracts, you broadcast the output state 2 and you immediately grab the funds from it. The only times that you will have to wait is if something wrong happens. If Bob broadcasts state 1, that's annoying for Alice because she can't get her money right away, but she can get it eventually, but Bob will never be able to spend it because Olivia is never going to sign that outcome. The only reason to do this is to be a jerk. So if Bob knows that he is losing and he is going to lose all his coins anyway, he might broadcast the wrong state, and this will inconvenience Alice. If Bob tries to be a jerk and delays Alice, then he should lose everything including that extra 1, and Bob should lose that too, as a disincentive to be a jerk.

Q: What stops Olivia from colluding with Bob or Alice?

A: It's still possible, right? The biggest aspect is that Olivia has no idea any of this is happening. Olivia says on some website or somewhere, here's an r point, I'm going to sign the weather tomorrow. She has no idea that Alice or Bob are doing this. So it's a little harder-- they are not already in contact with each other. If they are a good oracle, then they might say hey I don't even have an email address. Olivia could collude, but it will be public and they can only collude one way.

Evil Olivia-- a bad oracle can cause contracts to execute them the wrong way. But they can only do this once. They can't sign two different outcomes. Anyone can compute the private key and sign any message at that point, and it would be totlaly up for grabs at that point. An incorrect signature is public. If olivia is well known and they keep reporting the weather every day and it's been okay, and any invalid or wrong signature, everyone will be able to see that. It's possible, but it's a bunch of things that make this hopefully unlikely.

Q: What do you mean people will know if it was invalid? If I don't know if that contract is..

A: You don't have hte contract, but you know that Olivia said that she was going to sign something, and you have their sunny signature, you... this is like. Olivia doesn't even know the blockchain exists. She just says point r, here's my signature tomorrow, anyone can be given this data. Regardless of the contract, everyone can see that they made a signature for the wrong thing. Once they do this, everyone can post that signature and your software could immediately detect that the signature was for the wrong state.

Q: In that example, you can tell what the weather is. But say the contracts are.. less public data.

A: I'll talk about more realistic contracts, sure. It should be something that is non-ambiguous. Best case, it's a number that everyone is going to agree on. The oracle is there to just grab the number, sign it, and then you're done. But if it's something where people are going to argue about it, then people aren't going to be able to do this. This works better for pricing data, like the price of oil. Where there's no real argument. The oracle can just broadcast it and maybe thousands of people are using it and the oracle doesn't know.

https://www.youtube.com/watch?v=FU-rA5dkTHI&t=42m

The whole process is three transactions. You fund it, then you broadcast a close, then you sweep it. However, if the parties are chill, they can reduce this to two transactions, where there's a funding transaction, then you sweep to the correct party. If they both agree, and they are cool, they can connect to each other and say hey I have the rain signature and you know I can broadcast it, how about we just sign a regular 2-of-2 multisig where I get it in the clear and you get yours in the clear, and then enough to sweep. So this is a "gg" transaction if you lose (good game). That should save some space. That helps a little.

A more advanced thing, which is more complex, is that you can make a discreet log contract within a lightning network channel. So if this works, zero transactions go to the blockchain. It's sort of like adding an HTLC, you're adding a third sort of output that happens to be 2-of-2 multisig and from this output you build the contract. It does't even exist on the blockchain, it's just in your channel state, and if you want you would have to close both, if the parties become uncooperative you broadcast the three outputs and then from that you are broadcasting those 2 outputs, and then sweeping. So it's a little ugly when it doesn't work well when people are uncooperative and you have to go on chain. But if they are cooperative, then there's no additional transactions that need to go to the blockchain. So for parties that are cooperative, this is highly scalable.

It's sort of a threat: Bob knows that Alice can broadcast this, that she can close the channel without asking, and take coins. So if Bob is a good sport and knows that this is possible, then they will agree to update the balances and they can do many different bets all at the same time. It's a little harder because you need to put timeouts and stuff so that people don't broadcast old states, but it should work.

For the in-channel contracts, nobody sees that they occurred. Even if you broadcast to the network, it's not clear that it was a contract. It looks like a lightning network channel got opened and closed. So it's not clear that you guys participated in a smart contract. Even the oracle knows s and stuff, you can't tell because it's a new random pubkey that has been added to one. It's kind of cool. In practice I think you could get some probabilistic idea of which are smart contracts and which are lightning channels. You could see lightning channels ending with timeout, but these will end with the key script, but t you won't be able to know actual details.

https://www.youtube.com/watch?v=FU-rA5dkTHI&t=46m

So, real use cases. Weather is great and all, but you probably want something more fun or interesting. And so what people like to do is talk about money and stuff. Probably a big case would be betting on the price of the dollar. This is a little backwards seeming at first glance. In this case, you have to think of bitcoin as money and the dollar is just some altcoin. You price things in satoshis. So a dollar is about 25,000 satoshi BTC. You could make thousands of transactions based on the price of the dollar. So the oracle will sign in the price of the dollar tomorrow, in satoshi BTC, so if the price of a dollar is 1 satoshi, then one counterparty gets one, the other counterparty gets the other side of the deal. Zero means that the dollar is worthless and bitcoin has taken over the world.

You can make, you know, 10,000 transactions or 100,000 transactions which will be about 10 megs. It's off-chain and 2 computers can make 10 megs of transactions, that's no big deal. This is a little ugly because it's 10 megs and also, in practice, probably the range doesn't need to cover the whole thing. There might be ranges where Alice and Bob say hey if the price of bitcoin goes up to $100k, or $200k or whatever, you win. Whether it's higher, then Bob gets all of it. Conversely, if the price of bitcoin tanks, then Bob should win. You can split up the r values into two different r values and one is an exponent and one is an antica. So you can do the order of magnitude, and then the number of significant digits. It saves a lot of space for the off-chain part. It's not just scalable on-chain, but also scalable off-chain where you can get down from 10 megs to 1 meg. Which is overkill because 10 megs is not a big deal.

You can have multiple oracles, let's say that they want to use oracle 1 and oracle 2, that's easy, you just add up their points. You can add these into the pubkeys. It has to be both signing the same thing. And there's no size increase. You can do m-of-n. We need two of these three oracles to sign it, but it starts to blow up the size of the state between the two parties, it gets really big really fast. The other tricky part here is that they have to sign the same exact thing. If one oracle signs 52 and the other one signs 53, and they didn't intend to sign different values, then you can't close your transaction because none of your things will add up. You probably also want a timeout transaction where if the oracle goes down, then after a week or two, Bob and Alice should each be able to get half of their money back. If the oracle dies then it's a wash trade and they should revert.

Currency futures are probably the ideal use case. It's a synthetic future. It's sort of a contract for difference. I don't really care as much about the volatility, say, and the opposite side is that you have super bitcoin that are much more volatile then if the price goes up then you get more, but if the price goes down but you also lose them. And you will find people that want this, because people love leverage and gambling. It's nice because you can get a stable dollar-based currency and you just need to find the people that want to make that deal.

You can do stocks, synthetic assets on stocks. You can do a share of apple, if the price of apple goes up or down in bitcoin then the contract reflects that. Insuance is just gambling, there's no difference. Olivia could report on whether a house burns down, or whether a hurricane hits, then people can create insurance contracts. It's just general conditional payments. It could be on numbers, but really any pre-determined set of possibilities where one element of that set is the thing that happens.

It can't be things like "what's the name of the highest grossing film of 2017". You don't know the names, so you can't build that contract. It's borderline because you sort of know the movie sin production, but who knows, maybe something comes out left field and it grosses the highest, and you didn't know the name, so maybe that's a mess-- but you could do a timeout in that case really.

You don't need a token-- you can just use bitcoin. It's permissionless. Nobody can even tell what you're doing. You can do it on any blockchain. You can probably do it on ethereum, but I'm not doing that. There's no token you need. I am not doing an ICO. Sorry. I won't make 100s of millions off of this.

I think this is better than Augur. I live three blocks from them. They have raised millions of dollars to make a prediction market but I don't think they have finished it yet. There's gnosis, delphi, there's a bunch that want to do smart contracts or whatever. But I think my scheme is better because it's harder to equivocate, more private, things like that.

Q: In terms of currency futures and commodities... would this be a replacement for an exchange? Would an exchange adopt it?

A: The idea of an exchange.. there's different elements of an exchange. They are a place for buyers and sellers to find each other. Also they have custody and they execute on their behalf. They also have custody. How does Alice and Bob find each other? There's still a need for some kind of meeting place. An exchange could do that, and they could offer a trade and then people who want to buy and sell could find each other on that exchange and create those contracts. But they don't need to keep custody of people's funds in this model. Or the exchange could be a counterparty where they say hey we have a ton of money and we will take one side of your contract bets, and we even it out, we have a lot of capital, there's a spread and we enter into different contracts with different participants. But it doesn't solve how you find people for trading. Decentralized exchanges are really difficult and there's lots of timing problem. So this could mesh well with an existing orderbook and matching engine.

Q: Seems like for a prediction market, you need oracles. Augur and others.. workaround for multi-oracles?

A: They had this thing where everyone is an oracle. I know how Augur worked, where everyone voted on something and the truth is determined by majority vote. I think this is dangerous because they have this token with reputation points and the majority of the reputation endorses an outcome. But if you managed to corner the market, and the minority loses their stake to the majority, so if you managed to grab it, then you could kind of say, I'm going to sign on-- what's vote on pie. Tomorrow I will sign pi, and then you say 3.14 well nope it's 7 and the majority endorses 7... and all the honest people lose the reputation to the dishonest people. So you can't recover from this some sort of dishonesty problem. In discreet log contracts, it's up to Alice and Bob to pick their oracles. In practice, I feel like the oracle job is a natural monopoly where you're not going to have hundreds because the costs in terms of thinking about it, because hey I want to enter into a contract with you, and you say hey what about this other oracle... well it bifurcates the market, which is already tricky because of the epxiry date. It's like a options market where you have the option to buy and sell. Having multiple oracles is going to end up with a couple big oracles like Bloomberg or Reuters or something like that.

Q: It's just like the regular market. There's ... go to..

A: But if you're making a contract where you have a futures contract based on the price of oil in 1 week, everyone is going to use a specific intermediate. You have bushing, WTI, you have a few different ones, but not millions. There's probably going to be single digit or double digit well used oracles for different things. So people will mostly use the defaults. The oracle has no idea if anyone is using them... maybe they broadcast isgnatures and maybe someone uses them or not. Not sure how they get paid. I think an exchange would be a good oracle. If kraken wants to sign the price volume weighted average for their price for today, you can trust them because, they got everyone's money anyway, if they wanted to rip everyone off they could just run away with the custody anyway, so you might as well trust them to report an accurate price. They use this to drive people to their exchange as a service. We sign the price of the coin on our exchange and people can use this for derivative contracts. So maybe exchanges would use this. I'm writing software onw. I'll do it. It's pretty easy to just sign stuff.

Q: Do you envision ... so two counterparties doing a trade, based on something happening like price of oil, do you....

A: The oracle can't tell if anyone is using their data. Probably where the value gets captured is matching the users. So when Alice and Bob want to find each other. Bloomberg where you have an orderbook, you have a matching engine, they find each other, that can capture a fee maybe. It's hard for the oracle to capture the fee. They don't know who's using it. Maybe they can charge for the signatures.. but one person can subscribe to that and put it on pirate bay. You don't even need pirate bay, the signatures are 32 bytes each. I think it's not a money-making thing. I think people just provide it as a service:

Q: Is it... added.. or ..

A: The script? Okay, so, this stuff you need segwit.

Q: You need segwit there. Do you need a new opcode?

A: Nope. It's the same as lightning. So, segwit is locked in and it will activate in a week. But actually it needs segwit less than lightning does. You know the timing of everything. Without segwit, you could have a funding output that has a 2-of-2 multisig OR checklocktimeverify and a refund. But since segwit is going to activate, the script itself..

Q: I thought bitcoin only supports..

A: The Schnorr doesn't happen on the blockchain. The schnorr signature happens with Olivia signing. But Alice and Bob uses ECDSA with the keys they have derived. So the Schnorr signature doesn't touch the blockchain at all. It's the same scripts.

Q: You presented this as .. schnorr, but you can do it with ECDSA?

A: No. The Schnorr signature is required, but it happens outside of the blockchain. Olivia just says here's a pubkey and a point r, I'm going to sign the price of something tomorrow. If someone wants to use that on a blockchain, cool, but I don't know about that. That's where the schnorr signature occurs. Alice and Bob can incorporate that data into their ECDSA pubkeys. It goes into the pubkeys that can then be used for ECDSA or Schnorr. The Schnor happens off-chain.

Q: Schnorr generates the key.

A: Yeah. You generate the key with schnorr. You can't do this with ECDSA offline. You need that property of the schnorr signature. It's nice because it's not a consensus rule for bitcoin, you can run it today, well you need to write software. I started a branch in lit. I don't know how long it will take. There's no required consensus rules for this.

Q: ... have you read the plasma paper.

A: Yeah. It's sort of vague. It sounds cool. I haven't worked with Joseph in a while.

Q: Will you post the slides?

A: Sure I'll post the slides. The DCI slack or the meetup page? Sure.

Q: We have a slack. Not the DCI slack. Ethereum developers slack channel.

A: Eh, I'll post on the meetup page. Ethereum slack, I dunno. Nah, we're all friends. Any other questions?

Q: We're all going to mead hall. September 13 is the next meetup. Ethan Heilman will be speaking about something confidential. No, controversial. Well right now it's confidential because he wont tell me what it is, other than that it will be controversial. Same room same time.

Okay, thanks.