I want users to have fully non-custodial browser wallets. The wallet should be able to prepare payment authorizations for a service in advance, for example:
20 sats for the interval 13:23–13:24
20 sats for 13:24–13:25
20 sats for 13:25–13:26
Ideally, these authorizations could be generated upfront for a long period (e.g. a week or even a month). Later, while the user is offline, the service should be able to redeem (“sweep”) only the authorizations corresponding to the time that has actually elapsed. The service must not be able to increase the amount, change the recipient, or create additional payments.
My first idea was to use pre-signed arkoor transactions, but from reading the SDK it seems that this isn’t possible because new Ark rounds invalidate previously prepared transactions, and I couldn’t find any public API exposing this functionality anyway.
Then I looked at the Lightning payment flow, where it seems there is an intermediate state (HtlcReceived) before the payment is actually initiated. That looked closer to what I need, but again I couldn’t find a public API that would let me prepare these payment capabilities in advance and hand them to another party.
Is there a protocol-supported way to solve this problem? Or would Bark/Ark need new primitives for “pre-authorized future payments” or “redeemable payment capabilities”?
My goal is to keep the wallet completely non-custodial while allowing an unattended service to collect only the payments that the user has already authorized.
After experimenting with different approaches, I’ve come to the conclusion that the simplest solution server wallet with something like VLS, but for Ark - VAS? The user defines and approves spending policies in a separate key manager. Whenever a payment is requested, the key manager evaluates it against those policies and signs it if allowed. Unfortunately, this requires a small Bark wallet fork to extend the local signer with an external one, but it is a relatively thin overlay rather than a major architectural change.
@okmaybenot Unfortunately it looks like this wouldn’t be possible without a non-insignificant amount of work on our side to enable cosigning the presigned payments server-side. It’s not anything we can prioritize right now, but we can look at it again if we see a lot of demand for it.
If you have any other approaches for your use-case, swing them by us.
What do the team think about factoring out keys from the wallet with some trait, to have a way to sign with remote keys? Ideally, I’d rather not maintain a fork for this; maybe it’ll be useful for something else?
Unfortunately factoring out the keys runs into the same problem: signing in bark is stateful and multi-step, so it’s a similar amount of work to the cosigning route.
Another thing you will want to consider, per-minute Ark payments build long exit chains, which can get prohibitively expensive to exit on small balances, and ultimately the server caps chain depth. Lightning can still be better for streaming payment applications. For Ark you’d want a lower frequency, to avoid regular refreshes, perhaps with refunds for unused sats.
per-minute Ark payments build long exit chains, which can get prohibitively expensive to exit on small balances, and ultimately the server caps chain depth.
I’d like to know more about this limitation, maybe an article in the blog someday? Especially with calculations. It’s a non-obvious one from the perspective of the high-level interface.
Lightning unfortunately is too expensive to manage, probably some limited form with unidirectional non-routing channel will be ok, but I’m not sure it exists somewhere. Probably I’ll try to stay with Ark and switch to per-hour billing.
We started working on a guide on how to enable may payments from a single bark wallet.
One of the questions that often came up is. Why don’t we just put this in our product by default?
Another thing you will want to consider, per-minute Ark payments build long exit chains, which can get prohibitively expensive to exit on small balances, and ultimately the server caps chain depth
We improved the wallet and did manage to solve this problem.
The improvements have been released in v0.6.2.
For more details I refer you to MR 2397