spesmilo / spesmilo/electrum

Privacy feature: wallet without co-mingled funds.

Open
#7,757 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
8.6k
Forks
3.5k
Avg merge
2d 8h
Merged PRs (30d)
61

Description

To date, afaik all Bitcoin wallets tend to co-mingle sources of funds over time. For example:

Jim spends input A (from Alice) which leaves change B. Jim later spends B combined with C (from Bob). Alice, and Bob are now connected in the blockchain, which is not necessary.

method 1 -- isolate by source of funds
Jim could prevent this co-mingling by creating a separate wallet for each source of funds, one for receiving funds from Alice and another wallet for receiving funds from Bob.

method 2 -- isolate by each incoming Tx
Jim could go even further and create a new wallet each time he provides a receive address to Alice or to Bob. This would prevent tx (a) from Alice from being tied to tx (b) from Alice. At least within Jim's future spends.

The downside of this of course is that sometime Jim may need to combine inputs from different sources in order to make a large payment. Because Jim has been maintaining separate wallets for each source, it is clear and apparent to Jim that this combination of sources is occurring and he can weigh the risk/benefit of doing this.

All of the above is possible today, however it is very cumbersome for Jim to manage. In particular because each wallet requires seed phrase to be written down and stored securely.

The proposed feature then is to have a single wallet that guarantees to Jim it will avoid co-mingling of incoming funds.

Such a wallet can easily implement method 2. It would tag each incoming Tx. It would present a total balance and a list of "spendable balances". Every change output would be associated with the original incoming Tx. All utxo associated with the same incoming Tx would be summed to form a single spendable balance. Typically there would only be 1 utxo at a time associated with a given ancestor incoming Tx (unless intentionally splitting by sending to self).

This is different from coin-control. Coin-control is an optional thing that can be done (or not) at any time. In contrast, this feature/option would be chosen when the wallet is first created and would apply to all Tx during the life of the wallet. It would be considered a wallet type, eg a "non comingled wallet", though hopefully a less awkward name could be found.

If a wallet wishes to implement method1, then it must rely on Jim to specify who is the source of funds when generating a receive address. This relies on Jim using a unique address for each possible source of funds. As such, there is opportunity for user mistakes and the wallet software cannot guarantee funds have not been co-mingled. For this reason, I would think that initially at least, Electrum might implement method2, and not method1.

Anyway, I am curious to hear thoughts on this idea. I am not aware that electrum (or any wallet software) presently implements it, but if so, please let me know.

edit: even for method2, the wallet should require or at least strongly encourage Jim to enter a label for each receive address. This then helps categorize any funds later received by that address, and helps Jim decide which input to use when later sending funds.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing Electrum's existing wallet and coin-control concepts against the proposed method 2. Determine where wallet type, incoming transactions, change outputs, spendable balances, and receive-address labels are represented. Done would require an agreed design and implementation plan for preventing co-mingling throughout the wallet's lifetime.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.