Max Hillebrand (MH): So Rusty, I am very happy that you joined me for this conversation today. You have been a pioneer in Lightning Network. To start off this conversation I am curious, 6 years ago before you got into the Lightning Network what was your understanding of Bitcoin back then and where did you see some of the big problems that needed to be solved at that point?

Rusty Russell (RR): Firstly thanks, it is good to be on. I guess we have to go back 7 or 8 years, I had heard of Bitcoin, I had read the white paper probably 2011 I guess. It is a very easy read. I was always interested in different open source projects doing different stuff and seemed ambitious. The cypherpunk stuff and cryptography generally has always been a side interest of mine. It was in that vein that I looked at this cool open source project trying to make open source money. I bought some Bitcoin early on and spent it all on random stuff. “Let’s buy some play money and send it around and do stuff like that.” I had a reasonable understanding I guess of Bitcoin leading up to that. That coincided with me realizing that the main issue was always going to be the scalability problem. I was working on this on the side and I had a day job doing Linux kernel development. It was actually my wife who said I was much nicer to live with when I was working on something that I was passionate about. She convinced me to take a 6 month sabbatical from kernel work and work on a project which is basically a sidechain. It is called Pettycoin. The word “sidechain” hadn’t been invented yet but it is a sidechain, that’s what we’d call it today. Much easier to explain and try to convince people that I wasn’t writing an altcoin. The idea was you’d transfer petty cash from the main Bitcoin network onto this network which gave you lower security guarantees but ideally higher throughput. That would be your spending money. If you got enough there you would transfer it back onto the Bitcoin network where it was safer. I guess that was my interest in Bitcoin. Towards the end of that sabbatical Blockstream dropped their sidechains paper. I’m like “This is what I was trying to implement. I really wished you had dropped this at the beginning and not the end of my sabbatical.” They reached out to me and said “Hey we should talk.” Shortly after that I ended up joining Blockstream. But in that period between the end of my sabbatical and switching to Blockstream the Lightning paper dropped. Here I was digging into my rusty C++ skills to work on Bitcoin Core, I assumed that’s what I would be doing with Blockstream. Greg Maxwell, then CTO, after I had gone across and visited for a month, said “Why don’t you go implement Lightning?” At the time the paper had dropped but there was no intention to actually implement it. It seemed like something that somebody should do and I kind of felt a bit of bait and switch, I was really looking forward to working with the Bitcoin Core team and getting involved in the Bitcoin project itself. But having written by that stage the explainer that a lot of people used to actually read the original Lightning paper, it was kind of a dense read. I had written this set of blog post deconstructing the paper, a primer on how to read it. It seemed too good an opportunity to pass up, somebody had to do it. I ended up writing the first Lightning implementation as it was and then stepping into a role for standardizing the different implementations that came about around that time. That gives an intro into how I got into Bitcoin and then into Lightning.

MH: Really fascinating and lots of things to unpack here. One thing that I would like to find out about your foundations is your Linux kernel background. Why did you get interested in that and what were your tasks there?

RR: I was interested in Linux when I was in university. I played with Linux at the time. I was also a UNIX person so we had some machines. In my first job I moved into a job and they didn’t have an internet connection at all. I was like “Wow we really should do this”. I had a friend at the university set up a modem and we used a spare PC as a Linux box to route things. That was the first time they ever got email. That was a software company that I was working for. I had played with Linux at university and it was cr*p. I had access to Sun machines, I could install Linux, I could be root, you could throw up a xclock and xterm and that was about it. My machine was flaky so of course it didn’t stay up very long. “This is cr*p I’ll stick with real Unix.” It was actually 1997 when I went to a conference called “Usenix” which was the big Unix conference in the world. This year they had a “Use Linux” track. They had got this up and coming, new fangled Unix clone, Linux, and they had Linux Torvalds, David Miller, Alan Cox. The key Linux people had come to this conference to talk about Linux. I thought “This is a really good opportunity, I’ll go across to Anaheim California to attend this conference.” I went to a couple of talks but a particular talk about porting Linux to the UltraSPARC, the machines I was familiar with, the Sun machines and things. It was given by David Miller and it was probably the most inspiring computing talk, it was definitely the most computing talk I have ever been to. Unfortunately it wasn’t recorded but Dave Miller, this scraggy looking student guy gave this talk on beating Solaris, beating Sun on their own hardware with his Linux port that he’d done in his spare time as a student. It shifted my world view. When I went into that conference I still had this idea of how software was produced. Software was produced by big companies and big teams of inspired programmers producing these gems of software that they shipped out to the world. This idea that this random group of people across the internet could produce something that was even close to usable, let alone something that was competitive and even better than the stuff coming out of the hierarchical system was something that didn’t even occur to me. By the time I left I realized that my whole worldview had shifted. This is the way great software is going to be produced. And more importantly this is what I wanted to do. I wanted to work with this group of people, I wanted to work with people doing this kind of stuff. When I got home I had some kernel patches that I had been working on, some little hacks and things, I started polishing them off. In my spare time I put them together. I submitted them it turns out to David Miller, who as well as the UltraSPARC port was in charge of Linux networking at the time. One day he took my patches and ripped out the old code I’d replaced and that’s it. I was Linux firewall maintainer from then on. I went back to the conference and I pitched to someone who was looking to hire someone, I said “I don’t want to work for you but I have got this new project to make the Linux firewall even better. It is going to take 12 months. But if you pay me, if you send me money I don’t have to have a day job and I can probably complete it in 6.” I was amazed that they went for that. They ended up sending me money for it turns out to be 12 months because software while I worked on this next generation of firewall stuff. Since 1998 I was full time employed as a free software programmer working on Linux. I have never worked on proprietary software since. That was what got me in. Linux of course was this poster child for open source software. A lot of other projects came up, I was interested in what are other open source projects doing? Linux was very polished, a lot of senior practical people working on it. A lot of good procedures, techniques for doing things and stuff like that. That has given a lot to those working in open source because there are some things about the kernel development process that I really like. It scales remarkably well and has a really cool dynamic to it. That has been worked out over the last 20 years. I always look around at new projects and see what they are doing. There was a similar vibe to Bitcoin in the early Linux days. The same thing, this is not how you produce software, it is very much the early Bitcoin vibe. This is not how you make money, this is not where money comes from. This is not how it is done. That level of ambition I think is something that really attracted me to the Bitcoin space. Doing something as a community that people don’t think of as possible. This is not how currency is made, this is not how money works. It is interesting because of course in the early Linux days there were a number of people who said “That’s not a real Unix, it is not real software” etc. There were a lot of perfectly valid points on why it wasn’t. Who am I going to get support from? How can I trust randoms on the internet to write my mission critical software? What is really interesting to me is that we never found a good answer to that. What happened is it became almost compulsory. If you were in a IT department, the people who believed that software had to be produced that way retired and other people who understood that this was the way software was produced took their place. We never got a really good answer. How can you trust randoms over the internet to produce software? At the end of the day it didn’t matter because it was simply better and it was there and it was ready when people needed it. That process took 20 years. When I look at Bitcoin I look at it through the same kind of lens. It will not meet all the criticisms that people have of it but ideally it will have its niche and people will end up discovering this thing is really useful. And progress is made as people age and retire frankly. There will be some people who will never come to Bitcoin and that is fine. That is always the way it has been. Progress happens as more new people come on the scene doing different things. I guess the other important point on those lines is that in the early days of Linux we knew exactly where we were going. Linux was going to go on the desktop, it was us against Microsoft. Linux vs Windows was clearly the battle that everyone was prepared for. That was what we thought we were doing. It turns out we weren’t, it turns out we killed the other Unixes but we never defeated Windows. Despite that however all top 500 supercomputers in the world run Linux. It is probably the most widely distributed operating system, certainly serious operating system, on the planet. All the Android phones and everything else. A serious amount of the internet is served on Linux and that is just a given now. Sometimes you win in ways you don’t expect and the battle that you think is coming is not the actual one that is there. The moral of that is that if you are producing worthwhile, that you think is really useful, it will generally find a use. It just might not quite be what you were expecting it to be. Progress of course will be uneven. It is really hard to predict the future and say “This is where we are going.” That is always a little bit fraught.

MH: What are some of the differences that you see between Linux and now Bitcoin?

RR: It is interesting because from my experience with other open source projects I really prefer a hierarchical approach. It is good to have a boss. It is good to have somebody who is in charge of the project, sets the direction and makes decisions. You have these debates, should we do A or B? Which is the better way? Sometimes developers don’t agree, not everyone agrees with it. Having somebody who goes “We are going this way”, sometimes it is nice to have an answer even if you don’t agree with it. There were many times that I disagreed with Linus, not many times, but numerous times where I strongly disagreed with Linus’ decisions but he had a track record for being consistently correct far more than he was incorrect. Also he had the flexibility to change his mind if he was proven wrong later. And to some extent underneath the stuff that I maintained Linus didn’t really get override so I got to make my own architectural decisions there. I really preferred that in projects. I had a huge skepticism of projects that weren’t run with the founder carrying it along and making these calls. It does simplify governance significantly. Bitcoin obviously doesn’t have that model and it works remarkably well. I think part of that is that in practice there is a core group of Bitcoin developers who have been around for quite a long time. It will be interesting to see what happens as they retire. In the longer term they get replaced by people who haven’t been there forever. Do they have the same kind of weight in decision making? What will happen when there are huge disagreements? I think to some extent Linux was still trying to figure out how to make software. There were a whole heap of things that we take for granted now that we struggled with back in the day. How do we make this all work? How do we have maintainers? Who is in charge? All of those things have got norms now that does make some things easier. On the other hand, Bitcoin is a much more ambitious project. We are not just trying to make yet another thing like something that already exists which is basically what Linux was trying to do. We are trying to make something really new and that is much more ambitious as a project. It is going to have its own issues. But there are definitely echos. There were some crises in the early days of Linux that no one remembers now. But they were huge at the time. Massive governance crises about how things would be run or how decisions were made or big things about should we go this way or that way. They are completely water on the bridge now but at the time were hugely distressing and major crises in the project itself. I think that reassures me sometimes when we have the inevitable Bitcoin crises. Once you have been through a crisis once you have a bit more perspective over what it takes and what happens. But your first crises are always emotional and difficult because you don’t know what is going to happen. This whole thing could fall apart over this random hard fork or whatever it is. I see a similar maturity path. We’ve done this before, we kind of have a roadmap now on how this stuff happens. I do see that maturity process happening now in the Bitcoin space which is fairly reassuring. But different projects are different. Bitcoin has a whole pile of layers of things that are not directly computer science related. The whole economic side and things like that which have their own significant part. We are also in a very different time. Instead of Slashdot we’ve got Twitter and much more ferocious, almost gamed, weaponized social media and things like that. I think that makes a higher profile project that is coming into its own more difficult and more stressful for the people involved. I am slightly concerned that that will become a problem. It is not as easy as it used to be. Once it breaks out of that core group of geeks who are hacking on something and think it is cool you inevitably go through this transition where you are flooded by newbies and you get attacked. You get attacked from all these directions from people. That is just part of the process that you inevitably go through as part of mainstreaming. I think we are seeing that now. A lot more people care about money than care about software so Bitcoin’s battle is proportionally much larger I think.

