Elle Mouton | Connect the World

In the beginning of March you participated at the 2-day technical Advancing Bitcoin conference in London! You gave a talk about static invoices in Lightning and you dove deep comparing LNURL, Lightning Offers (BOLT12) and AMP (Atomic Multi-Path Payments). Why is static billing development so important within the Lightning Network and more importantly how is it related to growing adoption?

Usability! People are used to paying to a fixed bank account number and being able to safely pay to this number as many times as they want and whenever they want. This is what is natural for people. It also makes things like setting up recurring payments a lot easier.

What’s the main problem of invoicing within Bolt11?

Following on from the previous question, the issue with current payments using bolt 11 is that you as the receiver need to create a different invoice each time someone wants to pay you. So the sender first needs to ask the receiver to generate an invoice for them and only then can they go ahead and make the payment. The other issue is that there is a limit to how much you can squash into a bolt 11 invoice before the QR code representation just becomes way too dense. Meaning that there is limit to how much info the receiver can give the sender using this invoice format.

You talked about the pros and cons of LNURL, Lightning Offers and AMP. Which are the big cons of LNURL and AMP?

– LNURL cons: biggest one is that you need to set up a webserver (tls certs, domain name etc). Another con is that where before the sender of a payment could stay completely anonymous, now they have to make a Get request to the webserver and possibly reveal their IP address.

– AMP cons: no proof of payment

Why is there no proof of payment using AMP?

Ok so like Keysend, with AMP, it is the sender that determines the preimage of the payment and then encrypts it for the receiver to use to claim back the HTLCs. With normal payments, the only way the sender could get the preimage was if the payment was successfully made which is why it is seen as a proof of payment. But with AMP, since the sender is the one generating the preimage, them knowing it means nothing.

For podcasts there is Podcasting 2.0 where a listener can directly pay a creator without an intermediate party. What other possibilities do you see possible for Lightning in the future?

My favourite use case is paying per article instead of needing to pay for a subscription. So in general , the pay-per-use model can definitely benifit off of lightning. Then there are other things that micro payments enable such as being streamed your income continuosly rather than being paid once per month. Infact, I think people will then beter value their money as it will be more closely associated with the time it took to make it.

You described all Lightning Layers, from application, invoice negotiation, invoicing, payments, messaging and network and then you put LNURL, Offers and AMP next to it: You see instantly that Lightning Offers offers everything we need! Is this correct do you think or are there still big problems with this Lightning native integration?

Hmmm I think this slide was maybe miss-interpreted, the aim of the slide was just to show which layers each of these proposals would effect – ie, what in LN needs to change to get these proposals to work. So it was actually showing that Offers has a big vertical stretch through the layers and so would require many layers of LN to adapt.  That being said, I do think Offers is very cool and that there are definitely benefits to having it. The big barrier and point of contention lately though is around onion messaging (which Offers relies on) and how we will prevent people from spamming the network with onion messages.

When talking more about the cons to Lightning Offers you said that it:
Couples many things into one proposal and that it brings application-level detail into the network. Why do you see these as cons?

– “Couples many things into one proposal”: Not really a bad thing, just requires many people to agree on many things. So can make it harder to move forward on things. Offers depends on Route-blinding and Onion messaging and those things are not even in the spec yet. So all I really meant here is that it isnt a quick-fix solution that we can make happen easily. It also requires majority of the network to upgrade if it is to work properly. But we are still in the early days i think. So if it is going to bring big benifits, then let’s go for it!

– “brings in application level details into the network”: I think modularity is good. Layers should be well defined so that they can be good at one thing and not become too complex. This also makes it easier to swap out layers in the future. Also, I think we should think hard about what should and should not be included in the network. It is a payments network, so does it need to know that it is being used for recurring payments or should that be an application-level thing?

You ended your conclusion with 3 questions?

– How important is proof of payment?
– What should and should not be included in the protocol?
– Should there be only one invoice solution to solve every use case?

I find that last one very interesting! Do you see it as a possible future that a user can choose for themselves to choose which static invoices they want to use?

Yes abosolutely. I dont think this is necessarily a one-size-fits-all scenario. LNURL, for example, works very well for merchants who probably are already running a server. So adding one more webserver is not a big issue. And AMP works very well for spontaneous payments (tips, donations). I think it can be good to have different methods that are catered to a specific group of users instead of trying to solve everyone’s problems with only one.

How will developers reach a consensus about what should be included in the protocol?

This is done through the spec process. You can propose a change to the spec. Then a bunch of people can go review and think about your change and can discuss it in the bi-weekly spec meeting. Then if implementations are interested, they can go implement it. If 2 implementations implement it, then the change can be merged into the spec.

Do you think there will be one standard implementation of Lightning in the future or is this the strength of Bitcoin and Lightning that there will always be a choice what to use?

No I dont. I kind of hope that there never is only one. That’s no fun. Competition is healthy and will ultimately lead to the best possible network.

You made a video demo about Aperture Dynamic Pricer. We will put this video in the show notes. Can you tell us more about how it works?

Yay im so happy about this question! (i can give a more techincal description on the day if you want) Basically: Aperture is a proxy you can use to create paid API points for your website and for content on your website in a KYC-free way! This is done with something called an LSAT (lightning service authentication token) which is a combination of a macaroon and a payment preimage. So you can charge for example 10 sats for all requests for the “/articles” path and 20 sats for all requests for the “/videos” path. But one thing that was missing is that you couldnt charge a different price per article or video (ie, dynamic pricing) in a scalable way. You can do this now (it is a feature I added last year) ! So the aim of the video was to demonstrate how to do this.

For what kind of people or content creators can this app be an actual use case for?

All kinds! Articles, podcasts, videos etc! Especially if you want people to be able to pay for content and the always have access to that content without ever needing KYC info from them

A lot of our listeners run a Lightning Node. Do you run a personal Lightning Node yourself? And if yes: What implementation are you running and why?

Of course! I run an LND node at the moment. Mainly because I work at LL and should definitely be testing the implementation that I work on. There is also loads of documentation out there for anything to do with running an LND node. However, I definitely aim to be running one instance of every implementation at some point so that I can more easily test interop.

If you believe in a Hyper Bitcoinized world, what major problems can Bitcoin and Lightning solve in the short term?

Remittance (as mentioned before). And also in the short term, as many countries are experiencing more and more inflation, Bitcoin will help solve the problem of saving & having a reliable store of value

What kind of app would you like to see on your mobile in the next 4 years?

Hmmm, im not sure. Will need to think about this one a bit more. I guess I would like to see more apps that accept lightning payments for online purchases.