Maybe this can be made bi-directional. To do so, we need a way to make older transactions revocable, just like in Lightning.
In Lightning, a transaction is revoked by revealing a preimage, such that the preimage allows the honest party to take all the balance (I might be slightly oversimplifying there)
The mint has functionality to check which tokens have been spent *and with which secret*, and that might be the mechanism we can use to ensure that the honest party sees what the dishonest person has done and that the honest party has sufficient data needed to get their money back
Replies (3)
I’m new to Cashu. But I feel like this could be much simpler.
Here the mint is the rule enforcer, isn’t he? Could this work:
A = user. B = service provider.
1. Say A locks 1000 sats with the mint for B using B’s pubkey as a 2/2 multisig (enforced by the mint). Let’s give a unique identifier for this lock. lock_21
2. The mint gives a receipt to A signed with their pubkey. This receipt contains the lock id, amount, B’s pubkey, timestamp and a future timestamp (valid until).
3. Now A sends this receipt to B when they first interact with each other. B can verify that the mint signed this receipt. And start providing services.
4. Everytime A wants to do a micro payment, A signs a message with lock id (lock_21), nonce and amount then sends it to B.
5. After many many txns, B goes to the mint, submits all the messages and claims the amount they’re supposed to receive from the locked tokens. A can then withdraw the remaining funds from the mint with B’s closure signature (happy ending) or after the locked funds expire.
6. B cannot be malicious here at all. A cannot be malicious here either as they cannot withdraw funds before the expiry of locked funds.
Mints can offer this service for a fee maybe.
Pls correct if this has some major loopholes 😅
Your idea looks like it will work, yes. But I think it would require support from the mints to add the necessary functionality. The other methods proposed here can work with existing mints (as long as they support P2PK)
It might be possible, or even easy, to get mints to support your idea, so go for it!
Sounds like it could work but the mint would know that a channel is being setup and it would have to track all that state as well (which should incur fees for the service).
Our modus operandi is that the mint should know as little as possible about what's happening between users and that most complexity should be offloaded to clients to keep the mint simple and easy to run. It also decreased the anon set if the mint can differentiate the different usage patterns of users.
My sketch above has only two interactions with the mint: open the channel (the mint doesn't know that this is a channel yet because it's blind-signing) and close it (at which point the mint knows it was a multisig coin with second spend path which is a timelock).