MH: So with Linux and other GNU Linux type operating systems one easy solution to the governance is that you can fork off the code, create your own new project and even inherit the future progress of the other work. In Bitcoin there is seemingly the same thing, you could fork the Bitcoin Core code, change some parameters in the consensus rules and then you will spin off a new independent coin, a new network in of itself. But maybe more nuanced, we might have the same situation inside the Bitcoin network with multiple consensus clients running alongside each other. On all these three levels of analysis what do you think?

RR: The “You can always fork it” thing is more difficult as a project gets more mature independent of the whole Bitcoin specific consensus issues. A project builds up infrastructure as it goes. In the case of the Linux kernel there is infrastructure around everything now. It is part of people’s work pipelines, there is distribution. They take the code released by Linus and they do things to it, they run it through tests. This infrastructure is significant, mostly invisible to people who don’t know it but has been developed over time and ritual and has a huge number of people involved and a lot of moving parts. You simply can’t just reproduce it, you can’t just “I am going to fork the Linux kernel today” and expect to get anything. In practice it is so big that almost any fork is a non-starter. Not just because there is so much momentum. Even if Linus made some decision that 10 percent of people didn’t like, that is not enough. He’d have to really p*ss off a huge number of people. And then you would still have this massive momentum problem where all the infrastructure would have to be moved. Unless it is so bad that everyone moves it is pretty much unworkable. It would be a huge, massive disruption to restart with new infrastructure. What is interesting is this is the same argument for Bitcoin. Bitcoin has a huge amount of infrastructure, that is its head start. That is why you can’t just go “I am going to make a better Bitcoin and ship it.” We rely on that infrastructure. But similarly that means that you can’t just tweak it and expect you can go off into the sunset independent almost of the fact that there is this consensus problem that you would immediately fork off the network and you would be on your own. The question of multiple implementations is interesting because when you look at the developer priorities for Bitcoin, there is one that is above centralization. The decentralization is the second most important thing in Bitcoin. The most important thing in Bitcoin is that it works. This is nowhere seen as clearly as the decision not to have multiple independent implementations. That would be more decentralized in many ways. It would avoid this whole Bitcoin Core centralization issue. But the risk to the network is probably too great. At some stage maybe we will have a formal language that we can describe the Bitcoin consensus algorithm in and at that point you can reimplement it with a reasonable assurance that you are not going to fork off the network and mess everything up and take 30 percent of the nodes with you. But until then it is a safety question. This is one area where decentralization has taken a backseat to the practical matter of making sure that everyone stays in consensus. That is just real world engineering. There are no absolutes. You do the best you can. We don’t have a good way of doing decentralized development. As long as we are still doing development we are going to be somewhat centralized. The only way to really do decentralized is to freeze everything and say “We are never upgrading Bitcoin again.” At that point it becomes practical perhaps to have multiple independent implementations of the same thing that you can prove against each other and stuff like that. But we are definitely not there yet. I am sympathetic to the idea that we are not good enough at writing software to have independent implementations running live on the Bitcoin network in critical areas. There are other implementations but in practice if they forked off it would do very little economic harm. It certainly wouldn’t disrupt most of the network. I think it is healthy for those things to exist but I do defer to the Bitcoin Core developers who generally have the view that there are too many sharp edges and too many difficulties with trying to maintain consensus as it is with a single implementation, let alone introducing multiple implementations. There are finite resources, how many implementations can you have at the same time and keep them all up to date? If you look at the CVEs, the issue disclosures for Bitcoin Core, there is a lot of maintenance going on to just keep the ship afloat and keep it robust. Multiply that by the number of different implementations and you start to see the problem.

MH: This problem exists across multiple implementations but it also exists in one implementation across multiple versions. This makes it even more difficult.

RR: Yeah, we have multiple versions, we have multiple platforms. There have been cases in the past where 64 bit and 32 bit bitcoind’s would disagree with each other. Not to mention endian which is mostly gone now. There are always going to be these issues that we have to deal with. As you say, multiple versions. To some extent across a soft fork by definition you can fork off older versions but it shouldn’t happen under normal circumstances. Things like that have happened recently enough that people are still very nervous about upgrades and taking it very softly, softly and engineered approach to doing that on the network which I completely support, it is fantastic.

MH: Now we have set a foundation for your motivation to work in free software let’s dive a bit deeper into the Bitcoin nuances. You mentioned that you started your work out with sidechains but then eventually switched to Lightning Network. What were the downsides or trade-offs of sidechains that made you choose in favor of Lightning Network?

RR: The sidechains that I proposed developing anyway were basically custodial. You could have a quorum but basically you’d move it into a custodial system. You were taking that payoff in return for this other blockchain that would have different properties that would make it move faster and everything else. It would be good for petty cash hence the name Pettycoin. For me this was an interesting trade-off but you still have this problem that someone is literally holding your funds. You can have certain reassurances, it could be a consortium, but at some point this to me was an uncomfortable trade-off that I was never entirely happy with. Now Lightning doesn’t have that trade-off. It has trade-offs but not that one. This was the first thing that I saw that really convinced me that this kind of thing was interesting. Perhaps if Tadge (Dryja) and Joseph (Poon) who were the authors of the paper, had been determined to go implement it and they were off running, “Here is the paper and by the way our implementation is on its way” I might have let them do that and continued on Bitcoin Core. But the fact that they didn’t intend to implement it, this obviously has to exist, it is a fantastic idea, somebody needs to go implement it and make it work. This was the driving motivation to dive into Lightning. With my background in open source and open specifications it became obvious to me that we needed a spec and we needed to coordinate the different implementations. Because unlike Bitcoin we don’t have the same global consensus requirements. We set about making sure we would have multiple implementations, ideally new implementations would come along and interoperate and compete in that sense, have their niches. That was what appealed to me about the Lightning Network. But it is the same kind of goal. How do we make Bitcoin scale? Joseph Poon printed these hats, “Make Bitcoin Great Again.” It was partly a joke because of course in the early days of Bitcoin, transactions were free and everyone trusted each other so they were fast. You just zero conf through and everything else. That was never going to last. But Lightning brought these promises back, in a real way this time, not an illusion, a temporary thing. I can get this almost instant finality and I can get really fast transactions and really cheaply. When you first heard about Bitcoin it was like “This is awesome, you can send money around the world for free”. This was bringing that back. That “Make Bitcoin Great Again” thing was definitely a huge appeal.

MH: It is a lofty goal and I assume it was a monumental amount of work that you put into getting to this point where we are now. How about the differences with the Bitcoin software itself being the specification and with Lightning Network having multiple implementations that strive to do the same thing? What were different methodological approaches that you were considering to implement to coordinate all of this?

RR: I believe in the rough consensus and running code thing, the IETF model of RFCs and having people implement the RFCs, they do bake offs between themselves, they work with each other and they go forward. The way the spec process works is that you propose a change and then it has to be implemented by two independent implementations that interoperate and show they work together and not vetoed by anyone else. Then it basically becomes a formal part of the spec. That keeps you honest, you can’t just add stuff to the spec that only you have implemented. That has been incredibly useful. As we feel our way through this the three main contributors to the spec are Blockstream, originally myself and now myself, Lisa and Christian, Lightning Labs obviously and ACINQ with eclair and Phoenix. There are too many cases to mention where one of the other teams has given feedback on something and either made it significantly simpler because they saw a different way of doing it or fixed a bug or made it more generic or better. There has been a huge amount of improvement that has happened through the spec process and trying to really nail down what is supposed to happen. I have a very opinionated view on how specifications should be written and that has come through in the spec process. I originally chaired the spec meetings at 5 30am on a Tuesday Adelaide time.

MH: That’s dedication.

RR: Someone is going to get screwed. You’ve got people all over the world. It wasn’t going to clash with anything. That was the original meeting time. Fortunately the chairing now rotates so I hardly ever chair myself which is great because I can sit back and drink my coffee and try to wake up while people are discussing things. But it was important to drive that early process. The spec is designed for you to read the spec while you are implementing it. If you are reading this you will do this, this, this kind of thing. If you are writing this message you will do this, this, this. It really is supposed to be an implementation spec. This unfortunately means that the readability as far as the high level view is sometimes difficult. Those of us who work on the spec can see it all but if you just pick up the BOLTs as they are called, we love our Lightning puns, if you pick up one of them and try to read it you’ll find it a bit painful. Particularly when there are additions, the spec will say “Do this. Unless it is this case in which case do this.” That has always been a bit of tension. c-lightning is the only implementation that actually generates our code from the spec. There is a tool in the spec directory that will parse the packet descriptions in the spec and produce a simplified format in csv, comma separated fields. We have a tool that takes that generates our C code to print, create and read all the different messages. It makes it easy for when we change the spec. We quote the spec throughout our implementation which I find really useful because it also means when you are writing things if you end up implementing stuff that isn’t in the spec you think should we mention this? If everyone is going to have to do this we should probably say that in the spec. “You must do this” or “You should do this” or “Consider this” at least. We have another tool that goes through and finds those quotes and just checks that they match, ignores whitespace changes and stuff. The quotes in our source should match the quotes in the spec. When the spec gets updated we run that tool again and if there has been a change in a spec we fix up our source code. “This has changed. We should now being do this.” We do that every release generally. We are very tied to the spec process.

