Sounds very elegant. Would love to have this happen under the hood in our cashu dependencies, so that we don't get rate-limited by the mints as much.
Earlier spam mitigation strategies involved mints in the local network that are backed by global mints and don't keep their keysets as long as the global mints do. However, the "channel" based solution would vastly reduce the complexity for us if it just works..
I'm only just this morning properly reading NUT-11 (P2PK). I didn't realise that it's possible to make a signature only to a specific combination of proofs; basically I kinda knew about SIG_INPUT in Cashu but not SIG_ALL. But I think I see now, also thanks to calle's message just above.
(As I'm new to this, I'm just obsessing about the ideas that [I think] I understand, and therefore I'm likely misunderstanding a lot of what others have said in this thread)
I might have another idea, which might be possible in current Cashu. Just thinking out loud:
A and the mint prepare a set (a few dozen) of BlindSignatures with P2PK for a variety of denominations - large denominations (many sats) and small denominations (millisats).
At any time, A can take a subset of those (e.g. 32 sat + 8 sat + 1 millisat) and sign the collection of those and give the signature to the router, giving the router unilateral exit to take the value in that set of proofs
Later, A can update the balance by taking a set which has a larger total value (e.g. 32 sat + 16 sat + 1 millisat) and giving the updated signature to Bob
It's important here that the new set has some overlap with the older set, in this case the 32 sat and the 1 millisat are in both the new transaction and the old one. This overlap ensures that the router can't exit with *both* sets; the mint will notice that the second signature is for a particular Proof that has already been spent
Every time A creates a new set of proofs and signs that collection, A must ensure that this set has an overlap with every one of the previous sets that A has signed. This ensures that B can only redeem via one of the many signatures B has got from A.
To satisfy the overlap constraint, maybe we could simply have a single 1-millisat proof that A includes in every set
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...
