Looking forward to our next co-working session to better understand NUT-11, Spielmann channels and the trade-offs of various approaches.
Join us if your interested in this and looking to hack in Berlin:
https://signal.group/#CjQKICR6RaghMyOJSoigj7HJ2Hud1HPBAWdBMmhvmTgMrHIeEhCWrRCsNNix4EXftaD8LPRl
I've written up a more concrete proposal for this as a PR, I think it's a combination of multiple ideas from this thread:
Thanks for this detailed explanation. The double spend section helped me to understand how sig-all and the re-used proof work. It's beautifully simple 😀
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
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).
Okay i didn’t realise your sketch didn’t require changes to the mint software. I was thinking about it more like UTXOs where each spend is a UTXO and the service provider can redeem these UTXOs. But it’s similar to what you guys have proposed.
This would be great for Routstr by the way. We will be able to perform 100s of requests without being rate limited by the mints.
One advantage the UTXO design would have is that the service provider wouldn’t need to interact with the mint to verify that the channel is opened (cuz mint’s pubkey signs the message) but i guess we can do this by adding it to the spec you guys have proposed.
you don't need to talk to the mint in my example either, just need to check the DLEQ proof to verify the coin
nostr:nprofile1qqsdxpfv503a2ga3ajqxw843hws9z7302ghpj4mcmjpa6qagmp9pwrspzamhxue69uhhyetvv9ujuurjd9kkzmpwdejhgtcg47gk0 I want my bitaxe to spend Spiel e-hash on internet access..
I'm sorry what? Yo dawg...
