Different derivation path for CashFusion addresses

Wallets
#1

When users want to fuse their coins, they usually do so inside their main Electron Cash wallet. The current implementation uses change addresses for fused outputs, which are used and discarded. This rapidly consumes the first change addresses and makes the wallet heavy and unresponsive.

The current mitigation is to only scan for an n amount of change addresses. However, that means users will not be notified if they receive funds in a change address in the future. Also, change addresses are meant to be used for that, change. Mixing protocols were not envisioned when they were first added.

Even if there is not yet widely implemented by wallets, CashFusion and other mixing protocols, a proper use of the addresses is important. And a standard can be created now so that new wallets are aware of this.

This idea comes in part from Samourai Wallet, which implements a mixing protocol and has different derivation paths for premix and postmix coins.

  • For premix coins, the derivation path is: m/84'/0'/2147483645'
  • For mixed coins, the derivation path is: m/84'/0'/2147483646'

A wallet compatible with CashFusion will only use those derivation paths to search for unspent fused outputs. Smarter wallets should be aware of this and their differences, so in the future it is easier to know how to treat those coins in particular or even if a different derivation path is used for each new protocol.

1 Like
#2

That’s an interesting idea and potentially elegant solution. However, it also makes Electron Cash wallets less portable since there are no other mainstream CashFusion-supporting wallets and other wallets probably won’t implement this right away. In fact, there’s another active topic discussing the issue of different derivation paths used by different BCH wallets currently. That being said, I assume most people using CashFusion on Electron Cash wallets don’t really consider those wallets to be particularly portable anyway, so I’m not sure how much of a problem it really is.

Also, due to differences in the CashFusion implementation I don’t think the “pre-mix” derivation path/holding zone is necessary. Electron Cash could probably simply use Deposit (standard) and Post-Mix paths.

1 Like
#3

Thanks for your reply. Let me go deeper into some points you mentioned.

I agree with this, but there is currently no other major wallet with CashFusion support and we would be directing efforts to follow this (potentially) proposed standard. Wallet developers have incentive to implement similar features and standards, but they tend to create new solutions when they believe a problem is not addressed correctly.

For that reason, I think would be better to make changes now than dealing with competing solutions in the future.

I am aware of this ongoing discussion, but I think it was better to create a dedicated thread since it is a technically different issue.

I don’t think that either. I would argue that it would be even better to create a completely different derivation path than those, which only serve as examples.

#4

I actually think the unresponsive part has been fixed already, you might want to try updating to latest.

I also want to point out that just moving the change addresses onto a new derivation sub-path will not have any effect on the amount of addresses that need to be monitored. You just change where they come from. Nothing more.

#5

I like the general idea. Seems reasonable.

And CashFusion indeed does make Electron Cash painfully slow, I have experienced it myself after multiple fusions.

Indeed.

The solution would appear to be to just create a second wallet for the user when Cash Fusion is initially started. Obviously, also popup a prompt to the user so he can write down and confirm the seed.

This way ElectronCash + CashFusion will just contain & manage 2 separate wallets and will retain compatibility with other CF implementations.

To do it the easy way, the additional word could always be the same word. Not sure what are the privacy implications of such simplification though.

#6

Since change addresses are meant to be used for change outputs in transactions, I don’t think moving CashFusion addresses to a new path is a bad idea, even if that doesn’t change the amount of addresses requiring monitoring.

The main advantages are a cleaner and easier user experience and an easy way to obtain fusion addresses.

#7

Instead of a second wallet, a different derivation path can use the same seed, no extra work from the user is required.

#8

Yes - it is the easiest solution, however that will require more work from all wallet developers that want to support CF.

And also it will make current CF implementation incompatible with other CF implementations (if there are any).

I guess is there aren’t any more working CF implementations right now, this will suffice.

#9

From what I understand, the implementation of CashFusion itself has nothing to do with how wallets provide addresses to the server. The implementation doesn’t need to be changed and the server wouldn’t know about changes in the derivation path, for example.

This change should be 100% compatible with current CashFusion usage.

#10

If CF for Electron Cash is the only currently working CashFusion implementation, then there is no need for compatibility.

It will just become the standard automatically.

Derivation for CF change addresses can be made by either using different derivation path, or adding an extra word(s). It doesn’t matter.

#11

As I support cashfusion transactions in Flowee Pay, I can say that the slowness is likely an implemetation problem in the wallet you are using. It is not present in Flowee Pay where having all those transactions in your wallet is basically invisible to the user.

