Alex Bosworth
London Bitcoin Devs
Submarine Swaps and Loop
Video: https://www.youtube.com/watch?v=eB_HkYb7Y2M
Slides: https://www.dropbox.com/s/cyh97jv81hrz8tf/alex-bosworth-submarine-swaps-loop.pdf?dl=0
https://twitter.com/kanzure/status/1151158631527849985
Intro
Thanks for inviting me. I’m going to talk about submarine swaps and Lightning Loop which is something that I work on at Lightning Labs.
Bitcoin - One Currency, Multiple Settlement Networks
Something that is pretty important to understand about Lightning is that it is a flow network so once you set up your channels and you’re in a network of channels with other people, the balances can only shift along flow properties of the network. If I spend my channel entirely down then I can no longer send to somebody else. Also if I spend my channel down in one direction, even if I have balance in another direction I can’t use it to apply to the other direction. This is super different from the UTXO model that the blockchain uses. The blockchain uses a broadcast system. In Lightning we get these great scaling characteristics because of this flow model that only the people involved with the payment or in the middle of the payment need to really know about it. That scales great. You can load up tonnes and tonnes of people and as long you’re just bothering your section of the network you’re not impacting anybody else. But with the UTXO model that the blockchain uses you’re bothering everybody in the world but you are also getting this great property that you can send to anybody in the world. You don’t need any flow with them. Even though we have this one concept Bitcoin we actually have multiple different networks where settlement can happen. Each have pros and cons.
Submarine Swap - Witness Program
A submarine swap is something that I thought about a while ago as a way to deal with these pros and cons. What happens if I’ve got some funds on the chain and I want to do stuff that the chain can do but I also want to interact with the Lightning Network? Or what happens if I’m on the Lightning Network but those flow limitations are really getting to me? I need to escape that. In case I want to use the advantages of the chain. In order to make that work I just deconstructed what a HTLC is, the HTLC is the building block of the Lightning Network itself. In a HTLC, this is the classic version of the HTLC, you have two locking conditions. You have the locking condition which is the hash and you have the locking condition which is time. Those are the H and T in HTLC. If you are familiar with Bitcoin script these are Bitcoin opcodes and a rough representation of how the script executes. What the first line is saying is… I should fix this. The first line is saying “If I see a preimage, the secret part of a hash, then I’m going to go to condition 1. If this hash doesn’t match then I’m going to go to condition 2.” What condition 1 says is “If that preimage, that secret value, matches that hash then Alice can controls these funds. Otherwise we’re going to do a check on the time. We’re going to do a check on the locktime of the transaction to see if it is at the current height where it should be. Even though the hash is incorrect Bob will get control over those funds.” This is a stack based language. What is really happening is that the pubkey is getting pushed onto the stack and we’re following these conditions. The final code is to check the signature. Whoever provides the signature and also passes these first checks will be able to send the funds around.
Submarine Swap - Execution Flow
Some things that are not super intuitive about HTLCs are how do they execute? Here is the execution flow of how this actually goes. In the successful case the secret is revealed and Alice’s signature is presented. One thing to notice is that the success case is the entirety of the time. It is not an OR situation. You can see that there is some delay for the timeout to start executing but even during the timeout period both sides share control of the funds. One thing to bear in mind if you are deploying this type of contract, if you are using Lightning Network you are using this contract already, is that the fee market can play a role in this. What happens if you want to execute the success case and you think “I have a lot of time before the timeout is going to start executing” and you put in your transaction for the success case well before the timeout. But you put in your transaction at a very low fee rate. Maybe there’s a fee spike. What we have is a race. If you are not attentive to that fee, if you’re not bumping that fee somehow then you can get into the danger zone which is the timeout zone and the other party can start to take control. But, especially on the Lightning Network, once you reveal the preimage which is secret information, people along the route can start taking those funds. You need to be pretty careful. Even though a submarine swap is designed to be minimal trust, you need to execute it properly. You need to give yourself plenty of time and you need to consider that in the case of a fee rise you’re going to need to bump it up.
Q - What’s plenty of time?
A - That’s something that is pretty interesting to think about especially if you are doing submarine swaps across different networks. You have time that is running at one speed on one network, and time running at a different speed on another because these are in blocks. It really depends on how you define the contract. You could define the contract to give yourself a huge amount of time but then if things go wrong you’re also going to have to wait a huge amount of time to do the refund part. So it’s really something that needs to be part of an overall solution for yourself.
Submarine Swap - Variations in the Wild
Since I came out with submarine swaps, I made submarineswaps.org and I published some information on the idea, some people have started to adapt it for their own use cases. I saw Moon wallet and Breez wallet have adapted it into their wallets. Lightning Labs were working on including it into the Lightning App that we’re working on. One cool thing about submarine swaps is that they’re very adaptable because they are very simplistic. There’s just those two clauses. You don’t have to fit within the Lightning structures of how contracts should be developed. One thing that I changed in my own script is I added this HASH160. That allows you to create your private keys in Bitcoin Core or wallet that’s friendly to Bitcoin Core. Bitcoin Core has a dump private key that makes it really easy if you’re using some other software and you want to have the standard flow of private keys you’ll be able to dump them out. Bitcoin Core doesn’t otherwise have a way to get at your private keys. The HASH160 can make it friendly towards the keys that Bitcoin Core knows about. Size is also something to think about. I showed you that contract before but there’s a potential vulnerability that you need to think about which is what happens to that secret, even though it matches up to a hash that I expect, if it some crazy huge secret value and I didn’t expect it to be that size. In some cases you don’t need this OP_SIZE, in my implementation I omitted it because it is checked already on the Lightning side. When I make a Lightning payment out, all normal Lightning HTLCs already include this OP_SIZE check. In certain cases, in Lightning Labs we have an implementation of submarine swaps that was created by Joost and it goes in the other direction. It goes in both directions now, it started in the other direction from my implementation. In that case OP_SIZE became more of a safety precaution to make sure that the secret that’s being exchanged is of a consistent size that we expect. OP_CSV is something that I’ve seen people use. I’m not sure which one of the wallets included it. I’m not sure why you would use this. CLTV is used pretty consistently for HTLCs in Lightning because it makes it easy to reason about, when are things going to be finished. They give you pressure to go to the chain and actually execute the contract. CSV becomes like a CLTV as soon as it hits the chain. Hopefully these swaps are going to the chain. Another interesting thing that I haven’t seen used in the wild but I think could be used, is that you can set up the refund path of the submarine swap to go to a somewhat conventional but less conventional wallet which is controlled by multiple keys. If you have a 2-of-3 wallet you could actually do a swap to pay to a Lightning payment request and you could do it in a way where if the swap doesn’t go correctly it refunds back to the 2-of-3 controlling setup that you were already spending from. Submarine swaps can be compatible with a wide variety of wallets.
Submarine Swaps - Swap in use cases
When I first started working on submarine swaps I was actually thinking about it in the context of altcoin swaps. Altcoins were super hot and I was thinking the demand is really in altcoins. There were some interesting use cases though for Bitcoin-Bitcoin. The other thing I was thinking about was that we have that flow problem and we have the potential solution which is to use a non-flow network like a UTXO network. I was thinking what if we used an altcoin’s UTXO network for this purpose. Either a sidechain, we could fix balance problems with a sidechain. Or potentially we could go to a different chain and if the chain fees were too high they would override the problems of switching between currencies. Maybe I have a switching cost of 1% to go to Litecoin but the chain fees on Litecoin are so good I’m fine to switch over and switch back as long as it makes sense from a cost perspective. At the moment with Lightning Loop we only support one currency and that’s Bitcoin. There’s already tonnes of use cases that make it very compelling for us to include it in Lightning in our app. We have this nomenclature about swaps in terms of directionality where we say it is an in-swap if it is going into the Lightning Network and it is an out-swap if it is going out of the Lightning Network. In-swap is what I originally made and the idea is what if I’ve run down the liquidity in my wallet. I’ve been on a spending spree and I’ve bought so much stuff that now I need to go to the exchange and fill up my wallet again with money. There’s two possible ways you can go about this. One way is you can add a new channel actually. You can just put funds on your regular wallet and this is how you can do it on the existing Lightning App wallets and lots of Lightning wallets. You’ll make a new channel. The problem with making a new channel is you’re increasing the burden on your channel partner. What’s the situation from your peer’s perspective? You are spending down your channel especially if you’re on your phone. You’re spending down your channel. Then you’re making a new channel. Spend down that new channel, make a new channel. From your peer’s perspective more and more of their funds are getting locked up with you. It is possible that you’re paying enough in routing fees that it is worth it to them. They have enough money that they can just provide for that liquidity. But if you use a submarine swap you can reuse the same existing channel and instead of changing how much capital needs to be devoted to this relationship you just reset the scenario through the swap provider so that the person’s channel is full again and they can spend again maybe for months and months. If we look at the metrics on the Lightning Network the average channel is already averaging months of use. We could easily see a full year of use. Hopefully we can make channels as long lasting as possible. In order to get savings we want to aggregate as many transactions as possible into one channel. Another way you can use submarine swaps that I think is pretty cool and was something I was thinking about when I first did Bitcoin to Bitcoin swaps and submarineswaps.org is you can take your cold wallet or your non-Lightning wallet and you can buy those cool things that are available on Lightning. Maybe there’s some fun game that you want to play and you’re not really interested in Lightning spending all the time, you can take your normal Trezor and you can spend to a normal address, a normal pay-to-script-hash address. It is a non-custodial operation. You still have this refund scenario. Then you go to stores that accept Lightning and you can pay them. That could even work with something like Bitrefill. Bitrefill will give you a 2% discount if you pay with Lightning. If you had a swap provider who charged you 1% and the chain fees were low for maybe a large purchase, it could actually be advantageous for you to make this kind of swap.
Submarine Swaps - Swap out use cases
I actually think maybe I made a mistake when I was working on submarine swaps because it turned out the bigger use case for swaps is the other way. I have Lightning funds and I want to get them out, I want to get them out of my channel. The biggest reason that people want to get their funds out of their channel is because of a capital problem that we have in Lightning. The capital problem is there is a limited amount of Bitcoin. In order for you to receive funds somebody needs to commit their Bitcoins in your direction. They could select anybody in the network to commit their funds in their direction. They only have a limited amount of Bitcoin. There’s another situation where funds can get locked to you other than somebody creating a channel in your direction. Lightning Network is currently in a unidirectional state. When you create a channel with somebody all the funds start on your side. The reason for that is the capital economic reason. There’s multiple reasons but that is one of the major reasons. You wouldn’t want to allow other people to take your capital and commit it wherever. Even if they put up some capital themselves it is still risky because there’s people out there with huge amounts of capital and you don’t know what their intentions are. This is a way where you can say instead of having somebody initiate a channel with me I spend down my channel. Because channels are bidirectional all the money that I spend down out of my channel I’ll be able to receive back. What I thought would happen is that exchanges would start accepting Lightning and then if you wanted to receive some inbound liquidity it would be simple. All you’d have to do is go to the exchange, deposit a bunch of your funds on the exchange with Lightning and then you’re golden. You can receive money. But at the state that we’re at right now with the Lightning Network there’s not that exchange that you can deposit your funds on. Even more, people who are offering Lightning accounts and also allowing you to withdraw your coins back to yourself, they’re starting to notice that this is something that could potentially be used. There might be limits of how much you can do of that. With a submarine swap, the way it can execute is you can choose any node in the network, you can create a channel to them, the funds will start on your side but as long as you can pay through them towards the swap provider you can empty that channel out. Even better than putting it on an exchange you can lock it into that contract, the HTLC contract, so that the funds return back to you onchain. Because the funds are returning to you onchain it escapes the flow problems.
Q - Is there any way to batch the onchain transactions in a swap?
A - I’ll definitely get to that.
That handles that super common use case, the receive money use case. People want that for all sorts of reasons. Another reason that you might want to do this is you might want to make a regular payment to a store or an exchange that doesn’t support Lightning. The reverse case of I want to buy something from a Lightning vendor. I have my funds in Lightning and I want to buy something from a vendor who doesn’t accept Lightning. The merchant also has a distinct use case where they don’t want their hot wallet to limitlessly expand. Normally what is happening with a merchant is people are paying, paying, paying and Lightning wallets are hot wallets so they are getting more and more funds on their side of the channel. Throughout the day, maybe the throughout the month they’re growing the exposure of their hot wallet. What they can do is use a swap provider to push out those funds. They spend down their channels and they can push out the funds to a cold address. They can push back out to like a Trezor. There are a lot of savings that they can still get from that because what they’re doing is aggregating their transactions. They’re aggregating many transactions throughout the day, throughout the month. It is going back to maybe an exchange, they’re selling it or maybe they’re holding it for some reason.
Q - So when you say it could get abused. What types of abuse are possible? You said that if you offer this service as an exchange….
A - Let’s say you’re an exchange and you offer the ability to deposit with Lightning offchain but then withdraw onchain with onchain funds. The issue is you yourself as an exchange have limited amounts of inbound liquidity so the more people send to you the lower your inbound liquidity goes. When they take it out onchain that inbound liquidity doesn’t go up. It would be one thing if you paid them back offchain. In that case the flow would be reversed. Because they are escaping the flow, they’re going onchain, that state of the network is permanent. They’re moving their inbound liquidity. Plus not all inbound liquidity is equal. Maybe your prime inbound liquidity is being used up. It has been a current problem that I’ve heard about.
Q - If there are services offering both Loop In and Loop Out…?
A - This is an exchange. This is why you’d want to use Loop In and Loop Out. Or why you’d want to do a submarine swap because you can address the network more broadly. Of course swaps still have the same concept which is the flow is too one directional. That’s why it is important when you initiate a swap that you connect to the mass of the network and you’re not too isolated. It is also important for the nodes involved to set their fees properly. Let’s say I process ten swaps but now my channel is depleted. I need to make sure that either the traffic is bidirectional so I’m going to get routes in the other direction so the flow resets. Or I have enough money that I’ve made off of routing fees that I can close those channels and reopen new channels because the funds have moved from one side to the other side. I’m going to have a liquidity problem that can’t be solved within the flow network. I have to leave the flow network.
Submarine Swap - Limitations
I was already talking about this problem in terms of routing economics. It is a problem and a solution. One of the nice things about a swap is that you connect to any node. From the perspective of those nodes it just looks like a regular payment. They are just pushing out a regular payment. Instead of buying a channel from somebody who is a channel provider you’re going to anybody in the network. You can pick and choose. You can say “I’m going to go for the guy who has the lowest fees or who is online the most. It seems like his business is being a great node.” Also I’m going to set up my channels in a diverse setup. If that guy goes down it doesn’t matter. I have like five other people who are still up. We also think this is a healthy way that the network can spread out the liquidity so that it is not too brittle. But there are some problems with submarine swaps. One problem is that we are still using up chain space. We want the chain benefits, we’ve got to pay the chain cost. Another problem is that normally things in Lightning are pretty fast but as soon as you get the chain involved everything goes screeching to a halt. It really makes you appreciate the offchain experience. With the offchain experience, you test something and in two seconds it is done. When you go onchain you’re waiting for confirmations, it is awful. Another thing that is not great about submarine swaps in the naive implementation is that from a privacy perspective the chain is not ideal. You are broadcasting values to everybody in the world. You’re broadcasting timing, you’re broadcasting the preimage so people know that secret. That’s not great.
Submarine Swap
Just to get technical about chain cost. Chain cost is one of the biggest disadvantages of submarine swaps. Also not only is it a disadvantage for the user, it is a disadvantage for everybody in the network. The more chain space you use, you’re also driving up fees for everybody. Ideally we can use the chain sparingly. If we have a cooperative setup with somebody we don’t have to go to this global court to fix things with each other. Let’s drill into what actual virtual bytes are used in these swap transactions. The swap transactions are actually two transactions. The first transaction is that you deposit money into the HTLC that goes onchain. How that looks is, if you’re familiar with how a raw transaction works. A raw transaction has some wrapper stuff on it. It has got these version bytes, its got locktime bytes, its got these counters that tell a parser how many bytes to expect coming up. It has got a marker and a flag byte for SegWit. Outside of that wrapper, it has got the funds that I’m spending and where I’m sending them to. The funds that I’m spending, that will be referenced with an outpoint. I’ll reference an old transaction ID and I’ll reference an old transaction index of which output I’m spending. I’m going to put in a sequence number which isn’t really used that much apart from OP_CSV. We’ve moved around how the inputs are structured. Now the signatures that are part of proving why I’m allowed to spend these previous outputs, they’re now at the end. That’s going to include your public key, it is going to include the signature of the public key and then any scripts if you have them that are locking those outputs. Once you’ve pulled funds into the transaction you also attach outputs, where are the funds moving out too. Any funds that aren’t attached to an output, they’re going to be pushed over to miner fees. The outputs, you’re going to put out a 8 byte value and you’re going to put a scriptpub. These are all approximate values. If you have different types of scriptpubs, different kinds of outputs scripts, it is going to cost different amounts. An interesting thing to look at is because of SegWIt we actually have a big discount on the public key and signature which are actually a lot of real bytes but much fewer vbytes. That’s a funding transaction. Now I’ve got this transaction confirmed on the chain. This HTLC, there is a clock ticking on it, that CLTV timer. In the happy case the swap counterparty is going to reveal the secret. In one case of a swap they separately paid a payment request offchain and now once they’ve paid that payment request offchain they’ve got this secret and they know that secret corresponds with this HTLC that we set up in the initial transaction. Now they’re going to use that secret to sweep the funds under their sole control. What they’re worried about is that timeout. If they don’t sweep it then the timeout clause can execute and the other person can take it. The sweep transaction, it has the same kind of transaction wrapping. It isn’t a huge amount of bytes but it is still some bytes. It includes the same thing where it has to the reference the last transaction. It is even more signature bytes because we’ve got that preimage in there which is 32 bytes. I’ve even simplified this. What is really going to happen is that when you fund this transaction you’re not going to have one output, you’re going to have two outputs. Unless the amount is exactly correct you’re going to have to move some funds over back to yourself. We’re looking at maybe 260-290 vbytes that you’re going to have to pay for. If fees are 1 satoshi per byte you’re going to pay 300 satoshis but if fees are at 100 satoshis per byte, you’re going to pay a hundred times as much, that’s no fun.
Hyperloop - Improve Privacy
Now we’ve established what the problems are, at Lightning Labs we’re working on this solution called the HyperLoop. The idea is to take all these problems and minimize them but still retain the benefits. The first problem that we’re going to address is this privacy issue. People can see on the chain that I’m doing these swaps. If you analyze the chain you can see all the swaps that are being done. You could tell how many swaps is Lightning Labs doing. I could have an estimate because I looked at all the blocks. What we’re going to do is we’re going to bring back in the channel construction. How the channel construction works is you create a multisig output. The multisig output, just like in Lightning, in Lightning we have a funding transaction where we fund the channel and then we create this child transaction which is called the commitment transaction. That’s the transaction that holds the current balance between the counterparties. We actually never want to broadcast that commitment transaction, that’s our safety net. When we close the channel we’ll cooperatively work to say “I have this signed commitment transaction that I could broadcast to the chain if I wanted to but it is going to be cheaper and more private for us if we cooperatively sign something that just spends from the multisig to any address, not fancy contract address stuff.” We’re going to do the same thing with a submarine swap but in a simplified lighter weight version. When we fund this we are going to create this funding transaction but before we actually commit and pull the trigger on sending the funds there we’re going to set up this safety net for ourselves. We’re going to say “The funds could go into a regular submarine swap but before they go into the regular submarine swap they go into multiparty control.” What we’ll be left with is multiparty control which wouldn’t be ideal if you didn’t have the safety net. If you didn’t have the safety net and you put your coins into multiparty control the other party could say “I’m leaving now” and you wouldn’t be able to get your money back. We first create the signatures so that we could broadcast the child signature if we wanted to. We then fund this multiparty contract and then we do the same thing that we do in Lightning. We have this escape clause and we know we can do it but instead what we’re going to do is a regular onchain spend and we’re going to hide from everybody the fact that we’re even doing this submarine swap. We’re also going to save money because we are no longer have to include all of this proof data that we otherwise would need and we can use something called signature aggregation. That’s something we’re also working on at Lightning Labs for ECDSA which is you can combine two signatures into one signature. That is good for two reasons. For privacy it is great because it looks like any regular signature. You couldn’t tell the difference between it and any other signature. You can do it today, no soft forks, you don’t need anything. It is also great because you are saving a bunch of signature data bytes. Now you don’t need to pay for those. We save on privacy and we save money.
Q - If you’re unlocking an UTXO do you need to publish onchain all of the public keys?
A - No you need one consolidated public key. It can even be something like a public key hash. It can look identical to any other normal payment.
Q - Is it a lot of work to get it working with ECDSA? Is it not worth waiting for Schnorr?
A - We do have something that works in terms of testing that you can go and check out on GitHub today. You can set up a two party signature. The difficulty is making sure it is rock solid and that we feel confident pushing it to production. But it works. You can have multiple parties sign and the network will accept it. Something that I will get into is that we might not ever push to production.
Q - Is it faster as well that version? Are you still pushing it onto the main chain?
A - You’re still using the chain so you’re still waiting for confirmations. In the worst case it is actually worse. In the worst case you are going through more stages. If you don’t plan to cooperate, maybe somebody is going to mess with you, then it is better to use the simpler version.
Hyperloop - Reduce Loop In Chain Footprint
Hyperloop for Loop In is going to take the same principle of making a lightweight channel and we’re going to bring in certain technologies to really save on space. Two party ECDSA signatures is something that is going to take us a lot of work to move into production but luckily enough Blockstream has already been working on this concept, MuSig. They’ve been doing all that work of how to make them production ready which is not trivial. The really cool thing about MuSig is that MuSig is something that can work for any number of keys. There are no limits. You can have a hundred keys in there. It collapses to one signature. That’s a huge saving of bytes. You have constant bytes. The more people you load in the more money saved. What we can do with the HyperLoop is try to get tonnes and tonnes of people to enter into one of these loops. They all get their same escape hatch so if something goes wrong that escape transaction can still be used. We’re also saving from these multiple transactions. All these people are sending to this one output. They have all these inputs and they are sending to this one output. This is a case where we don’t have the great savings of MuSig. We don’t always have great savings. In the Loop In case people are spending from different outputs. They are not spending from the same one so we can’t condense it. But we can still get savings on the other side of this. We can get savings once we’ve already put it into this multisig they can then spend it as one. Maybe in the future we’ll get signature aggregation across multiple inputs but that is not something I would hold my breath for. We still get a lot of great savings so we still get better privacy. The other huge savings here is that we can use atomic multi-path payments. Normally in a submarine swap you have one onchain transaction and it is corresponding to one offchain transaction. Every time we do this it is costing like 300 vbytes on the chain. But we can use atomic multi-path payments to say “What if I want to do tonnes of offchain payments?” I can collapse them all into one onchain payment. If I want to refill a lot of channels, in this case Loop In, I’m going into Lightning. I’ve depleted ten channels. Instead of doing ten swaps I can do one swap because it is all AMPed to that one onchain transaction. Of course that also has no limits. It is as many channels as you have, you get that much savings.
Hyperloop - Reduce Loop Out Chain Footprint
It gets even better with the Loop Out case. With the Loop Out case we are no longer constrained by those inputs. Every time you add an input you’re referencing an old transaction which is 36 vbytes. Then you’re also referencing that signature information that cannot be aggregated. We’re having this heavy weight on our transactions which is the signature information and the previous outpoint. But if you look at a transaction, those vbytes, if you are spending out the vbytes are actually very low because all you need is one script and one value. Script and value. If you’re sending to a single key it can be maybe 30 bytes altogether. Much less than all those inputs cost. What we can do is, the swap provider can control a massive input. All the people who want to Loop Out, they want to get their funds out, they send to the swap provider offchain. Then the swap provider takes this massive input and he says “Here’s a 30 byte output for you.” As more and more people enter into this HyperLoop I can say “Here’s a 30 for you and here’s a 30 for you and here’s a 30 for you.” We’re also cutting back the change. You just get the output you want. We have a fixed cost otherwise. Just to go into a little bit of detail about how AMP works. AMP isn’t actually all that complicated in the simple sense. In the simple sense what is happening is, let’s go to Lightning Network for this, in a normal HTLC somebody comes along and they say “I’m going to lock 1 Bitcoin to you and I want you to lock 1 Bitcoin to somebody else.” The reason you’d do that is because there’s a difference between those where there’s a fee you’re going to get as long as this entire chain of HTLCs completes. You look at 1 Bitcoin coming in on this side and it makes sense for me to lock 1 Bitcoin going out, hopefully. But what happens if somebody locks half a Bitcoin to me and he says “Please lock 1 Bitcoin going out.” Normally what I’d say is “No I’m going to be losing money.” But he could tell me “I’m going to send half a Bitcoin to you but then hold on for a minute. Don’t error back to me. I’m going to send you half a Bitcoin somewhere else and it is going to be locked to the same preimage. I’m not changing up the preimage at all but I’m going to lock both of these to you.” Whenever you have a lock that’s set up, normally you’d never use a preimage. But because I wait for the lock to be set up, I wait for the commitment transactions to be signed, I say “Ok I’ve got one half a Bitcoin locked to me and now from another point I’ve got another half a Bitcoin locked to me. They’re keyed to the same payment hash, they’re keyed to that same secret. Now it makes sense for me to send out 1 Bitcoin going out because once that goes out and I get the preimage I’ll be able to take these two coming in and I’ll be square. That’s how HyperLoop can work also without very complicated changes, no soft forks or anything. Just based on that simple logic. Let’s say I’m a busy merchant with 100 channels that all have got tonnes of money in them. At the end of the day I want to push them all out. I’m going to go to the swap provider and I’m going to say “Wait for this amount of money.” I’m going to be locking, locking, locking all these to the same preimage. Then when the swap provider has enough funds that are locked to it, it will say “I’m going to aggregate those all into this one onchain output that’s going to correspond to that same preimage.” We’re going to get huge chain savings from all these individualized offchain transactions that are being moved into one instead of doing a new swap for each one. I would definitely say that in terms of forks… We saw before with MuSig, that depends on the Schnorr soft fork. But it will also be helped by taproot which is potentially in the same fork for all these escape hatches. One problem with the Loop Out and all these cases, what happens if somebody doesn’t cooperate? If someone doesn’t cooperate and we’re not cooperatively signing then we all have to go to these escape hatches. This even is a problem for us actively with the Lightning Loop service. With the Lightning Loop service, when you Loop Out what is going to happen is we’re going to pay onchain and when you see that payment onchain you’re going to pay us offchain. You’re not going to want to pay us offchain if you don’t see that you’re going to get reimbursed. That’s the way we make it non-custodial. But we are paying onchain so we are paying chain fees. You can cancel, you can say “I changed my mind, I don’t want to do this.” We’ve still paid those chain fees and now we have to pay a timeout fee because we have to wait until it times out so we’ve got our capital locked up. Then we need to pull it back. We’re going to pay two chain fees.
Q - Surely you only pay the chain fee if the swap goes through on both sides?
A - That’s not the simple way to do it. The simple way is you set up this HTLC and then you pay the chain to do that. We’re talking about onchain, not offchain. Offchain if there’s a problem we can fail back and nobody has to know about it. But this is all onchain, this part. We’ve published this onchain transaction paying to a HTLC. Then we say “Please pay an offchain payment request that we’ve made. You’re going to publish the preimage when you do the sweep.” Basically we’re going to match an onchain to an offchain. If it doesn’t work out we’re going to go back to ourselves. In order to go back to ourselves onchain we’re going to have to pay a chain fee. In order to solve that we currently have what’s called a prepay. Whenever you initiate one of these swaps you pay us in advance for that chain fee cost and to anti-DOS. We wouldn’t want somebody to spam us with tonnes of requests and make tonnes of chain requests that never were fulfilled. That’s also something we can do with the HyperLoop to make sure everybody is cooperating. If you don’t cooperate there’s a small component which is anti-DOS. There’s other ways the swap could be constructed to make it so that you could maybe attach your own inputs. Then you could attach another output which is the chain output. This is the simple case and also uses minimal chain space.
Q - Does the HTLC pay the fee back or does the person pay the chain fee at the end of it?
A - We refund it. We say “Put a deposit down for that timeout case. If there’s a problem we’re going to take that money. Otherwise you’re going to get it back.”
We’re already setting up for this coordination of this massive multiple signer.
HyperLoop - Chain VBytes 204 + 30/Swap
I want to circle back to what are the actual chain costs of the HyperLoop? This is the same rundown of how the transactions are going to be represented onchain. This is the HyperLoop Out. In the HyperLoop Out case the thing I want to highlight is that we’ve actually saved some money on the preimages. We removed the preimages so those are no longer represented. But also they already had the SegWit discount so they weren’t hugely contributing. The huge thing that was contributing was that every single swap we were doing we were doing more and more chain transactions. With this we only have to attach more outputs and the output is so cheap. All that we’re representing instead of 300 vbytes, we’re representing 30 vbytes. That’s not even thinking about AMP aggregation. If you AMP aggregate maybe ten channels into every swap you’re only using maybe 3 vbytes. All the other costs are static. All we have to do is coordinate a massive swap between a bunch of people and our chain impact is pretty minimal. We still get those great benefits of escaping those flow network constraints.
Addressing Current Needs - Fixing Current Pain Points
I just want to sum up a little bit about our philosophy of developing HyperLoop. One thing that we’re really focused on is trying to match it to what people’s immediate needs are. The biggest need that we saw was Loop Out because people want to play with Lightning, they want to receive. Capital is something that is a hard problem. Who should get it assigned? We’ve provided that with Loop Out at the moment, we’re trying to make it cheaper. Another thing that I’ve been thinking about is if we really want to make Lightning take off we can see the answer right in front of our faces. People are paying $20,000 every block every ten minutes to do something that can theoretically be done with this network that we’ve created at very minimal cost. The practical reality is at the moment the number of exchanges that accept Lightning, the number of regular stores that accept Lightning is pretty low. But Loop Out with HyperLoop could actually just save your regular onchain costs. Because what you could do is you could say “I have these onchain costs that I regularly pay out so whenever I’m making these regular onchain transactions I’m going into my wallet, I’m selecting some inputs and I’m making an output to where I want it to go and then I’m making another output that is change back to me.” What I’m doing is spending a bunch of money on selecting these inputs, I’m spending a bunch of money on selecting the chain output and then only out of the 150 vbytes of my transaction maybe only 30 of those vbytes is what I actually want to do, which is send an output to the exchange or go to the store that I care about. Even if you don’t care at all about Lightning, if you just establish some channels and you use a swap provider, the swap provider can give you a ride on one of these Loop Outs. It can say “Forget about that change, forget about those inputs. All you’re going to get is that output that you wanted. You’re going to send us offchain and we’re basically going to do what exchanges do, we’re going to batch everything up together. In anticipation of this future we’ve pre-adjusted the costs for Lightning Loop. Our charge for it now is actually lower than cost because we anticipate these savings coming in the near term. If you try it out and you start to integrate it into your existing systems it will cost you closer to those future costs. We know in theory it works, we just have to do the work of building it out.
Q&A
Q - Do you have an ETA on launch?
A - We’re going to do it very iteratively because HyperLoop involves lots of different components like AMP and two party ECDSA. There’s another component that I didn’t even talk about which is what are the fees that I use? The fee can make a 100x difference. If I have a low time preference I can set up these swaps to take days. If I have a very high time preference, I want it to happen right away, I’m going to pay more. We actually have in a pull request right now in the repo something that allows you to choose your sweep cost so you can save 100x on the sweeps. Then we’re going to add that out to the rest of the components so you can specify your time preference. Time preference is also important to set us up for these aggregated things. We need to collect lots and lots of people onto these transactions. It is not every moment that there’s going to be a hundred people all wanting to grab onto one of these loops. But over the course of the day we can say “There’s lots and lots of people who are going to enter into that Loop, we can merge them altogether.”
Q - How are you going to expose this? Is it going to be APIs?
A - Currently we have an API so you can go to our GitHub, there’s a client that’s open source, MIT. It talks to an API. It is a way to demonstrate doing a non-custodial use of the API but also just something that you can practically use. Then we’ve planned to integrate it into our desktop and mobile app. People on iPhone, Android, we haven’t worked out the user experience but we’ll try to integrate that so that people are getting the savings without even thinking about it, they’re getting the advantages. I want to receive so I can just press a button that says “It works.” Other wallets have already beaten us to the punch even. Moon wallet, Breez wallet, they’ve got submarine swaps integrated already.
Q - Do you plan to be the only market maker of that initially?
A - Submarine swaps are not super complicated so somebody can set up one of these services. The thing that we’re focused on is really creating a production ready service that a lot of people can use. We want people to build on this. The advantage of people building on it for us is we can do more aggregation. We want to get tonnes of people to aggregate. The more people we can aggregate the faster we can do these loops. That’s one reason we want people to build our APIs into their own apps. Then we will also include it in our own app. It will be usable both ways. Right now there’s a command line version you can try out.
Q - Do you have any idea on how much cheaper or more expensive it would be to use these instead of paying….?
A - I don’t think they’re mutually exclusive because these things can actually be hooked right into channels. The output is just any output. A Loop Out output, you could have that output be the funding output for a new channel. I would say the bigger question there is a question about liquidity. Liquidity is a market itself. I want to get $100 million locked to me. How am I going to do that? I’m probably going to have to go to liquidity providers. I think there are two separate markets there. We’re more focused on the ongoing process. The submarine swaps are more focused on ongoing usage. The network can adjust to these swaps going on. They can say “I see that there’s some movement in this direction, I’m going to assign more liquidity.” With the Bitrefill style which is something that I also played with on Yalls.org to buy a channel, it is more about I’m throwing a party and I want everybody to pay me for beers. Also the amount is larger than what a swap would really work with. With swaps, until we have AMP we are constrained by the values. We can’t do a swap for 0.16 Bitcoin.
Q - Can you do a couple of swaps with yourself in the same block? I read about the Loop de Loop. Could you pay a couple of invoices to yourself, you’d be adding a couple of signatures of your own together in that way?
A - The Loop de Loop concept is kind of like, let’s say my app wants new users to have perfectly balanced channels from the get-go. Maybe they don’t understand this channel liquidity concept. When they put in $20 I want them to be able to receive $20 and send $20. That is easier than if they just put in $20 they have to wait until they’ve spent down that $20 to receive $20. What I can do is I can say “I’m going to do one Loop to get all of that money out and then I’m going to send the money back to myself and make a new channel out of that.” I can maybe even use the output of the Loop that is the success output and make that into a channel. Now I did this one Loop and I’m balanced. You could even potentially go further. You could say “That channel will now do a Loop Out so I’ll get even more liquidity to me, get even more liquidity to me” because I’m Looping and Looping and Looping. Let’s say I’m setting up a merchant. In that case I could do tonnes of Loops with a very small amount of capital. I don’t need to have a matching amount of capital which is a constraint of a swap. I can get $100 of liquidity bound to me even with only $20. The cost there is that you’re paying these fees every time you’re doing it. We’ll see how that works out. Then for splicing I’d actually say this is an alternative to splicing where there could be savings. A splice in a normal scenario still carries that baggage of those inputs. You’re changing your channel around but you are paying to represent inputs onchain and maybe you’re representing change onchain to go somewhere else. I think it can be cost competitive with splicing. It has other benefits. If you’re a routing node, one of the signals that people can use to do pathfinding is they can look at old channels. They can say “This channel has been around for a long time so I know it is probably stable because these are two nodes that I’ve had experience with.” If you do splicing you are erasing the history of your channel because it is no longer placed in a very old block. Potentially we could have the history connect to it but that’s complicated. Another thing is we don’t have splicing yet and this is something we can do right away.
Q - Could you tell us a little bit about how Lightning Labs has been managing the BTC reserve versus what is in their channel? As people Loop Out you’re having to spend some capital that you have reserved in BTC and you need to balance that out.
A - At Lightning Labs we have our own problem because we run our node, we have our own liquidity problems. What we’re doing is selling you liquidity. We’re not focused on that business which is what Thor has been working on, Bitrefill has been doing, purely monetizing that capital. Our philosophy has been more low key. What we really want is the network to be healthier. We don’t even really publish our node. We don’t want you to be swapping directly with us. What we want to do is create a global network where if you connect to one you can pay to all. If we allowed a lot of people to connect to us it would create a network that was localized around us. We’re trying to discourage people from connecting directly to us. It is also better from a privacy perspective. Now the funds aren’t flowing through us when you’re spending, they’re flowing through whoever you picked. Maybe you picked your friend and so now your funds are flowing through your friend when you do a spend. We do have an issue with funds moving too much in one direction. That’s one reason we recently launched Loop In. Before we only did Loop Out to deplete your channels. Now we have Loop In which goes the other way, you can refill your channels. That’s also another reason why we want that global network. We want to make sure that those flows can be more balanced. In actual practice we want the flows to be equal but that’s why we have these submarine swaps. In real life capital flows are not equal. You go spend at a store and that store isn’t going to take that money and directly send it back offchain to make the bidirectional channels perfectly efficient. What we do is we close channels and move funds on the chain when we need to move capital around because we are using the chain just like a submarine swap would use the chain, to escape flow problems. The other thing we’re trying to do is educate people on how to run a routing node. How to set your fees properly and then also how to make money by taking advantage of people doing traffic on the network. Hopefully what happens is we have a lot of people Looping Out. What they’re doing is sending traffic in our direction. We want people to notice and say “This is a great sync.” Maybe not to us but maybe to one node or another node. They’re saying “This neighbor is getting lots of traffic so what I’m going to do is take those fees that I’ve made doing that routing and I’m going to commit even more capital in that direction because that is a highly used direction.”
Q - So when you say submarine swaps and Loop In, Loop Out, they’re exactly the same thing? It is just terminology.
A - Loop is more like the brand, this is the production service that you pay for. Submarine swap is more like here’s a technology, here’s a concept. Lightning Loop is the service. It is also a proprietary service. The server is not open source. I have previously written an open source submarine swap service. The devil is in the details. We’re really locking down on providing production uptime, providing good rates, providing good liquidity to the network, building out that toolset.
Q - You released Loop Out before Loop In just due to demand? There’s no extra complexity?
A - It was much more difficult to do Loop Out because of this problem with doing the onchain payment. That is one reason why I didn’t implement it. It requires to do this locking. We had to change lnd to make it be able to support this type of a swap. It uses HODL HTLC, it holds onto the HTLC which is a feature we had to build. The demand was there for moving funds out and we’re also trying to think as we build production services, how can we be representative of the people who are using lnd to make things? That’s the best way for us to know what to add to lnd is to actually run into the challenges that other people are going to run into. When we make the mobile app we can see the problems mobile app developers are going to have because we have our own mobile app. When we make production services of lnd we can be the first ones to encounter all those problems of somebody trying to run an exchange, somebody who is trying to make an app because we had to face those problems ourselves.
Q - With HyperLoop, whether it is an API or whether it is just a service you’re providing there is a coordination problem?
A - In order to create this massive multisigning system you’re going to need to have a coordinator or some decentralized version of a coordinator if you wanted to make a competing system. It is just easier for us to set ourselves up as a coordinator. It is non-custodial so we’re coordinating but we can’t mess with the funds. It makes it easier for us because we don’t have to be so paranoid about security because in the worst case people get their money back.
Q - It is like a coinjoin?
A - It has a lot of the privacy benefits of joining your coins in terms of leaving the UTXO footprint behind. Even doing a regular submarine swap the settlement is happening somewhere out there. Somebody who is just looking at the chain is like “I saw some funds move over here and now there’s funds over here, I don’t know how that happened.” I wouldn’t say that we are super focused on the maximal privacy in the current iteration because like I mentioned you still see the preimage on the chain. That’s something you wouldn’t really want if you were just making a purely privacy focused system. But privacy is pretty important to us and we are going to include more elements to make it more invisible and the way you access our service is also private. We don’t know who you are, we don’t have your email address, your name or anything. It is onion protected. That is also why we want you to connect at a distance. When you do this Loop with us you’re paying us offchain. We don’t know where it originated, that’s part of the Lightning Network.
Q - I’m interested in why some services are included or integrated within lnd and some are external to lnd. So Loop has its own daemon separate to lnd. Why is it not integrated?
A - We separated the Loop daemon from lnd daemon because number one, the Loop daemon, it sounds like it is a big heavyweight thing, it is really not. It is just doing that one transaction type. The only reason it is called a daemon is that you need to worry about those timing risks. You need to keep it on so that it can bump the fee if there is a problem. It is not a very complicated piece of software. You could implement it yourself probably if you just spent some time on it. It uses our service, we’re building it to use our service. lnd is something for the community, we want that to be a community driven platform. We want people to submit features to it, we want people to build on it. We want to have a Chinese wall between those two different things. lnd 0.7.0 is out now, I would definitely recommend everybody update it right away.
Q - Is there much of a healthy network on testnet, a testnet Lightning Network? Do people use that?
A - It is healthier than the Litecoin network. It is not so bad. One thing I do is I measure healthy nodes in the network. In addition to working on Loop I also work on the other side of it which is monitoring the network. The main network maybe has 250 nodes that are great routing nodes out of thousands and thousands of total nodes that anybody installed and made public channels. Testnet has maybe 50 good routing nodes, pretty ok. A lot of services run a testnet node in addition to their mainnet node. Litecoin maybe has 25 strong nodes. Of course there is a lot less money which is kind of funny. Even though testnet money is free there is way more real money than there is testnet money.
Q - Do you know how many good routing nodes are behind Tor? Can you see that?
A - My node is a great routing node. I’m behind Tor. There are also two types of nodes behind Tor. There are those that also provide a Tor address and then they provide a normal address. One problem with Tor nodes is you need Tor to connect to them. They struggle with inbound liquidity because regular people don’t have Tor installed so they can’t connect to them. Tor can connect out to the clearnet but clearnet can’t connect to Tor. Another problem with the Tor node is that it is wrapping one onion inside of another onion. You have a slow down. Lightning is already kind of slow because you go through one hop and unwrapping and then going to the next hop. You’re now doing that another time because the regular networking does that with Tor. I think Tor node support is growing because we’ve been trying to prioritize it in lnd in terms of supporting it as a first class networking stack. Casa HODL has also been trying to get people to install it. Not just for privacy but also to avoid people revealing their IP address to everybody and to provide a consistent address for them to connect to because you create a hidden address and even though your IP changes your hidden address can stay the same.
Q - There’s Tor for Nodl and the Raspiblitz too as well.
A - I’ve definitely seen an improvement but I would say only 10% probably of good nodes are Tor. They struggle with this liquidity problem.
Q - What are they going to do about it?
A - You could make a clear node and a Tor node and you can move liquidity. If you have inbound liquidity on the clear node you could move it over to the Tor node by sending between the two nodes. I have both nodes, I have a clear node and a Tor node. I can move liquidity if I need it. I do similar amounts of routing on both nodes.
Q - How are you approaching this from a regulatory perspective? Are you going to end up with a Shapeshift kind of problem?
A - From a regulatory perspective I think the biggest thing we focus on is having no custody. We also have no rates. We’re trading Bitcoin for Bitcoin. We’re basically providing a service to you of moving your Bitcoin around. At least we’re aligned with the regular network. The regular Lighting Network moving point A to point B is non-custodial. I’d say from a regulatory perspective that is what we think will work. I’m not a lawyer, I don’t know. It will probably vary from country to country. That’s our thinking.
Q - Would the prepayment fall in that category?
A - It is something that we’ve kept small for that reason, to try to make it so that the bulk of your funds are not represented by the prepayment. If it were a problem we could set it up so that users had to bring their own inputs. We could also do something where you had some other way to prove that you can’t costlessly attack us. We’re having to spend this money and you could be anybody. I’d say it is more akin to a service fee.
Q - I’m into Tor nodes because I’m running two of them and no clearnet node. There’s been a discussion amongst people that the speed of a Lightning payment done with a Tor node is significantly slower. Do you experience that?
A - People have said that Tor nodes are slower. Since I switched over, Y’alls is now 100% Tor, I do notice that it is slower. Part of it is because we weren’t working on Tor. We were working on all sorts of other problems that lnd was having. We weren’t running Tor ourselves and we weren’t working on the high latency mode which is something that we are working on now. We’re running Tor more ourselves and because we’re working on the Lightning App which is designed to be used with your mobile connection. The same principles that are going to improve the operations of a phone are going to improve the operations of a high latency node that’s on Tor.
Q - Do you think that implementing into the nodes to be Tor relay nodes would help this? Most of the communication that is delayed is happening on the Lightning Network?
A - There’s all sorts of sources of delays. Tor is just one delay. There’s a lot of tuning that’s happened in lnd. How long do I give the other person? How long do I retry? How many retries do I do? How do I extend the retry time? One of the biggest time delay things is that we currently have a pathfinding system that is very unsophisticated. We just do a simple Dijkstra over the graph. What you normally see when you pay in lnd is you say “Initiate payment” and then it looks like it blocks, spinning, spinning, spinning. It is like “Payment failed” or “Payment succeeded”. But if you actually watch what was happening it would first do the Dijkstra to see what’s the cheapest route. Then it would try Fee 1 and then it would say “That didn’t work” because there would be some route failure. It would go Route 2, Route 3, Route 4, Route 5, it could try a hundred routes. The worst thing is up until 0.7 after 30 seconds it would forget about all the previous attempts. So the next time you went to pay it would just try all those fees, 1,2,3,4 all the way going up. We’re working on for speed getting the right route the first time. We’re going to attach a cost to failed routes. If I don’t want to save 1 satoshi and I know this route is probably going to fail I’m going to skip over it. Then there’ll be a time component. That’s a complicated thing for us to implement. That’s one way we can get much faster payments.
Q - At what point is Tor slowing down this process?
A - Tor just adds latency to everything. Every time we do this payment attempt we have to set up a new commitment transaction with our peer, we have to do some back and forth messages and signing and stuff. That’s taking more time because we’re on Tor. If we just had that one time that we tried it it wouldn’t be so bad. We are also thinking about how to change the protocol. The protocol itself is getting upgrades. One upgrade that we are thinking about in order to make payments more reliable is to include better errors. Right now when we get an error back it is actually not trivial to figure out who I should try next. I got an error somewhere on the route, it is onion wrapped, I don’t really know where it failed. Right now whoever failed it will sign a reason that it failed and get back to you. You have to interpret that reason and say “Ok that reason means I should try this way or this way.” But you don’t get too much information. One thing we want to do is add maybe what I saw to every hop. One attack that you could carry out on the network today is you could slow things down. That’s something that I think we really need to be careful of when it comes to Tor which is we’re trying to think ahead about this attack which I just behave like a very high latency node. I still maybe carry it out or I fail it back but I take a long time.
Q - It is like Hodl Invoice?
A - It is like hodl route. We don’t really expose this API so you’d have to hack up your lnd. Maybe c-lightning has this hook. You could take your time. What I want to be careful of when we do this optimization is that we don’t overpenalize Tor because those Tor nodes are going to take extra time. It is a judgement call. Do I want to spend that extra time waiting for my payment to go through? I wish that the whole network was Tor because it would improve privacy for everybody. One person’s privacy also extends to other people. We also have to balance growing the network and providing great user experience.
Q - Assuming that Lightning Network is a massive success can Tor scale with that success? Let’s say the default is to use Lightning Network over Tor, can it scale with the Lightning Network?
A - We need to adjust how Lightning works. We need to continue to evolve the protocol. The fundamentals of the protocol are I’m just exchanging states. All I’m doing is basically exchanging a signature with my peer, exchanging a little bit of metadata. That can scale on Tor pretty good because the overall network is created in a way where I’m not sending out too much traffic. That’s also one of the reasons why the errors are not sending back a lot of good information. Everything was designed very explicitly to keep the data pretty compact. The things that would probably fail if we had huge usage of Lightning Network and it was used in a way that we didn’t expect is the gossip system. That’s something that we’ve already had to deal with because the network grew so quickly. The current system of gossiping who the nodes are, what the channels are, the fees that you should pay, the time delays you should do, which channels are online, which channels are offline. That data started to get out of control and we had to lock it down. I think in lnd 0.6 we created a new system for that that solved a lot of those problems. We really optimized it. We still anticipate going forward that we’re going to have to improve that gossip system depending on how the network plays out. It may be that there is a small number of public nodes and the bulk of all the nodes are private, non-routing nodes. It may be that tonnes of people want to be routers. Then the gossip of traffic between people announcing things is going to be huge. It could be that people are trying to change their rates up all the time. It will have to be adaptive.
Q - I’m set up this way. I have two nodes, one is watching another because only one has funds on it. The question is if the watchtower is offline then in that time if a transaction happens on the active node then the watchtower won’t know about that justice transaction so it won’t be protected. If that state was broadcast to the network it won’t be protected by the watchtower?
A - If the watchtower misses an update?
Q - Or if I connect my node to a watchtower it won’t know about the previous states at all. It needs to be online when those changes happen.
A - Yeah it needs to be online to hear about the potential breaches and then it needs to be online when a breach happens. Although there is a timelock so potentially you can have two weeks or something. Then you probably wouldn’t even want to update it exactly when things happen. Maybe after fifteen minutes you would tell it. Maybe you’d have a buffer of wanting to tell different nodes. You might also consistently be telling it different justice transactions because you might want to have different fees. Let’s say they broadcast a justice transaction but the fee is at 1 satoshi. The timer runs out, the time for justice is over. You need to make your fees commensurate with your risk.
Q - With previous releases of lnd, you’re monitoring the chain on behalf of yourself on the same node?
A - Existing and previous. You are always watching the chain to see if there is a problem.
Q - When you said the new release with watchtowers integrated that’s for the case of me running two nodes and one of those nodes being a watchtower node for my other node? It is for that use case?
A - We intend for them to be set up in a way that one watchtower can watch for many, many people. It is not so complicated to make that use case happen. Transactions are relatively small and they can be updated and kept around. We can also change how HTLCs are represented in terms of signatures. This is kind of like the first step. We got it in a release, you can turn it on, you can set up a watchtower for your own node and you can run a watchtower for somebody else. This is also something that we want to put into the standard protocol. That’s another reason why it would be a part of lnd itself.
Q - Can you run a watchtower over Tor?
A - I think it should work with Tor right away. I think the current version should work with Tor. I haven’t run it myself actually. We’ve been running watchtowers internally for a long time. I think it should work with Tor but I don’t know exactly.
Q - I could only use the clearnet IP on my node.
A - I think you might have to set up some kind of tunnels so you set up the Tor connection separately. I don’t know. If there is a problem with Tor we definitely need more hands on Tor pain points to be represented in the issues. If you run into this I would make an issue. It is a priority for us.
Q - The watchtower standard is going to be part of the BOLTs?
A - Hopefully it can be part of the BOLTs. Watchtowers were part of the original white paper. They were influencing the design of how the transactions were even formed. We think they are useful to all implementations. We would like it so that one watchtower for one implementation could serve as a watchtower for another implementation. We’ve got a ways to go.
Q - The eltoo paper talked about some enhancements for watchtowers. Does that simplify the need to hold each transaction?
A - If we did have eltoo. Eltoo is kind of far out. We have Schnorr, taproot, even that is far. We have to get consensus around it. There is another soft fork which is the consensus clean up that we were talking about. Then there’s SIGHASH_NOINPUT that would provide different channel constructions. The advantage of eltoo is you can no longer really have these penalty transactions. You just have your out of date transactions. You still have to have someone watching because you can still steal money but the punishment is no longer you lose all your money if you try to steal. The reason for that is we potentially don’t want to punish people too much for using an out of date backup. Although we have another system in the current protocol called data loss protection which will warn your peer if you are trying to use an out of date state. In practice so far it has been pretty good to stop this from happening. As long as you connect to peers that are online, good routing nodes. If you connect to nodes that are bad there can be this case where eltoo would be helpful where one node force closes but it force closes on an old state and the other node wasn’t around so it wasn’t able to connect to them. It has to do this punishment system. Eltoo allows for more simple watchtowers because you don’t have to keep as much old signature data around. I’m not super deep into why it is beneficial. I also think that we will potentially still have a mix of eltoo channels and regular channels depending on the values because of the economics of it. If I stand to gain a thousand dollars and eltoo has a limited penalty for me trying to take that thousand dollars why don’t I just try? If the watchtower catches me the watchtower catches me. But if it doesn’t catch me I get a thousand dollars. The only thing that you lose, which is potentially be a bunch, is the chain fees. I tried to steal, that cost me an onchain transaction to try to steal. I think the way that it will play out will be more along the lines of value. If the values are small in the channels then the chain fee will be a serious component. Also the risk calculus will be different, I won’t stand to gain that much. If the channel is huge then am I going to put a million dollars at stake that they could try to take and there’s going to be no penalty for them? In that case maybe I would want to work in a penalty. Eltoo potentially can even be adapted to make the penalty more moderated. I really think this is far out though because of the soft fork thing and because there are so many thoughts on how we could do it.
Q - Another thing in 0.7 was the ability to pass your own randomness for seed creation?
A - That was a late addition.
Q - I’m trying to get my head around it in terms of aezeed. BIP39 should be replaced even though hardware wallets are currently using BIP39? I’m struggling to think what I need to back up for both my onchain funds and my Lightning funds.
A - There are some big questions around. lnd has its own seed format that we came up with. It is not exactly BIP39. BIP39 is what is used by most wallets that are based on Trezor’s mnemonic system. There’s a lot of questions about how we should message to people what you need to back up. Normally people are used to the mnemonics and they like the mnemonics because it is simpler than saving a file, you just write something down on paper. Maybe it is even more durable. But in Lightning not everything is represented by that mnemonic. It can be confusing to people. Why do my channel funds not return with the mnemonic? This is such a deep subject because people have a lot of different opinions on what should be done. The opinions on aezeed, in our seed, we have two opinions that we’ve changed from BIP39. Even BIP39 is opinionated. Bitcoin Core doesn’t use BIP 39. So it is arguably not a standard because there are a lot of wallets that don’t use it. Electrum said this seed format isn’t working for us. The thing that we added is a version to the seed to say “What does this seed even mean?” A lot of times if you try to load up a seed you have to match which wallet did I actually use and is it on the same standard? There is a lot of nuance to this. Even if wallets are on the same BIP39 standard maybe they have different values for how many addresses am I skipping over? I’m skipping over this amount of addresses or I’m skipping over this amount of addresses and it can make it look as if your funds are gone. Then we also added a birthday. The reason we added a birthday is, when did your wallet start so that instead of looking over the past ten years of the blockchain for all the transactions that could potentially be in your wallet we know to only look over the last six months of the blockchain or whenever you started your wallet up. We’ve made those two changes in aezeed. The story of what to back up at the moment is use a watchtower for yourself, copy down the mnemonic, the mnemonic is like the master key. You’re not going to be covering your channel states so all your channel balances are not copied by the mnemonic and also not covered by the watchtower. So what you want to do is take the static channel backup. That is a feature that we added to represent your channels in a static way. You only need to back up one time every time you make a channel. That basically keeps a record of who your peers are and what their channel identifiers are so you can go to your peers. Then your peers can force close and force close in a way where you can get your money back as long as they cooperate with you. We have those three components right now for how to safeguard your funds.
Q - There’s a cipherseed on top?
A - Yeah you’re right. I don’t use it. There is a feature we have with our seed, I guess in lnd, I don’t know if it is part of the seed exactly, is that we will further encrypt the seed. I guess it is part of aezeed. You can provide a passphrase to your wallet, you can have your mnemonic and then you also have a passphrase for your seed itself. So the passphrase for your wallet encrypts your wallet. The passphrase for the seed encrypts the seed. The selling point of it is that if you enter the wrong passphrase for the seed it will tell you. It will say “Hey this doesn’t match.” Potentially that will be better than trying to restore from a seed that you wrote down incorrectly and you are like “Where’s my money?” You won’t get to that state because you’ll be stuck on the state which is what’s my password for my seed? It’ll be like “You’ve got the wrong password for the seed.” Instead of loading up a seed, its a random number, so I’m looking for all the coins on that random number. But I think there’s a checksum already in the seed. I’m not sure, I personally don’t use it.
Q - It is not like an extra word?
A - Kind of. It is hard to think about because if it encrypts the seed you don’t want it to just be like “Apple”. If you want to use it in the way that you’re just checking it yourself you do want it to be “Apple”.
Q - Could you restore without it, with just the seed?
A - No because you’ve encrypted the seed.
Q - It is not like encrypting the file on disk? It is a component of aezeed?
A - You could store it in two different places maybe. If you did use it what I would definitely recommend is that you write down both. Our seeds are already pretty long, they’re already 24 words. In order to make a passphrase with sufficient entropy that would be meaningful you would need to make a long passphrase for that too. You’d be writing a lot of stuff down. That’s why I personally don’t use it. In different workflows maybe it could be more useful. It really depends on the situation.
Q - The Lightning App doesn’t use it?
A - No the Lightning App doesn’t use it. We have a PIN system and the PIN protects a randomly generated master password but that password is encrypting the wallet. If you do go through the recovery flow... If you try to recover a wallet that does have it then the app doesn’t even support it.
Q - We have had plenty of issues with the Raspiblitz builds because before, the 1.2 version which is the current one, we did offer this cipherseed option but through the lnd interface and then people who did use it had trouble restoring.
A - It can cause problems and it also doesn’t work like the Trezor seed. The Trezor has a password but the way the Trezor password works is totally different. You have your master seed and then the Trezor allows you to have a special path that is recovered by a simple passphrase maybe. Then the idea is if somebody asks you to show them the money from the Trezor you could show them one and then be like “I only put in $100 there, all the rest of my money is somewhere else.” It doesn’t work like that although potentially it could. I also didn’t mention the entropy. Entropy is now something that you can feed directly into the seed system. Let’s say you’re testing. I don’t actually know, I wasn’t privy to the conversations of why we needed this exactly so I’m kind of guessing. For myself, if I want to run unit tests I want that entropy to be reproducible. Every time I make a wallet I get the same things out of it. I also know that as we’re deploying to Android, iPhone, Mac, Linux, Windows we’re seeing a lot of variation in how entropy works on different platforms. In theory we’re using React Native that is supposed to make the platforms all the same but we’re still seeing issues. It probably ties into something like that.
Q - I think I read that one of the motivations was to use the same entropy as you used in your onchain wallet?
A - In theory lnd would use the same source of entropy for its own seed that it would use for the onchain wallet. Your onchain wallet isn’t separated.
Q - You have an onchain wallet before you install Lightning or you install lnd. You have entropy on that onchain wallet and you want to use that same entropy for your lnd wallet.
A - I don’t exactly know why it was merged. It has been an open issue for a long time.
Q - There is the complexity of the seed format with versioning and birthday, aezeed. There’s also the complexity of multiple keypairs required to monitor your channel, to monitor your onchain funds.
A - That’s just how lnd works. We just use different key families within the same master key.
Q - The same source of entropy is feeding into those different keypairs?
A - Yeah it is like a HD key.
Q - There is only one source of entropy?
A - Yeah. That is all deriving from that seed. The seed had to be created with sufficient entropy. It has 24 words so there’s going to be a lot of entropy there.
Q - Where is the birthday stored?
A - It is also stored as part of the seed. That is why the seed is so long. It includes all this extra metadata. You don’t have to write anything else down. It is a little bit weird for people writing down the seed because they’ll notice that the first word of a lnd seed is always going to be A because that’s version 0. So it’ll be like “Why am I always getting Adam for a first word?”
Q - Do old seeds migrate automatically?
A - I don’t think we’ve actually changed the seed. The only thing we’ve added is the ability to add your own entropy in creating the seed. Maybe in the old days we did change it one time. We also didn’t used to have seeds. When I started using lnd on mainnet there was no seed. So unfortunately I deleted that data so I don’t have one of the oldest nodes on the network because I couldn’t easily back up that state.
Q - If you’re worried about the source of entropy then you might be motivated to have different sources of entropy for say the key controlling onchain transactions, the key controlling channel updates?
A - For lnd it is going to be the same. In lnd the same seed is going to control all keys that are ever used. The thing that we might change is that we have an onchain wallet that is responsible for funding transactions and also when you close a channel and goes back to you. We can offer more flexibility in that space where we can say “You can have a channel that is funded by an outside wallet.” The complexity there is because of the protocol it has to be a SegWit spend. As long as you have an external SegWit wallet it can spend and create a channel externally from the application. That is something that we might add as part of Loop. We want Loop which is a separate application to be able to tie back into the normal flows of the wallet. We could say “You can Loop Out and you’re Looping out to a new channel.” Then the other way as well. If you close a channel we could say that the output is something that is an externally controlled thing. Even the protocol itself, the Lightning protocol has a feature that we’ve never used that we could use which will set up a predetermined exit address. Your peer will not allow you to change it. The idea for that is let’s say a hacker got access to your machine. They couldn’t close the channel out to their address. They would have to close it out to that current address. Or they would have to have enough inbound liquidity to spend the channel down. In that case we could work on ways to even have policies that said you’re not allowed to spend the channel down unilaterally, you need some more checks or something.
Q - You alluded to the Lightning Labs strategy of building out these services but not necessarily wanting majority market share five, ten years down the line. You’re building defaults and you want other people to come in and improve on them or build their own versions of those services. At the moment you are doing so much. You are a pioneer in watchtowers, you’re in a pioneer in Loop In, Loop Out, you’re a pioneer on the Lightning App, Lightning wallets. Are you planning longer term to go back and not be one of the major providers of those services or are you happy having a majority market share providing all those Lightning services?
A - Is Lightning Labs wanting to dominate the market of Lightning stuff? I would say we do want to dominate certain things. We want to be your go to liquidity provider when it comes to this submarines swaps thing. We at least want to provide a super compelling experience and be the best out there. We’re very committed to that. As far as apps go I’m not on the apps side of things. I think our philosophy is more like we want to provide a demonstration or model of how the apps could be. I don’t think we want to destroy all the other apps that are building on top of lnd but we do want to make a really competitive app that a lot of people are going to want to use.
Q - When Coinbase got loads and loads of traction it kind of wound down a bunch of different services and just focused on one or two.
A - One thing we are definitely working on is to make things non-custodial. A side effect of our focus on being non-custodial for regulatory reasons and also aligns with our philosophy that this should be a distributed network. It also aligns with the whole idea of Lightning itself which is why are we even using Lightning in Bitcoin? We are using it because we don’t want to be locked in. We should be aligned with that philosophy if we want to make Lightning a success. Otherwise we’re not providing something compelling. But I don’t run Lightning Labs, I’m not the CEO. Elizabeth probably is the one to answer it. It is very commonly asked. I can definitely tell you with Loop we want to be number one. Number one Loopers.