group-income
group-income copied to clipboard
Payment option: Lightning
Problem
We don't support Bitcoin yet.
Solution
Implement Lightning-based payments.
Useful links:
- https://btcpayserver.org - we would most likely be integrating with this
- https://twitter.com/roasbeef/status/1189314303687569408
- https://github.com/jamaljsr/polar
- https://blog.lightning.engineering/posts/2019/07/24/lndmon-v0.1.html
- https://medium.com/tierion/lsats-pseudonymous-authentication-using-bitcoin-lightning-payments-459e209b4b36
- https://blog.lightning.engineering/announcement/2020/01/21/lnd-v0.9.html
- https://github.com/joostjager/whatsat
- awesome LNURL
- https://www.coindesk.com/bitcoin-wallets-are-adopting-this-tech-to-simplify-lightning-payments
- https://medium.com/breez-technology/as-free-as-the-breez-building-lightning-to-make-bitcoin-mobile-4f3d2cca22eb
- https://github.com/BlockchainCommons/Learning-Bitcoin-from-the-Command-Line
- https://lightninginabox.co/2018/12/how-to-install-btcpayserver-on-raspberry-pi-3-b/ <- pretty cool
- https://github.com/btcpayserver/btcpayserver-docker/pull/450#issuecomment-826008546
- https://degreesofzero.com/article/shared-private-lightning-network.html
- Lightning Network Invoice Multiplexer: https://bottlepay.com/blog/multiplexer/
- Liquidity Primer for designers: https://twitter.com/StephenDeLorme/status/1521245135316701184
- Bolt12 standard
- https://twitter.com/BoltObserver/status/1542527402286391296
- https://twitter.com/OshiApp/status/1542532210451939334
- https://lightningdevkit.org/blog/ldk-an-sdk-for-the-lightning-network/
- bos a CLI utility for interacting with LND
- Nostr's Lightning Zaps
-
Lightning Addresses!
- https://github.com/andrerfneves/lightning-address
- WebLN (standard)
- WebLN (library)
Wallets:
- LNBits has multi-address invoices too
- cashu Ecash wallet and mint with Bitcoin Lightning support. "Cashu is an Ecash implementation based on David Wagner's variant of Chaumian blinding."
- https://blog.bitrefill.com/top-11-lightning-network-wallets-bitrefill-328b5465b1b4
- https://github.com/lightninglabs/lightning-app
- https://github.com/joule-labs/joule-extension via https://github.com/joule-labs/webln
- https://github.com/shesek/spark-wallet
- https://github.com/LN-Zap/zap-desktop
- https://muun.com/
- "What if you could pay a Lightning invoice with your debit card? What if your bank account could speak Bitcoin?"
- https://github.com/asoltys/coinos
- https://github.com/btcontract/IMMORTAN
- getAlby: https://mstdn.io/@[email protected]/109519162811444387
Research:
- MPP (multipath payments) + Bolt12
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:
- The user experience is way more simple, virtually no setup needed;
- This will probably be an "intermediate" wallet for most users, that they just use for Group Income, so keeping it simple might actually be better;
Let me know what you think
A couple more things that have been on my mind since I started this research:
- What is the advantage of having our own wallets?
- Why should people use our wallet instead of another one that they potentially have been using already?
- If we want to do "one thing, and do it very well", does implementing lightning wallets help with that?
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.
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
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.
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:
- What problem are we trying to solve?
- How do we know this is a real problem?
- Why is it important to solve?
- Who are our users? What are their goals and motivations?
- How will we know if we’ve solved the problem?
Anyway, I will continue researching, and I'll think about doing this in a way so that users can use whatever wallet they prefer.
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.
Yes, I will do that @taoeffect !
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](https://user-images.githubusercontent.com/22004566/69884111-28cccb00-12d7-11ea-8373-17a0bc1f613f.png)
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:
- Let their users create non-custodial wallets OR let them use their existing wallets without an intermediary wallet;
- Their main purpose is not to be a wallet "provider", but something else (like creating articles, for example);
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:
- Generate recovery phrases;
- Keep their wallets/keys safe (they will be using their GI password to login, and that password should give them access to their wallets);
- Recovering passwords becomes a more serious problem - we need a robust way for users to recover their passwords or else they'll lose access to their funds;
- Generate sending and receiving addresses;
- Implement ability to create channels - it's not possible to use the Lightning network otherwise;
- Implement the ability to send funds using the LN (through channels);
- Implement the ability to receive funds using the LN (through channels);
- Implement the ability to send and receive funds outside the LN (on-chain);
- Display how much they'll need to pay in LN fees;
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.
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.
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:
- The current payment distribution: which says who needs to pay who and how much.
-
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. - 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?
@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:
- Pay group page with only manual payments;
- What it would look like with multiple payment methods (whatever these might be);
- 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.
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):
- Lucy requests a payment, with a specific amount set - in other words, Lucy generates an invoice;
- Karl uses that invoice to pay Lucy.
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.
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.
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!
Here's a good video that compares Lightning payments with Nano: https://www.youtube.com/watch?v=iVNyr4Q3jq4
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.
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.
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.