As the author of a wallet that is aimed at a larger number of users than the expert-friendly wallet you are talking about, I think that the user experience of addresses can be improved by the wallet without using a different derivation.

Sure, one little downside. No other HD wallet can find your funds. That has nothing to do with cash-fusion, btw.

#12

Wait, what? Flowee Pay has CashFusion now?

That’s literally awesome.

I tried to install Flowee Pay before BTW, but it failed on my operating system. I did not have time to debug it back then.

#13

One way I can image it would do some good is if the coins are transferred back to the main path once the fusion is “done”. When new coins are going to be fused the wallet provides output addresses from m/44'/145'/<some CF specific number>/ and keeps fusing with those addresses until the wallet consider the fusion as “done” and then provides address from m/44'/0' or m/44'/145' for the last round of each coin.
Non-fusion aware wallets will never scan the CF path with “ongoing” fusion coins and thus never spend them.

The question here is what the definition of “done” for Cash Fusion is. Or if this really is a problem that needs to be solved.

I’m not saying this is a good idea – just food for thought.

2 Likes
#14

Pokkst, when he was still developing Pokket.cash, set things that any CF transactions the Pokket wallet makes is sent to m/44'/145'/2016'.

Source here: Link

1 Like
#15

I like this solution even if I personally prefer to have funds completely separated.

Currently, Electron Cash allows you to set a minimum of rounds for coins to be used. This heuristic could help to determine when the fusion is “done.”

#16

Indeed, however Pokkst officially (desperado style I would say) left the BCH ecosystem and his software should receive deprecated/abandoned status, until somebody will take it over and actually maintain it for a year or so.

Whatever derivation Pokkst used, is irrelevant right now. CashFusion implementation from Electron Cash should be treated as the golden standard for the future.

#17

imo, this is 100% the way to optimally manage a CashFusion wallet … CF addresses are 1-offs, there’s no need to scan them for subsequent incoming txs, so they can be forgotten, which i a perfect reason to put them onto their own derivation path.

not to go digging up an old thread (which i only just read tonight), but to just throw my 2 cents into that “other” discussion, i have to disagree with @tom and his utter dismissal of the “privacy” implications behind sharing a derivation path between BCH and BTC

IF the user DOES NOT share a seed phrase (not the case in Bitcoin.com wallet), then they would have no issues … otherwise, this is EXACTLY the problem with EVM and the account model.

i would have to believe that MOST users (eg. using MetaMask) DO NOT reset their seed phrase when switching between (countless) EVM chains.

and it’s the reason why I won’t even use shomari.eth , shomari.bch, etc unless I’m doing a “very public” transaction, otherwise my ENTIRE transaction history becomes available for EVERY EVM chain that I’ve ever used (and will use in the future)

although, it’s certainly harder to trace with a UTXO model, chainalysis tools are widely available (even open source, iirc), so this is a real problem for even BCH

so I’ll say to that:
+1 for separate BTC/BCH paths (as ideal, but not necessary)
+0xFF for every wallet scanning multiple paths (i mean how freakin’ hard is it to write a loop??)

#18

Notice that there is zero reason to scan for subsequent incoming transactions for the change chain as well. We already use that fact in Flowee Pay.

To be clear, I did NOT dismiss the privacy issue. In fact I agree with this privacy issue being real and think that the bitcoin,com people did it wrong (although for very understandable reasons). They invisibly expose multi-chain users to a privacy issue.

What I did dismiss in that other thread is the solution of using a different derivation path, because simply using a new seed-phrase for a different chain makes so much more sense. This website we use is for researching how to do things properly. We design things that the software will then give as features to the user. Balancing UX and privacy, in this case.

It is my opinion that a good wallet assists the user in creating a new account and it generates a new seed phrase. Make that the best way the easiest to use and avoid all the mess that comes with these derivation paths.

#19

yes, that’s true!

I do agree that it’s the “right way” to do it! Similar to people that re-use passwords on 100 different sites vs people that use password managers.

bcom’s wallet let’s you create multiple wallets for each currency. and i’ve noticed that when you “add” a new wallet, it generates a “unique” seed phrase. so i’m wondering if they only shared seeds at the “initial” setup for ALL supported wallets.

it seems like they already have the functionality there, but just choose not to use it. eg. my newest device has bch, btc and eth all sharing the same seed phrase. but when i add avax, it gets a unique seed. so that dispells the idea that the “first” account on a chain all share a seed. it’s ONLY the ones that are created at installation of the app.

anyway, wish we could just look at the code to know exactly what’s happening :unamused: