EarthBucks Pay Supports Bitcoin Cash Now
2026-10-17 · Ryan X. Charles
Two days ago, we wrote that you already have a Bitcoin Cash wallet. We also wrote that the better way to send BCH is EarthBucks Pay. That is now possible. Open Pay, select a person, and send them BCH with a message.
This is the largest change to Pay since we made it a messenger. We rebuilt the full send path. This post explains:
- What a message can carry now.
- How you control who can send to you.
- How Pay sends a message from server to server.
- What we did to make each send safe.
- What comes next.
What a message can carry
Each Pay message has a note and an attachment. The note is encrypted in your browser, as before. The attachment is the postage: the price that the sender pays to get the message to you.
Select the attachment next to the amount field. The attachment dialog gives these choices:
- EBX: the recipient gets this EBX.
- BCH: the recipient gets this BCH.
- EBX and BCH: one message can carry both.
- Proof of work: your browser does work for the recipient’s server, and the work pays the postage.
- Nothing: only when the recipient made you a contact.
Proof of work can also go together with a payment. Then the work pays the postage, and the payment can be any amount. For example, you can do the work and attach a small gift of 0.001 BCH.
Each message in a thread shows what it carried, such as 0.5 EBX · 0.001 BCH
or 70M PoW. A message with nothing attached shows only its note.
Send BCH to a name
With the BCH wallet alone, you send BCH to an address. With Pay, you send BCH
to a name, such as alice@earthbucks.com. You do not copy random
characters, and you cannot paste an address for the wrong coin.
The payment also goes directly to the recipient’s server, with the message. The recipient does not search the blockchain for it. This is the “give the check to the recipient” idea from our last post.
Each BCH payment goes to a new address of the recipient, which comes from their master key. Thus no two payments share an address, and the blockchain does not connect them.
BCH confirmations in a thread
A BCH payment can revert before it gets confirmations. If this occurs, the thread shows the payment struck through, with “Reverted”. If the network refuses a payment, the thread shows “Rejected”. The balance of the BCH wallet corrects itself.
You control who can send to you
In our earlier post, we said that a payment is a better spam filter than proof of work, and that one network minimum of 0.01 EBX would apply to all users. We kept the network minimum, but there are now three of them, and each user can raise their own. We also brought proof of work back.
Each user can raise their minimums
Each user has three minimums. A message must meet one of them:
| Minimum | Lowest value |
|---|---|
| Minimum EBX payment | 0.01 EBX |
| Minimum BCH payment | 0.0005 BCH |
| Minimum proof of work | 70M |
Each minimum starts at its lowest value. Change them in Settings, under Pay. You can make each minimum higher, but not lower than its lowest value.
Your minimums are your price for your attention. A person who gets many messages can make the price higher.
No minimum can be 0. A minimum applies to every sender in the world, so a minimum of 0 would let every spammer send to you for free. To let one person send to you for free, make them a contact (see below).
When you open a thread, the composer gets the recipient’s minimums, and the amount field starts at their minimum. Thus your first send is usually correct. The bar at the top of the thread also shows the recipient’s minimums for you.
Proof of work is back, as a choice
We still think that a payment is better postage: the money goes to the person whose attention the sender uses. But a new user has no EBX and no BCH. Without proof of work, that user cannot send their first message.
Thus proof of work is now a choice. Your browser solves a puzzle for the recipient’s server, and that work pays the postage. It can take some time, but it costs you no money. Each solved puzzle pays for one message only.
Contacts send for free
At the top of each thread, there is a Contact switch next to the person’s name. Turn it on to put that person on your allow list. A contact can send to you with nothing attached. They can still attach a payment if they want to.
A minimum and a contact are different things. A minimum applies to every sender. A contact is one sender that you select. Free messages come only from your contacts.
From server to server
Pay now sends each message the way that email sends each email: from the sender’s server to the recipient’s server.
When alice@earthbucks.com sends to bob@earthbucks.com, the server of
earthbucks.com calls the public API of earthbucks.com. It does not read Bob’s
data from its own database. It uses exactly the same steps that it will use
to send to bob@example.com on a different server.
In short, the steps are:
- Prepare. The sender’s server asks the recipient’s server for the recipient’s minimums, a payment address and a message key.
- Sign. The sender’s browser signs the payments, signs the message header, encrypts the note, and solves the proof of work if it uses one.
- Notify. The sender’s server tells the recipient’s server that a message is ready.
- Pull. The recipient’s server gets the message from the sender’s
domain. Thus a message from
alice@example.comalways comes from example.com, and nobody can send a false message in Alice’s name. - Accept. The recipient’s server checks the postage against the recipient’s minimums and allow list. Only after it accepts the message does it broadcast the payments.
The recipient’s server and the recipient’s browser both check the signature of each payment over the message header. Thus a payment cannot be moved to a different message.
We wrote the full protocol down, and our tests send messages between two servers with different domains.
Your old messages
Your old Pay messages stay in your threads, and you can still read them. Old and new messages show together in one list. The old send path is removed: every new message uses the new protocol.
Safe sends
Money and networks do not always agree. A connection can drop after the server sends a payment but before your browser gets the answer. We did much work to make sure that this cannot make you pay two times, or lose a payment. Some examples:
- A lost answer. If your browser does not know whether a message went out, it keeps the full signed message and sends the same message again. It does not make a new payment. The recipient’s server knows the message, and it does not accept it two times.
- A refused message. If the recipient’s server refuses a message, it does not broadcast the payments. If your browser cannot be sure that a BCH payment was not broadcast, the withdrawal stays pending in your wallet, and it does not show as spent or as returned too early.
- A false transaction. Your server builds the EBX transaction, but your browser checks it before it signs. It signs only a transaction that pays the recipient the amount that you typed, with the change to your own key and no fee.
- A false address. When a server calls a different server, it connects only to the public address that it checked, and it confirms the certificate of that domain. Thus nobody can point a server at a private network address.
- Clocks. Your computer’s clock can be a little different from the server’s clock. Proof of work allows one minute of difference.
What comes next
Today, only earthbucks.com runs Pay. The protocol is ready for more servers, but one limit remains: a second server needs its own access to the EBX network to check and broadcast EBX payments. BCH has no such limit, because each server can run its own Bitcoin Cash node.
The next steps are:
- More servers. Anybody will be able to run an EarthBucks node on their own domain, and its users will send and receive Pay messages with earthbucks.com.
- Atomic swaps: exchange BCH and EBX with another user, so that both of you get the agreed amounts, or neither of you does.
Try it
- Open Settings and look at your Pay minimums. Raise them if you want to.
- Open Pay and select a person.
- Select the attachment, select BCH, type an amount, and send.
If you do not have BCH yet, deposit some on the Bitcoin Cash page of your wallet first. Or select Proof of work, and send your first message with no money at all.