http://lightning.network/

slides: https://lightning.network/lightning-network-presentation-sfbitcoinsocial-2015-05-26.pdf

Great to have you guys. They are going to talk about bitcoin's scalability problems. There they are.

Okay, hi. So yeah, I titled it solutions because that sounds more positive than talking about problems. Joseph will go after that and talk about what needs to change and the economics and things like that. Okay, so I'll start.

Bitcoin scalability. The thing that is on everyone's mind is line 10 of consensus.h which is static constant unsigned integer max blocksize is 1 million bytes. That's been in there for a number of years and hasn't budged. That's the current thing that people are focusing on. The discussion quickly becomes larger about scalabity. If each nodes create transactions and every transaction is stored by every node, that looks like a whole lot of n squared and that's not very scalable.

So this is the problem. How do we get everyone to use bitcoin? How do we get lots of transactions? There are different solutions.

There's the SQL database model which is very scalable and very fast. You can implement many transactions per day. There's altcoins, and there's many blockchains with atomic swap; you could have larger blocks, and then there's payment channels which is many payments between predetermined parties.

The SQL database model is very fast, and it's the most widely used off-chain implementation. Users give transactions to the database, then users can query and transfer funds. Nothing happens on the blockchain. People just ask for their money back. It can support millions of transactons per second. It looks a lot like delivering bars of gold to the Fed in NY. You don't have your bitcoin, there's things like counterparty risk. It's very likely to happen if no other solutions come up. It's already very popular. People use this often already. Like changetip. No matter what happens, there will be some of this in the future. And it's okay. But you don't want to be reliant on it, because then you're sort of back where you started with trusted entities handling money.

So altcoins; you could sell bitcoin and buy neatocoin, and it might have hydroflex negative block times or something which are impossible. And then later you can buy bitcoin when you're done. This is maybe a solution. The problem is that the altcoin exchange is just the SQL model. The altcoin exchange is just a centralized database.

Atomic cross-chain transactions between cryptocurrencies could work, but I've never seen any exchange using that. It's kind of a cool technology but I don't know if any altcoins are using it.

So if neatocoin really works or not, a lot of cryptocurrencies don't have the security of bitcoin, if it does work and it's scalable, then why not use neatocoin? If sometihng presents better scalability and security than bitcoin, then gee maybe that's going to take over? It's not really a good solution for bitcoin because it's not bitcoin. That's pushing the problem somewhere else.

Larger blocks is another solution. Computers are great. Even if it's 100 MB per block, that's 5 terabytes per year, and 5 TB hard drives are under a bitcoin right now. If you're getting 100 meg blocks every 10 minutes, 5 TB hard drives will be under 1 BTC because there will be more users using it, so therefore the scarcity will probably cause the market price to be higher. I run a full node on a 2005 or 2006 era laptop I found in the garbage. Version 0.11 is going to have pruning and it will go down to 1 gig or something. There's a lot of reasons to say that one meg is really small; from a technical standpoint you could probably do more; if you look at the computer science angle, n squared is not that bad really. If the total network cost is something on the lines of n squared, then for each user it is still O(n) and if the value of the network is Metcalfe's law, then the cost is roughly proportional to the value. This is all very handwavy. There are some problems with bigger blocks. If you switch to 20 megabyte blocks, you only get 20 transactions/second or something. You need much larger blocks... if your fridge wants you to go pick up some eggs, for all those internet of things stuff, that's going to be a lot of transactions. Larger blocks could help, it's necessary but not sufficient.

So what I will talk about for a few minutes is payment channels. These are transactions that can be delayed and aggregated before going into the blockchain. Now you just need a transaction on the blockchain to get a channel open. It's opt-in, you can do a lot of transactions, instant confirmations, and you can scale it to a lot of users.

Okay, so this is sort of the tech part. I don't know how many people have heard of the regular payment channels. I think bitcoinj started this? I don't know where these ideas started. This part is not new. The basic idea is that Alice wants to pay Bob but she doesn't know how much yet, so she says she will pay him up to a maximum of 1 BTC and she will open a channel. She first gets a refund signed by Bob, but it's not valid yet, it's using nlocktime and it's valid tomorrow. After she gets a refund, she can now fund the channel, and it's just a simple 2-of-2 multisig where both Alice and Bob must sign. Since Alice has Bob's signature, Alice can just sign it herself and retrieve the funds.

