Interview Adam Back Elizabeth Stark
Speakers: Adam Back, Elizabeth Stark
Date: September 10, 2017
Transcript By: Bryan Bishop
Tags: Lightning
Category: Conference
Media: https://www.youtube.com/watch?v=0WCaoGiAOHE&t=1h58m3s
https://twitter.com/kanzure/status/1005842855271784449
stark: Thank you Giacomo. Who here had too much fun at the party last night? My voice is going. Hopefully it will stay for this interview. We are lucky to have Adam Back here today, co-founder of Blockstream and inventor of Hashcash (history). He just happened to appear and there was an available spot. Thank you for making this work.
adam3us: Thank you for inviting me.
stark: I’m a co-organizer of this event. I am also founder of Lightning Labs. We thought we wanted to make a really cypherpunk event. Who better to have speaking with us than one of the original cypherpunks. You were involved in the early days. What was going on back then and how did you get involved?
adam3us: At that time, PGP was pretty new. People were pretty excited about the change in the balance of power in that an individual could exchange encrypted email such that a government couldn’t intercept or decrypt them. For many people it was about “doing”. Just building things, rather than seeking permission to build things. This is a concept from startups. Skype didn’t go to seek permission from regulators and telephony is a very regulated space. They built technology, and then users adopted it. Technology that is deployed effects regulations and changes societal norms. Regulations and laws are trailing by maybe 50 years or something. Cypherpunks wanted to effect positive social change by deploying technology without permission. PGP was one of those technologies. Many of these things are based on protecting rights that you have under law. Another form of privacy and freedom is freedom of association, to have free association online you need anonymous communication. The cypherpunks also built the first anonymous remailers. It was through running one of those that I discovered the sort of spam problem. Normally, spam is dealt with by identity typically, and you associate identity too much with email then that creates other problems like non-intentional repudiation, audit logs that can show up in court, stuff like that. The remailers at the time allowed you to post on USENET groups. People would spam through the remailer and send to usenet groups and it would get broadcasted everywhere and it would have high expense to the world. I looked into ways to reduce spam or throttle spam and that’s where hashcash came from. The idea was to have a computational postage stamp that you could create with 30 seconds or a few minutes of work and attaqch this electronic postage stamp to the email and the recipients could check it locally with local information. It had good scalability.
stark: Hashcash is one of the few citations in the Satoshi whitepaper. When did you hear about that document and what was your reaction to being cited in there?
adam3us: I think it was in August 2008 or something like that. It might have been the first email that Satoshi sent to someone. I thought it was interesting and I cited for him some work by Wei Dai (b-money) which was an earlier idea using proof-of-work to make a reusable currency. It dated back from 1998 shortly after hashcash. Nick Szabo’s similar idea Bitgold was around from the same time. Both of those things were rough designs without specific blueprints or specifications, and no implementation. I think that Satoshi contacted Wei Dai and that’s how the b-money reference got into the whitepaper. There were previous electronic cash systems dating back to mid 1995. DigiCash had a strong privacy-centric electronic cash using blind signatures by David Chaum. It was pretty interesting. People were excited about it at that time. It was very centralized and it got shutdown simply by the company going out of business. I think people took that as a lesson, that decentralization is important for survivability. DigiCash was much more private than bitcoin as such, but not decentralized. I think the lesson was that it’s better to have something deployed as a first step and could survive. The design by Hal Finney and Wei Dai… sorry, I mean Nick Szabo and Wei Dai…. Hal Finney provided a design later. DigiCash had a go at deploying a beta server and they promised they would not issue more than 1 million currency units called beta-bucks. People on the cypherpunk list had a go at bootstrapping value. They figured maybe they could use the promise of the company to not issue more than that, and let’s sell some t-shirts or something and see if we could bootstrap some value. Unfortunately the company went bankrupt and if you had any coins then they would be impossible to verify without the server. The architecture is such that the company has a database of double spends and you require access to that to verify your money. Bitcoin, bitgold and others get around that by requiring a peer-to-peer (p2p) network to broadcast the double spend database, effectively.
stark: What led you to pursue bitcoin full-time? You’ve been involved in these communities, you have a PhD, you were working on other aspects of applied crypto. What brought you to bitcoin?
adam3us: People were working on trying to bootstrap and deploy an electronic cash system that was survivable, p2p, and robust. Of all the cypherpunk tech like remailers, tor and things like tor that came before it, one of the gaps was an electronic cash system for paying for these services. People figured tor would be more robust if you could pay for the channel capacity. Tor nodes are run by volunteers. People were viewing electronic cash as the holy grail of cypherpunk technology. When it got deployed and it started to have a market price and show that it could hold a stable value, myself, and everybody else, thought this was interesting. If you think about it, that something as simple as social media platforms like blogging and facebook and twitter and these things are credited with having an impact for allowing some parts of the world to have revolutions and regain control of their country for free society. If just a blogging platform can have a meaningful effect, then a free global internet money, it’s early days now, but in the next 10, 15 years, it would be interesting to see what a free internet money would have in terms of effects.
stark: The theme of this conference is a focus on security. What are the biggest security threats to the bitcoin protocol today?
adam3us: Apart from the technical security threats, bitcoin is great and the finality is great, but it depends on computer security which hasn’t been in a great state of affairs with different operating systems not putting great focus on security. I think we have good solutions with carefully reviewed code, hardware wallets that we heard about yesterday at this conference. I think that’s interesting. There’s still gaps on authentication or the address substitution problem, but that could be addressed with end-to-end authentication. There are some question marks about the social dynamic of blockchains. I think it’s important for security for people to run their own full nodes and verify the transaction set.
stark: Who here runs a full node? Show of hands. Nice.
adam3us: That’s part of the interest with the Blockstream satellite product. It’s a network of satelites that we’re leasing bandwidth on commercial satellites with the idea that the cost of running a full node can be made a lot lower with maybe $100 equipment then you could have free download of bitcoin blockchain and transactions in real-time. The costs of running a full node can thereofre be made low. Many smartphone wallets like GreenAddress smartphone wallet can be configured to connect to your own full node over tor. So reducing the cost of receiving the blockchain is not just for emerging markets, it allows for people who can’t afford to run a full node due to bandwidth, it’s also useful for people with high speed internet because it’s more private. There are people monitoring on the bitcoin network looking for which IP addresses are broadcasting transactions. This can place you at risk of geolocation, burglary, and other thefts. By using a satellite, it’s completely passive and download-only. The bulk of the data is coming in a passive mode. We don’t know how many people are using it, because we can’t tell. You can send transactions over SMS, tor, or other networks. This leaves a much smaller footprint, it saves you bandwidth, and presents another redundant link to the internet. If you have a network split caused by an undersea cable disruption or there’s a tornado in the southeast US which causes problems to internet connectivity— it’s good for bitcoin security to have a robust network with redundant links and a satellite is a very robust independent link. In phase 1, we have one teleporter uplink. In the second phase by the end of year 2017 we will have a couple more uplinks. The satellites can listen to each other in a ring. If the internet connection on one uplink cuts out, then it can donwload blocks from the neighboring satellites and it can be more robust to local internet failures on the uplinks.
stark: The year is 2017. Satoshi whitepaper came out 9 years and the software came out 8 years ago. What do you think the threats are that we are going to see in the future in 5 or 10 years assuming bitcoin continues on its trajectory?
adam3us: As long as you run your own full node and configure your wallet to point at it, all changes are opt-in. A lot of discussions have been had recently about unusual viewpoints about hashrate defining the protocol. But it doesn’t. The hashrate is a service that follows the economics and it’s the users that provide value to the coins. As long as people are running full nodes, the protocol upgrades can be opt-in. I think scale is optimistic, I think we can adopt new technology going forward. I think the enthusiasm about lightning is interesting for high-scale. There’s also a lot of flexibility and extensibility coming into bitcoin with the script extensions that Eric Lombrozo talked about. I think in the next few years we will see sidechains. The ability to incorporate more sweeping alternative opt-in blockchains that are bitcoin-denominated. You could see tech like SNARKs or zerocash that provide strong privacy or other novel features that might be difficult to incorporate into bitcoin directly because of technology risk to see those deployed into a sidechain that is still bitcoin-denominated. Many of the short-term complicatoins about conflict of interest between miners and users will be resolved because they can, if someone wants to focus on medium-security chains then they could just do that and make a sidechain and set the parameters as they wish and see if it succeeds and draws users in the market.
stark: There’s never a dull moment in bitcoin. There’s been discussion in the community about upgrades and block size. How do you think we can most securely upgrade the bitcoin protocol?
adam3us: I think soft-forks are a safe way to upgrade bitcoin. With hard-forks, it’s opt-in and it’s not clear if everyone will opt-in, thus creating two chains when someone doesn’t opt-in. There are ways to combine soft-forks and hard-forks, called evil forks, which is even more coercive. People didn’t want to talk about it for a while but it’s been public for a while now. It’s basically the idea that, you make a new block… Johnson Lau causes this forcenet on bitcoinhardforkresearch.github.io page.. You make a new block, the original block has a transaction that has a hash referring to the new block. The consensus rule is that the original block has to be empty. The original clients and nodes see no transactions. If miners enforce that consensus rule, then it forces a change. In that circumstance, if a change was made that users didn’t like, then they would just soft-fork it out, they would have to make a change to avoid it.
stark: We’ve seen proposals from the community about ways to upgrade bitcoin. How would you do those differently?
adam3us: It’s important that all parts of the community have a voice. I’m not in favor of segwit2x collusion meeting. Proposals that go beyond proposals that are edicts are not something I’m in favor of. I think the timeframe is also important. If you ask any of the developers, they would typically want to see 18 months or 2 years lead-time on something with as widespread impact on all the software and hardware out there as a hard-fork. For a hard-fork, basically every piece of software and equipment needs to upgrade, which requires a lot of lead time. I think replay protection is important. In the bcash proposal, there was mandatory replay protection and the timeframe on that was super rushed. It only got checked in 5 days before their fork date, which is on the extreme end of a short timeframe.
stark: One of the big questions in the community is around fungibility. Can you use the same coin and avoid taint? What is your vision for how we should treat fungibility in bitcoin and what problems are you seeing?
adam3us: Fungibility is an important problem. It’s related to privacy. It can be achieved separately. What provides fungibility in bitcoin today is that mining is decentralized. If miners in one country are ordered by their government to not process some transactions then other miners will process them. If mining gets too centralized then it puts fungibility at risk- if you end up with some coins and maybe some government doesn’t like you, say you’re Wikileaks or you’re a lobbyist or politician, that’s problematic for a currency. You expect that everyone will accept the money no matter who previously had it. Fungibility is important. I think we could have more technology to guarantee fungibility. For someone to block a transaction, they first have to know how made it, in order to block it. The digicash protocol works this way- each payment was unlinkable to previous payments. The people processing each transaction, even though they were centralized, had no information that would allow them to know if they should block it. They had no way to discriminate. What causes problems for bitcoin is the linkability between transactions and change UTXOs. There are some protocols in flight like lightning which has improved fungibility inside the network. There’s also tumblebit, zerolink and confidential transactions is also interesting. There’s some space overhead problems on that one. Confidential transactions interacts well with coinjoin, and you can join coins without having to worry about the specific amounts making it obvious which inputs correspond to which outputs, because confidential transactions hides the values. You can still validate the blockchain but the values are hidden using a form of homomorphic encryption. The inputs and outputs can add up without revealing the values themselves.
stark: What are the protocol-related technologies that you are most excited about coming down the road?
adam3us: For the short term it would be great if companies could integrate lightning into their wallets and exchanges and merchants. It solves some usability problems by providing instant confirmations. Also it improves fungibility and privacy. It should be cheaper too because it provides a lot more scale. If lightning provides a high degree of recirculation in the network then that should be equivalent to a much larger block size in terms of throughput or scale which is otherwise implausible. If we put everything on to the blockchain then it would eventually saturate the internet basically. It’s a broadcast mechanism. You have n^2 scaling problems. If we could get 1000x recirculation within lightning then that’s great but with segwit and around 2 megabytes if you were to have 2 gigabyte blocks to match that on chain then that’s not plausible and you would only able to do the validation computations in a data center. If you can’t see the transactions and verify themselves due to scale mistakes, then that’s not far from today’s world where you are trusting a bank that they had an auditor to check their internal ledgers.
stark: What are the upgrades you would like to see most to the bitcoin chain?
adam3us: It would be interesting to see some more opcodes reintroduced. Script extensability. The merkle tree proposals are interesting because they provide more privacy, like the MAST proposals. It allows you to have a syntax tree represented in the blockchain where the normal case is just a simple transaction but then there are some hidden extra clauses that can get exercised. If the exceptional situation happens then you reveal the more complex program. If the transaction is multisig then basically as long as both parties agree, then the full contract never needs to get revealed, and that saves space on the blockchain, and it’s more privat ebecause transactions are indistinguishable unless their clauses are exercised.
stark: Okay, let’s open it up to audience questions. Thanks.