kanzure / webcash

Webcash is an experimental "e-cash" (electronic cash). See https://webcash.org/

Webcash

Webcash is an experimental new electronic cash ("e-cash") that enables decentralized and instant payments to anyone, anywhere in the world. Users send webcash to one another directly on a decentralized peer-to-peer basis by copying-and-pasting their webcash to their recipient. The central server helps webcash wallets detect double-spending and ensure the integrity of the monetary supply according to the supply schedule.

Navigate to https://webcash.org/ for more information, including the Terms of Service.

Installation

This is a python-based webcash wallet client. To install the latest version on the python package index, use this:

pip3 install webcash

Otherwise, install locally for testing or development purposes:

pip3 install .

If you want to run the software without installing the module, you still need to install the dependencies:

pip3 install -r requirements.txt
python3 -m webcash.walletclient info

Usage

webcash setup
webcash status
webcash pay 5
webcash pay 18 "memo: for lunch with bob"
webcash insert <webcash goes here>

Mining

See webminer for a substantially faster mining client.

This repository contains the original reference implementation of the miner which is much slower:

python3 miner.py

License

This repository and its source code is distributed under the BSD license.

webcash's Issues

Insert/pay should peek secrets until transaction is committed

Right now the new secrets are allocated for a transaction regardless of whether the transaction confirms or not. So if you insert a secret into a wallet and the insertion fails, the replacement secret is still allocated.

This created an issue for me because I was inserting a batch of a few hundred secrets from webminer's webcash.log file. Unfortunately the my internet connection went out in the middle and so some secrets time out and weren't inserted. And because I am lazy I decided to just cat webcash.log | xargs -n 1 webcash insert the whole list again. I know, I know: bad on me for wasting server CPU time. But it got the job done since duplicate insertions are rejected by the server.

Only in the process my key counts increased by the size of the webcash.log file, even though only a few of them were valid. This means if I try to recover from a wallet backup it won't be successful, because I have a gap of 100's of secrets. It will still be recoverable, thankfully, but not with default options and not without an equivalently large drain of server resources.

Comparatively, miner.py "peeks" at the next secret and only commits if it actually finds a proof-of-work solution. This should be the behavior for all the wallet APIs: fetch a new secret to construct the transaction, but only commit it if the transaction confirms. Any error and the key counter is left at wherever it was before.

Recovery misidentifies existing outputs as PAY

When recovering a wallet I got a lot of outputs that were found which look like this:

Found known webcash of amount: 190000 (might be a payment)

These were from the RECEIVE chain code though, so I was confused. From looking at the source, I think what is going on is if it recovers an output which the wallet already knows about then it outputs the above statement, which is confusing. There should probably be a different report for such 'skipped' outputs.

Save destination keys to wallet prior to 'replace' operation to prevent loss of funds

If the server times out or the network connection is disconnected while performing a replacement, it is possible that the action is still performed by the server even though a confirmation was not received by the client. In such cases the requests python module will error out, which causes the whole operation to be cancelled, and the new ephemeral key is thrown away.

This combination of events, which has happened during recent server overloads, results in certain loss of funds. Although switching to deterministic wallets will mitigate the worst aspects of this problem, a stopgap measure is still needed before then to protect user funds.

Probably the easiest solution is to save the wallet with a "unconfirmed" array of webcash secrets just prior to making the replace API call. Should a wallet later be opened with this field populated, the secrets should be run though the health check API to see if the transaction went through.

Better handling of network request failures

The error handling around API requests could be a lot better. Right now the clients have nearly no ability to recover from network or server availability problems on a per request basis.

Impacts:

• deterministic wallet
• secret derivation/generation
• walletdepths
• inserts/payments

Sorting webcash in wallet to enable effecient consolidation

Does it make sense to auto-sort webcash secrets in the wallet?
This mimics real life behaviour where you use up small denoms for any transaction before dipping into bigger denoms.
Currently the wallet searches for exact value or consolidates top of stack, irrespective of value.

I have an implementation and PR available to be merged.