search

simpleledger / Electron-Cash-SLP

Electron Cash for SLP Tokens
https://simpleledger.cash/project/electron-cash-slp-edition/
MIT License
67 stars 53 forks source link

Separate path of SLP tokens with BCH #48

Closed imaginaryusername closed 4 years ago

imaginaryusername commented 5 years ago

It'll be a long road to merge EC-SLP into mainline, but I propose this needs to be done as early as possible to prevent complications later as SLP gains popularity. Some todo things off top of my head:

  1. When creating wallet, have two address derivations: 145' and 245' by default. Ditto for importing - give two paths, they can be the same for legacy reasons if needed.

  2. The "receive" tab now has a tab asking whether you want to receive tokens or BCH, similar to the send tab. Remove ability to switch between cashaddr and simpleledger by the bottom address format button - they'll coexist and "switchable" by this change instead.

If you switch to BCH, it takes receive address from 145'/0'/0'; if switch to token, 245'/0'/0'. Change should follow a similar convention, for outgoing transactions sending tokens change addresses should be picked according to whether tokens exist on that address.

  1. The wallet shall still recognize untagged BCH on all addresses as well as tokens on all addresses for compatibility reasons. When loading old wallets, if it's an 145' default or BIP39 wallet, an 245' path should be automatically created for it; otherwise there should be a dialogue prompting if a user wants additional derivation paths for safety.

  2. After these are done, SLP history can be merged into the main "history" tab; that should make for vastly better UI. There can be an additional column "SLP amount".

  3. SLP balance can stay on its own tab.

  4. The "Coins" tab might gain an additional "SLP balance" column.

Just a batch of suggestions as a starting point, please let me know what can/should be changed. =)

Platinumwrist commented 5 years ago

Sounds great with additional balance column and I'm understanding the switchable tabs with Addresses thanks for useful

jcramer commented 5 years ago

@imaginaryusername

Just to clarify, you are suggesting that the wallet actively uses both 145' and 245' paths, so any non-token UTXOs are on 145' and all token UTXOs are on 245'?

I agree this would be the most ideal approach.

imaginaryusername commented 5 years ago

@jcramer yes, and imo this will lead to maining becoming much easier down the line.

jcramer commented 5 years ago

@cculianu @markblundeberg @fyookball any reservations on this? When would we want to start tackling this? I assume before SLP merges with mainline/cashshuffle we would want this done.

Tentative order of events: 1) After cashshuffle merges into mainline, merge mainline into SLP 2) temporarily disable CS parts in SLP 2) Update SLP code so all BCH utxos are on 145' and token utxos on 245' 3) Merge SLP into mainline

cculianu commented 5 years ago

Hey @jcramer -- I just had a moment to read this. I think the order of events you outlined is 100% good (or, at least what I had in my mind too).

So yeah we can merge cashshuffle into SLP and just be sure it's 100% turned off (in the UI and in the code). It's a plugin, after all (mostly) with minor hooks in the main_window.py file (mostly).. it won't be too bad.

Wallet.py was pretty much untouched by CashShuffle.. really Yura did 1 great thing with respect to that: He kept all the changes within the plugin. And I tried to continue that keep all the code within the plugin. So -- it shouldn't really be too bad.

So just to clarify the "slpaddr" format is going away then? Is that a problem (I admit I don't know what goes into an slpaddr I just assumed a different checksum or magic byte in the encoding or something like that).

I do like the idea of actually making use of derivation paths. But I'm not the best person to ask/decide this since I'm not as "in tune" with what's trendy in bitcoin culture and what people hate/fear. But reading the spec on HD wallets, it really sounds like the original authors had this kind of usage in mind when they came up with this stuff.

As far as derivation paths go: Purely from a code/organizational perspective it would be a nice separation. I'm in favor of doing this for CashShuffle if CashShuffle really takes off and we have the "gravitas" to impose that. Would make everything easier if it's a good idea and doesn't create more hassles for users. But again -- I am not the best person to decide this.

imaginaryusername commented 5 years ago

@cculianu no, simpleledger: isn't gonna go away: it's more like it'll be baked into receive mechanism and people won't be give an option to switch between that and cashaddr willy-nilly. For example if you choose to receive BCH, you'll be given a bitcoincash:, if you choose to receive some token you'll be given simpleledger:. You won't need to manually select them using the format switch button, it'll be much more intuitive with less margin for error.

If people really want to extract a simpleledger address and use it to receive BCH, they can still either switch to legacy format or use the address converter.

cculianu commented 5 years ago

Ahhh ok. That makes a lot of sense actually. Less margin for error == good. Sounds good.

jcramer commented 4 years ago

I'm going to close this issue because I don't think it's going to happen with this wallet.