Deal with renamed tokens about bittytax

[icstm]

As requested: Voyager (VGX) is BQX on Binance.

[nanonano]

See https://github.com/BittyTax/BittyTax#data_source_select for more information.

[nanonano]

Dealing with renamed tokens is explained in the README.me.

Cryptoasset symbol names need to be consistent throughout your transaction records. For example, Bitcoin Cash was referred to as both BCC and BCH at the time of the first fork, but more recently as BCHABC or BAB. The symbol name you choose should match the symbol name used by the price data source, otherwise valuations will fail. See Price Tool for more information.

When Excel integration comes, there will be macros to help you normalise the symbol names in your transaction records.

[aleqx]

I think it's easier for BT to do it than the user mangling their data every time they export, which is why I added a conf list

[nanonano]

Aliases for symbol names when global can cause more collisions, it's better that the data is normalised before its processed by the accounting tool.

This normalisation is best done by the conv tool as it knows the symbol name in context of the exchange data being parsed. This already happens in the Coinfloor parser in a primitive way, but could be implemented better as part of the data parser instantiation, in addition to a central repository.

It's better that the user is aware of this normalisation of their data, in a transparent way, rather than the accounting tool masking the problem.

[aleqx]

I either don't understand the argument, or I disagree. The user and the conv tool are not the ones using remote price data. The main tool is. The main tool may use any price index provider, which may also have different token names from other providers - that's very common. It's certainly the main tool which should be doing the translation. Doing it manually in the source file or having the conv tool do it doesn't solve the problem ... in fact, it contributes to the problem.

I also don't understand the masking argument -- the tokens that are renamed are listed in the .conf file, and under the control of the user.

[aleqx]

In addition - the tool can always inform/warn the user that a renaming occurred, just like it already informs of missing prices.

This is better for the user too as they won't be caught out. When re-exporting data from exchanges that risks either (1) reintroducing old names or (2) some token has been renamed -- it's not hard for these to go undetected when running the main tool currently (the missing price data doesn't always jump at you, nor is it guaranteed to be visible in the last page/console screen).

[nanonano]

Yes the conv tool could inform the user that the symbol name has been normalised, that is a good idea.

The price tool already has config for mapping of a symbol to a data source and asset-id.

If you re-export our data from an exchange, the conv tool would normalise so you won't introduce old names.

Re: price tool, there is a price data appendix in the PDF tax report. This contains all the prices used, and identifies any which are missing, it's important that these are reviewed by the user, this is described in the README file.

[farynaio]

The price tool already has config for mapping of a symbol to a data source and asset-id.

@nanonano I examined the Readme and config file, but I couldn't found anything related to this. Can you please explain how it works and how to configure it? Thanks