search

okTurtles / group-income

A decentralized and private (end-to-end encrypted) financial safety net for you and your friends.
https://groupincome.org
GNU Affero General Public License v3.0
328 stars 43 forks source link

Payment option: Lightning #766

Open taoeffect opened 4 years ago

taoeffect commented 4 years ago

Problem

We don't support Bitcoin yet.

Solution

Implement Lightning-based payments.

Useful links:

Wallets:

Research:

mmbotelho commented 4 years ago

I'm still wrapping my head around how all of this works, but I have a question that can be addressed now:

We want to create non-custodial wallets, right?

I am pretty sure your answer (@taoeffect ) will be yes, but I just want to leave here a few thoughts on why a custodial wallet might be good as well:

Let me know what you think

mmbotelho commented 4 years ago

A couple more things that have been on my mind since I started this research:

taoeffect commented 4 years ago

We want to create non-custodial wallets, right?

Can you define what you mean by this? Perhaps link to some examples? I want to make sure we're on the same page.

What we want to make is something that has the functionality of this: https://github.com/lightninglabs/lightning-app

Seeing as they're using the same license as we are, we can literally import parts of that project.

What is the advantage of having our own wallets?

As opposed to what? We have requirements that require us to have our own wallet. It's not possible to do what we need to do without it. I've mentioned those requirements before, but happy to give a refresher if needed.

If we want to do "one thing, and do it very well", does implementing lightning wallets help with that?

Again, we cannot do what we need to do without doing so. We need to be decentralized, which means not relying on a third party. We need to be able to send optional fees, which means having precise control over the transaction.

mmbotelho commented 4 years ago

Can you define what you mean by this? Perhaps link to some examples? I want to make sure we're on the same page.

Wallet of Satoshi is an example of a custodial wallet. Zap is an example of a non-custodial wallet. The main difference that I can see is that the first handles keys for you and the second gives you the keys and makes you responsible for keeping them safe.

As opposed to what?

As opposed to letting people use whatever wallet they are already familiar with or that they like. I know exactly what the requirements are, I just think that the extra amount of work we are imposing on users (having to set up a new wallet, send funds to it, etc) will not make sense for most of them and they'll just use whatever method is easier and faster for them (for example a Zap wallet that they already use on a day-to-day basis), rendering all our efforts to support lightning payments useless.

We need to be decentralized, which means not relying on a third party

But in practice, users WILL need a third party to transfer funds, regardless of what we do. At the moment, it's not possible to go from having 100 USD in my hand and sending them using GI's Lightning wallet without it passing through a third party, correct?

@taoeffect

taoeffect commented 4 years ago

Wallet of Satoshi is an example of a custodial wallet. Zap is an example of a non-custodial wallet. The main difference that I can see is that the first handles keys for you and the second gives you the keys and makes you responsible for keeping them safe.

OK thanks. Yes in this case we will need to focus on non-custodial wallets. Using a wallet run by someone else is not only dangerous, it's also, again, against our requirement of being a decentralized application. We do not want to encourage bad practices. Using custodial wallets is a bad practice in the cryptocurrency world. Admittedly, it is sometimes not possible to avoid it (as with some exchanges), but the usage of custodial wallets should be limited as much as possible.

If everyone were to use custodial wallets, there would be no point in having cryptocurrencies in the first place.

I just think that the extra amount of work we are imposing on users (having to set up a new wallet, send funds to it, etc) will not make sense for most of them and they'll just use whatever method is easier and faster for them (for example a Zap wallet that they already use on a day-to-day basis), rendering all our efforts to support lightning payments useless.

This is a valid concern, so it will likely require some more research. What is definitely not the right answer is saying that we will do nothing about it at all, because that would be failing our requirement of ensuring the financial survivability of the project. So if you're not happy with my suggestions, you'll need to dive into the details of how Lightning invoices are generated and ask questions like, "Can they specify multiple recipient addresses?" etc. The QR-code invoice scan type thing is possible, which would allow users to use a lightning wallet on their phone. Maybe it's possible to generate a link that they can click that will open another wallet app with all the transaction details filled in. I don't know. But this is a hacky method of doing things, and we would be beholden to the app-maker of another wallet. That puts everything we do at risk, as there's no guarantee that the developer of another wallet will keep their app compatible with ours. It's begging to shoot yourself in the foot.

But in practice, users WILL need a third party to transfer funds, regardless of what we do. At the moment, it's not possible to go from having 100 USD in my hand and sending them using GI's Lightning wallet without it passing through a third party, correct?

Only half correct. You could exchange it directly with a friend for Bitcoin. It's unspecified how you obtain Bitcoin. That's not a problem we need to worry about. You can use a dozen different ways of getting cryptocurrency, whether it's Bitcoin or something else (Lightning supports other cryptocurrencies too). What we absolutely do not want to do is specify a third party that all our users must use in order to use Lightning.

mmbotelho commented 4 years ago

What we absolutely do not want to do is specify a third party that all our users must use in order to use Lightning.

