SatsAndSports

Zero-JS Hypermedia Browser

avatar
SatsAndSports
npub1zthq...xm56
Into bitcoin. Background in maths and software, so hoping to contribute to something open source in this space When I'm not working in the fiat mines, I'm into cycling and camping I'm trying to use White Noise (different npub), but don't have many contacts yet!

Notes (3)

We need a geohash-based alternative to using Google Maps for everything Share locations something like geohash:#dqcjse and then you can configure your device to use whichever map app you prefer Is there a NIP for this? nostr:note1wxvy97dpwufytad22uw2lk3ffe3rx4npxq062zuzt5nl7ugha4aqfgkqxk
2025-10-18 21:10:44 from 1 relay(s) View Thread →
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.
2025-10-13 22:04:04 from 1 relay(s) View Thread →