I've been thinking of 'Cashu Channels', as they might be useful in nostr:npub1zzt0d0s2f4lsanpd7nkjep5r79p7ljq7aw37eek64hf0ef6v0mxqgwljrv to be very efficient in transferring tiny amounts of cashu at an extremely high volume. We want the device and the router to be able to update their mutual balance - without trust - and without needing any communication with the mint. The mint is involved in setting up the Cashu Channel and in closing the channel a few hours later; but the mint is not needed during the millions of tiny cashu-balance-updates in between.
In Lighting, after two parties have set up a channel and their funding transaction is confirmed in the blockchain, the two parties can move balance over and back in their channel with zero communication with any third party; they simply sign updated commitment transactions and revocations. In nostr:npub1zzt0d0s2f4lsanpd7nkjep5r79p7ljq7aw37eek64hf0ef6v0mxqgwljrv , this could be useful as the device needs to send tiny amounts to the router at very high volume. In our Tollgate use case, we may want to support billions of such transactions and we want zero communication with the mint during this time.
This isn't possible in Cashu today, but I feel like it could be supported with the right NUTs.
Let's simplify by having all transfers in one direction, from A (my phone) to B (the Tollgate router). Initially, with the cooperation of the mint, A "locks up" some of their cashu in a special 2-of-2 multisig token that can be spent with the cooperation of A and B, and which reverts to A after a suitable delay (a few days?).
Now the 'Cashu channel' is active and they don't need to talk to the mint any more. Each time A wants to transfer a tiny amount of Bitcoin to B, A signs a updated 'commitment' transaction:
"Of the original 50,000 sats in the 2-of-2 multisig, A agrees that 2,315 of those sats can be redeemed unilaterally by B. Signed, A"
Instead of immediately redeeming though, B just continues providing service to A and A continually updates the balance and signs the updated commitment transaction, adding a few (milli)sats each time.
Finally, to 'close the channel', B can take the latest signed 'commitment transaction' and get a few sats from the mint, and A is seperately able to approach the mint for the remainder of the sats.
I've been trying to squeeze this into the exiting Cashu protocol, where a Cashu 'proof' could be sent over and back an arbitrary amount of times with something like Lightning's revocations, but I can't see how to make it work trustlessly.
I don't think you need a channel just locked tokens to the tollgate public key, along side your public key for recovery and a timeout.
you keep the tokens in your reserve and send them as you need. What ever tokens you don't send just need to wait for the timeout for you yo take them back.
you can also do that with HTLCs but I think that is over complicating it in this case.
True the word channel can be misleading. I think nostr:nprofile1qqsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpesppemhxue69uhkummn9ekx7mp0qyghwumn8ghj7mn0wd68ytnvv9hxgtcpr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0efx0jg had something along the lines of what you described in mind (no HTLCs)...
I like that the tokens stay on the client side until they are spent in what you described here. this way the client doesn't need to race the vendor to redeem un-spent proofs.
I think earlier versions of this idea involved over-payment with time locks and trust-less recovery of un-spent proofs, but those solutions were more focused on cash back rather than reducing traffic to the mint...
I don't want a situation where the mint needs to create millions of milli-sat tokens in advance.
I'd prefer to build a smaller set of tokens (1 millisat, 2 millisats, 4 millisats, 8 millisats, ... 1024 millisats ) in order that millions of different combinations are possible with only a small number of tokens.
At one moment in time, three of those tokens (1+2+4 = 7 millisats) "belong" to the router. Next, to move the balance up to 8, we need a way to send the 8 millisat token to the router, *where the router somehow revokes its access to the 1,2,4 -millisat tokens*. That's the challenge; the device gives access to a subset of the tokens, where the router can later 'revoke' its access (like in Lightning) in return for an updated - more valuable - set of accesses
