"Smart custodial account" extension

[Kixunil]

I was thinking that it'd be useful to extend this specification for cases when the customer has a business relationship with other party and the other party might owe him some satoshis. This is different from the mere withdraw case, when it's only possible to withdraw over LN and actively scanning the QR code - in this case opening a (turbo) channel should be possible too. Further, I'd like to see a way to enable the users to withdraw without scanning anything.

Cases when this might be useful:

• Exchange executed a buy order and the customer should be able to withdraw regardless if he has a channel already or not
• An employer tops up the balance of employee and doesn't bother him with asking for invoice. The employee withdraws whenever it's comfortable or the wallet could withdraw automatically.
• An ATM needs to know that customers wallet is compatible before accepting bills (because it can't spit them out)
• A waiter is earning tips within POS in order to simplify the flow for the customers and tips are credited to his account automatically. His wallet could withdraw them without scanning anything.

Rough idea of extension:

A new fields "accountBalance" and "accountCapabilities" are added to login response object. Here's an example:

{
    #...
    # msat
    "accountBalance": 1000000000,
    "accountCapabilities": {
        # whether the service can open a channel in case of routing failure
        # MANDATORY (the field must be present even if false)
        "openChannel": true,
        # msat, not present if openChannel is false
        "openChannelFee": 1000000,
        # sat, the minimum amount for opening the channel
        "minChannelAmount": 100000
        # Indicates whether the opened channel supports spending zeroconf push - AKA "Turbo channels"
        "spendUnconfirmeddPush": true,
        # The wallet can GET this URL to retrieve current balance, MANDATORY
        "pollURL": "https://example.com/acount/poll",
        # Minimum delay between polls in seconds to prevent overloading
        "minPollPeriod": 30,
        # The wallet can use this URL for withdraws, MANDATORY
        "withdrawURL": "https://example.com/account/withdraw"
        # OPTIONAL, the wallet can use websocket to wait for balance changes
        "websocketURL": "https://example.com/account/listen"
        # OPTIONAL, the wallet can provide a callback that will be triggered whenever the balance changes
        "subscribeURL": "https://example.com/account/subscribe"
    }
    #...
}

Websocket sends same messages as poll response: JSON object with MANDATORY "accountBalance" field and OPTIONAL "accountCapabilities", which is same as above. If it's missing, the wallet assumes it didn't change since the last poll.

This is just the protocol, the wallet is responsible for all automation (if any). In the future, it should be extended with splicing in, if there's an open channel between the parties. The provider MAY use trusted third-party service for opening the channels.

Additional ideas: on-chain withdraw for larger amounts, topup (off and on-chain)

What do you think?

[akumaigorodski]

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.

[Kixunil]

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?

[fiatjaf]

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.

[Kixunil]

@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.

[Kixunil]

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