MH: That is very interesting. I wonder how fluent are the contributions from spec to implementation and in what flow does it go? Is it both ways?

RR: I do them both at the same time. I tend to write a first draft of the spec first. We have this whole experimental system in c-lightning where you turn experimental features on and you get all this cool stuff.

MH: Reckless mode.

RR: Yeah basically. One of the things is you then have a quote from a particular version of the spec. Normally you just say BOLT 10 and it goes “Cool I know what that is.” In this case it is bolt-git-version for specific extensions. I write the basic spec and then I implement it. There are a huge number of fixups to the spec as I write it because either I realized what I wrote was dumb or I didn’t spell it out enough, I handwaved over things, “I need to spell this out”. I always implement them together. For example splicing, I have written the first draft of the spec but I haven’t implemented it. However I cheated because most of the stuff involved in splicing…. Splicing is where you have a channel and you either want to move funds in or out onchain. You want to change the commitment transaction. You go “Hey I want to splice. I want to add this input and I want to add this output.” The other side also gets a chance to throw things in “I’ll add this output, I’ll add this input.” This negotiation of what the new onchain transaction which will spend the old channel and create a new channel atomically will look like.” That protocol of negotiation is the same one that Lisa spent so long writing for dual funding, which is the same idea. “Hey Max, let’s open a channel.” You go “Cool. I’m going to throw some inputs in as well and some outputs for change for whatever else.” Which of course is a coinjoin, this is basically a coinjoin protocol between two peers. You can already do it to create an opening transaction with c-lightning. When I’ve finished this work I’m basically reusing the exact same protocol to negotiate on a live channel, we want to reconfigure it this way. You want to take funds out or you want to put more funds in. Of course as we look further down the track and we have things like signature aggregation it becomes extremely attractive. If you have cross input signature aggregation “While you are splicing I will throw some more stuff in as well” because that becomes cheaper. Even as it is it is a good opportunity to do cleaning and everything else. Interestingly unlike a normal coinjoin you have this great ability to go “I don’t really want to make a small change output, I’ll just top up the channel, I’ll put more in the channel.” You have some interesting flexibility there which also has the great side effect of confusing onchain analysis. That is an example of spec work that’s been ongoing and gone back and forth over a year plus. Lisa going through the spec changes, implementing it and then going back to the spec and going “No that didn’t work”. Particularly because we did want it to be completely generic. You should be able to open a channel in theory at the same time as you are doing a coinjoin with someone else and have the coinjoin come out as the channel output. Your peer doesn’t know that you are doing that, you are just feeding it all these inputs and outputs from somewhere else. That ideal isn’t met there but you can definitely do multiple channel opens at once, that is the easy case. You just talk to all these peers. I tried to open a channel with everyone on testnet at once a while back. Most nodes on testnet are dead because people set them up and then drop them but I think I still ended up with something like 100 opens in a single transaction with every node. I would do it on mainnet except I can’t afford it, that would be a cool experiment if someone wants to give me a couple of Bitcoin to play with. I would happily do that as well. Developing that protocol and making all that work was a lot of back and forth. Nobody is smart enough to just write from scratch, you really have to have a first draft, try it, go back and just keep iterating until you get something you like.

MH: I see. Let’s focus on dual funding as this is very close to coinjoins. Are dual funded channels limited to a two person coinjoin or could we also have multiple people that are in that coinjoin?

RR: One side could bridge to a coinjoin. Let’s say there’s Alice, Bob and Carol, at least in theory, I haven’t implemented this. The devil is always in the detail. Bob could say “Alice, I want to open a channel” at the same time as Carol goes to Bob and goes “Hey I want to open a channel”. In theory Bob can go “Excellent. Every time Alice gives me a new input or output to add I will just tell Carol that I’m adding that one to hers and vice versa. I’ll just bridge between these two and we will all end up negotiating the same transaction in the end.” Alice will think Bob is adding a lot of inputs and outputs but whatever, who cares? Similarly Carol will think Bob is doing a lot of work. But Bob can intermediate and negotiate between the two of them and end up with this. In theory that can extend indefinitely. There could be other things going on at the same time. In this case I usually think Alice, Bob and Carol as Lightning nodes but there could be something else wanting to do a coinjoin. “I’ll be in that but I will also open a couple of channels on there.” Or conversely with splicing it is a similar thing. “I want to splice a channel. We could do a coinjoin in or we could do a coinjoin out or even a channel close.” In this new scheme a channel close eventually uses the same negotiation technique. At the moment close is basically “Give me your address, give me my address, it will have two outputs”. But it doesn’t need to be that way. “I want to close a channel with you, sure” or you say “You want to close a channel with me, great”. At the same time I’m going to use exactly the same transaction to open another channel and maybe put some funds out to cold storage and maybe do a coinjoin. The sky is the limit. It is not really limited, it is a peer to peer system so it is one party talking to another party one on one. But because they could be relaying from other parties it doesn’t necessarily mean it is just the two of them.

MH: To break down a coinjoin there are multiple inputs. These inputs can be from the channel peers but they don’t necessarily have to be. There can be inputs from non-Lightning Network users, just single public key coins, they can be the inputs in that coinjoin. Then on the output side we kind of have the same thing. We can have an output that is a Lightning channel itself, multisig pre-signed transaction construction. For this one Lightning output there are always two users that control it. This is the peer to peer aspect on the output side of the coinjoin. But again there can be other outputs that are from other users who know nothing about Lightning Network who just use single public keys as their base wallet.

RR: Absolutely, that’s exactly right. At the moment it is quite distinctive when you open a Lightning channel. It is a 2-of-2. Even if you can’t see that on the pay-to-witness-script-hash side, when it is spent, even a mutual close, you will see it is a 2-of-2, it is almost certainly a Lightning channel. Whereas with Taproot of course and MuSig that becomes indistinguishable from any other spend. In the case that the Lightning channel doesn’t break and you don’t have to unilaterally close or anything, in the normal case and you splice in or out you can’t tell. Nobody could tell it is a Lightning channel. Of course a lot of Lightning channels are public. There is another layer of information if you are looking at the Lightning Network. They will tell you “This is a Lightning channel” and in that case you know. Even for private channels that are badly named, basically unannounced channels, there are ways of probing and finding out what those channels are. This is one of the things we are working on. It is not as private as we would like. One of the steps is making it more private onchain. This would definitely win across the board. You would definitely have these octopus transactions of which you know very little.

MH: How much of additional communication has to be done to negotiate this dual funded Lighting channel? Especially in the context of coinjoin where let’s say we have 100 users getting together, there are certain timeouts for each step of the protocol that everyone has to succeed by, otherwise you will be thrown out of the coinjoin. How much extra complexity is it to negotiate these channel openings?

RR: That is a really good question. The dual funding protocol is aimed to completely displace the existing funding protocol. A dual funding protocol where one side doesn’t put anything in is basically the old one. We are switching across, everything will be “dual funded” although in many cases one side won’t put anything in. Max connects to me and says “I want a dual funded channel” and I’m like “Great, let’s do it. We are a modern protocol” and then I just don’t add any inputs or outputs and it is all you. Of course I have the option now. It is pretty fast. You basically have add input, add output, remove input, remove output. You can play around with things. Then you have a closure phase. When we both say we’re done, you may not be done yet, then we exchange the signatures on the channel transaction that’s going to get our money back if everything goes pear shaped, the unilateral close transaction. Once we’ve validated those and everything else then we exchange the proper signatures for the actual final construction that we’ve transacted. Now we’re happy we can get our money back. What is your latency like? It is a reasonably efficient protocol. As long as you’re not in Australia behind 28 layers of Tor or something and even then I still think it will be fine. I don’t see latency as being a huge issue. It would be interesting to find out what it looks like.

MH: So latency, not that much of an issue. Of course there is the online requirement but I guess that’s always assumed for both Lightning and coinjoins. One other question, do you use cryptographic blinding to enhance the privacy during the coordination of the coinjoin already?

RR: No. We looked at things like PODL for example, you would obscure the UTXO that you were offering. But at the moment the Lighting Network is not sophisticated enough and there are a number of papers showing that if you combine the information you can already tell a lot. It didn’t buy us a huge amount. PODL was in the original spec that Lisa wrote. She had a trial implementation of it. You would prove that you owned one of these outputs before I would reveal any of my outputs. You would come to me and say “I want to open a channel and I want to dual fund as well.” You would have to provide a proof to me that one of those was real and unspent. Then I would publish that out in a way that if you tried to reuse that proof for somebody else it would clash. It does complexity and it is something that is fairly easy to add later. We didn’t do that. That is a scheme that was invented for coinjoin that is kind of cool. The difference is that coinjoin gives you I think 10 different possibilities, you can have different variants of the proof so you can try 10 times with the same input. We don’t have to do that in Lightning because it is not like you can’t spend that output anymore, it is just that no one will contribute to your dual funding. You’ll have a single funded channel if you try to reuse it. Even if something goes wrong it is not useless, you’ll either have to spend another UTXO or open a normal channel that isn’t going to be dual funded. We chose to excise that from spec because the spec was already getting pretty big and we thought this is something that we can add as a requirement later when we see how things actually play out. We don’t have the same requirements in that sense. In practice you end up seeing what your peer is offering for UTXOs and you could abort at that point.

MH: I think you are spot on. If this is a two party coinjoin then obviously the other party will know which inputs you have because it is the inputs you do not have. In order to get that type of privacy protection one thing to do is to use a larger coinjoin type. Coinjoin with 100 users where 90 of them are not even Lightning users, it can become very difficult for the counterparty to find out which channel is yours. I think at that point it does make sense to add some blind cryptography like Zerolink uses Chaumian blind signatures and now Wabisabi uses key verified anonymous credentials. This can then be used to make it cryptographically not possible to find out what the input is.

RR: Yes there is a twist there that you want some spare stuff left over to put in the channel and you have to prove that you have got sufficient spare to go into the channel. Somebody brighter than me would probably have to figure out how that would all work. But certainly in future it would be interesting to see something more ambitious like that put forward. Even as a two person coinjoin the fact that the amounts don’t add up in an obvious way as a step zero is actually pretty nice for your onchain privacy.