Worst case scenario, even if Bob disappears, Alice just has to wait to get the funds. She can sign a transaction that is valid right now and where she gives Bob 0.1 BTC and the rest back to herself. She can send Bob that signature maybe through email or some chat window or some other network. Now Bob has that signature. Bob can also sign that transaction and broadcast it to the blockchain. But he doesn't. Bob waits. What's next about this is that Alice by sending Bob this 80 byte signature, that's essentially a payment. That's really fast. Alice then says since Bob hasn't broadcast, I'll pay 0.2 and then send the rest to me. So Bob can forget about the previous transaction- because it's clearly worse- so he only keeps the ones that are the most beneficial to him. Alice can keep doing this in positive increments. Eventually if the channel wipes out and it's all going to Bob, then Bob will probably immediately broadcast that.

Okay I can slow down. There's some problems with this. It's unidirectional. Bob's can't push funds back to Alice. Instead of this being no locktime, you make this tomorrow at lunchtime instead of tomorrow night. So Bob can only broadcast this tomorrow after lunch, and the refund happens at night, so Bob can still get the money. Then if Bob wants to send the money back to Alice, he creates a new transaction with an even earlier locktime to send the money to Alice. He might send a locktime that is closer to the present than what he has. So Alice knows that if she broadcasts before Bob does, she gets more money. So you can switch the direction of channel by bringing it closer to the present, which you don't want to do often because you will run out of time eventually. So for one-to-one... oh the other thing that could happen is that instead of just Alice funding the channel, both Alice and Bob could put 1 BTC in the channel. Perhaps they only know that they will do payments to each other but they don't know who will pay the other.

This breaks because malleability. When you have two signatures funding this transaction, it's easy for someone to resign. You can sign the same message twice and get a different signature. Unfortunately this breaks this refund transaction, because a refund has to refer to a specific set of signatures. So that's sort of an issue.

But basically this works now. I think there's streamium or something that is using this. It works today. It's pretty cool.

Scalability wise, it helps if you are doing microtransactions with one party. But what if you want to do a 3-party optimistic iterative payment channel? Say there's Bob, Alice and Carol. Alice wants to pay Carol without touching the bitcoin blockchain. The obvious easy way to do is that Alice would say to Bob I am going to give you 0.1 BTC and please give it to Carol. Alice would ask Carol whether she got it. Bob gets 0.2 BTC and then it goes to Carol, etc. etc. You just keep giving Bob a little bit, and then Bob keeps giving Carol a little bit. The worst that Bob could do is keep the 0.1 and this is a problem because if he keeps it, and sends it off, and Carol could just claim she never got it. There's no real way to prove it. With only 2 parties it's obvious that Bob kept your money, but what happens when there are many intermedaries? It may not be clear who is breaking the transaction. In general this is not that great because of all the trust requirements...

Alice wants to pay Dave without opening a new channel. This is the lightning network concept. A simplification at least. Dave comes up with a random number R and hashes it using sha256 and gets H so H is the hash of R. And R is secret. Dave gives Alice the value of H. So Alice says to Bob that she will pay him a BTC if he knows the preimage of H. So if you know R, I will give you a bitcoin. So Bob forwards this request to Carol. You can do this in a script in Bitcoin today. If you can sign and you know the preimage for this random number, you can spend, otherwise you can't spend. Carol forwards this to Dave and says I will give you a bitcoin if you know the preimage of H, and Dave came up with R so he does know that. So he has to show R and reveal it if he wants to get the transaction. If you put this on the blockchain, everyone knows R and all the payments go through- Alice to Bob, Bob to Carol, Carol to Dave, they are all valid. Dave can never take money from Carol without the other two transactions being valid. So that's a nice model where Alice doesn't have to trust Bob or Carol and you can have many intermediate nodes without worrying about one of them grabbing the money. The only issues with this scheme are timing issues. You can keep these channels open, you can push payments to other users, and you don't have to touch the blockchain until you want to close the channel.

