Hold Invoice: this RPC call is not supported with restricted account macaroons

[cj-chua]

Getting this error when calling v2/invoices/hodl rpc endpoint: this RPC call is not supported with restricted account macaroons Is hold invoice generation not supported by custodial accounts..?

Here is the permission tied to the macaroon

lncli printmacaroon --macaroon_file my.macaroon

{
    "version": 2,
    "location": "lnd",
    "root_key_id": "0",
    "permissions": [
        "uri:/invoicesrpc.Invoices/AddHoldInvoice",
        "uri:/invoicesrpc.Invoices/CancelInvoice",
        "uri:/invoicesrpc.Invoices/SettleInvoice",
        "uri:/invoicesrpc.Invoices/SubscribeSingleInvoice",
        "uri:/lnrpc.Lightning/DecodePayReq",
        "uri:/lnrpc.Lightning/LookupInvoice",
        "uri:/routerrpc.Router/SendPaymentV2"
    ],
    "caveats": [
        "lnd-custom account 7a9a7fa721ccab03"
    ]
}

[AndySchroder]

I am also confused why this is not supported. The preimage is generated by the macaroon holder, so it seems like any macaroon that can generate an invoice should be allowed to do a hold invoice.

[ViktorTigerstrom]

I am also confused why this is not supported. The preimage is generated by the macaroon holder, so it seems like any macaroon that can generate an invoice should be allowed to do a hold invoice.

This ties into the same problem as issue https://github.com/lightninglabs/lightning-terminal/issues/632 unfortunately. The accounts system currently cannot link a invoice to the account that have generated it, if the invoice has no invoice hash (i.e. HODL invoices). If we did allow generations of such invoices currently, the respective account would never get credited when the invoices were settled. Therefore we need to add support for linking invoices that have no invoice hash before we can support this. Unfortunately it's not super trivial to add this support, but we are aiming to add support for it in the future when we have the possibility to prioritize it. @AndySchroder, is this a feature that is much needed from your end?

[AndySchroder]

Generally, I like the LND Accounts system because it uses the same gRPC interface as a normal LND node. gRPC is a lot more complicated than a simple http query, but you do gain a lot of magic from the gRPC. If you design an application that works on the gRPC, it's nice that it should be able to transition from a normal LND node to a more restricted account without any software changes, only a change in macaroon. With that being said, I would also expect any feature in LND that doesn't have to do with node management or channel management or on chain activity to work. We have this issue, as well as https://github.com/lightninglabs/lightning-terminal/issues/533 that caught me off guard when I found they were not supported.

There are so many applications where you'd want to restrict an application or device to a limited account, but still allow it to use basic lightning network features. The application may be software with limited trust in the developers or a device that is freestanding in public. I shouldn't need to allow every point of sale machine in public to have access to all invoices on a LND node, only the invoices that it has generated. Or, you might just be developing your own application software and want to use a more limited account because you want to develop on mainnet and not testnet.

[AndySchroder]

If https://github.com/lightninglabs/lightning-terminal/issues/632 is related , possibly https://github.com/lightninglabs/lightning-terminal/issues/505 is also related.

[ViktorTigerstrom]

Generally, I like the LND Accounts system because it uses the same gRPC interface as a normal LND node. gRPC is a lot more complicated than a simple http query, but you do gain a lot of magic from the gRPC. If you design an application that works on the gRPC, it's nice that it should be able to transition from a normal LND node to a more restricted account without any software changes, only a change in macaroon. With that being said, I would also expect any feature in LND that doesn't have to do with node management or channel management or on chain activity to work. We have this issue, as well as #533 that caught me off guard when I found they were not supported.

There are so many applications where you'd want to restrict an application or device to a limited account, but still allow it to use basic lightning network features. The application may be software with limited trust in the developers or a device that is freestanding in public. I shouldn't need to allow every point of sale machine in public to have access to all invoices on a LND node, only the invoices that it has generated. Or, you might just be developing your own application software and want to use a more limited account because you want to develop on mainnet and not testnet.

Ok thank you for sharing your perspective, makes a lot of sense! We'll make sure to take that into consideration when prioritizing features :).

If #632 is related , possibly #505 is also related.

Thanks for flagging! Sending to HODL invoices shouldn't really be related to this though, as the problem above is related to linking specific invoices to accounts.

[cj-chua]

Chiming in here - I think lit account macaroon is very underrated at the moment and it could be big in future. Indie hackers building on lightning would feel more comfortable using their node for side projects because funds loss from application error is capped by the amount in the lit account. Similarly LSPs managing huge sum of customer funds could utilize lit accounts to greatly strengthen security (as well as minimizing loss from application errors)

I actually use lit macaroon for all of my side projects. But for each project I also have another LND macaroon with minimal permissions to support grpc calls that the lit macaroon doesn't support. So I have to manage code paths for 2 macaroons for each project 🙃

I think the adoption of lit accounts will speed up a lot when a lit macaroon could be used as a drop-in replacement for a regular macaroon. This is my 2 cents

[AndySchroder]

Another application for LND Accounts is live and video demos. It's much easier to create an LND Account that do other macaroon scoping and then share the limited scope macaroon publicly with a much lower risk, or more quickly deactivate the account before publishing the video or right after the live demo is over.

It's also a way to give a temporary working demo to someone to test or help someone learn to develop on lightning without needing to give them access to a full node (not requiring them to figure out how to get a full node setup just to see if they want to develop on lightning). Or, you might want to limit the scope of node access to people doing development work for you.