That's not what I am suggesting. I am not even at the point where I can suggest anything. What I am doing is questioning if implementing our own wallets is the best thing to do and if people will find that useful. This might sound annoying, but it's a very important part of my job (questioning if the briefing is the correct one). More specifically, answering questions like these:

Anyway, I will continue researching, and I'll think about doing this in a way so that users can use whatever wallet they prefer.

taoeffect commented 4 years ago

One question you might want to look into is exactly what Lightning QR-code invoices can be used to do. If they can be used to create a single QR-code for a transaction that supports 20+ recipients, then that's something we could use. At the very least, finding out what is possible there would help clear things up I think.

mmbotelho commented 4 years ago

Yes, I will do that @taoeffect !

mmbotelho commented 4 years ago

Quick update on my research:

Here's one example of a system similar to ours (in the sense that they act as an intermediary between 2 people) - it's a website where you can write articles and get tipped using the Lightning network. It's called Y'alls. The whole process is very simple, you have a textarea where you can paste an article and you have a field where you can paste your public LN node public key (webpage here):

Captura de ecrã 2019-11-29, às 18 15 49

To receive money, users need to:

Claim rewards at any time by pressing on the payout button in your article. Enter an invoice that matches your public key to claim. Make sure to regularly claim rewards. Rewards can go away, go down, and are kept in a custodial wallet.

You can read more about their payout system at https://yalls.org/payouts

They list a number of existing wallets but don't create wallets themselves. And use a custodial wallet to keep things simple (I know this is not what we want to do).

I am still on the hunt for software/apps/products that fulfill these 2 requirements:

If you are aware of any, let me know.

At the moment I have a somewhat clear idea of what needs to be designed and implemented in order for us to have functional, non-custodial, wallets on GI. Here's a summary:

Keep in mind that this is a very high-level list of what needs to be done. I don't think we can implement less functionality than this in order to create wallets ourselves. In other words, the minimum amount of features is all the features.

In order to use an external wallet in GI, I'm still not sure how we can do it. I found this article but I'm not 100% sure if what they are doing is what we need. @taoeffect can you please read it and let me know what you think?

Regarding your question about invoices, I'm pretty sure that one invoice is only valid for one transaction (between 2 people). I'll update you if I find something else on this subject.

mmbotelho commented 4 years ago

Forgot to mention on my previous comment - there is the option to create indexed invoices:

AddIndex is a feature that wasn’t included in the decoded invoice above but is still available to be used. It adds a sequence number to all subsequent invoices, starting with the number 1. Customers can then use this number as a “checkpoint” to keep track of unpaid invoices. This method of generating invoices is well-suited for subscription or streaming services.

For example, let’s say a customer subscribes to Netflix with monthly payments of $10 per month. Netflix would then generate indexed invoices every month which the customer could autopay once they receive it. The great thing about indexed invoices is that if you store them outside of your LN node and your node goes offline, it can automatically catch up with the most recent invoices and pay them once it comes back online.

https://blockfuse.io/blog/lightning-network-invoices/

This is a great feature, but I'm not sure it'll be useful for GI, since the amount of money a user needs to send to someone can change all the time.

taoeffect commented 4 years ago

In order to use an external wallet in GI, I'm still not sure how we can do it. I found this article but I'm not 100% sure if what they are doing is what we need. @taoeffect can you please read it and let me know what you think?

You found a great Lightning wallet! I just added it to the list above. This article they wrote also seems illuminating and probably relevant to you.

Since we won't be implementing this for the prototype, the idea here is just for you to get an idea of what other Lightning wallet UIs look like, and what they're capable of. Then, combine that with what you know about how custodial wallets work. Then combine that with what you know about how non-cryptocurrency payment services like PayPal/Venmo work. Then combine that with what you learn about Interledger's (#752) flow.

Then somewhere out of that horrible amalgam, find the simplest design that covers all (or most of) the future UIs that we will need, should we chose to support more payment methods. We need to make sure that the base UI we design is "plugable", and easily modified to accommodate different payment systems. It may be that by the time we're done with the prototype, we'll have decided to implement something other than Lightning first. Or we'll stay the course and implement Lightning. Who knows. But the point is that whatever UI you design now needs to be able to easily adjust to all these possibilities.

