Knock, knock. It’s Cashu, Bitch@
Calle teased a Bitchat application that natively supports Cashu payments. How does it work?
I think there’s something brewing on the internet. Well, thousands of others do as well, but I will claim that we called it first.
If you’re on Nostr, or the Bird app, you might’ve seen the newly released Bitchat application from Jack Dorsey. It’s quickly gone viral and has caught the attention of a number of devs in the space. Calle, the creator of Cashu, has been building Bitchat’s android implementation and… you guessed it:
A native Ecash wallet is built into the Bitchat mobile application.
Bitchat combined with Chaumian E-cash has the potential to create a new tool for anonymous, offline payments on mobile devices. What used to require pigeons can leverage noise. What used to require paper notes can leverage Chaumian E-cash.
Here’s my take: Bitchat and Cashu are a promising tool for anonymous, offline bitcoin payments. There’s tradeoffs, but in certain situations, they can provide users a convenient way to transmit value offline. This can even be critical infrastructure in times of crisis.
And funnily enough, our team was debating this combination’s capabilities a few hours before the announcement was posted. This piece is a reflection of those discussions.
Breaking down Bitchat
Bitchat is a peer to peer messaging app that uses Bluetooth to send messages to nearby peers. The tech stack for it is built in three different layers: Bluetooth mesh networking for message sending and receiving, the noise protocol for private communications, and ephemeral peer IDs for ensuring identities are only provided to those you trust.
Bluetooth mesh networking
First is a bluetooth mesh networking layer. A mesh network is a local network created between local, co-located peers. Different nodes (mobile phones or laptops with bluetooth chips) find and connect to each other. Once connected via Bluetooth and the networking protocol, they can transfer data amongst themselves.
In a mesh network, each phone is both a sender and a relayer of data packets. This means that a device can either be the recipient of a piece of data, or can relay this piece of data to another recipient in the network. Individual Bluetooth ranges are limited, so this local-peer relay feature extends the reach of each peer in the network past what their device is capable of on its own.
Here’s a quick example. Alice needs to send a message to Charlie, who is 200 yards away. In between them is Bob, who is 100 yards away from each. Alice, Bob, and Charlie are all on the same mesh network. Alice sends the message out over the broadcast band, Bob relays it, and Charlie receives it. Once Charlie has the data, they’re ready to decrypt it and read what’s inside.
For the encryption and decryption of the data packets that are relayed across the network, bitchat uses noise.
Noise protocol
The Noise Protocol was pioneered at OpenWhisper Systems, the founders of encrypted chat app Signal, as a framework for establishing encrypted communications between two peers who want to exchange private messages.
It’s primarily a “handshake protocol” which allows two peers to use the Diffie-Hellman key exchange in order to establish a secure, encrypted connection for ongoing private communications. Using just Diffie-Hellman key exchange, the Noise protocol enables end-to-end encryption, forward secrecy, identity hiding, and authentication.
Bitchat uses a 3-step Noise XX handshake. Users establish a secure channel (known as Noise sessions) between each other, all subsequent messages exchanged between them will be private communications.
To establish this connection, one peer initiates the handshake phase, the other peer responds. After a successful 3-message handshake, the peers are able to continue communicating using a shared encryption key.
The session is rekeyed, or “refreshed”, after 10,000 messages or a timeframe of 1 hour enabling strong forward secrecy.
Ephemeral peer IDs
Bluetooth allows peers to exchange data packets; the Noise handshake protocol allows for peers to encrypt messages into those data packets. Now how do you know who you’re talking to, but maintain anonymity over time?
Insert Ephemeral peer IDs.
Ephemeral peer IDs ensure the rotation of peer IDs within some time frame. This means users’ IDs within a chat change periodically during random intervals. In Bitchat, this happens every 5-15 minutes or when a session terminates. Bitchat’s session management framework ensures that these peer IDs are appropriately discarded after a session has expired.
During a noise handshake, the application links the current ephemeral IDs and maps them to a SHA256 fingerprint of the respective users’ public keys. This ensures that even after a session expires, users who have authenticated their relationship can retain a persistent identity for each other. Users can also assign social names to their peers whose relationship has been authenticated.
Users can maintain secure relationships with their peers, while preventing tracking in the broader network.
Bitchat enables fully offline, private transfers of data
With Bluetooth for mesh networking, Noise for encrypted channels, and ephemeral ids for identity, Bitchat enables users to connect and send encrypted messages through a broader peer-to-peer network. Users do not reveal themselves to network participants unless a secure connection is established.
Bitchat can be useful in a wide range of circumstances. It can be used in situations where internet infrastructure and cell towers are not functioning. Or, it can be used in more mundane circumstances - like when you’re at a concert and your cell signal isn’t coming through.
For the privacy conscious, it provides an alternative to internet-based encrypted chats. Connecting through Bluetooth means that you don’t expose your location to local cell towers.
If only we could maintain that level of opsec when sending bitcoin around…
Combining it with E-cash
Calle demonstrated another use case for Bitchat yesterday: transferring bitcoin-backed tokens across a mesh network while offline.
Calle invented the Cashu protocol in 2022, a Chaumian e-cash payments protocol which enables users to use bearer tokens to transfer funds. Chaumian payment systems rely on a mint, which holds the underlying asset in exchange for e-cash tokens which users can use as payment instruments. Bitcoin-denominated e-cash mints hold user deposits of on-chain Bitcoin. The mint operator is expected to secure the funds until redeemed by e-cash token hodlers and keep the bearer tokens in the mint pegged. Mints are also responsible for not issuing more e-cash tokens than they have bitcoin holdings. It’s expected that the value of e-cash tokens in circulation match 1:1 with the mint’s on-chain bitcoin balance. By removing on-chain custody concerns, e-cash mints lower the barrier to entry for setting up bitcoin custodial services for friends, families, and communities.
The Cashu protocol provides a feature for offline payments. If a sender doesn’t have an internet connection, they can still transact using e-cash by sending the token to the receiver over a communication channel; bluetooth or NFC are both common local comms channels for sending e-cash tokens. But, there is a catch with using e-cash offline. One of the peers in the payment needs to be online to finalize the exchange.
Example 1: Offline receiver, online sender
If the receiver doesn’t have internet access, the sender can lock the tokens to the receiver’s pubkey. Cashu’s Pay-to-Public-Key (P2PK) feature allows users to lock e-cash tokens to a receiver’s public key. Only the receiver’s private key can produce a valid signature to unlock the e-cash.
Let’s walk through an example from the documentation. When a receiver is offline, the sender constructs a transaction to pay to the offline receiver's public key. Then the sender forwards the transaction to the mint with the recipient’s public key embedded as a secret. The mint then provides a blind signature on that secret enforcing that the receiver is the only party that can unlock the funds. The sender takes this transaction, blind signed by the mint, and sends it over to the receiver who can uniquely produce a signature to unlock the E-cash tokens.
{
"amount": 1,
"secret": "[\"P2PK\",{\"nonce\":\"859d4935c4907062a6297cf4e663e2835d90d97ecdd510745d32f6816323a41f\",\"data\":\"0249098aa8b9d2fbec49ff8598feb17b592b986e62319a4fa488a3dc36387157a7\",\"tags\":[[\"sigflag\",\"SIG_INPUTS\"]]}]",
"C": "02698c4e2b5f9534cd0687d87513c759790cf829aa5739184a3e3735471fbda904",
"id": "009a1f293253e41e",
"witness": "{\"signatures\":[\"60f3c9b766770b46caac1d27e1ae6b77c8866ebaeba0b9489fe6a15a837eaa6fcd6eaa825499c72ac342983983fd3ba3a8a41f56677cc99ffd73da68b59e1383\"]}"
}In the snippet above, we have an “amount”, a “secret”, a “C” or blind signature from the mint, “id”, and “witness” field.
The “amount” is the amount of e-cash being spent in the transaction. In this example we have a value of `1`, which would be 1 satoshi for a bitcoin-denominated note.
The “secret” is the receiver's public key.
When the sender sends the transaction to the mint, the mint produces a blind signature, that is stored in proof “C”. Only the recipient can produce a valid signature to unlock the funds sent to their public key.
Upon coming online, the receiver of the e-cash token produces a signature on the serialized string of data in “secret”, which is then added to the witness field.
In this example, the receiver is unsure if the blind signature in field C is actually a valid signature from the mint. To prove this, we can leverage DLEQ, or Discrete Log Equivalence, proofs for each signature. These proofs allow us to verify the mint’s signature belongs to the mint’s private key, without having to come online and verify the signature with the mint. The receiver can have confidence that the e-cash token she received is a valid token for the mint.
This example requires the sender to be online to send this P2PK transaction, as the mint needs to produce a blind signature that is locked to the recipient’s pubkey.
Example 2: Offline sender, online receiver
Online senders can send to offline receivers using the P2PK feature of Cashu. Is the reverse possible? Can an offline sender pay an online receiver? Turns out, this is also possible.
An online receiver can generate a payment request for the offline sender. The sender creates a transaction locking an e-cash token to the receiver's public key. Now, the receiver sends the transaction to the mint, and gets the blind signature from the mint operator to enforce the spending condition. The receiver displays this payment request to the sender, who equally can verify its a valid request and fulfill the payment. The recipient can then take this payment, go to the mint, and claim, or “melt”, the tokens into their own wallet.
The reverse of this example also requires the mint to enforce the spending condition. The receiver needs to be online to finalize the transaction with the mint to ensure that the sender cannot double spend the coins. Until the receiver has melted the e-cash tokens, the receiver has no guarantee that the sender hasn’t sent the same e-cash tokens to a different party.
There’s a few other considerations
In both examples, one party needs to be online to finalize the payment. There are also some other considerations for offline payments:
Users are restricted to the denominations held in their wallets. To split the denominations, you need to directly interact with the mint to create e-cash tokens of different amounts.
Users can’t spend newly received tokens until they come back online and “melt” the tokens into their wallet balance.
If the mint operator is also offline, we’re trusting that they have the necessary back ups to come back online.
If the mint operator is offline, no transactions between peers can be finalized.
So is Cashu over Bitchat a permanent, “we’re offline for months” solution? Probably not. But in certain circumstances, sending E-cash tokens while offline is a viable option for parties who don’t have, or don’t want, access to the internet.
Example #1: I need to pay my friend for a beer at a concert but I have no cell signal cause there's 10000 people. He went to another stage with less people and had service. So I just message him an E-cash token worth a few thousand sats that he can finalize since he’s got some service.
Example #2: A hurricane just hit, and my family doesn’t have gas for our generator. I need to go into town to get some. I go into town, but I forgot the wallet on my phone doesn’t have any E-cash 🤦 So I open a chat with my wife, and the merchant, via Bitchat and have her forward the E-cash to the merchant directly. The gas station has power (their generator is on), so they are able to connect to WiFi. The payment gets finalized with the mint and added to the merchant’s wallet.
Either way, both of these exchanges can be communicated through Bitchat. No internet connection needed for the sender. And, since connecting through the bitchat mesh network is able to extend an offline party’s reach, there are dozens of other scenarios where an offline sender, or receiver, could use the Bitchat/Cashu combination to exchange value.
But we’re all friends and family here… would they really double-spend me?
There seems to be some misconceptions around whether one of the participants in an E-cash transaction needs to be online. Yesterday, I thought both parties could be offline. But after chatting with niftynei and Tuma, and looking through the protocol specifications, I was able to see that one of the parties needs to be connected to the mint to ensure that the transaction can finalize (as pointed out above).
Bitchat enables users to establish secure communication channels with people that they trust: friends, contracts, etc. If you’re communicating or transacting with parties that you trust, you can continue to transact while both parties are offline. As long as the e-cash tokens aren’t duplicated, they can theoretically be exchanged completely offline and redeemed, or melted, into a user’s wallet once reconnected without issues.
What if wallets embedded in the bitchat application allowed offline-to-offline payments between parties that have secure, verified connections with one another? You’d have to trust that each party’s bitchat app wasn’t saving copies of forwarded tokens, but it’d work.
In the hurricane example above, if neither the merchant nor I have an internet connection, we’d be able to use this fully-offline mode of bitchat to create a transaction for me to pay the merchant. The merchant then communicates with the mint when they regain an internet connection to claim the tokens.
The sender needs to be honest in this scenario and not double-spend the receiver if the sender comes online first. And, current wallets may not even allow sending unmelted notes. But if it can work, the example above could be a way for peers to transact, fully offline, in a trusted, communal environment.
Ack the tradeoffs, enjoy the ride, and hell, use it (if you want)
E-cash over Bitchat is a cool experiment. Offline payments are a huge unlock for E-cash, and the synergies with the Bitchat application are promising.
One of the participants in the transfer needs to be online. Through Bitchat’s networking capabilities, we can extend the range that the offline party has to make, or receive a payment. This a new frontier; not just for bitcoin, but for the broader payments application space as a whole.
There’s an explicit tradeoff that bearer tokens used in E-cash are not native bitcoin. We must follow the developers’ lead and continue to honestly tell users that the protocol is custodial. But using bitcoin off of the mainchain is always about tradeoffs.
Within certain circumstances, Bitchat and Chaumian E-cash can provide (maybe at times critical) temporary payments infrastructure. It’s also a user-experience improvement for those who simply don’t have (or want) an internet or cellular connection for a period of time. Offline mode payments would give them the freedom to transact off-chain in an open, albeit trusted, manner.
Cashu and Bitchat are not dependent on each other. Both solutions can continue to be developed and gain more adoption, completely irrespective of their counterparts' success.
But come on, the fact that someone sent an E-cash token through Bitchat makes a kid wonder about the future of fully offline payments.
And can you blame him?