MH: It is basically a payjoin type where two users put together their inputs. This obfuscates the payment amount but one nice thing is you can make a payjoin inside a larger coinjoin. This gives you added benefits. You keep the benefit that the sending amount is obfuscated but you make that defense even stronger because of additional inputs in the coinjoin, making the subset sum analysis much, much more difficult.

RR: Absolutely, that is a really good point. I hadn’t thought of that. One of the things I am excited about is attempting to implement payjoin in c-lightning even though it is completely outside our scope. Just because I think it is something that more people should do. Payjoin brings us to another issue we have with the Lightning Network when talking about privacy, the current way when you pay someone something, the problem of refunds. Today you give me an invoice, I pay it. You don’t necessarily know where that payment is coming from. The network isn’t as obscure as we’d like it to be but the ideal is I know where your node is because you’ve told me as part of your invoice but you don’t know where the payment comes from and you don’t care. It is not credit, you are literally holding the Bitcoin, you’re happy, you’ve got the money. You don’t need to know anything else. The problem comes of course when you want to offer me a refund. The normal way is you contact me somehow and I send you an invoice. That tells you where my node is, that’s a leak already. In practice there is a meta question of how do you know it was me. You’ve given out the preimage so you know it is paid but everyone along the route as the preimage. You can’t just go “If you’ve got the preimage I’ll assume it is you and I’ll give you a refund”. Any of the routing nodes would go “I’ve got the preimage for that, I’ll claim your refund, thank you very much.” There are ways of doing this but my preferred way of doing it is part of the offers protocol which is one of the other things that I’ve been working on. That is a second layer where an offer is basically “You should go here to request an invoice”. When you request the invoice of course you give it a payer key which is a transitory key that you can later use to prove “I was the one who requested that invoice that I paid”. This gives an obvious way to do refunds. You just sign it with your payer key and you must be the one who is after the refund. The other thing of course is rather than choosing private channels as we do today we use blinded paths which is something we’re moving to generally, slowly, in the Lightning Network. This idea that you can supply a blinded path “Here’s the thing to put in the onion at this point and it will get it to the next point”. That could be routing you through private channels that you don’t know about or could be routing you through public channels, you won’t even know. That privacy enhancement is something that people have wanted for now, vendor privacy. The model in the Lightning Network at the moment is you know where your vendor is, you have their node ID, you can route to them. While you can have an unannounced or “private” channel you announce it in the invoice so people can use it “Hey I’ve got a channel from here. It is this channel ID”. It is a small s secret. You’ve had to tell some random person who clicked your website that you’ve got this channel. It is unannounced in the gossip of the Lightning Network but it is still there. This offers a more sophisticated way of doing that. It has some upsides and some downsides. This offers layer comes with a lot of these privacy benefits that I think are really important, including practical ones that people don’t really think about like the refund problem.

Offers PR: https://github.com/lightningnetwork/lightning-rfc/pull/798

MH: That is interesting. Why do you call it an additional layer?

RR: All an offer does is send an onion message. It looks a little like an unfinished invoice. It says “I am selling this. Here is where to contact me.” What your software does is take that, send an onion message saying “Hey I would request the invoice for this offer” maybe offering some of the details and you get back the proper invoice. At that point you pay it. It is kind of a pre-step. First you contact the node and get the actual invoice and then you pay the invoice. One of the problems we have with invoices is that that preimage that they promised, “Here is the hash and I will give you the preimage if you pay” is totally not re-usable. You should not be posting invoices on Twitter. Ideally you send them to this one client and that is their invoice. That is a huge problem. There are a few interesting ways around that but there are other reasons it is nice to have this second stage. It is nice to have an invoice but having this request for invoice stage which we call an offer means that it is a static QR code. It will generate an infinite number of invoices. You can spray it on a wall, you can have a static image on your web page, all those things, and it just works. But also of course it gives you all the other cool things that you want from offers like recurring payments. The offer says “Hey this is for once a week”. It gives you currency conversion. It says “This is 5 USD”. And when you get the actual invoice it will tell you what that is in Bitcoin. In practice this is the way things work with wallets. If you are a Bitcoin maximalist it is easy. You just say “This is an invoice for whatever” but particularly for recurring payments people tend to be fixed in a currency other than Bitcoin. It is really useful to know that. The user would approve, scan an offer for once a month for 5 USD and it says to me “That is 8 Australian dollars plus or minus 10 percent each month” and I go “Yeah that’s fine”. As long as it stays within those bounds it will continue to pay it every month and request a new invoice. The fact that you have a payer key means that you can do the request for refunds and stuff like that in a much more straightforward and automated way. There is a whole reason to have a separate layer on top even though there may be other enhancements to the invoice. Having this offer format is incredibly useful. That is already spec’ed and implemented. I’m waiting for a second implementation which will basically mean that we can move forward. The other reason to have a second implementation is that it is good for someone to poke into the deep details while you are implementing it and go “Why did you go this way instead of that way? Wouldn’t it be better if we did this?” Those kinds of ideas. I’m actually really looking forward to that. The way to send people money at the moment on the Lightning Network, they send you an invoice or you just keysend to them. You just throw money into the void. I really dislike that model of throwing money. It is really good for the early days where Lightning Network is full of friends. You send people money and it is all good. When you look at serious commerce and you start thinking about what commerce looks like when there is no middleman, there is no intermediary, you really want your receipt. You really want your proof of payment. You really want to be able to prove that you did or did not make some payment. The oldest piece of writing that we have in existence is actually a receipt or maybe an invoice. There is a reason for that. When you have a cash system with no intermediaries you want a record that you’ve actually paid for something. Keysend doesn’t give you that. You throw some money and it vanishes and you go “Cool I’m assuming they decrypted it and they took the money. That is fine.” But it is terrible for paying for stuff. If you have a dispute at some point, it could be their software is buggy, you send them the money but they don’t have any record of it. The ability to prove that is actually really quite nice. In fact in the Blockstream store we’ve had at least one case where the person proved that they had paid. If they have paid they should have this information and indeed they did. At this stage in the Lightning Network’s growth that is underrated. I think we are definitely going to want that in future. The problem with the payment hash is that while I can prove that it was paid I can’t prove that I paid. You end up with the Brian problem. “I’m Brian” “I’m Brian” “I’m Brian”. Once you have revealed the payment or to anyone in the route… scriptless scripts would fix that. Once you have revealed it, “Hey I’ve got the secret” then everyone has got the secret. Whereas with a payer key you can prove without revealing the key itself, just using a signature, that I was the one who requested the invoice and prove that it was paid. It doesn’t matter who paid it, I was the one who had the invoice created.

MH: You could still share the private key with others?

RR: You absolutely could but you don’t have to. This is always true. You can always give information to everyone else. At the moment you can’t, you share that preimage to prove that you paid it and someone else can immediately tweet “I’ve got the preimage, it was actually me not him”. You don’t have this problem with a payer key. That is a really nice property to have.

MH: These offers, I think try to solve a similar problem as pay-to-endpoint or also LNURL tries to solve. To have this server address that can be reached to negotiate the payment invoice. But where does offers build even more on top of that than pay-to-endpoint or LNURL?

RR: LNURL uses a web request which is definitely a great first approach. Whereas I want to use the Lightning Network itself. There are several reasons for that. One is that not everyone has Tor, not everyone is using that. You are going to be using the Lightning Network anyway. The second one is that I want to bind it closer to the protocol. There are a lot of really cool things we can do if you don’t need to have a Tor web request or something like that, you don’t have a separate server running, your Lightning node will do this for you. I think it is the right layer to do it. Ideally it will give better privacy but it also turns out to be a useful… the fact that I can send a message through to the person I am going to be paying and get a response back, that is a really good start for my first payment. That might not work and you might go somewhere else. It is like a liveness ping. Although theoretically it is slightly higher latency, in practice it will be really useful to have that.

MH: The communication for this offer is already routed through the Lightning Network with multiple hops, those are the same hops and peers where the payment will be ultimately routed through. That is already somewhat of a probing without actually spending sats.

RR: That’s right, exactly. There is a messaging system that people have hacked on by sending fake payments through the Lightning Network but it is actually quite intensive. It uses up a reasonable amount of resource to actually tie up liquidity to do it. Whereas this is built on a much more lightweight onion message system. This is a message, this is not a payment. That is also a nice general improvement to have and pretty easy for nodes to implement. For the first one, what the implementation does is try to have a route through nodes that have those features. It will probably have a fallback by default where it will just do a direct connection. If if can’t find enough nodes that speak the new onion message protocol it will go “Screw it. Unless you have turned it off I will make my own direct connection.” This kind of defeats the point. “The new person who connected is asking me for this thing. What are the chances? It is probably them.” This might be ok if you are over Tor but that is a bootstrap mechanism until it gets rolled out widely. That’s probably how we would do it. Further down the track there are definitely things in offers that I am excited about. The recurring thing, it is hard for me to emphasize what it should look like. Everyone loves recurring payments, vendors love them for two reasons. One is that you don’t have to ask someone every month whether they want this magazine, “Do you want to pay me again?” Invoicing someone every month is just a pain in the ass. But they also love them because they are damn hard to turn off. In a Bitcoin world there are no pull payments, there are only push payments. Your wallet, you scroll across, you have the tab of all the ongoing payments you’ve got. “No stop paying that one. I’m done, that’s out.” That is the level of control that I really want to have. “I want to pay Max every week for his podcast because I think it is awesome” but I have complete control of that. I go to my wallet and go “Stop paying Max.” There is no “Revoke your access to my credit card to stop you direct debiting my account” or whatever the current arrangements. I think it will be incredibly useful. Users will really like it. Recurring payments are awesome. Vendors will like it as well, probably not as much as trapping people into their payments but certainly I think this is an approach that will definitely take off. I see your wallet becoming more of a manager of all your stuff. For example the first PR on the offers draft is a request to have compulsory fields. You’ve got to give me your shipping address, send your shipping address or send your phone number or send your email address in the case where I’m selling you an online newsletter. There are a few others like that that might be important. If that’s at a programmatic level it is easy for your wallet to say “They want your shipping address” and you go “No” or “Yes sure. I’ll send this shipping address.” It becomes like a shopping manager, here is all the stuff I’m doing. One thing that did not make it into the spec because it could be added later is the whole shopping cart in the offer. At the moment you scan the offer, you supply the information you need. The offer may say a variable quantity of these things can be ordered. You request an invoice for that one offer. In theory you could request an invoice that covers multiple offers, the shopping cart experience. Your phone scans this, scans that, scans that. At the end go “Send it”. It would say “Hey I have a request for the following offers and here is all the details.” That would be a fairly extension to add and it would overcome that back and forth shopping experience. You can simulate that without it because Lightning fees were so cheap but in theory it would be more efficient for you to have one payment that covers an arbitrary number of things. In some cases it may matter. I don’t want the nuts without the bolts. I want either both to succeed or both to fail. I don’t want to order one and pay, go to the next one and pay and it go “Sorry we are out”. In some cases it is quite useful functionality. But again it can be added to the spec later and the spec already has significant meat on it. The spec is called BOLT 12. BOLT 11 is the current invoice spec and BOLT 12 is the update that builds in offers and things like that.