It doesn't seem that scalable because you have to come up with new transactions each time. There's a way to clear out those transactions later, but it's more complicated. The worst that happens is that your transaction doesn't go through, you don't lose any money. Then you can clear it out. Lots of payment to anyone in the network. You don't have to make new channels, for as long as there's a path between any two users, it's sort of like the internet with the network packet routing.

So I am going to be talking more now about the lightning network. Its sort of philosophy behind it and the risks. And also its applications. If you see that everything is going ot be run in a network of payment channels, what gets broadcast into the bitcoin blockchain becomes a programatically adjudicated court system. If 99.9% of all contracts you write, you don't ever go to court. It's not really enforced by any sort of system. Everyone agrees to cooperate. However if you do disagree, you do have a fallback. The blockchain is going to be this fallback. With the lightning network, you are creating real bitcoin blockchain transactions that can be interpreeted by the blockchain, just like in contracting that you are writing contracts that can be interpreted by a judge. Disagreement usually doesn't happen. You are creating transactions that are real bitcoin transactions but it doesn't ever hit the blockchain except for disagreements. But how does this work?

I think it's very important to review any development in bitcoin as a replay of the history of money. Bitcoin is functionally this base currency and using this we're sort of you know we're at 2000 B.C. that's sort of where we're at right now. But I think it's sort of a waste of time to repeat history. It's ideal to learn from the mistakes of history and learn from the ways that systems operate today. Often there's a reason. The way that the lightning network works is that it uses time as a function of atomicity and in the real financial markets today, we have systems like T+3 which is for equities. When you for example sell a stock, it must be completed within 3 days. It's a hard limit. Your clearing, your broker, ultimately settlement and delivery. There are organizations like DTCC which handle huge portions of all equities; or corresponding banking where people have different responsibilities at different time. Over-night is a huge part of the financial network. In the lightning network, you use time commitments between hops, which are enforceable on the blockchain. It's all programmatically interpreted which is a huge benefit. With T+3 the enforcement is "you do this or you get fined" which is not so good. It's a lot cleaner that everything is enforced; you can have locktime in bitcoin which can have significant clarity in the processing of financial transactions. That's sort of how lightning makes things effectively trustless.

However, there are some considerations that you need to look into. Isolated attacks on to something like lightning doesn't work because if you decide to violate the terms inside your channel, it can be interpreted on the blockchain in such a way where you can penalize the other party and take all their money. The other party can say that the other one is being a jerk and prove it, and then take their money back. Systemic attacks are theoretically possible with the lightning network. They are unlikely, but it requires a supervillain with like 1 million BTC and simultaneously try to flood the network and they pay very high miner fees and they need cooperation from malicious miners to interpret child-pays-for-parent, it may not be malicious miner I guess, it depends on your definition. In any case, it sort of requires a lot of money to attack and it's very unlikely, but there are ways to mitigate this depending on how you construct it.

You can mitigate it by having a soft-cap block size structure. Let's say blocks are as big as you want. Miners are probably not going to mine unlimited blocks. Blocks are going to be full most of the time because if you allow unlimited block sizes, transaction fees are going to go to zero, and miners are probably not happy about that. No matter what you set the cap to in bitcoin, miners are probably going to set a lower limit. You ideally want a dynamic bitcoin max block size adjustment algorithm. The benefit of full blocks is that you have this fee market and miners can be compensated long-term for their work.

The chances of that happening are sort of low if there's a soft-cap block size limit. I am not saying 20 megabyte blocks tomorrow. Could probably be done with a sidechain structure or something.

The economic implications for something like lightning have some interesting effects. There will be a lot of coins locked up in channels. They aren't gone. They are just a balance. It's not like these coins are gone, it's just that they are being associated with those commitments. They are available to spend almost immediately, I can spend that 0.1 BTC and spend it somewhere else. The intermediaries both have funds associated with the people they have a channel open with as well. The net effect of this is that the funds available may reduce the money supply a little bit, and the effect of that may increase the market price. It's not 100% correlation but there might be some side-effect.

