Ways to improve UX / tech of CashFusion

Technical
#1

I’ve been looking at CashFusion every now and then and I’m personally convinced it is by far the best anonymity solution in crypto. Well, it does have severe problems. But it could be the best solution. So here is my thinking on what we can do to improve it.

  1. To make more clients use it, drop the usage of Protocol Buffers. The product is horrible for the main thing we need: stability. Just switch to something else.

  2. The protocol is well described but still quite complex. It is straight forward, but there are simply a lot of steps. Where this is a real problem is that some of these steps have a time-limit. You can only open tor connections for N seconds, you have only X seconds to supply your proofs. That kind of timings.
    These timings are open to improvements, which will make it wildly easier to get a mobile client to participate in a fusion round.
    Improvements range from longer timeouts to having more predictable time tables. Things would be a lot easier if a mobile phone that connects to a fusion server and gets told to check back in 60, 200, and 1200 seconds. And the actual fuse starts directly after that 1200s mark. (today the phone would have to talk to the server ever 2 seconds or so and the time the fusion starts is unpredictable)

  3. A wallet can run fusions in the background. For instance if the phone is on charger and wifi. Naturally this depends on the wallet architecture actually being able to run face-less.

  4. A wallet can use the idea explained in New CHIP: 2026-paths (the derivation type) to have a ‘main’ controlling wallet which runs the fusions and a second wallet that is running on the mobile phone.
    So one person has one seed and the desktop has two wallets based on that seed (but different derivation paths). One of those wallets is duplicated by the phone.
    How this works is that the desktop can run fusions and the mobile phone simply notices new transactions coming in that fused his outputs.

  5. Following the setup of (4), the ‘main’ controlling wallet should be able to simply top-up the mobile phone wallet with very little interaction. Always having various utxos in your phone wallet while on the go, meaning you always pay from confirmed ones, and never forgetting to put some extra “cash” in your phone wallet in the morning.

  6. The main reason today a CF round fails is because there are not enough people that joined. Or people left. Especially when a mobile phone starts being able to do background fusions, this problem will largely evaporate. So this isn’t really an action point like the others are, just a point that explains that when you enable a larger community to join fusions then fusions will become smoother. It is a network effect.

#2

Only 1 and 2 are relevant for the protocol. The other points are wallet specific implementation details and should be discussed within the relevant wallet projects.

  1. I agree. The main benefit of protobuf is when it’s used in gRPC which CashFusion is not based on. A simple JSON format is better suited in this protocol. A change to JSON in itself is not warranted but should be done when other breaking changes is done, such as:

  2. Timings can and should be optimized and it would be helpful if someone conducted the research to get a new proposal.

1 Like
#3

Points 1, 2 and 6 mostly trace back to the client-server model, so worth putting a working alternative on the table.

@0pen and I have worked on a P2P CashFusion based on Nostr (00 Joiner, part of the BCH Stealth Protocol), coordinated peer-to-peer instead of through fusion server.

  1. Protobuf: In our model it’s dropped entirely. Wire format is JSON in Nostr events. The only public event is the pool announcement (kind 22230): an availability beacon signed by a per-round ephemeral key, advertising input/output counts, no real identity attached. Everything else, all round coordination (kind 22231), is NIP-59 gift-wrapped and NIP-44 encrypted, signed by a one-time ephemeral key per message, so the relay only ever sees opaque kind 1059 blobs it can’t link to a round or to the peers. Outputs are onion-encrypted, so the join order isn’t visible to peers either. Nothing binary-stable to maintain across clients beyond the kinds.

  2. Timings: The tight Tor windows and ~2s polling come from one server holding round state and everyone syncing to it. With Nostr the relay just stores signed events. Peers can subscribe and submit inputs, commitments and proofs when ready, so the schedule can be looser and more predictable, closer to the check-back-in-N-seconds model you described, without a constant heartbeat.

  3. The failed-round / thin-pool problem is largely a side effect of each CF server running its own isolated pool. Nostr relays aren’t siloed. A round can pull participants across multiple relays, so the effective pool can trend toward the whole network rather than whoever happens to be on one server right now. That can help the network effect more directly than background fusion alone, though the two stack. Btw we treat Tor as optional here rather than a hard dependency.

Repos if anyone wants to dig in:
Protocol: https://github.com/00-Protocol/BCH-Stealth-Protocol
Wallet: https://github.com/00-Protocol/00-Wallet

1 Like