MH: Fascinating. I think recurring payments are really a kicker in making Lightning even more amazing than it already is. I see it because this podcast is hooked to the Podcasting 2.0 namespace and it has my Lightning node in the RSS feed. I do receive payments from crazy listeners who actually like and enjoy the show. This is absolutely fantastic. I myself as a listener too am spending way too many satoshis to other podcasters that produce amazing content. It is a spending trap as well. One of the things that I really notice is that transaction batching makes a lot of sense. Especially when it is small value, recurring payments like 10 satoshis every minute. One transaction per minute is already pushing it. When you send very low satoshi amounts your percentage fee rate also increases. There is a financial incentive for transaction batching. I would argue that there is a security incentive, at least for now with the current Lightning channel update mechanisms where you have to keep some information for every single payment that you make. You want to make less payments so you don’t have to keep gigabytes of backup data that constantly need to be updated.

RR: In practice the information you have to keep for old payments is pretty low. There is some but it is not quite that bad. Different implementations do it differently but the lightningd implementation is pretty efficient. If you are dribbling sats out every minute you will start finding that for small numbers of sats fees will start to bite. The current range for fees is probably 1 percent or less. Once you start kicking through that threshold is this worth it? The problem is if you are paying for something that is genuinely 1 per minute that is hard. There is quite a detailed section on recurrence because it is actually quite a hard problem, how you define it. One of the things you can specify is a pay window. If you think of payments as periods, once a week, once a minute, whatever it is. When do you pay for the second period? You have to wait for it has started? The default is that you can pay for period n in period n-1 or during period n. You can pay for period 0 and then 1 immediately. But also the invoice can specify “Here’s your window where you can actually legitimately pay for this.” You can make that window really huge allowing them to pay into the future. You can pay way in advance if you want. Often you don’t want that but for something where it is every minute it does potentially make a lot more sense if you can pay all the way through this. That would be an obvious consequence if you had this batching mechanism. “I’ll pay this invoice and I want to pay periods 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 all at once”. That would naturally fall out from that flow which would be cool, I hadn’t thought of that before. I am still not tempted to add it to the spec Max because it is already getting too big. I want people to implement it as it is.

RR: We have a mechanism in Lightning for doing extensions. This is a mechanism that I stole from the Linux kernel, the ext2 file system with a slight twist. Basically you have these feature bits everywhere. The rule is it is ok to be odd. The odd feature bits, if you don’t understand one of those you can just ignore it. But if you see an even feature bit you don’t understand you’ve got to go “No I don’t get this. I can’t do anything with this.” This gives us a really good way of doing either backwards compatible or non backwards compatible upgrades. When we add a new feature we go “Cool, here is the new feature. It gets a pair of bits, an optional one and a compulsory one”. You start by using the optional one and you fall back if they don’t negotiate with the same bit. “They don’t understand this, we’ll do it the old school way.” At some point you can go “We are no longer supporting the old style” and you set that bit to compulsory. Everyone who supports it goes “Cool that is fine, I understand that bit”. Those that don’t go “I’ve got this unknown bit 18, I don’t know what that means”. The idea is that people can Google “What is unknown bit 18?” “This is new whatever. You’ve got to update beyond version 7” or whatever it is. We’ve used that generally throughout the Lightning process. The other it is ok to be odd rule is that we have numbered fields inside our messages. If you see an odd field you don’t understand that is fine. But if you see an even one you don’t understand that is an error and you should never have gotten there. Similarly we can add these optional things later on and you go “I didn’t understand that, that’s fine”. Or later on you turn it on and “If you are using an obsolete client it is time to upgrade”. That is why I can be a little bit handwavey about we can do that later. As long as it is not going to be a massive rewrite. I am always wary of predicting the future. I want to see people using it, I want to see them out there trying things and see what works, what takes off, what becomes the big thing that people want. Then “That goes to the top of our priority list, we should definitely do that extension”. Or maybe it is never an issue. Maybe in practice podcasts use once every 5 minutes and that is good enough. Fees are low enough that no one ever complains and you are done.

MH: Is there a way to give a discount if you make a lot of payments in advance?

RR: Yes. The way the offer spec is that the offer itself has a description and optionally an amount. For a lot of cases the offer itself will say “This is the cost”. In some cases not, it is an open ended offer “Send me some money”. But normally “This is the cost and optionally here is a quantity” and you choose a quantity. But the actual amount only comes at the invoice phase. But say “I like Max, I am going to give him a 10 percent tip”. In the invoice request I include an amount which is greater than the amount you want. You go “Great, that is what you are getting in the invoice then. Fantastic, thank you”. But you can do it the other way too. I send you “I want this offer. It would normally be this”. You can do two things. One is you can set the amount to whatever you want. If you want to give me a 10 percent discount for whatever. The other thing is you are allowed to change the description, there is a strong recommendation that you only append a description because wallets will expect that. That special case is handled. The description would be “Max’s podcast subscription” or some item that you might buy in bulk “A kilogram of coffee” and I’ve ordered 10 kilograms. You change the description in the invoice to “1 kilogram of coffee (10 percent discount for greater than 5 kilograms)”. You append the description. On my end my wallet goes “Cool they appended this to the description” and shows the user. You change the price as well but you can also provide feedback in the description. It can go the other way too. It could be “You’ve given me your shipping address. I have got to add that because you are in Australia. I am going to add 1300 dollars for shipping”. There is a mechanism to both modify the mechanism which tells them why and change the amount. That is why two steps is useful.

MH: Both discounts and tips, absolutely. This is a similar thing to what BTCPay Server does right now and things like LNURL. But it is all done inside the Lightning node itself. What are some ways that you would as a user interface with these features to create these offers?

RR: Our implementation is all command line because I suck as GUIs. You create an offer, you can say optional recurrence and set up all these things. The default plugin will automatically… You can disable offers as well, you can turn them off obviously. It will automatically turn the requests into invoices and things like that. It will link them back to the list of invoices. You will be able to see this is about that offer. It is not too bad, it is a little bit tricky if you have to specify your recurrence. It is every week or every 3 days or whatever it is. Recurring offers are a little bit more complicated to specify. They are generally not too bad. When I say recurrence it is tricky. There is a standard recurrence which is when you first send me the invoice request for period 0, that is the start period. But other things are fixed to a calendar. There are 12 of these things. The first one is January 1st etc. You can come in midway but you are not at period 0, if you come in March you are going to get the March one. Then there is a further twist, if you come halfway through a period do you pay for all of it or do you pay proportional to how much is left? This is a common thing so there is a bit for that. There is some complexity if you start getting right down into the weeds with that stuff but generally it is just a matter of typing “Here is the description of the item”. We have a vendor field now which was a mistake in BOLT 11. It has a description field that people put the vendor in there, who is selling. No, that is supposed to be a description of what they are paying for not who they are paying. It turns out that in many countries to be a legal tax receipt it has to have a vendor field and an amount and a date and things like that. A vendor field was an addition that made perfect sense. Now there is a vendor field.

MH: That is fun because in Wasabi there is mandatory labelling for onchain transactions. This is not Lightning but same concept. For each address you provide a label. The idea here is to write who knows about this address, who knows that this address belongs to you? Who can make that link? Who is the observer of this address? But people often “misuse” this feature to be the reason for payment. “I bought pizza” instead of “From Bob”. It is interesting that you have the same problems but good to hear that you now have it fixed with the vendor field.

RR: The vendor field is a really nice addition. Of course the spec says you should put a meaningful description in there. It is probably the most violated part of the spec that I’m aware of. Hopefully we will move to something more useful. The other thing that was considered is that there is a reverse description, a payer note. Sometimes the person paying it wants something put in the invoice. The classic thing would be an offer that is basically just a tip jar. An offer that doesn’t have an amount on it. “Give me money.” The description might be “Give me money”. But the person who is actually paying it might want to say what it is for. “This is for episode 21, I thought it was fantastic.” They shouldn’t be allowed to set the description because the description is basically what the money is for. That would be hilarious if you created something and we changed the protocol so the person paying the offer could say “Set the description to this because you don’t care what it is” and I set it to “Sale of ICBM missiles” or something. You’ve signed this invoice to say you’re selling me this stuff. Having a separate user payment field that annotates. But then you end up with this problem that you’ve got to make it very clear in the UI this is something that the vendor will see. You end up with that UX problem. This is your private note for what this is for versus this is something that you are sharing with the vendor. Like anything UX problems are as much a part of refining this stuff as anything else.

MH: It is a privacy sensitive topic. Good to have this two way communication, that is essential.

RR: Interestingly, you mentioned privacy, one of the other things is that one mistake we made with BOLT 11… I made many mistakes with BOLT11. I wrote BOLT11 in a weekend because we needed something to specify invoices. It had some interesting ideas in it and others that haven’t worked so well and we’ve learnt from that, BOLT12 does things better. The signature in BOLT11 is a linear signature of the entire thing after encoding, which is even worse. Whereas the signature in BOLT12 is a signature of the Merkle tree with additional nodes put in so you can obfuscate parts of the invoice. I can share a fully signed invoice with you but omit fields. You can still validate the signature but I can prove to you that I have an invoice from Max that offers me this at this date but doesn’t show my shipping address, my description, the routing hints etc. I can selectively reveal. This is one reason I wanted to break up the shipping address too. I want to be able to show “He shipped to Australia” but not necessarily reveal my home address when I’m sharing it with people. Another interesting vector that we didn’t consider at all in BOLT11 is outsourcing payment. If you are using Strike to pay for stuff you are giving them your invoice. They don’t technically need your invoice, they just need the payment part. They don’t care about the description of what it is you are paying for but it is altogether at the moment. You can’t give them parts of it and not everything when there is technically no reason we couldn’t do that with BOLT12. Your wallet has all the stuff but it only sends to them a version with the stubs for the Merkle tree parts they don’t need. They don’t have a description of what it is for, they don’t have a description for shipping address or other things that are nothing to do with them. That is a nice to have. It is possible to write a bouncer that would take an invoice and produce another invoice and then route it through. I started writing one in Rust and I am not very good at Rust. It was like a “I should learn Rust while I do this” and as a result I neither learned Rust nor finished the plugin. I should get back to that and do that in my copious free time.

MH: Soon.

RR: Two weeks.

MH: I think both UX and security or privacy improvement to Lightning, on many fronts that is awesome. One thing I am still curious about is what happens if I set up a recurring payment as the sender and then my node goes offline for a while? I come back at a later point. How is the time that I was not online being handled?

RR: You can’t currently get an invoice for period n+1 until you’ve paid period n. It is a serial set of periods. It depends on what it is. For some things there is no particular reason that you have to do 0, 1, 2, 3, 4, 5, 6, 7, 8, 9. You can just create a new payer ID and start again with your recurrence, that’s fine, that’s easy. But if you specifically want a series of payments and you want them all linked then you can’t go offline for more than 1 valid payment period. You have a little bit of slack there because by default during period 3 you can pay for period 3 and period 4. You could be a little bit ahead. This is fundamental. If you are not online you can’t make your recurring payments. That’s a feature of any push system. You have to be deliberately pushing your payments, there is no way to pull it. That said, in a offer they could say there is a pay window and let you pay later if they wanted to, if this becomes a problem. The payment period is really wide. Generally you don’t want that though because if you’ve missed it you don’t want to pay for it. It depends on how it works out. It has been suggested that for some things recurrence shouldn’t be by time, it should be by something else. But specifying that is a complete nightmare. What if you pay per byte? That’s a really hard thing to define in a specification. I would like to see how people use it before I get too creative. The current recurrence stuff is very much based on concrete use cases that I could come up with from the real world. It will be really interesting to see what people do in different directions and the way they push this. That is one thing that happens. Lightning on the low level, there is all this stuff, and then people on the layers above invent this new stuff. That is great, it is great that LNURL solved a problem that needed to be solved. But it is also nice to pull that into a real spec, let’s think about how we would ideally solve this assuming that we can change anything that we want on the Lightning Network. Those who are not actually doing a Lightning implementation have very little visibility into what is going on with the specs. That is disappointing because there is some pretty cool stuff in there that is not completely unapproachable that I think would benefit from more review and wider review. I am hoping that things like offers will get people on the upper layers sit up and say “I read the offers spec and it was readable and it made sense. I can give meaningful feedback, here is what I want to do. How should I do it? What is the best way of doing this?” That is one of the exciting things for me, seeing people take it, run with it and trip over the nasty edges and go “We need an extension here because it doesn’t do this”. Or other things I might simply have never thought of. Tipping for example, Australians don’t tip, it is not a thing in our culture. But it turns out this is not something that you can implement later because it is really important and considered a fundamental of any payment system in some cultures. Having a way of handling that from the initial thing was actually surprisingly important, that was one of the first pieces of feedback that I got for example. I definitely look forward to that.

MH: What about split payments? That is one of the nice things I like about Podcasting 2.0, I can specify multiple Lightning node public keys with a percentage. “50 percent goes to me as the show host, 30 percent to the guest, 20 percent to the editor” for example. How about including that in offers?

RR: You can’t really do that. You can’t get a receipt and both have a single payment. Not without doing some really clever tricks. Either you want to do really clever tricks at the protocol level so that you have a front end that pays the back ends, I pay a payment to you and you are splitting it behind the scenes, that requires Lightning level infrastructure which is definitely something that we should really be looking back. For example you can’t redeem the payment without getting secrets from them as well. That would be pretty cool. The other way of doing it is “The only way you can route a payment to me is go through this path where this path covers the other people who are being paid.” They will take their cut out of the payment as it goes through which is the other way of doing it. That’s better than putting it on the front end and going “You should make these 3 payments”. That kind of works but it is not atomic. What happens if I can’t reach one of them? I pay the others, what do I do with the rest of the money? Do I keep it? Do I try to pay it later? When you go to reconcile you go “Hold on, you are screwing me. I didn’t get my 10 percent of what you got. How did that work?” It is not even conceptually a single offer if you are doing it as 3 separate, completely independent payments. You could put it in an offer but then you have to make 3 requests for separate invoices, roll them together. I’d have to think about that one because it is hard to see how that would work. If that becomes a common use case then you could definitely have multiple node IDs in a single offer. It would be like “You should ask these 3”. I would basically go “I want to send a dollar” and you would presumably send me an invoice for 80 cents, in Bitcoin, 80 sats. One of the other nodes would send me one for 15 and one of the other ones would send me one for 5. I would check that they added up correctly. I’d go “Cool, you’ve sorted that out yourself, that is fine. We are going to spread it out”. That is a trivial addition to the spec, we just change the field to allow for more than one node ID. No it’s not… Because we need more than one route hint. Not quite a trivial addition to the spec but it is certainly a possible addition to the spec to allow multiple things at once.

MH: It is one of the features that I really love. The idea that we can reward an entire supply chain automatically. For example one way that this is used in podcast index or Podcasting 2.0 is that the wallet creators get paid. If you use the Breez wallet to listen to podcasts and make payments or donations then 5 percent of those go to the Breez software developers and 1 percent goes to podcastindex.org which is somewhat of an aggregator. This can reward the entire supply chain if used nicely and correctly. I think there is quite a lot of potential.

RR: Interesting. For me the important thing there is always visibility. I said before about the problem of without coordination I can’t reach everyone. On the other hand it is pretty transparent to have it all on the user side. It is up to the user. You say to the user “Here is the default” and they screw with their software and they pay different amounts. That’s life. But it does allow you to express a preference there. The problem is of course you are dealing with multiple payments now instead of a single one. There are ways around that, you can route things through potentially multiple points and drop things. But at the moment that would just look like a really weird fee. They wouldn’t have any trace in their system that it was for a particular thing. There is nothing more sophisticated there. I am going to have to think about that case. I do agree that it is nice in that case to have this multiple receiver idea. I was thinking about extending to have multiple things from a single node rather than having multiple nodes. I am definitely going to have to go away and sleep on that one to see what I come up with. It is certainly a fascinating use case.

MH: Can you walk me through why atomic multipath payments would not work for that? We can build multiple routes to the same receiver so that all routes only get settled if all of them get settled. Why does that not work when we send to multiple receivers?

RR: This is what I was referring to before. If each receiver is coordinating, they go “Hey I have part of this payment, do you have part of this payment?” and they all go “Yes I do”. Then they can exchange secrets and all accept at once. They can do that anyway on the backend but it requires more backend infrastructure. These nodes have to be talking to each other to say “Hey have you got your 10 percent locked in? Great, I’ve got mine, let’s go, let’s grab it all”. You could but at that point is almost easier to go “Why don’t you in a future invoice format using scriptless scripts, handwave…”. You have a pre-agreement with your two nodes to go “I will give you this payment in a percentage and you will give me the secret”. Then you just present a single invoice and you spray it out from your node to them. That maybe easier. The interesting thing about AMP actually is that there is nothing stopping you from having multiple separate payers. Multipart payments, this hasn’t been realized or implemented by anyone I know of yet, you don’t have to have the same node making all the payments. If you want to split a bill with MPP it is trivial. You only send part of the bits. You send your part, I send my part, we do it at the same time. As long as the recipient gets all of them close enough together it can take all of those. You can do bill splitting today in the Lightning Network. Somebody has to write the code to do it, coordinate between the wallets and go “We’re ready to pay the invoice. Here is how much I’m paying, here is how much you’re paying. Let’s go”. All that sharing stuff. But in theory that infrastructure already exists. This is on the other end, this is multiple payers so they can collect atomically. That requires similar infrastructure but on the receiving end. Is that a worse or better case? If one of them is offline you don’t get your money? Or is it a better payment case for the payer to go “I tried to pay the 3 of you but only 2 of you were online”. Maybe the wallet retries later or something.

MH: The way that I think this is implemented in Breez right now is that if one party is offline that party does not receive his percentage. The others still get their percentage. The user ends up sending less satoshis.

RR: Which I think makes perfect sense, “Get your s*** together, get yourself online”.

MH: The other parties don’t get the amounts that the other person would have gotten which also makes sense. This is a nice hacky solution that works. But I think with more thinking and more implementation there could be some cool things done. Also considering privacy because this is somewhat analogous to coinjoin. We merge transaction graphs for both the sender and receiver. There are multiple senders in the transaction and multiple receivers in the transaction. Having this type of split sender and split receiver, it is very different but it is similar in some analogies.

RR: Particularly if you had a system where your wallet would drop payment on the way through. You would pay it in a large fee. There is something in the onion to tell them what it is for. That is definitely a possibility. I am trying to think whether you can use scriptless scripts to do decorrelation and get some magic there. I don’t think so. As long as the final recipient accepts it you will get your tip. Maybe if that doesn’t work then I retry and pay you directly. Potentially it is an optimization. Rather than doing multiple payments you go “I can actually route more cheaply than routing to all three of these. I can route through A to get to B and do one big payment in that way”. That would be cool. In that case I would not have proof of payment that I paid A however. The only proof will be that B got the payment. There is a potential issue there. Again it depends. If A and B have an agreement where they will fee split… When I thought about this originally I was thinking that A wants to take 10 percent, A is your agent. Everything that pays to B has to go through A and A is going to take 10 percent. Behind the scenes when B gets the receipt “I’ve got this payment coming in”, they would ping A and go “You are holding 10 percent of this?” They would go “Yes I am” or “No I’m not”. If it is no then “I’m not touching it then because you haven’t paid my agent”. If they are they go “Great not a problem”. That solves your problem because then you go “B accepted the payment so it is up to them to make sure that they paid their agent. That is how it is supposed to work”. I no longer have this problem, I can simply drop a payment on the way through. In more complex scenarios where you are paying 3 people you start to go “I am not sure I want to have this payment winding its way through the Lightning Network and multiple points of failure.” In that case you can’t handle A being down. You’ve told them “No all payments must go through this”. I don’t think that is acceptable. For something like this I don’t think that’s the right solution. Just make 3 payments, maybe with an optional optimization to drop things on the way if you can. I think your base is going to be make 3 payments at once.