Why? Because the basic idea of a payment is the same regardless of what payment system we end up supporting, at least as far as the Pay Group UI is concerned. It consists of:

  1. The current payment distribution: which says who needs to pay who and how much.
  2. Payments: a statement that says someone has sent payment to someone else in some currency for some amount, has an associated "status", and can included an arbitrary number of fees to other recipients. Typically a payment is 1-to-1, i.e. person 1 pays person 2, but again, for our purposes we may need to include additional recipients because of multiple possible fees (depending on the payment network, if they're sending a donation, etc.). A specific payment can also potentially have a history associated with it, for example, a history of status changes, e.g. ["pending", "completed"], etc. It's also important to remember that a specific person might receive multiple payments in a single month, even from the same person multiple times.
  3. Receipts (one for each payment): a statement that says whether a payment succeeded or failed. Effectively updates the payment's status.

All of this other stuff about recovery phrases, channels, etc., — any specific details to a specific payment method — all of that should be part of a totally separate UI from the UI that exists in the Pay Group page. This separate UI is not something you need to design now. The only consideration you need give to it is how you'd end up navigating the user to it.

However, the Pay Group page should be able to tell us which which payments were sent, their status, who needs to be paid still, which payment methods were used for those existing payments, how much (in terms of the group's currency) they were for at the time of sending, etc.

https://blockfuse.io/blog/lightning-network-invoices/

This is a great feature, but I'm not sure it'll be useful for GI, since the amount of money a user needs to send to someone can change all the time.

Yeah, at least for payment multiple recipients in one go it doesn't sound useful, and based on that link it looks like lightning invoices can only support a single destination address, which sucks, and means that we'd need to generate one LN payments for each person we're paying, which definitely means that if we use LN, QR codes are out of the picture, since nobody has time to scan 20 QR codes. We'd need to programmatically send all of the payments, which means having a real wallet implementation going.

Again, while that might sound intimidating right now, the good news is that we also don't need to worry about it right now. The only thing we need to worry about is figuring out a base UI for the Pay Group page that would work without much modification for all types of payment systems, and segregate all the "payment plugin" stuff someplace else.

Does that help?

mmbotelho commented 4 years ago

@taoeffect it does, thank you. Please take a look at these 3 artboards on Figma: https://www.figma.com/file/mxGadAHfkWH6qApebQvcdN/Group-Income-2.0?node-id=7342%3A5

Artboards description:

  1. Pay group page with only manual payments;
  2. What it would look like with multiple payment methods (whatever these might be);
  3. Example of a detail view for a payment.

This is what I understood you wanted to see, from your previous comment. As you can see, the jump from page number one (only with manual payments) to a multiple payment system is very simple (in terms of changes to the interface itself) and can be easily done in the future.

mmbotelho commented 4 years ago

I am going to leave here a few other concerns / questions I have about the Lightning network, for future reference.

The flow of a Lightning payment goes as follows (excluding channel setup):

Now, this poses a problem for partial payments on GI. Let's say that Karl only wants to pay half the value Lucy requested. Lucy would then have to generate a new invoice, with a new amount. This makes sense when we think of using Lightning in a traditional shop - you order a coffee, the shop generates an invoice for that coffee and you pay for it. However, this feature makes it difficult to only pay part of an invoice instantly, because the payer would always have to wait for the payee to generate a new invoice.

taoeffect commented 4 years ago

Please take a look at these 3 artboards on Figma:

@mmbotelho This looks great. I see what you mean now. OK, this looks like it can work. :-)

However, this feature makes it difficult to only pay part of an invoice instantly, because the payer would always have to wait for the payee to generate a new invoice.

Is that really true? I think it should be possible on Lightning to simply send to a Lightning address, without an invoice... I would be very surprised if that wasn't the case.

mmbotelho commented 4 years ago

Is that really true? I think it should be possible on Lightning to simply send to a Lightning address, without an invoice... I would be very surprised if that wasn't the case.

From the research I did, there is the option to do it, using something called circular payments. You can read more about it here. However, when I read it, it seemed very "hackish" and not safe. But maybe I was too fast to discard that option - I'll let you be the judge on that one! 😄

I do hope that in the future they will come up with a more robust solution!

mmbotelho commented 4 years ago

Here's a good video that compares Lightning payments with Nano: https://www.youtube.com/watch?v=iVNyr4Q3jq4

taoeffect commented 4 years ago

From the research I did, there is the option to do it, using something called circular payments. You can read more about it here.

Here's his code for doing it, which seems simple enough.

Here's a good video that compares Lightning payments with Nano:

Eh, NANO, though somewhat interesting (because it uses a similar data model to what we do), seems to have serious problems (must be logged in to Twitter for that link to work).

There are lots of cryptocurrencies that claim to magically solve the DCS Triangle, and, well, people should be very skeptical of such claims. It is possible to get around it, but all such attempts might look like hacks to casual observers, because it really is a fundamental limitation of decentralized consensus systems.

mmbotelho commented 4 years ago

Here's his code for doing it, which seems simple enough.

Regardless if it's simple or not, the payee will only see the payment as "fees" - that's why I say that it's very hackish.

Eh, NANO, though somewhat interesting (because it uses a similar data model to what we do), seems to have serious problems (must be logged in to Twitter for that link to work).

If you watch the video and ignore the nano part, he makes a great job at explaining why the experience of using the Lightning Network is still not the best or practical to use with anything except for regular payments, with the same amount, between the same people.

taoeffect commented 4 years ago

True, and I expect it to be that way for a while, but I also think the Lightning developers (core and third-party), are aware that they need to improve usability. By the time we get around to integrating this, I'm hoping that usability will be improved.