diff --git a/__transcripts__/mit-bitcoin-expo-2015/_index.md b/__transcripts__/mit-bitcoin-expo-2015/_index.md
new file mode 100644
index 0000000..7fe8aa5
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/_index.md
@@ -0,0 +1,7 @@
+---
+layout: default
+has_children: true
+title: Mit Bitcoin Expo 2015
+---
+
+{{< childpages >}}
diff --git a/__transcripts__/mit-bitcoin-expo-2015/andrew-miller.md b/__transcripts__/mit-bitcoin-expo-2015/andrew-miller.md
new file mode 100644
index 0000000..59def6c
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/andrew-miller.md
@@ -0,0 +1,253 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Andrew Miller
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Step by Step Towards Writing a
+Safe Contract: Insights from an Undergraduate Ethereum Lab
+
+- Andrew Miller
+- Elaine Shi
+
+Next up I want to introduce Elaine Shi and Andrew Miller from University
+of Maryland. Andrew is also on the zerocash team.
+
+Okay. I am an assistant professor at the University of Maryland. We all
+believe that cryptocurrency is the way of the future and smart
+contracts. So students in the future have to program smart contracts.
+
+So that's what I did. I asked some students to program some smart
+contracts. I am going to first give some quick background and then I
+will talk about the insights that we gained from this lab. Okay.
+
+So I asked my students to work in groups of 4. This is the first time
+that this type of lab has been attempted. I asked one of my PhD students
+to advise each project group.
+
+In the first phase we had the proposal phase where students developed an
+application of choice on top of Ethereum's programming language called
+serpent. As the lab went on, we realized that we needed a second phase,
+the amendment critique phase.
+
+In the second phase, the instructors- Andrew Miller and myself, and the
+graduate TAs. We gave feedback about the applications they created. I
+asked the students to form groups and critique each other's
+applications.
+
+Based on the feedback, the students amended their designs.
+
+The outcome is that there is good news and bad news. The good news was
+that this was an aspiring experience. Both the students and the
+instructors learned tremendously throughout the process. Some students
+said they really enjoyed learning about cryptocurrency. All project
+groups did a really impressive job.
+
+The bad news is that some students didn't enjoy the premature nature of
+Ethereum's language. This language is in development. It's poorly
+documented and some groups had difficulty setting things up and getting
+their application to run on top of this language.
+
+The students created many interesting applications like games where
+players play for money, like RPS, Russian roulette, and so on. Escrow
+services. Auctions. One group created a parking meter application. Some
+groups created stock market applications.
+
+Okay. So what are the lessons learned? At the end of phase 1, we
+actually realized that many groups programmed contracts which had
+problems with them. They were insecure. And essentially as weak now,
+security is difficult. When you write a traditional program, we know all
+the ways you can mess up. Here we are programming smart contracts, it
+turns out there are new ways to mess up and create bad contracts. Okay.
+
+So as we all know, smart contracts have high value transaction values.
+So the security is important. If I am a user, I want to know that my
+money will be protected if I send money to the contract. Let me give you
+some examples. Partly the purpose of this is to walk through step by
+step about how to create a safe cryptocurrency contract.
+
+Before I do that, let's first try to have a very quick overview of the
+programming model of Ethereum. Okay. In Ethereum, there's a key concept
+called a contract. And the contract would interact with different users.
+So the contract can both have both storage and program logic. Okay. A
+contract can store messages and money. It has some Turing complete
+program logic it can execute. In Ethereum, the idea is that the data of
+the contract is going to be stored on the public blockchain. And the
+program logic of the contract is going to be executed by all miners on
+the network. Okay. So assume the underlying cryptocurrency protocol
+maintains its security properties, then one way to think about the
+contract is to think of a trusted third party without privacy. Okay, so
+is it trusted? It is because, assume the entire network reaches
+consensus, and assume that you assume the protocol is secure such that
+the majority of the miners will execute an honest reference client. Why
+is there no privacy? Well, everything is public and the whole blockchain
+is public and all messages are public. Okay.
+
+So the contract would interact with the users and the users can send and
+receive money to and from the contract and they can send and receive
+messages from the contract. Okay. So I am going to use a rock paper
+scissors example to show some mistakes.
+
+So here is how you would write a RPS contract. There are three entry
+points to the contract. At player, input and winner. Let's imagine a two
+person contract. "At player" would register and then send money to the
+contract. So the contract would store their money and their identity.
+That's the first step. The second step of the game is a function called
+input. This is where the players, the players need to choose something
+to play, so I choose paper, so I choose scissors, this is where players
+send inputs to the contract. The contract will store their inputs. In
+the final step, the contract will decide the winner and send all the
+money to the winner. That's a high-level overview.
+
+For instance, here's a typical at player function that students wrote.
+If you look at the function a little more carefully, it's very simple.
+Self dot storage is the contract storage and when the contract receives
+the message it will basically first see whether the amount of money
+associated with the transaction is bigger than 1000 ethers. Then it will
+see if player 1 has been created. If not, the contract would record
+player1's identity and then it would store the money on to the contract
+which is the storage winnings equal to .. plus message value...
+Similarly, when player two enters. So I hope it is clear what this
+function does.
+
+What's the problem with this function? Does anyone see the problem? If
+you look at this a little more carefully you will realize that what if a
+third player tries to join the contract. What if I make a mistake where
+I send less than 1000 ethers? The contract eats the money. So if you are
+the user and you are dealing with this contract, you would have to be
+very carefully. You do not want to be the third player to send money.
+There can be someone concurrently attempting to send money in the same
+epic. The users are unprotected.
+
+So here's a second type of mistake. The input function where players
+send their choices. Here the program is very simple. It looks at whether
+this is player1 or player2 and then it records the player's choice.
+What's wrong with this? Okay, if you think about it a little more
+carefully, it will become immediate that the problem here is that the
+players are sending their choices in cleartext to the contract. So the
+messages are sent in the clear and the player's choice is stored in
+plaintext in the contract. So if I am a player, what makes sense for me
+is to wait for the other player to send their input, and then for me to
+decide what I should send. So that's broken.
+
+How do you fix this? There's a simple technique where you make a
+commitment. You make a commitment, it is cryptographically hiding, then
+in the second part you would open your commitment. That's what you want
+to do.
+
+Suppose you do the right thing and use a cryptographic commitment. There
+are still ways you can mess up. Imagine that the players have sent their
+committed inputs to the contract. In a later phase they would open their
+commitment. This function is where they open their commitment. The
+detailed code is not too important. What is the problem here? Okay, so
+here is another problem. Essentially let's say you and I are playing the
+game, you open the commitment and I see that I am losing. At this moment
+I have no incentive to open my commitment. It becomes stuck in the
+contract. If you are the winner then you wont get the winnings. So
+that's pretty bad.
+
+So this brings us to the third class of mistakes which is incentive
+compatibility. You want to create contracts that are incentive
+compatible. You can introduce a deposit structure to the contract where
+you require players to deposit money to play, and then if they don't
+open their commitments within a certain amount of time then their
+deposit will be sent to the other player.
+
+This was an interesting experience, we went back and forth to get the
+students to fix their contracts. What's coming up soon is that we are
+going to release some online course material for programming smart
+contracts. I have hired my undergrad students back to create a detailed
+manual to write the instructions. We will setup a VM where we are
+running pyethereum and we will have this step by step lab where we coach
+students how to create these smart contracts and what kind of mistakes
+to avoid. So if you are a professor and you want to do a lab like this,
+then check our online course material and use the virtual machine we
+have setup.
+
+In this course material we will have some other more.. which I am not
+going to cover here.. they are related to the specifics to the ethereum
+or serpent language.
+
+Andrew will now give a quick announcement. Hi everyone, thanks. I have
+no particular, where are my other slides. Thank you. I want to give you,
+I have no transition for this, I want to give a short update on another
+project. This is one of my pet research projects. Kicking around
+since 2013.
+
+This is just a short announcement. Non-outsourceable mining puzzles. The
+motivation here is that everyone knows that Bitcoin's value is
+decentralization. And we aren't quite getting the decentralization we
+want. There are extremely influential mining pools. There are some large
+industrial miners. They sell shares of mining power to other people that
+may have been Bitcoin mining on their own but instead they are hiring
+some central organization to do their mining for them. So I wanted to
+investigate if it was possible to have a technical disincentive against
+this, so a technical measure to prevent this and restore Bitcoin to a
+more decentralized ideal.
+
+The observation that makes this work is that the reason why pools are
+able to exist in the first place is that the members don't have to trust
+each other. There's a protocol where you send shares. The goal of this
+research is to propose a new puzzle that prevents that protocol to work.
+Whoever does the block and finds the solution, they have to have a
+private key to take the reward for them. To do the work you have to have
+a private key and you can take that reward if you have it. We have a
+stronger version where you can take the reward and you can avoid getting
+caught or punished. How does that work? Uses magic cryptography using
+zero knowledge snarks. Someone else will give an intro to zkSnarks
+later. There's this technical way to steal the puzzle solution for
+yourself if you find it. This is an implementation of this, it's new, it
+takes only 14 seconds to create one of these puzzle stealing proofs
+using the libsnarks library. It would take about $40 of ec2 time.
+
+I got a lot of great feedback. There are some conflicting challenges to
+integrate this. Mining pools going away, mining solo is hard unless you
+have lots of hashpower or hashrate. There has been some work recently on
+the GHOST protocol and other proposals for getting the time between
+blocks down really fast, so maybe we can include that. Hosted mining has
+other things they can do, like getting you this much money every week so
+that there's no way to hide it, and they could use the same shares
+protocol to prove how well they are doing. You want to have fast low
+value blocks to prevent hosted mining from absorbing the risk
+themselves. So we have put together a different incentive scheme like
+State lotteries. Every time you make an attempt at a puzzle, you have a
+chance at a low value prize or a high value prize. The low value prize
+is for variance, and high value is so that big centralization wont be
+able to take money, and to prevent someone from skimming from the top.
+
+This is compatible with existing Bitcoin mining equipment. We give a
+transformation for the non-outsourceable puzzle variant. You can make a
+non-outsourceable version of an ASIC resistant puzzle. This is all in
+the new version of the paper if you just search for the word
+non-outsourceable you will find it, that's all, thank you.
+
+Q: Can we use automated techniques for testing to detect these bugs?
+
+A: You asked the right question. That's our new research program. I
+would be happy to talk more about that offline.
+
+Q: Hi, so, when I looked at the initial presentation, I was reminded in
+the legal system, if you don't commit, if you don't answer a claim you
+default and you also lose. It looked a little static. If people noticed
+the flaw, they could play along for low stakes, and then wait until the
+stakes get big. Have you done dynamic iterations of these experiments?
+
+A: So far we have run this lab once. We definitely want to repeat it.
+That's why we are also creating this online course material.
+
+Q: So if you noticed a flaw and it was in a dynamic situation, you might
+withhold the fact that you noticed the flaw and then play along for a
+while. And then ponzi schemers put up small returns, but when the money
+gets big they walk away. There seems to be a game play element.
+
+A: We did not see concrete instances of this. Cases of this like would
+be very interesting to us. I think this proves that programming smart
+contracts is very tricky. There are all of these things you have to get
+right, these things don't exist in traditional programming. This can be
+an interesting place where disciplines cross each other. You can have
+game theory, incentives, mechanism design meets programming language
+research. It would be very interesting to try to design tools to get
+programmers to do this right.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/armory-proof-of-payment.md b/__transcripts__/mit-bitcoin-expo-2015/armory-proof-of-payment.md
new file mode 100644
index 0000000..a074f23
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/armory-proof-of-payment.md
@@ -0,0 +1,143 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Armory Proof Of Payment
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Armory proof of payment
+
+Andy Ofiesh
+
+I am going to talk about proof of payment. This is simple. You can do
+this. That you couldn't do before 2008. We'll see if this works. I hear
+it might work. That's okay, I'll pull this up here. I have ruined
+everything. Just jam that in there. Here we go.
+
+So uh, I said who I am. Bitcoin Armory. I am here to talk about proof of
+payment. Basically, let's talk about Armory first real quick. First
+released in 2011. Open-source Bitcoin security software. It's been
+featured on bitcoin.org for free. It's the original innovator of cold
+storage. You can install it on an offline computer. You can hold your
+credentials there to sign transactions. Use your online computer to know
+how much money you have. That's the gist of cold storage.
+
+More recently we added cold multisig where it's multisig, it's all the
+benefits of that plus you keep your private keys distributed offline.
+The free version is great. It does a lot of things. We have also come up
+with a paid version with a consulting services that we're offering to
+enterprises that has a bunch of features that individuals may not want,
+but if you are hiring people to manage a lot of Bitcoin then you may
+want the features we have in the paid version, like distributed
+security, auditing, multi-user key management. Earlier we heard about
+some of the challenges involved with turnover in an organization and how
+you pass on a wallet from the control of one group of people to another
+group. We have solutions for that. We also have a full API so you can
+add stuff on to it. That's one of the aspects of this presentation that
+I will be talking about.
+
+What is proof of payment? Because Bitcoin converts money into public
+data, anyone can answer "did you pay for that?". This is a new thing. It
+used to be that you had to be a trusted central organization that
+everyone already built trust on, and then you have to go with that. It
+limits competition and such to answer that kind of question but now
+anyone can do that. By anyone I mean any program. You can work this into
+a program. I am going to demonstrate how easy that is.
+
+How does that work? The payer signs a request requesting something from
+the payee. The payee gets the request, sees that it was signed by the
+payer, and now the payee has the payer's address. The payee can now look
+that up on the blockchain and see that the payee paid the payer. The
+payee can then see how much it was paid and whether or not the requested
+service should be provided. It's really that simple. There's not a lot
+to it, I mean there's a lot that goes into something like this, but for
+you to implement such a thing it's relatively easy. I say really easy,
+but compared to understanding elliptic cryptography, well that's anyway.
+
+So everything that is happening between the payer and the payee can be
+done in a program. That's what I mean by easy. They can both be
+anonymous. They don't have to know each other. Payer and payee can also
+be programs. They can be autonomous entities on the internet. You can
+have programs that have their own private keys and some advanced
+techniques for keeping people from stealing them. For small amounts, you
+can have programs running around and paying each other and having a
+virtual economy without any pesky humans involved.
+
+For our humans who value anonymity, let me talk about that. People talk
+about anonymity in Bitcoin and we have heard Andreas Antonopoulos talk
+about pseduonymity versus anonymity. Bitcoin allows anonymity, that does
+not mean that you have to use it. There are certain things that are on
+you, like single-use addresses. Holding your own private keys. Offline
+cold storage for instance. There's item 3 and 4, like coin mixing and
+cleaning dust. This is possible. That's a network effect thing. There's
+lots of examples like that that you can find.
+
+One way also is don't use an exchange that requires a Know Your
+Customer. So how do you get Bitcoin? I think you should do stuff for
+Bitcoin. Do stuff. Sell stuff. In this room, one of the things you can
+do in this room is write a program that uses proof of payment, and then
+get paid every time someone uses your program. Or they can pay once and
+then they can use your software. It just matters how you build it out on
+top of the existing tools.
+
+We have bitcoind, armoryd, we have armory python scripting tools so if
+you go into the source code, you can add your own stuff to it. I will
+demonstrate some of that. We have other resources. These are in the
+slides so you can look them up later when you download these slides if
+you like. Here's what we're coming to.
+
+I am going to use proof of payment. Does anyone know what this is? Am I
+just old? I don't think everyone here is young. This is from peanuts.
+Lucy is the cynical character. She fancies herself as a psychiatrist.
+For five cents, the doctor is in. The example is if you have never read
+the peanuts, there's some variation on this when Charlie is depressed
+and Lucy tells him to snap out of it, and then charge it.
+
+Well, I created a robot Lucy. She will do the same thing for 5
+millibits. The difference is that robot Lucy does not have to trust
+Charlie to pay her after she has given him shitty advice. That gets paid
+upfront. If you want to see the program for Lucy, you can see that in
+our source tree at the github address below (RobotLVP).
+
+Quick example that I will use. I have Lucy in a plugin upfront. We can
+see that this is just Armory. This is our dashboard on testnet. You can
+tell it's testnet because it's the green arrow. None of this is real.
+From these three tabs, that's what you get when you run Armory. These
+other tabs are plugins.
+
+Python decorators are super cool. That python decorator implements the
+proof of payment. Please go make real money.
+
+We are paying 2 BTC for the best entry for the best variation on
+RobotLVP by April Fools day. We don't want any actual real projects you
+have been working on. Carry on with your real projects, but we're
+looking for fun demonstrations, do something clever with this technique.
+Use anything, you can use our plugins, you can use armoryd or any other
+tools you like and give us something impressive. If it works, get it
+working on mainnet, and we will pay 2 BTC directly to your program as
+we're using it. That's our offer and that's my presentation. Any have
+any questions feel free to ask and we'll get the mics out.
+
+Any questions?
+
+Q: Are you able to get a python API for lockboxes?
+
+A: Yes, this is exposed in armoryd for 093. Where is our armoryd? Expand
+that out. And we'll look at our RPC calls. What do we got? We can ..
+yeah we got sendlockbox, you can send someone a serialized
+representation of your lockbox. A lockbox is a collection of addresses
+that work together, it will spit out the P2SH address to send funds to.
+And then each member of that can sign and then serialize the transaction
+partially signed and then send it to the other signers, and that is
+exposed in the UI in here. And again this is another, this is another
+way to use our plugins. Our lockbox UI exposes every little thing, like
+simul-funding and a lot of things that not everyone is going to want to
+do. If you want to make a version of multisig for your grandma, you can
+trim everything out of this except for Send or Sign and then grandma can
+sign on your multisig transactions through a plugin that you create or
+you can do any number of things where if a particular part of the user
+interface is too much, you can pair it down and create a plugin for
+that. That's exposed in armoryd. Thank you, earn yourselves a couple
+bitcoin.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/arvind-narayanan.md b/__transcripts__/mit-bitcoin-expo-2015/arvind-narayanan.md
new file mode 100644
index 0000000..66502cc
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/arvind-narayanan.md
@@ -0,0 +1,301 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Arvind Narayanan
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Arvind Narayanan
+
+Threshold signatures
+
+I want to tell you what threshold signatures are and I want to convince
+you that threshold signatures are a technology you need. This is
+collaborative work.
+
+There are three things I want to tell you today. The first is that the
+banking security model has been very very refined and has sophisticated
+techniques and process and controls for ensuring security. It does not
+translate to Bitcoin. This may seem surprising. Hopefully it will be
+obvious in retrospect.
+
+You need Bitcoin-specific technologies. You should be using multisig.
+Multisig has some serious drawbacks and they may apply to your specific
+case to a greater or less degrees.
+
+Then I want to explain threshold signatures and how they are stealth
+multisig.
+
+The people I want to address are developers, developers of wallets,
+people at companies. This is an up and coming technology. I hope to be
+back in a year that you need threshold signatures even for mainstream
+for consumers. But this is mostly directed to early adopters at this
+stage.
+
+As an aside, yesterday in Joi's talk he waved this paper at you, and he
+said "gee wouldn't it be great if we could bring some computer
+scientists into this room". As one of the authors of this paper, I was
+like "that's great". That was awesome to see that dialog here. Andrew
+Miller will be up next, also one of the authors of that paper.
+
+So yeah at Princeton we have been you know doing a bunch of research
+from a neutral perspective talking both about strengths and weaknesses
+and developing prototype technology that we hope others will adopt.
+
+Let me ask you a question. Who recognizes who this person is? Not you
+Andrew. Someone else. Do you have a guess? Yes. This is Ross Anderson.
+He is a towering person in information security. He is a professor at
+Cambridge, and in particular in the economics of infosec. If you are
+interested in Bitcoin security you should read everything that this man
+has written. In particular he has this great book, "Security
+Engineering". I highly recommend it. Chapter 10, banking and
+bookkeeping. It's wonderful stuff. He has great insights. You should
+take a look at this.
+
+The reason why I bring this up is that Ross destroys the idea that
+banking security systems, even though they are digital, he destroys the
+idea that they are secured by technology. Instead he points out with
+many examples that it is the human processes that banks have, and
+non-technology things like audits, and recovering money even if the
+money is lost, that's what keeps them secure. Not access controls and
+money. You will be convinced of this if you read the chapter.
+
+Banks have an undo button. This is an important and key property of the
+financial system. You can reverse transactions. You have the force of
+law enforcement and the legal system to go after the perps of financial
+crime. He explains that it is these factors that keeps them secure.
+
+Of course, banks do have access controls. But it's a minor part. It's
+the detective and corrective measures of security that really keeps the
+financial system secure.
+
+The reason why this is relevant is because in Bitcoin we do not have the
+ability to undo or reverse transactions. So it is more difficult to go
+after perps. It forces us to do the most with preventive security. This
+is a key difference to understand. I will show you the magnitude of this
+difference.
+
+I want to point out that we often tend to forget this. In the usability
+panel, great panel by the way, people made the point that these banks
+have evolved security systems and they will be imported into the Bitcoin
+context. I think we have a lot to learn from banks, but bringing that
+into Bitcoin security is unlikely. There will be this big asymmetry
+always.
+
+Just to emphasize this difference. "Nobody sells gold for the price of
+silver" is a great paper that emphasizes that the reason why the
+financial system is secure is not because they have great ways of
+securing credentials, but because they have really good ways of ensuring
+that things don't blow up even if someone does.
+
+This is a quote: "In the underground market, in one example, 40k
+financial transactions with a face value of $10M and it traded for a
+market value of only $500." What does that tell you? Even if access
+control has been breached, the damage that can be caused is so little,
+because of reversibility. $10M to $500 and how much credentials are
+actually worth.
+
+Bitcoin does not have this luxury. This is fundamental. This is a good
+thing, we want no reversibility. This is why Bitcoin is great. But we
+have to acknowledge that it puts us on the back foot here. In Bitcoin if
+someone gets credentials for $10M, that's exactly worth $10M and there's
+no difference. Theft is more or less risk free and irreversible.
+
+There are some things we can do. I think the first step in solving the
+security problem is to acknowledge it and see how severe the disparity
+is with the traditional system.
+
+We need Bitcoin-specific security measures.
+
+In particular, software has never been put in a position where it has
+been the sole line of protection for money. Now it is. We need to deal
+with this. Software security has not evolved to respond to these high
+requirements. This is a cultural phenomenon that might change in the
+future but is not ready yet. Software security is not ready to handle by
+itself the stresses that Bitcoin puts it through. Every machine with
+Bitcoin is a sitting bug bounty.
+
+There are 100s of strains of malware that look for Bitcoin wallets.
+Kapersky Labs reports that there are over 100 million malware infections
+that are scanning for Bitcoin wallets, per month.
+
+By the way, we have seen this chart of these huge amounts of thefts and
+amounts and losses and so on. Sure we can call them stupid or something,
+that may even be true, but I want to point out that there are
+fundamental differences here and it is difficult. That's why we need
+better solutions.
+
+Multisig. I think it's great. You should use it. Just to recap a little
+it, the idea is simple. You associate N different keys with an address.
+You stipulate that at least M of those keys must sign. It's like
+splitting your keys, but not quite. What it allows you to do is to just
+imagine how this can be useful, two ways. You can split those keys
+between different users or employees. And what you can say now is that
+if you have 2-of-3, even if one of these people gets hit by a bus or
+leaves the company, you still have the other 2 that can come together to
+construct a valid transaction while you recover from this development.
+You have the assurance that one user on their own can't do anything with
+the money.
+
+You can also think of it as three different devices, so that if one gets
+infected with malware, the other two can still function while you
+recover from that hack.
+
+Great stuff. But now I am going to ask some uncomfortable questions
+about multisig. The whole point of this is to resist these attacks quite
+well. Let's examine in more detail what happens when those bad events
+happen.
+
+What happens when an employee joins or leaves? You have someone coming
+into the group, you want to make it 2-out-of-4. You have to move all of
+these BTC into a 2-of-4 address. You can't just add another key. When
+someone leaves the system, if someone turns out to be malicious or is
+fired, you have to do a similar thing.
+
+What happens if a machine is hacked? An adversary gets into one of those
+3 machines, they deploy some malware. Here's what's going to happen, if
+they succeeded, you have to recover from that, you are going to use the
+other 2 devices to a new 2-out-of-3 multisig address. You have to
+publicly wear a badge of shame for any negative event that may impact
+your security.
+
+This sort of accumulates over time. Any internal change you make to your
+security process, every external adverse event.. you have to advertise
+it on the blockchain. Multisig does not split your keys, it allows you
+to advertise on the blockchain that you want to use multiple keys.
+
+You have to constantly advertise which 2 of those people are signing a
+particular transaction. You are revealing way too much about the
+internals of your security and your current security situation to
+everyone on the blockchain. Companies have expressed concerns about
+this.
+
+Despite this, I think multisig is great. I had a student a couple days
+ago run some numbers about adoption of multisig on the blockchain (see
+p2sh.info). I think that's turning out to be true- 2014 was the year of
+multisig. What we saw is that adoption peaked in August 2014. It was
+around 1% of all transactions. This is bad people. I am here to tell you
+that threshold signatures are better, but multisig is still pretty good.
+There still needs to be more adoption of these technologies. Access
+control measures are not sophisticated enough to distinguish between
+malicious users and regular use of your funds.
+
+So if you count the 1% in terms of the amount of BTC controlled by
+multisig addresses, that number is much lower and that's a cause for
+concern.
+
+In particular, anonymity. Multisig kind of ruins anonymity. A big part
+of the reason why Bitcoin we expect to be pseudonymous, that people
+can't trace your transactions. Let's say that a user is buying something
+from a shop, she might construct a transaction, she combines two of her
+inputs, pay an output to the merchant, and then the other one is the
+change address. So they can't really trace because they aren't sure
+which output is which. Here's what multisig does to that picture. The
+two inputs and two outputs have a very specific structure. If you are
+using multisig you will be using it for your transactions. It will be
+apparent to someone looking at the blockchain as to which one
+corresponds to the user's wallet.
+
+Same thing with coinjoin. Different users come together and mix their
+inputs and outputs. Unless you are in a world where everyone is using
+multisig and same M-of-N for multisig, what you will see is that every
+one of these users will have a distinct structure for those addresses.
+
+So how do we fix these privacy issues?
+
+Threshold signatures, the intuition is simple. Multisignatures do not
+split your key. Threshold signatures do what you would expect them to
+do: you can take any key and then split the shares of the keys. You can
+share them however you like. You do not have to advertise them to the
+world. That's the key difference. That's the advantage.
+
+You don't need to broadcast your security policy to the world. Let me
+give you some intuition for that. What is splitting a key? You want m or
+more shares to construct the original key. If those people want to ...
+on the other hand for security, if there are fewer than m people, it
+provides no information about the key. This rules out simple solutions
+like splitting the keys into different parts and concatenating, because
+if m-1 people are compromised then that will leave out the key and it
+won't work...
+
+What is the key mathematical intuition behind splitting a key? Let's
+call your key S. Here's what happens geometrically. You want to draw a
+point on the Y axis that corresponds to X=0 and Y=S. We are thinking
+about this geometrically. Any key can be represented as a number. You
+don't have to draw the graph. Represent it as a point on your Y axis.
+You draw a line with a random slope through that point. Random slope is
+key. You picked this slope. Here's what you do. You pick an arbitrary
+point on that slope, you treat that as the number, you treat that as the
+share of the key. You give that to one employee. If that one employee is
+malicious, they will look at their share of the key, but they won't know
+what the slope was. So it could be any line through that point. The red
+point as far as that green user is concerned could be anything. So they
+have no information about what your secret is. A single user cannot
+compromise this system. But here's what's cool. You give different
+points to different users. Any two of them come together and they can
+draw a line through the two points, see where it intersects the Y axis,
+and reconstruct the key. This is how you can reconstruct the key so that
+not only one person can compromise the key. It's any M out of any
+number. It's a little bit more complex, instead of a line you draw a
+parabola or something and then you need 3 points, and fewer than 3
+points gives you no information about which parabola it is. Any two
+points can interpolate the secret.
+
+What's further cool about this is not just that you can take the split
+copies and put them into your machine. You don't have to put anything on
+the blockchain. What's also cool is that you can use any access control
+policy. You can designate these people as regular employees, and these
+people as managers and at least two people and one manager needs to sign
+off. All of this becomes possible, a much richer set of security
+policies.
+
+So you've told me how to split the key, but now I have to reconstruct
+it, and if I am reconstructing the key on my machine then all the
+security benefits are lost. Aha. So, the answer to that is that you.. it
+is in fact possible to not reconstruct the key and sign transactions.
+These devices could execute an interactive cryptographic protocol where
+the key is never constructed at any single place. I wont go into that. I
+will link to this paper. The math is explained in the paper.
+
+This is why we need new research. We need to bring this to Bitcoin. Key
+splitting was invented by Shamir, which is the S in RSA. How do we
+construct a signature without introducing a single point of failure?
+
+We have a paper showing how to do this. We have a prototype. It's a two
+factor wallet. Split your key between your computer and your phone. The
+two devices can in fact together construct copies of the key. The key is
+never on one single device. Never at any point in the system is there a
+single point of failure. This is the true vision that we wanted with
+threshold signatures. We forked multibit to do this. You initiate a
+transaction on multibit, it shows you a detail, you get a popup alert on
+your phone, to ensure that the details ... you should match the details
+on your phone and computer, and then you know whether there is malware.
+You have the guarantee that as long as one of your devices remains
+secure, then the transaction that you are creating is secure. After you
+confirm, there is an interactive protocol, a complex dance of messaging
+passing through which they can construct the signature without
+reconstructing the key.
+
+We have the prototype. We have the paper. Just to summarize, I will show
+you the link in a second. I hope what I have convinced you of is that
+banking has sophisticated security procedures. Those come into play
+because transactions are reversible and they have strong forms of KYC.
+For Bitcoin, multisig is good but it has drawbacks like it destroys
+anonymity and it forces you to display your security on the blockchain.
+Threshold signatures are a form of stealth multisig, it allows you to
+take control. Work with us to make this ready. This is the url.
+
+
+
+
+
+previous implementation problems:
+
+
+Q: Is the key generated in one place?
+
+A: Great question. No.
+
+
diff --git a/__transcripts__/mit-bitcoin-expo-2015/bitcoin-financing-and-trading.md b/__transcripts__/mit-bitcoin-expo-2015/bitcoin-financing-and-trading.md
new file mode 100644
index 0000000..bdc14cc
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/bitcoin-financing-and-trading.md
@@ -0,0 +1,435 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Bitcoin Financing And Trading
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %}
+
+- Joshua Lim (Circle, ex Goldman Sachs)
+- Juthica Chou (LedgerX) (Goldman Sachs)
+- Bobby Cho (ItBit) (VP of trading at SecondMarket)
+- Harry Yeh (moderator) (Binary Financial)
+
+Today we will hear from some people who are traders and also
+infrastructure providers. Good morning everybody. It took me 18 hours to
+get here. The Uber dropped me off at the wrong building. They need
+better signs.
+
+So usually I am the one that sits on the panel. This is actually the
+first time I get to moderate. I get to ask the questions that nobody
+else gets to ask. I am kind of curious about this.
+
+Josh, do you trade on coinbase? Yes, we do. We really respect a lot of
+the great products that are coming out of Coinbase. I think they add a
+lot to the ecosystem. We want to work more closely with them in the
+future.
+
+This is more of a trading panel, so I will spend time talking about
+exchanges and things that I am curious about because I trade on these
+exchanges.
+
+So Bobby, why is everyone building exchanges? Aren't there so many of
+them? It seems like a race to the bottom to 0% fees. As an exchange
+operator what do you think?
+
+Bobby: Yes, you have a large number of people starting exchanges. In
+China and Asia you do not have that kind of action going on. There are
+market leaders in that country. Here in the US, nobody has really
+grasped it. A lot of the exchanges that do trade the USD pair are
+off-shore. So nobody has cracked the solution here in the US to being a
+fully regulated exchange, nation-wide. So that's obviously what we're
+hoping to solve in the coming future.
+
+So that leads me to the next question. Is the United States actually the
+most important market for Bitcoin? So first off, the United States is a
+heavily regulated market. Do you guys actually think.. it just doesn't
+seem that the US is the most important market? Does China lead the
+price?
+
+Josh: I think this is something that we have observed over the last
+year. The growth of trading and speculative use of Bitcoin in the
+Chinese market. If you just observe based on published volume that
+Chinese published volumes are 5-10x more than the USD volume. I think
+that's .. that's what, I think that in Asia that's a common use of
+speculative instruments as a you know, that type of mentality of using
+it as a speculative instrument. The United States leads in a couple of
+other ways. I think that in terms of practical applications of Bitcoin
+in an economic sense, meaning consumers to purchase goods.. I think
+that's where a lot of the exchanges that are cropping up in the US are
+facilitating the growth of that organic usage of Bitcoin rather than
+just a speculative instrument.
+
+Bobby: So basically, I think there's a lot of hope and opportunity in
+the United States. I think that China may be leading in volume. When you
+think about broker dealers, hedge funds, alternative asset managers and
+guys like them, I think the opportunities for Bitcoin to grow in a new
+market is what we're trying to solve here.
+
+That leads me to my next point. The US is actually leading the way in
+terms of innovation. So I see it in investment capital, Coinbase just
+raised $75 million recently, it seems like there's a lot more venture
+investment. Versus in China, where I spent some time-- even though
+volume is up, investment is not. Do you think over-regulation is
+stifling innovation?
+
+Juthica: I wouldn't say that there's too much or too little. I think the
+biggest difficulty for people starting companies is that there's a lot
+of uncertainty at the state and federal levels. That's the biggest
+challenge that new innovative companies are up against.
+
+Bobby: Look, the bottom line when you talk about regulation is what is
+it trying to solve? Well that's consumer protection. You can lead into
+the banking sector and other types of markets, really it's about
+protecting consumers. When you talk about customers or certain people in
+certain states sending money overseas, where are they going to go? Well
+they may go to their state representatives. I think that the regulatory
+bodies-- to basically say, let's look at this as an opportunity rather
+than just killing it right off, I think that's where we are right now.
+
+Josh: I think Bobby makes a good point about consumer protection.
+Companies in our ecosystem are struggling against a patchwork of
+regulations, created by state banking departments. When you want to
+engage in money transmission activities, you have to go state by state
+and get licensed. That does impose a heavy burden. I think that the core
+of this is that each state wants to protects its own citizens. There are
+also other interests at play for regulators. There's the, I would say
+the AML kind of like, counter-financing of terrorism angle where there's
+a need to control the gateways into and out of Bitcoin where it touches
+fiat currencies. I think that's something that is regulated on a federal
+level with FinCEN and the Federal Reserve. There's another angle which
+is the markets regulation piece. That's really the piece that is sort of
+missing in the United States. It is being built up as we sit here and
+talk about it. Juthica has more perspective on this, I know that the
+CFTC is getting very much more and more involved with the kind of
+development of derivatives exchanges and futures exchanges in Bitcoin
+and I think that is going to be an important catalyst.
+
+Do you just build a startup and worry about the rules later? You see
+companies like Coinbase that are building and releasing a product that
+is dealing with regulation at the same time. Juthica, it sounds like you
+have product ready? What would you guys suggest or recommend? What is
+the right path for a startup?
+
+Juthica: I think a lot of companies and exchanges and startups have
+different vectors or levers to use to be competitive. Well, who is your
+customer? Our customer is institutions. We have to prioritize trade
+reporting, centralized clearing, surveillance, and other customer bases
+may not care about those issues.
+
+Bobby: I think there's a whole spectrum of different companies in the
+Bitcoin space. Bitcoin touches many different laws and regulations. You
+definitely want to talk with inside or outside council on this. Yes
+Bitcoin is a new technology, but for companies like us, we're still
+touching cash. There are still rules about how to act as a custodian.
+You can't just dismiss this. You have to acknowledge that.
+
+This leads me to my next point. Is there too much or not enough? I think
+there's too much, but I think that's mostly because of the bad actors
+before hand.
+
+Bobby: I don't think there's really that much regulation here in the
+United States as it relates to Bitcoin specifically. I think there's a
+ton of regulation on anti-money laundering and money transmission. I
+think it's rightfully so because it boils down to consumer protection.
+In my mind that's where it is. With Bitcoin regulation, it's to be
+decided at least in the State of New York. The BitLicense which I think
+will hopefully this year come to market and give companies guidance in
+terms of what they should and should not be doing. I think that after
+that you will see other states adopt BitLicense.
+
+Josh: I think that the BitLicense is a good case study for how
+regulation and how the regulatory bodies can do the interplay between
+them and the Bitcoin ecosystem. When kind of the first draft came out, a
+lot of people saw a lot of issues with it, like the NYDFS was perceived
+as regulating software developers. It was perceived as too onerous for
+startups. Just a couple of guys hacking on a project would fall under
+the NYDFS BitLicense. I think that after extensive work by the community
+to reach out to Ben Lawsky and other regulators, there was a lot of
+concessions made in favor of Ben Lawsky in the Bitcoin ecosystem to the
+tune of having on-ramps and to the tune of explicitly carving out
+software developers and things like that. That's a good model for going
+forward for what we might see. Something else to mention is that there's
+also a group of conference of.. supervisors who are working on a model
+framework for how Bitcoin regulation should work on a state-by-state
+basis. That may provide some level of uniformity in terms of approaching
+the regulation.
+
+Juthica; I think in the cases of the areas where we see more clarity, it
+has been more promising. Our regulator is the CFTC and they have
+extensive history regulating a variety of commodity and currency
+derivatives. We have had nothing but positive dialog with them. They
+have been open and understanding and they have really educated
+themselves about Bitcoin. Some of the uncertainty is still the difficult
+piece.
+
+So clearly there's a lot of regulation. So I want to transition to
+derivatives. We used to trade derivatives in the equity market. I think
+derivatives are exciting. So Juthica, what are your views on Bitcoin
+derivatives? Will it be beneficial for the price?
+
+Juthica: Listen, I think that a real ecosystem has developed around
+Bitcoin. I think there are real use-cases and real companies with
+legitimate exposures. Derivatives provide unique hedging and investment
+opportunities. I think that it is definitely true here. Historically the
+advent of derivatives has improved stability and I think we will see
+something here.
+
+Isn't price volatility good for traders?
+
+Juthica: It creates opportunities for traders. I think not everyone
+wants that risk. It should sit at the level of institutions that are
+comfortable managing it. There are certain corporations that are
+comfortable, but not everyone should be facing the price volatility
+risk.
+
+Josh: My role at Circle is manging the treasury operations. We see
+transactions coming from our customers, we access exchanges, we talk
+with trading partners, and we try to find ways to reduce risk from our
+customer flow. A lot of risk we can mitigate with derivatives, there's a
+risk associated with holding Bitcoin and as you know it's a volatile
+currency, so our market exposure can be reduced by trading options. At a
+macro level, derivatives can help with this. You can use them as a gauge
+for how people are pricing risk on a forward basis. You can see how
+other people think how risky Bitcoin is according to other people's
+perceptions. You can use this to guide hedging decisions. Juthica
+alluded to this benefit, but the growths of derivatives markets tends to
+add liquidity to an underlying spot market, which has been observed
+empirically.
+
+Bobby: Which part of derivatives do you think will lead forward? The
+futures market in China is really for- seems more like for gamblers. I
+wouldn't want to hedge my portfolio with BTC denominated 10 or 20x
+leverage. And then the clawbacks...
+
+Juthica: I think different types of derivatives offer different
+exposures. We are starting with options. They offer more targeted and
+nuanced exposures. I think the real important part is the clearing of
+derivatives because it's not as straight-forward as a spot transaction.
+That risk needs to sit with counterparties and are ideally regulated to
+manage it. I think that the clearing component is going to be an
+important piece for the market.
+
+Josh: I am often shocked to see the growth of the Chinese futures
+market. I don't know if you have experience trading on the retail
+trading platforms like OKcoin, but the volumes there are stunning. I
+think recently in the recent rally that there was a one day where
+600,000 BTC volume traded on the futures. That's about $150 million.
+That's published volume so you can maybe take that with a grain of salt.
+That's very significant volume and that dwarfs the underlying spot
+market.
+
+Harry: Excellent, so that's most of the questions regarding derivatives.
+Oh, price. Sure, why not. Usually people ask me about the price, but
+okay. What do you think about the price long-term? What do you think is
+the fair price of Bitcoin? I think it will be about $10,000 at some
+point.
+
+Bobby: I think the current price is at a good level. What would you pay,
+theoretically, this widget or this tool that could essentially do a
+whole lot in the future? So you are basically buying for a future
+utility of this product or technology or whatever you want to call it.
+So I think the price is right where it should be for now. I don't see a
+huge spike in the future.
+
+Juthica: I am not going to answer the price question. I think that the
+next big catalysts will be as regulated US exchanges come online. I
+think there is latent demand that just can't get exposure to Bitcoin
+with the current platforms that exist. I think this will be a positive
+price catalyst.
+
+Joshua: I think the biggest catalyst would be the adoption of large
+institutional investment community, like Wall Street and hedge funds.
+You need to have that base of long-term buyers to counteract the steady
+supply from mining that hits the market every day. That's what needs to
+evolve and deepen over the next few years before we can see sustained
+price rallies. I think like the other catalysts that you should look at
+is the equitized assets for Bitcoin, like ETFs and the Bitcoin
+Investment Trust recently was approved by FINRA to be listed OTC. I
+think products like that expand the availability of Bitcoin to certain
+types of users and people who want to invest in Bitcoin from 401ks. I
+think that's bullish.
+
+Harry: In China, most of them are retail investors. Do you think more
+sophisticated investors? Interactive brokers?
+
+Bobby: So, our exchange will and will be open to retail traders ,but our
+target is institutions. The retail flow is good, but if you are trying
+to take this to the moon, you need to open up this product to the
+existing investment world. Hedge funds, multi-family offices, folks like
+them. I think that for us to take a leap forward in terms of adoption or
+even in price, you need to start getting the real money guys.
+
+Juthica: Our platform is for institutions as well. Especially on the
+hedging side, the most important piece first is the natural longs and
+natural shorts, serving the kind of true hedging needs, and once more of
+a market develops I could imagine more of a retail presence in the
+United States.
+
+Joshua: We currently do not service any institutional accounts, we are
+purely a consumer product.
+
+Harry: You with sunglasses and purple shirt. Can we give him a mic?
+
+Q: How are the back office environments with brokers? Bitcoin
+infrastructure?
+
+Harry: So the question is...
+
+Bobby: So how are banks integrating with Bitcoin and back office
+settlement operations?
+
+Harry: Go up to the mic.
+
+Q: What are you seeing in terms of banks, regulators and industry groups
+like NSCC, Federal Reserve, DTCC, how are they looking to adopt and
+when, the Bitcoin infrastructure to make things more efficient?
+
+Bobby: I think that they are all interested in the technology. I think
+as Andreas mentioned in the last session that they have looked past the
+currency. They have realized there's an interesting, trustless
+decentralized public ledger that they might want to leverage for
+tracking or audit or something. They are all looking at it. I don't
+think banks have integrated. For any bank to dismiss this technology and
+say they don't want involvement, I think that would be very
+shortsighted.
+
+Juthica: I think one of the best and clearest use cases for Bitcoin in
+the Western world in institutions is clearing and settling. It is a
+fantastic form of collateral. Better than a lot of what exists right now
+in clearinghouses. This is why we have applied to be a clearinghouse. I
+think that clearing organizations are looking at it. I think they
+recognize the potential. It's too early for them to start doing
+something about it actively.
+
+Joshua: I think collateral is a great application of Bitcoin. You can
+continuously throughout the day or night, just settle your collateral
+obligations, I think that's a great use of Bitcoin.
+
+Harry: You get the next question.
+
+Q: Thanks guys. So on OKCoin and Huobi.. I don't know about margin. But
+20 to 1 margin on something as volatile as Bitcoin to retail investors
+is like selling dynamite to little kids or something.
+
+Harry: Yes, that's China.
+
+Q: Is that like, just an interesting development or something that will
+stop eventually?
+
+Harry: So the question is do we think the leverage trading at 20x is
+like selling dynamite to children? I think the answer is yes. I think
+that's gambling. We do not use their futures platform for trading at
+all. The only futures platform that we think people can use is BitMEX,
+but that's Bitcoin denominated. I think that 3 to 1 is more reasonable,
+because that's actually what is considered reasonable. It's ind of like
+opening up a forex account and saying you can get 100x leverage.
+
+Bobby: There are reasons why the SEC denotes people as qualified
+institutional buyers. Because they meet certain requirements. These
+other exchanges are empowering the retail investor to feel like a quib
+or an accredited investor, to get 25 to 1 or 50 to 1. We wouldn't do it,
+I think it's a gambling mentality. I think it's just a different way of
+looking at things.
+
+Juthica: Philosophically, I think that exchanges should not be competing
+on margin.
+
+Joshua: I get enough excitement out of 1 to 1 leverage. 20 to 1 sounds
+kind of crazy to me. Even traditional FX markets have been extremely
+volatile lately, and this has had bad consequences for margin trading
+platforms that offer high leverage to even traditionally stable
+safe-haven currencies like the Swiss franc.
+
+Harry: So yeah, I hope you don't trade on those exchanges. Yes you may
+have the next question.
+
+Q: The mots important advantage of Bitcoin seems to be a currency with
+trust. But when we convert Bitcoin into fiat currencies we have to
+introduce trust again. So you guys run Bitcoin exchanges. What do you
+think about trust on Bitcoin exchanges? Is there any way to mitigate the
+problem of trust in Bitcoin exchanges?
+
+Harry: So the question is that Bitcoin was designed to be trustless, but
+when you go to fiat you have to introduce trust.
+
+Bobby: We are regulatory compliant in every district that we operate in,
+and this will happen in the United States in the near future. So it's
+the way you build the trust. Why do you trust TD Ameritrade or Schwab?
+Well it's because they have capital requirements, banking licensing
+requirements, I think that's the way you get people to trust you. You
+meet some requirements from regulation, and in turn this is why nobody
+asks Schwab to mail them their certificates. For better or worse,
+Bitcoin exchanges, and I was the same way when I was trading at Second
+Market, I never wanted to have any exposure on the exchanges... I think
+that what we're trying to do is build a company that people trust, and
+it starts with management, our board and the folks we bring into the
+company.
+
+Harry: I don't think you will have trustless money. Bitcoin is a
+protocol for transfer. If someone is going to wire you $5M to buy
+Bitcoin, you have to trust that they wont run off with your $5M.
+Technology does not replace trust, it just makes it more convenient.
+Next question?
+
+Q: So the question is about derivatives and bubbles. So we have had for
+four centuries.. tulip mania and systematically wiped out assets and
+ecosystems. As China ... regulation.. are we at a point where we could
+cause disasters? Is the system in place to protect the evolution and
+growth of Bitcoin? Or is that a big fear? A bubble will be in
+everything. Is there fear with this group? Do you believe there are
+systems in place? From a speculation and derivatives standpoint.
+
+Harry: I don't think we're at that point yet. The drop from $1000 to
+$155 and back up, that's just the way Bitcoin is because there's no way
+to hedge yet. I think that once hedging comes in. I think you will see
+big massive price swings... big events will cause the price to drop.
+
+Juthica: Healthy derivatives markets have a good mix with speculators
+and derivatives.
+
+Joshua: We see that the underlying Bitcoin trading infrastructure has
+not yet been made yet. We are trying to build the foundation for this.
+It starts with a spot market. You get price discovery. Then you can move
+on to derivatives.
+
+Harry: There is no WMD of derivatives yet. Okay, mic.
+
+Q: So one of the things that came out of MtGox was heavy accusations
+from the Willy Report that there were trading bots that were pumping up
+the price. What is the next generation of Bitcoin trading institutions
+doing to prevent those things again?
+
+Harry: I like the way you said MtGox. Empty. The question is what is
+going to be with... with exchanges in the future.. to mitigate trading
+bots?
+
+Bobby: Any exchange that is running principal money against their
+customers is in my mind a huge ordeal and bad. I think that exchanges
+doing this are taking advantage of their customers. We don't do that. We
+don't run proprietary trading bots. We do have market makers. But we
+would never run against customer orders.
+
+Juthica: Regulated derivatives exchanges are subject to extensive trade
+surveillance to identify fraud. I think we will see more surveillance.
+
+Harry: Okay last question.
+
+Q: This is regarding.. it is great there's a lot of trading happening.
+Do you guy have a view on what is the ratio of real useful transactions
+versus trading transactions on the blockchain?
+
+Harry: So the question is it's almost utility versus speculation?
+
+Joshua: There are many ways to approach this question. How much is
+transacted per day in Bitcoin? I think this is a better question for
+merchant processors like Coinbase to answer. I would estimate like a few
+million or less per day. And of course you have the mining volume which
+is real economic value that needs to be transferred, so that's probably
+a few million. I think a lot of that.. you can gauge that ratio by
+looking at Chinese volume versus US volume, that might be a good ratio
+to figure out speculation. You can also look at these fundamental
+metrics like mining activity versus exchange volume traded.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/bitcoin-regulation-landscape.md b/__transcripts__/mit-bitcoin-expo-2015/bitcoin-regulation-landscape.md
new file mode 100644
index 0000000..ec32d68
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/bitcoin-regulation-landscape.md
@@ -0,0 +1,279 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Bitcoin Regulation Landscape
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %}
+
+- Elizabeth Stark
+- Jerry Brito
+- Constance Choi
+- Christian Catalini (moderator)
+
+MIT Compton Labs - Building 26, room 100
+
+
+
+Okay guys, we are getting close to the time for the next panel. Head
+back to your seats. You may bring food in with you. We also started 15
+minutes late. People have 15 minutes .. we ended lunch on time. One of
+our speakers literally only came for 30 minutes today, 2 to 230.
+
+It's going to be escape. I don't know how to use Macs. It will be
+minimize and then just go to panels and it will be the seventy first in
+there. I think the livestream is not filming that though. Do you want to
+do it before we announce it? Did we find her? Yeah, we found her. Okay,
+that's fine. Oh, we have water for them. Nice. Talking to Constance
+then. Let's do one more run.
+
+Hello everybody. We are going to get the next panel started focusing on
+Bitcoin regulation. Christian focuses on equity crowdfunding and the MIT
+Bitcoin project. If you would like to submit a specific question, tweet
+it @ccatalini. We are going to hand it off now.
+
+Christian: I would like to welcome the panel. This will be difficult
+because we are after lunch. Talking about regulation at MIT, a place
+known for building things and breaking things, will be challenging but
+we have some great help. We have Constance on my left, she has a JD. She
+was the general council and CCO for Kraken. She is a digital currency
+expert and has founded data. Next is Elizabeth, a graduate from Harvard
+at Coin Center which we will hear more about in a second. Last and not
+least we have Jerry, an adjunct professor of law, also the executive
+director of Coin Center, an institution trying to bridge the gap between
+research, academics, practicioners and policymakers. This panel will be
+about policy.
+
+Christian: I want to start with a controversial ... ((Sorry,
+interrupted))
+
+Christian: We should try to avoid market failure. We should avoid
+destruction of public goods. As we move into other forms of intellectual
+property, we really need to rethink how we deal with regulation and how
+we go about the process of regulation today. On that positive note, I
+would like to open it up to our panel to hear if you had a blank slate,
+knowing what you know about this space and the dynamics of intellectual
+property and regulation and policymakers, how would you go about
+reinventing the debate for the modern era?
+
+Jerry: If I had a blank slate and if I could do anything, so much of the
+problem with regulation is path dependency. Okay, now it's on. So the
+question is, if I had a blank slate, so nothing there, and a magic wand,
+those pieces are important. The blank slate is important because so many
+issues with regulation today that makes regulation inefficient is path
+dependency and bureaucracy that makes it difficult to change. What I
+would do is think about the purpose of regulation and then see if
+technology allows us to achieve that purpose without a prescriptive
+approach. Money transmission regulation which each of the states does
+for itself is a type of regulation that effects Bitcoin business. If you
+want to start an exchange, or hold custody, you need to have a money
+transmission license. Ultimately it is an information asymmetry problem.
+The regulators are trying to address this with regulation. If you are a
+low income person with a checking account and you get paid, let's say
+you cash your check, you need to pay your electric bill. But they don't
+take cash. Okay, you get a money order from the money order company. You
+buy a money order, you send it to your electric company. When they go to
+cash it, it bounces. Why? Well the company went out of business. They
+didn't have enough reserves. You didn't know that going in. But the
+regulator sees this as an information asymmetry problem. So they think
+they will license the business and require that they have a bond and see
+on a regular basis when they audit them once a year that they are
+solvent. But the technology now allows us to see transparently on a
+minute by minute basis whether the company is solvent. So therefore you
+don't need the regulation as it once was. I think we would look at the
+regulation and then determine whether we need permissioning from the
+government.
+
+Elizabeth: I think that regulation is a boring word. To me this is much
+more of a question of the feature viability of the ecosystem. As Jerry
+stated, this is about what the technology is capable of doing. And how
+it can serve a community and consumers. Our current regime is built for
+an analog age. We didn't have cryptography. The early internet has been
+instrumental in a lot of my work. We are lucky particularly to counter
+the statement about AT&T. Telecom was substantially different from the
+development of the internet. Arguably the internet has become more
+centralized but maybe the blockchain technology can take us back. Early
+internet had safe harbors. They were laws that enabled or often promoted
+uses that say comply with the law but did not hold intermediaries
+liable. So if I am youtube.com or facebook.com and someone posted an
+infringing image, I could still operate that platform as long as I
+comply with those laws. Ultimately anyone could startup a new site, an
+open source project, a business, and they don't have to ask permission
+from the government. Well, in money transmission you must ask
+permission. So we have seen relatively little innovation. Our current
+regime is flawed in the idea that once must ask for permission.
+Blockchain solutions, multisig, real-time continuous auditing will
+promote to regulators as the way forward as opposed to the idea... by
+the way, $5k per startups per 50 states, and all the legal fees
+involved, is a lot of money for a startup that only has $100k and a few
+coders working in a basement. We need to reshape the conversation
+regarding what's possible and what the community can build.
+
+Constance: The internet offers us a lot of really great lessons on how
+we can deal with nascent technology and how permissionless innovation is
+not only good for people but also good for the market. The problem of
+course is that, you know, we're running internet technology technologies
+straight into financial regulations which are the most draconian and
+most rigorous of regulations. The two don't quite meet. So you are also
+meeting a problem of translation, with policy goals that are now trying
+to be adapted to this decentralized world and the analogies do not bare.
+So we need an entirely new conversation about what the goals are of
+these rules and how we can build the right rules rather than complying
+with existing broken rules. Law moves very slowly ,as Christian
+mentioned. It's based on analogy and precedent. Transformative
+technology challenges lawmakers and lawyers to make that active
+translation. On the regulatory front, there's a misalignment of
+incentives. You have one federal agency focused on security of finance,
+and then others that are evaluating firms for soundness, and then
+another one about horizontal access to the developing world. Everyone
+has their own specific mandate and a limited idea about the technology.
+As public policy concerns are being brought up, it's a challenge for
+lawmakers. So what would I do with a blank slate? The problem with these
+exponentially transformative technologies is that it exacerbates the
+governance gap. So we have to, because these issues are complex and
+multi-disciplinary, you can't have one regulator talking to a
+technologist and expect the right policies will emerge. I think on one
+hand we need to build our products and services in such a way to provide
+security and to provide sound products to consumers and address the
+usability issues. On the other end, we need to steer that conversation
+as both Jerry and Elizabeth have mentioned, we need a collaborative
+rulemaking process rather than one agency coming out with a proposal,
+the community reacting, and a conversation based on old paradigms and
+issues.
+
+Christian: If I was to summarize all three of you, it sounds like safe
+harbor is key here. The internet analogy is useful, but we need to not
+forget that getting safe harbor right or wrong could determine the
+policy. So it is about policy. If it is too narrow, then the safe harbor
+is useless. If it is too broad, then we run into market failure issues
+or damages to consumer confidence. So how could you envision a better
+process where you have policymakers on one side, and developers, hackers
+and platforms on the other side trying to come up with new technological
+solutions? Yes we can envision the fruits of this wonderful technology,
+but there's years of development on the way, for smart contracts,
+intellectual property.
+
+Constance: I think that is a problem we all identify. Technologists are
+building. The regulators know what the concerns are but they have no
+idea what the capabilities are. So the two must meet. So what we've done
+is we put a multi-disciplinary workshop at MIT and Harvard this January
+and we had a group of technologists, subject matter experts across four
+days distilling what the state of the technology is, talking about the
+regulatory concerns and mapping the goals of these rules to these means.
+And so we have working papers now across various subject matters like
+smart contracts, DAOs, oversight for decentralized networks ((what?)).
+This is also at Stanford at the end of March. We are bringing in
+policymakers, lawyers, legal experts, privacy experts, cryptographers so
+that we can substantiate what the technology is capable of now and
+perhaps the policy goalposts have moved.
+
+Jerry: I think there's a two-pronged approach. I think we need
+processes. We need to articulate exactly what we envision as an
+alternative to regulation. But at the same time, we have to recognize
+that regulators are people who have incentives that they are responding
+to. Those incentives are things like a statute that they are required to
+enforce. They are reading the statute, they may not think it applies,
+but their job is to enforce. So we have to be ready with these ideas to,
+in short terms, thinking, you have to figure out how to get it as good
+as you can get it. I think ultimately there are some laws some
+regulations that are impossible to comply with if you use.. using this
+technology. I think this is going to bring some conversations to a head.
+I think those will come soon enough. If you are talking about money
+transmission, AML (anti-money laundering), yes I am slipping into
+jargon. You do have to be reactive sometimes. I think you try to
+anticipate, but sometimes it is waiting to see what the regulators want
+to do. Hopefully you have tried to shape their thinking about it, that
+they have the right information so they are not misinformed about what
+they are regulating.
+
+Elizabeth: I am concerned right now. California just this last week
+released a law saying that no virtual currency company can operate in
+the state without a license or an exemption for banks or a big
+corporation. New York has released a proposal that would stifle
+innovation in its state and beyond. Regulation is the biggest threat to
+the Bitcoin ecosystem. Part of why I am so concerned, this community,
+and there are some people that don't want regulation.. People need to
+band together, and they need to say we can do things better. For
+example, the recent Bitstamp hack I am sure people have heard about. It
+is inexcusable that Bitstamp wasn't using multisig. We can do better as
+a community. We can implement this. We can show policymakers and
+regulators that we can be more secure and more efficient. That is our
+job right now. I invite the community to engage and get involved. Tell
+policymakers and regulators that we can do better, and that the laws
+they are proposing will not work for our space. There is an argument
+that maybe some investors will invest, but much of the VC funding is
+here in this country. The internet is global. Australia and the UK are
+far more friendly and open minded to Bitcoin. They want to compete on
+this level. People will leave. Entrepreneurs are leaving this country to
+go elsewhere.
+
+Christian: Yes, regulation can stifle innovation. How do we get the
+problems that the regulators have to comply with, because of old laws?
+Or there is still an issue that they have to pursue? How do we get those
+problems into those communities?
+
+Jerry: Multisig, and proof of solvency, are already working. How do you
+convince regulators? I think it is hard to show up and talk to them
+about a futuristic vision about replacing regulation (there job) with an
+algorithm. I think you need to just do it. Just build it. I think that's
+what we're seeing. And then it's a matter of.. trying to get rid of that
+vestige.
+
+Constance: I do think that it is also a problem of, the ecosystem is
+small and we are dealing with powerful incumbents. There is so much
+innovation in Bitcoin that there needs to be more coordination and
+collaboration. If this fulfills a slightest fraction of the potential
+that we all suspect, there's more than enough market share for everyone.
+If we can raise the common floor of practices in this space, if we can
+prevent these badly executed hacks, implement best practices like
+multisig or proof of reserves, these would stop bad news stories that is
+feeding into a very misleading news narrative about what Bitcoin is. We
+should collaborate and share practices. It is incredibly powerful to the
+regulators when the ecosystem does act like adults. When you look at
+when MtGox went down, and the leading exchanges and wallets in this
+space,
+
+((feed cutoff at 2h 46m 34s))
+
+Constance: it is powerful to the regulators when .. I remember when I
+was young, I overheard that 10% of the role earned 90% of the wealth.
+That was inconceivable to me. So now you are seeing an acceleration of
+that inequality, which I think is systematic. I think the financial
+rails have contributed to that. One of the exciting things about the
+blockchain is the ability to have an immutable incorruptible data trail
+((this is not entirely true though?)). Many people think that GDP is the
+cake and everything else is the icing. The truth is that the GDP is the
+icing. The actual value creation is what counts. What would be very
+interesting and what I would like to see is people creating value
+systems that count the actual value creation. That would be an
+interesting exercise.
+
+Elizabeth: It gives us a chance to start over. This is why this
+discussion is so important.
+
+Q: There's different kinds of regulation. It's not so black and white.
+Look at for instance healthcare. Regulation, traditionally was primarily
+at the edge through licensed professionals. Accountants the same way.
+Lawyers too. It was only recently that regulation has focused on more on
+the central, the hospital, the vendor, the FDA. Where could that kind of
+to the extent that Bitcoin is a distributed environment could there be
+an intermediate regulation where there is a professional licensed as a
+profession rather than capital intensive infrastructure?
+
+Jerry: So, you know, regulators are always going to try to find the
+choke point that is easiest place with the least amount of effort to get
+what they want done. That is going to be an intermediary. So Bobby,
+sorry, Charlie Lee was talking earlier about online gambling and how the
+way gambling is regulated is through payment processors because there's
+four or five payment processors you can go to and say don't allow
+gambling. If you have a decentralized system like Bitcoin and everyone
+has their own bank, it becomes difficult. It's not impossible, but it's
+much more costly to regulate those endpoints. We see new intermediaries.
+
+Hopefully we can get around market failures and ... a perfect market I
+know we heard one, I know that economists believe that market failure
+reasons exist, I think we have enough talent in this room to tackle
+those challenges thank you very much.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/decentralization-through-game-theory.md b/__transcripts__/mit-bitcoin-expo-2015/decentralization-through-game-theory.md
new file mode 100644
index 0000000..e3e2ec9
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/decentralization-through-game-theory.md
@@ -0,0 +1,358 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Decentralization Through Game Theory
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Andreas Antonopoulos
+
+Thank you Charlie, let's have another round of applause. Up next, we
+have Andreas Antonopoulos.
+
+So I may make this a bit difficult for the camera because I hate
+standing behind the podium. Welcome everyone. How are you, thank you for
+coming. How many people in this audience own Bitcoin?
+
+So I usually start my question with that. And most audiences that gives
+me an accurate representation. You gave Bitcoin to every undergraduate,
+so you ruined my polling ability.
+
+How many of you understand how mining works? Wow, okay. So today I am
+going to talk about mining. This is the MIT bitcoin expo, not the
+blockchain expo.
+
+I go to conferences all the time that are blockchain conferences, and
+not Bitcoin conferences. A couple years ago, when Bitcoin came up in
+conversation or in the media, it was described as bullshit. Bitcoin,
+bah. Nerd money, right?
+
+That was my reaction when I first came across Bitcoin until I read the
+whitepaper. The media continued with this story. Eh, Bitcoin is just
+silly. It's not going to work. It not working one year, two years, three
+years, not working four years, the story becomes less and less tenable.
+You keep announcing that Bitcoin is dead, only to be proven wrong 3
+months later and be ridiculed by sites like Bitcoin Obituaries. So if
+you are a journalist that starts to hurt, so you have to change your
+song.
+
+So this went from "Bitcoin is bullshit" to "the currency is bullshit,
+but the technology is interesting". They talk about putting the Federal
+Reserve in charge, giving the blockchain technology to Visa and they
+will build something cool with it. So they are triangulating.
+
+And this is a fundamental failure of understanding of what the
+blockchain is. The blockchain without Bitcoin doesn't work. The
+blockchain doesn't work without Bitcoin. The blockchain and the
+technology behind Bitcoin is based on a very careful balance of game
+theory that creates conditions whereby participants in the network
+compete to solve a mathematical problem and get reward for it. In
+competing, and through this arms race, they have escalated this
+competition to a point of using massive rows of hardware in giant
+warehouses that consume megawatts of electricity. They are spending real
+money, as the journalists call it, to pay the electricity bills in order
+to make Bitcoin.
+
+And this isn't some kind of side effect. This is not an appendage to the
+system. This is not some kind of weird fascination or get rich quick
+scheme. This is the entire basis of the security mechanism. You need
+competition. The competition needs to pit the possibility of pitting
+honest players against dishonest players. You enforce that by forcing
+the rules of consensus and you do that if only you give reward.
+
+What happens if that reward is not valuable? Nobody needs to do it
+anymore. Why would anyone spend real electricity to do it? What would
+happen if the cost of mining was not expensive? What if you could make
+mining more efficient so that you are not wasting money securing the
+network? Well then the cost of attacking the network drops. So now you
+can attack the network without expending any money. So there's no
+incentive to do anything honestly.
+
+The careful balance is this: I am going to invest in a load of hardware,
+I am going to hook this up to a megawatt of electricity and I am going
+to spend 90% of my profits on paying for that electricity bill. Meaning
+that if I mess up and I don't follow the rules of consensus and I do not
+play honestly, as defined by the rules, I will not get rewarded. And I
+will still have to pay the electricity bill, and this will cost me a lot
+of money. So it makes it dangerous to play against the rules of
+consensus. Short term you may win, but long-term you are burning an
+investment.
+
+If you put all of your money into hashing to attack the network, once
+you built it and turn it on, you realize that you could attack the
+network, or you can make yourself some Bitcoin and earn that reward. The
+game theory makes sure that every time you make that thought, you play
+the game by the rules of consensus. If you have the hashing power, it is
+more profitable to play by the rules. You can't have cheap mining. Cheap
+mining means no risk. And without risk, why have reward?
+
+You can't make mining without reward, because you can't take risk
+without a reward. You can't have a blockchain without this balance
+between risk and reward. There is no blockchain without a valuable
+currency unit.
+
+Right now, Bitcoin is a featherweight in terms of international terms.
+Bitcoin is a toddler with only a $3 billion "valuation". There are many
+more corporations that have more money. There are countries with more
+money. By comparison, Bitcoin does not compete as a national currency.
+However, Bitcoin is currently running a global level security
+infrastructure which means that Bitcoin is resistant to international
+class computing attacks against it. We have bought a world class
+security infrastructure to run a featherweight class currency. Does that
+look inefficient? Yeah, it really does. We are securing from
+multinationals, conglomerates, nation states, etc. Bitcoin is alive
+despite the fact that it is being relentlessly attacked every day and
+every minute of every hour. The arms race created by the incentive
+structure of mining has escalated to the point of delivering world
+class, international class security for what is still a featherweight
+currency.
+
+If you look at it, you may say it's sort of expensive for a $2 or $4
+billion currency. Well, that assumes that the currency wont grow. That's
+a fundamental misunderstanding, that mining has to scale as the adoption
+of the currency scales. We already have world class security from the
+mining. We don't need a single petahash of more mining to scale Bitcoin
+to $100 billion or $1 trillion. We could run a $1 trillion Bitcoin
+network on the current 400 petahashes of mining that we have right now,
+I don't remember the exact number.
+
+We have bought ourselves a big vault, and it was expensive, and we
+opened up that giant warehouse vault and we parked a tricycle in it. A
+kid's tricycle. One time that vault could hold 100 ferraris, and right
+now it is holding a tricycle and it looks silly, but that's okay. We can
+grow into it.
+
+And this is important and some people don't understand. When we grow
+into it, then Bitcoin is not inefficient. If Bitcoin is supporting a
+national-scale currency in the order of $100 billion or $200 billion or
+even $500 billion dollars, suddenly Bitcoin is the most efficient
+payment network and low-cost currency that has ever been built by man.
+Suddenly it is the most eco-friendly currency on the planet. The carbon
+footprint on a per transaction basis is minuscule. Right now, it's not.
+But the beauty about this is that Bitcoin is two completely independent
+economic systems, with only a single link-- price.
+
+It is an economic system of transactions between its participants. Also,
+it is a giant industrial economy of mining. These two are related in a
+loose and elastic fashion. So for those who don't understand how mining
+works, I will give you a quick analogy to tell you about the concepts.
+Specifically, the concept of difficulty and adaptive difficulty
+algorithms. So people are in a competition and the problem gets more or
+less difficult. For most people, this is hard to understand. The first
+thing you must not say when you introduce Bitcoin to people is that is a
+math-based currency. Well, most people are going to ask if they have to
+solve differential equations to pay for coffee, this is ridiculous, this
+is terrible. Well, I suck at math too, so that would be my reaction.
+
+An easier analogy, ... how many people are familiar with sudoku? Oh,
+that's more people than raised their hand for mining. So, sudoku is
+interesting because it has some strong analogies to mining. It is an
+asymmetric algorithm. Easier to verify than it is to solve. I show you a
+completed sudoku. In a few seconds you can run a quick check to see
+whether it works. I can give you one that is partially full and you can
+say yep obviously incomplete. Guess what happens when I start scaling
+that problem up? I make a 10 row sudoku and turn it into a 100 row
+sudoku. I show you when it is full and completed, you can just take 10
+seconds to confirm, alright that looks good. So the effort you put into
+verification has not dramatically changed. It has gone up linearly. Try
+solving it though. The difficulty of solving that sudoku has increased
+exponentially, it is much harder to solve a 100x100 sudoku.
+
+So we fill this room with sudoku solvers. And I give $100 to the first
+person who solves the sudoku. Just before we start, I put some numbers
+on the screen and say fill these in. The first person to solve it gets
+$100. So as soon as you get it, you raise your hand and I verify it and
+you get $100. Takes you about 10 minutes. People think it is a pretty
+good deal, let me call my friends at the MIT dorms, and bring in my
+buddies and we'll make a pool and bus them all in, and soon we will have
+100 people showing up to solve sudoku. So when the 100 people show up,
+it might take you 8 minutes instead of 10 minutes. But then I'll say,
+hang on, this is not taking long enough. So I will increase the rows and
+columns by 20%, so that it gets harder. So whenever it takes 8 minutes
+instead of 10, we can always add 20% more columns. If it takes a bit
+longer, we make it easier. And if it takes less time, we make it harder.
+
+That's Bitcoin. The numbers you put into the empty sudoku, that's
+Bitcoin transactions. Others can verify this. The numbers being filled
+in tells me that you did some work. There's no way that you just came up
+with those numbers. I know that filling in a sudoku is going to take
+some time. So you proved that you did work. The sudoku itself, a solved
+sudoku, upon presentation implies proof-of-work. It shows that you have
+done the work. As long as the initial input is something that I choose
+or something random.
+
+That's Bitcoin mining. It started off with Satoshi and others doing it
+on their laptops. Today it is rows of machines in China from coal and
+Iceland from geothermal. What this has bought us is world-class security
+for a featherweight currency.
+
+The beauty of this is that the number of miners in the space has nothing
+to do with how much money is on the Bitcoin network. Nor how many
+transactions there are. Only thing that matters is whether it's
+profitable or not to continue mining.
+
+People sometimes say they read that mining will not be profitable when X
+happens. I can tell you that mining will always be profitable. The
+simple feedback loop results in what is known in economics as a perfect
+market. The difficulty calibration fixes the supply according to the
+demand. When supply consistently meets demands and it moves in lockstep,
+participation will only return marginal profits over a long period of
+time for the most efficient operators. It will drive you to highest
+efficiency in a brutally competitive market.
+
+Satoshi didn't just invent a new currency. He gave us the world's first
+perfect market. Which is quite stunning as an achievement. There is no
+other market that has a tight feedback loop on 2016 blocks every 2 weeks
+calibrating supply and adjusting price across a global network that is
+completely decentralized that is supporting an industrial economy at
+3,600 BTC per day. This market grew from nothing to a world-class
+security mechanism in just 5 years.
+
+The next time that somebody says to you "Yeah, I like the blockchain
+technology, but Bitcoin is silly", or "could we do it without mining",
+or "I like mining, but could we do it without electricity?" Understand
+that they don't understand the basic economic principles of the mining
+market. Without reward there is no risk. Without the careful balance
+between risk and reward, there is no security for the blockchain, and
+therefore the blockchain doesn't work in that situation and the currency
+is valueless.
+
+People who tell you that they want the blockchain without Bitcoin are
+people who say "We like the lightbulb, but can you do it without
+electricity? Can't we just do it with kerosene?" Really what they are
+thinking of is a kerosene lamp. We have already done that.
+
+"I really like this automobile, but it sounds like oil purification is a
+big hassle. Could we run it with a horse that eats hay? Because we have
+plenty of that. Yes, but what you're thinking of is the steam locomotive
+and the horse carriage". We already did that. You can't do light bulbs
+without electricity, you can't do automobiles without gasoline, and you
+can't do the blockchain without Bitcoin.
+
+Thank you. I will take, maybe 10 minutes? 9 minutes to take some
+questions. Please ask the question once you have the microphone. We want
+the audience to be able to hear it. Thank you.
+
+Q: Andreas, how are you. Thank you for the talk. It's always great.
+What's the transition, best case, away from fractional reserve banking?
+
+A: What is the transition away from fractional reserve banking? Best
+case scenario? I think people underestimate the other side. Meaning
+that, we're not just trying to make Bitcoin succeed. That's part of the
+equation. But it doesn't exist in a vacuum. There's a context. Over 194
+other national currencies. Here's something you don't see on the news,
+or only rarely. Our generation is currently experiencing a historic
+event that has not happened in the last 3 centuries. A currency war. A
+race to the bottom of absolutely unprecedented scale. Never before in
+the history of currencies have 21 central banks fixed their interest
+banks at zero and kept them there for almost six years. This has never
+happened before. Never before in history has a central bank gone to
+negative interest rates, and then be followed by 6 other central banks.
+Never before has deflation been occurring simultaneously throughout the
+world economy. It is not only about Bitcoin succeeding. There's also the
+collapse of the entire economic system around it collapsing. We are
+watching. This is not flippant or funny. This is what leads to wars,
+violence, strife and ash and ruins in real life. The last time we had a
+currency crisis of this scale, and it wasn't this big, it was in the
+1930s. We know what happened next. We are living in a time where every
+central bank has gone nuts, and everyone is pretending as if nothing to
+see here. Stock market at all time high, and yet huge amounts of
+unemployment. Bonds tanking? Stock market exploding. Currency tanking?
+Stock market exploding. These things are not possible. Rational
+economics tells us that these things do not work. The small question is
+what happens next. The big question is what happens and where do we go
+when the era of central banking dies?
+
+Next question? Who has a microphone?
+
+Q: Your whole premise of the talk is about greed and honesty. As the
+ecosystem develops and there's more financial derivative instruments, do
+you see a possible scenario where a derivative instrument with a 51%
+attack could be used to destroy the system?
+
+A: I think that 51% attacks are overrated as a practical consideration.
+A 51% attack does not give the attacker a good outcome. It takes a lot
+of resources. I think that when you reach the point where you have that
+many resources, well the natural and rational decision is to invest into
+Bitcoin. An attacker who is not motivated by profit, but purely for
+destructive reasons, that will force the system to evolve. Bitcoin is
+decentralized and it is dynamically scalable and can be modified. It is
+software. And it is not easy to modify it because it requires consensus,
+but if it is under attack, then the consensus happens more easily. I am
+very confident that software systems can and do adapt to external
+threats. When they do so, they become stronger over time. We have seen
+this. Bitcoin has suffered setbacks again and again and again, and as
+time goes by, Bitcoin gets stronger, more secure, it gets harder to
+attack it. It is building immunity.
+
+Q: Everything that I see and read in presentations that you give and
+what people in this room are doing with Bitcoin, is true. It is solving
+a lot of problems. Software will solve problems. Technology always
+solves problems. However, we live in a world where even if that is true,
+philosophy or what convinces people of things... something like Bitcoin
+is at the forefront of this giant will of convincing of philosophy, the
+question now is how do we convince those who invest in Bitcoin that it
+has this world-class security? When all we hear about is hacking attacks
+to steal Bitcoin and please don't use the recent incident by the $1
+billion stolen from the Russian and Chinese guys with real cash? It's
+going to get hacked, so you can't use Bitcoin, how do you convince
+people? How do you convince people out of that?
+
+A: I think we don't convince people to use Bitcoin. I think we work
+harder on making Bitcoin more useful instead. The simple truth is that
+if I have to convince an American of the usefulness of Bitcoin, it's an
+uphill struggle. You are 5% of the population, your bank is not stealing
+from you actively, the government is only somewhat inflating your
+currency, and that's the exception. Then there are 193 currencies that
+are far worse, and most people live in a world different from this.
+Bitcoin does not require a hard sell because it solves life and death
+problems for some people in this world. There are 6 billion people who
+do not have access to banking. They have governments that are actively
+stealing from them, and is little different from organized crime. Or
+where the banks are organized crime. The simplest process of securing a
+future for your children is fraught with risk. As you see an entire
+fortune of yours destroyed not once but twice or three times in a single
+generation. In these places, in the places where the only form of
+technology available is a Nokia 1000 feature phone, where the nearest
+bank is 100 miles upstream by canoe, and where banking services will
+never reach-- we have the opportunity to bring 6 billion people into a
+global economy that they have been excluded from because of politics,
+cost and efficiency. We have engineered a technological leap-frog event,
+just like cell phones leapfrogged landlines in Southeast Asia. Every
+single one of those cell phones can become a stock exchange terminal, a
+mortgage origination terminal, a microloan terminal. Every phone becomes
+a banking service. If you bring that to the world, they don't need
+convincing.
+
+Q: Sounds like you were claiming that the current mining security is
+enough to sustain a much larger ... wont more miners scale up their
+operations to claim the reward?
+
+A: If the economy grows, then it depends- the only dependence is on
+whether the Bitcoin price encourages speculation. The mining industry in
+terms of say 2014 out, and what we looked at from 2008 to 2014, is that
+in the first period we are looking at order of magnitude improvements
+going from CPU mining to GPU mining to FPGAs to ASICs. You are looking
+at 100x plus improvements generation on generation of chips. That
+evolution has now run smack into Moore's law and is at the cutting edge
+of Moore's law at 28 nanometers or below. There is no 100x improvement
+available at the moment. Bitcoin mining is driving chip fabrication
+faster than desktop CPUs, which is incredible to even think about it. It
+may be the first technology that goes below 14 nanometers even before
+GPUs. We may not see 100x improvements. You cannot outpace the
+competition because the next generation has not yet been invented. So
+now mining has to be hyper-efficient in terms of operating costs,
+electricity price, thermal efficiency, electrical efficiency. That's
+where we will see improvements. There is no 100x increase possible in
+the next generation, I predict that we are going to see mining
+technologies surpass the current state of the art in data centers, and
+instead start to become the state of the art level of nuclear reactors.
+You are not looking at a 10 kW air-cooled rack in a data center, but
+rather a 100 kW submerged in mineral oil in a cooling bath which is
+really nuclear reactor technology, and that's where you see the next
+generation of efficiency. The mining industry cannot scale 100x because
+of physics, but the economy will scale a lot more than that.
+
+Out of time. Thank you so much everyone.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/eric-martindale.md b/__transcripts__/mit-bitcoin-expo-2015/eric-martindale.md
new file mode 100644
index 0000000..595ed97
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/eric-martindale.md
@@ -0,0 +1,251 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Eric Martindale
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Open source: Beyond Bitcoin
+Core
+
+Eric Martindale
+
+He is at Bitpay, working on copay, bitcore, foxtrot, and their
+blockchain explorer.
+
+First of all, a little bit about Bitpay. We were actually founded in
+May 2011. We have been around for some time. At the time, MtGox was
+actually still a viable exchange. The Bitcoin price was down at about $1
+or a little more. And we had a grand total of two merchants.
+
+So what Bitpay does is that it accepts Bitcoin on behalf of a merchant
+and allows them to transform that into a fiat currency. We drop into
+point of sale terminals. You let your consumers pay in Bitcoin.
+
+Today it is March, 2015. We are four years into this now. The Bitcoin
+price is a little bit more. You may have seen the meteoric rise. We have
+over 60,000 merchants accepting Bitcoin around the world. This is a big
+improvement. This is really meaningful at Bitpay those of us who accept
+our salary in Bitcoin. Still can't pay rent in Bitcoin though, which
+upsets me.
+
+So now around the world, and this isn't just Bitpay. There are over 100k
+merchants that accept Bitcoin. Bitpay itself is growing a little under
+1000/week right now. It fluctuates based on the news. We see a spike in
+merchant adoption when there are interesting events hitting the press,
+like exchanges getting approved by the Federal Trade Commission.
+
+What's next for us? We thought long and hard about this very early on.
+Bitcoin itself sort of disintermediates payment processing. It makes
+money simple. It tries to make sure there's no third party. So we had to
+think broadly about this.
+
+Our answer of course, and tihs is one of our engineering mottos is that
+we should decentralize all the things. There is a cost with
+decentralization that needs to be taken into account. If you look at
+this from an engineering perspective, any time you have a single point
+of failure, the system will eventually fail. If anything bad can happen,
+it will happen and in the worst way. So decentralization presents a good
+mechanism for eliminating these single points of failure.
+
+So I am going to diverge a little bit and talk about what open-source is
+and talk about why it is important. Closed system are very, security
+through obscurity is never a good decision. Hiding how you do things is
+probably not the best answer. If you have an open-source solution, there
+are more eyeballs on the code and I will talk about this in a minute.
+
+Richard Stallman is the guy who gave the name to the open-source
+movement which started prior to him, I grant. But he's responsible for
+the Free Software Foundation. It goes back to the early days of
+mainframe computers and the IBM conglomerate that got broken up by the
+government. This academic research and institutions like MIT, in roder
+to get their machines to actually work, people were sharing code because
+the machines were all different. This made it impossible to get anything
+to run, you would spend a lot of time getting your programs to run.
+
+So the open source culture was alive and well in the late 60s and into
+the 70s because it was actually essential. This changed with the advent
+of personal computing and the availability of computers to the business
+worl. They wanted to protect software as intellectual property.
+
+Eric Raymond has a great quote whic his, "Given enough eyeballs, all
+bugs are shallow." So it is less likely for your code to have a severe
+security problem if it is reviewed by say the Bitcoin core developers
+and the global community of engineers who have different experience than
+the engineers you have on your project.
+
+We think that open-source systems are a requirement. The guy who created
+Twitter Bootstrap, he wrote something called "What is open-source and
+why do I feel so guilty?"
+
+After giving some thought into this, we realized we were more than a
+services company. What Bitcoin needs is a robust infrastructure. It
+cannot be built by just one company. It must be spread out. Bitcoin
+intends to be decentralized. We felt that our best interest would be to
+provide tools and services and utilities that could be used for other
+entrepreneurs to build the solutions that frnaly in the industry you
+don't have enough ohurs in the day to go build everything.
+
+So as we did that, our first starting place was building Bitcore, a
+javascript library that implements all of the functions that Bitcoin
+Core implements. Javascript is perhaps the most widely used in the world
+today. You look at the github statistics and it has achieved meteoric
+rise just like Bitcoin has. It operates thanks to node a couple years
+ago, which allows you to run JS on the server side.
+
+We built Bitcore. It's secure and Javascript library. It needs to be
+modular. All of the things that I am about to talk about, they need to
+do things a lot more than just what Bitcoin Core does. It's private
+keys, public keys, your basics. It gots much more than that. I encourage
+you to check out and there's documentation that
+decribes basic transaction rules, script validation rules, and there's
+even an online playground. There's an entire playground where you can
+literally click buttons right there in your browsers.
+
+One of the first things we recognized as we were looking at our larger
+obectives is that network is really hard. The fact that we have an
+unencrypted internet presents a wide array of problems. The fact that
+someone can inspect the traffic grants them the ability to distinguish
+between...
+
+So we built foxtrot, and it takes some of the lessons we learned from
+Bitcoin and apply to the networking realm. Vin Cerf did a great job with
+TCP. But our job is to replace TCP/IP so that at the link level, the
+lowest levle of networking infrastructure that we can be sure that
+traffic is completely encrypted. It is a secure routing network. It sits
+on top of TCP/IP right now. It is open-source. It uses the same
+cryptography (libsecp256k1 curve). The debate about the vulnerabilities
+o the R1 key are well known at this point I thikn.
+
+We use hashes of public keys as the destinations for routing. It is not
+IP addresses. IP addresses are pre-allocated. There is an institution
+that controls the assignment of these numbers. This is not healthy,
+that's a single point of failure. We are laready out of ipv4 numbers. We
+wanted to get rid of the centralization there. So we wnet with hashes of
+public keys.
+
+Again this is all open-source on github. This is largely pseudocode.
+It's very simple javascript. You require an instance of foxtrot, you
+require the class and create an instance. It's an event emitter, so you
+can subscribe to various events. We have a direct usage for this. We
+want to be able to send messages for a very encrypted way to the
+recipient without having to know anything about the routing network. We
+do not have to maintain a routing table. We connect to a TCP server that
+does our bootstrapping for us (we will tackle that later). Then it
+broadcasts the encrypted message, client.write whatever our data might
+be, and then the peer that we're connected to.
+
+Networking is really interesting for a number of ways. Not only are we
+passionate about decentralization, this photo is from a project in
+Africa where they don't have the large telecoms or the whole boon of the
+internet and the academic institutions that helped lay the groundwork.
+So they have to build their own networks. They have to figure out how to
+lay these networks so that people can gain access to the wealth of
+knowledge frm the internet. You'll notice this is a coffee can, they are
+doing p2p wireless mesh networking. "Building a rural wifi network.."
+mesh network..
+
+Mesh networks are really interesting because if you combine them with a
+payment channel, a type of smart contract which allows a high volume
+very small value transaction to be bundled up into only one instance on
+the blockchain. Some use locktime, multisig, some include one
+transaction some include three. You arrange a pre-deposit of some sort,
+and as you start using that connection or the wifi network or even a
+physical netwrk, you can pay the node you are connected to for routing
+your traffic. He can choose his rate based on the demand, the supply and
+demand, how much bandwidth does he have, does he have the capability to
+rooute this? There are a number of projects in the mesh network. Many of
+them have talked about itnegrating Bitcoin. Our play is foxtrot.
+
+There is cjdns, which I think has the largest rollouts of a mesh
+network. They have hypergloria. They have a more modern project, they
+wanted to solve centralized DNS, they replaced the internet but not
+solving DNS. Then there's freenet and maidsafe. And then what's
+interesting here is that the gateway providers for everything, including
+using Bitcoin as a currency, is reliant on the ISPs. That makes things
+difficult as we saw with the recent net neutrality debate. We will see
+if that has a positive impact on the existing internet.
+
+One of the applications of the Bitcoin blockchain is using it for
+databases. Recently the debate has been about blockchain bloat, about
+OP_RETURN, because th blockchain is already pretty big. Gavin gave a
+good talk earlier about pruning. Matt's talk is fantastic, there's
+another way to do this which is through sidechains. Today we are excited
+to talk about chaindb, a new project by Bitpay, which is a type of
+sidechain that allows us to build arbitrary database types on top of
+Bitcoin without storing significant data on the blockchain itself.
+
+You can construct a key-value store from chaindb, you can construct a
+document store or even a traditional rdbms. You can define the custom
+transaction rules. So in key-value stores you may have a get/set. Or in
+a redis architecture you may have a push or pop. You can define what a
+transaction is.
+
+It is secured by the Bitcoin blockchain. You start talking about
+sidechains or altcoins, is it really altchains? Well they are vulnerable
+because they are using proof of work, and if you have less network
+effect then you are very vulnerable to an actor that can come in and
+assign hashing power.
+
+What does a blockchain provide and why is this interesting? It is a
+distributed system. It has a tamper-resistant history ((sort of)). As
+long as we have a genesis block, we have the ability to go back and
+rewind and replay. It offers consistency. This is what that looks like.
+The way we do this is through proof-of-fee. Proof-of-fee rathe rthan
+rpoof-of-work on this sidechain, proof-of-fee allows conflict resolution
+to take place by what is the highest chain up to this point. So if you
+have two chains of the same height, then you calculate the value of the
+fees to peg it to the Bitcoin blockchain. This pegging works with
+OP_TRUE, whic his an anyonecanspend transaction. In a 1-for-1
+relationship to the Bitcoin blockchain, that this is the current tip of
+this sidechain. Since it's ANYONECANSPEND, anyone miner can pick up that
+transaction. W ecan embed something in OP_RETURN that is the current
+state of the chain. The peers will continue to monitor the Bitcoin
+blockchain and find out what the tip is. So the chaindb will monitor. so
+you embed that in the Bitcoin blockchain.
+
+That allows us to calculate the best chain, not specifically based on
+blockheight, but based on weighted towards older blocks. In order to
+rewrite history you have to spend more time the further back it goes,
+you have to spend more money.
+
+So some of the applications: key-value stores, document stores,
+proof-of-existence, document stores say you want to take a RDBMS and peg
+it to the blockchain, you could do that today by writing a transaction
+rule set with chaindb. Longer-term applications are pretty clear, we
+look at smart contracts, deeds, equity, title, and we can track these in
+a tamper-proof ways.
+
+There was something in the news about someone that was accepting bribes
+to delete titles to houses so that people wouldn't have to pay taxes.
+That's not possible here. We can reliably say that even if our system
+becomes compromised, we have a provable chain that says this was the
+series of events, which is exciting for us.
+
+There is another realm here, storage. Storage is not quite a database.
+It's more like dropbox, which is extremely expensive. There's ipfs,
+storj, maidsafe, I would encourage you to ....
+
+Computing, we covered enough on this. Look at the ethereum stuff. Smart
+contracts. Bitcoin 2.0 is a misnomer. I want to continue to work on
+Bitcoin, we can submit 1.1 once we're ready. There's no reason to be
+talking about a different version or a completely different version.
+Incremental improvement still works.
+
+What did we build with it? There's one clear answer, and that's copay
+right now. We call it the wallet for everyone. It's our place where we
+decided to build an open-source decentralized wallet where you do not
+have to depend on a service. It uses a sort of, it uses foxtrot, it uses
+these protocols for decentralizing how we do private key management. It
+is asynchronous transaction proposals. Not all of your signers have to
+be online at the same time.
+
+We have broken this out into bitcore. All of the functionality that
+copay provides is available in isolated modules. You can drop it into
+any existing product. We hope this will seed the development of more
+multisig or threshold in the future.
+
+That's what I got. Do we have time for questions? We are out of time.
+Sorry about that.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/human-side-trust-workshop.md b/__transcripts__/mit-bitcoin-expo-2015/human-side-trust-workshop.md
new file mode 100644
index 0000000..9f1613c
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/human-side-trust-workshop.md
@@ -0,0 +1,34 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Human Side Trust Workshop
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Human side of trust
+
+- Matt Weiss
+- Joe Gerber
+
+We would like to start with a brief activity. In you rprograms, this
+says design workshop. If that scares you, then we will not be doing
+trust falls. We will not be forming teams. But we would like to start
+with an activity. Identify someone around you who you do not know. Keep
+a mental image of that person in your mind.
+
+Would you trust this person to save your seat? Would you trust them to
+watch your laptop if you went to get lunch? Would you loan them $15 to
+grab lunch? In cash? Would you give them your credit card to swipe?
+Would you trust them to repair the elevator in this building? Would you
+trust them to keep your deepest darkest secret? Would you trust them
+with your private key?
+
+yes, no, yes, yes, no, yes, yes, only already insecure private keys
+
+Trust is important. My name is Matt. This is Joe. We are designers at
+Ideo. We love deep human constructs that are both rational and emotional
+like trust. We can say whatever we want about trust.
+
+oh...
diff --git a/__transcripts__/mit-bitcoin-expo-2015/internet-of-value.md b/__transcripts__/mit-bitcoin-expo-2015/internet-of-value.md
new file mode 100644
index 0000000..4f53361
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/internet-of-value.md
@@ -0,0 +1,95 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Internet Of Value
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Jeremy Allaire
+
+What are the lessons from the development of the internet that we can
+learn from? Why is there an inevitability as to what Bitcoin is doing?
+
+At a high level, I like to explain that we are experiencing a
+fundamental transformation in how the world economy stores and verifies
+value. Bitcoin and these other projects that are being built are part of
+that arc. We have talked not just about payments. It's about how
+ownership and fidicuiary trust in general can be managed. And
+development of standards of how entities interact in this digitzed world
+of fidicuiary trust.
+
+The impact of this technology disruption and derivative work and work on
+Bitcoin itself will have a huge impact not just on finance. We focus a
+lot on finance. But also a huge impact on accounting, commercial law,
+civil law, property rights, insurance, and any intermediary industry
+built on the basis of disconnected ledgers. And human processes for
+verifying analog information. All of these fidicuiary trust institutions
+will be impacted.
+
+The first use case that people have been focusing on is payments. I
+think there are others. I think we are in a similar place. This is an
+analogy that lots and lots of people use. We are in kind of that birth
+of the digital web phase of digital currency. We are seeing a similar
+scale of venture capital and enthusiasm from early adopters. Nobody
+knows what the big transformation will be.
+
+What people may not remember is that in 1994 there were like 4,000
+websites. It was completely insecure. The standards were immature. Using
+HTTP and HTML were really a joke. You could do almost nothing with them.
+There was a deep amount of skepticism from entrenched government,
+private and commercial interests. We will come back to that both
+historically but also the skepticism we see today around Bitcoin.
+
+Bitcoin today is not useful for an average person. It is confusing. It
+is complicated. It is enormously challenging to use today. The web in
+1994 you could do little with. We saw that we could do more if we
+improve the architecture.
+
+What happened over the next 20 years we kind of know, we had the
+wholesle transformation in commerce and media built on open protocols.
+That work that it took, the technical work and the associated capital
+investments in software and improving protocols and capital expenses
+took many years to unfold. The $500 million in venture capital for
+Bitcoin should become billions of dollars of associated infrastructure.
+That might take 5 years until we start to see a single digit impact on
+the financial system. Online commerce is only 5% of retail sales today.
+TV is 96% of viewing hours even though it feels like youtube has had a
+huge impact.
+
+What is it about the technologies and protocols that enabled these
+transformations? How can we learn from that with what is happening with
+Bitcoin?
+
+I think the internet itself has encoded into its architecture a set of
+ideals. These ideals are what makes so many of things that we take for
+granted, work. The internet id distributed and decentralized originally
+conceived by the Defense Department, so that there was no single point
+of failure. That distributed architecture allows for scaling. Anyone can
+join. The internet has no.. there is no company that can say no. If you
+have a piece of software that speaks IP, you can get on the internet.
+You don't have to ask permission. That is deeply democritizing.
+
+This is always surprising to people when I say this. Nobody runs hte
+internet. Young people find that hard to believe. Older people don't
+understand that the internet is not governed by a company or any
+corporation or any specific government. It's a consensus-based
+environment that evolves with technical standards and protocols.
+
+There are nuances to this. Simplistically speaking, it is not governed
+by anyone. A payment system not governed by anyone is also hard for
+people to understand. Modern society runs on infrastructure that nobody
+controls (the internet). So they are able to get their heads around
+this.
+
+Fundamentally this architecture happens because there are public
+specifications, informal and formal standards bodies, there are open
+source projects where there is this enormous public good that everyone
+can take advantage of. These are really core ideas, if we didn't have
+open source we would not have the internet that we know of today.
+
+All of these ideals play themselves out. There are companies behind some
+of the efforts. It's not koombiyah free culture driving everything.
+There are companies at the foundation of what gives Bitcoin to be the
+opportunity to be the HTTP of value transfer.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/keynote-gavin-andresen.md b/__transcripts__/mit-bitcoin-expo-2015/keynote-gavin-andresen.md
new file mode 100644
index 0000000..8f55c74
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/keynote-gavin-andresen.md
@@ -0,0 +1,431 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Keynote Gavin Andresen
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Gavin Andresen
+
+His fame precedes him. He's going to talk about chain sizes and all
+that.
+
+Cool, I'll have to follow you guys. Thank you, it's great to be here. I
+was here last time and had a great time. I'm really happy that it's not
+snowing because we've had too much snow. I'm also happy that you all
+decided to listen to me on a Sunday morning. I don't usually give talks
+on Sunday.
+
+A couple years ago I was talking to a friend about Bitcoin. "You know
+Gavin, I don't think you're leading an open source software project, I
+think you're leading a religion."
+
+A tenth of a Bitcoin for anyone who takes the livestream and puts a pope
+hat on me during the stream. That would be awesome.
+
+I want to talk about the zen of Bitcoin. What are the principles of
+Bitcoin that we need to uphold as we take the project forward? I think
+there are a bunch of them. Here are four that I think about a lot.
+
+1. It is open. The software is open. Anyone in the world can participate
+ in the software.
+
+2. The network is open. Anyone in the world who has a computer and an
+ internet connection can start participating, receiving transactions
+ and sending transactions.
+
+3. It is decentralized. There are no single points of control or
+ failure. We get this almost entirely right. There's actually kind of
+ one little worrying central point of control which is the way you
+ bootstrap yourself into the network. If anyone has a good idea about
+ bootstrapping in a decentralized ways, patches welcome.
+
+4. There are no privileged nodes. Every peer is like all nodes. We have
+ SPV nodes that do not do validation, but if you are a full node on
+ the network you are as privileged as the other nodes.
+
+It's honest. Everyone knows the rules. Everyone knows there will only
+ever be 21 million Bitcoin created. That's part of the zen of Bitcoin.
+
+As we think about scaling up and potential changes, it's important to
+keep these things in mind.
+
+I think there are controversies about scaling up because different
+people have different ideas about what Bitcoin is for. Some people think
+of it as a replacement for banks because they don't trust fiat. Nobody
+will ever be able to pry the brainwallet passphrase out of my hand.
+
+Some want to buy goods and services with Bitcoin. Recently there have
+been people that want to use Bitcoin as this secure way of recording on
+a global ledger about some fact that can't be repudiated.
+
+I think these are all great uses of the blockchain. I think the
+consensus is that these are all great and should all happen. As we scale
+up I think we need to think of all of them.
+
+So why do we need to scale up? We will eventually have a problem. Right
+now we have like 1 or 1.2 transactions per second. With our current one
+megabyte blocks there is an arbitrary limit of 1 megabyte and you can
+get to about 3 transactions per second.
+
+You hear 7 transactions per second a lot. That's maybe 500 bytes per
+transaction, so it's maybe more like 3 transactions per second which is
+not enough. I mean, if we actually hit that limit and I think we might
+hit that limit in 12 months or 18 months maybe sooner if Bitcoin really
+takes off. Um.
+
+What will happen? The economics are pretty clear as to what will happen.
+Average transaction fees will have to rise. People will compete to get
+their transactions into these blocks. This has already happened
+actually.
+
+We had gambling sites like SatoshiDice that at one point were 50% of
+Bitcoin transaction volume. We made some tweaks to make it more
+expensive for SatoshiDice to operate the way it was operating. If you
+increase the price of something, then people will buy less of it. So we
+increased the price, we increased the dust limit, they responded by
+increasing the minimum size of the bet. Their customers responded by
+making fewer larger bets. That's the economically rational thing that
+you would expect to happen. You increase the price of something, people
+buy less of it.
+
+That in general will happen for all Bitcoin transactions. I don't think
+that transaction fees rising is a problem. I would love if people would
+pay 1000th of a penny per transaction if the network would support it.
+But if transaction fees rise, that's okay. You will be paying 20 cents
+per transaction instead of 10 cents, or whatever the average is these
+days.
+
+What does worry me is the number of unconfirmed transactions will rise,
+the number of transactions that do not get into a block. I don't want
+Bitcoin to get a reputation for being a flakey payment network. That
+would be bad.
+
+I want lots and lots of people to use Bitcoin. I want everyone in the
+world to use Bitcoin. I don't want usage to decline. If you talk to
+anyone in high tech, who has some startup, startups are encouraged to
+get big fast. Get lots of customers. Don't worry about anything else.
+Don't worry even about how you are going to make money eventually. Get
+big fast. That's the way to success.
+
+Maybe I am biased. I have been an entrepreneur in the past. I think that
+getting big fast makes a lot of sense. We should pursue that path.
+
+There's this argument that higher transaction fees are good for miners.
+People are worried that as the block reward goes down that the
+transaction fees are supposed to take the place of that miner revenue to
+keep the network secure. I've never understood that because miner
+revenue from fees is the average fee times the number of transactions
+times the exchange rate. If you increase the average fee by limiting the
+number of transactions and that hurts the exchange rate then that's bad
+for miners. Talk to an economist and they will say they don't know how
+the elasticity of demand will be, and maybe people will be willing to
+pay higher fees and you wont drive away people. I agree that's an open
+question. I think we should err on the side of getting big fast, more
+usage. Try to make Bitcoin as successful as soon as possible.
+
+Then I hear, "But, but, we can use off-chain transactions that do not
+hit the blockchain to scale up. We don't need to change the blocksize."
+If you imagine Bitcoin just as a store of value, the Bitcoin blockchain
+will only be the store of value and then you will transfer some other
+value for your day-to-day exchanges using sidechains or treechains or
+some other solution. If there's just one real Bitcoin transaction per
+person per year, and we have 1 billion people using Bitcoin, you do the
+math and that's 32 transactions per second. 3 transactions per second
+will not cut it, even if Bitcoin is only used as a store of value. We
+have to scale up, we have to make the blockchain bigger.
+
+There are not enough seconds in the year (23 million per year). That's
+not that many when you think about 100s of millions of people using
+Bitcoin.
+
+The other thing I don't like about these off-chain solutions is that
+they don't really fit into the zen of Bitcoin. We want it to be flat. We
+don't want privileged peers. We don't want there to be some gatekeeper
+or some other blockchain that you know, that that some people are
+participating but others aren't. The whole point of Bitcoin is a
+completely decentralized p2p network.
+
+Is scaling a big deal? I actually think it's not. Satoshi didn't think
+so either. This is I think Satoshi's second ever public communication.
+This was on the cryptography mailing list in 2008 I believe. He was
+talking about Visa processing billions of transactions. "By then,
+sending 2 HD movies over the Internet would probably not seem like a big
+deal."
+
+He was talking about a block being as big as 2 HD movies. I stream a
+couple HD movies pretty much every Saturday to my house because my kids
+love watching movies. And it really isn't a big deal.
+
+There's a bunch of low hanging fruit that we could pick that I think
+could get us a long ways towards where we need to be. Let me talk about
+a little bit about this fruit. Peter may be talking about this later.
+
+"It takes forever to download the blockchain". Try the new 0.10 release.
+It should download the blockchain in hours instead of days. Hours is
+still a long time, but it's much better than days. Soon we should get
+pruning, there's a pull request pending for the next release of Bitcoin
+Core that implements pruning of old transactions. You will not need to
+store the entire blockchain, only what you need to validate new
+transactions.
+
+And what are called utxo commitments. To validate new transactions in
+blocks, you have to know which transactions have not been spent yet. You
+need to know some recent history. As long as we don't have blockchain
+reorgs that go back 2 years. The idea behind utxo commitments is that
+you would ask a peer for the summary of utxos, because I don't want to
+recreate it by downloading the entire blockchain. You could be a fully
+validating node very quickly. The trick is how could you trust that the
+person told you the right information? They might lie to you. And that's
+where the commitment goes to. We would commit some sort of hash into the
+blockchain, where the hash of the unspent utxos are this. There have
+been some proposals but no consensus yet. There are tradeoffs, like how
+long does it take miners to compute this, versus how stable is it. I am
+hoping that we will come to consensus and we will get that. It would be
+fantastic to start a full node and be up in 10 minutes rather than 10
+hours.
+
+I don't think that's that big of a deal. I think we would survive even
+if it continues to take 10 hours to get up and running as a full node.
+We have so far, and it's sort of a nice to have feature in my view.
+
+There's low hanging fruit in optimizing the protocol. Every piece of
+transaction data is sent twice over the network. First as a relayed
+transaction for a miner to mine. Then it is transmitted again as part of
+a block. When a miner makes a block, they send all transactions. That's
+2x the bandwidth we need to use. Bigger blocks are slower blocks. A
+block with more transactions in it takes longer to propagate across the
+network. This is bad because it creates an incentive for smaller blocks,
+or it may create centralization of mining because big miners on a super
+fast centralized network, they might have an advantage over other miners
+on slower connections, or even Australia which has pretty bad internet
+connectivity.
+
+So the easiest solution here from gmaxwell and TheBlueMatt is to
+transmit the block header which is 80 bytes. And then txids. So just
+summarize the transactions using short IDs. You can make them pretty
+darn short. Just a few bytes per transaction. The result is you get new
+block announcements that are up to 100 times smaller. Instead of
+transmitting a block that is a megabyte, you are transmitting a block
+that is 10 kilobytes. The 80 byte blockheader plus 10k of tiny little
+txids. That's great. We need to get that into the core protocol. Just
+doing this would speed up the network part of block propagation by a
+couple orders of magnitude. This is obvious low hanging fruit and easy.
+
+Validation is interesting, right? Because if you think, if I am
+propagating blocks across the network you have to send it. You have to
+validate the block and make sure the transactions are valid. That takes
+some time. Last week I sent out this tweet today was a productive coding
+day, 1 new unit test, 41 fewer lines of code. That was a really good day
+for me. It was even better than that, and I screwed up it was using 60x
+less memory not just 10x memory. I was counting bits as bytes.
+
+Um. We can optimize the CPU work. Right? I am in the middle of this pull
+request, there's some more work to be done, it will turn out to be more
+lines of code because I need to write a new unit test. Hand wave hand
+wave. But we should be able to validate and relay a 60 megabyte block in
+less time and memory than we are validating and relaying a one megabyte
+block today. We should be able to get again approximately 2 orders of
+magnitude just by getting the low hanging fruit. We haven't looked yet.
+
+10 minutes is a long time. How did I get that 60x speedup? I took
+advantage of the fact that we had done all of the transaction validation
+work when we got the transactions the first time. You get the 100x
+speedup by relying on the transactions having been sent in full in the
+proceeding 10 minutes. We can get a factor of 60 to 100 just by taking
+advantage of the fact that we can do work during those 10 minutes before
+the block is found.
+
+10 minutes, a typical home broadband connection can upload 800
+megabytes. A home computer can validate about 800,000 transactions, over
+1k transactions per second. This tells me that network and CPU shouldn't
+be a problem. We should be able to scale up.
+
+This graph shows the growth in household broadband bandwidth. At one
+year ago we were at 8 megabytes, maybe that's megabits per second. Yes,
+that's megabits per second. Today globally it's about 10 megabits per
+second. The United States is way down on the list. They are like #40 in
+the world. We are way behind. It would be interesting to see if net
+neutrality changes recently will have a positive or negative effect on
+that. It will be interesting to watch. If it has a positive effect, a
+bunch of libertarians are going to be really upset I think.
+
+So that's the low hanging fruit that I think we can pick to get a few
+orders of magnitude scaling. Then there's the fun stuff.
+
+libsecp256k1 to get faster ECDSA validation. I should have said that's
+low hanging fruit, it's basically done just going through extensive
+testing. That gets 6x transaction validation.
+
+Schnorr signatures is on my medium-term wishlist. If Satoshi had known
+more about cryptography and realized that the Schnorr patent expired in
+2009 or 2010 that he may have gone for Schnorr signatures. That gives us
+multisig transactions in the same space as single signature
+transactions. That's a huge win.
+
+I've been thinking about the area of computer science that figures out
+given two databases that has mostly the same information how can you
+efficiently reconcile that information so that they both have the same
+information. That's what we want to do with Bitcoin transactions. We
+want all nodes on the network to know which transactions have been sent.
+We should be able to do transaction set reconciliation techniques.
+
+Then there's even more stuff like, there's an idea kicking around of
+doing probabilistic validation where instead of validating everything,
+they only validate one in ten randomly and get a 10x speedup. If any
+that aren't valid, I'll broadcast a sort of fraud proof that someone
+created a block with an invalid transaction in it. That's possible. It
+may be risky, I don't think it is. It's interesting to think about.
+Could give you infinite scaling if you think CPU might be a problem.
+
+So why don't we just do it already? Well, change is hard. We are
+conservative on the core dev team. We think about things for months
+before we decide that something is a good or bad idea. Sometimes years.
+Just changing anything is very hard. We are very careful. We're aware of
+how much money is sitting on this code.
+
+Consensus is even harder. It's really hard to convince people that this
+is exactly the right idea. That this is exactly what should happen.
+Right now working on just getting consensus among the five what I call
+core developers, the ones with push access to the github repository. I
+think I am close to convincing them that we have a plan that will work.
+I am going to have to write some more code and write some more
+benchmarks and have things ready to go before I completely convince them
+that this is the way to go.
+
+I am going to keep pushing and again I think we have a year to 18
+months. I would love the next release of Bitcoin Core, the next major
+release which will be in the June timeframe, to have a scheduled
+hardfork to increase the block size. It will probably be in a release
+after that though. We'll see.
+
+Those are my thoughts about scaling. Um. I think we have some time for
+questions. Thanks.
+
+A: Data of brand new blocks gets changed all the time. Every day we have
+a blockchain fork that is like one block long because some people have
+created competing blocks.
+
+Q: How much of that data can be changed from outside? How can me and you
+change the blockchain?
+
+A: We add to the blockchain by .. You cannot change the historical
+blockchain. With some caveats. You can talk with Andrew Miller if you
+really want to.
+
+Q: Thanks for being here. So, early on in your presentation you made
+mention of how you made some changes in order to keep the gambling site
+from .. so, the company I am representing, we're working with a central
+bank in a country in the world to get a license to use Bitcoin in that
+country. One of their concerns is who controls Bitcoin. What you just
+said is a fundamental, I don't know what the word is, but you're
+basically saying that you're in control.
+
+A: I said we were in control.
+
+Q: You and the 5 developers. I'm not against anything, there's no bad
+stuff going on here, but they want to know who is in control. And when
+you say things like "we made that change", who's in control.
+
+A: The answer is that everybody. It's the miners. It's the developers.
+It's the exchanges. It's anyone who decides to run a new version of the
+software. We made the change. I may have actually implemented the code.
+I submitted it. It got reviewed. It got pulled into the tree. We spun a
+release. That didn't change anything at that point. It took people
+downloading and running the new code for that to change. The entire
+Bitcoin community decided that this was the right thing.
+
+Q: So.. I was kind of hoping you would say that because this was in the
+past. When I, we are in an ongoing process. I made a reference like
+that.
+
+A: One thing you could tell them.. You could look at my history of what
+I have changed, there have been changes that I want to make, and it has
+been rejected.
+
+Q: What I told them in a paper is that these core developers may be
+making changes, but we have to accept the changes. And that's how it
+will alway be?
+
+A: That's the plan.
+
+Q: Follow-up. Could you speak to the process of consensus is? What's the
+process for making major changes?
+
+A: The typical process is that someone thinks they have a great idea.
+All of my ideas are great of course. Ideally you discuss it first on the
+mailing list or the #bitcoin-dev IRC channel. You write some code that
+implements it, you show that it works in practice. If it is a consensus
+change, you probably simultaneously create a pull request to get that
+code into the Core code and then you write a BIP, a Bitcoin Improvement
+Proposal. BIP is our standards process. That's how we argue about
+changing the consensus protocol.
+
+Q: And then the five people have a final say?
+
+A: it's everyone that wants to weigh in and scream and protest and
+suggest alternative ways of going. It's a messy chaotic process that
+eventually reaches consensus.
+
+Q: Is it voting?
+
+A: No, it does not come down to a vote. Yes, the five core developers
+agree that this should happen in the Core Reference Client. Or at least
+that none of them viscerally disagree....
+
+Q: I am interested in what was described in the paper that was mentioned
+yesterday (amiller's). In March 2013, I think there was an upgrade and
+then a lot of perhaps the miners did not upgrade. Could you explain a
+little bit about how the upgrade is propagated through the system to
+prevent something like that happening again?
+
+A: So the chain fork in March 2013 was triggered by an upgrade. That
+would have happened sooner or later even if nobody had upgraded. That
+particular bug, and it was a bug, it would cause two computers running
+the same older code to disagree about what the valid blockchain was. Two
+computers running different code kind of exposed the bug quicker.
+Rolling out a new change to the consensus code, or not even a change to
+the consensus code... openssl "upgraded" their code and anyone running
+Bitcoin Core that was linked dynamically against the openssl library got
+forked off the network because openssl changed the rules about what
+signatures they considered valid. We do everything we can to avoid that
+if you use one of the reference implementations binaries. We statically
+link against openssl because we want to nail down everything so that we
+don't have a chain forking incident like that. Will we never have one
+again? I can't guarantee that. That's definitely something we think
+about. This is another reason why this is hard.
+
+Q: We are just past the 1 year anniversary from the transaction
+malleability WTF day. I have noticed some work, maybe bip63 or one of
+those bips by Peter Voll. bip62. To address the twenty or so known edge
+cases that can lead to transaction malleability. Do you think it can
+ever be completely eradicated? And two, do you think there's any
+specific timeframe or do you have some timeframe for incorporating
+bip62?
+
+A: We are think, I think sipa said yesterday that 3% of miners are
+producing bip62. Bip66. 66. I can't keep the BIP numbers straight. Yes,
+the malleability BIP. The malleability fixes, we are in the middle of a
+soft fork right now and I think we are at 3% of miners are producing
+upversioned blocks. When that gets to 75%, it kind of switches over and
+you can start to rely on... no blocks that have these forms of
+malleability. I am actually pretty optimistic that in a restricted
+subset in our scripting system, that it will be immalleable. I think
+that we have found all the edge cases for that restricted subset. 90%
+confident of that. I am pretty optimistic that once miners roll out the
+block version that.. If you need something that has immalleable
+transactions, you will be able to construct transactions that are not
+malleable.
+
+Q: So for libsecp256k1, does that tighten up ECDSA signature and
+validation rules for malleability?
+
+A: Um, we had to do the soft fork before switching to the new libraries.
+Just because openssl is so vague and interesting. I don't want to trash
+other open source software developers. I know how hard it is. We had to
+do the soft fork first. That will give us more confidence. We really
+deeply understand libsecp256k1.
+
+Thanks a lot I will be around all day.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/keynote.md b/__transcripts__/mit-bitcoin-expo-2015/keynote.md
new file mode 100644
index 0000000..b24e65f
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/keynote.md
@@ -0,0 +1,313 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Keynote
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Charlie Lee
+
+It has been a while since I have been back to MIT. So. So um. Yeah,
+it's. I got extremely excited that the expo is at 26100. This was one of
+my favorite classrooms. Almost 20 years ago, I took 1802 with Professor
+Rogers. Yeah. I hope I am not as boring as he was back then.
+
+Another thing I remember about this classroom is that we watched a lot
+of LS movies. Does LCE still suck? Um, yeah. I definitely did not expect
+back then to come back and give a talk. So I am extremely honored.
+
+I graduated in 1999-2000 with a bachelors in computer science. I went to
+Silicon Valley. I worked at Google for 6 years on projects like youtube,
+chrome OS, google play games, and back in 2011 I found out about Bitcoin
+and later that year I created Litecoin, an open source fork of Bitcoin.
+In 2013 I wanted to go all-in with cryptocurrency, I talked with
+Coinbase, I told them I graduated from MIT, I worked at Google, I
+created Litecoin, give me a job. So they did, and the rest is history.
+
+I took 6046 here with Professor Ron Rivest, the R in RSA. 6046 is
+actually just algorithms. Mostly boring stuff. Professor Rivest would
+every now and then talk about cryptography, which is more exciting than
+search algorithms.
+
+My other experience in cryptography was that I started a company at MIT
+doing encrypted instant messaging, this was about 15 years before
+Telegram. Back then, people didn't really appreciate encryption as much.
+They didn't care if people snooped on their instant messages like they
+do today. The company did not take off. We implemented blowfish
+symmetric encryption for encrypting messages between users, in C++ and
+Java. We wrote and implemented both encryption and decryption, and that
+was pretty hard.
+
+Bac then there were not that many crypto libraries, and we were a bunch
+of MIT nerds, and if you can write it yourself then why use someone
+else's code?
+
+And then I also learned about economics. I took 1402, Macroeconomics. I
+learned about monetary policy. Tried to question why it's so much like a
+game. Change some numbers there, tweak a dial, you can all the sudden...
+Right? If there's a natural disaster, all you have to do is keep
+interest rates at 0, do some quantitative easing and wala the economy is
+back.
+
+And then also I learned about fractional reserve banking where money
+gets created from debt. If I deposit a dollar into the bank account, the
+bank can create 9 dollars out of thin air. I have three letters for
+that: w, t, f.
+
+One thing that I found out about at MIT is gold. I bought it for $300
+and I thought at that time that it was extremely expensive. Why is gold
+so expensive? And now it is like $1000, which is ridiculous for
+something made out of brass. I also found out that gold is being
+manipulated. The gold price is being pushed down because high gold price
+means dollars are weak. The government may not even hold the gold it
+says it does. The Audit the Fed bill, this is the Federal Reserve which
+sounds like a federal institutio, but it's actually a private
+corporation that is practicing monetary policy and controlling our money
+supply.
+
+So in 2011, I actually found something better than gold, and that's
+Bitcoin. Y'all know Bitcoin is open-source, rules enforced by the code,
+it's decentralized, fixed production, total 21 million coins, low fees,
+and it's borderless.
+
+When I first found out about Bitcoin, I realized that what struck me is
+that it's the best form of money. It's better than gold, it's better
+than dollar, it's better than anything we've ever had in our entire
+history. To realize why it is the best form of money, we have to ask
+ourselves first what is money.
+
+So money can be defined by a few properties. Money has to be divisible.
+If I spend $10 dollars at a store to buy some gum, I have to get change
+back. Money has to be divisible. I have to be able to transport my
+money. A cow is not a good form of money because it is hard to
+transport. It has to be scarce; if you can print as much money as you
+want, then it's not really a good form of money. It has to be fungible,
+what that means is that if you get a dollar, it doesn't matter which
+dollar you get that it is still worth a dollar. Must be durable, it has
+to last. It has to be non-consumable, it cannot rot, fruit is not good
+money, egg is not good money. Something you can eat is not good money.
+
+Seashells? Is that good money? They have been used as currency in our
+history. It is not divisbble, it's barely transportable, it's not
+durable, and the only good thing is that you can't eat it and it doesn't
+go bad.
+
+So next we have gold. Gold has been used as money throughout our entire
+history until recently. Gold is transportable, it's not divisible, it's
+fairly transportable except it's kind of heavy, it's scarce, it's mostly
+fungible except there's fake gold coins and fake gold bars. You can't be
+sure really if the gold coin or gold bar is real. It's mostly fungible.
+It's durable, and it's not consumable.
+
+Next we have the dollar, fiat currency. It's fairly divisible. You can
+get change. It's transportable. It's not scarce. It's fairly fungible
+but there's counterfeit dollars, you have to check if it's fake, and if
+it's not fake then it's not worth $100.
+
+We also have Bitcoin, which is the best format of money. It's divisible
+up to 1 satoshi BTC. It is transportable. To take cash on a flight, you
+have to declare it. But with a brainwallet you can just walk on the
+plane. You can send BTC overseas. It's scarce, only 21 million total.
+It's fungible. Some people are saying that if you use stolen Bitcoin
+that you shouldn't be allowed to use it-- we shouldn't care about the
+history. The fact that there is history tied to it may make it less
+fungible. It's durable, and it's non-consumable.
+
+I believe Bitcoin is the best form of money that we have. Once I
+realized that, what did I do?
+
+I immediately went out to buy some Bitcoin. So, it's interesting. The
+first time that I bought Bitcoin, I bought from Mike Hearn. You may know
+him. Core developer. He was at Google at the same time. He was a big
+proponent of Bitcoin. I sent him $1000 over paypal and he sent me
+Bitcoin. I bought at the high price of $30 per Bitcoin. Thta was
+extremely high because after I bought it, the price dropped to $20, and
+then a few months later it was at $2 after the mtgox hack.
+
+Did I panic? No, I didn't sell. The fundamentals of Bitcoin didn't
+change over that time period. So if you realize something before others
+do, you can make money from this. I bought more Bitcoin.
+
+In late 2011, I decided that I wanted to play around with the Bitcoin
+source code. This is when I created Litecoin. I wanted to create silver
+to Bitcoin's gold. Silver and gold have been used throughout human
+history as money. People use silver because it's easier, it's worth
+less, it's easier to carry around. I wanted to create the same thing.
+
+I first wanted to find a memorable name. I think Bitcoin is a good name.
+I think Litecoin is a pretty good name too. I created more coins. I also
+made it so that transactions are 4x faster. Lastly, this is the most
+important, I made it "CPU mined". The reason why this was important was
+that in for order for an altcoin to survive, it cannot compete with
+Bitcoin in terms of miners. It must have its own miners to support the
+coin. I saw many competitors to Bitcoin because miners wuld jump betewen
+the two coins and Bitcoin would always win out. Coins can't compete with
+Litecoin even in the scrypt space, now.
+
+Yeah, so. These days, so over time, Bitcoin became, uh, when Bitcoin was
+CPU mined, when Bitcoin became ASIC mined, at no point in history was
+Litecoin competing with.. So now that Litecoin is no longer a CPU coin,
+why is it still valuable? I like to explain that with an analogy.
+
+What you see here is Dragon Stone Castle from GoT. Bitcoin network is
+like a castle. It has high security. It's protected by the hashrate.
+Attacking it is next to impossible. Because of King Satoshi's decision
+to subsidize mining, the protection is actually paid for by mining
+rewards today. The number of transactions is not too high. In this case,
+everybody can be protected by this castle because there's room for it
+and it's low cost.
+
+Can this last? Mining rewards will asymptotically approach zero. The
+fees would have to be increased. Once it's not free to be protected in
+this castle, the poor people who cannot afford protection and they will
+have to be outside or do something else. This is where Litecoin can fill
+this role. So Litecoin is not as spectacular as Bitcoin castle, but it
+provides some protection and it's cheap, kids love it. If you are buying
+a house or a car, or interbank settlement, you want the protection of
+the Bitcoin network. You are willing to pay the higher fees to be on the
+Bitcoin blockchain. But if you are buying coffee, it will be too high
+for the Bitcoin network so you will be doing it off blockchain or on
+another network like Litecoin. Bitcoin's end game will be where fees pay
+for the network. Why would anyone mine Bitcoin if anyone is paying?
+
+Someone has to pay for the costs of decentralizations. A high-value
+transaction versus a low value transaction puts the same amount of
+burden on the Bitcoin network. So fees will have to be increased so that
+it makes sense. Low value transactions will kind of be spammy
+transactions on Bitcoin and they will be pushed out. I think it is going
+to take many years for us to see this reality because the fees are still
+too low, everyone can still use the Bitcoin blockchain, but in the
+future other alternative currencies will help out to accept the lower
+value transactions. Litecoin may not be the go-to alternative
+cryptocurrency in the future.
+
+What I know today is that if you have Litecoin today you can spend them.
+This is my purchase for my ticket to this conference. A couple minutes
+ago I went to CheapAir, which accepts dogecoin, and I paid for my ticket
+using Litecoin. I paid for my flight using a currency that I created 3.5
+years ago. I think this deserves an "achievement unlocked".
+
+So I like to talk about Bitcoin again. Why is it exciting? I think
+people talk about how it is analogous to an internet. The way I think
+about it is that, before Internet, information is restricted, right? You
+can get your information from newspaper or TV, and that's it. So um,
+after the internet, now everything is decentralized, you can get
+information from twitter, blog post and all these news sources. Bitcoin
+is the same. Before Bitcoin, money is controlled by the government.
+There are checkpoints to restrict money flow. A few years ago, the
+government cracked down on internet poker. All they had to do is talk
+with Visa, Mastercard and all the banks, and tell them to not allow
+payments to go to these gambling sites. And just like that, people can't
+deposit into poker sites.
+
+I think that's wrong. It's your money, why should the government be able
+to tell you what you can and cannot do? Well, Bitcoin solves that. They
+can't shut down Bitcoin. They can't prevent you from transacting.
+
+Recently they took down Silk Road. And after that, 10 more sites came
+up. And now the whole underground like, underground Silk Road kind of
+sites is like 10x bigger than a year ago. So this quote from
+Rothschild... if you give me control of the nation's money supply, then
+I can control who writes the laws.
+
+"He who controls the spice controls the universe."
+
+So I think that's extremely exciting about Bitcoin. Bitcoin will
+revolutionize money. The last thing that I want to say what's exciting
+about Bitcoin is that it is programmable money.
+
+Right now, everything is programmable. I have a Nest thermostat at home.
+When I go home, I turn off my home alarm, and this turns my Nest
+thermostat that I am home, and then it will turn on to the temperature I
+like. That's really powerful.
+
+Bitcoin allows programming spending money. You can have a smart fridge
+that can when milk is running low, it can send money to Google Shopping
+Express to deliver milk to your house. Or if you have autonomous
+thinking cars, it can just pay for parking on its own.
+
+And lastly, Bitcoin really makes it possible to have autonomous agents.
+Can you imagine having AI that can pay for its own server space? Its own
+storage? And pay for upgrades to computing resources?
+
+And one thing that the AI can also do is it can actually pay people to
+do work for it. There's Amazon's Mechanical Turk which allows you to pay
+to have people to do work. Well imagine if mturk accepts Bitcoin. And
+then you have AI with people doing work for it.
+
+The possibilities are endless. It's up to us whether you are a
+cryptographer, programmer, economist or just a Bitcoin enthusiast, what
+Bitcoin can do is only limited by our imagination. So go out there and
+create the next amazing Bitcoin thing. Thank you.
+
+I have some time for questions.
+
+Q: Are there any ways to stop the fees from going higher?
+
+A: Decentralization costs more. It is more efficient to run a
+centralized system. To have everyone keep track of the blockchain is
+expensive. I think that fees will have to go up. There's only so much
+you can increase the block size by, at some point people are ust doing a
+lot of work for very little money. So the economics have to make sense.
+The fees have to go up.
+
+Q:
+
+A: It is not that related to the difficulty for miners. That's
+controlled by how many people are mining (WRONG- it's the hashrate, not
+people). Difficulty will go down.
+
+Q: Do you see any possibility of centralized mining operations evolving?
+Somebody who invests massive amounts of money into computing power to
+run giant mining fields that become analogous to a kind of centralized
+server?
+
+A: Mining is already pretty big these days. You can still have, it wont
+be centralized to just one or a few. There can still be a lot of
+different miners. It's getting more centralized.
+
+Q: Is that trend evolving to Google/Apple style collections of miners?
+
+A: It's possible, but as long as the Google/Apple don't attack the
+network, I think that's fine. There's no incentive for them to do that.
+
+Q: For your definition of money, you did not include the stability of
+money. A lot of economists define money include stability, why didn't
+you include that one?
+
+A: Stability of value is not a property of that money. Stability is what
+the people make of. The reason why Bitcoin is so volatile is because
+nobody really knows where Bitcoin is going to go. It could be deemed
+illegal and nobody uses it. Or it could become the ... it doesn't define
+the money we're talking about.
+
+Q: Other than the first mover advantages to the altcoin market, how
+would you say, after watching the history, how would you characterize
+your advantages?
+
+A: Well, the first mover advantage is big. It's also big for Bitcoin.
+That's one of the reasons why Litecoin is the most popular one, it's on
+all the exchanges, volumes on exchanges is high, and it's hard to
+overcome that. Litecoin has played a huge role because being able to
+trade in and out of Litecoin is easy. Trading with dollars.. moving
+dollars around is hard, but moving crypto around is easy. So there's a
+lot of arbitrage between Bitcoin and Litecoin. And I think that is why
+Litecoin has succeeded.
+
+Q: Do you think the confirmation time in the future will be an
+obstruction for acceptance?
+
+A: Oh. Yeah. So the reason why I changed Litecoin to be afaster is
+because the 10 minute time was fiarly random (WRONG... wtf)... So for
+merchant payments, zero confirmation still works. I think trusted green
+address payments.. I think we will have to figure out zero
+confirmation... So the confirmation time doesn't matter that much....
+you can't really trustt this other person, so you have to wait for 1
+confirmation, sometimes in Bitcoin in rare cases it takes over an hour.
+It's just not fun. With Litecoin, the most I actually ever did was like
+10 minutes and that's more bareable. That's why I like Litecoin over
+Bitcoin.
+
+Okay, thank you.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/matt-corallo-sidechains.md b/__transcripts__/mit-bitcoin-expo-2015/matt-corallo-sidechains.md
new file mode 100644
index 0000000..cb0256b
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/matt-corallo-sidechains.md
@@ -0,0 +1,271 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Matt Corallo Sidechains
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Matt Corallo (BlueMatt)
+
+Sidechains, Blockstream
+
+One second. Technical difficulties. Okay, sorry about that. Okay. Hi. I
+am Matt or BlueMatt for those of you know me. I swear it's not related
+to my hair. Nobody believes me.
+
+I got into Bitcoin three or four years ago because I was interested in
+the programming and computer science aspects and as well as my interest
+in large-scale economic incentive structures and macroeconomics and how
+we create incentive structures that create actions on a low level by
+rational actors. So this talk is a lot about how Bitcoin security model
+is a function of depending on rational actors from miners and providing
+them with economic incentive structures in the form of money to pay them
+to act in the best interest of Bitcoin. I recently cofounded a company
+called Blockstream and we are interested in bringing this trustless
+technology from bitcoin to a number of industries and products. Our
+initial technology is called sidechains which relies on a similar
+security model to Bitcoin, but allows you to extend it significantly and
+have a lot of new properties and properties that you want in a
+blockchain without putting in as much effort as bootstrapping a whole
+new currency from scratch.
+
+So there's a long history of distributed consensus in academia and I am
+sure some of you are very familiar that Bitcoin is not at all this.
+Distributed consensus in academia has concerned itself with a system
+where you have pre-enrollment of some number of machines, like 5k
+machines in your data center and you want to create some consensus on
+let's say the status of your database or the order in which your
+machines should reboot in order to apply an update. You don't concern
+yourself with what if someone comes along later and wants a proof that
+consensus was reached. Bitcoin has the opposite of these two properties.
+We do not have enrollment. We do not have a list of 5k machines. We do
+not have a list of miners. We don't know their IP addresses. We don't
+now their mining power. They come and go as they please. As new
+technology comes out, um yeah. We also want this property where we can
+bring up a new node that has been offline for a year that has never been
+online that has been offline for a day and wants to see this whole audit
+trail of everywhere that Bitcoin has been and see exactly the consensus
+that Bitcoin came to.
+
+Bitcoin does everything in a different way. This is one of the few ways
+that Bitcoin has been novel. Everything else has been discussed before.
+This new distributed consensus... so it starts with hashcash which was
+created by one of my co-founders at Blockstream, designed for email
+spam. Its goal was two fold. It wanted to create a global decentralized
+rate limit, we want to take spam so that the spam is much less
+effective. We also wanted to definitely not rely on centralized identity
+because identity is a very standard problem for distributed systems in
+the kind of Tor method. Tor's solution is to just become a centralized
+system and track it itself. But we really don't have identity in email.
+You could use gmail login credentials or something.. but we want to stay
+decentralized.
+
+Bitcoin uses this for the same use. Instead of rate limiting email, we
+are rate limiting blocks. We have a block every 10 minutes on average.
+We use hashcash, or scaling-difficulty hashcash, so that we can rate
+limit the blocks so that only one happens about every 10 minutes. But
+that's not nearly sufficient for security. Let's say we have this
+picture here with a blockchain. Each square is a block. I as a miner
+have some hardware, and I have to pick whether I want to build block A
+or block B, and if they were just hashcash then it wouldn't really
+matter if it was just spam. But Bitcoin has to be concerned about
+building block A. Everyone else is going to see the spam and nobody will
+know which chain is the correct one. And let's say that there's a double
+spend in the alternative; which transaction should I accept? And
+especially if these divergent properties continue on for a long period
+of time, there's really no clear solution.
+
+So Bitcoin provides two main costs to convince people to mine the first
+block there. First it uses a direct cost, a power cost involved in
+mining any block. I don't want to just mine a block for fun, I want
+something out of it. And then there's an opportunity cost. If I mine
+block B and I put in a bunch of cost on electricity, I will not get my
+50 BTC if we assume that the rest of the network is honest in the
+Bitcoin sense. And that means mining block A. So if the network is
+mining on the other fork, then I wont be getting anything else, so now I
+have spent money on power for nothing. So as long as we assume that the
+rest of the network is honest, then the rational action for an
+individual who is not colluding with anyone else, then you want to mine
+the one that everyone else is going to be mining on top of... An
+individual rational actor that is not colluding, these are the main
+properties we assume that miners have in Bitcoin.
+
+We assume that the Bitcoin security model in terms of economic is that
+it is the percent of non-colluding rational miners. As Andrew mentioned,
+there's a lot of mining pools that are very centralized and have lots of
+hashrate. This is a weird security model that we almost don't meet
+today, and the only way that things continue to work is that there's a
+potential cost to attack the network, so it may not work. So the
+security model of Bitcoin is strange to say the least, at least for
+someone who wants a computational guarantee of security.
+
+So I want to talk briefly, and I know there are many people here who
+want to build interesting things on top of Bitcoin, and they want to
+build a crazy prediction market, or an identity system or something. So
+what do you need to build a blockchain to make sense? There's a lot of
+ideas that make sense, like Spongebob here.
+
+So, really you still need these two things. I talked about how you need
+this decentralized rate limiting, this global decentralized rate
+limiting that Bitcoin provides through hashcash, and you need this cost
+to attack which is provided by the opportunity cost and the direct cost
+per block. This is the same for any blockchain in the Bitcoin model.
+There is research going on into other models. Most of them are coming
+together but still have problems in various ways, like very minor
+problems to others making the system effectively centralized... So this
+is something you need whether you are building a new blockchain with a
+new altcoin, which needs value for this cost to attack property, or if
+you are building something different. The company I work for,
+Blockstream, our technology that we are building now, as part of some
+other projects, is called sidechains.
+
+Sidechains is quite similar. The principle is that we are going to take,
+we are going to create a separate blockchain but instead of issuing an
+additional currency as part of building a new altcoin like you would for
+Litecoin, we are going to use Bitcoin as the currency. Remember that I
+said that Bitcoin does concern itself with an audit trail of consensus
+history. So we are taking the audit trail and we are looking at the
+sidechain that has parts of its consensus and use it to prove to the
+opposite blockchain that our money wants to come over. So we have BTC in
+the Bitcoin blockchain and we want to move it in to a sidechain, and we
+want to use our BTC in the other blockchain. So we take our BTC and we
+declare on the Bitcoin blockchain that we want to move the money over to
+the other sidechain. Bitcoin will create an audit trail that it declared
+an intent to move. Then in the sidechain we say here is an audit trail
+that someone intended to move Bitcoin over to a sidechain, and then you
+claim your BTC. You can do the inverse to change from a sidechain to the
+Bitcoin blockchain.
+
+By doing this we can create a separate sidechain, with any property we
+want. Perhaps we want more anonymity like Zerocash. Say we want some
+crazy properties that let you build really fancy smart contracts. Say
+you want to build a decentralized marketplace that needs properties for
+bids and asks. We can build that on a sidechain and we don't need a new
+currency. We don't need to bootstrap a new currency, just to provide
+this cost to attack property. Instead, we can just use Bitcoin. But you
+still need the cost to attack property in the form of the opportunity
+cost by paying out mining fees.
+
+The two properties are this rate limit, this global rate limit, and the
+cost to attack. So the global rate limit we can kind of get for free
+using merged mining. We can mine both Bitcoin and the sidechain at the
+same time. We don't need to build an entirely new ASIC market or
+convincing miners to build new ASIC or build a decentralized market. But
+we still need to provide the cost for attack. We already have Bitcoin
+the currency, so we don't need to assign a new value to the currency.
+But we do need to pay out to miners to the opportunity cost for building
+on block A rather than building on block B. This requires either a
+transaction fee, like we see in Bitcoin in the long-distant future,
+which is providing its own security by paying transaction fees rather
+than block rewards. You could do that. You could have hand-drawn
+pictures of cats signed by Satoshi that goes to your winning block
+rewards. You need an incentive for people to mine honestly. Then you can
+get some remotely more stable value than a fresh new cryptocurrency.
+
+Q: I have a question about security. Since there are no block rewards on
+the sidechain, then is a sidechain less secure?
+
+A: If there was no block reward on the sidechain then it would be
+completely insecure. You need a reward system for people who mine
+honestly. That can be by block rewards, transaction fees, charging
+people for actions they are performing because you want to rate limit
+actions, you want to provide incentive for people to not eat up your
+blockchain.
+
+Q: Can you explain the process of the process going back to Bitcoin?
+What happens to that 1 BTC when it goes over to wherever it goes? How
+does it come back? Is it the same BTC? Is it a different BTC?
+
+A: So, yeah, as I mentioned you have to declare intent to move across.
+So you want to move a Bitcoin to a sidechain or the inverse. You have to
+declare on the sending chain an intent to move to the other chain. This
+takes the form of a lock, so you lock it to the sidechain. I am going to
+lock this coin to the sidechain. This allows you to claim it. This
+allows someone on Bitcoin blockchain to provide a proof. I am going to
+spend this money to a script, to a program because Bitcoin transactions
+are spent to programs not just public keys, spending to a program that
+says anyone who can provide an audit trail from the opposite chain who
+wants to move their money back can spend their money. It works both
+ways.
+
+Q: Maybe we have a zerocash sidechain. Would it be cheap to attack the
+sidechain?
+
+A: Merge mining doesn't provide anything. It only concerns itself with
+this idea that we need a decentralized rate limit. It does not concern
+itself necessarily with the cost to attack consensus. Because it is
+somewhat free to mine because you are already mining Bitcoin, it becomes
+also somewhat free to attack. So you really, this is why you need this
+opportunity cost in that if you are mining the wrong chain, then you are
+going to lose money somehow. This is why you still need that incentive
+structure for people to mine your chain to begin with. To mine the
+honest chain to begin with.
+
+Q: So if you are already mining Bitcoin with ASICs, then you may have a
+larger opportunity to attack a smaller network than to actually mine a
+network? If you can short it.
+
+A: Yes, if you can short it. We see today that with merge mining, that
+namecoin is like 70% or 90% sometimes of Bitcoin. So it is not clear
+that such a system is going to be inherently way smaller. If it is, yes,
+then potentially there is a large value to attack. With Bitcoin you can
+still see that the cost to attack it is going to be X, X dollars or more
+specifically X opportunity cost and the cost to attack it, and if you,
+yeah you can run the same number for the sidechain. Yes you have to have
+an equivalent opportunity cost that you might see on Bitcoin, but
+Bitcoin's block rewards for the level of security are somewhat fairly
+large depending on whether you maybe are doing a very large transaction.
+So yes and no. If you have low rewards on the sidechain then yeah it's
+going to be insecure.
+
+Q: I have read that sidechains are an environment to play around with
+innovation and should they work they get eaten up by the Bitcoin
+blockchain. Is the sidechains an end in themselves? Do you envision them
+sticking around and doing their thing?
+
+A: There are many cases where it may make sense, in a sidechain, to have
+a specific property that is useful only to a small subset of people. It
+may not ever make it sense to incorporate that into Bitcoin. Complexity
+is the enemy of security, especially true in the consensus security
+model that Bitcoin has. It may not make sense to make huge numbers of
+changes for every small group of people. For reasonably sized changes,
+that prove themselves on sidechains that have broad appeal, it may make
+lots of sense to incorporate those into Bitcoin, yeah.
+
+Q: So it sounds like there are mechanisms for transferring from a
+sidechain into Bitcoin that require Bitcoin verifiers to be aware of the
+proving system. I kind of have a two-part question. Is it possible to
+make that mechanism general to any sidechain? And if not, how will
+people decide which sidechains will Bitcoin...?
+
+A: Yes the mechanism is general. It will work for any sidechain. You
+have to declare which sidechain you are sending to. And moving back you
+have a proof of which sidechain it is. There's no static list of
+sidechains. You would use the genesis hash. The genesis hash of this
+sidechain is X and yeah, that's any random hash. The only restriction on
+the generalness of this mechanism is that Bitcoin must be able to
+understand the audit trail format of the sidechain. First, you have to
+have a similar kind of, you have to have a proof of work mechanism or a
+proof of whatever mechanism that the receiving chain understands. The
+intent to withdraw can't be in the zerocash format, it must be in a two
+block structure where you have the zerocash actual whatever hidden
+transactions and then you have separate transactions where you're like
+oh this money is moving back.
+
+Q: What happens when the two way peg is part of an orphan block on the
+original blockchain?
+
+A: A soft or hard fork on the original chain? An orphaned block? Oh, um,
+yes, so if you move money from an orphan block on a sidechain, so,
+essentially what you do is from this audit trail should be of sufficient
+difficulty and proof length that it becomes increasingly unlikely that
+you can move money from an orphan block, so you may want to wait 24
+hours. So if you have a significant number of orphan blocks that causes
+you to be able to move money over then both A your original blockchain
+was probably insecure and also B, that does cause problems for
+sidechains. Potentially you can create a system where everyone on the
+chain would take a haircut. This would basically be theft. So you might
+distribute the cost of that theft or you might just let people lose
+money.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/peter-todd-scalability.md b/__transcripts__/mit-bitcoin-expo-2015/peter-todd-scalability.md
new file mode 100644
index 0000000..e3eeff6
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/peter-todd-scalability.md
@@ -0,0 +1,342 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Peter Todd Scalability
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Peter Todd
+
+Scalability
+
+There we go. Yeah. Looks good. Thank you.
+
+So I wanted to talk about scalability and I wanted to give two opposing
+views of it. The first is really, scaling Bitcoin up is really really
+easy. The underlying architecture of Bitcoin is designed in a way that
+makes it easy to scale. You have your blockchain, and you have your
+blocks at the top which are 80 bytes data structures. They form a
+massive long chain all the way back to the genesis block when Bitcoin
+was created. For each block, those blocks commit to transactions in a
+structure called a merkle tree. Some data is pointing to another data
+structure by hash.
+
+In practice, suppose that I have my Android client, it doesn't have that
+much RAM on it or that much storage. I want it to have proof that a
+transaction is real. That when you pay me, you have really given me
+bitcoin. From the point of view of a client, we need a path of one
+transaction up to the blockheader, and the blockheaders are small, and
+with that small amount of data, you can scale up Bitcoin indefinitely.
+
+Suppose there were 2^64 transactions. One block for every grain of sand
+on the planet, every ten minutes. So in this respect, it scales up as
+much as we want. So the next question is how are we going to get these
+proofs of inclusion to the SPV clients. We can go make it web scale with
+sharding.
+
+We can very easily distribute this data across multiple shards. We don't
+have to play with altcoins. Bitcoin could be implemented in really sucky
+Python code that is interpreted and it would still work fast enough.
+There are some changes we would have to do to make this feasible.
+
+Right now a block does not commit to its contents in a way that is
+indexable. If I have an address starting with 1A3, I want a way for
+miners to go down a path in a tree or follow the A's and the B's and so
+on, you will end up at the part of the block that contains payments to
+you that you care about. This is called utxo commitments, txo indexes,
+and so on. Long story short, we know how to do this. We can implement
+this pretty easily. This will scale up Bitcoin great. All the clients
+will work fine.
+
+The problem is, it's not that simple. Bitcoin is not something where we
+have a centralized database. This is not a web2.0 application where we
+have someone who we already trust. We don't just query them for data.
+"Be your own bank" means that we want to have a system where everyone
+can participate fully. When we say fully we mean not just in making a
+transaction but also in terms of being a part of consensus and
+validation and the decentralization. After all, if you define "fully" as
+"able to make a transaction" then technically Paypal is a system where
+everyone can participate. A paypal transaction costs 1% or 5% of the
+value of the transaction. That's "fully participating" I guess.
+
+Miners are a trusted third party. That trusted third party as a whole
+signs blocks. Blockstream calls this a dynamic membership multi-party
+signature. Matt used this term earlier today. It's kind of this way of
+thinking about consensus algorithms in the context of how people talk
+about consensus. Paxos and other algorithms have a notion of a set of
+people in the consensus. But in Bitcoin the contribution is that the set
+can change. That's not to say that Bitcoin is not a trusted system...
+miners can censor transactions, they can change the rules. Your only way
+of protecting against that is your ability to audit what they are doing
+and participate.
+
+Bitcoin has economic incentives to build along these chains, touching
+along what Matt Corallo was talking about. Those incentives do not mean
+anything if nobody has incentives to be a part of that. When the number
+of participants is quite small, then incentives are hard to align and
+make work properly.
+
+What happens when those mechanisms break down? As an example, suppose I
+was a miner, and there was a small number of me. Maybe we scaled up to
+the point where only there was a small number of miners. What happens
+when a miner decides to mint a block that creates BTC out of thin air?
+From the point of view of a SPV client, it can't tell if that
+transaction exists. It's view of the blockchain is only from the other
+side. It wont know that the block is invalid. It will just assume it is
+valid.
+
+We have some possibilities here. The proof that the miner created an
+invalid transaction is relatively short. We could package it up as a
+fraud proof. We could show that this part of the consensus algorithm was
+broken, the miner committed to an invalid transaction, and then we pass
+the fraud proof around.
+
+How do you know that you are going to get fraud proofs? How do you know
+you will find them? We don't have any good answers to this question. We
+have no good way of ensuring that when a miner might create something
+that is invalid that someone is actually going to check it. For
+starters, you cannot assume that the Bitcoin network is composed of
+honest nodes. The Bitcoin network could very cheaply be replaced by
+someone running 3k Amazon ec2 instances with 3k different IP addresses.
+You just don't know. Someone who has the resources to do mining can also
+have the resources to easily do those Sybil attacks.
+
+Another issue is double spends. If Alice pays Bob and Charlie with the
+same money, on both sides of the blockchain it looks valid. How do you
+detect that? People have proposals like "ring blockchains", where you
+have a ring of blockchains where payers of chains get checked by each
+other, or you move money between chains. This is very much an open
+research question. It is not clear how to enforce this kind of thing.
+And even worse, with this sort of detection of double spends and fraud
+proofs, you have to wonder what happens in reality when fraud isn't
+detected until 3 days later? Do we roll back the blockchain? Do we just
+accept it that someone created some Bitcoin out of thin air? Do we just
+accept this? We don't know. As long as miners are a trusted third party,
+which may be inevitable, we just have to rely on the incentives working
+and the checks and balances working.
+
+Now, how do you scale up? I think we have a lot of small scale
+solutions. I like to call them micro-optimizing bubble sort. Bubble sort
+has O(n^2) scaling. You can take bubble sort and rewrite it in assembly.
+You can get a 10x improvement. But what you can't do is get a factor of
+100 improvement. That n^2 figure will eventually bite us. We will end up
+in a security situation where it is not easy to run a full node or check
+everything.
+
+Maye this means we can increase the block size to 20 megabytes or 40
+megabytes. Maybe. I don't know.
+
+This is not a technical debate either. In an environment where Bitcoin
+does not scale up upwards indefinitely, ultimately what we're doing is
+talking politics. We are saying that some people in the Bitcoin space
+will lose out over others. I think technical people are not used to
+this. They expect this to be about facts and figures. They expect
+performance benchmarks and conclusions. But in Bitcoin, we have
+regulatory issues. We may have some users of Bitcoin who follows laws
+that other people don't. Some other people may think those laws are
+unjust. If I am a Bitcoin user in a country like Russia, I want to
+ensure that I can continue to participate in Bitcoin. But if I can't,
+because my government is restricting my access, and at 1 megabyte I can
+evade those restrictions whereas 20 megabytes I have not, that's a
+political situation. In our efforts to scale up for some people, we may
+cause other problems for other people.
+
+This problem has technical aspects. Who benefits or who doesn't benefit
+is not a technical question. I don't have answers.
+
+If we want to scale up without getting into this political stuff, we can
+certainly do lots of stuff. Changetip is scaling up Bitcoin without
+transactions. Every time I tip someone with Changetip, I am transacting
+without a transaction on the blockchain. Well, sending money on twitter,
+you already have trusted entities there anyway. In reality we have found
+that this is acceptable to some people.
+
+There are payment channels and hub-and-spoke models. Where I can send
+money to Bob and I can essentially lock some money up and then adjust
+how much I give to him. I can send money instantly and in very small
+increments to a third party. They can send that money to someone else,
+and if I want to send money to Alice, I could send Bob a few pennies and
+Bob could send Alice a few pennies until finally I have given Alice the
+money I want to give her. Again, this is a tradeoff. We have decided to
+involve a third party. They don't have trust; but Changetip does. But
+they are a central point of failure. I am going to have to go pick a
+point of failure that I, and the people I am transacting with, agree on.
+There may be some privacy issues, and maybe we will use Chaum tokens or
+something, but it's not clear if people will accept this.
+
+On the bright side, these solutions do not need consensus. They do not
+need Bitcoin transactions. We can pick them based on what different
+communities need. Look at Silk Road. They had an off-chain transaction
+system. It never hit the blockchain. There were a lot of advantages in
+terms of privacy there. And the community of people that were involved
+were specific to that purpose. They didn't need to care about
+regulations in other countries. They could pick and choose because they
+were building on top of the decentralized network.
+
+It's much harder to build something on top of a centralized system that
+meets the needs of those communities.
+
+There are many ideas out there about sharding the blockchain. I have a
+proposal myself called treechains. I know ethereum is looking at similar
+proposals like this. They work by saying, let's split up the blockchain
+in a way so that multiple parties can participate in mining, so that we
+are collaboratively creating this data structure that meets the needs of
+anti-double-spend protection and validation and so forth. This is not
+easy. Let's be honest. It's much easier to just use Bitcoin as it is, to
+make the assumption that we have a trusted third party and hope for the
+best.
+
+Again I think this goes back to the politics of the situation. We don't
+necessarily know what the threats are. The Bitcoin community does not
+tend to look at this problem. Here's a threat model, we will evaluate
+our solution against that threat model. It's usually an engineering
+point of view, of tweaking knobs to reach some goal. I can't give a lot
+of good insight into where this is going to go. It would require
+consensus changes in some cases. It would require people to come to
+agreement that there is a problem, and that we would all agree to change
+the architecture of Bitcoin. I don't know what will happen. Maybe it's a
+sidechain that implements completely new consensus. Maybe it will be an
+altchain. Maybe Bitcoin gets killed off first due to a poor scalability
+aspect.
+
+I don't know what's going to happen. So thank you.
+
+Q: As you mentioned, Bitcoin has these trusted third parties who are the
+miners, and we are still paying the price as if it was trustless. Blocks
+are slow, costs per transaction are high. What do you think the risk is
+that there was a trusted third party, setting up 10 trusted node, and
+running 10 million transactions per second?
+
+A: Well, if you assume that for the Bitcoin network to succeed that it
+needs transaction fees, then that's a big risk. When I was first working
+on off-chain transaction systems, I was talking with gmaxwell and I said
+that if we do too good of a job we kill Bitcoin on that basis alone.
+Eventually the block reward keeps decreasing and that may eventually
+reach the point where it is not enough security. I don't know what
+happens then. Maybe Bitcoin gets attacked. Maybe we decide to fork and
+keep printing 50 BTC forever. Maybe something else gets developed. Maybe
+so many purposes and so many systems are using Bitcoin that need proof
+of some kind, not necessarily monetarily, that collectively as a hold,
+all of these use cases provide enough security. My treechains idea kind
+of makes that assumption where you create a system that doesn't
+necessarily have money attached to it, you just assume hopefully you get
+enough use cases that adds to the security enough. I think we will have
+to find out the hard way.
+
+Q: Sybil attacks?
+
+A: Sybil attacks are easy. I have done this before as a trial. I was
+surprised with how cheap and easy it was. It doesn't take much, you
+know. Android SPV clients are very vulnerable to this because,
+especially in bitcoinj. When I turn this on, it connects to a very small
+number of nodes from the DNS seeds. It does not remember nodes it used
+to connect to. So you just find those small number of nodes, you run
+enough to outcompete with them, then you DOS attack the ones that are
+not yours. You can pull this off with a few hundred bucks. I looked at
+this on testnet, I spent this amount of money, testnet is this big, well
+that just means mainnet- well it's a small amount of money. Ultimately
+it's way cheaper than money.
+
+Q: Thank you for the talk. I appreciate your contributions. Something
+that seems to come up when discussing Bitcoin Core. The advantage that
+Satoshi had was that he was an okay computer programmer, but he was an
+excellent economist. I think this is not an attribute shared by all of
+the Bitcoin Core developers necessarily. My question around scalability
+is, how could we possibly figure out what the optimal block size is to
+find a balance between scalability and making sure there is a sufficient
+volume for transactions for whatever number is ideal for taking place on
+the transactions? That seems to fall under the von Mises calculation
+problem. Would it be better to leave blocksize up to the market through
+some new mechanism rather than trying to plan the blocksize?
+
+A: The problem is that this is an externality problem. It's like saying
+how do we find out what the optimal amount of coal pollution is and
+let's the coal power plants decide that. We know that, if I am a miner
+with 30% of the hashing power, it is my incentive to prevent my ... my
+incentives are not compatible with a whole lot of mechanisms with
+letting the market decide. The market is, coming to consensus is a
+process controlled by miners. So letting the market come to consensus on
+this because miners are the ones calling the shots. They are not the
+market as a whole. There is a way around this using voting, written
+about 1.5 years ago on bitcointalk by John Dillen. If miners choose not
+to mine larger blocks, there's nothing we can do about that. But to
+increase the block size, we could go make this a one-sided vote. We
+could use voting with proof of stake to give miners permission. And
+that's one of the few examples where you can have this vote that is
+guaranteed to take everyone into account, or give the potential for
+everyone to be taken into account. And the very notion of putting this
+up for vote is extremely controversial. When John Dillen put this up in
+the first place, people asked why are you taking a technical decision
+and putting it up for vote, you'll get a terrible result? Well you don't
+even have agreement that this is political and not a technical question.
+Leaving this up to miners is not a good idea, that's a narrow point of
+the market.
+
+Q: Thank you for talking about the adversarial approach. Who is going to
+provide the fraud proof? Is it going to be the other miners? Or are you
+already assuming a 51% attack?
+
+A: I think the issue is that miners collectively can have very different
+interests than users as a whole. You get lots of cases where you may
+want to do something that may be seen as an attack but you don't want it
+to be an attack. You could have a situation where your blocksizes have
+increased to the point where it is hard to be a miner, and then miners
+then decide yes the amount of inflation reward is too low, we want to go
+in and increase the inflation reward because it's good for Bitcoin. This
+looks like an attack, but it also doesn't look like an attack.
+Politically it is not easy to talk about this. They have created a block
+that would be rejected by the Satoshi code base. Maybe they say they
+want to change the reward; well maybe they go write some Sybil attacking
+nodes, and ensure that when the average person connects to the Bitcoin
+network he has no way of getting proof that this is actually happening.
+But again, dishonest is kind of a fuzzy concept here. What this is
+really saying is that we don't have a mechanism where we can get into
+that majority, where it is currently very easy for someone to go get
+some mining power, some hashrate, connect to a pool, maybe they don't
+like Luke-jr's pool then maybe not connect to that pool. That happens
+frequently, but in the future it may not be the case.
+
+Q: Between yesterday and today, I think I learned a lot in terms of
+Bitcoin technology and protocols. My only question was, what are the
+implications of the blockchain technology, like five years from now? If
+you think of one dollar as like a signal to the market between supply
+and demand, and driving all of that information, what would be like the
+implications of supply and demand using the blockchain technology?
+
+A: I don't like the term blockchain technology. I think it gets used
+when the term "cryptographic auditing" may make more sense. Satoshi's
+design for the blockchain was not very good. It left many opportunities
+for indexes that need to be made. It left things on the table that a
+better design would have let you prove. Equally when people talk about
+blockchain technology, they might overestimate how important it is to
+have mining. Once you have a blockchain being mined, you can leverage
+that against the will of the Bitcoin community to secure your own chains
+in an interesting way. Well where do people go with that? Do they just
+talk about a blockchain technology? That's the wrong way to think about
+it, I think. We will see many interesting uses of this stuff in the
+future.
+
+Q: In your mind, what does the sort of, the current technology, what is
+the theoretical sort of limit the confirmation cycle? So from the point
+that the transaction is made, it is embedded into a block and it is
+verified by the miners and essentially proof of truth comes back, at the
+current algorithm, what is the minimal time required?
+
+A: This is easy to answer. We can take blockchain technology. We can say
+here's a set of trusted miners. We know that this is how Visa,
+Mastercard and Paypal works. But it's based on trust. But what about
+decentralization? Maybe Bitcoin has already gone too far in terms of
+something that can't be decentralized. We are just going to have to find
+out.
+
+Q: What strikes me is that one of the key points for actually the
+acceleration of the adoption of Bitcoin throughout the real economy and
+the financial economy is actually the fact that the system is too slow,
+right? And it's not competitive with Paypal?
+
+A: You want something like a fast confirmation? Look up green address,
+payment channels, etc. We can definitely get fast confirmations with no
+changes right now. I hope this answers your question, I have zero
+minutes. Thank you.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/security-and-usability.md b/__transcripts__/mit-bitcoin-expo-2015/security-and-usability.md
new file mode 100644
index 0000000..4c0090f
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/security-and-usability.md
@@ -0,0 +1,358 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Security And Usability
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %}
+
+- Melanie Shapiro
+- Alan Reiner
+- Kristov Atlas
+- Elizabeth Stark (moderator) and maybe Melanie Shapiro? malani?
+
+Security and usability.
+
+Elizabeth: I think this is a highly relevant discussion. I talked a bit
+about regulation. Regulation might be the number threat, but security
+might be the number two threat. I am excited to have a panel of leaders
+in this space who are actively building in this ecosystem. I am going to
+ask each to do a quick intro.
+
+Alan: I am the original creator of Armory and the Armory Bitcoin wallet.
+Last year I gave an introduction to Bitcoin. We have been around
+since 2011. I started to acquire Bitcoin from mining. Now we are
+developing enterprise solutions on the topic of security and usability
+they would say that Armory does not have usability at top of mind.
+Others have that in mind. Our focus is security though. That's where
+we're going with large institutions who have the resources to get over
+the usability and do the security right.
+
+Melanie: I got into Bitcoin in 2011. I was doing a PhD sponsored by
+Microsoft at the time. I became utterly fascinated by it. I spent the
+next couple years figuring out how to do something meaningful in this
+space. Biometrically secure will be launching in a couple weeks.
+
+Kristov: I started writing a book about Bitcoin privacy. That is a topic
+that I care about quite a bit.
+
+Elizabeth: What do you see as the biggest pro and biggest con in terms
+of Bitcoin security?
+
+Melanie: I think one of the biggest limitations is the users themselves.
+I think that placing responsibility in the hand of users is often times
+there is human error. Losing a piece of paper and private keys.
+
+((feed just skipped forward by like an hour))
+
+Alan: Sometimes the community mischaracterizes the security as one size
+fits all.
+
+Kristov: There will be different needs that people have for Bitcoin. But
+I am not sure that I agree that we are necessarily going to see people
+being their own banks, and then we will gravitate back towards something
+in between. I think that what we will see is closer to the realm of
+being your own bank in the Bitcoin space because in terms of engineering
+we can accomplish this, we can allow grandma to be her own bank without
+a substantial risk of funds. I think there are some things that we need
+to develop to get there. There is a temptation to say, man, hey, ...
+achievable..
+
+Elizabeth: I gave my grandfather a bitcoin for christmas a few years
+ago. It is currently being held in a hosted wallet. So I want to
+know.... where will he be his own bank?
+
+((lots of streaming problems))
+
+Melanie: To get people to actually .... using Bitcoin.. you are
+competing with credit cards. It's fairly simple to use a credit card. We
+should all be developing products that... to use ...
+
+Melanie: So that you can be a little bit careless. You're not completely
+at risk if you lose that credit card. With Bitcoin, obviously we all
+know that... that's not the case.. so you have to change that perception
+and that behavior... and getting people.... You do need to own your own
+security. You do need to be more aggressive about that.
+
+Kristov: So I think the world in which ... where we adjust from a very
+old world perspective to the world of Bitcoin and cryptocurrency. A lot
+of the challenges that come around security come from the fact that
+Bitcoin is so ... When you put it in the realm of money, people care a
+lot more. NSA downloading your photos from Facebook, meh. When you have
+bad Bitcoin privacy, people take all of your money and they hunt you
+down. So putting things in the realm of money is going to change things
+quite a bit in a way that we are not going to expect.
+
+Elizabeth: A recent survey among Facebook users were unaware that they
+were using the Internet. Usability is going to be a major issue. QR
+codes or strings of alphanumeric.. or long random passwords.. are not
+usable. Are usability and security fundamentally at odds with each
+other? And if not how can we address that issue?
+
+Melanie: As you become more secure and you add layers of authentication
+and security.. it gets more challenging... it does not have to be that
+way. There are great products that are secure and easy to use.
+
+Elizabeth: Like what?
+
+Melanie: I think that LaunchKey is an interesting product. What's ideal
+security though?
+
+Elizabeth: I think that LaunchKey is a device-based authentication
+company. Kind of like authy?
+
+Melanie: I think we need to define what ultimate security looks like.
+And then what does the ultimate use case look like? That's where we
+should looking for products. It's hard enough to enter into the Bitcoin
+ecosystem to think about these things. It needs to be as few steps as
+possible. It also needs to be the security of paramount importance for
+that user.
+
+Alan: My perspective is sort of contrary, but not specifically. I have
+an enterprise focus at the moment. Focusing on large organizations with
+employees managing money. It would be hard to say Bitcoin is going to be
+mainstream but we wont have large banks handling money? The difference
+between the consumer and the institution is that the consumer is
+managing their own money. They wont steal from themselves, it's already
+their money. But when you have employees managing, it's a different
+story. You just can't do that or don't make sense in the consumer space.
+My focus is on enabling those larger organizations which is the
+narration that I am going with. Those organizations have to have a high
+security solution that is not going to be usable by consumers, but they
+can also train employees and implement strong processes.
+
+Melanie: I think that the way that security will look for consumers and
+institutions will be different. People have time to be trained.
+
+Kristov: What we aim for is not perfect security but a certain
+threshold, which is context-dependent. I think there is a trade-off has
+been reached in other industries, like automobiles. There's some
+tradeoff with a car that is fun to drive and a car that is safe. A car
+with no doors and no roof, you can do all kinds of exciting things with
+cars if you have no safety standards. I think we will figure this out
+with Bitcoin.
+
+Elizabeth: Does centralization of say consumer funds pose a threat to
+the ecosystem when it comes to security? We have seen hacking, like
+against Bitstamp.
+
+Alan: My opinion is that, that whole infrastructure around centralized
+Bitcoin storage solution is not mature. We know about cold storage and
+multisig, and one of the things I talk about is in the institutional
+security world.. having employees manage valuables is not new. They have
+processes around that involve people, witnesses, lawyers, notaries. They
+have existed, they just haven't got into the Bitcoin system yet. There's
+this kind of.. it's going to be there. It just hasn't been there. So
+drawing too many conclusions based on the current state does not
+necessarily mean it wont be there. The maturity level and the
+institutions and so on, it just hasn't lead to that being integrated
+properly yet.
+
+Kristov: Yeah the pattern is, let's start a Bitcoin company, okay well
+we're going to make a copy of how it worked in the last financial
+system, we will have a lot of controls removed because it's Bitcoin and
+new, and that's a lousy place to start off. Naturally that's where they
+started. If we can get everyone, especially the leaders to adopt the
+cutting edge technological things, we would be a lot better off, like
+multisig and proof of reserves, voting, threshold signatures, if we
+could people more uniformly applying this across the board we would see
+less theft.
+
+Elizabeth: What role does education play in engaging both the enterprise
+and consumer side of things?
+
+Melanie: I think education plays a huge role. The kind of education is
+in the hands of the media, and they don't do a good job of understanding
+Bitcoin. I think a huge challenge is how we as a community face towards
+that audience. I think we are getting better at that. I think the
+conversation is becoming a little bit more positive, except when we have
+price volatility. I think that's where the education has to start.
+People have to start speaking out about the benefits and why we need
+Bitcoin security. And once you have a positive conversation sand then
+you can educate consumers about what it is actually like to use Bitcoin.
+
+Kristov: I have a few thoughts about education. It's a stop-gap measure
+for designing security into systems. If we can educate users to be more
+proactive about protecting themselves, then we don't have to build the
+security into it. We should just build it into it, it should be
+intuitive and natural. Education is not a replacement of that. We can't
+get everyone to the point of being an undergrad MIT computer science
+student. So in the Bitcoin space, I think this is a good place to be, a
+lot of the progress that is made is driven by consumer demands and not
+by industry standards or government demands. For this progress to be
+made, this has to be driven by educated consumers. A lot of what I run
+into is a lot of Bitcoin consumers are not informed about the privacy
+aspect of Bitcoin. They know a little about security, much less about
+privacy. We are not seeing a lot of demand for privacy-friendly
+services. So we need to educate users about how it is important and it
+is going to impact you and you should be asking for privacy from these
+companies. I think this will create better services.
+
+Elizabeth: What benefit can blockchains provide for security beyond just
+money itself? We have talked about the future of this space. What do you
+see in the future?
+
+Kristov: So, I think that Bitcoin is actually in terms of pushing the
+boundaries on security, I think it's kind of moving in several
+directions at once. In the cryptography side of things, we are ahead of
+the curve. We are seeing people splitting up keys, using cold storage
+instead of hot wallets, using multisig. That's more advanced than what
+banks are doing. There's a very low percentage of banks that are doing
+things like splitting up cryptography keys so that attackers have to
+compromise multiple sites; they don't do that. On the front of
+application consumer, like network application security stuff that
+happens everywhere on the web, we're behind because we're a new
+industry, but I think we will catch up pretty quickly. I think that
+Bitcoin is already ahead, 10 years from now it will be staggering as to
+how far ahead Bitcoin is for securing funds and banks are not going to
+be able to catch up without joining up with Bitcoin.
+
+Alan: I think that at its core, multisig is something totally new to the
+world of physical security... This idea that you can have something
+protected by private keys that are all generated independently in their
+own environments, they are never brought together, you can independently
+generate them, the people managing the devices don't have to know who
+the other people are, they don't have to know the security of the other
+locations. You can create a truly truly decentralized security system
+and no point was ever a single point of failure. I toured the Verisign
+facilities where they have a 6000 pound safe that holds tons of
+cryptographic material. And they have 17 people to get into that safe.
+That cryptographic material was generated in one place, sure, and
+there's a huge process, but maybe you can scale this back now that you
+have 7 independent locations and there was never any colocation from
+start to end, you have a fully distributed security model.
+
+Melanie: Well, one, multisig. Healthcare, banking, finance, I think
+everyone will see what's going on in our space and modeling their
+security off of what we have been doing for years.
+
+Elizabeth: There are still browser vulnerabilities. Mainstream users do
+not like browser extensions. What about hardware approaches to ensure
+security?
+
+Melanie: It's a multisig hardware wallet, one of the keys is in a
+database on the server, one of the keys is on the device, one is in
+third party cold storage that you can manage. We generate one of the
+keys on the device, so that we can maintain the RNG and know which keys
+you generate. The key in cold storage is third party, and if you want
+access to it that's great, but I think for the mainstream user that key
+and protecting it themselves I don't think that sits well for me, so for
+mainstream users that will not work out. Each one of our private keys is
+secured by a different layer of authentication, biometric inherence
+factor protects the key in the database, and the information layer
+protects the key in cold storage.
+
+Kristov: One of the challenges around hardware wallets, we need trusted
+competing devices. In the consumer space, we see a condensing to one
+device. We used to have a camera, mp3 camera, now we have one device and
+they are all getting smaller unless you are an iPhone user of course.
+Hardware wallets do not need to be these huge beefy machines. Maybe it's
+just a chip on the phone, maybe it's something embedded in your body,
+it's not something that will weigh you down. But right now, the smallest
+device that I have heard of, outside of Ledger, there's trezor and these
+other things that is like really big and you have to carry it around.
+That's a burden for the average user.
+
+Melanie: One of the things we're doing and putting money into is, right,
+I think money is moving towards a single phone that we all want. When
+that phone has everything about you, like healthcare, money, that's...
+
+Elizabeth: What happens if you lose your phone or it's stolen?
+
+Melanie: I think hardware plays a huge role in this ecosystem. In two
+years, I have no idea what role it will play.
+
+Alan: On the enterprise side, things are not necessarily getting
+smaller. These are concepts that have been around for 20 years to
+protect other types of cryptographic material. This is known as HSM.
+These are $5k-$30k Linux boxes that you put into a rack, it destroys
+itself when you try to break into it, it's what the biggest banks in the
+world use, it's what the rootzone DNSSEC security that protects the
+backbone of the internet uses. Only recently there are a few working on
+some. Armory has announced integration with HSMs. Again it goes back to
+the maturity of it. As large institutions get into it, like insurance
+banks, they are already familiar with it. Banks and insurance companies
+are already familiar with HSMs. That's a prereq for declaring that you
+have a secure solution. This should be a requirement from the start.
+
+Elizabeth: Recently we saw BitGo release a standard for security. Do we
+need to establish a set of practices amongst the community?
+
+Melanie: We use the matrix they came up with with C4.. My engineers all
+have it on their desk ((if you actually read it though, it's... not
+good)).
+
+Kristov: Coming to consensus about this is critical. I am working on my
+own project in the privacy space, we are working on publishing standards
+in the privacy space as well. It's basic stuff that we have been doing
+in security and infosec for a long time.
+
+Melanie: It should not be the wild west.
+
+Alan: It is going to converge. What you are going to see is that as more
+institutions get involved, especially in the enterprise market, you see
+a lot of overlap in the way these things are managed. What's trusted
+ends up being the standard. You see all these companies that you believe
+are secure, what are they doing similarly? That is going to become the
+standard. The transparency of it and the standardization. New players
+that come in will have a chance to know what to do to get insurance
+quicker, and the insurance company will trust me more because of the
+vetting.
+
+Melanie: Companies should not have to make this up on their own. BitGo
+and C4 are two different entities. I think that the community itself
+should work together to have best practices. We need more of that.
+
+Elizabeth: What about backdoors? Some people on the international level
+are taking this seriously. I am going to assume that the panel is
+against this. What can we do about backdoors?
+
+Melanie: I was interviewing someone who worked at the NSA. I asked him
+what he worked on. He was working on consumer firmware. It was a real
+problem, we didn't hire him ((why not? he was experienced...)) We are
+manufacturing, we have a device that we are shipping out. We are using a
+New York state manufacturing company, it's 5 miles down the road from my
+office. We are there when the devices are being manufactured. We want to
+be intimate with the process. Having internal... having operational
+security within your organization is important. We need standards for
+that as well.
+
+Kristov: I work for Blockchain.info, and one of their philosophies is
+that you design the software so that when someone comes knocking, it
+needs to be too late to do that. That boat had already sailed several
+years ago. I encourage companies to do that as much as possible, not
+because there's a particular organization that they are concerned about,
+but rather because if you can give access to one organization then
+others can take it from you as well. We need to build these systems as
+secure and private as possible from the ground up, otherwise there is a
+countdown on your business or organization where the compromise happens
+and people will be really disappointed in you.
+
+Alan: Operationally transparent is the right word I think. At the end of
+the day listening to someone like Joi Ito talking about FMTs and
+wondering about whether there is any end to the paranoia.. well, much of
+it is justified. At the end of the day, the problem is split into many
+pieces, and you need strong process at each of those steps. At the end
+of the day you cannot prevent everything, but you can reduce it and pick
+out large parts of the problem and know that some things have been done
+right. And perhaps there are forces beyond our control. You cannot throw
+up your hand and say it's unsolvable, you must solve this.
+
+Q: We hear about stolen accounts in the world. Millions of stolen
+accounts. I know lots of people around me that are probably among those
+stolen accounts. But I have never heard anyone complaining that any
+money was stolen from his account particularly. That's the first thing.
+Can Bitcoin be stolen in the first place? At all? And by the way, if I
+can buy coffee with my Bitcoin, that's not security that's limitation.
+
+Alan: Can Bitcoin be stolen at all? I think that's a question of again
+something that Joi Ito said. The cryptography is sound and it is really
+the process around it that is insecure it. So maybe it's a philosophical
+question to say, well they weren't really stolen, but... the fact is
+that, the world depends on the actual programs and algorithms and the
+cryptography behind it. When we talk about stealing coins, it will be
+the human element not necessarily... it may be that you had humans in
+the loop making bad decisions about which technology.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/some-questions-for-bitcoiners.md b/__transcripts__/mit-bitcoin-expo-2015/some-questions-for-bitcoiners.md
new file mode 100644
index 0000000..719d9ff
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/some-questions-for-bitcoiners.md
@@ -0,0 +1,254 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Some Questions For Bitcoiners
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Joi Ito
+
+He is the director of the MIT Media Lab. He served as the chairman of
+the Creative Commons and is on the board of the Mozilla Foundation.
+
+Just so that I can get a sense of the room, how many people here would
+say that you are technical? Most of you. How many of you were on the
+cypherpunks mailing list? How many of you have been threatened by
+Timothy May? How many of you know Timothy May? Okay.
+
+It's interesting. If you go back, this isn't really a new thing. I have
+been paying attention, I was paying a lot more attention in the 90s. We
+setup one of the first ecast servers. I hanged out with the cypherpunks
+at the hacking conferences. I have been interested in this space for a
+while. What's interesting is if you think about the arc of attention and
+the sudden increased attention in cryptocurrency. I am looking at other
+types of technology and platforms and how they proliferated in those
+curves. I will talk about the community.
+
+I don't know how many of you have read this, this went out on the
+developers list. The research perspectives and perspectives for
+challenges on cryptocurrencies. I am sort of influenced by this at the
+moment. A lot of the stuff you already know, it sort of systematically
+and neutrally goes around all the various types of attacks and
+weaknesses and strengths. We need to bring in the non-, how do you call
+it, the traditional computer scientists to look at this in a robust way.
+In addition to all the regulators, there are a lot of people that aren't
+sure how safe this is.
+
+As we start to look at the security and think about formal proofs, I
+guess it was Kevin Mitnick. The human in the loop is the weakest part of
+the loop. You can have a secure algorithm that you can provably secure
+but it is only as weak as the weakest part. Obviously human beings. And
+also hardware. So I find it fun and ironic that Zappo has to put your
+Bitcoin into deep freeze with the power off to make sure it is secure.
+So we end up in the physical world.
+
+And then you have to watch it through the manufacturing process because
+of the possibility of tampering. I think that is one of the weakest
+links. We have been working in Shenhzen lately at PCB factories, and I
+am standing on that floor and there's people you trust, and working with
+them is an essential element of that. We need to make sure that we don't
+forget, I used to run an ISP and lots of people talked about cyberspace
+as if there was no physical element. But there are really routers and
+stuff sitting around. There's intermediaries.
+
+The physical hardware is really quite exposed. In addition to thinking
+about ,ti's not the bitcoiner's job, but we are putting more targetable
+risk into the hardware devices that we have right now. I think that
+thinking about secure hardware and network security is important. We
+have to think about secure people. Do you trust the person on the
+factory floor? Do you trust the person carrying it across the border?
+
+The human brain is pretty hackable. It is more insecure than any
+software system we have. This guy has an experiment where he wires up
+your brain, and you click this button. Click and a light goes on, and if
+the light goes on already, then you don't have to click it. Three
+seconds after they see you getting ready to make the decision, they turn
+the light on and you click it anyway because you don't realize the light
+is on. And so there's a five second window in your brain after you have
+decided to do something, before you realized you decided to do
+something, I think that is a big security hole. Because he is sitting
+there behind you, knowing before you know what you are going to do. And
+what happens when you trigger that free will neuron? And we're learning
+more and more about how we are going to be manipulating brains. We have
+a great deal of self-deception. You may feel trustworthy, but somebody
+may embed an exploit, like through hypnosis or something. I may have
+many friends that I completely trust, but I wouldn't trust that their
+brains haven't been tampered with.
+
+Last week we did a gut biome discussion. Much of our personality is
+driven by the bacteria in our gut. In certain diseases, a fecal matter
+transplant (basically a poop transplant) fixes diseases but you also get
+the personality and the allergies that you get the FMT from. So if you
+could imagine stealth FMTs, and you wake up and suddenly you are a
+different person. So we are going to need tamper-proof assholes. So we
+know experimentally that you can copy personality from one person to
+another with a fecal matter transplant, but what's interesting is when
+the NSA begins to design bacteria to make you behave in different ways.
+Perhaps this can solve depression in a few ways; so that means it will
+be funded. You have to be aware of the different levels and layers where
+attacks can occur.
+
+There's a, there's another part which is when you think about the
+hardware, it's really important to remember that, this could all be a
+simulation. We could all be sitting inside a big AI, and then any
+security we think we have is just an illusion. I don't know if you guys
+know Bunnie Huang, but he had this idea, this Chinese GSM chip sitting
+on a board built into his laptop. The chip had all of its pins wired up.
+So for all the chip knew, it was being a phone. But it was on a little
+card in his computer where he could manipulate any input or output. But
+he was completely monitoring it and creating a simulation. All of our
+hardware has concentric rings of vulnerability. For that chip he was
+reverse engineering it. We should think about these shells. Regulation
+has a lot to do with what we can and can't do with Bitcoin.
+
+One thing to think about is the community and the architecture of the
+community. If you think about the technology we use today, like
+ethernet, it was probably not the best thing that could have been
+devised at the time. Because of a variety of factors, it got to the
+right place at the right time. You can use game theory in retrospect to
+explain why ipv6 is not switched on everywhere. But in advance it would
+have been hard to predict TCP/IP and ethernet. Those are probably more
+to do with community architecture and personality than with technology.
+
+Bitcoin wants to be widely accepted and scale in terms of impact and
+proliferation. It is not necessarily the only success case. Take the tor
+network for instance. It is extremely important and valuable for a small
+subset of people. That could be a possible endgame for the blockchain.
+It could be a small isolated community of people. I don't think that's
+what most people think here. They want it to scale. So when you think
+about scaling, you should look at the different things that have scaled
+and why they were able to scale.
+
+I was at a conference recently with Tim Berners-Lee. He got a question
+he always get. Why did you get it all away? Why not try to make money on
+the web standards? And we all kind of know the answer, but he said it
+eloquently: well, it wouldn't have become the standard if I had patented
+it and tried to make money. I put all the slashes there because that's
+how people worked with filesystems, and tags were for SGML and the
+markup community, but I was trying to design a standard that was most
+likely to be adopted, by not encumbering it with intellectual property,
+and trying to give it away. And the other part is that you had Tim. And
+on the internet you had John Pascal(?) with initial names and numbers.
+And you had Linus Torvalds that drew a line around the kernel and said
+what's in and out. Most of these communities have ways of making
+decisions and having core values.
+
+I think one of the things that is tricky is you either have a
+personality or it evolves over time. Pieces of the internet after John
+passed away, ICANN does not work perfectly but it sort of functions and
+it somehow allows the commercial and government interests... when I was
+on the board of ICANN, the governments are only advisors. They have an
+advisory committee. The government does not control ICANN. Nobody
+controls it. It's consensus (what?). It's able to protect the technical
+people from the financial interests. Engineering reasons win out.
+
+I think this is important, and I may be biased, but there are tremendous
+number of people who are highly technical but not motivated by money or
+government at all. The internet is not run by the government. A big
+chunk of the root nodes are crazy people that you have never heard
+about, because they are bale to attract technical talent that want to
+work on the right thing.
+
+I think that what's interesting is that as financial interests get
+involved in regulation, commerce, funding, it starts to skew the
+interests of people from doing it because it's right or correct, to
+doing it for other reasons. In places where the money has come in
+quickly and the technical people have run away, you see huge failures.
+Or in the worst cases where there wasn't any technical people in the
+first place. I think the government on the internet realized that it
+can't control it. It needs to depend on these non-commercial hippies at
+some level. They are okay with this idea at some level. They are not in
+charge. It took a lot of wrangling. I think technical people
+underestimate how important it is to cut deals with corporations and
+governments.
+
+The web and the internet was similar. Remember the bubble just
+before 2000. Late 90s. It was a mess. It was technically turning into
+crap. You had big companies. AOL merging with Time Warner. It was
+turning into a big pile of whatever. And it is interesting that after
+the crash, Douglas Roschoff said the stock price to before the internet
+existed. The market just said it's worth nothing, basically. Douglas
+called this the internet fending off an attack by the venture
+capitalists. Because that's kind of interesting. An attack. That's how
+we think about network robustness. I think that's how we should think
+about protecting this community and shepherding to technical things and
+getting technical things right.
+
+Right after the crash, you had blogs. Most blog software was written by
+people who were recently unemployed. They wanted to say stuff, so they
+wrote code. You had healthy stuff emerge after the crash because you
+didn't have money people to accelerate stuff. I am a venture capitalist
+and I invest, so I am not against business. There's a timing that is
+very important. As a startup, you should not take money if you don't
+know the direction. It's not a good thing. I distinctly remember there
+was a thing called the web two point oh summit that Tim O'Reilly used to
+run. It was trying to get people together after the bubble crashed and
+to talk about it. It was a cool conference. I can't remember which one.
+
+The fourth or fifth one, there were 2 sales people in front of me on an
+elevator. They had just joined their companies. They were trying to sell
+each other shit. I looked over and there was a trade floor of booths of
+people trying to sell people stuff. Great, some of my favorite companies
+exist, but my job is done here. I am going to move on. And they made
+money from me. But there is a phase that goes through when you have
+figured it out, then you hire the sales people and then they sell it to
+each other. I think the tricky part about Bitcoin is that everything
+happens at the same time. We're still trying to prove that the thing
+even works.
+
+I think the biggest risk right now is that the architecture of the
+community is not... we don't even have Linus Torvalds. What do you call
+in and out? I used to have these licenses at Creative Commons, anything
+that looked like CC but wasn't one was bad because it was a fork. So
+when you start to build the network you want to stamp out forks, but if
+you are in the innovation phase you want forks. I think we're in one of
+those periods where you can't tell whether forking is good and bad.
+Because people are already using it while we are still in the
+experimental phase. I think there's a tremendous amount of risk. We
+should think about how this architecture gets created. How does the
+community work?
+
+This is more of a question. I don't think it's ICANN. I think there's
+enough difference between internet and Bitcoin. There are many
+differences. I think we need to think about how to think about it.
+
+One of the things that I think is important, and which is why I like
+amiller's paper, you need a substantial chunk of people that everyone
+trusts to be involved not for commercial reasons but because you want to
+make things work properly. You don't know if they are being exploited,
+maybe they have conflicts of interest, maybe they work for the NSA,
+maybe you can build this trust. There is so much blurring because of so
+much venture capital money, it's hard to find a safe space.
+
+I want to end by proposing that everyone joins #bitcoin-wizards on
+freenode. I think academic institutions could help. I think this paper
+was Stanford and Princeton and maybe another one. What we are going to
+try to do is that MIT should also have a role to play here... I cannot
+officially announce, that we are starting to, we don't have a name for
+it yet, but we have a MIT cryptocurrency initiative, and .. we've had
+pieces and others working on Bitcoin stuff. I've met with central
+administration to go to Bitcoin a little bit broader. Simon Johnson who
+is a good economist joined this initiative. Ron Rivest, a great
+cryptographer, so what we are going to try to do is draw upon well known
+neutral players who do not have a stake in Bitcoin to try to think about
+the economics and the technical aspects of Bitcoin. I know about the
+policy side, yes that's there too. I think at the beginning that the
+academic institutions should serve as a place for people to hang out. We
+will also be reaching out to other people. Brian/Bryan who just.. he was
+at the whitehouse originally, but he wrote the internal whitehouse memo
+on Bitcoin. Now he is the project manager to pull the resources together
+at MIT. If you want to get involved, talk with him. To finish by cycling
+back to the security discussion.
+
+I do think that real security, not security for just our friends, but
+from our friends and others when we talk about true trustless networks.
+Well that requires hardware that we can really trust. I think that's
+another area that we should start working on at MIT because we can sort
+of justify saying we are going to try to research pure security without
+making it sound like we're cypherpunks afraid of black helicopters.
+
+So anyway, that is what we would like to do. Anybody who would like to
+be more involved, I would like to coordinate. That's a new project that
+we will be starting. Thanks everyone for coming.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/url.txt b/__transcripts__/mit-bitcoin-expo-2015/url.txt
new file mode 100644
index 0000000..82930c0
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/url.txt
@@ -0,0 +1,12 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Url.Txt
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %}
+ Transcript by: {{ page.transcript_by }}
+{% endif %}
+https://www.youtube.com/watch?v=lIgjogLipvk
diff --git a/__transcripts__/mit-bitcoin-expo-2015/welcome.md b/__transcripts__/mit-bitcoin-expo-2015/welcome.md
new file mode 100644
index 0000000..91783f2
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/welcome.md
@@ -0,0 +1,34 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title: Welcome
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Welcome session
+
+
+
+- Jonathan Harvey Buschel
+- Jinglan Wang
+
+We are going to get started in about two minutes, so please take your
+seats. We are also testing the mic for the live stream. If you have
+friends who are not here, feel free to tweet them, email them or post
+their facebook page or instagram whatever.
+
+(buzzing/feedback continues)
+
+Hey. All y'all ready? Alright, awesome. My name is Jing, I am president
+of the Wossley Bitcoin Club.
+
+Last year we had over 500 attendees and we had the launch of the MIT
+Bitcoin project.
+
+What's different this year? We have two days full of speakers. We are
+trying to get more academic so that we can dive into the heart of
+cryptocurrency. We have Charlie Lee, the creator of Litecoin. He leads
+the product engineering team at Coinbase currently. Please join me in
+welcoming Charlie Lee.
diff --git a/__transcripts__/mit-bitcoin-expo-2015/zerocash-and-zero-knowledge-succint-arguments-of-knowledge-libsnark.md b/__transcripts__/mit-bitcoin-expo-2015/zerocash-and-zero-knowledge-succint-arguments-of-knowledge-libsnark.md
new file mode 100644
index 0000000..95ef427
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2015/zerocash-and-zero-knowledge-succint-arguments-of-knowledge-libsnark.md
@@ -0,0 +1,286 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2015
+title:
+ Zerocash And Zero Knowledge Succint Arguments Of Knowledge Libsnark
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Zero knowledge proofs and
+SNARKs and libsnark
+
+Madars Virza
+
+I am going to tell you about zerocash and our approach of addressing
+Bitcoin's privacy problem. All of this is joint work with Techion, ETCH
+Zurich, and MIT, and Matt Green, .. and .. and..
+
+So first to get us going, I want to talk a little bit about two of my
+ideas around Bitcoin. There are two questions that every decentralized
+cryptocurrency must answer. First of them is where does the money come
+from. The second question is, if money is digital, if I have my digital
+$1 bill, can I copy it? What prevents it from double spending?
+
+Bitcoin has answers to both of them. Money comes from work for solving
+hard puzzles. Double spending is prevented by using a public consensus
+protocol that uses puzzles. It maintains a public ledger. This ledger
+has sparked tremendous innovation.
+
+If you have a public ledger, it is easy to track whether you are double
+spending. This innovation is also a liability for Bitcoin. Because it
+presents a privacy issue. Bitcoin is not really anonymous. A simplified
+example is the blockchain where you see a "from" address and a to
+address and amount. All transactions will be there forever.
+
+People may say, "those are just addresses" and "what can you get from
+them". It's true that it is not a first or last name. But it is just
+like a nickname. By design, those who you interact with know thos
+eaddresses. Anyone else can mine the ledger.
+
+There has been extensive academic work of doing just that. You might say
+that the academic work is not really there. Methods of analysis get
+stronger as time goes by. But your history will be saved forever. This
+is like something you see in the news.
+
+You might say it's not private, do we care? My answer is yes, because
+there are serious consequences for the Bitcoin economy. It limits
+adoption because consumers have purchases visible to everyone. If a
+United States merchants decides to go all Bitcoin, then their cashflow
+is exposed to competitors. Even more so, it threatens the Bitcoin
+economy because it's a threat to fungibility. Say I go to a coffee shop
+and get change, but it happens to be stolen from MtGox, it has now
+tainted my wallet. Maybe sometime later they will stop accepting my
+Bitcoin because of that.
+
+For many users, Bitcoin is in a sense worse than a bank. In a regular
+currency you leave everything to a bank. Do you have to reveal
+everything to everyone? We think no.
+
+Our goal is to preserve privacy and also have decentralization. Our
+result is zerocash. We can sit on top of any ledger system. You can have
+zerocash for Bitcoin or even for Litecoin. It provably hides all
+metadata about all transactions. Unlike previous approaches, zerocash is
+also efficient. Transactions are small, easy to produce and easy to
+verify.
+
+We have essentially what I would call a perfect system. Nothing comes
+for free. There is a caveat. We need one-time trusted setup to generate
+public parameters for the system. And we need additional cryptographic
+assumptions. The trusted setup limitation can be removed, and I am going
+to talk about that later in the talk.
+
+Now, let's have like a 10k foot overview of how zerocash works. What it
+amounts to is how to ensure integrity when everything is hidden. You
+cannot just look at tihngs to ensure integrity, because there is nothing
+to look at. Let's say there's an Alice and a Bob, and Alice wants to
+send 10 coins to Bob. He wants to know whether it's valid. He can't look
+at the ledger.
+
+Alice knows for a fact tha tthe transaction is valid. She knows she got
+10 BTC from Carol. She knows she didn't spend them. Therefore the
+transaction must be valid. So she can send all of her books over to Bob.
+He can examine her entire financial history. Well, this is not private.
+This is what Bitcoin does though.
+
+We need to do better. Let's use a trusted accountant. Alice has access
+to a trusted account. She can send her books to the accountant, the
+accountant will look and say yes it checks out, and produce a signature
+that says the transaction you are about to receive is valid. Bob can
+look at that signature and be convinced.
+
+But where do you get such an accountant? Accountants are humans, they
+don't really scale to billions of transactions and real-time operation.
+We would like to somehow digitize this accountant and have it as a
+program with integrity you can computationally verify.
+
+You can imagine a virtual accountant in Alice's head that she presents
+all transactions to. Later we get cryptographic proof that this account
+accepted. We can post that proof on a ledger. And now Bob is happy. He
+gets his coins and he can prove those are really unspent. So his
+question goes away.
+
+From a high level, this is what zerocash does. We can produce public
+transactions with zero knowledge proofs. But what kind of proof do we
+need? There are many cryptographic proof systems.
+
+There must be proof. We also want this to be zero knowledge. Bob must
+not learn a nything about Alice's transaction history by examining the
+proof. It must be non-interactive, which means that Bob can verify the
+correctness without interacting with any accountant digital or real. It
+must be posted on the ledger. It must be succinct. Small and easy to
+verify. Finally, we want the cryptographic property known as
+proof-of-knowledge. We want to ensure that Alice knows the secret behind
+the transaction. What does it mean that there exists a signature? We
+want to know that Alice knows the signing key for such a signature.
+
+All of those properties when taken together are actually impossible. So
+we relax this from being a proof to being an argument. It holds if
+cryptography is not broken. If you take all of them together now, a
+succinct non-interactive proof of knowledge, called snark. This is call
+zkSNARK when put together.
+
+Having identified what we want, can we get it? In a beautiful line of
+early work by Killian92 and Mical92, Mical00, they are efficient enough
+to be implemented.
+
+PGHR13, BCGTV13, BCTV14b, KPPSST14, ZPK14, CFHKPKNPZ14, BCTV14,
+
+We chose one of those systems, libsnark, that we believe is best. Our
+implementation we chose is fast. It's also very versatile. It supports
+low-level concepts like circuits and high-level concepts like random
+access machines. It is MIT licensed.
+
+
+
+SNARK is just a tool. It will not be plug and play. A great deal of work
+goes into characterizing how do we use this tool to build an anonymous
+payment scheme? That's the main contribution of "SNARKS for C" paper.
+
+We need to introduce a notion of decentralized anonymous payments. These
+are specified by algorithms that specify some security properties.
+Everything is hidden, so we need to define them a new. The algorithms we
+need are setting up the parameters, for users to create addresses, mint
+coins, send them to other users, for miners to verify transactions, and
+if everything is hidden on the blockchain then we need an algorithm that
+scans the blockchain and receives your coins.
+
+The security requirements are those. We want these to be private. This
+must be ledger indistinguishability. Nothing revealed besides public
+information on the ledger, even by chosen-transaction adversary. This
+should hold even if the adversary can choose transactions.
+
+Since everything is hidden, we need to ensure balance. No money from
+thin air. You can only spend what you have minted or received. Finally,
+we need non-malleability, the transactions must not be modified while in
+route to the ledger.
+
+Now we can build up from an insecure scheme to something more secure,
+completely secure, then we can add functionality.
+
+Let's build a basic anonymous ecash. Our coins are going to be
+identified by serial numbers. What we need to integrate are coins in the
+Bitcoin ecosystem. So we add new transactions. One is minting, it uses
+up 1 BTC to create a coin with a specified serial number. And here they
+are. You can scan the ledger for them.
+
+How do you use this coin? Well that's spending. The semantics is using
+up a coin with a unique serial number, and a BTC appears in the result.
+This scheme is horribly broken in multiple ways. It is not private.
+Anyone can steal your coins. But it's a start. So let's try better.
+
+In 1999, Sander and Ta-Shma used the idea of commitment schemes that my
+coin is going to be identified by a coin commitment that commits to a
+serial number. The commitment scheme is like a hash function that
+essentially ensures two properties, that it is hard to go back from
+commitment to the serial number even if you know the, it's hard to go
+from commitment to serial number, and it's also hard to claim a
+different serial number with a different commitment randomness for the
+same coin commitment. Main thing will be, I hereby spend 1 BTC to create
+this anonymous coin with a coin commitment. And coin commitments are
+here, and spending a coin would mean I'm using up a coin with a unique
+serial number so that you can verify that I am not double spending. So
+here is the commitment and randomness. So you can check if it really was
+there. The scheme is again horribly insecure, but we have made some
+progress.
+
+So what ... proposes is to build a merkle tree over all coin
+commitments, and then you still reveal the unique serial number, but
+instead of revealing coin commitment and randomness, you prove in zero
+knowledge that you know them. That essentially unlinks the minting the
+coin from the act of spending the coin. Integrity is ensured under the
+seal of zero knowledge proof.
+
+This only supports single denomination. If I want to spend you 10 BTC, I
+will need 10 transactions. This is not hard to fix. Use iterated coin
+commitments where the outer one contains a value, the inner one contains
+serial number, and then you mint, you post publicly how much you want to
+spend in Bitcoin, then you post two values k and r to prove consistency
+but you don't post the serial number. To spend against, you post the
+coin value and that proves, and the serial number, and this proves that
+you know the coin is a hash tree that corresponded to it.
+
+You can go on. All transactions must go through the Bitcoin network. If
+you are totally unique values, and they will appear on the network, so
+we will add an additional thing, that users can send coins directly from
+one to another. To do that, we need to ensure that a coin after it is
+sent cannot be spent by the sender. So we are going to make a scheme
+where the serial number is unknown to the sender. There is going to be
+an address in public, and a secret key pair for every participant in the
+system. You can send to anyone's public key, but to spend it, someone
+needs to know the corresponding secret key to produce a serial number.
+Those secrets can be sent either out of band to send someone a coin, or
+posted encrypted to the ledger.
+
+So that takes care of direct paymetns. But that doesn't let you split
+coin apart or join two coins together. Or convert to Bitcoin after the
+fact.
+
+What we are going to introduce is a concept that unifies these notions.
+Pouring. Zerocash coins go out, two coins go out, and there's a public
+Bitcoin output that can be split up for a transaction fee or just going
+to the Bitcoin ledger. This algorithm needs to know what are the values,
+how you want to split it up, and what the destinations are. It will
+produce the correct coins and a proof that ensures the transaction was
+valid. That the blaances match out.
+
+What will be posted on the ledger is the serial numbers for the old
+coins, and commitments for the new coins, and the proof. Let's take a
+deep breath. So this covers most of the technical part. If you want more
+detail, this is in the paper. This is actually a simplified version of
+our construction.
+
+So a nice theoretical construction, but can it be implemented? Yes, we
+did implement it. We started from libsnark, we integrated with bitcoind,
+we made libzerocash. We found out that the preformance for our clients
+is good and that the latency in block propagation time is negligble. So
+it really works.
+
+However, I will address this caveat of this trusted setup. So what is
+this? Our zkSNARK trusted setup is for initial public parameters of the
+system. It only happens at genesis time. After that, no trust is
+required in the system ever. However, if the trusted setup is
+compromised, then an attacker can fake new coins and could totally trash
+your economy. An attacker cannot break your anonymity or steal your
+coins. That said, we would like to get rid of trusted setup.
+
+There is a paper by some of us which will be appearing soon (BCGTV15)
+where we propose a multi-party protocol for sampling the parameters.
+Efficient MPC protocol. If just one is honest, then parameters are going
+to be completely secure, meaning that an attacker needs to compromise
+every single one of the participants presumably on the different
+continents, to break the setup assumptions.
+
+Another way around trusted setup is using PCP (probabilistically
+checkable proofs), but this is a topic for a different talk.
+(Multi-party computation?)
+
+Yesterday we saw this wonderful table by Charlie Lee that gratefully
+allowed me to reproduce it here, thank you. Zerocash is everything that
+Bitcoin is, in those terms, plus the fungibility issue is solved. So
+maybe zerocash is the perfect currency.
+
+You can go beyond privacy and fungibility. You can use zero knowledge to
+get more public oversight. The current statements we are proving is
+stuff like the balances match but I wont tell you more. Zerocash stops
+here, but you can extend it. You can prove to you that the money went to
+a non-profit. I am not going to tell anyone which non-profit it was.
+
+Public oversight example: I know the private keys that control a large
+amount of Bitcoin, but I am not going to tell you which address. This is
+an interesting public policy question. Which policies are feasible and
+which ones are desirable?
+
+To wrap-up, our approach is we have our whitepaper
+there. The zkSNARK library is from
+
+We were wondering what's next for zerocash. So we needed to solve this
+annoying trusted setup problem. We think we have this down now. The next
+thing is to just to deploy. Thank you.
+
+Questions:
+
+- what do you think of libsnark?
+
+
diff --git a/__transcripts__/mit-bitcoin-expo-2016/_index.md b/__transcripts__/mit-bitcoin-expo-2016/_index.md
new file mode 100644
index 0000000..d2352bb
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/_index.md
@@ -0,0 +1,7 @@
+---
+layout: default
+has_children: true
+title: Mit Bitcoin Expo 2016
+---
+
+{{< childpages >}}
diff --git a/__transcripts__/mit-bitcoin-expo-2016/cory-fields.md b/__transcripts__/mit-bitcoin-expo-2016/cory-fields.md
new file mode 100644
index 0000000..1006d4b
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/cory-fields.md
@@ -0,0 +1,159 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Cory Fields
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} MIT Bitcoin Expo 2016
+transcript
+
+last year- http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2015/ this
+year- http://diyhpl.us/wiki/transcripts/mit-bitcoin-expo-2016/
+
+Welcome everyone to MIT Bitcoin Expo 2016. If you haven't heard of
+Bitcoin by now, then I am not sure how you got here. My name is nchinda.
+I am the reigning Bitcoin club president. I am going to have some fun.
+The club is hijacking the #mit-dci IRC channel. You can twitter with
+#mitbitcoinexpo. There's a link up on our website for livestreaming. You
+can refer anyone who is not here to the club's youtube channel.
+
+We are going to begin day 1, the technical day of the expo. We are going
+to start with Cory Fields, a Bitcoin developer, he works here at the MIT
+Media Lab. (applause)
+
+Thank you Nchinda. I am a Bitcoin Core developer. I would like to open
+this morning by talking about what it means to be a Bitcoin Core
+developer. What is Bitcoin Core? Who here is actively involved in
+Bitcoin? Who keeps up with current events and drama? Okay. There's not a
+lack of that. So I will try to avoid sensitive subjects, so I will have
+about 10 seconds of material.
+
+Bitcoin Core, I think it's three things. I want to talk about it because
+I think it's worth with all the kind of strife in the community and the
+perceptions out there, I think it's worth trying to distill down, when
+the discussion comes down to different factions or groups or who thinks
+what, one of the things we hear pretty often is that "Bitcoin Core is
+this" or "Bitcoin Core is doing X". And I think we should step back and
+look at what this means. How has it evolved to the point where Bitcoin
+Core has meaning?
+
+To me, it's three things. Bitcoin Core is a software project. That's all
+it is at its essence. I am sure that you guys are familiar with what an
+open source software project. It's probably not interesting and it's not
+fun dinner conversation. But to you especially, it's the most
+interesting thing in the world. That's my entrypoint for Bitcoin. For
+me, the way that I came into it, is that I read some article about this
+new money thing that, a virtual currency that is software. You can take
+the software and run it but it's also money. That's a concept that at
+the time made no sense to me. Reading around, trying to get an
+explanation, my gut reaction was oh there's code, I'll look at the cde,
+I';ll clone the repo and try to build and it didn't build. At that
+point, it wasn't building and it wasn't running, so my entrypoint for
+working on Bitcoin was helping out with the build system, making it run,
+making it more accessible.
+
+When the term "Bitcoin Core" is used, it's also used to mean a group of
+developers who work on the Bitcoin Core project. It came devolve from
+there because just like any other project, so, show of hands, who here
+has contributed to an open source project? Okay, about the same. A herd
+mentality evolves at some point. There has to be a release. There has to
+be a roadmap. There has to be some sort of collective idea of what we're
+working towards. Bitcoin Core is no different.
+
+Where it's really different is in the third definition of what Bitcoin
+Core is and what it is. How many times have I said Bitcoin Core? It's a
+reference implementation of the Bitcoin protocol. And that's where it
+breaks all the rules of social, or all the social norms for a software
+project because at that point, it's in some ways the definition of a
+principle. Or it even embodies this living breathing system, so it's a
+weird overlap there.
+
+What we started to see online is not to say a lack of understanding, but
+a blur of the lines when we're trying to make decisions amongst
+ourselves and you want to purport to have some authority or want to
+purport to have some stake in the system. So it makes sense to come
+together and say this is what this enlightened group thinks r what this
+powerful group thinks or what this rich group thinks. At that point,
+trying to say we are Bitcoin Core becomes contentious and dangerous
+because you don't want to speak for someone else's principles or morals.
+That's a hard thing to do.
+
+So we find ourselves to an extent, unable to speak up for ourselves.
+That's a weird spot to be put in. I think it's worth being conscious of,
+and aware of, and when we are online discussing different possible
+solutions to things, it's worth discussing the context they are in. Am I
+proposing this solution and also demanding everyone runs it? Because the
+other very unique engineering challenge of Bitcoin is that it's a social
+consensus mechanism. It's not just a technical consensus mechanism. What
+matters is that it agrees with itself. I think it's interesting to take
+a step back every now and then and look at where maybe how we can work
+to improve that social layer. Because when, I was hoping to give a
+little bit of a, what's changed what's changed in the last year.
+
+I was at the Bitcoin Foundation before. I work at the MIT Media Lab at
+the moment. I am privileged to be working on Bitcoin day-to-day here. In
+2014, I went to the .. conference... my eyes were so big, I had just
+joined the foundation, there was a big conference, everything was real,
+there were financial people there, technical people there, investors, it
+was this wide range of people. And gavinandresen was there, he gave a
+State of Bitcoin at the moment, it was technical and it was thriving and
+it was fun and I think it's very much the same way now. In the last year
+or so, one of the big shifts we have seen is that Bitcoin has gotten
+social. Not only that, but the development process of Bitcoin has gone
+social in that, you know that you have a beautifully constructed safe
+system when the designers of the system can't change it even if they
+want to. This is not just a Bitcoin concept. Even if you have tested
+with mining.. it's fun to try to attack your own system and realize that
+you can't beat it. That's a uniquely Bitcoin thing.
+
+The social element is what's new, where there's this influx of people
+who wish to change and influence and improve the system but end up in
+gridlock because ultimately it's a measure of who can agree the best and
+who can agree the most. So I'd like to take one more minute to give a
+rundown of how that process works from the Bitcoin Core side and then
+for Bitcoin as a whole.
+
+The Bitcoin Core developers for the most part, for some of them, the
+technical and research talent for the Bitcoin ecosystem is tied up in
+Bitcoin Core as the reference implementation. It's where people gather
+and congregate. Naturally, proposals to change and improve come from
+there. Historically in the past what we have seen is that not really all
+that much interest. There have been things that need to be done, Bitcoin
+Core developers say stuff, and then it happens, and it wasn't hard. As
+the group has grown and there has been more interest, it gets harder to
+say this is what is technically correct and this is what we're doing. We
+get pushback because it maybe doesn't fit well with a particular profit
+model, or a difference of opinion for long-term goals, that kind of
+thing.
+
+So the big process was put in place, there was the Bitcoin Improvement
+Proposal process (BIPs). It was modeled after the python improvement
+process, which is a proposal to improve Bitcoin community-wide. That
+process has proven to be successful for the most part. It has begun to
+break down a little bit. As people participate outside of Bitcoin Core
+and the typical process, they are not necessarily beholden to that same
+process anymore. It's really worth thinking about how, and I as I have
+been thinking about what to try to say, over the last few days, I was
+hoping to propose a more rational way to come together. I have spoken
+with many people who have a pipe dream about a non-Core driven, a more
+community-driven process for changing Bitcoin. And sadly I don't have an
+answer for how to fix all of Bitcoin. It would save us a lot of argument
+and infighting.
+
+We had the scaling events, one in Montreal and one in Hong Kong, thanks
+to Pindar who is here today. After a lot of reflection, my realization
+is that Bitcoin healthier than ever in that everything is contentious
+and hard. It sounds weird, it sounds a little stupid. When you consider
+that it's a system that has been designed to resist change, to resist
+hostile takeover, to resist influence, the fact that it's doing that so
+well right now, is a sign of its health. Reddit loves to say "it's good
+for Bitcoin". I think that fighting is good for Bitcoin. The level of
+discourse, well it's arguable that the level of discourse has been
+good... if the fighting stops, if it becomes easy to push through a
+hard-fork, a difficult change, a major change, then at that point we
+know we have lost and it's not an interesting system anymore. If it's
+that easy to manipulate, then it's not worth working on this. I don't
+want to say let's keep fighting, but let's keep fighting.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/fraud-proofs-petertodd.md b/__transcripts__/mit-bitcoin-expo-2016/fraud-proofs-petertodd.md
new file mode 100644
index 0000000..572953a
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/fraud-proofs-petertodd.md
@@ -0,0 +1,189 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Fraud Proofs Petertodd
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Fraud proofs
+
+petertodd
+
+https://www.youtube.com/watch?v=UVuUZm4l-ss&t=4h29m10s
+
+In Bitcoin we have made this tradeoff where we don't have everyone
+running full nodes. Not everyone is participating equally. If you have a
+full node, you have lots of gigs of hard drive space, but if you do
+that, you only get a few transactions per second. Modularizing
+validation an argument for this is how to improve on this situation.
+
+What's the problem we are trying to solve? This is a real screenshot
+from one of the Android wallets. What this shows is that the SPV client
+will believe anything that miners or servers tell them. I don't really
+own 21 million BTC. All I did to make it think this, was to send it a
+transaction with 21 million BTC on the outputs. My lite client would
+have accepted this as valid if it were mined.
+
+Tihs was a trust failure. This phone would have trusted this. Lite
+clients expect that this error gets caught. When you go back to the
+original Satoshi whitepaper, when he talked about Simplified Payment
+Verification, which is instead of checking everything you check only
+some of the transactions, one strategy would be users accepting alerts
+from network nodes. A lot of people in the Bitcoin world didn't notice
+that at the first, but they thought about the idea of warning someone
+that something is invalid. Maybe hang on, this part of the blockchain is
+rejected, so move on to the next work chain I see, because that might be
+the valid one. The most work most valid chain is the chain that is
+valid, or rather, not most valid but valid is boolean.
+
+How do we know a transaction is valid? I copy and pasted this out of the
+Bitcoin Core source code. I'll simplify this. Why don't we go and, he
+talked about a rule that says given that the coin limit is 21 million
+BTC, surely we should not allow a transaction that creates more than 21
+million BTC. That's solid evidence that the transaction is invalid. This
+rule is enforced. That's why I had to use 2.1 million BTC, not 21
+million BTC. "Are you creating more coins than exist?". It can validate
+that one, but not the next thing, which was to go say, the amount of
+coins going into the transaction, is greater than the ..... yu can see I
+just made a mistake there. It's the number of transactions going into
+the transaction, versus transactions going out of the ... apparently I
+like inflation in my protocol rules (laughter). If you have this rule
+that's great, we can go enforce it, what's a valid transaction,
+obviously I am over-simplifying a heck of a lot. Let's go work with
+this. How could you make this usable? If I could have this, I could put
+it into my lite clients and use it. Given that the transaction would be
+large, maybe I would want a functional style to validate things in
+parallel. Once you are at that part, what kind of mathematical operation
+are you checking? Are we making money out of thin air?
+
+When you look at it, the equation you are running is looking like a
+tree. We are going down the inputs and outputs of a transaction. We are
+adding them all up, at every point, does the function equal true? For
+some, is it natural sum? We can store this as, we can do hashes of this
+data. I think Andrew Miller was the first person to work on this,
+originally having the idea of merkle sum trees. If I take every step of
+that computation and hash them into a tree, I have a record of this
+computation which is in this case one sided addition. If I bring this as
+a whole transaction, I have my inputs, I have my outputs, I have this
+rule here at the top, and I can go say, is this transaction valid. What
+if it isn't? What if somewhere there we create money out of thin air? In
+this case, I got the order of this right, and apparently money out of
+thin air is a valid thing. I can identify the problem, since this is all
+hash, I can now go and delete all the bits that are valid.
+
+So if I go give my phone a copy of this invalid transaction that it
+knows about that transaction, alright let's walk down, oh hang on that
+sum didn't work, well, obviously that means the rest of the transaction
+is invalid, therefore I know to reject any transaction that includes
+that and claims its valid, like a block maybe. This could be compact,
+maybe a kilobyte of data. If we structure this in the right way, we can
+maybe implement the alerts that Satoshi was talking about.
+
+What's neat about this is that when we send data on the wire protocol,
+we can apply something that looks like compression. You don't need to
+save the intermediate steps. You just need to give people the data at
+the bottom. You are not using up any more bandwidth moving the data
+around. This is something you can use for the clients that supported it.
+
+That sounded good. If we did this, we would have lite clients that
+wouldn't have to validate anything, they could go to their peers, we
+could scale Bitcoin up indefinitely. I have done some research into how
+we would do this. I have gone into a tremendous amount of detail. Some
+of them are more technical, like how do you commit to a list of
+committed coins that have been spent or unspent. This commitment
+structure raises a lot of scalability issues. One of the tradeoffs we
+would have to make is that given that a transaction is processed
+atomically, if all inputs are spent in one go, maybe you would split
+that up and get more parallelism by getting rid of those atomic updates
+in the protocol. By comparison, that's technical minutatia. Does this
+actually work?
+
+In a decentralized system, can we pull this off? What if you have
+missing data? Presumably, we are trying to use this technique to let us
+go split the blockchain across different nodes. But this is a
+decentralized network, someone can sybil attack hte network. You don't
+have a good way of ensuring that someone out there has the data in
+total. You just happen to see whatever data people are telling you
+about. If I can create money out of thin air, as a miner why would I
+give anyone that evidence? Why wouldn't I just leave that data out?
+
+This could apply to transactions, sure. If you look at the transaction,
+if it's valid but it spends money that was invalid a step back, it's not
+clear how to force the issue. One approach that might work is a validity
+challenge. If you remember back when we tried to determine if data was
+invalid, we can apply the same trick, we can say I suspect the node in
+this tree is invalid, I don't have data to prove it, please reply with
+proof, I will assume that stuff I can't see is invalid, therefore I will
+reject that block.
+
+So you can imagine a system where nodes would collaboratively look for
+places where the challenges are missing or something. Does this work? If
+that did work, this is a problem because then I can go to your node,
+feed oyu validity challenges, and then you would shut down until you
+have the data again. This doesn't scale well, because you need all the
+data to accept the block.
+
+I don't know how to solve this. In a centralized environment, if this
+was a bunch of banks running the blockchain, we can use legal structures
+to figure out who validates what, maybe Bank of America validates all
+transactions starting with 1, and Citibank starts validating all
+transactions starting with 0. But this only works in a centralized
+environment.
+
+I have done a fair bit of fintech work. I was even employed by R3. Even
+in that environment, the tech shows some promise, it could be
+interesting research avenue, does this work in Bitcoin though? It's not
+really clear.
+
+Another issue is censorship. I can go prove that data is valid. But we
+have another problem which is that I would like to prove that data is
+being censored. From the point of view of a miner, they might have
+honestly not seen a transaction they didn't include. Why didn't they
+include a transaction? There's no solid evidence of wrongdoing there.
+They just didn't see your transaction quite likely. If they continued to
+not mine your transaction, as a human being I could probably come to
+some kind of agreement that it was a bit suspicious that some donations
+to Trump are going through or something, but not to Clinton. But I can't
+write a computer program that does this. It's not a trivial problem. You
+can see in general that proof-of-work is evidence that things have been
+published, that something got to an audience.
+
+So maybe you add another proof-of-work layer into this, to insert
+transactions into the upper blockchain to prove that they should be in
+shards or lower-levels. But how many layers are we going to add to this?
+I don't want blockchains within blockchains or whatever. I'm not sure
+where this is going to go.
+
+This systematic process of looking at these rules in detail, if we can't
+scale or whatever, we can at least get a good understanding of what the
+protocol really is. I have also looked at scriptpubkey, this
+program-based process for deciding transaction validation authorization
+and signing, and applying this to cryptography in general, like maybe
+multi-party multi-key thing to sing my emails.
+
+This same approach for scriptpubkey can be applied to validity rules. So
+at worst we might have a more understandable system, but I don't know if
+we can do better than that.
+
+Q: Normally, you would have this in, connections so, it's hard to, ...
+
+A: So, the real question is who do they trust? If we are talking about
+electrum, which will only talk to peers that it knows about. Electrum
+comes with a list of nodes, like using SSL certs saying this is an
+electrum server, I know who runs it, and then I connect to 10 others.
+That's a simple trust model. It's not very decentralized. It's not the
+dream that Mike Hearn has for making SPV work in a decentralized manner.
+Bitcoinj on the other hand will connect to people at random, that
+connecting to 1000 different Bitcoin nodes will probably find a most
+work Bitcoin blockchain tip. How do you show it's honest? Well when I
+was doing that attack to show that bitcoinj thought I had sent 2.1
+million BTC, well, if I wanted to do this, it would be cheap for me to
+spin up nodes. Bitcoin Classic is doing this right now to try to show
+their support. If I have a financial incentive, like making money out of
+thin air, which I can do from the point of view of someone who aren't
+running a full node, well I can see that attack working. What about
+uploading illegal data to make running a full node more dangerous? It's
+not clear where any of this goes. We'll see as these attacks develop.
+Right now, under many scenarios, it's very easy.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/lessons-for-bitcoin-from-150-years-of-decentralization.md b/__transcripts__/mit-bitcoin-expo-2016/lessons-for-bitcoin-from-150-years-of-decentralization.md
new file mode 100644
index 0000000..c190744
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/lessons-for-bitcoin-from-150-years-of-decentralization.md
@@ -0,0 +1,353 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Lessons For Bitcoin From 150 Years Of Decentralization
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Lessons for Bitcoin from the
+150-year History of Decentralization
+
+Arvind Narayanan
+
+Lessons for Bitcoin from the 150-year History of Decentralization
+
+Arvind Narayanan (twitter- random_walker) Princeton University
+
+Another 30 seconds. Take your seats. We have Arvind Narayanan. Some of
+the research from Princeton has rivaled the work of MIT. Professor
+Narayanan is going to teach us some lessons for Bitcoin.
+
+Thank you. Can you hear me? I think you can. What I want to do today is
+to look at lessons from history for the future of Bitcoin, the next 10
+years for Bitcoin, the next 30 years for Bitcoin. Why am I doing this?
+Why does it make sense to talk about the far future at a time when we're
+at a crisis for the community?
+
+At this time it makes a lot of sense to look at the past and at the
+future. It helps to know that the future is bright for crypto tech. It
+can give us a sense of perspective and to help look past our immediate
+differences. I am doing this because I can, I'm an academic and I have
+the luxury of looking at long-term issues. I have no particular opinion
+on the scaling debate. If I offend you, I apologize in advance, but I
+hope you will forgive me.
+
+We did an online course on Bitcoin, with 30,000 attendees. We also made
+a textbook. It's been a pleasure to contribute to the community. Let me
+give a quick perspective of the long-term view of bitcoin. You might be
+familiar with the production lifecycle. Initially there is some
+motivation trigger, then a bunch of peaking around hype, and then the
+bubble, and then the trough of disillusionisment and then there's a
+plateau of connectivity. I think this fits Bitcoin's trajectory pretty
+well, we're somewhere in the trough of disillusionment, we have not hit
+rock bottom yet. I am going to make some recommendations.
+
+Right now, I would say we are in the trough of disillusionment. If you
+are playing this game, play the long game or don't play at all. We
+haven't hit bottom yet. There are still some things that are pretty
+hyped and for which the hype is going to deflate a little bit. I think
+there's always a pet example for everyone.
+
+"private blockchain" is a confusing name for a shared database. I would
+be happy to debate this later. If you look at bitcoin and take away the
+currency and take away proof-of-work, you have a shared database. This
+is not to say, by the way, that all the private blockchain stuff is
+bogus, I think there's a lot of value there, it's because they are
+finding a lot of value in shared database though. In some cases that
+tech hasn't been deployed yet, that's why they are finding value in
+shared databases.
+
+I find the linguistic connotations very interesting. Sometimes when
+something gets hyped, it reflects in the language that we use. From a
+grammatical perspective, how do you explain blockchain? I have been
+seeing people saying "I love blockchain". People are telling me that the
+blockchain is the best thing that ever happened to them. Maybe they are
+using it as a proper noun. I have heard that there is a Church of
+Blockchain in Brazil. Some of them believe this in all sincerity, like
+"I love Jesus". I find this very curious. I would say that someone
+reddit has a joinder to this, what's ultimately a data structure has
+taken an auroa around it... blockchains are going to revolution finance,
+is like saying an array will revolutionize finance. Dilbert at this
+point has done some blockchain spoofs, at this point. So there's a
+certain level of hype.
+
+So let's clock back and look at the old history. Let's dial the clock
+back to the year 1900. This was Scientific American. I read this article
+and this whole March 1900 addition... it was interesting to look back,
+it's the one on the left about a cheap telephone system for farmers. Why
+am I talking about this? By the way the other technological issues at
+the time, on this page, was about cutting threads.
+
+So this picture is showing someone installing a DIY telephone system
+using barbed wire. You have a pair of farmers connecting themselves
+before the phone company would do it. How is this relevant to Bitcoin?
+Well what was happening here is that it was the start of the movement
+that was rejecting the top-down centralist planned telephone system of
+the Bell telephone company. This was a DIY open decentralized movement.
+Initially it was pairs of farmers, and then it was little groups of
+small towns and farmers. This coalesced into small companies that
+provided services to specific areas, which later turned into bigger
+companies.
+
+There was a variety of technologies. There's a conflict of these two
+ways of doing this. Centralization and decentralized. There was a
+phoneommenal book called The Master Switch, by Tim Wu. He looked at
+telephony, radio, film and television. He showed amazing similarities
+between all of them. In each case he illustrated the tension between
+centralization and decentralization. He looked at open/closed primarily,
+but there's a strong correlation to what we're talking about today.
+There are lessons all over the place that we can apply to Bitcoin, but
+also for communication technologies that we are building today.
+
+Looking at the history of these technologies has a lot to teach us. I
+would recommend this book to any Bitcoin entrepreneur. How does one
+paradigm come to dominate over another? That's an interesting historical
+question, and I would point to that book.
+
+But here's a more specific lesson. Let's look at the evolution of
+Bitcoin mining from CPU desktop mining, progressing to GPUs which
+required expertise, then FPGAs which required even more expertise, and
+then ASICs where only well-funded corporations can do this. What does
+this have a historical parallel to? It has a historical parallel to
+actual gold mining, starting with mining by individuals, then sluice
+box, then placer mining, then pit mining which requires a large
+corporation.
+
+I wanted to point out that this progression has happened over and over
+again. Centralization has powerful economics behind it. If as an
+entrepreneur you are interested in challenging this, then I would say
+don't fight it head-on. First of all, let me say, there are two reasons
+why centralization has economics behind it. One is economies of scale.
+There is also another less obvious reason, in a centralized paradigm you
+are capturing as a company more of the economic value that you provide,
+compared to a decentralized paradigm. The forces aligned behind
+decentralization tend to not be as coordinated. They have a coordination
+problem to solve. Over and over again we have shown that trying to fight
+centralization head-on, doesn't work. Even though I showed those farmers
+and that inspiring story, it didn't work, it worked for a while but then
+Bell realized there was an interesting business opportunity there and
+then they crushed them.
+
+Over and over again we see that decentralization doesn't work. This is
+similar to how the Internet disrupted newspapers. The Internet was
+initially dismissed as a toy. It would have no made sense for Internet
+pioneers to say buy a computer in the 70s because one day you would read
+a newsletter. The product initially starts as unrecognizable as what it
+would eventually become. You don't set out trying to destroy newspapers,
+it would have made no sense at all. Disruption has a specific meaning.
+Clay Shirky talked about this, a product starts as a toy, then evolves
+into something you couldn't have predicted at the time. Disruption is a
+word that we are using as a proxy for competition. It also has a
+specific technical meaning which I have pointed out.
+
+I see entrepreneurs talking about disrupting industry X. This is bound
+to fail, because it's not disruption. If you look at Clay's book, you
+find that you are building a product that industry X is going to be able
+to see. They will have way more time to get on top of that, they will be
+able to compete against you and see it coming. This might seem abstract.
+
+Let me give you a concrete example. In the Bitcoin ecosystem, I see
+attempts to compete against well established ways of doing things.
+What's missing is a user story. Our vision is good. But we need a user
+story analogous to microcomputers, it wasn't the future of reading
+newspapers that appealed to people, it was playing video games for
+example.
+
+We wrote a paper about this case study, one of them is namecoin. It's an
+altcoin. It starts with a simple idea. Namecoin says we can treat a
+blockchain as the key value store, it's a censorship-resistance
+key-value store. These keys that map values, if you consider the keys as
+domain names, and the value as IP addresses, what do you get? You have a
+decentralized censorship-resistant system alternative to DNS, except
+that miners can censor on the plaintext transaction details. The idea
+that you can take this and disrupt DNS, it doesn't work. We did a whole
+study of this ecosystem for Namecoin.
+
+If you have this public key-value store, with domains mapping to IP
+addresses, you can download this whole thing, you can crawl the whole
+namecoin web. We did that. My grad students and I did that. "An
+empirical study of Namecoin and lessons ..." Namecoin is a total ghost
+time. This was a time when it's market cap in terms of the currency was
+hundreds of millions of dollars. This was when there was a huge amount
+of hype around namecoin. We looked at the 200,000 names that had been
+registered. We eliminated a lot of them for being squatters that were
+unused. And then we were left with just 700 names. And then we filtered
+for non-trivial content, as opposed to just expired names or redundant
+content or things like that. We are left with a mere 28 names out of
+200,000. These had actual content and were non-trivial content. We
+didn't expect to find this.
+
+This is a pattern we keep seeing, it's solutions looking for a problem.
+You had a vision of disrupting DNS, but there was no reason for users to
+adopt decentralized DNS. When you think about the problems that people
+are facing with DNS, it's simply not a pain point. People aren't
+clamoring for decentralized DNS at the moment. They were solving a
+non-problem. There's one point I want to make, it's that it's great to
+have a vision of decentralized DNS. But what it's good for is that it
+convinces developers to show up. The only story you can tell users is,
+hey look because we are decentralized we have managed to build lots of
+features that our centralized competitors can't match. That's something
+that I'm not seeing in a lot of Bitcoin blockchains today.
+Decentralization is great for getting developers, but what do you tell
+the users?
+
+So what are some approaches going forward? I am talking about a long
+time horizon. I will have some hopefully interesting suggesitons even if
+you have a short time window. One point I would like to make is that, in
+the process of writing our textbook, I have discovered that there are so
+much tech or ideas that have been invented in the space of crypto
+systems, there haven't been people trying to think about user stories.
+There are a lot of opportunities to look at the tech. The ideas that we
+see in the industry is only like 10% of the broader community of people
+for ... let me just give you one example, this was from Greg Maxwell.
+They managed to complete something called a zero-knowledge contingent
+people. This is a screenshot of the blog post.
+
+It's a really cool idea where Alice has some secret, it's some
+information of economic value. And Bob wants to purchase this
+information. Bob doesn't want Alice to put it up publicly on the web.
+Bob wants Alice to send him this information and then pay her for it.
+Here's the magic. The magic that Bitcoin enables is that you can make
+sure that Bob's payment to Alice goes through if and only if Bob
+correctly receives that secret from Alice. So what you have achieved
+through that simple technological protocol is an information market
+without a trusted mediator. As gmaxwell explains, it's like a movie
+style briefcase swap except you can do it safely securely over the
+internet with anonymous parties and total anonymity and total
+decentralization. Is there a user story here? I don't know, I think we
+need people thinking about this.
+
+I will make a plug for our own Coursera course here. We have 30,000
+students so far. We talk a lot about technical ideas there where many
+have been commercialized but others that people are not paying attention
+to. It's somewhat self-serving, but I'll suggest it will be fruitful for
+the community to build more bridges for academia. I have been part of
+this. It has been very fruitful and we share a bunch of ideas, it needs
+to happen more.
+
+I have to tell you a story. The reason why I got into Bitcoin. It seems
+ironic to say this. I have always been uncomfortable with academia, the
+very slow and inefficient ways of writing papers and distributing them
+in an obscure language that nobody understands. When Bitcoin came along,
+ideas were freely exchanged on forums and bitcointalk and stuff, and
+people building on that. I wanted to be a part of that. That's why I got
+interested in bitcoin. Super ironically, through this engagement, I've
+become more convinced that academia brings a lot of value here.
+
+A lot of academic papers from a few years ago were crap, they didn't
+understand Bitcoin. But lately there's a much higher quality. There's a
+more vibrant interexchange between academic and the broader Bitcoin
+community. I realized there is a reason for the academic discourse going
+up. I realized that academia scales better. The scaling of knowledge
+production works better in academia. I have read about the history of
+academia, and the reason for why we do this the way we do with papers,
+the reason for writing papers is that you end up with this knowledge
+craft consisting of millions of papers, but because of the rigor of
+this, the citation graph is a good way to maintain pointers between all
+this information and build one piece of knowledge on another. It gives
+us a way to stand on the shoulders of giant. I saw this in the work that
+Bryan Bishop did, leading up to the Scaling Bitcoin post. He said there
+has already been 400 posts on scaling bitcoin. They were talking over
+each other. So he as an individual read all of them and extracted what
+turned out to be 6 ideas that were the common threads on that. These
+clusters of ideas fall out of the citation graph, there's an automatic
+error process. Three's an automatic process of tracing ideas back to
+their roots. So anyway, the summary of that is that I think academia has
+a lot of things to contribute to the exchange here, and I would look
+forward to deeper ties between Bitcoin and academia.
+
+Specifically, one problem where I think academics have contributed a
+lot, and also Bitcoin community, for doing more work in the future. That
+is, what I call, human crypto interaction. It's a delibarte play on
+human computer interaction. This is one of the most unsolved problems.
+Because of human cognitive limitations, we completely suck at
+maintaining and understanding private keys. It's been a disaster. Even
+before Bitcoin it's been a disaster. If you were a company or enterprise
+and trying to have end users and certs and private keys, well in Bitcoin
+it has been the reason for many thefts and so on. From company
+commercially, etc... We did something called threshold signatures, which
+is what I spoke at MIT Bitcoin Expo 2015. We put out prototype code.
+There was also "Bitcoin vaults" which is an interesting idea. There are
+a lot of ways to solve this problem. If we solve this, the impacts are
+going to be far beyond the Bitcoin space itself.
+
+The only thing that I am going to say about the scaling Bitcoin debate.
+Here's one thing. Going back to history, I think the Bitcoin community
+hasn't learned a lesson that a lot of other communities in the past have
+sort of painfully discovered... Decentralized does not mean
+structurelessness. There was a famous essay called the Tyranny of
+Structureless. The feminism movement rejected patriarchy etc., they
+realized that structurelessness is an illusion. If you try to set things
+up in structurelessness is just bad governance, you can reject
+governments, but you can't opt-out of governance. The attempts to reject
+governance has left us with bad governance instead of no governance. I
+think that "no governance" is not an option.
+
+Let me give you an example of this. This was based on a blog post where
+I went back to 2013 and I looked at IRC logs. Why was I looking at these
+IRC logs? I wanted to understand what happened during the March 2013
+fork because of the bug that caused the 0.7 and 0.8 version of Bitcoin
+Core to hard-fork. During this time, this bug was resolved over IRC, and
+over a period of a few hours, all of this is still archived on IRC. I
+was able ot analyze this. I made the following bold point, which was
+that the decisionmaking that saved the day was a centralized decision
+making process. We should not be afraid of centralized decision making.
+
+Let me walk you through a timeline of this. At time t, the fork was
+discovered. Those were the fateful words from Luke-Jr. I can't convince
+you, but go look at that post. When the fork happened, the community had
+only a few hours to respond effectively. If they had not done crisis
+management, it may have become permanent. It was an hour earlier, but
+the realization happened at time.
+
+There was a fury of discussion. At t=16 minutes, Luke-Jr or something
+realized that the correct approach would be a down-grade not an upgrade.
+This is highly unintuitive. There's a specific technical reason why a
+down-grade was proposed. Some people figured this out. Over the next 25
+minutes, there was a purely logical technical discussion. It was a bat
+signal. Everyone was there in the next few minutes. At t+40 minutes,
+everyone in Bitcoin Core and some of the top miners I think, like
+btcguild, all agreed that downgrade was the way to go. Thinks worked so
+beautifully during that time. At t+40 minutes, Bitcoin Core started to
+give out the advice to downgade. At 20 minutes after that, gavinandresen
+sent out an alert, it was brief, people started to downgrade
+immediately. At t+60 minutes, the crisis was effectively concluded and
+Bitcoin was saved from a fork that day. This was really beautiful.
+
+Everyone that needed to be involved was there. It was a centralized
+process. The decisionmaking works. For economic issues, which are not
+clear cut, what we need is governance, we need a process. It might not
+be on IRC. But we need a formally explained and transparent process for
+decisionmaking.
+
+Crystals and Mud in Property Law. There is a phenomenal paper with this
+name. I know about this paper through a law professor, James. It turns
+out that a lot of the things we are seeking to do with smart contracts,
+where instead of the notion of contracts with property, it's usually
+very inefficient, what we want is an automated fast approach with clear
+rules, which is roughly what smart contracts are about. It's automatic,
+programmatic, and people can understand what's the outcome of a dispute.
+This idea has pedigrees of history in property law. Most of this has
+nothing to do with smart contracts, bitcoin or blockchain. These are
+things that you can do with traditional property law. This paper argues
+beautifully of some of the problems with doing that. Why every attempt
+has failed or partially succeeded, and why people keep going back to a
+fuzzy way of doing this, which is more inefficient.
+
+Some of the reductive notions of smart property, that's actually an
+op-ed that I wrote. I wanted to leave you with three takeaways which is
+what I said at the beginning, play the long game or don't play at all.
+In the short term, I would say, try to focus on solving real problems
+rather than focusing on big vision. Disrupting DNS is a description of a
+solution without a problem. Remittance is a description of a problem
+that needs a solution. This seems to be missed by entrepreneurs in
+general. What's needed to take these technologies and work for society,
+it's not to re-envision property law, it's a more painful gradual
+process of making these technologies work together with social
+movements, like the unbanked or third-world countries. That's going to
+take a generation, it's going to require technology, but it wont be just
+technology.
+
+
diff --git a/__transcripts__/mit-bitcoin-expo-2016/linq.md b/__transcripts__/mit-bitcoin-expo-2016/linq.md
new file mode 100644
index 0000000..d5ea111
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/linq.md
@@ -0,0 +1,376 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Linq
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} NASDAQ Linq
+
+Alex Zinder
+
+I have heard that Alex Zinder has a grasp of what makes NASDAQ Linq good
+and bad, and the advantages of a public versus permissioned blockchain.
+Alex is director of global software development at NASDAQ, but he is
+here to talk about Linq, which is a platform for managing securities.
+Alex?
+
+This is possibly Adam Ludwin's / chain.com's doing?
+
+We have been looking at this for a while at NASDAQ. It has a lot of
+implications for capital markets. I want to talk about the Linq project
+which we have been working on for over a year now. It's a platform we
+are building, based on blockchains, for specifically looking at
+registered securities. It has major implications in other areas.
+
+My goal was to run through a demo. But I was told that this venue might
+have spotty internet, so I scrambled to put together some slides and
+dive into some history of the formation of capital markets and how the
+structure evolved over a very long period of time, so then I can jump
+into some demo stuff.
+
+Wee are going to touch on the current state of capital markets. We are
+going to look at a brief history, such as risk and technology and all
+throughout the years. We are going to bring in blockchain concepts and
+see if parallels can be drawn there. And then we will talk about Linq
+more specifically and how it handles currently existing processes.
+
+So looking at the chart here, this came out here of a FCC filing
+regarding new rules and transfer capabilities. Some of the regulators
+are updating their descriptions around current venture processes. From
+this diagram, I can tell that it's complex, there's a lot of parts,
+pretty much everything is accounted here, like the DTCC in the middle,
+we have a clearing broker, initiating broker, we have direct flow of
+information between multiple counterparties for clearing and settlement.
+Some of the problems, the major problem is reconciliation of
+information, how do all of these nodes in the system operated by
+individual entities, collaborate and make sure all the data flows are
+correct in that process?
+
+One way to break down this structure is to look at how it evolved over
+time. I will breeze through this very quickly. Richard Brown, CTO of R3
+currently, has some excellent blog posts on this and covers this in more
+detail. But this gives a good backdrop.
+
+Market is a simple concept. 100s and 100s of years ago, if you had
+something you wanted to sell, you had 3 problems: proximity how do I get
+access to a customer and buyers and sellers. Asymmetry of information,
+how do I get intimiate knowledge of the market. And liquidity, how do I
+get access to the goods to facilitate my trades?
+
+From a risk perspective, we had organizations that are more correlated
+to brokers and market makers. They had some primary functions, to
+provide proximity to market place, you can broker trade,s they were
+informed in the markets, the market makers in the space were able to,
+their core function was to provide liquidity, and provide a deeper look
+into liquidity even though those risks have been mitigated and market
+makers, there's new potential risk that emerges. Safety, safe keeping,
+what if I don't trust my broker to hold my securities, and servicing.
+What if they service my securities like voting rights, derivatives, and
+other things passed on to the investor.
+
+Enter the custodian, the primary function was safe keeping and servicing
+of assets, yet another intermediary. they are designed to keep a ledger
+and records of ownersihp for investors on behalf of issuers. They are an
+intermediary to a broker dealer. The one facilitating the transfer would
+engage with the custodian to move the underlying assets themselves.
+Great helpful in the equation. But what happens now is that there are 2
+new risks?
+
+Clearing instructions: what if there are discrepancies in instructions
+sent from broker to custodian? Reconciliation of information. And then
+counterparty risk, how do you verify that someone you are transacting
+with really has these?
+
+So clearinghouses serve this purpose to step into the middle of a
+transaction itself. That's done through a process called novation. Also
+they verify that all of the instructions for the transfer of assets are
+correct and matched for buyer and seller.
+
+That solves most of the problems. We are almost done. But now there are
+two more reisks. Now that you have all these parties, how do I notify
+the issuer that my ownership status has changed, like if I am a new
+holder of securities? The transfer of ownership itself, how are the
+actual pieces of information, the underlying security, generally a piece
+of paper, transferred between buyer and seller.
+
+Those two functions are performed by a transfer agent, who is
+responsible for managing all of the information, they do this for an
+issuer. A centralized security depository is responsible for
+demobilizing all the paper, they put it on their own books and it's
+electronic. Now all the exchanges can happen wit ha books and records
+change, veruss moving physical certificates around. centralized security
+depository notifies the issuers and the issuers have a clear picture of
+who owns their shares.
+
+Let's assume this is still paper. This is how the counterparties in the
+capital market came to be and the reasons why. It's a simplistic view,
+there's a lot of complexity when going international, when you add other
+types of assets into the equation.
+
+So what role has tech played in this ecosystem? Before the 1960s paper
+crisis, all of this information was transferred in wheel barrows in
+Manhatten to facilitate the exchange of records. 90% of transfers were
+received in bundles through messengers. They would do human validation
+that all of the information was correct. There were several stages of
+verification. Entering information into transfer journal was considered
+to be the most consuming part of the transfer process. Physical paper
+certifactes were destroyed, and new ones issued, so there was a chain of
+custody and regulatory process and so on.
+
+This gave us a big problem in the 1960s, we had the paperwork crisis.
+Exchanges were closing on Wednesday. The time for trading was minimized
+so that counterparties could have time to facilitate clearing and
+settlement and so on, for securities transactions. It was a hugely bad
+event. It facilitated a new way of thinking about these problems. The
+fundamental idea was to dematerialize the assets and make as much of
+this as electronic as possible.
+
+Different studies came to bare, this was around 1969. Technology was
+still very nascent. We did not have an ability to cope with tremendous
+volumes. There was a tendency for everyone in their space to own their
+infrastructure, it was a competitive advantage. This was inting to a
+decentralized network. How do we get these counterparties around the
+country in different silos, how do we get them to communicate and build
+a process around transfer of securities so that multiple particiapnts
+can join in a consistent way?
+
+One of the forward thinking models was the Ttransfer agent
+depositories...
+
+1968 - Central Certificate Cervices, immobilization
+
+170 depository trust company
+
+19669 - Rockwell study peroposed a decentralized network of individual
+transfer agnet depositories.
+
+1969 - Aruthur Little Study ocnlucded, interconnected regional clearing
+centers.
+
+1969 - NASDAQ ... NASD proposed a vheicle for implementing a nationwide
+system of interconnected regional colearinghouses.
+
+1970 - BASIC committee recommended a central securities depository
+system. That was one of the things that ....
+
+This is an interesting concept. Just a warning to the blockchain space,
+what happened actually was that, TAD model was able to launch a CCS.
+This was a first system to allow, to demobilize their securities and
+holdings, and that would facilitate much easier transfer of those
+securities. They had this system in place for ... it wasn't accepted
+nationally, across the entire country, it took hold and it started to
+mature. When the regulators started to look at this, they knew how it
+worked, it was a first mover, let's everybody implement this structure.
+As we move forward with blockchain solutions, there's a lot of
+platforms, a lot of protocols, first movers are not necessarily the best
+solution that is out there.
+
+Now we have the DTCC, a highly centralized place, it has demobilized the
+majority of paper-based certificates, and it facilitates settlement.
+They do get a lot of efficencies from this. About 98% of transactions
+... they don't actually require the movement of cash. Because this all
+happens in a single entity, they are able to do that, take advantage of
+these issues which is great. But ... to some of your earlier points, the
+regulators are starting to look at this as a real rtechnology. How can
+this be leveraged and what impact might this have? This is a great place
+to be in.
+
+They have a new rule set
+
+SEC release No. 34-76743. File no S7-27-15. Transfer agent regulations.
+
+This is where we a re from a technology perspective. We had accomodating
+risk on a securities market place area, the paper crisis, implementing
+these systems, we ended up in a place where te centralized entity is
+magnging .... there is still a lot of intermedaries, there's a
+tremendous amount of cost.
+
+So ow is blockchain different? Why does it have an impact on capital
+markets? We worked on this with our partner chain.com. We want
+electronic bearer tokens, and facilitate the transaction and transfer of
+value. One of the proven ones is bitcoin, native issuance of token that
+represents value. Securities, something emreging, that's what we play a
+role in. Brand loyalty points, IOUs, etc. There's a lot of things that
+you could implement here. A certificate, a card, something of value,
+being able to digitize that and enter it into a network and blockchain.
+How do you do that?
+
+The best obviously and the most seamless approach is to have an asset
+issued on a blockchain. That's where we're going with Linq and
+registered securities. Native assets, title assets, IOU assets. Some
+people pool a bunch of funds into a central account, and then use the
+blockchain to distribute that value with more granularity.
+
+How is blockchain different? You are directly interacting with the
+networks' shared ledger. Assets are issued onto a network. You can still
+have entities that were created to mitigate risks, you still have
+clearing agents, you still have custodian,s you still have those
+participants but they are living on the same network and living off of
+the same information. Tis would solve the reconciliation of information
+problem. Entities control asset movement by authorization. All
+transactions are secured by cryptography.
+
+Programmable smart contracts enable complex transactions. Instant,
+direct value transfer 24/7, the blockchain doesn't get turned off.
+Flexible digital rails for building user-friendly apps. Blockchain
+provides a set of primitives to build complex business logic, connect to
+applications, that immplement those primtiives and because they
+implement primitives, you can scale this, you can get the multiple
+embodies of the same principles.
+
+Transaction finality is the holy grail for settlement. This is something
+we are very much interested in. It also provides perfect auditability.
+Everything is auditable. There's full provenance of information across
+the entire chain.
+
+So that brings us to Linq and what we're trying to do there. There's a
+lot of conversations on Reddit about what is NASDAQ doing, is it a
+database, how is it distributed. There are several principles we
+leverage here. We provide a blockchain ledger. You can have multiple
+concepts around different nodes. you can have a manager node, an issuer
+node, an auditor node, a janitor node, there are N number of these nodes
+working on a single blockchain. There are many different roles.
+
+Different entities can operate htier own nodes. You get provenance,
+immutability, protection from double spending, and we built a
+fundamental API with business logic associated with blockchain
+primitives which correlates to the financial transactions we see for
+registered securities. That's the value prop of Linq and its API. We can
+do corporate actions we ahave also built iuser interfaces to be able to
+demo and facilitate and bring users into the system.
+
+That's something we really wanted to do early on to get feedback. One
+premise here is that when we announced Linq there was a strong focus on
+specific private companies. We have NASDAQ private market, it's been
+around for a few years now, we know that space very well. The inherent
+use case was to start with private companies and help with issuing these
+securities. Linq applies to registered securities as a whole, like
+funds. The value proposition around Linq and starting with registered
+securities is that we have an opportunity to leapfrog the entire history
+primarily because unregistered securities are in a paper world. You get
+a physical security mailed to you, you countersign that certificate, you
+put it in a vault, it's a very difficult situation to facilitate
+liquidity in. We want to avoid going through a paper crisis.
+
+Now we can break into some screens here. The differentiation is that we
+have native asset issuance. We are not holding custody or anything, for
+any company that is an issuer. They are required to issue electronic
+certificates. Securities are transferred to founders, investors,
+employees. We have a full registrar of who holds shares. We keep track
+of how many shares each person owns.
+
+People can exchange shares. Everything is on the platform and on the
+blockchain. The transactions have to be represented in the platform. We
+can't just say hand over the paper, it has to go through the issuer and
+this platform for transfers of shares. Now that we have this registrar
+for facilitating transactions, this was the Chain 2016 Q1 Series B. We
+can allow current holders to put orders into a specific auction, buyers
+come in and, interested in buying our stock, for the price discovery,
+for setting the clearing price, we manage all the orders, create an
+acution and actually clear this and match the orders and move the
+securities and then you cfan see here on te transaction side, you can do
+a many-to-many transaction and once the actual auction is completed, the
+system cancels the old certs and creates a new cert, each new cert has a
+historical relationship, you have a full chain of custody and
+provenance, in perpetuity. A lot of these functions are usually in silos
+like with DTCC. But here it's done on the same data set all in the same
+blockchain.
+
+This maps very well to underlying infrastructure. You can transfer
+certificates. We decided it was fundamental to have this in the
+platform. We want to avoid replication of information. Pending
+Certificates. Everything is in the platform itslef. The contracts are
+saved on the blockchain. You have a concrete block of information.
+
+We designed this around registered securities. We started with ledger
+keeping, to give us a viewpoint of the current state, we have this
+information in the blockchain, we can facilitate investor communication.
+Our primary focus at NASDAQ is price discovery and auctions. This is
+what we do, we build markets. All other components are auxiliary. We
+want to reduce friction of transactions where we can take this model and
+take it and bring it to othe rmarkets and other components.
+
+Q: Do you need a blockchain like bitcoin? You could do this with a few
+databases and locks and so on? Certificates could be signed using
+documents.
+
+A: I don't disagree with the statement. We have never seen that work. I
+don't think anyone has ever seen that work. We haven't got ot the point
+where an ecosystem with so many participants and intermedaries has
+really been able to agree on a protocol and solve for problems around
+consistency of information. There's a lot of race case scenarios that
+blockchain has solved for in Bitcoin and has proven on a scalable basis.
+So Bitcoin is critical as that regard. Tihs type of technology can run
+at scale and be completely function and alleviate some of these pain
+points. We haven't seen this with other techs. There's lots of open
+standards, there's a bunch of protocols, but nothing has been able to
+come forward as a solution like we have come forward here with. Does
+that answer your question?
+
+I'm not convinced but whatever.
+
+Q: I am on the board of directors of a private rate. Is there a role for
+broker dealer in terms of the regulator yaspect? do I have to be a
+broker dealer? Do I have to have a market maker? Or does NASDAQ linq
+provide that? Can we create a closed community so that my shareholders
+can then trade with each other using this without issuer involvement?
+Have you considered taking the pricings, we have an NAV we have
+established for stock, but now I relinquish this pricing for creating a
+small pricing, i would imagine your prospective consumers would be
+nervous about that.
+
+A: Linq was designed to provide fundamental functionality around
+facilitating transactions, interacting with issuer, investor and
+bringing those pieces together. If you are looking at direct investment
+in a private company, we are not running an open market. These are
+restricted certs. There are restrictions. They have rights of first
+refusal. Issuer must be in the middle. Being a distributed tech, a
+single data set, and everything is on the platform, it enables the
+issuers to oversee and provide a certain level of structure around this
+because there's no way to auxilirate, and not tell the company about it,
+you have to do it here you have todo it on the platform. For
+funds-to-fund you can create specific structures, you can have orders at
+different price points, you can build in business logic to facilitate
+what you are talking about to create a dynamic marketplace. That doesn't
+exist in the private company space right now. For private equity funds
+and so on, absolutely, yeah.
+
+Q: The long-term of US policy on clearing seems to be heading towards
+centralized clearing especially for swaps under Dodd-Frank. How do you
+see Linq interacting with traditional clearinghouses if at all? Are you
+doing registered securities, swaps, derivatives? Where do you see the
+risk sitting after novation?
+
+A: Novation is a question mark here. Within the context here of this
+technology and this platform, we are getting this to a point where
+novation is no longer required. We are removing the need for a
+centralized cleairng party where you don't need to do that. It's going
+to take time for regulators to get comfortable with that. In the private
+security space, there's demand for broker dealer to take on that risk
+and facilitate that and so on. Interaction with some of the current
+traditional clearinghouses for registered securities, there's no plans
+to do that. One pretty significant pain point is ability to move funds
+efficiently and wrap that into single transactions. We are doing some
+things to help with that and in partnerships. Once that's achieved,
+aside from regulatory concerns, there's no need to go in that direction.
+Capital markets and so on, and clearinghouses, on an ongoing basis, to
+build a functionality of a clearinghouse
+
+Q: Are there .. how do you plan to maintain privacy?
+
+A: Yes there are full nodes. They are distributed across trusted
+parties. It's a permissioned ledger to the extent that only folks
+actually participating in Linq will be members of the ecosystem will be
+able to operate a node and have access to this information. There's some
+components around tokenization and what data exists at different tiers
+of nodes. So you only have to understand the blocks themselves, but how
+much information is going to be attached in those blocks?
+
+Q: Do you use proof-of-work at all? If that database forks, who resolves
+the disputes?
+
+A: It's a federated consensus model. It's a permissioned ledger. We
+don't need to protect against disputes.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/maaku-panel.md b/__transcripts__/mit-bitcoin-expo-2016/maaku-panel.md
new file mode 100644
index 0000000..a94262f
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/maaku-panel.md
@@ -0,0 +1,408 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Maaku Panel
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} This can be a broad range of
+topics for improvements. I am Mark Friedenbach, I have worked on Bitcoin
+protocol research, but I also do Core tech engineering at Blockstream.
+We also have Jonas, an independent Bitcoin Core developer. We also have
+Andrew Poelstra, who has been core to the crypto work which has been
+incoporated into Bitcoin, such as libsecp256k1 which we recently
+integrated in the 0.12 release. It speeds up Bitcoin validation by 7-8x.
+We also have Joseph Poon, the co-inventor of the Lightning Network
+paper, and he's running his own Lightning company as well.
+
+maaku: I am going to jump into this and asking the first question to
+Jonas. You have been involved with the Bitcoin Core wallet and GUI. I
+was wondering if you could tell us about the risks and challenges with
+Bitcoin wallets in general.
+
+Jonas: I entered the Bitcoin space in 2012. My first thing was that I
+wanted to build a better UI and better user experience. I thought I
+could download the software and start using Bitcoin. It took a couple
+days before I could use it. I wanted to improve the user experience. It
+felt like, oh, that's going to... I need to change the Core UI because
+its system like how blocks are going to be validated... and then I found
+out that a lot of people were using SPV wallets, like on their
+smartphone without validation. Then I found out that it was not
+decentralized, it's not participating in Bitcoin, connecting to a node,
+not distributing transactions and blocks... you are a leech. You are
+only downloading stuff, like a torrent leecher. We need to change that
+model. Not everyone can run a full node because smartphones aren't
+powerful enough. I want to go in a direction where everyone can run full
+nodes, connected to their routers perhaps, maybe in your homes or center
+or whatever you want to call it. And you can still use your smartphone
+to connect to it, and still do Simple Payment Verification wallets, it
+could be shared between families, between villages or tribes, so that we
+really participate in Bitcoin, not just consuming information. Obviously
+there's lots of things to change, but we're going in that direction with
+pruning, verification, I think that's the main Core change t odo to make
+it more flexible to run a full node. I want to work on a hybrid mode
+where we can do simple payment verification during bootstrapping a full
+node. The user experience on the GUI side needs to be changed... When
+people say Bitcoin-QT has a bad user experience, I fully agree. But we
+need to change the fundamentals first.
+
+maaku: Andrew, you have been doing some crypto work recently. At
+Blockstream also, I should mention we both work for Blockstream. You did
+some work on
+confidential
+transactions and some privacy-enhancing crypto work there. Where do
+you see that aspect of research going in the future?
+
+andytoshi: One project that I have been working on at Blockstream with
+gmaxwell and sipa is Confidential Transactions. It's a technology we're
+developing for Bitcoin, sidechains and other blockchains, to improve
+privacy and censorship resistance. Lately we have been talking about
+scaling, right? But that's not the only problem with Bitcoin. There's a
+problem in Bitcoin that all transactions are public. All the information
+and all the data in transactions are public. This allows for people to
+get the full transaction graph. They can infer a lot from this
+transaction graph shape data. So this is not only bad from a
+surveillance and privacy perspective, there are many companies that are
+trying to extract data from us, from the blockchain, which creates a
+censorship vector. We worry about centralization of mining, because
+miners are sort of gatekeepers to which transactions get into the
+blockchain. So what we have been working on with confidential
+transactions, is a way to cryptographically hide the amounts of all
+transactions. The shape of the transaction graph is still visible, but
+by hiding the amounts, you can hide what the transaction is doing. If I
+create a transaction, a standard single payment that has some output
+some big round number, and then an obvious change output. Hiding the
+amounts can hide the change address.
+
+Someone might pay me, I take the coin they gave me, and I trace back the
+history and I see a lump sum that happened at midnight on Thursday, that
+could be how much money they made. If I am their landlord, I might be
+able to do bad things like raise their rent. Another problem with
+amounts being exposed is that when you try to merge transactions,
+there's another technlogy developed by gmaxwell, called coinjoin, where
+you can combine different transactions. You take two transactions and
+try to paste them together. If you have two people wanting to send BTC,
+normally you would do individual transactions, you would have a bunch of
+inputs and a bunch of outputs, you would be able to figure out who owns
+what in thos etransactions. You can also see the change output. But
+maybe Mark and I can combine our bitcoin transactions, and then we can
+break this connection between the owners of the inputs and the owners of
+the outputs. If I am sending 1 BTC in and he's sending 2 BTC in and 2
+BTC out, well, people can match input amounts and output amounts, so
+it's difficult to do a coinjoin that improves privacy. By hiding the
+amounts, we allow for combining transactions where we no longer have
+this clear correlation. Nobody can see the amounts, and now it's just a
+pile of outputs with no amounts associated. We have done this
+cryptographically. It's implemented in Elements Alpha. We have tried
+very hard to make sure the performance is good. Hopefully this will
+eventually be implemented in Bitcoin Core. We care a lot about the
+performance of that, we hope that there is a path for inclusion of this
+into Bitcoin eventually. We think this will improve censorship
+resistance a lot.
+
+maaku: Joseph, I have one question with you. You are a coauthor on
+Lightning Network paper. With the changes coming to Bitcoin this year,
+checksequenceverify (CSV) and segwit, we might have a full
+implementation of lightning before the end of the year.
+
+Joseph Poon: Sooner, actually.
+
+maaku: Great. So what is lightning and what use cases?
+
+Joseph: One of the first replies to Satoshi on a mailing list in 2008
+was, this was really cool, but I don't think it scales. With more users
+and more activity, there might be some difficulty if everyone on the
+network knows everything. If you buy a cup of coffee on Bitcoin,
+everyone on the network knows about it. Everyone running a full node
+knows about it. Everyone in the world has to process this transaction.
+If people are buying 10's of thousands of things per second, that's a
+lot of traffic, and it doesn't make sense. It's like if everyone in the
+world was on one wifi access point. You can make that access point
+faster, but it doesn't solve the problem. The correct way to solve this
+is to ... in order to get delivery of whatever it is. On the Internet,
+it's messages.
+
+Lightning Network uses real Bitcoin transactions using smart contract
+scripting mechanisms. There's no overlay network. These are real
+Bitcoins. At a high level, this works by establishing a two-party fund
+of Bitcoin, through a Bitcoin transaction. It's functionally a ledger
+entry. Alice and Bob both have a ledger entry. With 1 BTC in there, the
+actual allocation of who owns what is known to both of them, but it's
+also cryptographically provable using real Bitcoin transaction. They can
+use the local state to whatever they want in that value. By having
+multiple of these two-party safes or channels open, they can route
+payments to anyone inside this network, nearly instantaneously and
+atomically.
+
+There are many interesting use cases because this enables incredibly
+high volume. In Bitcoin, we are seeing maybe 5 transactions/sec. Visa
+has like 20,000/sec in some cases. Because if everyone is receiving a
+message, even getting there, is nigh on difficult or impossible, but
+with Lightning because it is packet routed, and it's secured using the
+blockchain, you could potentially have millions to billions
+transactions. Instead of pay per gigabyte, it could be pay per kilobyte.
+You can reduce counterparty risk significantly. It changes the view of
+commercial activity, you can do pay-per-view on websites, or
+pay-per-play on video games or things like that. I could go into more
+detail. I felt like I was going a little bit over, OK. Okay, right.
+
+So the ultimate view of the way Lightning works is that it reshapes the
+view of what the blockchain is. Instead of viewing it as simply a
+payment system, if you view it as a smart contracting system which
+enables the blockchain to act as a dispute mediation system, viewing the
+blockchain as a judge is a lot more understandable and a lot more
+powerful. If you can establish these types of agreements between two
+parties off-chain, you can conduct a lot more activity and many other
+types of interesting activity. You can write a lot of legal contracts,
+individually, rent, employer agreements... if you view the blockchain as
+court, you don't want to go to court each time. You can have agreements
+off-chain, and ultimately you have full confidence that these smart
+contracts will be enforced, and either of you can go to to the
+blockchain to enforce it. It's even better than real-life court, you
+can't convince the judge, there are established roles in this system.
+
+Lightning is an early example of a smart contract system. I think you
+will see some cool stuff in the coming years.
+
+maaku: Getting checksequenceverify on the chain, it's very exciting.
+It's refreshing to see something that was proposed just for, frankly
+much less interesting use case, just related to sidechain pegs or
+something, and see it used to create something like Lightning which is
+much more broad in scope. That's really fascinating. I like to look at
+what kind of small changes can we make that will make drastically huge
+expansions of use cases and accessibility. One of the things I see soon
+happening is the aspect of segwit in terms of how it changes how
+scripting is down. It introduces versioned script which lets us replace
+the Bitcoin scripting language in the future if we needed to, like if we
+found something better. Segwit mostly is talked about in the context of
+scaling debate. But we could do something like Ethereum script, which is
+drastically different from Bitcoin script, but if there was value in
+doing that, segwit would make that much more easily doable. As well as
+for example, sipa has worked on key trees. You can hide, or rather, you
+can have a complex smart contract that has multiple different spendable
+scenarios, and you can hide the scenarios that aren't being used so that
+the people obsreving the blockchain only see the one use case that is
+actually arbitrated, which is a measure of privacy for those involved in
+the key tree instance. There are students in the room, and I would
+encourage students or anyone who is interested in getting involved, I
+would suggest the bitcoin-wizards channel on IRC and on the mailing
+list, to look at near-term ideas, just start hacking. That's the ethos
+at MIT, you guys invented that word, to work on something interesting to
+you and find new applications. Anyone here who is listening today, if
+you can't find a good idea, just come and ask us and we can point you to
+many interesting projects.
+
+I also want to say something to anyone who is considering Bitcoin as a
+potential business opportunity. The best advice I can give you is to
+take something that has users or potentially could have users, and bring
+it to the market. Write open source software, put it on github, get
+people using it, respond to their feedback, make changes that make their
+life better. You will find your product used. Having lived in Silicon
+Valley, my most important thing here is get users. It keeps you
+grounded. The worst possible mistake is to get wrapped up in research
+and then later get forced to examine reality later, don't fall into that
+trap. Have users, write code, make your own improvements.
+
+Speaking of which, I am going to go to Andrew. When you were starting on
+Bitcoin, you were at UT Austin. You were working on cryptography. Can
+you share about that?
+
+andytoshi: When I first started in the Bitcoin space.... right now I am
+working on libsecp256k1, which is a high-performance crypto library.
+When I got into this space, high performance cryptography seemed like a
+blocker to me. The work that I was doing, I had just finished a degree,
+I had just moved to UT Austin, the work I was doing in school was
+abstract mathematics. I was doing real analysis and metric geometry,
+which has nothing to do with elliptic curve cryptography. And so I
+think, a lot of people here are students at MIT that might have a
+similar perspective, they are doing something and they think it's cool
+but it probably has nothing to do with what they are actually working
+on. There's this whole process to work on crypto I guess. What I found
+is that in the last 5 or 10 years, everything has become so public and
+so open, even on the research side of things, it's entirely possible to
+get into this stuff. I do have a math degree, but it's completely
+unrelated to the work I do in crypto.
+
+I got in, I found this IRC community called bitcoin-wizards, it's still
+there, it's a bit more crowded now. There were several experts that were
+doing high-performance cryptography, some of them without degrees
+themselves. They were highly accessible. I was able to just download
+papers completely freely. I was able to ask questions and explore. By
+doing so, I was able to get into this high-performance crypto work.
+There were people who were happy to answer my questions. They were
+excited to have a new person to work with. On the other side of it, I
+can see this lack of talent. It's hard to find good people. There's this
+weird gulf where there are many talented people at MIT and elsewhere who
+are too intimidated or don't know how to get into that stuff, so they
+don't try. And on the other side, where are the good people? I will give
+people my cell number and say call me any time I will talk about crypto.
+It's a huge gulf. People should try to get together, don't worry about
+credentials, those blocks aren't really there.
+
+maaku: So there has been an effort to modularize the Bitcoin Core source
+code. What are the implications?
+
+Jonas: When Satoshi published the source code somewhere roughly seven
+years ago, it was a big gigantic junk of code. Guess how it is today?
+It's still a big monolithic chunk of code. It contains the consensus
+layer, the decentralized consensus layer. It contains a wallet, which
+has nothing to do with the consensus. It contains policy, fee stuff, and
+it contains the peer-to-peer layer. It's all running in one process, in
+one github repository too. When people say, sometimes I read that Core
+doesn't want that change, Core isn't going in that direction, you also
+see how Core involved. It was given over by Satoshi. It was always Core.
+That was Bitcoin. And now Core is getting an identity. We are trying now
+to modularize the source code, in particular so that the consensus layer
+can be moved into a separate repository, so that we can have a separate
+group of people deciding what will happen to the consensus layer, and
+not the guys doing wallet work or p2p network work, or whatever. That's
+a really important part to allow different clients... they want to do
+Bitcoin, ... it's not possible to specify that right in paper, you can
+try, but as soon as you specify... and then 95% specification, the
+chance of having that in your specification is extremely high. So it's
+impossible to specify it in my ... it should be a separate group, and
+then nobody can blame Bitcoin Core. It's also very difficult to make
+changes to the p2p network, because as soon sa you change it, you take
+the risk of changing consensus. The ... you risk the $6B market cap
+crashing, so we need to decouple those things and have independent and
+release as casuals, that would be a big advantage for the process and
+running multiple clients.
+
+maaku: We would like to open it up to questions now.
+
+Q: I had a question about the lightning network. Can you explain at a
+user level? Say buying coffee, how does that work. Do I have a special
+wallet? If Starbucks and I had some accounting, where would that
+information live? Is that on the blockchain?
+
+Joseph: There's a couple questions, if I skip one, do tell me. Okay, so,
+user interface question. There will be a separate wallet, ideally
+Bitcoin Core will have this built in. With the user experience, it
+should be as simple as possible. All the complexity can be hidden. Sort
+of like the Internet, you have no idea how it gets there, it's just
+buttons for users. The coffee example is an example. I don't know how
+applicable Bitcoin is for coffee. For me, coffee can be bought with Visa
+and Mastercard. What's the marginal value with Bitcoin there? Maybe 3%
+marginal savings. Visa and Mastercard solve $0.27/transaction, Paypal is
+$0.30/transaction. The reason why Paypal doesn't do microtransactions is
+because underwriting costs are really hard and really high. So with
+Bitcoin, it's like cash, there's no third-party custodian where
+chargebacks can happen. The use cases that I think are profound are
+transactions that might aggregate to a high value, but individually are
+small. Same thing with high-frequency trading, fundamentally your fees
+and market makers and things like that, when new entrants came in, you
+know, you have, the average share size is somewhere in the single
+digits, you go as small as possible because why not. The value of that
+for commerce in general is that you could significantly reduce
+counterparty risk. You sort of don't care. That's the real value that
+Bitcoin gives long-term. Ah, right, accounting. You do have a ledger
+entry on the blockchain for a value, so say if it's 1 BTC between you
+and another party, that's what everyone sees. But the individual
+allocation of who owns what, and the individual updates and state
+changes, are known locally to both parties. You might not directly have
+a channel open with Starbucks, maybe it's a friend or grocery store or
+something, you can pay through the lightning network, in a multi-hop
+atomic way, instantaneously. So the question is about backups, like
+losing phones. You do keep a local copy. The other party also has a
+local copy. If you lose your phone or whatever it is. You can delegate a
+third party to watch the network on your behalf, so it's up to you for
+the level of assurance that you want, the default for most users should
+be you should have a backup.
+
+Q: I had a question ... using the blockchain to help a bank in Zimbabwe
+to utilize opportunities with remittances and the correspondent banking
+.... one of the things I have a problem with is that using API for
+like.. co-pay for ... I've had a problem with working with local
+developers. I've been trying to build something with indiginous local
+developers. Interest, we need like a curriculum. How to introduce people
+beyond just putting APIs together, to really connect them down to a node
+level and beyond. I'm waiting for someone to come up with a solution
+that helps contract farmers track their transactions, right now there is
+a big issue in agriculture all over the world, where the former regimes
+still control the market, there's a gap between the European market and
+a small farmer. We want to get indiginous folks over this learning curve
+where they can start building on the Bitcoin blockchain. It's a smart
+contract, but we want them to deal with transactional value is good too.
+If there was a curriculum to get interested parties to where they ... if
+anyone had a direction... it would be nice. I'm behind schedule by 2
+months.
+
+maaku: There's a developers guide on bitcoin.org. They have a
+developer's guide which has a good description of the Bitcoin protocol.
+That's the best documentation out there right now. It's true that the
+Bitcoin documentation is lacking in general.
+
+Q: The information is there. I want to say, how do you help them connect
+the dots? It can be intimidating.
+
+maaku: We need a bitcoin or blockchain university, like an open group
+online where anyone developers can get on board... it hasn't
+materialized. Maybe it's an instance of needing the right people
+together. Like people who are interested in doing a first run-through of
+the curriculum. To your specific use case, there are things being worked
+on, like ... like native issued assets, on sidechains, that might be
+helpful to you, but we don't have sufficient documentation about that at
+the moment.
+
+Q: What do you agree with and disagree with from the last presentation?
+
+maaku: Our friends in China are very smart. They are working for the
+betterment of Bitcoin as a whole. At Scaling Bitcoin Hong Kong, we
+voiced concerns about centralization of mining in Bitcoin. The concern
+would be the same if it would be in any other country in the world. It's
+not just China. The other, and it's not a concern against the miners
+itself, it's a concern about the jurisdiction. The other thing that I
+would like to say is that Bitcoin is not a democracy. It was not
+designed to be a democracy. Democracy is anti-thetical to what Bitcoin
+represents. It's consensus even in the face of mob rule going either
+way. You can have a strong movement... against the consensus algorithm
+specifies as a valid block, but unless you get everyone in the world to
+upgrade every single node, you are going to have an incomplete
+hard-fork. This is user protecting. It's scary when things break. This
+is what makes Bitcoin great. Irrevocability of payments, no funds
+seizure. This is because it's difficult and hard to change the Bitcoin
+protocol. The point that we have to argue and debate over this, it's a
+strength of Bitcoin. If it was political money, then 18 months ago this
+would have been over whether you like it or not.
+
+Jonas: Voting or democracy.... my country is one of the only countries
+with direct democracy. You need to understand the topic. Who controls
+the ballot? Who controls the options? I don't think the miners
+understand the technical nature of the problem. They say "we don't care
+about these issues". But voting means you need to fully understand...
+and as soon as you say everyone needs to vote, and study the problem for
+a few days, who is able to do that? With voting comes lobbying.
+Companies collecting money to influence people. We see that back in
+Switzerland. It's about money and propaganda. I like it, but it's
+political thing, it's not technical stuff. Can the people in Bitcoin
+talk about what they really want?
+
+andytoshi: I agree that there is a lot of centralization in Bitcoin
+mining today. What has happened at this point is largely that existing
+wealth is getting imported. I don't think this is permanent. I think a
+lot of this is temporary. This existing property of the way electricity
+and avialbility..... I also don't agree there is no room for
+technological solutions. There's a lot of room for tech improvement. The
+social problem is not going to solve it. I think there are many
+political currencies out there today, if you think you want that, you're
+welcome to switch to them. Changing it to a political money is not a
+solution, that's shutting Bitcoin down.
+
+Joseph: I think there's this thing where, there's a lot of new people
+learning about Bitcoin. A lot of solutions have been tried already.
+Bitcoin has been working and working well. There might be more solutions
+coming. It's important to look at what has been tried already. There's a
+community full of scammers, called the altcoin community. They all
+congregate on bitcointalk.org, or as my friends like to call it,
+altcointalk...... They talk about these interesting ideas, but then I
+have to point them to how we tried that in 2012 already. Maybe there's a
+way to have 1 person 1 vote, several have tried it, Sybil attacks are a
+thing. There are many problems. Perhaps there is a solution. But Bitcoin
+has been working. We'll see how ethereum does with proof-of-stake, I'm
+skeptical of proof-of-stake because of nothing at stake problems. But
+especially banker types going in and saying, "oh yeah you need to hear
+about these other coins".
+
+maaku: Thank you everyone.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/pindar-wong.md b/__transcripts__/mit-bitcoin-expo-2016/pindar-wong.md
new file mode 100644
index 0000000..acf50da
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/pindar-wong.md
@@ -0,0 +1,379 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Pindar Wong
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Pindar Wong
+
+Forked to Death: What Internet governance can learn from Bitcoin
+
+So, the last talk today is going to be from Pindar Wong. He's been
+involved with Internet in Hong Kong. He also helped organize the Scaling
+Bitcoin workshops. It's my pleasure to have him speaking today.
+
+Okay. Thank you very much for staying until the bitter end. My topic
+today is forked to death, what Internet governance can learn from
+Bitcoin. I do mean this, and I would like to explain why. This is a
+fork. I am holding a fork.
+
+In Internet governance, we don't talk about forks, we talk about
+fragmentation. The title here should be fragmentation to death, what
+Internet governance can learn from bitcoin. Fragmentation from the
+internet is a real and present danger. This morning we heard we have an
+internet one behind China and one behind the United States.... I am from
+Hong Kong. We had some views this morning about the miners in China. As
+you also know, I was honored to finally meet many of you through the
+process of Scaling Bitcoin.
+
+Bryan Bishop at the end of Phase 2, why not post to the -dev mailing
+list about reflections about the event? Phase 1 was one of the times
+when many developers got together. And phase 2 was when all of the hash
+power got together for the first time. Looking back on that, this
+presentation is looking back on those two recent events, as well as the
+recent Satoshi Roundtable and also the Hong Kong meeting.
+
+First I would like to thank the students from MIT who came up to
+Montreal to help up with this seminal events. MIT DCI was one of the
+core underwriters for this event. Jeremy Rubin was the chair for
+phase 1. So thank you so much for that.
+
+So what can Internet governance learn from Bitcoin? The first point is
+that the Bitcoin community is very careful about attempts to externalize
+cost. This is really smart. At Scaling Bitcoin, I was the most stupid
+person in the room, which means I was in the right room. This group is
+really sensitive to the notions of externalizing costs. BGP attacks were
+mentioned earlier. Spam is another example. We did not do that cost
+externalization analysis, and I think this community does that really
+well, we should really learn from Bitcoin about when to externalize cost
+in a shared system.
+
+The second one is that it's about meritocracy, we don't care who you
+are, it's rather about your ideas. We see past race, gender,
+orientations, prejudices, it's a technical meritocracy for proof-of-work
+of hard work. To see people get on planes and come to the event for
+Scaling Bitcoin and have really deep civilized respectful technical
+conversations, was wonderful to see.
+
+The other thing that I have learned... I still use email. I don't use
+chat. I have only tweeted maybe 40 times. This community has discovered
+something faster than light, and that's rumor. It's real-time media
+audit. The use of reddit and the use of IRC and all the different chats,
+it seems 24 hours per day. That's something to recognize, because to me
+that's something really different. Cory and I had an interesting
+exchange, he said, would the internet have occurred if it was constantly
+under the media spotlight that current internet provides? I think the
+answer is no, but it's ust my hypothesis, we can't check this.
+
+I think this community is develping an immune system. I don't think it's
+about governance. Let me explain why. Let's look at the Internet today.
+I started the first ISP in Hong Kong in 1993. That was 23 years ago? How
+many of you are under 23? So technically, before you were born, geeze I
+feel old. July 5th, 1993, there was a famous comic in the New Yorker,
+which said that on the internet nobody knows you are a dog. That
+resonated with me because the internet was the first time at a societal
+level that mainstream can talk about the internet and say whatever it
+wanted. This year we see mainstream talking about Bitcoin. So keep this
+in mind.
+
+The reality is that, right now, despite the Internet, what we have is
+that people doing metadata analysis, doing data surveillance and making
+accusations and allegations. The metadata these days is the message. We
+have developed this Internet which was supposed to be free and open, and
+in terms of previous governance, we have failed.
+
+Also in terms of governance, before text, we had a wonderful word which
+I am going to describe. It was before images. The people who were at the
+cusp, like Joi Ito, who run the MIT Media Lab, who feel strongly about
+Bitcoin so that we don't make technical compromises that jeopardize
+interoperation of the Bitcoin blockchain.
+
+Today I was supposed to be in Morocco for an ICANN meeting. The internet
+kind of just works. Well, there's a lot of engineering that makes the
+Internet work. The closest thing I could say for consensus protocols is
+like BGP. All of the routers have this algorithm, and the packets end up
+where they should. On the internet, you need a hierarchical numbering
+system of IP addresses, like for IPv4. I was also the device chair of
+the IP name assignment for the agency. This meeting is important, I
+think, because it's the 55th meeting. Scaling Bitcoin has only had 2.
+This has had 55 minutes since 1998. It's supposed to decide if the US
+government lets go of the car keys, and lets ICANN self-administer. This
+was supposed to happen on September 30th, 2000. So we are 16 years
+later. Perhaps better late than never?
+
+This is as close to Internet governance as you will probably get. You
+all remember that in Bitcoin, on the front page of The Economist, was
+"the trust machine". If you look at today's Economist, there was an
+article about Internet governance. This topic is about Internet
+governance and what it can learn from Bitcoin.
+
+So what is Internet governance? It's blah blah blah blah. It took
+several years to negotiate the text. "Internet governance is the
+development and application by governments, the private sector and civil
+society, in their respective roles, of shared principles, norms, rules,
+decision-making procedures, and programmes that shape the evolution and
+use the internet."
+
+Guys like me show up in jeans, and then they ask who am I? The
+difference is that engineers are willing to solve it no matter who the
+engineers are, but then the Internet governance discussion becomes "who
+are you?". I think that's the wrong model.
+
+We heard this morning that you can escape government but you still need
+governance. I think what we have right now with Bitcoin is actually
+working, though. Governance is the wrong model. If you talk about
+governance, you are talking about control, centralization, you're
+talking about aligning different interests, whereas if we changed that
+model, from this afternoon's presentation, if at any time after this
+time forward and hear someone saying "Bitcoin governance" ask them to
+stop and ask about health instead. It's about Bitcoin ecosystem health.
+
+Anything that you do, should improve the Bitcoin ecosystem health,
+however you perceive that to be. Don't talk about governance, talk about
+ecosystem health. What I mean by Bitcoin health is that we are building
+a healthy industry with all of the different players, including
+academia. Everyone has different interests, but what aligns us all is
+that we are an ecosystem of interdependent almost by design, and in so
+doing, we need to think carefully about the health of the whole
+ecosystem and your own individual.
+
+Yes, we're dealing with issues of technical scalability, like the block
+size discussion and debate, the drama that has happened over the past
+year and a half, but sorry that's absolutely normal. Maybe it's your
+first time going through the mill, but this is sort of the strength of
+Bitcoin itself.
+
+Beyond technically scalable, which is something that I think we can
+solve, but is the whole thing economically sustainable? I think that's
+an open question. The subsidy and the cost of operating the system, like
+CPU time, like unspent transactions, and calculating the total cost of
+the system so that the whole thing is economically sustainable in
+addition to technically sustainable. For an ecosystem like this, what
+would you consider to be pollution? What is normal? What is UTXO
+pollution? What would you consider to be normal? What would you consider
+to be a normal functioning Bitcoin ecosystem? That's the imagine that I
+hope we can define.
+
+In the Internet ecosystem, we talk about evolution. There are no
+permanent favorites. In regards to the recent events in 2013, such as
+the Snowden revolutions, and NIST compromised recommendations, and the
+IETF engineering task-force has classified that as an attack. Previously
+they recognized censorship as an attack that the Internet routes around,
+that's an evolutionary process. We admit that we make mistakes, we learn
+from it, and we evolve. In an ecosystem health model, also look at an
+evolutionary health model, things that don't evolve will die. So we
+think about balance and that kind of thing.
+
+So that's the whole concept of stimulus and response, such as
+stimulating your immune system, and having it adapt and evolve. This is
+used in Japan for kaizen for continuous improvement. I believe Bitcoin
+should have the best tech, the best people, evolving the system to meet
+higher goals.
+
+How many of you remember this? Yeah, the mosaic browser. Okay you are
+all geeks. a16z before he was a VC, he actually wrote code, like Mosaic
+(NCSA). This was around 1993. There was an era before that, which was a
+magical era, which was the era of pure text, pure imagination, no
+graphics, no distractions.
+
+In that era, we had a timeline, we had the academic networks up to 1993
+more or less, we had our trade association from 1991 for the commercial
+Internet exchange, which my ISP joined as a member. This National
+Science Foundation network was designed to survive nuclear attacks.
+There was a whole bunch of 20 more years of research and development
+that ended around 1993. The commercial guys, I dropped out of
+university, I was 23 or 24 at the time, had a PhD, co-founded an ISP,
+and obviously ISPs were commercial they had the goal of making money. So
+you keep costs low, and you keep your revenue high. This was built into
+our blood in Hong Kong.
+
+There was a huge culture clash between those who were purists versus
+those who are commercial. There were culture clashes there which we sort
+of see now in Bitcoin, those who are interested in making money, and
+then a bunch of Bitcoin Core developers who are flag bearers for Bitcoin
+principles. At that point in time, for those who want to double check,
+look at the reports at the time. There was lots of drama. Nothing
+particularly new, when you have a difference of culture.
+
+Right now where we are in Bitcoin, in some sense we have this backwards.
+We have gone commercial, and as Arvind said is that academia is good at
+scaling knowledge, but it's still warming up. Some of us are good at
+building Internet, which I will talk about.
+
+I think that the Bitcoin community is super sensitive to externalizing
+cost. The ISP system was my community connects to your network. There
+are 60 or 70,000 right now. There are 70,000 different autonomous
+systems that comprise the Internet. When you are commercial, your goal
+is to make money. So you either keep your costs low or you shift those
+costs on someone else, you externalize your costs. If you keep your
+costs low, and you shove the cost to the ecosystem, the environment lays
+off you, you make more money, in commercial that's just the way it is.
+
+I think the Bitcoin ecosystem is very clever in identifying where costs
+are being externalized. That's really good in this stage of development.
+
+Let's take a trip down the memory bus, and this is to highlight that
+these big debates are perhaps nothing new. Get used to them. These won't
+be the last. If you look at Rick Adams, who has a long history, he also
+funded USENET, which was eventually acquired. In the old days of text,
+there was a peer-to-peer network called USENET news. It had a technical
+limitation. The USENET newsgroups could only have 14 character naming
+limitations. That was the constraint. Some people wanted to have
+newsgroups with more characters. There was a big revolt. They said
+usually these original 7 groups, they were just chat boards, these
+people who were interested in a certain subject would gather together
+and talk about those 7 big categories. They were all based on
+hierarchies.
+
+And then there was a revolution, there was an "alt" hierarchy, pretty
+much anything went. That's when I got introduced to the internet.
+Looking at these USENET newsgroups, you had to go stitch things together
+and it was very weird, you get really exposed to humanity at its rawest.
+It was absolutely wonderful. It was absolutely diverse. You could find
+anyone and everyone interested in one particular esoteric subject. At
+the time, I was into.... and that's the internet I falled in love with
+thing, it was borderless and nobody knew if you were a dog. It was all
+text, no graphics.
+
+Around that point of time, there was a book, someone wrote a book which
+was a guide to this space, by Ed Kroi called Hitchhikers Guide to the
+Internet (RFC 1118). Andreas' book is sort of like the first guide to
+this space. And then there was the usenet wars. And then there was
+another one, for the domain name system. This came from the US
+government funded NSF network. The meeting today will hopefully decide
+that it's time to end US government involvement.
+
+The backbone network, there were about 4000 nodes in the network and
+that's all they wanted. In 1992, when the government said this is
+government-paid infrastructure, there were commercial players on the
+line, a lot of people dropped out of school and joined companies
+instead. Commercial was about making money, and the academic thinking
+was entirely different and it was a culture clash.
+
+Great coders like Marc Andreessen originally wrote Mosaic and Netscape
+and the rest was history. The domain name system at the time was
+something about translation from text strings to IP addresses... again
+that had only 7 top-level nodes, was that a technical limitation, or was
+that a historical accident? We have spent over 20 years trying to answer
+that question through these 55 meetings.
+
+At the time, registering a domain name was just $50. People started to
+complain and they said it should be market priced. What's the fee
+market? What's the market price of a domain name? Nobody knew. So we
+took this "wait and see" attitude, and we have seen this price drop to
+$5 or less, and now we have ICANN. I was involved when I was appointed
+to.....
+
+So from that perspective, if we look at how the Internet has not been
+too graceful or strategic as the Bitcoin community, there are three
+examples. BGP is one example, how networks exchange routing information
+with one another. And yes you can attack it and redirect someone else's
+traffic, but when you are an ISP, your basic cost is that you are
+renting these communication lines. So if the traffic you receive off of
+the network is not related to you, you get rid of it as soon as
+possible, it's hot potato, you send it to someone else, you don't want
+to incur that cost, so chunk it out a window as fast as possible.
+
+Another example is email spam, sort of perhaps it is a design flaw in
+the protocol. That's the way the protocol behaves, perhaps exploit it.
+The very existence of email spam caused many people to run mail servers.
+How many of you run mail servers? Huh weird all the Bitcoin Core
+developers in the audience raised their hands.... and nobody else. Well
+anyway.
+
+Spammers can send millions of emails, and the rest of us have to bear
+that cost, or we have centralization. This is an unintended consequence
+of a design process in a protocol. It didn't forbid such behavior. So
+the few spammers exploited that.
+
+Are there equivalents for example with spam on Bitcoin able to inflate
+the UTXO set? Sure. The transition that was supposed to happen between
+IPv4 and IPv6.... Right? Which we just heard from IBM today. We are
+facing not an Internet of things, but an Internet of threats.
+
+Who knows what kind of software is in all these sensors? One of the
+reasons I am here today instead of at ICANN, is because I think that
+Bitcoin is building the foundation of trust. I don't actually know what
+Bitcoin is. I think I know what it is. But it's going to evolve. In the
+days of text, back in 1993, if someone said you are going to be doing
+real livestreaming of video, I would have said what on earth are you
+smoking because I want so.
+
+There's a DNS root, which gets attacked every now and then. There's an
+incident, like the Luke-Jr fork, the community responded within an hour,
+because they all knew each other, they agreed to downgrade. There's an
+Internet equivalent, which is when the DNS servers fell over. And then
+we realized we needed a backup system, or rather that we had to keep the
+initial servers working. So that community held everything together in
+times of crisis.
+
+Events like Scaling Bitcoin helps build the community equity. The best
+quote I have from Scale 1 is "I'm an asshole, you're an asshole, let's
+be an asshole together". That's great. The whole point being here is
+that externalizing costs of a shared system, shared systems such as DNS.
+If the protocol needs to evolve and your software if oyu are running
+wallet software, sorry but you are going to have to write some code.
+It's cheaper for me as a business to not absorb any costs of changing
+any code, if I can just change a parameter that's great. But writing
+wallet software for a fee market, sure that's a little complicated, then
+I need to get that working. It's extra complexity. As a business you
+don't want to do that, but then what's the cost to the ecosystem if that
+player externalizes their cost to us?
+
+I think this group, this brain trust, is quite amazing on answering that
+question so far. So Internet governance is the wrong model. Bitcoin
+governance, well just stop them right there, it's not about governance,
+it's about ecosystem health. I think to have a productive discussion
+about hwat your vision is of what that ecosystem looks like when it's
+healthy. Furthermore, I think in recent discussions, by example of the
+Internet, you end up healithier afterwards. Bitcoin Core has a very
+clear website now, that's evolved. Stimulus and response.
+
+So it's not really about governance, it's about health. And taking from
+theory and putting things into practice. Some of the research is just
+now happening, and we all want the best tech for Bitcoin.
+
+What is the role of universities? We had NSFnet, we had
+commercialization over 20 years. I was at FC 97, which was probably the
+first one. So having interest in Bitcoin, universities really act as a
+neutral platform. As you heard from Arvind, academia scales better.
+Universities over a long time, serve as trust actors for society. As we
+move from analog to digital, I think universities can serve as an early
+warning device for societies.
+
+Universities should run Bitcoin nodes on the network. They should
+operate fully-validating nodes on the Bitcoin network. The MIT bitcoin
+club should be running at least one fully-validating node. Could they
+act as seed nodes for the rest of the network? Can you add telemetry on
+this, to do research on Bitcoin?
+
+It's also empowering students, like the MIT Bitcoin project, it's quite
+helpful, like working on documentation or reading documentation and
+thinking about the ethics of the ecosystem. If you found a fundamental
+flaw in Bitcoin, as a researcher you could make money from that, right?
+What would you do? What is the ethical thing to do? If you publish
+yourself as a researcher, would you put yourself at personal risk
+because it could be market moving? Why? Because currencies are a very
+clear representation of societal trust and value.
+
+So right now in terms of current participants in the network, this is
+it, one in the BSafe.Network that I would like to announce, is the first
+fully backwards-compatible network. There is MIT, Boston, UC Irvine,
+University of Maryland, and in Erupe t's TU Darumshladt, University of
+Cambridge UK, New Castle University UK, .... slide went away. I want to
+stimulate discussion in blockchain research.
+
+Do we need an NSFnet for Bitcoin? I say yes. We need to make this area a
+safe space for legitimate serious research. We want the best minds. This
+is an attempt to do that. There's a slight tweak in here, which is that
+it should not be universities only, but also enthusiasts or outsiders
+who should not be excluded from collaborating with the people who would
+be otherwise operating on the "NSFnet" research project.
+
+So with that, I will close and say that everything is going to be OK.
+((applause))
+
+See you tomorrow morning.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/r3.md b/__transcripts__/mit-bitcoin-expo-2016/r3.md
new file mode 100644
index 0000000..1c1e430
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/r3.md
@@ -0,0 +1,134 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: R3
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Distributed Ledger Group
+
+R3
+
+Kathleen Breitman
+
+I work at R3. It manages the distributed ledger group, of 42 banks
+interested in using blockchain or distributed ledger tech. People wonder
+when I tell them that I work for a consortium that wants to use
+electronic ledgers. What does that have to do with capital markets?
+
+Ledgers can track transactions. Typically in a capital market context,
+this responsibility falls to the backoffice. After a trade, you finalize
+it and actually transfer value. In te case of trading equities, this can
+take up to three days. There's also balance sheet risk. It is hard to
+trade money if you are not sure if you have that money. Thta makes it
+difficult to finalize trades and what not.
+
+What's kind of driving this is that most of the technology in the back
+office is about as old as I am. And there's many reasons for this, I
+think Alex brushed over this. There have been many different efforts.
+It's hard to coordinate a group of actors to instate a new technology.
+It costs hundreds of millions of dollars to maintain these existing
+systems which does not offer a large amount of efficiency anyway.
+
+So at R3 we have united 42 banks who said we are really interested in
+improving these processes which have been stuck in 1980s or 1990s tech.
+What we want to do is find a better way to implement tech. This happened
+to be the case and sales pitch at a time when blockchain was hitting a
+new found popularity. What I find now is that blockchain is a stone soup
+for capital market applications. If you think you know your collateral
+management process is archaic because it's done in a spreadsheet on
+someone's computer, yeah sure blockchain can change that.
+
+So we are thinking about systematizing and creating a global ledger to
+bare the costs of these transactions. That's what our financial grade
+ledger is. That's what we're doing. We are also doing product
+development. How do we create a new digitization standard that reflects
+the times rather than 1980s or 1990s when most of the backoffice
+processes were made?
+
+How do we register and creat eauthority around these transactions in a
+21st century way? Finally our approach is centered around a lab. There
+are many solutions in the space. We are building our own solution. We
+are trying to extract value from other vendors and their insights from
+trying to operationalize this. Last week we announced we united 40 of
+our 42 banks among 5 different cloud platform in our lab. From a tech
+perspective this was not remarkable, but I think this issue is as much a
+political issue as it is a tech issue.
+
+Our consortium model is to facilitate adoption by a network effect here.
+
+At Bitcoin conferences and Bitcoin talks I often here what I might see
+on reddit which is that R3 is trying to do something bad to Bitcoin. Uh,
+this is in particular not the case. We don't have an official view as a
+company. It is the case that the solution does not use Bitcoin's code
+necessarily. Many design coices in Bitcoin are tradeoffs motivated by a
+threat model. It's a censorship-resistant cryptocurrency and many of the
+design choices that have led to the success of bitcoin are not suitable
+for capital markets, where we want to be able to punish people if they
+do break the law.
+
+Blockchain has been a catch-all for people trying to think outside the
+box. This gets a little tension in front-office processes like trading
+and whatnot. Rarely do we see people thinking about how you look at risk
+comprehensively by using one distributed ledger. How do you have
+multiple datasets and actually auditing them in a dynamic fashion?
+
+Bitcoin is a way to think outside the box and push the boundaries. We do
+not rely on Bitcoin's code.
+
+Q: Thank you for the presentation. The 42 banks, are any of them Chinese
+banks?
+
+A: No.
+
+((laughter))
+
+Q: Is there any intention for R3 to address consumer paymetns?
+
+A: Right now, what we're trying to tackle is capital markets. There are
+many parallels to what we see in the payment space right now. The type
+of adoption schemes that we could implement with capital markets.
+Ultimately this will benefit the consumer, it will put a lot of pressure
+on the sell side, we will see a new way to look at finance. It's
+Bitcoin-inspired but we're not imitating Bitcoin.
+
+Q: One of the biggest things attracting people to Bitcoin is
+decentralized. Why would it make sense to centralize blockchain?
+
+A: You mean for private use cases? If we want to reconcile internal
+records... that's a sort of false application of distributed ledgers.
+Whta people tend to not appreciate if they don't work in a bank, I come
+from consulting for banks, you might think that these are machines that
+are finely oiled and stuff, but they have lots of databases that need
+reconciliation. When they say internal databases, they mean a
+construction database, you want the guy sitting in the department over
+from you who looks at your expenses, to be able to say hey that's weird
+why didn't that transaction clear. To have a more aduitable ....
+
+Q: You have 42 banks in the consortium. People don't want to see other
+transactions. Zerocash? Confidential transactions?
+
+A: Within groups in a bank, you can't see what they are doing, for
+regulatory reasons. At R3, our architecture group which is trying to
+build this financial-grade ledger which will underpin everything. We
+have three main concerns. Scalability, privacy and smart contracts
+business automation because you can't get to these numbers without
+automation.
+
+Q: R3 is a part of hyperledger. How?
+
+A: We are not focused on syndicated loans. Use cases are something we
+are dealing with on an interest by interest basis for each bank. For the
+hyperledger project, we represent our members' interest. There are 5
+donated code bases donated to the hyperledger project. It will be an
+experiment to see which one serves the best uses of our members. It's
+open-ended.
+
+Q: My question is about privacy. What sorts of transparency and
+auditability do banks really want? How do you plan to enforce that? What
+about permissioned access and revoking permissions?
+
+A: This will fault to our product team which will be more of a case by
+case basis. Bilateral transaction between two parties.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/rootstock.md b/__transcripts__/mit-bitcoin-expo-2016/rootstock.md
new file mode 100644
index 0000000..835e696
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/rootstock.md
@@ -0,0 +1,398 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Rootstock
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Rootstock
+
+Sergio Lerner
+
+Sergio is co-founder and chief scientist at RSK Labs. The whitepaper was
+pretty good. I am happy that he is here. Thank you. Just give me a
+minute.
+
+Alicia Bendhan Lous Parker BitDevsNYC
+
+Yes, I use powerpoint. Please don't read my emails.
+
+Thanks everyone for staying here and not going to the next room. Thanks
+for the organizers for inviting me. Today I am going to talk about
+Rootstock. It's a codename for a smart contracting platform that we are
+developing for SKY labs, which is a company we founded in 2015.
+
+I am Sergio Lerner. I am from Argentina. Is there anyone else here from
+South America? I am a computer security researcher. I am also an
+entrepreneur. My first company was a high-tech medical company. When I
+discovered bitcoin, I completely switched to doing bitcoin companies.
+From the very beginning, I was working with smart contracts. This is a
+combination of many years of work.
+
+I am going to start from some simple concepts about smart contracts. I
+hope I don't bore anyone. Then I will start with the more complex
+things.
+
+When I have to explain to my mother what I am doing, I found I had no
+explanation. There are two ways to understand this. One way is that a
+smart contract is a way to attach rules to money in a payment network. I
+can send you money, but at the same time restrict it so that you can
+only use it in some ways. The other way to understand a smart contract
+is where you have a program, and you give the program the control over
+the money. So you can have a distributed DNS system where you can have
+this system to register payments to register domains.
+
+What's the relation between Bitcoin and smart contracts? Bitcoin has a
+limited implementation of smart contracts. The multi-sig wallet is based
+on this smart contracting scripting system. This is called Bitcoin
+script. Taking the case of Bitcoin wallet, there are things we cannot
+do. We can't apply limits on daily withdrawal amounts. We need some
+persistent memory to store the partial amount of money we are spending.
+We don't have reflection, we can't inspect the timestamp or inspect the
+transaction amount. Also, one of the things we would like to do with a
+wallet is have some payment addresses, and we can't do this with Bitcoin
+right now because we cannot inspect the confidential transactions.
+
+So why did Satoshi chose to implement this restricted incomplete
+non-turing complete language? There is a reason for this. It allows
+transactions to be replayed when there is a huge reorg of the
+blockchain. In that case, you can take a transaction from one of a
+branch and then put it into another branch. At the time that Satoshi
+thought abut this, I think he had a good design goal. But this time, we
+don't see many huge reorgs, so we can start to think what if we could
+include introspection into transactions so that they can relate to the
+block and read the block timestamp for example.
+
+So these are the restrictions of Bitcoin Script. We have no recursion.
+Not turing complete. Limited resources. No persistent memory. Almost no
+context inspection. Most of the interesting opcodes in Bitcoin Script
+are disabled. We want to extend these. We want to give Bitcoin the power
+of smart contracts, before Blockstream sidechain Elements Alpha becomes
+better known to the public.
+
+Off-chain contracts is one way to do this. You could have oracle-based
+model, like Codius. This was tried by Ripple, but was later deprecated.
+Someone proposed a tamper-proof open-source hardware platform, like
+Andrew Miller's recent paper. This is obviously difficult to do.
+
+Another way to do smart contracts is to do on-chain verification and
+off-chain execution, using hybrid techniques like SNARKs (libsnark etc.)
+which is very promising but it has some drawbacks, like right now it
+seems to require a trusted setup, and it's not battle-tested. So it
+could be problematic for implementing in Bitcoin right now.
+Zero-knowledge contingent payments are using SNARKs right now.
+
+Another way is to do on-chain deterministic replicated execution. Once
+you have this setup, you can emulate smart contract execution on SNARK,
+but with a minimum cost. So the solution allows you to grow into any
+other possible of smart contract solution.
+
+The history of practically implementing smart contracts begins in 2013
+with QixCoin which was determinstic... created only for gaming and
+gambling. At the time I was working on peer-to-peer poker playing. I
+implemented a prototype which is similar to today's Ethereum. I was
+aware of the financial applications but I was focused on poker.
+
+The following year, Ethereum came around. And over the last year we had
+Counterparty which implemented an Ethereum-compatible VM. And then we
+presented Rootstock.
+
+A smart contract is a program that is given persistent memory. This
+memory is protected from access by other contracts. It also has a
+digital safe deposit box where it can deposit other crypto assets, such
+as currency. It can create deposits and payments. It can receive
+messages and send messages, to interact with other programs and other
+smart contracts within the blockchain.
+
+What is a distributed application? It's a collection of smart contracts,
+together with the external applications that interact with them. One
+example is a protected wallet that stores BTC and USD and in order to
+pay $1000 per day into BTC or USD, to do this the smart contract to pay
+more each day, it would ... to authorize more spending. And at the same
+time, it has to see what is the value of the Bitcoin each moment, to be
+able to restrict Bitcoin spending. It has to interact with two other
+smart contracts which are probably created by the same people. The
+design which includes 3 smart contracts, each one interacting with each
+other, and also interacting with external applications like graphics
+interfaces and gateways to other systems, etc.
+
+So why did we choose Bitcoin? Why not create yet another new speculative
+token? It's clear that Bitcoin is the most secured decentralized
+cryptosystem. With the advent of the 2-way peg, we can do almost
+anything with Bitcoin to do almost anything that other blockchains can
+do. Also, it has the most real-world use cases. It has a large head
+start, large network effect, and most importantly, we have been part of
+this community for more than 4 years and we love it. Even if there is
+argue all the time, we feel part of it.
+
+The team is, these are the six founders: Gabriel Kurman, Diego Zaldivar,
+.... slide gone.
+
+We setup ourselves into roles last November. We want this to be a smart
+contract layer for Bitcoin. We want it to be democratic yet
+decentralized. We want to increase the number of use cases for Bitcoin.
+We want financial institutions to comply with their regulations and
+develop their use cases over Rootstock. We want to incentivize the
+Bitcoin and Ethereum community to test our platform. Most important, we
+want high incentives for Bitcoin miners. They are the ones that are
+doing the security. We can't forget that. We want them to be 100% mining
+on Rootstock. We have managed to do this I think. And trying to kind of
+solve a few things.
+
+We are trying to bring all the actors, we are trying to test the
+different, bring all the actors to form a community and try to design
+which will be the changes in the standard. Of course, we want to have
+low transaction fees, high transaction rate, we want to scale a little
+more than Bitcoin, maybe 100 transactions/sec to 500 transactions/sec
+without trouble. There is a tradeoff with decentralization, it's not
+free, I think we already have a decentralized Bitcoin so we want to be
+more scalable on top of Bitcoin.
+
+These are the incentives for the Bitcoin ecosystem for the governance
+platform. There's nothing new here. There's a federation. Essentially,
+the two interesting protocols are for, for allowing Bitcoin users to
+vote, we are using proof-of-stake. This is something we are trying. It's
+something new. We are going to try to reward, to give votes to full
+nodes. Bitcoin full node owners, or Rootstock full node owners, and
+through a cryptographic construction called proof-of-unique blockchain
+storage, where we can test onchain if these nodes are holding a unique
+copy of the full blockchain.
+
+What's the tech? What's new in Rootstock that we have created? We have
+the smart contracts. We are doing this as a ... compatible with... we've
+seen a lot of companies, each day we have a call with a company that
+wants to develop in Rootstock, we tell them OK, start working on
+Ethereum and then if you want you can switch. That's important for us
+because we want to see a standard. We don't want to have different smart
+contracting platforms. I think Rootstock can be that standard for
+Bitcoin. We have the 2-way peg which allows the Rootstock platform to
+use Bitcoin as a native currency. Because we have that fully 2-way peg,
+we need some new opcodes on the Bitcoin side, we will start with
+something simple, a hybrid - a federation and a sidechain.
+
+The federation will have custody of the BTC funds. And then a sidechain
+on the Rootstock side, until we have a fully automatic 2-way peg on
+Bitcoin.
+
+Also, we are doing merged mining. Bitcoin miners will be able to mine
+the Rootstock blockchain with the same mining power from Bitcoin, with
+no loss of profits on the Bitcoin side. We are making sure that when
+they do merge mining with Rootstock they will never lose out on Bitcoin
+mining.
+
+The federation has a few rules. We begin to protect the network using
+checkpoints, distributed by the network. If a node wants to know if it
+is being sybil attacked, it can use the federation checkpoints as a
+second mechanism to make sure it's connected to Rootstock. We are also
+providing a fallback system where if the merge mining ever goes below a
+certain threshold, then the federation can use byzantine fault tolerance
+consensus to take control and take activity of mining on their
+shoulders. I think this will never happen, but we want to make sure the
+network will keep running even if we lose miners.
+
+The Rootstock network we are having interesting technical improvements
+in terms of low latency for example. What is different? Well, in the
+first release, it's actually integrated interpreted VM compatible with
+the Ethereum VM. But in the next release, in the works, we are doing
+dynamic retargeting of some opcodes into a java-like bytecode. We will
+be able to use java to develop distributed applications. We will test
+this soon.
+
+We will have a just-in-time (JIT) compiler for this.
+
+Regarding the interface and higher-level applications, ... called Web3.
+This standard is pretty solid. We are implementing that. If you write an
+application in javascript that uses Web3, switch the network and you can
+use Rootstock.
+
+Regarding the 2-way-peg, there's a problem. We have two blockchains. One
+is the main Bitcoin blockchain. The other one is the secondary chain.
+And you want to move BTC from one blockchain to another. The problem is
+that this is not possible. You have to lock or destroy the BTC on the
+Bitcoin blockchain, and then create the same amount of Bitcoin on the
+other secondary chain. Eventually you might unlock the Bitcoin on the
+Bitcoin blockchain. You need a protocol that enforces that the Bitcoin
+are never unlocked on both chains at the same time. There are a few ways
+to do this.
+
+One is to use a federation, using multisig where, of course, you want to
+have renowned parties taking part of the federation. OP_CHECKMULTISIG.
+
+The other solution is to use a sidechain, which is the concept that
+Blockstream has developed, which requires two new opcodes on the Bitcoin
+side. This is kind of problematic because these opcodes allow you to
+interpret other blockchains which uses the same transaction format as
+Bitcoin. This is limited. OP_WITHDRAWALPROOFVERIFY, OP_REORGPROOFVERIFY.
+
+The third one is called Drivechain, proposed by Paul Sztorc, which
+requires a single new opcode. OP_CHECK_VOTES_VERIFY.
+
+You could mix some of these solutions together. You can have groups
+validating and votes maybe. I am going to skip the part about how
+sidechains and drivechains work. Basically I would say that a drivechain
+is a way for miners to vote on which is the transaction that will unlock
+the bitcoins. If the miner engagement in Rootstock is high, then the
+same group of miners will have the same power about how to unlock the
+bitcoins, which is the same as in a sidechain anyway.
+
+What we have now, what have we implemented? We are using a hybrid
+federated sidechain solution. We don't need new opcodes on the Bitcoin
+side. There is a Bitcoin address for the federation. On the Rootstock
+side, we have a full SPV node running on the Rootstock side. That SPV
+node is synced to the Bitcoin network through external messages. This
+provides the locking and unlocking services for Rootstock users and
+Rootstock smart contracts.
+
+The bridge takes a long time to transfer Bitcoin to Rootcoins (which are
+Bitcoin-specific coins). We must protect the network from hacking, long
+reorgs, and if that occurs, it could create bitcoins that live in both
+blockchains. We're partnering with market makers and exchanges to
+provide liquidity just to trade 1 BTC for 1 Rootcoin, more immediately,
+in less time.
+
+How does the federation work? It's running special software called a
+FedNode that runs a Bitcoin node and a Rootstock node at the same time.
+The FedNode listens to events created by the bridge. It just has to obey
+the messages. The bridge will say here is the transaction to sign, the
+FedNode has to transmit to the bridge the signature, then the bridge
+assembles all the signatures, creates the transaction, announces the
+transaction that has to be broadcasted on the Bitcoin side. There is no
+intervention by the FedNode of which outputs to spend or anything else.
+
+This is how it works. Basically, we have these bitcoinj nodes running
+SPV node, in the matrix, because these bitcoinj nodes think they are
+connected to the network. But really it's a separate world in a smart
+contract. Nodes can send headers over this bridge, they can also send
+the transactions that lock the BTC, with an SPV proof so that the bridge
+contract can receive those BTC and release Rootcoins. So the bridge
+actually has a Bitcoin wallet, a copy of the Bitcoin blockchain, and a
+Rootstock account to unlock the Rootcoins. This Rootstock account
+initally has 21 million "BTC" locked in an account.
+
+Here's another diagram of how the federation works. There are several
+fednodes running connected to both networks. The other one is a fallback
+system which could take control of the mining operation if the mining
+hashrate goes below some threshold. This could be fooled, that's true.
+
+So what is needed to implement the two-way peg? We need new opcodes on
+the Bitcoin side, to do either a sidechain or drivechain. This could be
+done with a soft-fork or a hard-fork. We are sponsoring an approach to
+this, called Bit2, which will bring these opcodes to the community to
+consider which path is the right way to go. We would like the Bitcoin
+community to decide. Soon we will have much debate over how to extend
+Bitcoin. I think Blockstream will be very interested in participating in
+Bit2.
+
+Another thing is the checkpoint protection provided by the federation,
+which allows for nodes to prevent Sybil attacks or at least check that
+they are being attacked.
+
+Rootstock uses merged mining. We have 10 second block intervals. We have
+tested and simulated this. It works pretty well. We have no loss in pool
+efficiency for Bitcoin mining. This is important to us. We are paying
+fees to the bridge contract using the SPV proof, the proof-of-work that
+Rootstock uses. This diagram shows how a proof-of-work of Rootstock...
+it contains... the SHA.... you can embed the tag and a hash of the
+Rootstock blockchain header in the last part of the ... and you don't
+have to transmit the full .. transaction.. just the mid state, the tail
+of the coinbase transaction which has a hash and that hash maps to the
+Rootstock header, and you also transmit of course the different nodes in
+the merkle tree to be able to map that into the Bitcoin header.
+
+One of the other things we have been working on is the integration with
+the most known and used mining pool softwares because we wanted the
+miners to be able to run our nodes on merged mining. So we created
+pladdings for these three implementations, ckpool, and another stratum
+mining pool. These will be available when we are ready. CoiniumServ,
+ckpool, eloipool (python).
+
+So what's new in terms of network? The network we aim to low-latency. We
+tested, we can have 300 transactions/second at 10 block sec interval. We
+have implemented mostly known tricks about how the network can operate.
+We have two-stage block propagation, we first propagate the header of
+the blocks in kind of a algorithm where the header propagates as fast as
+possible so that miners can mine only on top of the header. Miners have
+a timeout where they switch away from what they were doing, if the
+header does not come with block information.
+
+We have some local optimizations in each node. Some local route
+optimizations can be made to embed into the network, a graph that is
+more friendly to block propagation. Local Route Optimization (LRO). You
+can find the near minimum path between miners using the network itself,
+and you don't have to have another low-latency centralizing network like
+in Bitcoin.
+
+We are implementing the GHOST protocol. We are implementing the DECOR+
+protocol, for reward sharding between competing blocks. The selfish
+mining problem completely disappears. The competition for latency goes
+away. We can have much higher block rates because of this.
+
+This is an explanation of how DECOR and GHOST work together. This is a
+case where we have 3 competing blocks. Block X, block W, block Q. The
+miners can include reference to these other headers. They can receive a
+reward for including those other headers. The block reward of block X is
+divided almost evenly between all of the competing miners. There is some
+extra reward that some miners will get. There is a punishment fee for
+having uncles, which pushes the network to optimization rather than
+having everyone trying to create uncles.
+
+In the future, this will come in the first hard-fork maybe, we are doing
+the optimization in blockchain sharding, probabilistic verification,
+fraud proofs, we will be implementing Schnorr signatures. We will have
+agility. You can use whatever signature algorithm you can think of. Also
+we will be doing special proof-of-stake voting. Users can use that key
+to vote with their Rootstock stake, but prevent the ... to have two
+different key lifetimes, one for the monetary asset protection, and
+another just for voting, which is useful for proof-of-stake.
+
+This is a comparison between Counterparty, Ethereum, Rootstock VM
+implementations. We have tried to improve every feature of the network,
+like average confirmation time, mining security threshold, denial of
+service protection, incentivizing mining, etc.
+
+Talking about distributed applications, moving from the technical part
+to the community part, micropayment channels, hub-and-spoke networks,
+peer-to-peer decentralized exchanges, issued assets, asset
+securitization, fiat-pegged assets with BTC collateral (using oracles),
+IP protection and registration like NameCoin and DNS, supply chain
+traceability. The whole network can be implemented with like 100 lines
+of smart contracting code. Lightning network will therefore be much
+easier to implement on Rootstock. We also want to support fair gambling
+over the internet, we want to implement crowdfunding, and also voting,
+prediction markets, these are all applications that have been widely
+discussed in the community.
+
+HOw is the project going? RSK labs. In November we published a
+whitepaper, in December we started coding, in January we founded a
+company to have funding, we received seedfunding from a very strategic
+partners like ... digital currency group, I don't know if they are here.
+Thanks. We have received more than, in funding... we are sure that we
+will get to our goals. In February we hired 6 senior developers, 3 which
+are internal to Rootstock, 3 which are outsourcing. We are developing
+industry partnerships and with companies that want to work with us.
+
+In March we are on schedule for first alpha release in April. How are we
+able to do this? We took the improvements from Bitcoin, we took code
+already written, we don't want to write anything from scratch. We took
+ethereumj, and bitcoinj, we brought that code into Rootstock. Qixcoin.
+
+In April, we are doing a private testnet for a few partners please ask
+us if you want to participate. In July we are deploying our first public
+testnet. In August, we will establish a federation. In September we want
+the RSK launch. In December, we are going to test release 2 of the
+platform. In January, we will have a governance body established to take
+positions on how the protocol should be improved in a more democratic
+more contentious way. And in Q1 2017 we will have our first hard-fork.
+
+Rootstock is a combination of 4 years of blockchain tech improvement.
+It's from the entire community, it's not just our own work that we are
+reusing here. This is the benefit of being second. We want the Bitcoin
+miners to participate in the smart contract revolution. We've got
+excellent support from them. That's very important to us. Also, we
+managed to get ethereum applications running on our platform without
+problem. Most improtantly, and since I come from the third world, we are
+working with the third world companies to develop applications for the
+unbanked. They are developing their pilot use cases over Rootstock. The
+whitepaper is available on our website, thank you.
diff --git a/__transcripts__/mit-bitcoin-expo-2016/scaling-debate-is-a-proxy-battle-over-centralization.md b/__transcripts__/mit-bitcoin-expo-2016/scaling-debate-is-a-proxy-battle-over-centralization.md
new file mode 100644
index 0000000..6a2988c
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/scaling-debate-is-a-proxy-battle-over-centralization.md
@@ -0,0 +1,265 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Scaling Debate Is A Proxy Battle Over Centralization
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} James D'Angelo
+
+The Scaling Debate is a Proxy Battle Over Centralization
+
+I really appreciated the fact that.... I really appreciated Cory's talk.
+I quoted someone in my talk. It was a fairly recent quote. His whole
+talk was speaking about governance. There's a lot of governing issues
+coming into Bitcoin. We like the solving the whole world with technical.
+
+The word that I am fascinated with is the one highlighted here, the word
+"consensus". I'm just going to reach out to you guys. Does anyone want
+to make a stand at telling me what consensus means? Agree? I like that.
+It's important that we understand consensus. People say that it's
+decentralized consensus. The idea of no one entity controlling it.
+
+When you say entity, no one entity controlling it. It's an abstraction
+of agency. A group being able to make an authoritative decision. A group
+of what? Individuals. I want you guys to think about these terms. When
+you guys say that consensus is only about proof-of-work and algorithmic
+consensus, that's not what I mean. Economy of scale? Does anyone want to
+tell me what economy of scale is? Connor, you made it in, I'm sure you
+didn't sneak in and spoke with someone, I definitely want to talk with
+you, he's going to be running big stuff soon... what's an economy of
+scale? Production of the point of being able to make profit.
+Interesting. Anybody? The more you produce something, the cheaper it
+gets. Matthew, thank you. The more you produce something, the cheaper it
+gets. Like a flower in June, let's move.
+
+A pen should write. My talk, which I am starting right now, is that a
+pen should write. I hope you all learn that today. A pen should write. I
+can use a pen to defend myself. You take your pen, and then say, oh
+Amazon, right, and you get the box open. Oh, I ordered cliff bars online
+even though they cost the same next door. Anybody want a pen? My son has
+a thousand of them. I hear you. Alright.
+
+I can use a pen to defend myself. That's pretty cool. I'm sure it's been
+done. People have killed each other with pens. How many of you have been
+in jail? Oh a bunch of libertarians never been in jail? I can use a pen
+to smoke with, how many of you have done this? I did that. It tastes
+horrible, by the way. I'll bet it's bringing in more carcinogens than
+the stuff you're smoking.
+
+But pen manufacturers aren't going to lose two years talking about how
+to make pens into better weapons or pipes, are they? It makes sense. The
+essential feature of a pen is to write. That's the sine qua non of a
+pen. Who speaks latin here? You are all liars, nobody speaks latin.
+
+Does anyone know what the sina qua non of a pen? "That which it is not."
+If you have a pen, it is essential that it writes. What is Bitcoin's
+sina qua non? Non-political money. Settlement support. Permissionless
+transfer of value? I might end up arguing with all of you.
+
+The "sina qua non" of Bitcoin is decentralized consensus. On top of that
+you can build everything else. On top of your pen, you can kill people,
+you can smoke, it can open boxes from Amazon, but it must write. Bitcoin
+needs decentralized consensus. It's the only essential feature of
+Bitcoin.
+
+A decentralized consensus allows for a currency, it requires no
+third-party. Nothing matters next t this. Anonymity, nope. Lately,
+however, there has been this little block size scaling debate. Cory
+might have noticed this. You hear that investors want speed, customers
+want cheap transactions, just go to 2 MB blocks, I don't know who says
+that. "Bigger blocks solve everything". Yeah right. This block size
+scaling debate is bunk. Why?
+
+It's a proxy war. It's like when the United States goes into Vietnam
+because they want to fight Russia. It's a battle against dangerous
+centralization. If it becomes centralized, it's no-longer censorship
+resistant. Imagine a currency where censorship is available. Well, then
+it's not a currency. The dream is gone and we have nothing.
+
+"Bitcoin is as decentralized an institution as possible" -
+gavinandresen, it's probably a dated quote so I won't sa yit.
+
+"You have centralization on the low end and the high end" - jgarzik
+
+When you get down to small blocks, you might get centralization that
+behooves those with more money. You might have to take your money to
+Coinbase or something. If block size is pushed upward, nodes are pushed
+off the network, and miners do pretty well. The economy of scale might
+do pretty well.
+
+"(Centralization at the 1MB end) isn't a particularly dangerous type of
+centralization" - petertodd, I kinda agree.
+
+So what is this dangerous type of centralization? Is it the large mining
+pools? No. Some say it's off-chain settlement. But these are all
+subscriber-based centralization. A mining pool doing bad things, you can
+leave them. Miners can choose to leave pools. It's a subscriber-based
+institution. Coinbase is a subscription-based institution. That's a nice
+feature of any market dynamic. The bad dangerus centralization is not
+mentioned in WSJ or whatever. Bad centralization is the owners of the
+mining hardware.
+
+They are centralizing, but how much? Anyone know how much? Nobody knows
+how much? I thought this was important. Is it possible that one person
+right now controls all of mining? Or over 51%? Is it possible that one
+person can control more than 51% today? It depends on how much money
+they have. You do mining in China? By the way, I love you guys. I would
+say a lot of the arguments about China, mostly the people in the United
+States think they are stupid. You will see why later. It's a stupid
+mistake. Are Chinese stupid? Sometimes. Yeah, you have some smart guys
+over there. Some of you guys like to do backroom deals. I'm Sicilian, so
+I understand black-room deals, but we just copy off the Chinese. They
+really know how to do backroom deals. We'll talk about that.
+
+Last year I was hearing abut a mining oligarchy. I like that term. It
+sounds cool. Measuring decentralization is difficult. Why can't we say
+the miners are Chinese? It's because we don't know who they are. It's
+probably one guy who owns all this. Measuring decentralization is
+difficult. Measuring Bitcoin decentralization is impossible. Is it
+kosher for us to use the word decentralization if we don't even know if
+it exists? Maybe we should drop that word.
+
+A centralized consensus is an oxymoron. A centralized consensus is an
+oxymoron for civil war. Decentralization has nothing to do with
+hardware, nodes, It has nothing to do with hardware. You can go to
+Amazon's cloud and make a million nodes right now. I can do that right
+now. It would look pretty good. Oh we had 5,000 nodes right now? Oh look
+it went to a million nodes and 5... great.
+
+Decentralization requires counting human noses. Each nose should have
+one vote. Bitcoin does neither. In early 2013, almost everyone in
+Bitcoin meetup groups were miners. But now almost nobody there is a
+miner. We can't go back to mining. Folks who own massive amounts of
+hardware, they choose to opt-in. If they want to centralize, they can do
+that.
+
+The ugly axiom is that the two are inversely proportional or maybe even
+impossible. Even if blocks are lowered to 1 kilobyte, big miners are
+still subject to economies of scale. To assume that the chip
+manufacturers in China are not colluding, to print cash, it's utter
+foolishness. They can sell their old chips to KNC, ... etc. What's your
+definition of collusion? Check google.
+
+Even if segwit and lightning network, both genius great ideas, even if
+they were both working today, mining will continue to centralize
+exponentially. They just make it cheaper for those people to centralize.
+Dear engineers, not everything can be solved with more technology. No
+hardware or software solution will return us to 2013 where most people
+with small rigs were mining.
+
+Satoshi made a fatal mistake. What was that mistake? His mistake was
+"Proof-of-work is one-CPU-one-vote". I have 3 CPUs in my house, all of
+them are crapping out, none of them are making money from mining. He
+says that proof-of-work, and he's defining it here for you, he said it's
+one CPU one vote. He uses that word vote, I like that word vote, I
+studied voting. He understood voting decentralized. That's all he
+understood about it. The only way to decentralize things is by voting.
+The only way to decentralize anything is by voting. There has never been
+any form of decentralization, there never will be, it requires identity,
+it requires one person one vote. petertodd made a point earlier today,
+he said we need identity. I think it could work, he disagrees.
+
+Proof-of-Work is just proof-of-wealth. It's broken. Decentralization can
+only work if you have real identity. If we voted for miners like we vote
+for politicians, then we can prove it's decentralized, we can scale
+infinitely. It's infinitely faster and infinitely more scalable.
+Proof-of-work is just slowing us down.
+
+Is this possible? If so, tihs doesn't change the most important type of
+anonymity, which is transaction anonymity. We can either have anonymous
+miners, a large unscalable network and massive centralization, or we can
+have Satoshi's dream. That was decentralized consensus. Unless we inject
+identity.... this will also help with Bitcoin governance, we can elect
+people, we can decide on stuff, we can have dates and times and stuff.
+How long will it take for the libertarian mob to realize that politics
+has benefits? No governing body has ever been as decentralized as
+Bitcoin. That's good and bad. Our governing body, which doesn't exist,
+is all of us arguing on Reddit. We can't vote, there's no way to do
+anything, because we wait for the mob to go crazy. What does Satoshi say
+about governing Bitcoin? Day 1, Satoshi ran Bitcoin on 50 machines we
+suspect. There was an outage in the first few days.
+
+Maybe he wanted 1 BTC per machine, because 50 BTC was the original block
+subsidy. I would argue for another reason. If you are going out on day
+1, and you are concerned about this project, and there's a flaw in it,
+does he want to reach out to the decentralized consensus to make an
+upgrade? Or does he want to instantly run a 51% attack, slap on an
+upgrade... he did it to run a 51% attack on Bitcoin. He likely ran
+hundreds. He also had hidden hard-forks in some of the early git
+commits.
+
+Early decentralization terrified him. He wouldn't be able to run
+updates. This is what he did to make decisions, to move faster, to
+upgrade things. He sacrificed everything to get to his final goal. To
+get to decentralized consensus, you must start with centralized decision
+making. Satoshi was focused on making a pen that writes.
+
+Bitcoin isn't protected by math. It's protected by us. It's a social
+consensus. It's people. It requires voting and politics and convincing
+majorities. Jihi Peng in China could take over Bitcoin right now.
+
+So if you have problems with this, blast me, @JamesGDAngelo. I want to
+be wrong. That's it. Do we have time for questions? There's some time.
+
+Mark Friedenbach: You seem to be making a decision that decentralization
+is best used by one person one vote. We already have political money.
+Wouldn't it be good to try non-political money?
+
+James: Yes, I think it's good to try. Try away.
+
+Q: Noses are biometric.
+
+James: Well, I think the fact that everyone has some place in the center
+of their face, I don't think we need to use software to have a nose. I
+am talking about counting human souls. I am not the biggest fan of
+biometrics.
+
+Q: As far as I know, ethereum has been moving away from proof-of-stake.
+Does proof-of-stake make you feel better about this?
+
+James: Dagger, swagger, slasher, vixon, I've been watching this for a
+while. He has moved into proof-of-escrow instead. There's some issues.
+There are economies of scale. The problem is the economies of scale.
+Miners can buy more hardware, cheaper each time. When we see the
+hashrate rising enormously, is there an economy of scale? Yeah, there
+probably is. I am not optimistic that proof-of-stake can work. Does
+anyone understand NxT's proof-of-stake? Write it up or something.
+
+Darren Miller: I have a question about the 21 Bitcoin computer and the
+chip that is in there. What's going to happen in the future with that?
+Does it have any effect on decentralized?
+
+A: If we all got together to save the world, I think that's where 21 is
+going, they don't understand the tragedy of the commons there. Most
+people are not going to invest to lose money. If we all got together and
+put money into bitcoin to save it, there's nothing in the history of
+man, ..... 21 has to solve climate change first. That's my thing.
+
+Joe: You seem to have a dystopian view on Bitcoin. What do you think we
+can do to fix this?
+
+James: We need to... we should not make a Bitcoin congress with 1000
+individuals, and mine. Governance, immediately. We would all respect
+them or hate them if they got mining rewards. We have to make sure we
+have a decentralized base. This happens authentically at about 200
+individual humans. It's hard to rock 200 people with bribery. With a
+thousand, you might be pretty secure. I think it's actually amazing, we
+could go to Visa scaling and type tomorrow, if we did this and if we
+don't, then we can pretend that economies of scale don't work. But they
+do. It really messes us up.
+
+Q: I am new to Bitcoin. I am from China. I would like to ask, what
+percentage of Bitcoin is mining in the United States? Since you assume
+that China has been colluding, and that it's a large community, then
+what about the United States?
+
+James: Like the USSR vs the US and we will both make enormous missiles?
+So maybe the US would buy equally? We don't know those numbers. We don't
+know who's mining where. We don't know if the American miners are
+controlled by the Chinese. You cannot decentralize hardware. You can
+decentralize people, not hardware.
+
+Why are people not hardware?
diff --git a/__transcripts__/mit-bitcoin-expo-2016/siacoin.md b/__transcripts__/mit-bitcoin-expo-2016/siacoin.md
new file mode 100644
index 0000000..21baacb
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2016/siacoin.md
@@ -0,0 +1,182 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2016
+title: Siacoin
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Sia
+
+David Vorick
+
+I have been working on a decentralized cloud storage platform. Before I
+go into that, I wanted to mention that I have been working on Bitcoin
+since 2011. Since 2013 I have been in the wizards channel. In 2014 a
+friend and myself founded a company to build Siacoin. The team has grown
+to 3 people. Sia is the name of our decentralized storage protocol. We
+are trying to emulate Amazon S3. You give your data to Amazon, and then
+they hold it for you. We want low latency high throughput.
+
+We had a bunch of prototypes in 2015. Here's a screenshot of our wallet.
+You can offer your resources to the network. Here's a screenshot of that
+interface. I have 20 GB on this node. I took it last night. Here's some
+music I uploaded. So, cool.
+
+We are going to remind to the modern cloud storage. Normally the data is
+owned by one company. It's usually encrypted and not authenticated. You
+just give them the raw data, and they hold on to it. It's usually
+unencrypted. It's often sitting inside of one legal jurisdiction in one
+geographic location.
+
+Amazon is a profit-making company, well maybe not, but Microsoft is, and
+sometimes the profit motives might not align with your personal
+requirements. In general, the cloud storage space has very inflated
+prices. It's inflated if you look at what storage really costs. The
+numbers are really big to get storage from Amazon. We want to
+decentralize that.
+
+One of the core advantages of decentralization is that the person who
+owns the thing, controls it. In Bitcoin, if I have 10 bitcoins for a
+year, so like 50,000 confirmations, I feel confident that nobody would
+be able to steal those. You would have to steal my private key, or reorg
+50,000 blocks to undo that transaction. That's powerful to me. I want to
+do something similar with data, such that I know the data is mine and
+its destiny is mine to control.
+
+We want to eliminate the trust. Right now we trust Amazon with our data,
+but I don't think we need to. With data, you have some limitations. The
+point is to give data to someone else, and when I ask for it, they give
+it back to me. As soon as it leaves my hands, there's nothing I can do
+to control it. If Amazon decides to unplug the drive, or hold the data
+hostage, there's no amount of cryptography that will save you from this.
+This is part of having data in the cloud. You need to know that people
+can unplug this. You can't attain perfect trustlessness.
+
+Once they have the data, they can share it without your permission,
+unless it's actually encrypted. Once someone has the data, you have no
+control over who they give it to. So these are two things that you can't
+fix. But I think you can do better than Amazon, eve nif you can't have
+perfect control over your data.
+
+With Sia, your data goes to many hosts, covering many legal
+jurisdictions, everything is encrypted and hashed and authenticated by
+default. It's much cleaner ecosystem. We have these contracts that align
+the incentives with consumers. We make sure that the host profit model
+is organized around protecting uploader's data.
+
+We also have an open marketplace where people can provide services for
+cheaper. We hope to create a race to the bottom and keeps up with
+technological trends and improvements. This is what we're aiming for.
+
+The core cryptographic tool is called a file contract. The host is going
+to put money int othis contract, as a promise to keep the data. After
+some period of time, like 6 months, the blockchain is going to trigger
+and say okay host, prove to me that you still have the data. The host
+needs to provide the proof, it gets paid if so, and after a certain
+period of time, and if the host doesn't provide the proof, then the
+money is returned to the consumer or to the void. The host will not be
+paid in te event of a failure to provide proof.
+
+The storage proof by breaking up the file into 64-byte segments, which
+are hashed into a merkle tree, and then the blockchain picks one of
+those segments at random and says post proof that you have this segment.
+At the bottom layer we have the raw data. Blockchain might choose this
+segment here. The host will provide that, and all the hashes at each
+layer, and you have this merkle tree proof, and then proves that it's in
+the merkle root, which is in the file contract itself.
+
+The host proves it for 64 bytes, but the host has no way to know which
+segment. The random number is the block id from the block before the
+contract expires. If the host is only storing half the file, then the
+host has a 50% ability to cheat and submit a proof successfully. Because
+the host also put in money, which means that if the host fails, not only
+does he lose revenue but he will also lose the collateral. If the
+collateral is higher than the potential revenue, so there's no economic
+reason for a host to try and cheat. That's how we align the incentives
+on our network and get hosts to hold on to data.
+
+(But why would a host pay that much collateral into that contract?)
+
+We use something called reed solomon codes. In a 7-of-21 scheme, any 7
+pieces I can use to get to get the original file back. If 14 hosts
+cheat, or blow up, or are unavailable, I'm okay because 7 are online and
+it doesn't matter which 7, I just need any 7. The math works out pretty
+nicely. Even if the hosts are 95% reliable, this is something you could
+do from home, 95% allows you to lose power once a month for a day and
+you still get 95% uptime. In a 7-of-21 scheme, with 95% reliability, we
+get 11 nines of reliability on the final retrieval. If we are using 100
+hosts, we can get 11 nines of uptime, with 95% reliability, for around
+1.4.... so that's a significant cost savings with a number of hosts.
+
+The number of hosts also helps with hostage attacks, where they are
+trying to extort you to get your data back. You don't need to care as
+long as some of the hosts aren't part of that collusion group.
+
+I breezed past a big problem here, which is how to pick hosts. Sybil
+attacks have been mentioned a full times today. Some malicious actor
+could spin up 10 million nodes to pretend to be 10 million hosts. Since
+there are only 100 real hosts, and 10 million hosts, at least 15 of
+those hosts are going to be the attacker, so now the attacker can do
+malicious things with my data. Besides sybil attacks, they can also
+force really low prices, and other things, to force renters to pick bad
+hosts. As a renter, how do I figure out which one to trust my data with?
+
+This is like the weakest part of our protocol. I think that the
+solutions we have are good enough in a practical environment. It's not
+theoretically perfect, but I think it would hold up for most attacks in
+the real world. I think we can account for most of those things. The
+renter can track real-time statistics, iit can do off-chain challenge
+proof requests, it can scan for the hosts, you can do trial downloads to
+make sure none of the hosts are trying to hold data storage. For the
+sybil attacks, you do proof-of-burn where the host has to take some
+percent of their revenue like 2% and throws it away. Makes it
+unspendable. Why would hosts do that? It makes it harder for an attacker
+to fake 10 million hosts. If each of the honest hosts are burning 2% of
+their revenue, that's $100k or something. So the attackers are going to
+have to provably throw away millions of dollars, which only works as a
+deterrent if an attacker does not trust that their attack will be
+valuable enough. So hosts that forego proof-of-burn are unlikely to be
+legitimate.
+
+We can add centralization to help with hosts being reliable. We can do
+KYC, AML to get pictures of hard drives. We can do certifications and
+ratings. You can get a better picture of the network. So an agency can
+devote a lot more resources than an individual for figuring out which
+hosts are safe to use. So the renter will have to trust that agency, but
+if there's a bunch of agencies, then they can compete with each other.
+There's a low trust cost, this is called trust egility. This is
+centralization, we would like to stay away from, but if it's needed,
+it's an avenue to sort of keep the gears spinning.
+
+So one of the final topics is scalability. Blockchains don't scale.
+Bitcoin is grappling with this. Sia has the same problem. We use
+proof-of-work. We take file contracts and put them on the blockchain. We
+have file contract revision channels, it's like lightning payment
+channels but wit hdata. You can upload as many files as you want, it's
+just two transactions on the blockchain, actually three because there's
+a storage proof. So there's only room for 50 million file contracts,
+unlimited data per contract, but 50 million is not that many, because
+each user is going to need at least 20 contracts per year. So 20 hosts
+means 20 contracts. You can't lump multiple hosts into a single
+contract. So if you need more reliability, you might need 200 contracts
+per year. So our scale is like 200,000 users to 2 million users, which
+is not that great. Our platform is targeted to enterprises. We would
+like to see improvements that would get consumer scale as well.
+
+There are potential horizon improvements, a lot of the work that is
+special to us, for 5x to 100x scalability improvements. But even then,
+100x falls short of everybody being able to use the network. Like all
+blockchain tech, we're sort of, we do have this scalability problem in
+front of us, but we don't have 2 million users today, so it's not really
+an issue for us.
+
+Our platform is open-source, we have a community and developers, and
+when people contribute things like plugins and desktop widgets and file
+systems and userspace implementations, everyone benefits. Another thing
+that is unique is we have this powerful cloud storage platform which is
+fast and cheap and secure, and even if you don't care that it's
+decentralized, those things have utility. We can sell this platform to
+people who don't care about decentralization, because it's an aggressive
+highly parallel cloud storage platform.Sia
diff --git a/__transcripts__/mit-bitcoin-expo-2017/_index.md b/__transcripts__/mit-bitcoin-expo-2017/_index.md
new file mode 100644
index 0000000..1dd0758
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2017/_index.md
@@ -0,0 +1,7 @@
+---
+layout: default
+has_children: true
+title: Mit Bitcoin Expo 2017
+---
+
+{{< childpages >}}
diff --git a/__transcripts__/mit-bitcoin-expo-2017/bitcoin-mining-and-trustlessness.md b/__transcripts__/mit-bitcoin-expo-2017/bitcoin-mining-and-trustlessness.md
new file mode 100644
index 0000000..19be1a7
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2017/bitcoin-mining-and-trustlessness.md
@@ -0,0 +1,163 @@
+---
+parent: Mit Bitcoin Expo 2017
+title: Bitcoin Mining And Trustlessness.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+parent: Mit Bitcoin Expo 2017 title: Bitcoin Mining And Trustlessness.Md
+Hidden: true TranscriptBy: Bryan Bishop
+
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2017 title: Bitcoin Mining And
+Trustlessness nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Bitcoin mining and security
+models
+
+Matt Corallo
+
+2017-03-04
+
+
+
+
+
+Yes, something like that. As mentioned, I've been contributing to
+Bitcoin Core since 2011 and I've worked on various parts of bitcoin,
+such as the early payment channel work, some wallet stuff, and now I
+work for Chaincode Lab one of the sponsors-- we're a bitcoin research
+lab. We all kind of hang out and work on various bitcoin projects we
+find interesting. I want to talk about reflections on trusting trust.
+
+For those of you who are too young to have read it, it's a great paper,
+it's about trusting compilers and it's from the 80s. First I want to
+talk a bit about what is bitcoin. Not technically. We have had a bunch
+of presentations covering the details of the blockchain and what most
+people are aware of a chain of blocks and transactions. But what is
+bitcoin socially? I don't want to talk about private blockchains because
+they are just cryptographic audit logs, they are a different class of
+thing.
+
+It's useful to put bitcoin into context. Bitcoin is the first ecash
+scheme that didn't have a centralized trusted third party. This turned
+out to be critical. There were schemes that were centralized in some
+way... chaumian ecash and great features for privacy, but they had some
+trusted centralized third party and they all failed in one way or
+another, like paypal which failed at their original goal. They were an
+ecash scheme with lots of privacy and then the government told them they
+can't do that and they changed their system. Or what about Digicash? The
+system was good but the business was unable to make money. Bitcoin
+endeavored to fix this by removing trust and all trust requirements.
+
+David gave a great talk earlier about full nodes, every full node
+validates everything; you just trust the software you are runnig, with
+the caveat of double spend protection... which is the job of miners.
+Keep in mind that the hashing has a cost. Bitcoin endeavors to be a
+trustless system, but maybe doesn't always succeed. If you want to
+assign a cost to undoing your transaction, bitcoin succeeds there. The
+cost to reorg a month or 6 months of bitcoin blockchain which has actual
+investment and hashrate-- all the sudden you can make reasonable
+arguments about the security.
+
+Waiting a week or month for a payment to confirm, that's uncompetitive
+in the payments industry. When people use bitcoin for payments, yeah
+they relax this trustlessness requirement. Ultimately I think it should
+be roughly clear to people that pretty much every use case of bitcoin
+extends from trustlessness in some way. Some people see bitcoin as an
+interesting hedge against the US dollar or fiat. Maybe you don't trust
+the Venzeluen bolivar, which is currently worth effectively zero. But
+maybe you're OK with trusting miners? Maybe you only care about the 21
+million bitcoin limit, and as long as you're running a bitcoin full
+node, you can make sure that stays true.
+
+Payment processors act as trust anchors in payments. Merchants trust the
+bank. They don't have to trust each customer that walks into their shop.
+Banks have to trust their customers, and this actually leads to
+censorship issues where banks don't have to actually give you service.
+Also the government can cause banks to not take you as customer.
+
+Some people talk about bitcoin as a global currency. They are still
+interested in the trustlessness. If you are sitting in the US, maybe you
+don't want to trust a US bank.
+
+... you do have to trust the bitcoin community at large. When you take
+your bitcoin and put them in your full node or your bitcoin bank or
+whatever, ultimately you're trusting that the people pushing for the
+bitcoin brand are pushing for the bitcoin that you own or that you want.
+If the entire rest of the bitcoin community decides to hard-fork and
+increase the 21 million coin limit, all of the sudden the trustlessness
+property goes out the window. Ultimately what you're really trusting in
+for many bitcoin use cases, or the most trustless bitcoin use cases,
+it's a trust that the community will stay together and enforce the
+requirement that changes must have consensus and that the bitcoin system
+will continue to be the bitcoin system you care about. This is where
+David's talk about everyone should run a full node and clearly defining
+and not trusting everyone to be on the bitcoin system that you care
+about... but if you lose control of the brand, perhaps that system is no
+longer worth as much to you.
+
+For the future of bitcoin technology, and for what people use bitcoin
+and how they use bitcoin, is that people should be able to relax these
+trust requirements. Almost all the use cases of people using bitcoin
+isn't taking a transaction and waiting 6 months so that they aren't
+trusting anyone, well they are trusting Coinbase or Bitpay and using
+only 1 confirmation. Trust relationships aren't inherently bad, they
+just add cost when you are forced into them or when they can be
+exploited.
+
+When we talk about lightning network or tumblebit, it's trusting miners
+a bit, you can accept 1-6 confirmation transactions and in lightning
+it's trusting that you will be able to get a transaction into the
+blockchain within 1-6 days or whatever. These are also relaxations of
+trust, but they are relaxations of trust that people are okay with in
+the current bitcoin environment. Taking advantage of these trusts makes
+the system more usable. You get lightning, tumblebit, sidechains. Or SGX
+if you want to trust Intel. They make bitcoin the currency more usable
+even if people aren't actually using the bitcoin protocol.
+
+The only way that bitcoin succeeds, because of this property where the
+only way for bitcoin to succeed is where the community enforces the
+consensus property; therefore the community must only change bitcoin
+with consensus. It's where we have freedom to innovate on top, using
+bitcoin and lightning and whatever, but that they are able to use these
+systems interoperably without using the chain unless they really do not
+trust any of the miners and want to wait 6 months for their payment.
+They should be able to do that. But the only way that this works is if
+people who have trust relationships can take advantage of those on a
+regular basis for most of their payments.
+
+That's most of what I wanted to talk about in terms of trying to make
+points. If anyone has questions, now would be a great time. We're an
+hour ahead of schedule so we do in fact have time for questions.
+
+Q: The one thing that I take from your presentation... the really
+attracted to.. bad people wanting to do bad things using bitcoin to
+facilitate that.. are there any... if things got really out of hand,
+like a lot of bad people doing bad things, ... is there..?
+
+A: Bitcoin is a trustless system. In order to provide this property, it
+must be able to take advantage of it and do bad things with it. I would
+characterize it differently though. Because it's ultimately the ways
+that bitcoin is useful is using systems on bitcoin, like utilizing
+bitcoin as an asset to transact safely, you can bake anything you want
+into those systems, like zero-knowledge proofs that you are paying your
+taxes, or the same way we enforce money transmission laws today. If you
+fly a suitcase of cash to Iran, you're going to prison, not because the
+transaction is blocked, but rather because you go to prison. I gave a
+talk in Berlin a few weeks ago, digging into that. Essentially I made an
+argument that-- as a society, we have to have a lot of discussions about
+how far censorship can and should be allowed to go. I drew parallels
+with the Snowden disclosures with government monitoring of your phone
+and internet usage and it's even worse in the UK now, with a lot of the
+financial censorship in the US. It's somewhat common practice under the
+Obama administration for DOJ to show up at banks and insist that the
+bank not do business with someone simply because the DOJ was asking.
diff --git a/__transcripts__/mit-bitcoin-expo-2017/exchange-security.md b/__transcripts__/mit-bitcoin-expo-2017/exchange-security.md
new file mode 100644
index 0000000..43455cc
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2017/exchange-security.md
@@ -0,0 +1,227 @@
+---
+parent: Mit Bitcoin Expo 2017
+title: Exchange Security.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2017 title: Exchange Security
+nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Exchange security
+
+Mitchell Dong
+
+2017-03-04
+
+
+
+
+
+How often do you check your wallets? Have you ever looked in your wallet
+and found all your bitcoin gone or missing? Last summer, somebody, a
+friend of mine checked his wallet and found that 100,000 bitcoin was
+gone. What the hell, right? But that's what happened at Bitfinex last
+summer. Some hacker got into their hot wallet and stole 100,000 bitcoin.
+This was $70 million bucks. Of which 1.5 million was mine.
+
+I spent the last 6 months trying to figure out how to... to understand
+it, how to manage it to minimize the chance of this happening again.
+What have I studied in the past 6 months to try to prevent future
+losses?
+
+First some background on what happened last August 2016. On August 2nd,
+the Bitfinex... let's see. No slides? What's that? Ah, it's over here.
+Okay. Alright. How do I go back? I'm going forwards, so how do I go
+back? Okay. I'll leave it on there.
+
+So last August, when Bitfinex was hacked, 36% of all their digital
+assets were stolen, both.. their digital assets. Bitfinex decided to not
+go bankrupt like MtGox did. Instead what they decided to do was try to
+continue and promise to pay back the people that lost the money. They
+did that by issuing first of all they socialized all the losses. Even
+though not all of the bitcoin--- as I said, 36% was stolen. None of the
+whitecoin was taken, none of the cash was taken, only the bitcoin. They
+first decided to socialize the losses. 36% of all their assets, everyone
+took a haircut of 36%, no matter what assets you had or who you were.
+And then they issued IOUs, promises to pay them back. These were in the
+forms of digital tokens called BFX. These tokens were freely tradeable
+on the exchange, they traded between $0.20 and $0.80 cents on the
+dollar. This was a way for the market to predict whether they would get
+their money back. Bitfinex offered to exchange these tokens into equity
+in the company, at a price of about $200 million valuation. So $70
+million losses converted into a company worth $200 million roughly. So
+eveyrone who lost bitcoin, had the right to take 1/3rd of the company.
+So people would be able to get back their losses and to enjoy the cash
+flows of the company. We felt this was a better solution than MtGox
+because in MtGox only the lawyers make it out okay. And here there is at
+least a chance of you getting your money back.
+
+Since then, we're a market maker and arbitrageurs. We look for price
+differences. We buy in the US and sell in China. Buy in Europe, sell in
+Japan, etc. On a second by second basis. We have to keep money on all
+the 15 different exchanges. Having money on an exchange is counterparty
+risk, which is the chance that the person you have your money with, goes
+under, or they are hacked, or they steal the money, or there is some
+loss. So we have to assess counterparty risk. What did we do to assess
+that?
+
+Well over, let me see if I can get that, so uh, what we did was we
+first... this is a list of 16 different exchanges that we interviewed.
+They are located in the US, China, Japan, Europe, a few other places.
+They range from relatively early stage bitcoin exchanges to more mature
+bitcoin exchanges. They range in volume from 100 bitcoin per day to
+100,000 bitcoin per day. There's a mix between the big and the small. We
+interviewed all the CEOs of these exchanges. We asked them some basic
+questions. Some of the questions are showed here. How do you protect
+your hot and cold wallets? How do you prevent internal fraud or
+collusion? If there is a loss, would you cover customer losses? Do you
+have those reserves? Financial health is very important. So we asked
+whether they... I am not used to this laptop. Are you profitable? Do you
+have insurance? Do you have a bitcoin or banking license? Do you have a
+good relationship with regulators, with your bank? Tell us about
+lawsuits you have against you. And what are the other securities?
+
+We spent 3 months interviewing these CEOs, CTOs, CFOs, asking them all
+these questions. I am going to summarize the lessons learned from this
+interviewing process or survey, if you will. Integrated in this is, what
+we believe are the best practices. One cautionary note is that-- these
+results are generic to what we learned across all 16 exchanges. I'm
+going to avoid making comment on any one particular exchange.
+
+We like to do business with only profitable exchanges. Ones that have
+financial resources to constantly invest in improving security. We like
+exchanges where owners have a strong stake in keeping it going. If it's
+not profitable, owners have less incentive to keep it going. If it's not
+profitable, it's harder to attract tech talent, because we know how
+highly paid they are. Next, we like big name VCs because they do a lot
+of diligence. I like exchanges that have a relatively low burn rate. A
+lot of this might sound common sense to you. That's one of my
+conclusions.
+
+We like CEOs who are highly communicative. During the Bitfinex hack, we
+were speaking with the CEO and other management on an hourly basis until
+things settled down. We avoid exchanges where CEOs are unwilling to
+identify themselves or unwilling to have a phone call on a moment's
+notice. If you have a problem, large or small, you want the CEO to
+address it.
+
+Next, we want to have CEOs that are very open aobut the inner workings
+of their companies. What are the financial statements? Who controls the
+keys to the cold wallet? Next, since bitcoin exchanges are private
+companies, they usually don't disclose financial statements. So we have
+to make common sense judgements about the people. Look at them eyeball
+to eyeball and ask does their story make sense? Do you trust him? Does
+he have a prior track record of success? How much does she have invested
+in this? Is she hungry, or is she fat and happy? You want to trust
+someone who has good jugement and will make good decisions especially in
+a crisis.
+
+Will you cover my losses if there is a big loss? If not, that's a
+dealbreaker, we walk away. In some jurisdictions where there is a
+banking license, it's a requirement that they cover customer losses. The
+final point on this slide is that we like to do business with those who
+have the cash to cover the losses.
+
+Back in... a bitcoin exchange that has a bitcoin license or banking
+license, is good where the regulators require that they have large cash
+reserves to cover customer losses. Some licenses, you have to be
+careful, do not require those reserves, such as those offered in Japan.
+Having a license is no substitute for good license. In real estate, the
+saying is location location location. In private equity, it's management
+management management. As markets evolve, we only want to do business
+with people who can evolve with the market and stay ahead.
+
+We like exchanges that don't change their banks every few months, such
+as those in China. This can be a yellow flag. We like CEOs who put their
+customers ahead of their own interests. In the Bitfinex hack, their CEO
+would tell me that his first priority was to compensate customers for
+their losses before he gets his own money back. In our survey for
+insurance, we only found 1 bitcoin exchange that had any kind of
+insurance. I'm still skeptical, because insurance companies aren't in
+the business of giving payouts, but rather collecting premiums.
+
+In terms of internal fraud controls, how do you guard against collusion
+of the top management? I just had a funny conversation the other day
+with a Japanese exchange CEO and asked him what prevents him and his
+colleagues from stealing all the bitcoin. He laughed and said I'm a
+shareholder I'm not going to steal your money. There's nothing to
+prevent the CEO of any exchange from walking out the door with all the
+bitcoin. You want to put your money with the CEOs that have a greater
+incentive to keep things running, rather than running out to Mongolia
+and living as a fugitive. Many of the exchange CEOs we do business with
+are now wealthy individuals. So why go to Siberia or Mongolia and have
+an awful life as a fugitive?
+
+Here's a question that we never got a satisfactory answer to. How do you
+prevent against kidnapping of the top executives that hold the private
+keys to the cold wallet? I don't think you can protect against this
+unless you have a team of bodyguards. The way to prevent this is to not
+tell anyone who has the private keys. And then give the private keys to
+people across cities.
+
+About the hot wallet, how do you prevent hacking against the hot wallet?
+We like exchanges that keep as little as possible in the hot wallet, for
+as little time as possible. I think Bitfinex's biggest mistake was
+keeping everything in their hot wallet, no matter how good they thought
+Bitgo was. Only keep the hot wallet hot for a few milliseconds. Do it in
+small batches, do it multiple times a day. It reminds me of an old bank
+robbery movie where the thiefs found that the bank truck drove past the
+same spot every single day at the same exact time. The idea is to avoid
+repeatable patterns.
+
+How do you protect the cold wallet? Usually 90% of the bitcoin is in
+there. So that's where the honey pot is. Taking the multisignature, keep
+the keys and hardware in a vault, in different places, different cities,
+restrict the access to the top 3 people and have reliable backups.
+
+If the exchange provides leverage, how much margin does it offer to its
+customer? Is it 3-to-1? 10-to-1? 50-to-1? 100-to-1? With the higher
+leverage, it could potentially be a red flag. Whta happens if they are
+lending money at 100:1 to buy bitcoin long, and then there's a 10% or
+20% drop? This would result in negative equity. And then who takes the
+loss? Do socialized losses across all the exchanges as the Chinese
+companies do? or does the exchange absorb the loss? If the exchange
+absorbs the loss, does it have sufficient cash reserves?
+
+We like jurisdictions that have favorable regulatory environments for
+Bitcoin, like NY state, Japan, Luxembourg, have very favorable
+government regulations about bitcoin. An example of an unfavorable
+regulatory environment would be China.
+
+As a trader, we believe in diversification. We don't put more than 10%
+of our digital assets in any one exchange. We learned htis the hard way
+by having more than 40% of our assets in Bitfinex at the time of the
+hack. As traders, we take our bitcoin out immediately to our own cold
+wallet. Same with fiat. If the cash is not being immediately used, we
+wire it to our own bank. If the exchange socializes their losses, we
+want the assets out of their reach.
+
+Finally, we monitor, monitor and monitor. We try to be vigilant about
+watching our golden eggs. We look for yellow flags, we monitor all the
+chatrooms, we go to the bitcoin conferences to pick up hints and clues.
+In conclusion, as I said earlier, running a bitcoin business is no
+different than running any other business with respect to its people. We
+want to deal with knowledgeable, competent trustworthy people who run
+profitable businesses. Before you put your money into any bitcoin
+exchange or bitcoin company, use your common sense about the perceptions
+of the people you're dealing with. If it smells bad, it's bad. Where
+there is smoke, there is usually fire. Ask good questions and expect
+good answers. If they avoid your questions, then avoid them. Do good due
+diligence. Be a healthy skeptic. Hope for the best, but plan for the
+worst.
+
+The biggest danger in the bitcoin business is that you don't know what
+you don't know. As a fund manager, people always ask me what my biggest
+loss was historically. I tell them it's not exactly relevant, because
+you're driving through the rear-view mirror. Your worst loss is always
+ahead of you, not behind you. On the other hand, what doesn't kill you
+makes you stronger, a smart person will come out stronger. When you do
+suffer that future loss, I hope you will emerge stronger.
+
+Thank you. Happy to answer any questions or comments and reactions.
diff --git a/__transcripts__/mit-bitcoin-expo-2017/ideal-number-of-full-bitcoin-nodes.md b/__transcripts__/mit-bitcoin-expo-2017/ideal-number-of-full-bitcoin-nodes.md
new file mode 100644
index 0000000..36dbf94
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2017/ideal-number-of-full-bitcoin-nodes.md
@@ -0,0 +1,253 @@
+---
+parent: Mit Bitcoin Expo 2017
+title: Ideal Number Of Full Bitcoin Nodes.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2017 title: Ideal Number Of
+Full Bitcoin Nodes nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Ideal number of full bitcoin
+nodes
+
+David Vorick
+
+2017-03-04
+
+
+
+
+
+Today I am going to be talking about bitcoin full nodes. Can everyone
+hear me? Okay, great. I don't actually think there's a specific number.
+I think a lot of people do. They look for a number. 5000 is about how
+many we have today, 6000. Some people ask whether it's a good number. I
+think that's the wrong way to look at the role of full nodes in the
+ecosystem.
+
+I've been with bitcoin since 2011. I do a bunch of stuff. I am gonna
+skip this.
+
+As a refresher for what bitcoin full nodes do, they validate bitcoin
+transactions. Bitcoin has this longest chain rule where the chain with
+the most work is the chain that everyone follows, except the chain has
+to also follow all the rules that the network has. The full nodes check
+that the chain follows the rules. If it doesn't follow the rules, it
+doesn't matter how much hashrate is behind it. It's only the full nodes
+on the network that check this. And yes, so yeah that's an important
+part of the ecosystem. "SPV" nodes don't check the rules. They download
+the headers, they check most work, but they don't check that the chain
+is valid. So they are making a gamble that if a miner produces an
+invalid block, the rest of the ecosystem will sort of detect invalid
+blocks and reject it and route around it and "SPV" nodes have blind
+faith in the broader network to do this process and make sure the
+longest chain is valid. But they don't know. They are just assuming that
+the broader network is going to stay safe. So if you don't do rule
+enforcement, you give miners the ability to do whatever they want. If
+people can spend each other's money, or miners can do silent inflation,
+well it's important that there are rules. Full nodes are really
+important to the bitcoin network.
+
+Now we're going to switch to some new stuff, which is a topic on network
+upgrades. When I say upgrade, what I really mean is a block that
+enforces different rules than most people are familiar with. Instead of
+invalid block, I am going to say attempted upgrade. It's a block that
+follows different rules. To say invalid, doesn't make a whole lot of
+sense in the context of a whole network. In the network today, we have
+Core nodes that follow the rules and then we have BU nodes that follow
+different rules. So a block might be valid to some nodes but not other
+nodes. If you have a block following different rules, you can't say it's
+invalid to the whole network, because there might be nodes trying to
+create a new network. Soft-forks don't really change the rules, they are
+just more creative about how they use the rules.
+
+When you have an attempted upgrade, you have a few things that happen.
+You split the chain into two pieces. The attempted upgrade either fails,
+and it gets rejected, the chain dies, nobody is using the coins, the old
+rules are the longest chain and the only ones that get used. Another
+thing that could happen is maybe you have miners on both sides, maybe
+you have full nodes on both sides doing payments, and that's a partially
+successful upgrade. A completely successful upgrade would be one where
+the upgrade is universally adopted. A few weeks ago, a BU node mined a
+block that was larger than the max block size. The standard rule sets
+said that the max block size was lower; what happened was that the other
+miners rejected this block. It got orphaned. Nobody is mining on top of
+that block or that chain. It was an attempted upgrade that just failed,
+it was only one block long.
+
+A successful partial upgrade would be the Ethereum Classic and Ethereum
+split when they addressed the DAO attack. They changed the rules in a
+way that was incompatible with old nodes. You had hashrate that the
+majority followed the new rules, but you still had a set of old rules
+where nodes were continuing to mine and enforce the old rules. So this
+was a partial upgrade for, as it was called, a coin split, where you
+have two live healthy ecosystems, one is a lot bigger than the other,
+but people who want to use the old ethereum rules and stick with the DAO
+disaster, that chain is alive and it exists and you can go use it today.
+
+A successful upgrade, would be the Ethereum hard-forks that happened
+three more times after the DAO hard-fork. These did not result in chain
+forks. The other chains died entirely. So even though they hard-forked
+three times, it only resulted in one chain. So those were completely
+successful upgrades and nobody resisted those changes.
+
+What goes into deciding whether an upgrade attepmt is successful? You
+could say that some sort of upgrade attempts could be blocked by miners,
+if nobody is mining on a chain, then miners could kill it even if
+there's interest in a chain. But really if you want to push an upgrade
+to the network and disregard the miners, you could change the PoW or the
+header format and you can upgrade without consent of the miners. What it
+boils down to is the full nodes. Are people accepting money on this new
+set of rules or the old set of rules? If I want to participate in a set
+of rules on a network, are there other people to participate with? Is
+there a community? Full nodes are the only ones that have full
+visibility into this. They are the ones that decide whether or not an
+upgrade is going to be successful or accepted or partially accepted or
+whether it will fail completely.
+
+That's sort of one of the central points of this talk: if you are not
+running a full node, your opinion on whether you like a hard-fork is
+less relevant because ultimately if you are not validating the rules and
+someone gives you a transaction following a different rule-set you won't
+know anyway. So you shouldn't really be able to weigh in on the outcome
+of an attempted upgrade either way, in this case.
+
+An add-on to this is that if there's money to be made mining a block,
+someone is going to mine this. Even if you have an ecosystem where
+miners are super-hostile to a fork that the users want, if the users
+execute the hard-fork and the coin is getting used and it has value,
+someone is going to go pickup the mining reward. It might not be the
+same miners. But if there's user energy behind a certain coin, there's
+monetary reward, and someone is going to go and get it. Miners don't
+really have the power to cut off hard-forks. Really it comes down to
+full-nodes actively accepting payments on a certain coin. Yeah.
+
+If there is a hard-fork and you're running a "SPV" node, you're
+depending on other full nodes in the ecosystem to tell you whether the
+transactions are valid. You are depending on them to represent you and
+your opinion in the outcome of the hard-fork. If there are malicious
+full nodes out there, they might tell you they are on one side of the
+hard-fork when they are actually on the other. As an "SPV" node, you
+don't know. Generally speaking it's probably okay to think that you will
+find trustworthy parties to tell you the truth, but yeah you're trusting
+them to be there. During a bitter hard-fork where one side of the
+ecosystem is going one way and the other is going th eother way, "SPV"
+nodes are basically left out to dry. They can't be certain that they are
+on the side of the fork that they support.
+
+I think we've said this enough times. You can think of full nodes as
+analogous to representation in a democracy... if you, it's sort of like
+voting, if there's a contentious change being proposed to the network
+and you're able to run a full node, you can put your stick in the sand
+and say you will not accept coins from chains that have 8 MB blocks or
+whatever. That's sort of an economic weight... when full nodes choose
+not to participate in a chain, that reduces the weight. If we take a
+bitcoin payment processor like Bitpay and they decide they want to be on
+one side or another of a fork, that will have an impact on the value of
+the coins on those sides. So Bitpay has this big representation and when
+they vote, they are going to impact the value of the coin because that
+influences where the coin can be spent and what the coin is useful for.
+And so this is sort of an aristocratic arrangement. If you are someone
+who accepts a low-dollar value transaction once a month, the ecosystem
+will care less which side of the ecosystem you end up on. But if you are
+a giant, your weight means a lot more. Full node number is not as
+relevant as the amount of economic participation from that full node.
+
+Coercive upgrades are where it's important to have full nodes. If we
+have a situation where the miners, Bitpay, Coinbase and other major
+payment hubs in the bitcoin ecosystem all agree on a change that the
+users in general feel is hostile to them, the users if they aren't
+running full nodes can be dragged along anyway. If you aren't running a
+full node and your infrastructure decides to pick an upgrade, you have
+no recourse and you have no way to catch up. This is a much bigger
+problem if you're unable to run a full node if it's too expensive. Today
+I am guessing a lot of us don't run full nodes. In the event of turmoil
+it's currently somewhat easy to spin up a full node and check. If the
+block size was much larger, and you required $1k of bandwidth to catch
+up, well if you can't afford that then it's too bad and you have already
+lost control.
+
+The next major talking point here is that if full nodes are expensive to
+run, then only those people who can afford to run the bandwidth have any
+say in the contentious upgrade. In the case of ethereum classic
+hard-fork, the ecosystem said yes we are going to do the hard-fork,
+there was wiggle room for the others to say no we're going to have a say
+and not let that happen. If ethereum full nodes were more expensive,
+then they wouldn't have been able to do that at all. So this is why the
+correct number of full nodes is not really a number. If powerful
+businesses and big institutions are the only ones able to run full
+nodes, it doesn't matter if only 100,000 nodes exist --- they have
+different priorities than individuals anyway. The people deciding how
+the coin progresses in the ecosystem, aren't you. So the correct number
+of full nodes is: can I run one then yes. Coinbase never has to worry
+about the number of full nodes; they can run one, if they disagree about
+something, they will always be able to run full nodes. At a personal
+level, you should feel the same way: if you are able to run a full node,
+you don't have to worry about it. But if the bandwidth costs go up, then
+you should probably complain. If things go wrong, are you going to be
+motivated enough to actually run a full node to make sure that my
+opinion and economic weight is getting applied in a way that I would
+like it to be? And can you afford that?
+
+So that's the major point of this talk. Full nodes are super important.
+You should really care if you can run a full node. The fact that there
+are 6000 full nodes out there that aren't you, shouldn't bring you much
+confidence because they might not share your ideas about how the
+currency should upgrade. During contentious times, like the block size
+debate, you should be conscious of the fact that you don't matter unless
+you're running a full node. Often you can find someone to represent you,
+so maybe connect to full nodes that have the same ideology as you do,
+but if they are trying to represent 100,000 users then they might not
+represent you super-well. If you run a full node on your own, then you
+can represent yourself perfectly well.
+
+If we're going to pick a number to help the scaling discussion along,
+how big should blocks be? When is it okay to make full nodes more
+expensive? I think it really makes sense to look at the transaction
+price. There are two ways that people are priced out of the bitcoin
+ecosystem. The first is that full nodes become too expensive: you become
+a guest to people who are able to run full nodes. The second way is if
+transactions become too expensive, it doesn't matter if you can run a
+full node if it costs $100,000 to send a transaction and bitcoin isn't
+useful to you anyway. The ideal validation cost for a full node is where
+the transaction price meets the full node cost in terms of people being
+priced out. You want people to be priced out at the same time. If
+transaction fees are super high, then maybe it makes sense to increase
+the full node cost.
+
+And then this is sort of just a personal opinion or side tangent, when
+it comes to decentralization and looking at transaction fees, you
+shoudn't be looking at a $0.50 fee and saying oh coffee is too expensive
+now. A $0.50 fee is not too high-- when we're talking about bitcoin, we
+want to be protecting against censorship, hyperinflation, government
+asset seizure, things that aren't really a problem in the United States
+but if you're in another country you want to be immune from political
+garbage that threatens your money. If your $3 coffee is victim to
+10,000% hyperinflation, I mean, a fee is not so bad compared to that...
+Also, I would argue that right now full nodes are too expensive. And
+really, in dollar terms, the size of a full node, 100 GB of storage I
+think, in dollar terms that's not the biggest problem, that's like $2
+bucks. Other parts of running the node is more expensive. In
+psychological terms, when we're talking about every day users about
+running a full node, they look at their 500 GB hard drive, they see they
+are using 50% and then they think well if I am using a bitcoin full node
+then I am losing half of my remaining space and even though it's $2 it's
+still a massive psychological barrier. I don't know how pruned nodes
+adjust this equation; regardless of the dollar cost of running a full
+node, I would say it's the hard drive space is the biggest problem
+facing us, even if bandwidth is technically more expensive.
+
+Full nodes are really important. You should care if you are able to run
+a full node. In the broad ecosystem, I think people tend to undervalue
+full nodes by a lot. I think it's really important htat people protect
+the sanctity of full nodes and appreciate how they function to keep the
+system decentralized and out of control from parties that have different
+ideas about what's best than you do. Thank you.
+
+
diff --git a/__transcripts__/mit-bitcoin-expo-2017/mimblewimble-and-scriptless-scripts.md b/__transcripts__/mit-bitcoin-expo-2017/mimblewimble-and-scriptless-scripts.md
new file mode 100644
index 0000000..251dbaa
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2017/mimblewimble-and-scriptless-scripts.md
@@ -0,0 +1,182 @@
+---
+parent: Mit Bitcoin Expo 2017
+title: Mimblewimble And Scriptless Scripts.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2017 title: Mimblewimble And
+Scriptless Scripts nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Mimblewimble and scriptless
+scripts
+
+Andrew Poelstra (andytoshi)
+
+2017-03-04
+
+
+
+
+
+Up next we have Andrew Poelstra and he is going to be talking about a
+really interesting new concept for a cryptocurrency. It's called
+mimblewimble, after a spell from Harry Potter, because it prevents
+characters from speaking. Try speaking? Hello, test. We also have a...
+hello? hello? Can you guys hear me?
+
+I am going to talk about the concept of scriptless scripts. It's a way
+of describing what
+mimblewimble
+does, in a way that shows the conceptual details, and maybe give the
+ability to take the lessons we learned from mimblewimble and apply to
+other projects.
+
+"Scriptless scripts" are magic digital signatures that can only be
+created by faithful execution of a smart contract. So what I mean is
+taking a smart ...... if they do this, the result is a digital signature
+which people can verify. This has some cool privacy consequences.
+
+You might think this is limited in power, and it is, in an academic
+sense, but there's a lot we can do with this paradigm. Verifying digital
+signatures is a very general thing, but it's powerful. Mimblewimble only
+supports scriptless scripts. I'll build up to that as I run through my
+talk. I've talked about mimblewimble before, so maybe I'll leave it
+unstated if I don't.
+
+Bitcoin, ethereum and these different blockchains have a scripting
+language which is a way of describing under which conditions coins can
+be spent. These scripting languages allow you to do smart contracts
+where coins can be spent under conditions like
+timelock, multiparty,
+delay, random numbers, or some other .... everybody downloads, everyone
+verifies.... ings... so they can't really be compressed or aggregated in
+any coherent or consistent way. They actually end up being hashed, so
+they can't really be compressed. It just doesn't work, without breaking
+the hashes, it just doesn't work. Secondly, the details of these scripts
+are public, they are visible to everyone forever and they have to be
+stored. This means different outputs in bitcoin, or different accounts
+in ethereum, are not very fungible or private because you can tell what
+the rules are on each individual coin and you can distinguish ebtween
+coins and track all this cool stuff, because of individual scripts
+moving coins around.
+
+In scriptless scripts, the only thing that matters is whether the
+signature is valid. These are basic cryptographic structures. They just
+look like random data. It erases so much of the public data. It's also a
+consistent data structure, so you can have a lot of compression.
+
+Let me do a bit of a digression to explain
+Schnorr
+signatures. You have an ephemeral key pair, like k and kg here, you
+compute this value s which is a simple linear transaction... values..
+and the position on the line you choose is a hash of all the data you
+want to commit to, which is what a digital signature is. The
+verification is simple, there's a discrete log problem which is that i
+can put G's in there and you can't figure it out. I can publish all
+these values and... because it's multiplication.. equal signs and minus
+siigns don't get broken. The verification equation... makes sure the
+signature was... pretty much anything out there. Just the equation from
+my early slide, but I've added some... from one of them. You can verify
+this equation the same as verifying an ordinary
+Schnorr
+signature, you multiply everything by G... this verification is a
+weird special property of this value, what it's verifying is that if
+this verification equation checks out, then given D, a valid Schnorr
+signature too, you can figure out the other one, just given the first
+signature. D is a translating key between two separate independent
+Schnorr signatures. So to make two transactions atomic, one is happening
+from one party, the ohter transaction is happening with the other, it's
+2-of-2, each party has a half that they are contributing. During the
+setup phase, someone gives this other party the value p, and then once
+they give that value away, as soon as they sign one transaction, that
+signature can be used to tweak and make that other transaction. You get
+this atomicity property from hash preimages here. Both
+lightning and
+general
+atomic swaps, there's only really one party, so they can.. sure that
+they... And what's exciting about this value D is that it's the
+difference between two Schnorr signatures. So someone is sharing the
+value p before the signatures are made; once the transactions are out
+there and public, .. I can take any two Schnorr signatures in the world
+and get their difference, and I can go make up a transcript. So this
+value D doesn't provide any linkages. These remain independent separate
+signatures. The only magic is that D is public before the signatures are
+public... this is critical because in mimblewimble we don't have support
+for scripts, and it was thought for a long time that we wouldn't be able
+to do atomic swaps or lightning network. This was a big deal because
+mimblewimble scaled pretty well, but if we can't do opt-in payment
+channels then this blockchain scalability story kind of get undermines.
+People would say well bitcoin in principle we can setup indefinitely
+many transactions in a payment channel, and it's great that your
+mimblewimble transactions are small but it can't handle payment
+channels. However, using scriptless scripts, we can make payment
+channels. We can do this on mimblewimble and any blockchain that uses
+Schnorr signatures. If bitcoin had Schnorr signatures, and I think we
+probably will in a few years, you could do a closing scheme where
+currently in lightning everyone has a hash preimage and every channel in
+the path has to have a preimage of some hash, you could use each linkage
+in the key to the path to have a different D value, you still have the
+atomicity and channels and they can only be created/destroyed in one go.
+You no longer have hash preimages in places that people have to store
+and validate forever. We get a win for fungibility, privacy, etc. An
+overarching theme has been what makes a blockchain-- well it's mostly
+signatures, they all look random, there's nothing for people to really
+track here and attaching taint or censoring or whatever. Everything sort
+of looks the same, which was the goal of scriptless scripts and that we
+achieved here. I came up with this to get mimblewimble and lightning. As
+a bonus, it turns out to be very generic.
+
+So let's get on to mimblewimble here, which I claim is itself an
+ultimate scriptless script. The way that mimblewimble transactions
+work.. for those of you who haven't seen this before, mimblewimble is a
+blockchain where every transaction has inputs and outputs. Every input
+and output has a key. Confidential transactions everywhere. In a valid
+balance transaction you can take the input commitments and output
+commitemnts, all the pederson values balance out. So this is like a
+multisignature key. If you take this difference, outputs minus inputs,
+you get a multisig key of the outputs and a multisig key of the inputs.
+We call this the "kernel" in mimblewimble. To make the transaction
+valid, we require a signature with this key. The signature authorizes
+the transaction and proves that the owner wanted the transaction to
+happen, and secondly the fact that the signature is possible, which
+means the transaction balanced, so it's using this proof of
+non-inflation really. So what this is is that the validity of a
+transaction, meaning all relevant parties authorized it, and no coins
+were created from nowhere or were destroyed. The validity comes down to
+a single key and a single signature and ultimately everything
+mimblewimble except for these keys and signatures is just for witnessing
+what's going on. The core of mimblewimble is tha tevery transaction is
+compressed into a single key and a single signature. The signature is
+simple enough, there's no real requirement, there's one thing that we
+need to add, you need to sign a locktime, to make it possible to back
+out if people ban, but I'm not mentioning that here. The very simple
+signature can be used in any of these other things, we could make the
+preimage the decryption key of something, we can use an atomic swap
+mechanism, I can do whatever I want, so even though these are sngle
+signatures, I can enforce arbitrary multiparty smart contracts into
+these single signatures. That's the real magic of mimblewimble.
+
+I will end with a few open questions. One is a generic scriptless
+script; I gave some examples of cool things to do. I wonder if there's a
+generic way to do this, like is there a way to do a NAND gate in
+scriptless scripts to execute arbitary script? The second one is
+locktime. I can't do locktimes in scriptless scripts, without
+SNARKs,
+which isn't efficient. Locktime needs to be publicly validated, which as
+we talked about, scriptless script works with.... so it would be cool
+that instead of a locktime in the blockchain forever, if we could remove
+that, as the last wart of mimblewimble. Everything needs to be just keys
+and signatures. Those are all the open problems, an exhaustive lst of
+open problems.
+
+And that is my talk, thank you.
+
+
+
+[Scriptless scripts and deniable swaps](https://lists.launchpad.net/mimblewimble/msg00036.html)
diff --git a/__transcripts__/mit-bitcoin-expo-2017/scaling-and-utxos.md b/__transcripts__/mit-bitcoin-expo-2017/scaling-and-utxos.md
new file mode 100644
index 0000000..f5a9d53
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2017/scaling-and-utxos.md
@@ -0,0 +1,231 @@
+---
+parent: Mit Bitcoin Expo 2017
+title: Scaling And Utxos.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2017 title: Scaling And Utxos
+nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Scaling and TXO commitments
+
+Peter Todd
+
+2017-03-04
+
+
+
+
+
+Thank you. I'll admit the last one was probably the most fun other than.
+On the schedule, it said scaling and UTXO and I threw something
+together.
+TXO
+commitments were a bold idea but recently there were some
+observations that make it more interesting. I thought I would start by
+going through what problem they are actually solving.
+
+Like
+David
+was saying in the last presentation, running a full node is kind of
+a pain. How big is the archival blockchain data? Earlier this morning on
+blockchain.info,
+it was 125 GB. They don't have a good track record, who knows, but it's
+roughly the right number. History doesn't disappear, it keeps growing.
+In this case, in David's talk, we were able to mitigate that problem
+with pruning if you want to run a pruned node you don't have to go keep
+all that 100 gigs on disk all the time. Currently there are some issues
+with pruned nodes where we don't have the infrastructure to do initial
+synchronization from each other. But long story short, it's pretty easy
+to see how the archival history problem we can solve it by essentially
+splitting up the problem and letting people contribute disk space.
+
+However, pruned nodes still have the problem of the UTXO set which is
+that if your node wants to go verify someone spending a coin, you must
+have a copy of that data. Otherwise, how do you know that the coin is
+real? Even a pruned node is carrying around 50 million UTXOs right now.
+That number while it can go up and down a bit, fundamentally it will
+always go up in the long run, because people will lose private keys.
+That's enough to guarantee that UTXO set size will continue to grow up.
+50 million translates to about 2-3 GB of data, which doesn't sound like
+a lot, but remember that it can grow just as fat as the blockchain does.
+That can grow by 50 GB per year. If we want to go scale up block size,
+and segwit does that, the amount that the UTXO grows can go up too. So
+it's not necessarily a big problem right now, but even in the future
+having the UTXOs around can be a problem.
+
+When you look at the UTXO set, if you're going to process a block
+quickly, you need to have the UTXO set in reasonably fast access
+storage. If you have a block with 5000 inputs, you need to do 500
+queries to wherhever you're storing the UTXO set... so you know, as that
+goes up, the amount of relatively fast random access memory you need
+goes up so that you can have decent performance. You can run this on a
+hard drive with all the UTXO data, and the node will run a lot slower,
+and that's not good for consensus either. In the future we're going to
+have to fix this problem.
+
+How is the UTXO data stored anyway? With this crowd, you're all thinking
+about a merkle tree. The reality is that it's oversimplified of leveldb
+architecture. Basically everything in existence that stores data,
+there's some kind of tree, you start at the top, you go access your
+data. You can always go take something that uses pointers and hash it
+and convert it into what we usually call a merkle tree. The other thing
+to remembe rwith UTXO sets is that not all the coins are going to be
+spent. In this diagram, suppose the red coins are the ones that people
+are likely to go spend in the future and they have the private keys. And
+the grey ones maybe they lost the private keys. If we're going to scale
+up the system, we have some problems there. First of all, if we're going
+to scale it, not everyone wants to have that all that data. So if I go
+and hash that data, you know, I can go and extract proofs, so I can go
+and outsource who has a copy of this. For instance, go back a second, if
+you imagine all this data being on my hard drive and I want to not have
+it, I could hash it all up, throw away most of it, and if someone wants
+to spend a coin, we can give the person hey here's all the stuff you
+didn't have, you know it's correct because the hashing matches, now you
+can update your state and continue block processing.
+
+With lost coins, the issue is that, who has this UTXO set data? How are
+we going to go and split that up to get a scalability benefit out of
+this? And, where was I.... I mean, so the technique that I came up with
+a while ago was why don't we go and make this insertion-ordered? And
+what's interesting about insertion-ordered... imagine the first
+transaction output ever created ends up at position 0 on the left, and
+our not-so-used coin, we have 20 inputs here maybe, a lot of them are
+lost... but because people lose hteir keys over time, we could make the
+assumption that entries in the UTXO set that are older are hte ones that
+are less likely to be spent. Right? Because obviously people are going
+to go spend their coins on a regular basis. And the freshly created
+coins are most likely to correspond to coins that someone is about to
+actually spend. The grey ones are dead. But sometimes maybe someone
+spends an old coin from way back when. But first and foremost, if you're
+insertion-ordering, what happens whne you add a new coin to the set?
+What data do you need to do that? If we go back to UTXO set commitments,
+if we're storing that by the hash of the transaction and the output
+number, that's essentially a randomly distributed key space because
+txids are random. So I oculd end up having to insert data into that data
+structure almost anywhree. Whereas if you do insertion-ordering, you
+only need basically the nodes on the right. Right? Because I always know
+what part of the big data set I'm going to change and add something new
+to it.
+
+Which also means that in addition to this, we have a cache .... we can
+go pick some recent history and keep that around, and the other stuff
+you discard it and now your disk space usage goes down. Just like in the
+UTXO commitment example, someone could still provide you that extra data
+on demand. You threw away the data, but you still had verified it. Just
+like bittorrent lets you download a file from people you don't trust. So
+we can still get spend data when needed. Oops, where is it, there we go.
+
+When that guy finally spends his txo created a year ago, he could
+provide you with a proof that it is real, and you temporarily go and
+fill in that and you wind up being able to go record that. Now, here's
+an interesting observation though.
+
+If we're going to implement all this, which sounds good, we can run
+nodes with less than the full UTXO set, does this actually need to be a
+consensus protocol change? Do miners have to do this? I recently
+realized the answer is no. We've often been talking about this technique
+in the wrong way. We think of this as TXO proofs. Proofs that things
+exist. In reality, when you look at the details of this, if we're basing
+this on standard data structures that you otherwise build with pointers,
+we're always tlaking about something where data you pruned away and
+discarded, that's not really a proof. You're just filling in some
+details that are missing from someone's database. I'm not proving that
+something is true. I'm simply helping you to go prove for yourself.
+Which then also means, why do we care that miners do any of this? Why
+can't I just have a full node, that computes what the TXO set commitment
+would be, computes the hashes of all these states in the database, and
+hten among my peers, follow a similar protocol and give each other the
+data that we threw away. If I want to convince your node that an output
+from 2 years ago was valid; I am going to give you data that you
+probably processed at some point but long since discarded. I don't need
+a miner to do that. I can go do that just between you and me. If miners
+do this, it's irrelevant to the argument.
+
+We could deploy this without a big political fight with guys scattered
+around the world that might not have our best interests in their hearts.
+This makes it all the more interesting.
+
+The other interesting thing is that if this is not a consensus protocol
+change, they can be a lot faster. People actually implemented....
+Mark Friedenbach
+implemented a UTXO set commitment scheme, where he took the set and
+hashed it and did state changes, he found that the performance was kind
+of bad because you're updating this big cryptographic data structure
+every time a new block came in and you have to do it quickly. Well, if
+we're not putting this into consensus itself, and we're just doing this
+locally, then my node can compute the intermediate hashes lazily. So for
+instance we're looking at our reently created UTXOs cache example... I
+could keep track of the tree, but I don't have to re-hash anything. I
+could go treat it like any other pointer-based data structure and then
+at some point deep in the tree, on the left side, maybe I can keep some
+of the hashes and then someone else can fill me in on the details later.
+A peer would give me a small bit of data, just enough to lead to
+something that in my local copy of the set has a hash attached to it...
+and if I add that to the data I already knew about it, it doesn't matter
+that I didn't bother aggressively rehashing everything all the time. I
+have implemented htis and I'm going to have to go see if this has any
+performance improvements.
+
+And finally, the last thing I'd point out with this is that setting up
+new nodes takes a long time. David talked about how many hours spent
+re-hashing and re-validating and checking old blockchain data and so on.
+If you have a commitment to the state of the transaction output set,
+well, you could go and get the state of that from someone you trust. We
+recently did this in Bitcoin Core version 0.14 where we added something
+called
+"assumedvalid".
+My big contribution to that was that I came up with the name. That
+command line option is also-- we assume a particular blockhash is valid.
+Rather than rechecking all the signatures leading up to that, which is a
+big chunk of time of the initial synchronization, we assume that a
+blockchain you're synchronizing in ends in that particular blockhash,
+then it skips all the signature validation. You might think this is a
+terrible security model-- but remember the default value is part of the
+Bitcoin Core source code. And if you don't know that the source code
+isn't being malicious, well it could do anything. Some 32 byte hash in
+the middle of the source code which is really easy to audit by just
+re-running the process of block validation. That's one of your least
+concerns of potential attacks; if that value is wrong, that's a very
+obvious thing that people are going to point out. It's much more likely
+that someone distributing the code would go and make your node do
+something bad in a more underhanded way. I would argue that assumedvalid
+is a fair bit less dodgy than assuming miners are honest.
+
+If we implement TXO commitment schemes on the client-side without
+changing the consensus protocol, and you take advantage of it by having
+a trusted mechanism to assume that the UTXO state is correct based on
+state, that's actually a better security model than having miners
+involved. In BU, you could assume that miners say something is true then
+it is say true... But I would much rather know who I am trusting. I
+could be part of my security model I already have: the software that I
+am trusting and auditing. Why add more parties to that? And with this
+model, what would Bitcoin, what would running a bitcoin node look like?
+You download your software, have an assumedvalid TXO state in it, then
+you ask your peers to fill in the data you're missing. Your node would
+start immediately and get full security in the same trust model that the
+software had to begin with. I think this would be a major improvement.
+
+I setup some nodes on scaleway and it took about 5 days for them to get
+started. Maybe we could go implement this in Bitcoin Core in the next
+year or two. Thank you.
+
+---
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/__transcripts__/mit-bitcoin-expo-2018/_index.md b/__transcripts__/mit-bitcoin-expo-2018/_index.md
new file mode 100644
index 0000000..3cae99d
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2018/_index.md
@@ -0,0 +1,7 @@
+---
+layout: default
+has_children: true
+title: Mit Bitcoin Expo 2018
+---
+
+{{< childpages >}}
diff --git a/__transcripts__/mit-bitcoin-expo-2018/improving-bitcoin-smart-contract-efficiency.md b/__transcripts__/mit-bitcoin-expo-2018/improving-bitcoin-smart-contract-efficiency.md
new file mode 100644
index 0000000..baf9bf7
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2018/improving-bitcoin-smart-contract-efficiency.md
@@ -0,0 +1,290 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2018
+title: Improving Bitcoin Smart Contract Efficiency
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Improving efficiency of smart
+contracts on the bitcoin network
+
+Tadge Dryja
+
+video:
+
+
+
+## Introduction
+
+I will be talking about discreet log contracts, taproot, and graftroot.
+Not in that order, the order will actually be taproot, graftroot, and
+then discreet log contracts.
+
+Quick intro: I'm Tadge Dryja. I work here at MIT down the street at
+Digital Currency Initiative. I was coauthor on the lightning network
+paper, and I worked on lightning. I also was the author of a paper
+introducing discreet log contracts. It's a more recent thing that looks
+a lot like lightning. I'm going to talk about taproot, graftroot and
+discreet log contracts.
+
+I only have about 20 minutes and this is only meant to get you
+introduced to it, please bug me later if you would like even more
+details.
+
+## Smart contracts
+
+So, what is a smart contract? There's no real good answer to that
+question. A lot of people think one thing is a smart contract while
+another isn't or something. All outputs in bitcoin are smart contracts
+because they use bitcoin script. Even pay-to-pubkeyhash with OP_DUP
+OP_HASH160 and OP_EQUALVERIFY... So in my view, pay-to-pubkeyhash is not
+really a smart contract. You're just sending money. It's functionally
+the same as using cash.
+
+Multisig, is multisig a smart contract where you have multiple
+signatures and maybe some kind of threshold? Yeah, maybe, kind of.
+That's iffy. But it's sort of novel, it's not how cash works, it's kind
+of a smart contract.
+
+What about OP_CHECKLOCKTIMEVERIFY where there's an output and it can't
+be spent until after a time has passed? Okay, that's getting there.
+That's something.
+
+And then there's stuff like the
+lightning network where the
+scripts in lightning are using multisig, OP_CHECKLOCKTIMEVERIFY and
+revealing secrets to revoke old state. I'd say, yeah, that's a smart
+contract. It's a fairly limited one compared to what people are looking
+at, but this is a smart contract with conditoinal payments and things
+like that.
+
+## Smart contracts in bitcoin
+
+How do we do smart contracts in bitcoin? It's not the same model as in
+ethereum. You have-- there's basically two output types that you can see
+on bitcoin today. There's pay-to-pubkeyhash (P2PKH) and
+pay-to-scripthash
+(P2SH). In P2PKH, there's a key, you can spend to the key, pretty
+straightforward.
+
+In P2SH, you take some kind of script or program or a predicate, you
+hash it, and you can send to that. When you want to spend it, you have
+to reveal what the script actualy was.
+
+So you have these two different output types in bitcoin. And these two
+different output types look different, and that's bad. Why is that bad?
+Well, in bitcoin, you want fungibility and uniformity. You want it so
+that when Chainalysis and other similar companies that when they look at
+the blockchain that they get nothing. Ideally they just have nothing and
+just see random numbers and random outputs with uniform distribution of
+addresses. So you want to make everything uniform. One idea to do this
+is something called taproot.
+
+## Taproot
+
+
+
+Taproot
+is an idea from Greg Maxwell, who is somewhat of a bitcoin guru. He
+knows a lot about bitcoin. He wrote a post introducing taproot a couple
+of weeks ago. It merges p2sh and p2pkh. It does this in a very
+annoyingly-simple way where we started wondering why nobody thought of
+this before.
+
+You start by making a public key, the same way you do to create your
+addresses. Say you have your script S. What you do is you compute the
+key C and you send the taproot. I skipped the elliptic curve operations,
+but if you're familiar with any of this stuff then this is how you turn
+a private key into a public key, you multiply by G. You can add public
+keys together, it's quick and really simple to do. And if you add the
+public keys, then you can sign with the sum of the private keys, which
+is a really cool detail. What you do is say you have a regular key pair,
+and you also have this script and you perform this taproot equation. You
+hash the script and the public key together, you use that as a private
+key, turn that into a public key, and add that to my existing public
+key. This allows you to have both a script and a key squished into one
+thing. C is essentially a public key but it also has a script in it.
+When you want to spend from it, you have the option to use the key part
+or the script part. If you want to treat it as P2PKH, where you're a
+person signing off with this, then you know your private key will just
+be your regular private key plus this hash that you computed which you
+know. So you sign as if there were no scripts and nobody will be able to
+detect that there was a script -it looks like a regular signature. But
+if you want to reveal the script, you can do so, and then people can
+verify that it is still valid, and then they can execute the script.
+It's a way of merging p2pkh and p2sh into one.
+
+It's nice because in many cases in smart contracts, there's a bunch of
+people getting together for a smart contract. If all of those people
+sign off on the outcome, then you don't really care what the smart
+contract was. If everyone agrees, then don't use the smart contract.
+Everyone just agrees. In real life, you enter into legal agreements all
+the time and you don't go to court, there's no disagreement so you don't
+need to use the contracts themselves... the contracts are really only
+useful in the event of a disagreement, but they still need to be there.
+
+.... ((stream died)) ...
+
+## Graftroot
+
+
+
+
+
+.. or I sign a script and then execute that script. The really cool
+thing about this is that I can add scripts after I've received the
+money. I can say "it's my money, OR it can be this 2-of-3 multisig" and
+I can sign off on that, and I can keep adding people into the contract
+after I've created it, without touching the blockchain at all. This is
+really cool. It's in some ways like merkleized abstract syntax trees
+(MAST), which is a way of having a whole bunch of different scripts that
+could be executed. It's simple, and the scaling is really great. You can
+sign a million different scripts with this key, and all million are
+different possible ways of spending the money, but there's no additional
+blockchain overhead, it's just 32 bytes because the 32 bytes you can
+sort of squish the signatures together.
+
+The downside is that you have to sign. In taproot and p2sh, it's only
+operating on public keys. Anyone can take your public key and send money
+to it, or anyone can take your public key and a script and combine those
+in the case of taproot. In the case of graftroot, there are signatures,
+and someone's private key has to be online, so this doesn't work as well
+with cold storage situations or offline wallets. But the upsides are
+really huge and you get these really cool scripting and scaling
+benefits.
+
+I have 10 minutes left.
+
+## Discreet log contracts
+
+
+
+
+
+Discreet log contracts can use some of those scripts. This is an
+application, though. It looks a lot like lightning network. I came up
+with it from working on lightning network for years. I wondered if we
+could do discreet log contracts instead, and hopefully we can reuse
+80-90% of the lightning network source code to do this.
+
+The idea of lightning is that you have this multisig output, you keep
+making new transactions. In lightning, the most recent transaction is
+valid, and the older transactions are invalid.
+
+In discreet log contracts, you have a different way of choosing which
+transaction is valid. You have this non-interactive oracle which can
+determine a valid transaction. I have a little graphic about this. Let
+me do the graphic first. So yeah, in lightning, you say, okay, we have
+this funding transaction, you have 10 BTC shared between Alice and Bob
+and they can keep sending them back and forth. And they update these
+amounts per each state, and they invalidate the previous state to make
+sure that neither of them can successfully broadcast the earlier states.
+They are really only able to broadcast the latest most recent state. If
+they try to broadcast the older states, then they lose everything.
+That's what lightning does. But in discreet log contracts, both parties
+create all possible outcomes of the contract when they enter into the
+agreement. It looks similar in terms of transactions, with a multisig
+2-of-2 at the top, and they make a million transactions descending from
+that. But in this case, they take an oracle's key nad they say there
+might be 3 different possible outcomes for tomorrow, and given the
+outcome as determined by the oracle, that will determine which of the
+millions of transactions or 3 different transactions is going to be the
+one valid transaction. The oracle's signature is going to be used to
+endorse one specific transaction.
+
+This uses
+Schnorr
+signatures. This all happens offline. We don't need Schnorr
+signatures to be on the bitcoin network. The idea of a Schnorr signature
+is pretty straightforward. You have a pubkey, you make a temporary
+pubkey like k \* G(r), and then you compute a temporary private key
+minus a hash of a message and R times the public key, and then to verify
+you multiply everything by G and see whether it equals what it should
+be. They give you (r, s) and you get this and here's what you compute.
+In bitcoin, (R, s) is the signature. It's ECDSA in bitcoin today not
+Schnorr. You get a point and a scalar and see if this relationship holds
+true and if it does then it's a valid signature.
+
+In discreet log contracts, -- well, until now, the public key is a point
+on the curve and so on. But what if we keep the equations the same, but
+we say the pubkey is two points, and we pre-commit to the R value. We
+just move one thing to the beginning, when we're sharing the public key.
+What's interesting is that-- normally, you don't do this because this
+lets you only sign once. If you reuse the same R value, then people can
+find the private key. This happened on ps3 back in the day with geohot.
+I think blockchain.info had problems with people reusing R values. it
+makes your signatures one-time use. But it also allows you to figure out
+what the signatures are going to look like. If I know (A, R) and I can
+come up with the expected messages, I can compute the signature times G,
+and if we think of a signature as a private key, then I can compute what
+that public key would be. So this is a weird thing you can do where you
+can't figure out the signature but you can figure out the pubkey version
+of the signature. You have to think of signatures as private keys. This
+lets you take this oracle's signature and use it as a private key in
+your own transaction, and combine it with other existing keys.
+
+It's a third-party oracle model. In many other oracle models like in
+ethereum, generally the oracle has all visibility into the smart
+contract so they know what is going to happen if they say the price is
+one thing or the other. But in my model, the oracle might not have any
+idea that they are being used in this arrangement. Maybe smart contracts
+use their signatures maybe not, you can't tell without being party to
+the discreet log contracts. The oracle wont necessarily know if anyone
+is using their services, and it might be difficult for them to make
+money, and it has good privacy properties.
+
+There are use cases like currency futures where you can make contracts
+on the price of bitcoin that settles into bitcoin. It's the opposite of
+CME and CBOE where they do cash-settled futures. You can also do a lot
+of other stuff like betting and gambling which I guess people will do.
+The downside is that you have to enumerate all possible outcomes, so
+some things it doesn't work, like if there's tens and tens of millions
+of possible outcomes then it might become unscalable. But if you have a
+small finite number of outputs, and it's bounded, it's based on how much
+data you can store, and the only thing going into the blockchain in all
+cases is just the first one transaction and maybe the spending
+transaction.
+
+## Q&A
+
+
+
+Q: Delegated timing?
+
+A: Yes, kind of, yes. Graftroot, you can, the issue with graftroot is
+that there is a root key that creates the scripts. You can make the root
+key interactive. But you can make a way where it doesn't exist and it's
+endorsed to script. You can delegate, you can say you have this key and
+you can sign off on a script where you have a key and you can sign. But
+do we make it recursive? Like a tree of delegation? It wouldn't be hard
+to make it recursive, but
+last
+week at the Bitcoin Core dev meetup, people were arguing it might be
+crazy to allow that. It might allow indefinite delegation.
+
+Q: Since it doesn't have a dependency on bitcoin network, then it should
+be... Lightning network and passing a message to any blockchain...
+
+A: So you're using bitcoin or a similarly compatible network as a court,
+essentially. As long as everyone is getting along, it's fine. Only the
+results get posted to the blockchain.
+
+Q: It could be like...
+
+A: Graftroot and taproot would be a soft-fork. Discrete log contracts,
+there's no soft-fork needed, it looks, if you look at it, it looks the
+same as lightning. It could work today, I just have to code some of
+this. You don't need Schnorr signature soft-fork-- the non-interactive
+oracle uses Schnorr signatures, but it's all offline, to compute private
+keys which we then use for ECDSA on bitcoin.
+
+Q: ...
+
+A: The smart contracts in bitcoin script? There's not a programming
+language for discreet log contracts. You enumerate all the outcomes, and
+you make a bitcoin transaction for all of those. You can look at this as
+a giant OR gate, circuit-wise.
+
+Okay, thanks a lot. Ask questions to me later.
diff --git a/__transcripts__/mit-bitcoin-expo-2019/_index.md b/__transcripts__/mit-bitcoin-expo-2019/_index.md
new file mode 100644
index 0000000..5d65a58
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2019/_index.md
@@ -0,0 +1,7 @@
+---
+layout: default
+has_children: true
+title: Mit Bitcoin Expo 2019
+---
+
+{{< childpages >}}
diff --git a/__transcripts__/mit-bitcoin-expo-2019/signature-scheme-security-properties.md b/__transcripts__/mit-bitcoin-expo-2019/signature-scheme-security-properties.md
new file mode 100644
index 0000000..fd1b12e
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2019/signature-scheme-security-properties.md
@@ -0,0 +1,409 @@
+---
+parent: Mit Bitcoin Expo 2019
+title: Signature Scheme Security Properties.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2019 title: Signature Scheme
+Security Properties nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Name: Andrew Poelstra
+
+Topic: Secure Signatures - Harder Than You Think
+
+Location: MIT Bitcoin Expo 2019
+
+Date: March 9th 2019
+
+Video: https://www.youtube.com/watch?v=0gc1DSk8wlw
+
+Twitter announcement:
+https://twitter.com/kanzure/status/1104399812147916800
+
+Transcript completed by: Bryan Bishop
+
+## Introduction
+
+Hi everyone. Can you hear me alright? Is my mic? Okay, cool. I was
+scheduled to talk about the history of schnorr signatures in bitcoin. I
+want to do that, but I only have 20-30 minutes to talk here.
+
+Instead, I am going to talk about only one particular piece of that
+history, which is the security model surrounding not just Schnorr
+signatures but extensions to Schnorr signatures. I'm going to focus on
+the security model involved.
+
+## Schnorr signatures
+
+Let me start by describing what a Schnorr signature is. There's two
+purposes to this, depending on which side of the audience you're sitting
+on: one is to intimidate you with algebra, and the other is to show that
+what a schnorr signature is is really this one simple equation.
+
+Schnorr signatures is a digital signature algorithm which has been
+proposed to replace Bitcoin's ECDSA algorithm. There's a few reasons,
+like shorter signatures. A signature has two objects that are computed
+by these two simple equations. The only operation here is the hash
+function and there's a plus sign and a multiplication operation. There's
+no division, no modular inversion, nothing exotic, not computing an
+elliptic curve point and taking an x-coord. It's all straightforward
+grade 9 algebra stuff. You get a Schnorr signature from this.
+
+You'd think, seeing an equation like this, that maybe you could turn
+this into a proposal for Bitcoin and it would be straightforward and
+then you'd have a BIP and you could then fight about deployment or
+something. But in fact, it turns out there's a lot more to Schnorr
+signatures than this simple equation. This equation gives you knowledge
+whether a signature is correct, that someone who knows a secret value x
+can sign.
+
+But there's another property that signatures need to have, which is
+security. Nobody else should be able to forge a signature. Let me try to
+formalize this intuition and show why this might be difficult.
+
+By the way, this is a verification equation and this is a signing
+equation. They are very similar.
+
+## Secure signatures
+
+What does it mean for a signature to be secure? First, you want to
+formalize your attacker. In this case, an attacker is any probabilistic
+polynomial-time algorithm. Basically, any computer program, anybody who
+has some amount of hardware, including like a quantum computer (although
+it turns out that our signature is not secure against quantum
+attackers). So our attacker is operating in the physical universe, and
+it needs to be impractical.
+
+The intuition we have for signatures is that nobody can sign a message
+without knowing a secret key. Suppose you have a polytime algorithm that
+can produce a signature; maybe I can use this algorithm to extract the
+secret key from it. If any such algorithm would be ameniable to this
+kind of modification, then somehow the algorithm must know the secret
+key in the first place to get it, right? Well, no. That's a good way to
+think about it, but it's not true. It's possible to create fake
+signatures without knowing a secret key, in case you have a sufficiently
+broken signature algorithm like one where the verification algorithm
+looks at a few bytes and then says sure it's done. This is trivially
+forgeable because any pile of bytes would be a forgery according to our
+definition, but it's not going to be secure: anyone can produce a pile
+of bytes.
+
+We need to change this from just extracting secret keys, to maybe
+forgery. So now we say, can an attacker be created that would sign some
+message that I choose? If nobody can do that, then maybe that's
+sufficient for security. Well, no, that's not really far enough: let's
+say that the attacker is allowed to choose the message and do chosen
+message attacks. Our security definition is now, no probabilistic
+polytime algorithm is able to choose a message and forge a signature.
+That sounds pretty good and pretty general- we're letting any algorithm
+run, we're letting it choose a message, what more do we need? In fact,
+there are signatures that are insecure in this regime, one example of
+which is Winternit's signatures which are used by some altcoins out
+there. The way these signatures work is that they are so-called one-time
+signatures. If someone produces enough signatures, and someone observes
+them, they can extract some information and create forgeries. If the
+algorithm sees signatures, then it can't help it.
+
+We define an attacker as a probabilistic polytime algorithm that is
+allowed to request signatures on whatever series of messages it wants,
+we have to give it to the algorithm and give it valid signatures. Given
+that, the attacker is allowed to choose another message and produce a
+forgery on that. In many protocols, we let it do as many queries as
+possible, to make sure that the definition is maximally defined. Really
+what we're doing here is we're trying to define an attacker to be as
+powerful as reasonably possible, where reasonable means can we prove
+security.
+
+We want to give the attacker more and more power, and then at some point
+in principle it should be clear that there are no more powerful
+adversaries that could be reasonably called an adversary. We started out
+with a weak adversary, and then we said well we want the attacker to
+have as much information as possible. So we'll let it ask for a whole
+bunch of other messages and signature pairs.
+
+But really that's not enough; maybe you could find an attacker that
+could make zero-knowledge proofs of the same key or weird functionality
+like that. If you want to do that, you have to get into a security model
+called universal composability, we don't have time to get into that, but
+it's much stronger.
+
+There's a few more ways to strengthen this. You could say, well, maybe
+the attacker is allowed to request a signature where on the message it's
+going to forge on, and in this case you don't want to give back the same
+signature that doesn't count as a forgery so let's say it has to give
+you back a different signature. We can do that.
+
+Something relevant to bitcoin is this last point: what if you let the
+attacker choose the signing key? If your attacker can choose a signing
+key, then of course they can produce signatures. We can't just let the
+attacker choose the key. But suppose we give it a public key, and we say
+the attacker is allowed to derive bip32 child keys, and can it produce
+forgeries then? The answer would be yes, for a naieve form of Schnorr
+signatures where e is the hash of a public key, R, and message, and if
+we didn't have the pubkey in there then this would be insecure against
+that more general model.
+
+- If nobody (i.e. no probabilistic polytime algorithm) can extract the
+ secret key from the signatures?
+- If nobody can sign a given message without the secret key?
+- If nobody can sign any message?
+- What if they're allowed to request signatures on other messages?
+- What if they're allowed to request signatures on the same message?
+- What if they chan change the key?
+- What if they freely choose the key?
+
+I raddled off some words about the definition of a secure signature. But
+these are actually standard definitions in the literature. The one where
+an attacker can request a bunch of messages is what it means to be a
+"secure signature". A signature that is secure against existential
+forgeries under a chosen message attack, a chosen message meaning the
+signer can choose the message.
+
+If we allow it to request messages on the signature it's going to forge,
+then it's called a "strong signature" which is slightly stronger. If we
+let it choose the key, then as far as I know there's not really a name
+for this definition in the literature because most of the academic
+signatures don't consider this as part of their security model. It
+assumes that a public key is somehow associated to some identity (like
+your key fob when you try to get into the building) and it's not going
+to change. They take the public key as fixed, and then they move on with
+their life. We're seeing a hint that maybe things are not so simple in
+bitcoin, because this is insufficient to protect bip32 child keys based
+on signatures on the parent key.
+
+Even more than just the security definition, there's other difficulties
+when trying to deploy this in practice. In my first slide with those
+equations, I made it look less scary. But I didn't mention that some of
+the values need to be uniformly random.
+
+## Uniformly random distributions in signature schemes
+
+Uniformly random means that any probabilistic polytime algorithm is
+unable to distinguish the values generated by whatever you're claiming
+to be uniformly random from an actually uniformly random distribution.
+This is not a sufficient definition, but I'm not going to get into why.
+
+I realize that uniform randomness is hard to come by, especially if
+you're signing with a keyfob or a hardware wallet or something with a
+strange ability to gather randomness from the environment and also needs
+to run on low power. One thing you might ask is, what happens if you
+screw up the randomness? Say it's supposed to generate a 256-bit random
+number, and say you're 7th bit tends to be 1. What is the danger in
+that? Well it turns out the danger in that is that if you produce a
+signature, you will leak your secret key. There's no room for biased
+randomness at all, which is frustrating because when you read a paper
+describing a signature scheme, there's usually a statement that it is
+drawn from a uniformly random distribution which most people don't think
+about it. Suppose you don't have a hardware random number generator, and
+you're worried about maybe it's going to be biased, what am I going to
+do? Even if I think I can produce uniformly random values, how could I
+convince anyone that they are uniformly random? That I didn't somehow
+backdoor this randomness and introduce bias in some way? I can even bias
+it in very subtle difficult to detect ways. So this is something we
+worry about.
+
+There's a standard solution to this. You take this value k, part of your
+signature, and this value k needs to be uniformly random. You hash your
+secret key and your message. We assume that our hash function is
+uniformly random in some nebulous sense called the random oracle
+heuristic. It turns out that if your hash function is sha256 then this
+assumption is held up very well in practice. It's not really random; in
+particular, if you give the same inputs to the same function, you get
+the same output. You'd think a random output would change. And it's not
+really random because if I give you a sha256 evaluator then you would be
+able to plug in some input and get the same output, which again is not
+random. But because I'm going to be plugging in my secret key in here
+and I'm going to assume my secret key is unguessable, I can take a hash
+function that is seeded with my secret key and we can take this as
+uniformly random for our purposes. This is great, this works, people do
+this. The result of hashing the secret key and the message is that if
+someone changes the message, someone gets a different uniformly random k
+value. This is called a nonce. You're repeating your signature too,
+which isn't that bad, anyone can copy-paste a signature.
+
+A question you might ask is, what about your secret key itself? Does the
+secret key need to be uniformly random? As near as I can tell, the
+answer is no. Don't do that just because I said "no", but it seems like
+the answer is no. You need to have sufficient entropy so that nobody can
+guess it. In practice this seems to be secure, which is surprising. You
+read a paper, you have the arrow dollar sign symbol indicating a
+uniformly random distribution saying draw your secret key uniformly
+randomly, and draw your nonce uniformly randomly... but it's the second
+one that is more dangerous where if you bias even a 256-bit number by 1
+bit, you leak your key and you lose all of your money. That's the kind
+of thing that really surprises you in real life, not when you read it
+but when you try to implement it. You're trying to write code, and
+people can keep breaking your stuff in ways that the paper didn't even
+mention.
+
+## Sign-to-contract
+
+Moving on, let me talk about one extension. I have two extensions to
+Schnorr that I want to talk about. One is called sign-to-contract, and
+the other is multisignatures. All I want to do is highlight the security
+properties of this.
+
+There is a construction called sign-to-contract where you take a
+signature, you have this value R called a public nonce, it's just kG
+where G is the elliptic curve generator. You can turn R into a
+commitment. You can hide data in there. You can timestamp data in the
+blockchain.
+
+You take your nonce, you take your normal signature scheme and compute
+this nonce R, you hash the nonce along with some other secret message
+you want to covertly sign, and then you add that to the original R and
+you get this new R value. You use this as the nonce in your signature.
+This works, it's easy, and it's algebraically trivial.
+
+This lets you take a signature that seems to be a signature on a
+transaction, and it is, but it's also a signature on some other
+auxiliary data. You can sign the current state of your wallet, as a
+timestamping mechanism. You can take arbitrary data from people and
+anchor it into the blockhain, and you get a timestamp in zero additional
+space.
+
+## Sign-to-contract replay attack
+
+
+
+Sign-to-contract seems really straightforward: you can see the only way
+I've changed the signature scheme is that I've modified the R value,
+which is public data. So surely you should be able to tweak it and not
+have anything bad happen. You're not messing with any secret keys here.
+The final signature is based on adding that hash.
+
+How could this go wrong for me? You don't even need a security model-
+it's all public data. Well, that's not true. Here's the thing. In the
+last slide, I said hey uniform randomness is hard so why not generate
+our nonce by hashing a secret key and a message? Well, if you have a
+hardware wallet that is doing that, and then you ask it to do
+sign-to-contract, and say hey in the next signature you make I want you
+to not only sign this message but I also want you to commit to this
+other data. If the wallet is generating a secret nonce by hashing the
+real message and a secret key, then if you ask it for multiple
+signatures on the same message but different commitments then you can
+solve the resulting signatures and extract the secret key. The reason is
+the equation here, which I am not going to go into.
+
+Oops, so we have to think harder about this. The awful thing is that
+this isn't something that would be caught by a security model in a
+published paper. The reason being is that the vulnerability comes from
+our replacing our uniformly random nonces with some sort of hashes,
+which we argued was correct for single signatures. Intuitively and very
+well reviewed and audited, in a way that didn't actually correct for
+single signatures. We tried to add something unrelated, tweaking public
+data, what could go wrong? Well somehow these two things interact.
+
+## Sign-to-contract as an anti-nonce-sidechannel measure
+
+There's a solution. There's four things, the first three cause you to
+lose your key, and the fourth one I think saves you. It took us many
+iterations to get to this. Every time we tried something, something else
+would cause a problem and go wrong. I would like to say more about this,
+but I want to continue.
+
+((equations go here))
+
+## Multisignatures
+
+Let's talk about multisignatures real quick. Multisignatures are the big
+reason we want Schnorr signatures in bitcoin versus the existing ECDSA.
+The nice simple Schnorr equation I showed you has some nice algebraic
+properties. If you have a whole bunch of people producing signatures,
+you can just add the signatures together and the result will be
+somtehing that you can still verify.
+
+If everybody uses the same challenge to create a signature, and you add
+those together, you actually get a single signature on a single message
+with a single public key where that public key is jointly controlled by
+all of the participants. This is really straightforward. I took my first
+thing- from my first slide- and I said now everyone is going to do this
+independently. At each step, everyone tells each other what they did.
+Then they add up the values. You do that twice, then you get a
+signature, a multisignature. It's straightforward, fast, algebraically
+simple. It's correct, but is it secure? Sure, you can see the signature
+is the same as the original Schnorr signature so what could go wrong?
+
+The real cool thing about Schnorr signatures is that the difference
+between signing and verification is that the equation only changes by
+including those multiplications by the generator G. I apologize for not
+giving any introduction to elliptic curves before saying that. If you're
+familiar, you'll appreciate that.
+
+## Secure multisignatures
+
+musig: and
+
+
+What does it mean for a multisignature to be secure? So now the attacker
+can be one of the signers? Can the attacker freely choose a key? How
+about all the signers? All but one? Also, can you start multiple signing
+sessions in parallel?
+
+Secure multisignatures isn't just that nobody can forge. Now you have to
+think about all the different signers. You have a whole collection of
+signers, and none of them individually control the entire signing key?
+Well, what if one of them is bad? Or what if all of them are bad? If all
+but one are bad, that's something interesting. Suppose you have one
+honest signer in the middle of a multisignature, what can happen to
+them? Also, suppose you have one honest signer, and they are asking to
+be using the same key in multiple multisignatures at the same time. Note
+that there are multiple rounds in this algorithm. You could manipulate
+responses or do other bad things. It really makes the security model
+more complicated.
+
+When I start layering on these different things that an attacker can do
+in a multisignature setting, we're moving away from the intuition from
+the first few slides that we had defined the most powerful attacker. It
+should start to be uncomfortable. We're no longer able to enumerate all
+the possible attacks. This should make you uncomfortable. This is life;
+you end up with bigger security models that need to be reviewed very
+carefully.
+
+In fact, the multisignature scheme that I described earlier where
+everybody has everything is insecure. There's multiple problems. One of
+the problems is that the attacker can choose their key adaptively. This
+is called the rogue key attack. Suppose you have one attacker and a lot
+of honest participants, and they all want to produce a signature
+together. The attacker can wait for everyone else to provide their
+public keys, and then the attacker makes their public key by subtracting
+out everyone else's public key and saying hey my public key is this
+difference here. When you add these together, the result is just the
+attacker's public key by itself even though it was supposed to be the
+sum of everyone's public keys. So everyone in the protocol thinks it's a
+multisignature key, but it's actually just a single-signer key
+controlled by the attacker.
+
+There are a few iterations of ways to prevent this. In the end, in a
+signature scheme called MuSig, we hash everybody's public keys together,
+and then everyone's individual-- they are required to hash their signing
+key in the index of the session with that hash of everyone's keys, and
+it turns out that prevents these kinds of attack.
+
+Then there's another attack, where basically, there's a parallel attak:
+your attacker waits for everyone to choose their R values. They open
+1000 signing sessions in parallel, they wait for all the honest
+participants to choose R values and nonces. The attacker can grind these
+values, and they are able to get a free signature by doing enough
+parallel signing sessions and grinding their values. This was something
+we didn't see; we published a paper, and it almost got through the peer
+review process, where someone published a paper responding to our
+preprint. They didn't say our scheme was insecure; they said the proof
+technique in our paper could provably be shown to not be able to use our
+proof in the way we did. Six months later, there was a proof that it was
+insecure too. So anyway, you add a pre-commit phase to your signature
+protocol. The issue is that the attacker chooses their nonce after
+everyone else chooses their nonce, so you add a pre-commit phase to your
+signature protocol. So now everyone exchanges a hash of their nonce,
+then everyone exchanges their nonces, adds them up, then everybody
+exchanges their signatures and adds them up.
+
+## See also
+
+
diff --git a/__transcripts__/mit-bitcoin-expo-2019/utreexo.md b/__transcripts__/mit-bitcoin-expo-2019/utreexo.md
new file mode 100644
index 0000000..9640338
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2019/utreexo.md
@@ -0,0 +1,350 @@
+---
+parent: Mit Bitcoin Expo 2019
+title: Utreexo.Md
+Hidden: true
+TranscriptBy: Bryan Bishop
+---
+
+---
+
+layout: default parent: Mit Bitcoin Expo 2019 title: Utreexo
+nav_exclude: true transcript_by: Bryan Bishop
+
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Utreexo: Reducing bitcoin nodes
+to 1 kilobyte
+
+Tadge Dryja
+
+
+
+See also:
+
+
+## Introduction
+
+I am going to talk about another scaling solution and another strategy
+I've been working on for about 6-9 months, called Utreexo.
+
+## Bitcoin scalability
+
+Scalability has been a concern in bitcoin for the whole time. In fact,
+it's the first thing that anyone said about bitcoin. In 2008, Satoshi
+Nakamoto said hey I made this thing called bitcoin. Some guy on the
+mailing list, James A. Donald, said it sounds like an interesting idea
+but it doesn't really scale to the required size.
+
+If you look at bitcoin right now, it's about 221 GB for the blockchain.
+The chainstate data is around 3 GB. You have to download every block,
+verify every signature (except you don't), and keep an updated UTXO set
+which is the set of all the current coins. You need to download and
+process 220 gigs to get to the end state of 3 gigs.
+
+Some people may not know this, but you can use the pruning parameter.
+It's not the default, but maybe it will be soon. With pruning, you don't
+need to store all 220 gigs.
+
+## UTXO set
+
+How do you reduce the UTXO set size? You have a lot of things that help:
+lightning network, segwit, and now utreexo.
+
+UTXOs are where bitcoins live. They are called unspent transaction
+outputs. I don't know where the x comes from. Also there's a lot of
+confusion, people think addresses hold coins. But really it's more like
+coins have addresses. A UTXO has an address in it, but an address does
+not have a UTXO in it.
+
+## UTXOs
+
+UTXOs are pretty small. They are like 50 bytes, less than 64 bytes.
+There's a lot of them, though. There's like 60 million of them. It's
+been going down since the end of 2017. The number of UTXOs has been
+going down, but it was climbing before that. Long-term, it goes up. If
+you have bitcoin in any real sense, you have to have at least 1 utxo.
+Now, people can use exchanges where 1 utxo is shared between a lot of
+people... not as great. In lightning, you can have fractional ownership
+of a utxo in a more cryptographically secure way.
+
+Long-term, expansion of the UTXO set is a concern. The blockchain itself
+can be pruned. You verify old blocks, then you throw them away, and you
+can still be a fully-verifying full node. But if you don't have the UTXO
+set, you can't verify signatures because you don't know what the public
+key is supposed to be, you can't even tell if the UTXO exists.
+
+## SPV
+
+One solution is SPV. It's pretty widely used, but there's a lot of
+problems with it. SPV clients don't store the UTXO set, and they assume
+blocks are valid because there's Proof-of-Work work on them. Also, SPV
+nodes can't check signatures, and can't check that an input even exists.
+There's also privacy and other problems with SPV.
+
+SPV relies on the miners being honest and saying the right things.
+You're not validating data when you're using SPV. That's a pretty big
+downside.
+
+In SPV, you're telling all your addresses to some other machine, and now
+they know it's linked to you. There's block filters and some other
+ideas, but it's still an issue.
+
+## Accumulators
+
+A great way to deal with the UTXO set is that we don't need the whole
+UTXO set. We just need to verify that something is in there at a certain
+time. The other 60 million UTXOs aren't active at that time that you
+check the presence of a UTXO.
+
+An accumulator would help. Accumulators are a cryptographic construction
+where you hold some data, but the idea is hopefully small, like a
+constant sized or logarithmically sized accumulator. You can keep
+throwing data into it, and it doesn't get bigger, or if it does then it
+only gets bigger very slowly. People can then provide proofs that
+something was thrown into it at some point prior.
+
+A really simple accumulator only has addition and proofs where you add
+elements into the accumulator and you get back the updated accumulator
+and the proof, and then a verification function where given an
+accumulator, an element in the accumulator, and a proof, can return
+whether the element is really in the accumulator. This is an inclusion
+proof verification.
+
+## UTXO accumulators
+
+For a UTXO accumulator, we also need a delete operation. If you can only
+throw stuff in it, then you can't prevent double spends. Someone would
+be able to throw something into an accumulator, spend it, and next time
+they want to do a transaction they use the old inclusion proof and then
+spend it again. So you need to be able to add, delete, prove and verify.
+
+You can tie delete to verify. The only time you need to verify that a
+UTXO exists is when you're getting rid of it (spending it). An output
+appears, weeks past, and then the output is deleted, and that's the only
+time you need to know it exists.
+
+## UTXO accumulators in practice
+
+So how would this work, an accumulator-based ecosystem in bitcoin? You
+could have all the nodes potentially store the accumulator itself, and
+not the full UTXO set. They could store this very small representation,
+a cryptographically secure representation of the UTXO set, but they
+don't know the UTXO set. Then, wallets would manage the proofs. The
+wallet would maintain proofs that its UTXOs exist, and you would give
+the proofs to other people in the system. When you spend the coins, you
+prove to everyone else that they exist and that you're an owner. These
+proofs are public, it's all public data, but it's sort of the same
+responsibility. If they are your coins, you need to prove they exist,
+and prove that it's yours. Proving that it's yours is the private key,
+and the proof that it's there is this accumulator inclusion proof.
+
+Right now, you could have things that are sort of like externalities
+where an exchange has 10 million UTXOs and makes dust outputs and weird
+OP_RETURN things. If you have a wallet and you're running it in a weird
+way, that's on you. The resource cost will be on you, and it's a minimal
+resource cost on the rest of the network instead of bloating the UTXO
+set.
+
+## Other accumulators work
+
+There has been some other recent work on accumulators in this area.
+Benedikt Bunz at Stanford has been talking about RSA accumulators. They
+have gotten much more compact and they have fast proofs. They also said
+you could use "class groups" which are a bit novel (although old). It's
+cool, but there's a difficulty: you can't aggregate proof updates. The
+proofs change. Every time a block occurs, new things get thrown into the
+set, and the proofs actually change. Even if the UTXOs haven't changed,
+everything else around it has changed, so the inclusion proofs have to
+change.
+
+In the RSA case, if you want to change all the millions of proofs at
+once when a block comes in, that seems like it's not possible. In my
+design of a hash-based accumulator, it's possible.
+
+## Wallets
+
+Why is this a problem? I said that wallets need to track their own
+UTXOs. That's nice and idealized. It moves the bloat from network-wide
+to the specific wallet that owns those coins. But in practice, they
+aren't going to keep track of their proofs and keep updating them.
+Wallets can go offline. They will probably outsource this.
+
+## Bootstrapping
+
+There's another problem, which is bootstrapping. If I write this
+software and say cool I'm using an accumulator and I have proofs for all
+the UTXOs in my wallet. I connect to the network, and ask for a block,
+and then you ask them for UTXO inclusion proofs. They will wonder what
+you are talking about: they have never heard of this protocol.
+
+If I'm the first person trying to use this, nobody will give me proofs.
+Even if I'm the second or third. I need every wallet to start supporting
+this. It's technically a soft-fork because you're requiring new things,
+but yeah it's not going to happen.
+
+## Bridge nodes
+
+So what you need, and I believe Pieter Wuille came up with this term, he
+sort of inspired a lot of this research because he said yeah all this
+accumulator stuff isn't going to work because you are going to need a
+"bridge node".
+
+The bridge node maintains a proof for everything. It has the whole UTXO
+set, and it also has this accumulator, and it also has a proof for
+everything in the accumulator. When it sees a transaction without a
+proof, it can stick a proof on it, and hand it over to the people who
+want proofs.
+
+This is problematic for RSA accumulators because updating those
+proofs... there's 60 million UTXOs, and if you have 60 million UTXO
+proofs to update, then that's 60 million RSA operations. Actually, it's
+worse, because it's one operation for each change in the accumulator. If
+there's 5000 changes in a block, then that's 5000 times 60 million. It
+gets bad. It's feasible with like many racks of servers but not very
+bitcoiny. We would like this to be able to run on crappy laptops.
+
+## Utreexo accumulator
+
+The utreexo accumulator is basically a merkle tree. I hope people are
+familiar with merkle trees (the parent is the hash of the children
+concatenated together). A merkle tree is like an accumulator. But you
+can't add to it if you only know the root hash. You only keep the top in
+a regular merkle tree. You prove inclusion of a leaf by giving a branch
+and you hash the siblings.
+
+So let's make a merkle tree accumulator for UTXOs. A bridge node in this
+case would store the whole tree, and it could create proofs very quickly
+by just going up the tree. The proofs are inherently aggregated: when I
+change anything in the tree, the top will change, because it's a hash of
+everything in the tree.
+
+So you need to use a bunch of trees; it's not constant sized like a
+merkle tree. It's actually log(n), which isn't too bad. It would be cool
+if it was O(1) but whatever.
+
+## Perfect forest
+
+You recompute the merkle tree, and include the previous merkle tree root
+as a child in the merkle tree structure at the top level. Each time you
+update the tree, you include the previous version in the current tree.
+There are papers describing this, it's not novel, although it's cool.
+
+## Deleting
+
+Deleting I think is novel. I looked through papers, I think this is new.
+Worst case, I try to publish and then someone says here's a paper from
+20 years ago where they try to do this.
+
+You first need to prove something in order to delete it, which matches
+up to our use case in bitcoin. The idea is that there are three
+algorithms. If you have two deleted siblings right next to each other,
+you can skip this and just delete the parent. But otherwise, if there's
+one sibling kept and one deleted sibling, you move them around. This is
+a swap operation. You move nodes around to get twin pairs of deletions.
+This might not be possible because you might not know in the tree, but
+it's actually the case that if there's a deletion occurring, the
+inclusion proof will always give you enough information to perform this
+swap operation. The root operation is that if there's a deletion then
+you can move to or from the root on that level. The twin rule and the
+swap rool are just optimizations, you could do deletions with just the
+root rule one at a time.
+
+It works. It's complicated, but it's super fast for a computer to do. It
+doesn't impact speed much.
+
+You can batch delete a lot at a time, like a block-worth of UTXO spends
+like in bitcoin.
+
+The main downside here is that you have these proofs and they can be
+kind of big. The nice thing is that you're adding stuff on the side over
+here, which has smaller trees. A lot of times, UTXOs appear and
+disappear very quickly. Everyone waits 6 confirmations and then
+immediately spends their coins. But a lot of time, UTXOs are short
+lived. So if you push them to one side of the tree, then your proofs are
+going to be smaller. Old coins are unlikely to be spent, so it's okay if
+they have larger proofs.
+
+## Proof size
+
+So the biggest downside is now we have all these proofs. How big are
+they? 1 proof is around 20 hashes. With 32 byte hashes, that's 640 bytes
+for a proof. With 5000 inputs in a block, that's 3.2 MB for all the
+proofs. This isn't good-- this means youre 200 GB initial block download
+is going to get way bigger.
+
+Proofs can be aggregated, though. If things are next to each other in
+the merkle tree, the proofs get smaller. You can prove many things with
+a smaller branch. Aggregation can help. There's a lot of optimizations:
+how to optimize this and make the proofs smaller?
+
+## Initial block download hints
+
+You can remember nodes in tree. You could remember the last blocks of
+proofs. The servers know how long the UTXOs last, they can tell you
+things and hash things and just let you know. It could help with initial
+block download.
+
+If you want to be really hard core with Utreexo and have like only 1
+kilobyte of memory for the UTXO set... you could do it, but you would
+have a 100%+ data overhead where you have to download 200 GB of proofs,
+and that's going to keep up as you're keeping up with the blockchain. If
+you have a bit more RAM, then you could store a larger part of the tree
+and download less.
+
+Here are some preliminary results. If you have no RAM at all, you need
+like 7 billion hashes, which is 237 GB, and you have overhead of like
+112%. If you use 300 MB, you only download 68 GB and your overhead is
+33%. If you use 5 GB of RAM, you download only 5.4 GB and your overhead
+is 2.6%. There's possible optimizations here and hopefully bringing
+these numbers down.
+
+## Cheating
+
+When I talk about this, people say oh it's a UTXO commitment. No, it
+doesn't commit. But it could: you could put the root of this tree in the
+coinbase and then people can skip validation. Hopefully they wont do
+that. But if you sync on your desktop and you trust its node, then you
+could make a little QR code that has the entire state of the accumulator
+and take the picture with your phone and now your phone is fully synced
+up with only a few hundred bytes. That's a valid use case, but yeah
+people will abuse this.
+
+## Things to improve
+
+Right now there's lots of optimizations that are possible. Right now
+deletes and adds are separate. Merging them could save on proof size and
+CPU time.
+
+Lookahead optimization feels NP-hard. But optimal strategy exists- what
+are the heuristics?
+
+I feel like it's our job to help the crummy computers because we wnat
+everyone to be able to use bitcoin.
+
+It might be possible to get a proof that you don't really need collision
+resistance in the hash function. I'm pretty sure this is the case, but
+it's scary. You could get space savings this way.
+
+Also, this is not a fork. We don't need a soft-fork. It's a peer-to-peer
+thing like compact blocks or bip151. So that's nice, it's permissionless
+innovation.
+
+Long-term, this helps scale the network. You could run a full node with
+1 kilobyte of space. You could run it on a router maybe. There's code
+up, I was hoping to write a paper.
+
+
+
+## Q&A
+
+Q: Who can run a bridge node?
+
+A: Ah, it's about 10 GB of space on your drive and minimal extra CPU. In
+the future, maybe this will be an option in Bitcoin Core to run a
+utreexo bridge node. It would be like running an archive node today. You
+don't really need to serve 220 GB to people, but people do it because
+it's low cost and people want to. I don't think you need an ICO coin to
+incentivize people to use utreexo. You could theoretically shard it
+between multiple bridge nodes, but right now it's not that big so you
+can run it on a regular node.
diff --git a/__transcripts__/mit-bitcoin-expo-2020/2020-03-07-andrew-poelstra-taproot.md b/__transcripts__/mit-bitcoin-expo-2020/2020-03-07-andrew-poelstra-taproot.md
new file mode 100644
index 0000000..eb9f7a8
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2020/2020-03-07-andrew-poelstra-taproot.md
@@ -0,0 +1,511 @@
+---
+layout: default
+parent: Mit Bitcoin Expo 2020
+title: 2020 03 07 Andrew Poelstra Taproot
+nav_exclude: true
+transcript_by: Bryan Bishop
+---
+
+{% if page.transcript_by %} Transcript by:
+{{ page.transcript_by }} {% endif %} Name: Andrew Poelstra
+
+Topic: Taproot - Who, How, Why
+
+Location: MIT Bitcoin Expo 2020
+
+Date: March 7th 2020
+
+Video: https://www.youtube.com/watch?v=1VtQBVauvhw
+
+BIP 341: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
+
+## Intro (Hugo Uvegi)
+
+I am excited to introduce our first speaker, Andrew Poelstra. He is
+coming to us from Blockstream where he is Director of Research. He is
+going to be talking about Taproot which I think is on everybody’s mind
+these days.
+
+## Intro (Andrew Poelstra)
+
+Thanks for waking up so early for the first day of the conference and
+making the trek from the registration room over here. It is more faces
+than I expected considering. Hello to all the livestream people hiding
+from the Corona virus. I hope it doesn’t reach you, best of luck. I told
+myself I was going to write my slides on the plane. As you can tell I
+instead spent the entire plane ride drawing this title slide. I am very
+proud of. I hope you enjoy it. I am going to split this talk into two
+halves. I have only got 20 or 30 minutes. I can’t really describe
+Taproot in full detail in half a hour, probably even in a couple of
+hours. Instead I am going to give a brief overview of what Taproot is,
+describe some of the technical reasons for it being what it is and give
+a high level summary of the components of it. In the second half of the
+talk I am going to talk more generally about how we design proposals for
+Bitcoin, the considerations we have to make for a system with such high
+uptime requirements with so many diverse stakeholders who all more or
+less have a veto over proposals but nobody has the ability to push
+things through. And where everything is very conservative. We are all
+very afraid of deploying broken crypto or somehow breaking the system or
+causing a consensus failure or who knows what. Let’s get into it.
+
+## What is Taproot?
+
+First half, what is Taproot? Taproot is a proposal for Bitcoin that was
+developed originally by Pieter Wuille, Greg Maxwell and myself. It has
+since been taken up by probably 10 major contributors who have been
+doing various things on IRC and on the mailing list over the last year
+or two. It is a new transaction output version, meaning that it is a new
+to define spending conditions for your coins on Bitcoin. I am going to
+talk about what that means.
+
+## Spending Conditions: Keys and Scripts
+
+First off for those who don’t know Bitcoin has a scripting system. It
+has the ability to specify spending conditions on all of the coins.
+Typically for casual users the way we think of Bitcoins, you have an
+address, the address represents some sort of public key. You have a
+secret key corresponding to the public key and if you can produce a
+signature with that secret key you can spend the coins. This is actually
+a special case of what Bitcoin can do. It is not just one key, one
+signature kind of thing. We have the ability to describe arbitrary
+spending conditions where arbitrary means specifically you can check
+signatures with various public keys like you do with the normal one key
+standard wallet. You can check hashlocks which means you can put a hash
+of some data on the blockchain and it will enforce that somebody reveals
+the preimage of that which is a way to do a forced publication of some
+shared secret say. It can do timelocks where it won’t allow coins to
+move until some amount of time has gone by. You can do arbitrary
+monotone functions of these. You create a circuit out of ANDs and ORs,
+threshold 2-of-3 or 5-of-10 of these different checks. You can do
+arbitrary sets of these. The mechanism for these is called Bitcoin
+script. Script can do a fair number of other things, most of which are
+not super exciting. It can’t do a whole bunch of things. In particular
+you can’t use Bitcoin script to enforce things like velocity limits. A
+common thing people want to do is have a wallet where they have some
+coins that say only a certain amount of coins are allowed to move in a
+given day. That kind of thing you can’t do with Bitcoin script. For
+people thinking about future research directions for Bitcoin this the
+kind of missing functionality we have. Although as we will see by the
+end of this talk it is not as straightforward as having a cool idea and
+everybody cheering for you.
+
+## Spending Conditions: Scripts and Witnesses
+
+An interesting thing about script. We use this word “script” which
+conjures up connotations of scripting languages like shell or Python or
+PHP or Node or whatever people use these days. A difference between
+Bitcoin Script and an ordinary scripting language is that in Bitcoin
+Script you are describing conditions under which a spend is valid. You
+aren’t executing a bunch of code. You literally are executing a bunch of
+code but morally what you are doing is demonstrating that some
+conditions exist that were sufficient to spend the coins and you have
+met those conditions. Scripts often specify a wide set of conditions.
+Say you have a 2-of-3 signature check then there are 3 different public
+keys. Any pair of those could be used to spend them. You may have a
+timelock with an emergency key. Maybe after a certain time has gone by,
+the original 3 keys have been lost, then there is an alternate key. You
+can do this but what hits the blockchain when you are spending coins is
+only one condition. You have the script that is describing a whole bunch
+of different things. Ultimately only one of them matters. Only one of
+them matters once the coins are spent. If they don’t get spent none of
+them matter. So it would be nice from a privacy/scalability perspective,
+it is nice I can bundle those up, there is usually a trade-off there.
+For the purposes of this talk privacy and scalability are going to come
+hand in hand. It would be ideal if we weren’t even revealing all these
+spending conditions. If at most one of them matters why are we
+publishing them all? Why are we making everybody download them? Why are
+we making everybody parse these? Why are we everybody check that they
+make sense and that they hash to the right thing etc.
+
+So around 2011, 2012 on Bitcointalk I believe, which is where all
+Bitcoin ideas were invented. You can Google them and resurrect them as
+easy publication. There was an idea called MAST, Merklized Abstract
+Syntax Tree. I think now it is Merklized Alternate Script something or
+other. It is not quite MAST. The idea is that you take all these
+different spending conditions, you put them in what is called a Merkle
+tree. You take all the conditions, you hash them up, you take all the
+hashes, you bundle those together and hash them up. You get this
+cryptographic object that lets you cheaply reveal any one of the
+conditions or any subset of the conditions without needing to reveal all
+of them. This is smaller. What actually hits the chain is just a single
+32 byte hash representing all the different conditions. When you use one
+of the conditions you have to reveal that condition and also a couple of
+hashes that give a cryptographic proof that the original hash committed
+to it. This idea has been floating around for quite a while. It has
+never been implemented. Why hasn’t it? For a couple of reasons that I am
+going to go into in more detail. One is that for something like MAST
+there is a wide range of design surface and because changes in Bitcoin
+are so far reaching and so difficult to do nobody wants to post
+something for Bitcoin and nobody wants to accept a proposal for Bitcoin
+that isn’t the best possible proposal that does what we are trying to
+do. For years we have had variations on different ways to do MAST.
+Different ways to hide script components. Questions about should we
+improve the script system at the same time as we are doing this? Should
+we change the output type and so on. Since 2012 we have had a number of
+different upgrade mechanisms appear. We have learnt a lot more about the
+difference between hard forks and soft forks and when hard forks are
+necessary and what they are appropriate for. We have learned new ways to
+soft fork in changes, especially changes to the script system, in ways
+that minimize disruption to nodes that haven’t updated. On all levels of
+this kind of change we have made a lot of progress over the last several
+years. In one sense it has been worthwhile. It is great that we didn’t
+try to deploy this in 2012 because what we did would have sucked. On the
+other hand it is 2020 and we still don’t have it. There is this
+trade-off that I’m going to talk about a bit more.
+
+## Spending Conditions: Keys Tricks
+
+That is one of the two major ideas in Taproot. It is this thing MAST.
+You put all your spending conditions in a Merkle tree. You only have to
+reveal one. Nobody can see how many there are. Nobody can see what the
+other ones are, everything is great. The second part of Taproot is this
+family of things I am going to call key tricks. The standard Bitcoin
+script, address, whatever you want to describe it as, has a single key.
+You spend the coin by providing a single signature. Traditionally a
+public key belongs to one entity. It identifies that identity and it
+identifies the person who holds the private key, the person who is able
+to spend those coins. The idea is that there is one person with this
+private key. One person has complete and sole custody of the coins. It
+turns out there is a lot more you can do with keys, with single keys. A
+lot of this stuff is made much easier using Schnorr signatures versus
+ECDSA. I am not going to go into that but I am going to throw that out
+there. These are two different digital signature algorithms. They both
+use the same kind of keys but Schnorr signatures let you do some cool
+things with the keys in a much simpler way. The most important one that
+I have highlighted here is multisignatures. If you have several
+participants who all individually have a signing key, it is possible for
+them to combine all of their keys into one. What they do is they all
+choose some randomizers, they all multiply their key by some randomizer.
+This is a technical thing that prevents them from creating malicious
+keys that cancel out other participants. They add them together. I am
+using add in the sense of elliptic curves which is really like addition
+that most people are familiar with. But it behaves algebraically exactly
+like addition so we call it addition. You add these keys together, you
+get a single key out of this. Then what is cool is all these
+participants by cooperating are then able to produce a single signature
+for this single key and publish that to the blockchain. What the
+blockchain is going to see is one key and one signature. The same as if
+there was only one participant. The same as if it was an ordinary wallet
+that is not doing anything remarkable. But in fact behind the scenes
+there are multiple parties that all share custody of these coins and
+they all had to cooperate to move the coins. That is a cool thing. You
+can do variants of this. You can do threshold signatures. Instead of
+having 5 participants who all their combine their keys and then the 5 of
+them cooperate. You can have 5 participants combine their keys in such a
+way that any 3 of them might cooperate. There are 5 choose 3 different
+possibilities here and any of those 5 choose 3 possibilities of sets of
+signers are able to spend the coins. This requires a little bit more
+complicated interaction protocol between the individual participants but
+again what the blockchain sees is just one key, one signature. You can
+do more interesting things than thresholds. You can do arbitrary
+monotone functions, arbitrary different sets of signers can all be
+bundled together into one key which is pretty cool.
+
+Another thing you can do with keys and signatures that we have learned
+is something called adaptor signatures. If you have two parties doing a
+2-of-2 multisignature, they both have to cooperate to spend the coins,
+they can modify the multisigning protocol such that when the second
+party finishes the protocol, they complete the signature, by doing so
+they reveal a decryption key for some secret to the other party. A lot
+of what we use hash preimages and hashlocks for in Bitcoin is when you
+have two parties and you want one to have to reveal a secret to the
+other as a condition of taking their coins. We can bundle that into the
+signatures. I am not going to go into that but the keyword to lookup
+would probably be adaptor signatures or scriptless scripts. Adaptor
+signatures are the specific construction I am describing. This is the
+only equation that I am going to have in all these slides, last year I
+did 100 equations in a row in half a hour at the first talk of the Expo
+and I was told I scared people. This is a commitment equation.
+
+`P -> P + H(P,m)G`
+
+What is going on here? On the left hand side I have P for public key. I
+am going to modify my public key here. I am going to add the hash of the
+original public key and some arbitrary message m. I am going to multiply
+that by the generator of my elliptic curve group. What this
+multiplication does is converts this hash, which is a number, into a
+point which is a public key. This allows me to add them together. The
+effect of doing this transformation is that before I had a public key
+that I or some people knew the secret key to. Afterwards I have a
+different public key which the same set of people know the secret to. I
+have just offset it by this value which is a hash of public data.
+Anybody can compute it, I have just offset it. I haven’t changed the
+signing set at all. What I have done is turn the key from just a boring
+old key into a key that is actually a cryptographic commitment to this
+message m. I am using an arbitrary hash function H. If that hash is a
+cryptographic commitment, specifically if it is reasonable to model it
+as a random oracle then this construction also works as a hash. You can
+also model it is a random oracle and you can see that as long as I had a
+uniform distribution of hashes I am going to get a uniform distribution
+of points out of this. What is the point of this? The point of this is
+if I’m on the blockchain, I’m publishing a key and this key represents
+some sort of spending conditions. Now I can do one better, I not only
+have a key on the blockchain I have a commitment to some secret data.
+What is this good for? This is good for a couple of non-blockchain
+things like timestamping say. If I have some data, I want to prove that
+it existed at some point I can hide it inside of one of my public keys
+that I was going to put on the blockchain anyway. That goes into the
+Bitcoin blockchain that timestamps it. I have a whole bunch of proof of
+work on it. There are a certain number of blocks that were created after
+it. Everybody has a good idea of when every Bitcoin block was created,
+at least within a few minutes or a few hours. I have a cryptographic
+anchor for my message m to the blockchain. You can also use this to
+associate extra data to a transaction that the Bitcoin blockchain
+doesn’t care about.
+
+For example at Blockstream we work on a project called Liquid which is a
+sidechain, it is a chain where you can move coins from the Bitcoin chain
+onto this other chain, Liquid. The mechanism of doing that is all the
+coins that are on the alternate chain, from Bitcoin’s perspective these
+are actually in the custody of this 11-of-15 quorum of who we call
+functionaries. To move coins onto the chain, you send them to the
+functionaries and then you go onto the sidechain and you write a special
+transaction saying “I locked up these Bitcoin, please give them to me on
+the sidechain.” The consensus rules of the sidechain know how to look at
+Bitcoin and verify that you did so. How do you say this is me? You are
+sending the coins to the functionaries, they are the same 15 people all
+the time. How do you identify that you were the one who locked up the
+coins when from Bitcoin’s perspective you gave them to the same people
+that everybody else did. You use this construction. You put some
+identifying thing here in this message m, throw that onto the Bitcoin
+blockchain. You then reveal m on the sidechain and the sidechain
+validators can verify this equation is satisfied. That is an example use
+of this.
+
+## Taproot Assumption
+
+“If all interested parties agree, no other conditions matter”
+
+The coolest use is going to be in Taproot. Let me throw out this maxim,
+the Taproot assumption. In most situations, most uses of Bitcoin script,
+you have this wide range of spending conditions that represent different
+possibilities for how your parties might interact, but ultimately you
+have a fixed set of parties that are known upfront. In a Lightning
+payment channel you have got the two participants in the channel. In an
+escrow type arrangement you have got the two parties in the escrow. In
+Liquid you have got the 15 functionaries who are all signing stuff. On a
+standard wallet you have got the one individual party. If everyone who
+has an interest in these coins agrees to move the coins they can just
+sign for the coins. As I mentioned two slides ago they can sign for the
+coins using a single key that represents all of their joint interests
+and do so interactively. The Taproot assumption is that in the common
+case, in the happy case of moving Bitcoin you only actually need a key
+and a signature. All this scripting stuff is there as a backstop for
+when things don’t go well or when you have weird requirements or weird
+assumptions. With that said we can get into where pay-to-contract comes
+in, where this commitment thing comes in. Here is where I describe what
+Taproot is.
+
+## Taproot
+
+We use MAST to hide our spending conditions in a giant Merkle tree. We
+get a single hash. We take that hash, we use our key commitment
+construction to commit to that hash inside of a public key which you put
+on the blockchain. Then we say the public key is how you spend the
+coins. What hits the chain is a single key, in the happy case with a
+single signature. Nobody even sees that any additional conditions exist.
+If you do reveal that they only see one of the conditions. In the
+typical case whether you are a normal wallet with a single key that is
+on a user’s hardware wallet or something, or if you are doing an escrow,
+or if you are doing a Lightning channel, or if you are doing a Liquid
+transfer, if you are doing a non-custodial trade, whatever you are
+doing, what hits the chain is one key, one signature. This is cheaper
+for everyone to validate than putting all the conditions explicitly on
+there. It is also much better for privacy because you are not revealing
+what the conditions are, you aren’t revealing that there were any
+special conditions. You are not revealing how many participants were
+involved, how many people have an interest and what that interest looks
+like. You are not revealing any of that. That’s Taproot. There’s a whole
+bunch of detailed design stuff that I am not going to go into here. At a
+high level that’s the idea.
+
+## Designing for Bitcoin
+
+In the next five minutes let me talk about some of the design
+considerations that went into this. The different ways that we had to
+think about Taproot.
+
+## Is Bitcoin Dead?
+
+Before I do that let me quickly talk about Bitcoin development. I know a
+lot of people here are MIT students or students from other universities.
+There is a perception that there is a lot of really cool stuff happening
+in the cryptocurrency world. There are all these new things being
+developed, all these new technologies being deployed. Meanwhile Bitcoin
+is the dinosaur in the room. It never really changes and it doesn’t have
+any of the cool stuff. It doesn’t have the cool scripting language, it
+doesn’t have all the cool privacy tech. It doesn’t have DAGs, all this
+cool stuff. There is this idea that Bitcoin maybe hasn’t really changed
+in the last several years. We don’t have new features and new press
+releases saying “Here is a cool thing you can do on Bitcoin that you
+couldn’t do before.” On some level everything you can do in Bitcoin in
+2020 was technically possible in 2009. Although very very difficult and
+very inefficient for many reasons. The reason for this perception is
+that deploying new things on Bitcoin is very slow. If you have a
+proposal you need to write it up, you need to have a detailed
+description of the proposal. You need to have code that is written. You
+need to have a fair bit of buy-in from the developer community. That is
+to just have a proposal, to have something that somebody is willing to
+give a BIP number to. A BIP number means almost nothing. Then you need
+to go through probably years of review, you need to get input from
+various stakeholders in the ecosystem, you need to go through all this
+rigor and rigmarole. It is a very long process and it can feel
+frustrating because there are a lot of other projects out there where
+you have a cool idea, you show up on the IRC channel and they are like
+“Wow somebody is interested in our stuff. We will deploy your thing of
+course.” Then you get stuff out there. You see various projects that are
+having hard forks every six months or something, deploying cool new
+stuff that is very experimental and very bold. That is super exciting
+but Bitcoin can’t do that. The requirements in Bitcoin are much higher.
+In particular Bitcoin is by far the most scalable cryptocurrency that is
+deployed and it is probably not scalable enough for serious worldwide
+usage. We are really hesitant to do anything that is going to slow down
+validation. Even to do anything that doesn’t speed up validation. That
+is maybe the most pressing concern. Others would argue that privacy is
+the most pressing concern. That is also a very valid viewpoint.
+Unfortunately improving privacy often comes with very difficult
+trade-offs that Bitcoin is unable to make in terms of weird new crypto
+assumptions or speed or size. Despite the difficulty in deploying things
+the pace of research in Bitcoin is incredibly fast. I hinted at all of
+these things we can do with keys and signatures. Over the last two years
+we have seen this explosion of different cool things you can do just
+with keys and signatures. There is an irony, it is so slow to deploy
+stuff on Bitcoin. What do we have? We have keys, what can we do with
+keys? But we have actually done a tremendous amount with keys, far more
+than anybody even in the academic cryptography space would’ve thought.
+Let’s do cryptography but the constraint is you are only allowed to
+output a key and a signature at the end. First of all they would say
+“That is the most ridiculous thing I have ever heard.” I actually did a
+talk at NIST once and I got belly laughs from people. They thought it
+was hilarious that there was this community of Bitcoin people who had
+tied their hands behind their backs in such a dramatic way. A result of
+all this is that there is a tremendous amount of research that is
+developing really cool stuff. Really innovative things that wind up
+having better scalability and better privacy than those things that we
+would’ve deployed in the standard way where we are allowed to have new
+cryptographic assumptions, we are allowed to use as much space as we
+want or we are allowed to spend quite a bit of time verifying stuff.
+
+## The Unbearable Heaviness of Protocol Changes
+
+As I mentioned, I am going to rush through these two slides, there is a
+lot of difficulty even if you have a proposal that checks all these
+boxes you have got to get through a whole bunch of hoops. This change
+has to be accepted by the entire community which includes very many
+people. It includes miners, the protocol developers, the wallet
+developers who often have opposing goals, HSM developers who are in
+their own little world where they have no memory, no space and no state
+and they want the protocol to be set. We have retail users who just want
+their stuff to work and who often want bad things to not happen even
+when the cryptography guarantees that bad things will happen to them.
+You have institutional users who care even more about bad things not
+happening. Exchanges, custodians etc. All of these people have some
+interest in the system. All of these categories represent people who
+have a large economic stake in the system. If any change makes their
+lives meaningfully worse without giving them tremendous benefit they are
+going to complain and you are not going to get your proposal anywhere.
+You are going to have endless fights on the development mailing list.
+Just proposing an upgrade at all is making people’s lives worse because
+now they have to read stuff and you are going to have fights about that.
+
+Bitcoin, I checked this morning, has a market capitalization of about
+170 billion dollars. This is not flash in the pan money, it has been
+over 100 billion dollars for several years now. When we deploy changes
+to Bitcoin on a worldwide consensus system these changes can’t be
+undone. If we screw up the soundness and it forks into a million
+different things. There is no more agreement on the state of the chain,
+probably that is game over. If people lose their money, if coins can get
+stolen it is just game over. It may even be game over for the whole
+cryptocurrency space. That would be such a tremendous loss of faith in
+this technology. Remember in the eyes of the wider public, as slow as
+Bitcoin is to us, it is really fast, reckless, all this crazy cypherpunk
+stuff, going into a computer system that has nobody in charge of it that
+is supposed to guarantee everybody’s life savings. It is nuts. If we
+screw it up we screw it up, game over. We all find new jobs I guess.
+Maybe go on the speaking circuit apologizing. That is the heaviness of
+protocol changes.
+
+## Tradeoffs
+
+A couple of quick words about cryptography. In the first half of the
+talk I was talking about all these cool things we can do with just keys,
+just signatures. Isn’t this great? No additional resources on the chain.
+That is not quite true. You would think adding these new features would
+involve some increase of resources at least for some users. But in fact
+we have been able to keep this to a couple of bytes here and there. In
+certain really specific scenarios somebody has to reveal more hashes
+than they otherwise would. We have been spoilt with the magic of
+cryptography over the last several years. We have been able by grinding
+on research to find all these cool new scalability and privacy
+improvements that have no trade-offs other than deployment complexity
+and so forth. Cryptography can’t do everything, we think. There aren’t
+really any hard limits on what cryptography can do that necessarily
+prevent us from just doing everything in an arbitrarily small amount of
+space. But it is an ongoing research project. Every new thing is
+something that takes many years of research to come up with. When we are
+making deployments, I said if we make anyone’s lives worse then it is
+not going to go through. This includes wasting a couple of bytes. For
+example on Taproot one technical
+[thing](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html)
+I am going to go into is we had public keys that took 33 bytes to
+represent. 32 bytes plus one extra bit which represents a choice of two
+different points that have the same x coordinate. We found a way to drop
+that extra bit, we had to add some complexity. There was an argument
+about how we wanted to drop that extra bit and what the meaning of the
+bit would have been. Would it be the evenness or oddness of the number
+we alighted, would it be whether it was quadratic residue? Would it be
+what part of the range of possible values it lives in, stuff like this.
+That is the kind of stuff that we spent quite a while grinding on even
+though it is not very exciting. It is certainly not some cool new flash
+loan technology or whatever that various other projects are deploying.
+This is stuff that is important for getting something through on a
+worldwide system where everybody is a stakeholder and no one wants to
+spend money on extra bytes.
+
+## Political Things
+
+Finally a few general words about politics. I deliberately ran out of
+time here so I wouldn’t have to linger on this slide. I have said most
+of this. Usually when we think about Bitcoin politics, those of us who
+have been around for a little while think about the SegWit debacle where
+we had this UASF thing going on. We had miners doing secret AsicBoost
+and we had misalignment of incentives between users, developers and
+miners. There was this fork, Bitcoin Cash, all this grandstanding.
+People saying “We are going to create a fork such that we have no replay
+protection so that if you don’t give us what we want we will cause all
+this money loss.” That was pretty dramatic but that is not really what
+Bitcoin politics is like generally. Generally Bitcoin politics are the
+things that I have been talking about. You have a whole wide set of
+participants who are generally afraid of change and complexity for very
+good reason by the way. We have seen a lot of technology failures on
+other projects deploying things too rapidly. We have a lot of people who
+feel that Bitcoin is increasingly onerous to validate. The blockchain is
+getting too large, it is already too much of a verification burden.
+That’s is what we should be doing, reducing that somehow. We have people
+who think privacy is the most important thing. Again with good reason.
+Bitcoin’s privacy story is absolutely horrible. We have an aversion to
+reading stuff, as people in this room probably are aware, when you
+propose things for Bitcoin it can be hard to get people to read your
+emails. Especially if you have some cool new crypto that requires a lot
+of cognitive load for people to read and for people to deploy. It can be
+difficult to compete for people’s attention. Even once you succeed on
+that there is a long process. There is going to be a lot of bikeshedding
+on various trivial features of your proposal that you have to be polite
+with and try to come to a conclusion. On the opposite end with
+bikeshedding you are going to get demands for proof, demands that you
+prove your idea and you deploy it in a solid way. That can take quite a
+bit of time and energy.
+
+## Q&A
+
+Q - This would work for any blockchain or ledger? Grin etc It would work
+for all of them?
+
+A - Absolutely. But in Bitcoin there is a much more extreme aversion to
+experimental technology. All the blockchains you mentioned were deployed
+around some new technology that they wanted to prove. By nature these
+are more willing to accept new ideas or ideas that maybe have different
+trade-offs in terms of algorithmic complexity or cryptographic
+assumptions or something like that. But any blockchain that expects to
+survive and expects to continue to work for its users, all these
+considerations apply.
diff --git a/__transcripts__/mit-bitcoin-expo-2020/_index.md b/__transcripts__/mit-bitcoin-expo-2020/_index.md
new file mode 100644
index 0000000..c73e17b
--- /dev/null
+++ b/__transcripts__/mit-bitcoin-expo-2020/_index.md
@@ -0,0 +1,7 @@
+---
+layout: default
+has_children: true
+title: Mit Bitcoin Expo 2020
+---
+
+{{< childpages >}}