MH: Is it possible to add a regular onchain address, single pubkey, as a fallback to a Lightning offer in the case that the Lightning node is offline?

RR: No it can be added to an invoice but you need to get the offer into an invoice. In the same way we have fallbacks for BOLT11 invoices we have fallbacks for BOLT12 invoices, it is the same thing. An offer is generally not mappable straight to an invoice without talking to them because it doesn’t have the payment hash for a start. That’s probably the key one. If they are really offline you can’t get the invoice out of them. Another thing you’ve got from the spec is the ability to redirect and say “Hi I have a signature here proving an authorization from the node you are trying to talk to saying I can give you an invoice instead”. It helps if you are doing migration, Company A buys out Company B but they still want to accept all Company B’s offers and stuff like that. You have things that redirect. “Here is your offer, that’s obsolete” or “Yes we can redirect all of it, here is the signature”. Future infrastructure could allow you to do things like this. You would have someone who would issue those things on your behalf if you were offline. Now obviously that would be something of a trust issue at that point. The node would have had to have signed something saying “Yes they are authorized” or “They are authorized for this particular offer or some subset”. That is the way it would probably go forward. Because again if someone else can take your payment then what is your receipt actually worth? I paid someone but that doesn’t oblige me to anything. There is a natural tension there between “I need your actual signature on it” which means you have to be online in some sense. You could pre-generate a whole pile of these and leave them with someone. But in order to then accept the payment they are going to need to know the preimage. Again that becomes a trust issue. To actually take the money on your behalf, you need to trust them to some extent. There are things we can work around the edges but the fundamental assumption of the Lightning Network is that you will in some sense be online to receive payments. I think you or your agent will be online to accept payments. I don’t see how that can change if you want from the vendor a proof that you paid.

MH: Does the offer also include some form of communication about opening a new channel?

RR: No I didn’t do that although it is a really common thing to do at the moment. I think that will fade in the long term. Lisa will probably be talking about this next month. There is already a “will fund for food”. It is a bit that was proposed in the Adelaide summit, now over two years ago. It is dual funding where you say “Here is my rate card. For this rate I will fund a transaction for you.” That goes out on the network as part of your node announced gossip. People connect and go “I want to pay you to open a channel with me”. I think that open marketplace will end up taking over that whole boutique offer thing. If you want someone to open a channel with you, you will pay for that. I think that’s a more logical way to do it. The only case where that’s an exception is if I don’t have any Lightning funds. Then how do I pay you to open a channel to me? The answer is get some Lightning funds. Increasingly that is getting easier. More people are on Lightning so you don’t really have that bootstrap problem of “I’ve only got onchain Bitcoin and I need to get capacity”. I think that need will be a boutique thing but I could be wrong. Maybe that is a big thing in which case it is easy to add a future bit saying “This is a representation for a channel open as part of the offer”.

MH: We still have a very small amount of Bitcoin users compared to global population. A tiny fraction of Bitcoin users are also Lightning users. I do think we will have a massive of onboarding still left. Maybe it is worth considering.

RR: Onboarding won’t come from Bitcoin users, onboarding will come direct. The real big onboarding will be that way. It won’t be people opening their cold storage in order to go onto the Lightning Network. I don’t think that is how it is going to happen. Predicting the future is dangerous but I think we will see things like Strike, most people will come direct from fiat to Lightning.

MH: Leapfrogging.

RR: It won’t go through Bitcoin. I see people setting up stuff on Lightning, becoming successful, having lots of incoming and then going “I’ve got way too much capacity. I need to bleed some of this off to my cold storage. I need to learn about cold storage, here’s a Trezor or a Coldcard”. That’s where you should be sending the funds. I definitely see people going that way but if Lightning is being built just for the Bitcoin community then that is thinking too small. The current narrative in the Bitcoin world is very much store of value, HODL and everything else. This harkens back to a very different narrative which is about spending, borderless payments and stuff like that. I think it has always been there but certainly isn’t the emphasis at the moment. I think naturally you get a HODL store of value turning into a “Now I actually have too much and I need to spend some for some reason”. Then the Lightning Network is ready for you at that point. But I still think we are probably going to see this going straight onto Lightning migration which I think is cool. I feel that our struggling with “I have Bitcoin but I don’t have Lightning” is a very small subset of the population.

MH: How do you envision for a complete new user, has no satoshis at all, he wants to first receive Bitcoin in the Lightning Network, how do you do that in the future?

RR: Phoenix Wallet does this today. They basically open a channel on demand. To some extent that is trusted because you are trusting them to open a channel with you as part of the receipt of payment. But it is a reasonable UX bridge to get you across that whole initial delay. But I do think in the short term there will be the classic buying users model. People will fund channels to you because they want you as a user. Some of that will come out of exchanges and other things like that. We will create a channel to you. I have always liked the introduce a friend thing. I did that with Bitcoin, someone was interested in Bitcoin, I’d set them up with a wallet and give them 5 dollars of Bitcoin. We’ve got the pieces in place to have a similar experience with QR codes. The fund a friend model. Trivially of course I can set you up with a Lightning wallet and I can open a channel to you but my phone may not be the greatest Lightning node that you want to connect to. So the ability to fund a channel for you from someone else for 5 dollars or something would be useful. We have the pieces but it would be UX and scanning QR codes to make it a standard and make it work. It has kind of pushed into the background because of things like Phoenix where wallets will open a channel to you on demand and hope that the fact that you’re receiving a payment implies that you are going to be using the Lightning Network. When you first install the app they don’t open the channel to you. They do it when you receive the payment or send a payment. At this point you are serious and they start funding that channel. I think there will be some of that happening but it will be interesting to see that roll out. I do think there will be a certain amount of buying users by eating the cost of funding the channel to them in the early days.

MH: I am very curious how this will further evolve if we really have Lightning Network inbuilt channel opening, the fee rate that people offer or charge. That will change the equation quite a lot.

RR: Absolutely, that will be really interesting. I don’t want to steal Lisa’s thunder on this as I know she’s working on it right now. I am hoping that she will make a big splash when she’s got an implementation of that and the spec out. I think an open marketplace for that is going to be a real game changer.

MH: Back to offers. What about HODL invoices? They are somewhat of a cool functionality but always seem to be a bit hacky. Is that feature more adequately satisfied with offers?

RR: HODL invoices are a plague on the network and will eventually be banned, it is pretty clear. They are basically holding up liquidity for an indefinite amount of time. That is a spam attack waiting to happen. We’ve supported them in c-lightning. We have a hook (invoice_payment) where you can delay things for as long as you want while you sort stuff out. For a technical reason you often want to do just-in-time invoicing or something. Just because I have offered you an invoice doesn’t mean I am ready to take you money. At the point that I accept your money I want to make sure the backend is ready and I actually have the stock, stuff like that. That’s why I put it in, it is a useful thing to have. But this whole “We’ll wait while something happens” this has been under discussion for quite some time, how we handle spam on the Lightning Network. It seems whatever method we end up using will end up meaning you can’t just have a HODL invoice that you hold for longer than some fairly short period of time I imagine. A minute or so. Beyond that penalties will start to apply. Of course everything is negotiable. One option would be to send a small payment through that flags “There is this other associated payment that is going to come through. It is going to be high latency, it could be open for a hour”. You prepay fees, you send two payments. A small one and once that has gone through everyone is like “I am happy to hold that liquidity for you for a hour if you want”. Then you could send your HODL invoice and there would be no penalty. There will be a mechanism of doing this kind of thing. But as a rule of thumb if your business model is counting on HODL invoices today get ready because at some point the network will start banning them. I think I said the exact same thing at my talk at Berlin. There’s this ability to indefinitely delay accepting a payment, at some point it becomes an attack on the network that we are going to have to address. Offers doesn’t specifically grant you anything to do with HODL invoices but you could do them the same way you could do before.

Antoine Riard on Taproot and Lightning: https://btctranscripts.com/advancing-bitcoin/2020/2020-02-06-antoine-riard-taproot-lightning/

MH: One thing that I would like to hear your thoughts on as well is how Taproot can improve the Lightning Network. I think the obvious ones, we’ve already talked about them at Join the Wasabikas podcast in the past, MuSig will aggregate multisignatures to look like single signatures and adaptor signatures will make hash timelocked contracts look also like public keys and signatures basically. What do you think about these two improvements with Taproot?

RR: Hash timelocked looking like normal… where they fail and timeout you still end up going to the script path and it is pretty obvious. I don’t think they’ll be well obscured in the Lightning case if you have multiple of them. It will still look like a weird pattern I think, we’ll have to see. The ability to have a multisig look like a single sig is key, that wipes out a whole heap of differentiators which is awesome. The other one is payment decorrelation. At the moment an invoice says “I will give you the preimage to the thing that hashes to this” and that is literally the contract you sign in hash timelocked contracts. The problem is it is the same contract across the network. If you go through Alice, Bob, Carol, Dave, all of them can trivially correlate the payment because it is for the same preimage. It is literally the same HTLC going through. If we switch to using points or scriptless scripts then you can tweak them at every point. If Alice and Carol are run by the same person and they are trying to correlate payments, at the moment it is trivial “This is the same payment going through”. But with scriptless scripts you can have a tweak at every point, it can be a random tweak. If you don’t see every single hop you can’t trivially tell using the preimage. You can just tell that it is after this point but I can’t tell this is the same point that was asked two hops back. Of course there is still timing, there is still the amount, there is still the delay that is left. There are other things that you can do, some statistical analysis and you can figure it out. But it is certainly not the trivial thing that it was or is at the moment. We call that payment decorrelation because it is decorrelated across the path. The other cute thing is that with MPP, multipath payments, you can obscure it in different ways as well. People have talked about doing this weird ass MPP where your nodes will actually split payments for you or combine them back them again to obscure the amounts more. That is a lot of engineering and I don’t know how much we’d gain out of that. But certainly the payment decorrelation is something we’ve talked about from the beginning, I think was discussed in Milan, the very first Lightning summit. That is something that we’ve wanted for a long time. Just that alone will make us feel a little bit better about our privacy for payments across the network.

