"Smart custodial account" extension about luds HOT 5 CLOSED

Not too enthusiastic so far. As far as I understand this is an extension of lnurl-login which would allow to do certain actions from user phone instead of, say, service webpage where user logs in to, I see little point in that and better hand this to service developers (i.e. let user do those things on site/app once logged in).

Plus, https://github.com/btcontract/hosted-channels-rfc seems to be at least partially covering outlined custodial use cases, but with better privacy and accountability.

from luds.

It seems that calling this "custodial account" even with quotes was confusing. I somehow couldn't come up with a better name.

The goals of my suggestion are basically automation of invoicing (employee/barista with tips use case) and automation of decision (turbo/LN) - improved LN UX. I present them together because I believe both can be solved with this protocol extension.

• ATM being unable to return fiat is a real world use case. Further, I don't think it's a very good UX for the user to have to pick between Turbo and existing LN channel. Automating this is much better.
• You can withdraw manually with a website, but why not automate it? Especially if the end user is expected to withdraw anyway. If the sender is capable of providing Turbo channels, the ability to easily resolve routing failure by opening such channel is very handy.

More detailed description of use cases:

ATM use case

1. A user approaches an ATM, selects "Buy Bitcoin over Lightning" button.
2. The ATM instructs the user to scan a QR code.
3. If the ATM server receives correct request, it knows that the wallet is compatible. I witnessed first-person quite serious issues with people messing up buying. I believe the possibility of user error should be minimized as much as possible.
4. The user inserts as many bills as he wishes.
5. The user hits "Buy" button
6. The wallet is notified of changed balance
7. The wallet determines if there's enough incoming capacity for withdraw - if not, it requests a turbo channel.
8. The wallet can withdraw partially using more than one channel - this is a great UX!
9. If the routing fails, the wallet requests Turbo.

Employee use case

1. When the employee signs the contract, he's shown a QR code
2. The employee scans it to establish link
3. Whenever the employer calculates the paycheck of employee, he just enters it into the system (can be fully automated)
4. The wallet of the employee receives push notification (using the callback feature)
5. The wallet withdraws automatically

This completely removes the requirement for the employer to manually generate invoices and sending them to the employee.

Regarding hosted channels. I think it looks nice too. What I'm missing there is again some way to turn the hosted channel into Turbo. This could be done by the wallet automatically paying some channel-opening service and then "rebalancing".

What I'm missing is a way to credit the hosted channel without interaction and notifying the wallet about the change. Even if it's implemented, there needs to be a protocol for establishing those channels - so LNURL should be extended to cover this.

Do you plan to implement hosted channels into BLW/Eclair?

from luds.

I don't see the reason for all this unnecessary automation. The ATM case can all be done manually with more QR scans. The employee can also get his salary manually and it's not a big deal. At least I don't think it is worth implementing an automation protocol that would be complex to support so many different cases -- and also the wallet having to keep a background service to be able to receive notifications when it would be just as easy for the employer to send Telegram message with an lnurl to the employee for the salary.

Also I personally don't like my wallet doing things on my back without I understanding it.

But I also think it's too early to think about these protocols as there's no expectative of people paying salaries with lightning and still small adoption by other wallets of lnurl things. Maybe that will change in the future then this idea can be revisited.

from luds.

@fiatjaf why would automation ever be unnecessary? There's nobody pointing gun at your head - don't use it if you don't want to, but let others do it, if they want. You don't have to implement it either. The background service already exists for push notifications. I don't see any problem with efficient use.

Here's the deal: I want to implement this feature and I'm now attempting to cooperate in such way for the feature to be useful for more people and well documented. If nobody else wants it, I will just fork whatever is necessary and do it myself.

LN is currently extremely complex to any newbie. They have to deal with multiple balances, channels... Now add the fact that there are possible failures, Turbo channels, submarine swaps... I deal with explaining this almost every day and it's hell.

You may think salaries with LN aren't a thing, but in fact they are. I witness this first hand. Currently salaries and tips are done using on-chain and address reuse. Sometimes they are in shitcoins. I want to get rid of this nonsense and provide smooth experience.

from luds.

The way this was described was grossly confusing. Please forget that I wrote this. I rewrote it from scratch at #14.

from luds.