I do think there will be some fee market inside lightning network. The fee market there will be different from the bitcoin blockchain fee market. It's not going to be per-payment in the lightning network but per channel. The fees could be positive or negative. There are situations where Alice has a relationship with Bob and Bob has a relationship with Carol and Carol has one with Dave. If Bob and Carol do a lot of traffic, there might be an incentive to send the money the other way. There might be a situation where Dave might want to send money; if Dave has a relationship with both Bob and Carol, then maybe Dave could offer some funds to go in the other direction.

Alice, Bob, Carol, Dave. Let's say Dave is sending a lot of money in Alice's direction. Erin can move money between Bob and Dave so that more channels are available. Maybe Erin is just someone with a smartphone. Erin has the same amount of money after this. This is a trustless scheme.

Speculative economic implications are as follows. The economic incentives for the network are that; liquidity is going to exist because of the fee market. There's economic incentive to keep channels open. I think routing will be a lot easier. Let's say I have channels open with 5 different people. Well, you know, if someone wants to move money in one direction or the other direction, I can just net things out, I don't care what my balance is between parties. Channel liquidity might be slightly more constrained. There might be some kind of fee if you are receiving a lot of money. I think ultimately the fees are going to be very very low. The way that it will be reflected in the long-term is probably higher exchange rates to accomodate available channel liquidity. If you expect to receive a lot of money, someone needs to open a channel with you. If you don't have any money locked up, and the other person does, they are locking up their own funds without guarantees that money will be sent to you, so you will probably have to pay a fee for that. But if you bitcoins laying around, you're basically making money. Say you have 0.1 BTC that you are not going to use soon, and someone else wants to receive 0.1 BTC in the future, you can setup a channel with a fee. You don't need to trust this other person, they could be a jerk or whatever, it has no risk and you make some small fee doing this too.

I think there's a lot of interesting applications for something like this. The promise of bitcoin was micropayments, but right now micropayments are functionally impossible. Changetip is cool but I think that for the long-term we need micropayments to scale out to a penny or subpenny. I'd like to see pay-per-article in the newspaper industry. Let's say that I read an article and then I pay 2 cents or something, and hte ads get turned off, and it's low enough that you don't really care but in aggregate you know it will help.

You could do automated payments to every website you visit; you could have something in your mp3 player where you pay 1 penny per play or something. You could do micropayments for bandwidth. If you have sufficient wifi everywhere, perhaps if you paid some small amount, I think that many people would open up their wireless access points.

Instant payments are important; paying for something with bitcoin at the moment does involve some trust, accepting zero-confirmations and you kind of want the confidence that if someone sends you an unconfirmed transaction that it will go through. Right now there's no guarantee. You could do instant payments between exchanges or merchants with the lightning network. Right now ultimately the lightning netwokr needs some changes to the bitcoin network, like a fix for malleability in some form. That's critical and lightning network cannot exist without that fix.

It would be nice to have some relative maturity system also known as OP_RELATIVECHECKLOCKTIMEVERIFY. Ideally to protect against supervillains you need to account for something like 10x bursts of block sizes. I don't think that will actually occur, I think you just need the threat that this can compensate for that, if a supervillain sees that they will lose all of their money if they try to attack the lightning network, they will probably not bother.

Also this will require a network communication layer for the lightning network. It's definitely possible and I think long-term for bitcoin to truly scale, we need to put things off-chain. It doesn't make sense that everyone knows you bought a cup of coffee on the blockchain. That's way too many transactions to handle.

