I still can't believe we're having an ecash btc++ conference in two days.
Just a year ago we were merely a handful of nutcases. Now we have a whole ecosystem to build on. Incredible.
I've been thinking too much about NFC payments lately. It would be insane if we could achive card-to-terminal payments one day but I think challenges with storage and coin selection make the naive approach (store nuts on card, terminal takes them out) infeasible in the short term. However, we can still achieve a lot with phones.
The naive approach with phones would be to send the nuts directly via NFC form device to device. This is possible in Android through Host Card Emulation (HCE) where one phone can pretend to be an NFC card with data on it (the nuts) and the other phone simply scans it. Unfortunately, Apple will never allow us to use their (your!!) hardware for HCE so we shouldn't depend on it.
There is an alternative approach though, which use payment requests. Payment requests are a work-in-progress Cashu NUT protocol update. They are generated by a receiver to tell the sender how to send them nuts. They include information transport methods (how to reach the receiver), optional amount and receiver pubkey. For example, a payment request can say "send 100 sats to this HTTP endpoint, or DM this pubkey on nostr". It can also include instructions to lock the tokens to a pubkey. A payment request can be shared as a QR code, which can be scanned by another cashu wallet that then makes the payment (similar UX like Lightning invoices).
We can use payment requests in combination with NFC to make a very good payment UX that works with Android, iPhones, and on the web (webnfc). If we put a payment request onto an NFC card, that card can be scanned by a sender's phone. The sender's phone could then do the coinselection and send the nuts via nostr to the receiver, for example. This would basically be almost instant. A web wallet like cashu.me could even generate payment requests and store them on an NFC card (from the browser) which another cashu.me wallet could scan (also from the browser) to make a payment. A little bit like a cursed PoS system.
Should be further explored!
Awesome feedback! nostr:nprofile1qqsdmup6e2z6mcpeue6z6kl08he49hcen5xnrc3tnpvw0mdgtjemh0spz3mhxue69uhhyetvv9ujumn0wd68ytnzvuq36amnwvaz7tmjv4kxz7fwdehhxarj9emkjun9v3hx2apwdfcqzynhwden5te0danxvcmgv95kutnsw43qvqle0h is the amazing dev behind npub.cash
π’ sovereign.app and Chamberlain mint release with a nice blog post by nostr:nprofile1qqsxkxud4s60l3sagexlamcquj5y5czwzuh0vwglkc5jj0t0zenpfrqprdmhxue69uhkx6rjd9ehgurfd3kzumn0wd68yvfwvdhk6qgdwaehxw309ahx7uewd3hkcqg5waehxw309aex2mrp0yhxgctdw4eju6t0pz6090.
Let's see some Nostr clans!
nostr:nevent1qqs8wpemmpvu9wyn6fcqsx0g2hjl97kaghcvkj8xcgyxa9mwjxm5ruqppemhxue69uhkummn9ekx7mp0qgsxkxud4s60l3sagexlamcquj5y5czwzuh0vwglkc5jj0t0zenpfrqrqsqqqqqpgt44un
Let us pay in ecash. Paywall receives ecash, burns it and receives on LN. Just two simple API calls (see NUT-05) or you use cashu-ts and it's almost trivial :)
It's could be as straightforward as "paste token here" in the beginning. Eventually (I hope soon), we will have NWC for ecash operations and ecash payment requests so that it's more convenient to pay ( nostr:nprofile1qqsdmup6e2z6mcpeue6z6kl08he49hcen5xnrc3tnpvw0mdgtjemh0spz3mhxue69uhhyetvv9ujumn0wd68ytnzvuq36amnwvaz7tmjv4kxz7fwdehhxarj9emkjun9v3hx2apwdfcqzynhwden5te0danxvcmgv95kutnsw43qvqle0h is the man here).
I'm not aware of what lightning pre-pay is but if you mean "you pay upfront" it's that with pre-locking, you don't pay yet. If you don't end up paying, you wait for the timelock to expire and redeem it back yourself.
Here you go: https://github.com/cashubtc/nuts/blob/main/11.md
There are a few apps that use it already, it's pretty simple in design: put the NUT in an X-Cashu header, make the middleware read and receive it, and let the request through. I'm not aware of a comprehensive middleware that you can just plug and play but there are many libraries available depending on what you're building.
check this out: https://proxnut.com/
That's very interesting, it would indeed be very useful for mints not having to reveal their UTXOs for a proof of reserves. Thanks for noting that.
I haven't been able to look at your protocol yet so I have a rather basic bunch of questions that come to mind:
- The ~55 Mb keyset file you load seems to have information up to a certain block height. Is this file generic for the entire chain or custom to the prover?
- The processing of the file takes quite some time and you mention this can be done once and proofs can be checked faster after that. Does the client need to do the processing or could someone else do it for them?
- Does it require processing custom to the prover or can it be used to prove anyone's claim?
- Is there a window for cheating when the file is for a lower block height than the current one? Since I don't know the UTXOs, is there a way to make sure the coins haven't been moved since the proof was made?
- The range was from 100k to a power of two, you say it's just the way you set it up. Can the range be arbitrarily precise?
@keychat has pioneered one of my favorite use cases of Cashu today, which is to pay for access to a a nostr relay with ecash. 1 event = 1 sat.
They achieve this without accounts or registration. Your balance is not tied to your identity. You can post from any pubkey. If you want your real sats back on Lightning, you simply burn the ecash with the mint. The next step would be to run their own mint for their relay.
nostr:nprofile1qqsvwct7qgjz7kznled4z02pruvmgjkn7rdftg5dxw5m06f87f2a6tgpr3mhxue69uhkummnw3ezumt4w35ku7thv9kxcet59e3k7mgpp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfdufyudzh can upgrade cashu-ts and it will accept the new cashuB format as well :)
nostr uses x-only keys (32 bytes) which don't have the first '02' byte, wheras cashu uses compressed pubkeys (33 bytes). I doubt that `.splice(2, -1)` removes the last byte.
Oddbean new post about login | logout
Notes by calle ποΈβ‘ποΈ | export