MH: One of the other improvements that I would really like to dig down on, especially because you mentioned previously that the “private” non-announced channels certainly can be improved in privacy by quite a lot. What do you think about these ideas to use Schnorr ring signatures to prove the channel? Can you explain how that idea works?

RR: I can vaguely from a high level. At the moment to announce to the network that you have a channel that can be used routing you prove that you own a particular UTXO. In theory it is a privacy leak, it would be nice if you could just say “I have some capacity” and that’s it. The reason that we tie it to a channel is simply anti-spam. You have to have some money on the Bitcoin network, you announce across the Lightning Network. All the hard cases in Lightning we offload to the Bitcoin network. Your channel has problems, your peer is about to timeout, you go onto the Bitcoin network. We do the same thing for our gossip. For example you can’t announce a node without a channel and you can’t announce a channel without proving you own a UTXO. There you go, that solves our spam problem. Unfortunately proving that you own some subset of UTXOs doesn’t do it for you because you can’t constrain that. If I prove to you that I own a UTXO in this block, as far as I can tell you can produce an infinite number of proofs that you own a UTXO in that block, more than there are UTXOs in that block, and use that to spam the network. So it doesn’t actually benefit us in that way. Are there other ways that we could anti-spam? Quite possibly. We could require some kind of different proof perhaps or simply use other techniques. Sure you need one channel but then you can announce other channels without actually revealing anything else or something like that. But to some extent we shortcut a whole heap of spam problems by requiring you to prove onchain ownership at the beginning. There is a secondary reason. Because we all have this blockchain that we all share it is a really compact way to refer to something because you can say “This block, this transaction, this output” and that uniquely identifies a particular channel. We can fit it quite neatly in 64 bits and that makes our gossip more efficient and things like that. That’s the other reason but it is secondary to the fact that we use it for anti-spam. There are ideas on getting rid of it but nobody has come up with a good way of doing it and still stopping people from spamming the network.

MH: That is an interesting trade-off that I did not articulate before. Is the channel outpoint also used in the creation of the route from the sender?

RR: Yes. You literally say “Here is the next hop” and you express it as the outpoint. There is a proposal to allow you to do a node ID as well. It is basically an alias for the node ID. But the node ID is bigger which was originally a concern. These days with our variable size onion probably isn’t. In fact onion messages explicitly can use either. You can specify the next hop either as a short channel ID or as a node ID. The short channel ID is shorthand for where you want it to go next. The short channel ID is the outpoint, it is literally the block number, the transaction number within that block and the output number in that transaction.

MH: Even if we have these Schnorr ring signatures to prove that we own some of these outputs, how could you create a route through this node if you don’t know exactly which outpoint they have?

RR: You would just specify “Get this payment to the next hop and that’s this node ID”. Presumably it would have said “I have a channel to this other node”, you need that for routing but you wouldn’t know anything about it other than what they tell you.

MH: The sender tells the routes to send the money to that other node but the sender does not need to tell the routing node through which exact channel that has to be done.

RR: That is true today actually, you can have multiple redundant channels between two nodes. They specify one of them but you just use that to indicate which direction you are going, you don’t have to obey it. They can’t tell. It is just a shorthand for the next node ID.

MH: What do you think is missing before we can have more private channels?

RR: There are a couple of things of privacy, quite a lot. We need this and we have a spec for this blinded path. The idea with a blinded path is that I provide you with these encrypted things to put in the onion and you have to lay these in the onion. That is only decryptable by that particular node. It decrypts it and goes “I know where this is going next”. You have to put these in. It is specifically implemented so that if you skip one of them it doesn’t work. There are tricks here of course. If you hand out one of these things in your invoice “You must use these encrypted secrets to get to me”, whoever me is, I am hiding behind this shield. You have to obviously not accept it if they try to use that invoice in the clear or through any method other than the one you specified. If it didn’t come with that encrypted blob because each one rolls, this one will decrypt to the next one to the next one. You can tell that they used this properly. If they do anything else you obviously pretend that you don’t know it. Otherwise they can probe and go “I wonder if it was Max who sent me this invoice”. They send it to you in the clear and say “Hey can I pay this invoice?” and you go “Sure” and it is obviously you. There are a few tricks in that implementation but it is not too bad. I have a draft implementation of that as well and Eclair are looking at it too. We have to do some more checks on the crypto side. That is key for vendor privacy.

MH: A quick aside here. This is basically rendezvous routing for the entire route? Or it is a more holistic approach than rendezvous routing?

RR: This is separate. This is hiding the vendor, the person you are going to. At the moment you say “Hey I have this private channel from this dude” or even a series of private channels in theory. You can say “Here is a route to use to get to me” but you still know who I am and that leaks a reasonable amount of information as well. This is like “Here is an encrypted path to get to me” and ideally what will happen in future is that we would disallow routing through unannounced channels unless you are using an encrypted path. Because that encrypted path could only have come from the person at the end of the path basically. Then we can cut off that hole at the moment where you can try to probe through. “This might be your channel that I am trying to probe through and detect it”. That’s required for having vendor privacy. For the sender privacy, trampoline routing or rendezvous routing solves a slightly different thing. Normally your node looks across the network and goes “How do I get this to wherever?” Even in the case of vendor privacy the vendor path ends up at some node and I have to get it to that node and then use my encrypted path to get through. Or if I am sending out it to some node I need to get there. For light nodes they often don’t have enough information to know the whole routing table. Certainly as Lightning grows that is going to be more and more difficult. Particularly in the case of a mobile app, the Eclair guys talk about this really well. Basically people open the app and send a payment. But when you open the app it starts trying to sync the network and get the information that it needs to send a payment. It is too late by the time it starts doing the gossip stuff and everything else. They want the payment to go through now. The trivial way is to have a server somewhere and go “How do I pay Joe? No reason, just asking” and then the next payment goes out to Joe. That’s a trivial information leak. Another way of doing it is to send to some node on the network that you do know how to get to. “Can you send this to Joe?” Normally of course you only give the next hop. In this case you go “Here is an extra payments and I want you to route to wherever Joe is, wherever this node ID is. Get it there. Create the rest of the hops, do the thing.” In that case of course I still have to ask “How do I get to the rendezvous node? How do I get to one of those?” and then tell the rendezvous node where it is going. But I could chain these. If I don’t want the rendezvous node to know I’m paying Joe I could ask the rendezvous node to go to another rendezvous node and tell that one I’m paying Joe. The rendezvous node may guess where the payment is coming from or whoever I’m asking for the route knows that I’m going to the rendezvous node. The rendezvous node collaborates with them and “I know it is going to Joe and I know who asked for the route to you so therefore we can figure it out together”. It is effectively like the Tor network. At the moment you can only have a randomized route between any things that are connected by channels. This is another layer up which allows you to send over arbitrary numbers of channels between peers. Obviously you are sending across a much longer path but it does allow you to protect your privacy. This is a service that nodes would charge for. It does allow you to outsource your routing, that’s the whole point of this exercise. There are a few interesting proposals on that with the ACINQ people leading the charge there. This is a hot issue for them. They would like to not be exposed to that information and have as many nodes as possible out there offering these kinds of services.

MH: I hope that we will see more and more of these Lightning service providers or these Lightning services being provided by everyday nodes. Connect themselves and each other optimally, I think there is more cool, crazy complex things that can be done that needs a lot of work to figure out.

RR: Absolutely.

MH; Fascinating. Rusty, we covered a whole bunch in our conversation here. Is there anything else that you are still eager to speak about?

RR: No I find this whole space really exciting. I am a low level bits and bytes kind of person so I can get lost in the weeds, how are we going to implement this and everything else. But there is this whole stack above, you talked about the podcasting stuff and things like that. What is really exciting for me is people building stuff on top of this, building the higher layers and getting stuff to work. Deploying it to real users. That’s definitely not my strength but it always surprises and impresses me when people do that. I learn a lot. I really appreciate the feedback because often we find people have worked their way around something. If we had known it was an issue it was something that we would address. Either the implementation level, the Lightning node, or often the spec level. This is something that we can spec out. We should have a way of doing this and we should have a standard way so that everyone doesn’t have to implement some boutique hack. We can design it and make sure it is a standard thing that everyone is going to support. That’s the takeaway. I always love it when people tell me their problems, tell me the issues that they have and what they are trying to do. We can often work out a way to make sure that we are doing that. The spec still moves and it is still evolving. Obviously we haven’t had a face to face meeting in a while but there is hope that maybe later this year there will be another face to face Lightning spec meeting which we would expect to kick things in higher gear. That would be my takeaway. If you are working on doing stuff with the Lightning Network make sure you are reaching out to your friendly Lightning developer and making sure they know what they need.

MH: It has been a blast to see how Lightning has evolved from concept to the very first reckless implementations and to now, this thundering ecosystem already. We are just getting going. We have outlined in this conversation 101 things on how we can make Lightning even better. I am hopeful that this rigor to improve Lightning to continue to be there. I think it is a massive opportunity, as you say, to bring free and open source money in a way that it is both usable as a store of value, you can verify that nobody is printing more money, and simultaneously you can make payments that not everyone has to verify. This is a ridiculous achievement and I am happy that we have some wizards like you onboard to help us figure out how to get it done.

RR: To be fair I am probably at the older end of the spectrum of Lightning developers and it definitely keeps me on my toes keeping up with all the exciting and novel things that other people come up with in the space. It is certainly keeping me getting up at 5:30 in the morning for the calls, I have never done that for any other job. Just how exciting I find this space, it is amazing.

MH: Physical excitement and bullishness that it actually hurts. Waking up at 5:30 is one of those symptoms being knee deep into Bitcoin.

RR: Absolutely.

MH: Thanks again for coming on the show and keep up the great work. Talk to you later.

RR: Thank you Max.