So the problem with malleability is that... when you're spending with bitcoin, you're referencing your input txid which is a hash of your input transaction output. This actually breaks if both Alice and Bob are both funding a channel. Your refund has to be created before you fund the channel, otherwise you can both put a coin in, and then there's no refund. So now it's a hostage situation. You both have to sign to take those coins out, and now Bob says alright how much is it worth to you, I will give you 0.9 BTC back, but Alice would say I put in whatever amount more... so Bob does a time-value of money attack; I will sign 100 transactions and they are all timelocked, and for the one that is timelocked today she gets 0.1 BTC, and if she waits a year she gets back 1 BTC or something. So if you want to wait you get back all your money, but if you want it now, Bob gets to steal some. The problem that makes this hard to mitigate is that the way that ECDSA works is that you can't fix the malleability problem by constraining the script. When you are doing ECDSA you get a random number k and that leads to the R part of your signature and it's alwas different. Bob can sign the same transaction twice and come up with a different signature and that will change the txid and if the channel transaction changes then the refund transaction is wrong and invalidated, because Bob resigned and now the txid is something different. So Alice has a refund but it's not the right one or valid anymore, it's useless and the coins are stuck. It gets even more problematic with multi-hop network channel stuff. All of the transactions in payment channels are based on txids; the easiest way to do this is to have a new sighash type that doesn't reference txids that just references the txin script and maybe the amount, and gmaxwell says it might be dangerous if you don't reference the amount or something. So normalized txid, or no txid at all? But basically most contracts break especially this stuff if you don't have a way to reliably spend transactions that are not yet on the blockchain.

Functionally if you want to make this channel bi-directional you need to be able to build the terms of this payment before it is funded on the blockchain. So the situation we have right now in bitcoin is that you sort of pay the other party, if you want to pay someone else to build a contract, you need to pay them first before you agree to the contract... It's like agreeing to a loan where you have to pay them first and then write the contract later. That's not good. So fixing malleability will fix this.

Ah the question is timeline. I don't know. It seems sort of not that tricky when you think about it. The problem is that it gets in with, where if we're going to have a new sighash type, then maybe we should also switch to Schnorr signatures and you could do threshold signatures for 100-of-100 etc. And then people propose one big update or something... the politics involved in actually changing bitcoin source code, there's no algorithmic consensus for the humans writing the software (yet). So it might take a while. Hopefully within the next year. Maybe version 0.13 of bitcoin core?

Some of the normalized txid schemes only work for one hop. Personally I think that having no txid is the easiest solution. You can shoot yourself in the foot if you have two spends to the same address in different amounts, you might try to spend the smaller amount, and then someone probably the miner would switch it to the larger amount and would keep the fee or something. If you're going to be using the exotic sighash types, you should know what you're doing. SIGHASH_NONE is another example of a way to shoot yourself in the foot already.

If a node drops out it doesn't matter if it's hostile or non-hostile. If the node drops out effectively you have the relative maturity of the relative checklocktimeverify, your funds might be locked up for 2 or 3 weeks depending on what you set it to. That doesn't mean you can't spend your money, you probably have channels open already. You probably wont even notice. What will hpapen is that after a certain period of time, your client will auto-broadcast a certain transaction. Or perhaps your client doesn't need to be online, perhaps you push the transaction to the network on your own. Functionally if you're using the system correctly, it shouldn't effect you at all and the other party cannot steal your money. The worst case scenario is that the money in that channel is inaccessible for the duration of the remaining timelock. So you might have no access to the money for a week or two. So you do sort of trust the central nodes in that sense, but their main reputation is their uptime. That's their only real metric of service. Because you're not trusting them for your money, so they can't compete with each other on trust.

So why setup the locktime to be weeks? The reason is because that number, let's say the relative maturity stuff, functionally that's the minimum amount of time that you can .. the blockchain every so often that the other party is not acting maliciously. It's like checking your mail. It's your settlement time. So if you open a 2-day channel and you go away for a long weekend without your phone, you might lose money if the other party is a jerk. You might lose some money, that send that someone sent you might be canceled. You don't need to watch it; you could give the penalty spends to someone else and those people could be completely untrusted because they can't broadcast them unless the other parties are a jerk. So if your counteparty is a jerk, then 100 other people are fighting to give your counterparty's money back to you. The more trust there is, the more efficient it is and the longer the timescales can be. So when we say a week or two-week we're just making up numbers, but they seem like reasonable timeframes or timescales. The fewer transactions you make, if bitcoin transaction fees are higher, then you might want a 2 month long channel or something.

Do double spends become a problem with malleability fixes? Almost everything in these payment channels are multisig. So to double spend, both parties need to cooperate. They can both conspire to double spend. The presumption is that you have many channels open. If something like Lightning exists, I can require an insane number of confirmations and it doesn't matter because everything is inside the channel.